Conception de bases de données

Signaler

Le respect des contraintes d’intégrité et de normalisation permet d’éviter la survenue d’anomalies dans les bases de données. Le modèle entité-association conduit à des schémas relationnels respectant ces contraintes.

I. Exemple d’anomalie : redondance de données

Lorsque les bases de données n’ont pas été suffisamment normalisées ou lorsqu’elles n’ont pas été conçues de sorte que les contraintes d’intégrité soient respectées après modification des relations, des anomalies peuvent apparaître, comme la redondance de données.

Considérons, par exemple, une base de données modélisant les produits achetés par une entreprise, avec le schéma relationnel :

feec95dc-d933-481b-8807-5e7c1a176c4c

Un exemple de table pour ce schéma :

8e2e079f-2b9a-42e1-a087-2fd0cd6152e0

L’adresse est redondante dans cette relation, celle des Vergers du Sud apparaissant plusieurs fois, ce qui a un coût d’espace et conduit à des performances moindres de la base de données.

La solution typique consiste à séparer cette relation en deux :

une relation Fabricants = ((Fournisseur, S), (Adresse, S)) ;

une relation Produits = ((Produit, S), (Fournisseur, S)).

L’exemple précédent devient :

90187ed1-5d41-4ca2-b438-ddec74da45cd

Néanmoins cette solution n’est pas pleinement satisfaisante. Si la société Vergers du Sud change de nom ou est supprimée de la relation Fabricants, la table Produits aura une anomalie de mise à jour (ou de suppression), car les produits Tomate et Ananas ne seront plus référencés. Et si une nouvelle société prend le même nom qu’une déjà existante on aura une anomalie d’insertion.

II. Élaboration d’un modèle conceptuel des données

1) Le modèle entité-association

La première étape pour aboutir à un modèle permettant de stocker les données dans une base consiste à identifier les objets à représenter ainsi que leurs liens. Cela aboutit à un modèle conceptuel des données (MCD), comme le modèle entité-association présenté ici.

Une entité est une unité de base du système modélisé. Il peut s’agir d’individus, d’objets qui ont commun les mêmes propriétés.

Une association représente un lien entre entités. Elle peut être binaire et représenter un lien entre deux entités A et B, nommée par un verbe. Si chaque occurrence de l’entité A est liée à au plus une occurrence de l’entité B on parle de relation binaire fonctionnelle, sinon on parle d’association non fonctionnelle.

2) Un exemple

Prenons comme exemple l’étude simplifiée de la gestion d’un parc immobilier. Des propriétaires possèdent, éventuellement collectivement, un ou plusieurs appartements, un locataire occupant un appartement.

Trois entités se dégagent ici : les propriétaires, les locataires et les appartements. Il y a un lien représenté par le verbe « habiter » entre l’entité locataire et l’entité appartement. Ce lien est une relation binaire fonctionnelle dans la mesure où on admet qu’un locataire n’occupe qu’un seul appartement. Il y a un lien représenté par le verbe « posséder » entre l’entité propriétaire et l’entité appartement. Cette association n’est pas fonctionnelle car un propriétaire peut posséder plusieurs appartements et, réciproquement, il peut exister des co-propriétaires.

III. D’un MCD au schéma relationnel

D’un MCD, on en déduit un schéma relationnel en utilisant les règles suivantes :

Toute entité donne lieu à une table dont la clé primaire est l’identifiant de l’entité.

Toute association binaire fonctionnelle est implémentée par la présence d’une clé étrangère dans la table qui représente l’entité origine de la dépendance fonctionnelle.

Toute association non fonctionnelle génère une table dont la clé primaire est l’ensemble des clés primaires des tables qu’elle relie.

L’exemple précédent donne (clés primaires en gras, clés étrangères en italique) :

b94ad77b-4b46-42e5-a8d0-bf0f35fdb1df

L’association « habiter » est représentée par une clé étrangère dans la relation Locataire, l’association « posséder » par la relation ProprioAppart.