|
|
|
|
|
Conception d'une base de données (Merise) Ahmed Tebakh 05 décembre 2006 Résumé 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
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 uitres 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 • 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 sym bolise 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 cœur). 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'iden tifiant de l'entité constitue alors la clé primaire de la table. Par exemple, l'entité articles de la figure 9 devient la table : articles(n umé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 detix 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'assoc iation 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 tech nique : 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 pers onnel (unique), #numéro appartement (uniq ue), 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 majo rité 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, Règle 1 les tables dont la clé primaire est non composée (et non clé étrangère) deviennent des 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 iation.
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émentaii 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( ftnumé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 u ssi é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(n um é ro produit , nom produit, ...) produits standards( #(l)num é ro produi t, 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 cor jr.a r.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 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 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.
Références [1] Gabay, J. Apprendre et pratiquer Merise. Masson, 1989. Ce livre très synthétique permet de s'exercer sur la méthode. [2] Matheron. J.-P. Comprendre Merise. Eyrolles, 1994. Cet ouvrage très accessible permet vraiment de comprendre la méthode. (3] Nanti. D.. Espinasse. B.. Cohen. B. et Heckenroth : H. ingénierie des systèmes d'information ara Merise. Sybex. 1992. Cet ouvrage complet détaille la méthode dans son ensemble. [4] Panet. G.. LETOUCHE. R. et TARDIEU, H. Merise/2 : Modèles et techniques Merise avancés. Édition d "organisât ion. 1994. Ce livre décrit la version 2 de la méthode. [5] Tardiet. H.. ROCHFELD, A. et COLETTI. R. La méthode M< rise. Principes et outils. Édition d'or ganisation. 19 v // s'o(jit'là du livre de référence par les auteurs de la méthode. |
bravenet.com
