Conception d'une base de données
Préparé par : Ahmed OULD TEBAKH, ing
Consultant en informatique
05 décembre 2006
Ce support de cours regroupe quelques notions concernant le modèle entité-association, le schéma relationnel et la traduction de l'un vers Vautre.
Mots-clef : Merise. MCD. entité, association, MLD. relation, traduction, MPD
Table des matières introduction 2
1 Modèle conceptuel de données (MCD) 2
11 Sc hema (mtité-assoriatioi) 2
1.2 Cas particuliers 4
13 Roules de normalisation 6
14 Méthodlogie 7
2 Modèle logique de données (MLD) 7
2.1 Systèmes logiques 7
2.2 Scliéma relationnel 8
2.3 Traduction 8
3 Modèle physique de données (MPD) 12 4 Rétro-conception 12
5 Compléme nts 13
5.1 Agrégation 13
5.2 Identifiant relatif 14
5.3 Sous entité .. . .. 16
5.-3 Sous-associât ion .. ....... 17
Conclusion 18 Table
des figures 19
2 MODÈLE LOGIQUE DE DONNÉES (MLD) 8
2.2 Schéma relationnel
Concentrons-nous sur le MLDR. Lorsque des données ont la même structure (comme par exemple, les bordereaux de livraison), on peut les organiser en table dans laquelle les colonnes décrivent les champs en commun et les lignes contiennent les valeurs de ces champs pour chaque enregistrement.
Les lignes d'une table doivent être uniques, cela signifie qu'une colonne (au moins) doit servir de clé primaire. La clé primaire d'une ligne ne doit pas changer au cours du temps et ne peut contenir la valeur NULL, alors que les autres colonnes le peuvent.
Par ailleurs, il se peut qu'une colonne Colonnel d'une table ne doive contenir que des valeurs prises par une colonne Colonne2 d'une autre table (par exemple, le numéro du client sur une commande doit correspondre à un vrai numéro de client). La Colonne2 doit être sans doublons (bien souvent il s'agit d'une clé primaire) et on dit que la Colonnel est clé étrangère.
Par convention, on souligne les clés primaires et on fait précéder les clés étrangères d'un dièse # dans la description des colonnes d'une table :
clients(numéro client, nom client, prénom, adresse client, ...) commandes(numéro commande, date, #numéro client, ...)
Remarques :
- une même table peut avoir plusieurs clés étrangères mais une seule clé primaire (éventuellement
composées de plusieurs colonnes) ;
- une clé étrangère peut aussi être primaire;
une clé étrangère peut être composée (c'est le cas si la clé primaire en liaison est composée). La section suivante contient des exemples.
On peut représente]- les tables d'une base de données relationnelle par un schéma relationnel dans lequel les tables sont appelées relations et les liens entre les clés étrangères et leur clé primaire est symbolisé par un connecteur :
2.3 Traduction
Pour traduire un MOD en troisième forme normale en un MLDR. il suffit d'appliquer cinq règles (à connaître par coeur). Mais avant, on dit qu'une association entre deux entités (éventuellement réflexive) est de type :
- 1 : 1 si les deux cardinalités sont 0,1 ou 1,1 ;
- 1 : n si une des deux cardinalité est 0,n ou l.n;
- n : m (plusieurs à plusieurs) si les deux cardinalités sont 0,n ou l,n.
2 MODÈLE LOGIQUE DE DONNÉES (MLD) 9
En fait, un schéma relationnel ne peut faire la différence entre 0,n et l,n. Par contre, il peut la faire outre 0.1 et 1,1 (cf. règles 2 et 3).
Règle 1 : toute entité devient une table dans laquelle les attributs deviennent des colonnes. L'identifiant de l'entité constitue alors la clé primaire de la table.
Par exemple, l'entité articles de la figure 9 devient la table :
articles(numéro article, nom article, prix unitaire de vente, ...)
Règle 2 : dans le cas de deux entités reliées par une association de type 1 : n, on ajoute une clé étrangère dans la table côté 0.1 ou 1,1, vers la clé primaire de la table côté 0,n ou l,n. Les attributs de l'association glissent vers la table côté 0,1 ou 1,1. Et si la cardinalité est 1,1 alors la clé étrangère ne peut recevoir la valeur NULL (autrement dit, vide interdit).
Par exemple, l'association livrer de la figure 9 est traduite par :
fournisseurs(numéro fournisseur, nom fournisseur, téléphone, ...)
livraisons(numéro livraison, date, #numéro fournisseur (non vide), nom livreur)
Règle 3 : dans le cas de deux entité.- reliées par une associât- n de type 1 : 1. on ajoute, aux deux tables, une clé étrangère vers la clé primaire de l'autre. Afin d'assurer la cardinalité maximal, de 1. on
ajoute une contrainte d'unicité sur chaque de ces clés étrangères la colonne correspondante ne peut
prendre que des valeurs distincte- Les attributs de l'association sont alors repartis vers l'une des deux tables. Et si la cardinalité est 1.1 alors la clé étrangère concernée ne peut recevoir la valeur NULL (autre¬ment dit, vide
Par exemple. l'association résider de la figure 8 est traduite p
êtres humains(numéro personnel, nom, prénom, #numéro appartement (unique),
date d'entrée, ...) logement(numéro appartement, adresse, #numéro personnel (unique),
montant du loyer, ...)
2 MODÈLE LOGIQUE DE DONNÉES (MLD)
10
En fait, la règle 3 considère que le type 1 : 1 correspond à deux type 1 : n symétriques. Autre technique : ajouter une table intermédiaire dont la clé primaire est composée de clés étrangères vers les clés primaires des tables en association et une contrainte d'unicité sur ces clés étrangères (c'est-à-dire considérer le type ] : 1 comme un cas particulier du type n : m) :
êtres humains(numéro personnel, nom, prénom, ...) logement(numéro appartement, adresse, ...)
résider(#numéro personnel (unique), #numéro appartement (unique), date d'entrée, montant du loyer)
2 MODÈLE LOGIQ UE DE DONNÉES (MLD) 11
Par exemple, l'association concerner (1) de la figure 9 est traduite par :
articles(numéro article, nom article, prix unitaire de vente, ...) lignes de commande (tournéro commande, #numéro article, quantité commandée) commandes(numéro commande, date, ...)
Règle 5 : une association non binaire est traduite par une table supplémentaire dont la clé primaire imposées d'autant de clés étrangères que d'entités. Les attributs de l'association deviennent des mnes de cette table.
exemple, l'association vols de la figure 7 devient la table : ". s(#numéro avion, touméro pilote, touméro aéroport, date et heure, durée, distance)
3 MODÈLE PHYSIQ UE DE DONNÉES (MPD) 12
3 Modèle physique de données (MPD)
Bien que certains outils (PowerAMC notamment) considère que le MPD et le MLD représentent la même chose, c'est faux. Le MPD est une implémentation particulière du MLD pour un matériel, un environnement et un logiciel donné.
Notamment, le MPD s'intéresse au stockage des données à travers le type et la taille (en octets ou en bits) des attributs du MCD. Cela permet, de prévoir la place nécessaire à chaque table dans le cas d'un SGBDR.
Le MPD tient compte des limites matérielles et logicielles afin d'optimiser l'espace consommé et d'optimiser le temps de calcul (qui représentent deux optimisations contradictoires). Dans le cas d'un SGBDR, le MPD définit les index et peut être amené à accepter certaines redondances d'information afin d'accélérer les requêtes.
Par exemple, la table commandes de la figure 14 peut être supprimées et ses colonnes, notamment date, sont ajoutées à la table lignes de commandes. On renonce donc à la troisième forme normale
puisque la date est répétée autant de fois qu'il y a de lignes dans la commandes, mais on évite une jointure coûteuse en temps de calcul lors des requêtes.
Une application pratique de la séparation entre le MLDR et le MPD est le portage d'une base de nées d'un SGBD à un autre. Par exemple, on peut traduire un MPD Access on un MLDR puis traduire MLDR en un MPD Oracle.
l Rétro-conception
Dans la majorité des cas, le travail du concepteur de bases de données consiste non pas à créer une
mais plutôt à corriger ou étendre une base existante. Dans ce cas, la donnée est un modèle léthode consiste à. le traduire en un modèle conceptuel, modifier ce modèle et régénérer le modèle physique modifié. Il s'agit de rétro-conception ou reverse engineering.
bases de données relationnelles, il suffit de traduire le modèle physique en un MLDR,
puis d'appiquer les règles de traduction du paragraphe 2.3 dans le sens inverse.
Règle 1 les tables dont la clé primaire est non composée (et non clé étrangère) deviennent des
entités ( les colonnes - non clés étrangères deviennent dos attributs et la clé primaire devient identifiant).
Règle 2 : les tables dont la clé primaire est composée (exclusivement) de clés étrangères deviennent
des associations n-aires, où n est le nombre de colonne définissant la clé primaire (les autres colonnes non
clés étrangères de viennent attributs).
5 COMPLÉMENTS 13
Règle 3 : les colonnes clés étrangères restantes deviennent des associations binaires de type 1 : n (il reste à ré-inventer leur nom).
Règle 4 : les cardinalités minimales sont 1 si figure la. mention (non vide) et à retrouver par le bon sens sinon (0 par défaut). Les cardinalités maximales sont 1 ou n selon que la mention (unique) figure ou non.
5 Compléments
Les extensions présentées dans cette section font partie de la version 2 de Merise (cf. [ ]). Elles
permettent de traiter certaines situations réelles plus simplement.
5.1 Agrégation
Exemple : dans un entreprise dont les représentants vendent des produits dans différentes régions, une des règles de gestion est qu'un produit pour une région donnée, ne peut être vendu que par un seul représentant.
Si on se contente du schéma de la figure 17, alors cette règle n'est pas forcément respectée. Il faut
utiliser une agrégation qui permet d'associer une entité à un couple d'entités en associations (cf. figure
L'agrégation constitue alors une entité dont l'identifiant est composé des identifiants de ses propres
iation.
5 COMPLÉMENTS 14
Comme l'association vendre est de type 1 : n. le schéma relationnel que l'on obtient est alors le suivant :
représentants(numéro représentant, nom représentant, ...)
régions(numéro région, nom région, ...)
produits(numéro produit, nom produit, ...)
couvrir(#numéro région, ftnuméro produit. #numéro représentant (non vide), date et heure)
type n : m (cf. figure 19). alors le schéma relationnel ferait intervenir une table supplémentaire
représentants(numéro représentant, nom représentant, ...)
régions(numéro région, nom région, ...)
produits(numéro produit, nom produit, ...)
couvrir(numéro région. #numéro produit)
vendre(##numéro région. ##numéro produit, #numéro représentant, date et heure)
Identifiant relatif
une eut: du bâtiment numérote les factures relatives à un chantier par le numéro du
-uivi d'un numéro automatique. Les factures du chantier 14 sont 1401, 1402 et 1403 tandis que . chantier 15 sont 1501 et 1502.
5.3 Sous-entité
Exemple : les factures d'une entreprise font l'objet d'un règlement par chèque ou par carte. Cette entreprise souhaite connaître pour tous les règlements, leur date, pour les règlements par chèque, le nom de la banque et le numéro du chèque et pour les règlements par carte, le numéro de la carte, le nom de la banque et la date d'expiration.
On a donc une entité générique règlements et deux entités spécialisées chèques et cartes. Ces deux sous-entités de l'entité règlements ont des attributs propres mais pas d'identifiants propres.
Sur le schéma entité-association, on représente le lien qui unie une sous-entité à son entité générique par une flèche (cf. figure 22 ).
FIG. 22 - Représi ntation des sous-entités
La traduction des sous-entités au niveau logique relationnel fait intervenir une clé primaire commune ussi étrangère :
règlements(numéro règlement, date, nom banque)
chèques(#numéro règlement, numéro chèque)
cartes(#numéro règlement, numéro carte, date expiration)
Remarque au niveau logique objet, on retrouve la notion d'héritage.
5 COMPLÉMENTS 17
5.4 Sous-association
Exemple : une entreprise artisanale vend non seulement des produits à prix unitaire fixe, mais aussi des produits sur mesure dont le prix unitaire est calculé à partir de la durée de confection et d'un taux horaire.
Dans ce cas. non seulement l'entité produits est spécialisée en produits standards et produits personnalisés, mais en plus, l'association concerner entre les entités commandes et produits est spécialisée selon qu'il s'agit d'un produit standard ou personnalisé (cf. figure 23 ).
FiG. 23 - Représentation des sous-associations
On a alors les sov s-associations concerner standard et concerner personnalisé dont le lien avec l'association générique concerner est représenté par une flèche.
Dans le schéma relationnel, les sous-associations sont traduites de la même manière que l'association générique correspondante, mais avec leurs attributs propres :
?
produits(numéro produit, nom produit, ...) produits standards(#(l)numéro produit, prix unitaire) produits personnalisés(#(2)numéro produit, taux horaire) cocc&ndes(numéro commande, date, . . . ) concerner(#numéro commande, #numéro produit, quantité) concerner standard(##numéro commande, 3#(l)numéro produit) concerner personnalisé(##numéro corjr.ar.de. ##(2)numéro produit, durée)
CONCLUSION 18
Conclusion
Intérêts de la décomposition MCD/MLD/MPD :
- le MOD permet d'éviter certaines erreurs de conception (en contradiction avec les règles de norma¬
lisation) ;
le MCD permet de voir facilement quelles associations de type n : m, non binaires ou réflexives sont en présence (c'est important) ;
- le MLD peut être obtenu automatiquement par des outils de génie logiciel ;
- le MCD peut être traduit en différents MLD cohérents (notamment on peut traduire un MCD en
un MLDR puis en une base de données Access tandis qu'en parallèle le MCD est traduit en un
ensemble de classes Java (MPD orienté objet) afin de développer une application web sur cette base
Access).
Cependant, la méthodologie Merise est typiquement française. En Grande-Bretagne, la méthodologie standard s'appelle SSADM (Structured Systems Analysis ans Design Method) et repose sur les mêmes principes. Les nord-américains utilisent ce qu'on appelle des diagrammes de flux dont les principes sont repris par la version 2 de Merise.
Aujourd'hui, ce sont les méthodologies objets et leur unification UML (Unified Modeling Language, autrement dit langage unifié de modélisation objet) qui tendent à remplacer Merise et ses extensions objets. Le lecteur est donc invité à se documenter sur le cadre UML pour être à la pointe de l'état de l'art en méthodologie de conception.
TABLE DES FIGURES 19
Table des figures
1 Entités 2
2 Associations 2
3 Attributs 3
1 Identifiants 3
5 Cardinaiités 4
(i Association reflexive 4
7 Association ternaire 5
8 Associations plurielles 5
9 Normalisation des relations G
10 Schéma relationnel 8
11 Traduction d'une association de type 1 : n 9
\!) Traduction d'une association de type 1:1 10
13 Traduction alternative d'une association de type 1:1 10
M Traduction d'une association de type n : m 11
15 Traduction d'une association ternaire 11
16 Sacrifice de la troisième forme normale 12
17 Mauvais MCD 13
18 Solution avec- agrégation 14
19 Agrégation avec une association de type n : m 15
20 Identifiant par concaténation 15
21 Représentation d'un identifiant relatif 16
22 Représentât ion des sous-entités 16
23 Représentation des sou^-associa?ions 17
Plus d'informations sur
Merise
