• Save
Conception bd 2
Upcoming SlideShare
Loading in...5
×
 

Conception bd 2

on

  • 2,022 views

 

Statistics

Views

Total Views
2,022
Views on SlideShare
2,022
Embed Views
0

Actions

Likes
0
Downloads
38
Comments
1

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • TELECHARGER :
    http://www.tifawt.com/office/conception-dune-base-de-donnees/
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Conception bd 2 Conception bd 2 Document Transcript

  • www.tifawt.com www.tifawt.com Conception d’une base de donn´es e Cyril Gruau ∗ 17 octobre 2005 (corrig´ le 13 juillet 2006) e R´sum´ e e Ce support de cours regroupe quelques notions concernant le mod´lisation conceptuelle de syst`me e e d’information par sch´ma entit´s-associations (via l’´tude des d´pendances fonctionnelles), la trae e e e duction en sch´ma relationnel et la d´marche inverse (r´tro-conception). Il pr´sente ´galement les e e e e e extensions majeures du mod`le conceptuel de donn´es. e e Mots-clef : Merise, mod`le conceptuel, entit´, association, d´pendance fonctionnelle, e e e graphe de couverture minimale, sch´ma relationnel, traduction, r´tro-conception, e e agr´gation, identifiant relatif, h´ritage e e Compl´ments apport´s ` l’´dition de novembre 2003 : e e a e – – – – – – une r´-´criture compl`te des r`gles de normalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 ee e e un nouveau paragraphe sur les d´pendances fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 e une r´-´criture compl`te de la section sur les agr´gations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 ee e e idem pour les identifiants relatifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 et l’h´ritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 e auxquels s’ajoutent de nouveaux exemples et donc de nombreuses figures illustratives . . . . . . . . . 42 Remerciements L’auteur tient ` exprimer toute sa gratitude envers Fr´d´ric Brouard pour son travail de correction a e e sur ce document, ses judicieux conseils et son soutien en toutes circonstances. ∗ Cyril.Gruau@ensmp.fr www.tifawt.com 1
  • www.tifawt.com ` TABLE DES MATIERES 2 Table des mati`res e Introduction 3 1 Mod`le conceptuel de donn´es (MCD) e e 1.1 Sch´ma entit´s-associations . . . . . . . . . . . . . . . . . . . . . e e 1.1.1 Entit´s et associations . . . . . . . . . . . . . . . . . . . . e 1.1.2 Attributs et identifiants . . . . . . . . . . . . . . . . . . . 1.1.3 Cardinalit´s . . . . . . . . . . . . . . . . . . . . . . . . . . e 1.1.4 Associations plurielles . . . . . . . . . . . . . . . . . . . . 1.1.5 Association r´flexive . . . . . . . . . . . . . . . . . . . . . e 1.1.6 Associations non binaires . . . . . . . . . . . . . . . . . . 1.2 R`gles de normalisation . . . . . . . . . . . . . . . . . . . . . . . e 1.2.1 Les bonnes mani`res dans un sch´ma entit´s-associations e e e 1.2.2 Les formes normales . . . . . . . . . . . . . . . . . . . . . 1.3 D´pendances fonctionnelles . . . . . . . . . . . . . . . . . . . . . e 1.3.1 D´finitions et propri´t´s . . . . . . . . . . . . . . . . . . . e ee 1.3.2 Graphe de couverture minimale . . . . . . . . . . . . . . . 1.3.3 Traduction vers un sch´ma entit´s-associations . . . . . . e e 1.3.4 Gestion des dates et du caract`re historique . . . . . . . . e 1.3.5 D´pendances plurielles et r´flexives . . . . . . . . . . . . . e e 1.3.6 Associations sans attributs . . . . . . . . . . . . . . . . . 1.4 M´thodologie de base . . . . . . . . . . . . . . . . . . . . . . . . e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4 4 5 6 7 7 8 10 10 14 16 16 17 17 18 20 20 21 e e 2 Mod`le logique de donn´es (MLD) 2.1 Syst`mes logiques . . . . . . . . . . . . . e 2.2 Mod`le logique relationnel . . . . . . . . e 2.2.1 Tables, lignes et colonnes . . . . e e e e 2.2.2 Cl´s primaires et cl´s ´trang`res 2.2.3 Sch´ma relationnel . . . . . . . . e 2.3 Traduction d’un MCD en un MLDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 22 22 22 22 23 24 3 Mod`le physique de donn´es (MPD) e e 3.1 Distinction entre MLD et MPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Optimisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 27 27 4 R´tro-conception e 4.1 Traduction inverse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Cas particuliers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 28 29 5 Compl´ments e 5.1 Agr´gation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 5.1.1 Association de type 1 : n . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2 Association de type n : m . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.3 Tables de codification ou tables de r´f´rence . . . . . . . . . . . . . . . ee 5.2 Identifiant relatif ou lien identifiant . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 R´solution d’un probl`me sur le sch´ma relationnel . . . . . . . . . . . e e e 5.2.2 Mod`le conceptuel correspondant . . . . . . . . . . . . . . . . . . . . . e 5.2.3 Discussion autour de la num´rotation des exemplaires . . . . . . . . . e 5.3 H´ritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 5.3.1 Sous-entit´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 5.3.2 Utilisation de l’h´ritage pour s´parer les informations compl´mentaires e e e 5.3.3 Sp´cialisation des associations . . . . . . . . . . . . . . . . . . . . . . . e 30 30 30 32 34 35 35 36 37 38 38 39 40 www.tifawt.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  • www.tifawt.com INTRODUCTION 3 Conclusion 41 R´f´rences ee 41 Table des figures 42 Index 43 Introduction Quand nous construisons directement les tables d’une base de donn´es dans un logiciel de gestion des e bases de donn´es (Oracle, SQL Server, DB2, Access, MySQL, PostGre, ...), nous sommes expos´s ` deux e e a types de probl`me : e – nous ne savons pas toujours dans quelle table placer certaines colonnes (par exemple, l’adresse de livraison se met dans la table des clients ou dans la table des commandes?) ; – nous avons du mal ` pr´voir les tables de jonction interm´diaires (par exemple, la table des ina e e terpr´tations qui est indispensable entre les tables des films et la table des acteurs). e Il est donc n´cessaire de recourir ` une ´tape pr´liminaire de conception. e a e e ´ Les techniques pr´sent´es ici font partie de la m´thodologie Merise (M´thode d’Etude et de R´alisation e e e e e Informatique pour les Syst`mes d’Entreprise) ´labor´e en France en 1978 [Tardieu et al.], qui permet noe e e tamment de concevoir un syst`me d’information d’une fa¸on standardis´e et m´thodique. e c e e Le but de ce support de cours est d’introduire le sch´ma entit´s-associations (section 1), le sch´ma e e e relationnel (sections 2 et 3) et d’expliquer la traduction entre les deux (sections 2.3 et 4). La construction du sch´ma entit´s-associations peut se faire en ´tudiant les d´pendances fonctionnelles (section 1.3) et e e e e en tenant compte d’un certain nombre d’extensions conceptuelles incontournables (section 5). Ne sont malheureusement pas abord´s ici : les contraintes, les traitements, le langage relationnel et la e gestion de projet. Pour toutes ces notions importantes, car li´es ` la conception de syst`mes d’information, e a e le lecteur est dirig´ vers [Akoka et Comyn-Wattiau, Matheron, Nanci et al.]. La mod´lisation objet ne e e fait pas non plus partie des outils expos´s dans ce document. e www.tifawt.com
  • www.tifawt.com ` ´ MODELE CONCEPTUEL DE DONNEES (MCD) 1 1 4 Mod`le conceptuel de donn´es (MCD) e e Avant de r´fl´chir au sch´ma relationnel d’une application, il est bon de mod´liser la probl´matique e e e e e a ` traiter d’un point de vue conceptuel et ind´pendamment du logiciel utilis´. e e 1.1 Sch´ma entit´s-associations e e La mod´lisation conceptuelle que nous proposons dans ce document pour un univers dont on veut stoe cker les donn´es, conduit ` l’´laboration d’un type de sch´ma tr`s r´pandu, le sch´ma entit´s-associations. e a e e e e e e 1.1.1 Entit´s et associations e Une entit´ est une population d’individus homog`nes. Par exemple, les produits ou les articles vendus e e par une entreprise peuvent ˆtre regroup´s dans une mˆme entit´ articles (figure 1), car d’un article e e e e a ` l’autre, les informations ne changent pas de nature (` chaque fois, il s’agit de la d´signation, du prix a e unitaire, etc.). clients - articles fournisseurs numéro client nom client prénom adresse client ... - numéro article - désignation - prix unitaire de vente - ... - n° fournisseur - nom contact - n° téléphone contact - ... Fig. 1 – Entit´s e Par contre, les articles et les clients ne peuvent pas ˆtre regroup´s : leurs informations ne sont pas e e homog`nes (un article ne poss`de pas d’adresse et un client ne poss`de pas de prix unitaire). Il faut donc e e e leur r´server deux entit´s distinctes : l’entit´ articles et l’entit´ clients. e e e e Une association est une liaison qui a une signification pr´cise entre plusieurs entit´s. Dans notre e e exemple, l’association commander est une liaison ´vidente entre les entit´s articles et clients, tandis e e que l’association livrer ´tablit le lien s´mantique entre les entit´s articles et fournisseurs. e e e clients - numéro client nom client prénom adresse client ... commander - quantité commandée - date de commande articles - numéro article - désignation - prix unitaire de vente - ... livrer - quantité livrée - date livraison - nom livreur fournisseurs - n° fournisseur - nom contact - n° téléphone contact - ... Fig. 2 – Associations Remarquons que dans ce sch´ma, les entit´s clients et fournisseurs ne sont pas li´es directement, e e e mais indirectement, via l’entit´ articles, ce qui est assez naturel. e www.tifawt.com
  • www.tifawt.com ` ´ MODELE CONCEPTUEL DE DONNEES (MCD) 1 1.1.2 5 Attributs et identifiants Un attribut est une propri´t´ d’une entit´ ou d’une association. ee e Toujours dans notre exemple (figure 3), le prix unitaire est un attribut de l’entit´ articles, le nom e de famille est un attribut de l’entit´ clients, la quantit´ command´e est un attribut de l’association e e e commander et la date de livraison est un attribut de l’association livrer. clients - numéro client nom client prénom adresse client ... commander - quantité commandée - date de commande articles - numéro article - désignation - prix unitaire de vente - ... livrer - quantité livrée - date livraison - nom livreur fournisseurs - n° fournisseur - nom contact - n° téléphone contact - ... Fig. 3 – Attributs Une entit´ et ses attributs ne doivent traiter que d’un seul sujet afin d’assurer une certaine coh´rence e e au mod`le. Dans notre exemple, il est donc pr´f´rable de ne pas mettre les informations relatives aux e ee fournisseurs dans l’entit´ des articles mais plutˆt dans une entit´ fournisseurs s´par´es (et li´e ` l’entit´ e o e e e e a e articles via l’association livrer). Ensuite, chaque individu d’une entit´ doit ˆtre identifiable de mani`re unique. C’est pourquoi toutes e e e les entit´s doivent poss´der un attribut sans doublon (c’est-`-dire ne prenant pas deux fois la mˆme e e a e valeur). Il s’agit de l’identifiant que l’on souligne sur le sch´ma, par convention. Le num´ro de client e e constitue un identifiant classique pour l’entit´ clients (figure 4). e clients - numéro client nom client prénom adresse client ... commander - quantité commandée - date de commande articles - numéro article - désignation - prix unitaire de vente - ... livrer - quantité livrée - date livraison - nom livreur Fig. 4 – Identifiants Remarques : e e – une entit´ poss`de au moins un attribut (son identifiant) ; – au contraire, une association peut ˆtre d´pourvue d’attribut. e e www.tifawt.com fournisseurs - n° fournisseur - nom contact - n° téléphone contact - ...
  • www.tifawt.com ` ´ MODELE CONCEPTUEL DE DONNEES (MCD) 1 1.1.3 6 Cardinalit´s e La cardinalit´ d’un lien entre une entit´ et une association pr´cise le minimum et le maximum de fois e e e qu’un individu de l’entit´ peut ˆtre concern´ par l’association. e e e Exemple : un client a au moins command´ un article et peut commander n articles (n ´tant ind´termin´), e e e e tandis qu’un article peut avoir ´t´ command´ entre 0 et n fois (mˆme si ce n’est pas le mˆme n que ee e e e pr´c´demment). On obtient alors le sch´ma entit´s-associations complet 1 (figure 5). e e e e clients - numéro client nom client prénom adresse client ... commander - quantité 1,n commandée - date de commande articles - numéro article 0,n - désignation - prix unitaire de vente - ... livrer 1,n - quantité livrée - date livraison - nom livreur fournisseurs - n° fournisseur 1,n - nom contact - n° téléphone contact - ... Fig. 5 – Cardinalit´s e Une cardinalit´ minimale de 1 doit se justifier par le fait que les individus de l’entit´ en question ont e e besoin de l’association pour exister (un client n’existe pas avant d’avoir command´ quoique ce soit, donc e la cardinalit´ minimale de l’entit´ clients dans l’association commander est 1). Dans tous les autres cas, e e la cardinalit´ minimale vaut 0 (c’est le cas pour une liste pr´-´tablie d’articles par exemple). e ee Ceci dit, la discussion autour d’une cardinalit´ minimale 0 ou 1 n’est vraiment int´ressante que lorsque e e la cardinalit´ maximale est 1. Nous verrons en effet lors de la traduction vers un sch´ma relationnel (sece e tion 2.3), que lorsque la cardinalit´ maximale est n, nous ne pouvons pas faire la diff´rence entre une e e cardinalit´ minimale de 0 et une cardinalit´ minimale de 1. e e Notons que sur notre exemple, un article peut ˆtre command´ par plusieurs clients. Cela provient du e e fait que tous les crayons rouges ne sont pas num´rot´s individuellement, mais portent un num´ro d’article e e e collectif. En toute rigueur, notre entit´ articles aurait du s’appeler types d’article. Ainsi, un crayon e rouge peut ˆtre command´ par plusieurs clients, ce n’est simplement pas le mˆme crayon ` chaque fois. e e e a Il s’agit d’un choix de mod´lisation, le lecteur peut tr`s l´gitimement faire le choix inverse qui consiste ` e e e a num´roter individuellement chaque crayon rouge. e La seule difficult´ pour ´tablir correctement les cardinalit´s est de se poser les questions dans le bon e e e sens. Autour de l’association commander, par exemple : – cˆt´ clients, la question est ( un client peut commander combien d’articles ? ) et la r´ponse est oe ( ) e (( entre 1 et plusieurs ) ; ) – cˆt´ articles, la question est ( un article peut ˆtre command´ par combien de client ? ) et cette oe ( e e ) fois-ci, la r´ponse est ( entre 0 et plusieurs ) e ( ). 1. Le lecteur avis´ aura not´ que le sch´ma de la figure 5 comporte des erreurs de conception. Ces erreurs seront corrig´es e e e e dans la section 1.2 d´di´e ` la normalisation des sch´mas entit´s-associations. e e a e e www.tifawt.com
  • 1 www.tifawt.com ` ´ MODELE CONCEPTUEL DE DONNEES (MCD) 1.1.4 7 Associations plurielles Deux mˆmes entit´s peuvent ˆtre plusieurs fois en association (c’est le cas sur la figure 6). e e e posséder - date d’acquisition - prix achat 0,n personnes - n° personnel nom prénom ... 0,1 0,n résider principalement - date d’entrée - montant du loyer 1,1 logements 0,n - n° logement - adresse - ... 0,n résider secondairement - date d’entrée - montant du loyer Fig. 6 – Associations plurielles Dans cet exemple issu d’une agence immobili`re, une personne peut ˆtre propri´taire, r´sider princie e e e palement ou r´sider secondairement dans un logement g´r´ par l’agence. Les logements qui ne sont pas e ee g´r´s par l’agence ne figurent pas dans l’entit´s des logements, ce qui explique certaines cardinalit´s 0 du ee e e sch´ma. Nous supposons ´galement qu’un logement n’est d´tenu que par une seule personne et que ce e e e propri´taire figure obligatoirement dans l’entit´ des personnes. e e 1.1.5 Association r´flexive e Il est permis ` une association d’ˆtre branch´e plusieurs fois ` la mˆme entit´, comme par exemple a e e a e e l’association binaire r´flexive de la figure 7. e diriger - date début 0,n 0,1 employés - n° employé nom fonction adresse ... Fig. 7 – Association r´flexive e Dans cet exemple, tout employ´ est dirig´ par un autre employ´ (sauf le directeur g´n´ral) et un e e e e e employ´ peut diriger plusieurs autres employ´s, ce qui explique les cardinalit´s sur le sch´ma. e e e e www.tifawt.com
  • 1 ` ´ MODELE CONCEPTUEL DE DONNEES (MCD) 1.1.6 www.tifawt.com 8 Associations non binaires Lorsqu’autour d’une entit´, toutes les associations ont pour cardinalit´s maximales 1 au centre et n e e a ` l’ext´rieur, cette entit´ est candidate pour ˆtre remplac´e par une association branch´e ` toutes les e e e e e a entit´s voisines avec des cardinalit´s identiques 0,n. e e La deuxi`me condition qu’il faut imp´rativement satisfaire est la r`gle de normalisation des attributs e e e des associations (section suivante). Cette r`gle conduit parfois ` l’apparition d’associations qui ´tablissent e a e un lien s´mantique entre 3 entit´s ou plus. e e Sur l’exemple de la figure 8 issu d’un cin´ma, l’entit´ projections est uniquement entour´e d’assoe e e ciations dont les cardinalit´s maximales sont 1 cˆt´ projections et n de l’autre cˆt´. De plus, la donn´e e oe oe e 2 . On peut donc la remd’un cr´neau, d’un film et d’une salle suffit ` d´terminer une projection unique e a e placer par une association projeter branch´e aux trois entit´s salles, cr´neaux horaires et films. e e e On parle alors d’association ternaire. Fig. 8 – Entit´ rempla¸able par une association ternaire e c 2. sans la date dans l’entit´ cr´neaux horaires, la donn´e d’un cr´neau, d’un film et d’une salle aurait d´termin´ plusieurs e e e e e e projections et l’association ternaire n’aurait pas pu se faire www.tifawt.com
  • 1 www.tifawt.com ` ´ MODELE CONCEPTUEL DE DONNEES (MCD) 9 La difficult´ de concevoir une association ternaire (ou plus) directement est d’´tablir les bonnes care e dinalit´s. Il est donc conseill´ d’en passer par un sch´ma entit´s-associations dans lequel on ne trouve e e e e que des associations binaires, puis de rep´rer les entit´s rempla¸ables par des associations, comme sur la e e c figure 8 ` gauche. a Cette r`gle de conduite permet d’´viter d’introduire une association ternaire abusive, par exemple e e entre les avions, les pilotes et les vols (figure 9), car le concepteur peut s’apercevoir que l’une des cardinalit´s maximales ne convient pas. e avions 0,n - utiliser 1,1 vols - numéro vol - heure de départ prévue - heure d’arrivée prévue numéro avion date mise en service modèle propriétaire départs 0,n correspondre - numéro départ 1,1 - date - heure de départ effective 1,n assurer pilotes 0,n - numéro pilote - nom - grade Fig. 9 – Contre-exemple : l’entit´ d´parts n’est pas rempla¸able par une association ternaire e e c Par ailleurs, une association peut ˆtre branch´e ` plus de trois entit´s, comme sur la figure 10. L`e e a e a encore, le conseil pour ˆtre sˆr de la l´gitimit´ de cette association 4-aire, est de v´rifier les cardinalit´s e u e e e e sur un sch´ma interm´diaire faisant apparaˆ ` la place, une entit´ occupations et quatre associations e e ıtre a e binaires. jours dans la semaine - n° jour - jour 0,n semaines dans l’année - n° semaine - date de début occuper 0,n - motif 0,n 0,n créneaux horaires dans la journée - n° créneau - heure de début salles - n° salle - capacité Fig. 10 – Exemple d’entit´ quaternaire ou 4-aire e www.tifawt.com
  • 1 www.tifawt.com ` ´ MODELE CONCEPTUEL DE DONNEES (MCD) 1.2 10 R`gles de normalisation e Un bon sch´ma entit´s-associations doit r´pondre ` 9 r`gles de normalisation, que le concepteur doit e e e a e connaˆ par cœur. ıtre 1.2.1 Les bonnes mani`res dans un sch´ma entit´s-associations e e e Normalisation des entit´s (importante) : toutes les entit´s qui sont rempla¸ables par une associae e c tion doivent ˆtre remplac´es (comme sur la figure 8). e e Normalisation des noms : le nom d’une entit´, d’une association ou d’un attribut doit ˆtre unique. e e Conseils : – pour les entit´s, utiliser un nom commun au pluriel (par exemple : clients) ; e – pour les associations, utiliser un verbe ` l’infinitif (par exemple : effectuer, concerner) ´ventuellement a e a ` la forme passive (ˆtre command´) et accompagn´ d’un adverbe (avoir lieu dans, pendant, `) ; e e e a – pour les attributs, utiliser un nom commun singulier (par exemple : nom, num´ro, libell´, descripe e tion) ´ventuellement accompagn´ du nom de l’entit´ ou de l’association dans laquelle il se trouve e e e (par exemple : nom de client, num´ro d’article). e Remarque : lorsqu’il reste plusieurs fois le mˆme nom, c’est parfois symptomatique d’une mod´lisation e e qui n’est pas termin´e (figure 11(a)) ou le signe d’une redondance (figure 11(b)). e étudiants - n° étudiant nom prénom adresse enseignants - personnes n° enseignant nom prénom adresse - fusion n° personnel nom prénom adresse (a) Deux entit´s homog`nes peuvent ˆtre fusionn´es e e e e clients - numéro client - nom client - adresse de livraison commandes passer 1,n 1,1 - n° commande - date commande - adresse de livraison redondance, donc risque d’incohérence (b) Si deux attributs contiennent les mˆmes informations, alors e la redondance induit non seulement un gaspillage d’espace mais ´galement un grand risque d’incoh´rence : ici, les adresses risquent e e de ne pas ˆtre les mˆmes et dans ces conditions, o` faut-il livrer e e u ? Fig. 11 – Contre-exemples de la normalisation des noms www.tifawt.com
  • 1 www.tifawt.com ` ´ MODELE CONCEPTUEL DE DONNEES (MCD) 11 Normalisation des identifiants : chaque entit´ doit poss´der un identifiant. e e Conseils : – ´viter les identifiants compos´s de plusieurs attributs (comme par exemple un identifiant form´ par e e e les attributs nom et pr´nom), car d’une part c’est mauvais pour les performances et d’autres part, e l’unicit´ suppos´e par une telle d´marche finit tˆt ou tard par ˆtre d´mentie ; e e e o e e – pr´f´rer un identifiant court pour rendre la recherche la plus rapide possible (´viter notamment les ee e chaˆ ınes de caract`res comme un num´ro de plaque d’immatriculation, un num´ro de s´curit´ sociale e e e e e 3) ; ou un code postal – ´viter ´galement les identifiants susceptibles de changer au cours du temps (comme les plaques e e d’immatriculation ou les num´ros de s´curit´ sociale provisoires). e e e Conclusion : l’identifiant sur un sch´ma entit´s-associations (et donc la future cl´ primaire dans le sch´ma e e e e relationnel) doit ˆtre un entier, de pr´f´rence incr´ment´ automatiquement 4 . e ee e e Normalisation des attributs (importante) : remplacer les attributs en plusieurs exemplaires en une association suppl´mentaire de cardinalit´s maximales n et ne pas ajouter d’attribut calculable ` partir e e a d’autres attributs. En effet, d’une part, les attributs en plusieurs exemplaires posent des probl`mes d’´volutivit´ du e e e mod`le (sur la figure 12(a) ` gauche, comment faire si un employ´ a deux adresses secondaires ?) et e a e occuper employés employés - n° employé nom adresse principale adresse secondaire n° téléphone domicile n° téléphone portable - n° employé - nom 1,n normalisation posséder 1,n - type adresses 1,n - n° adresse - adresse numéros de tél. 1,n - n° de n° de tél. - n° de téléphone - fixe ou portable (a) Attributs en plusieurs exemplaires remplac´s par une association suppl´mentaire e e commandes - n° commande - date commande - montant total figurer 1,n - quantité articles - numéro article 0,n - désignation - prix unitaire de vente calculable à partir de (b) Attribut calculable qu’il faut retirer du sch´ma e Fig. 12 – Contre-exemples de la normalisation des attributs d’autre part, les attributs calculables induisent un risque d’incoh´rence entre les valeurs des attributs de e 3. Un num´ro de s´curit´ sociale, un code postal ou un num´ro de t´l´phone sont bien des chaˆ e e e e ee ınes de caract`res, mˆme e e si elles ne comportent que des chiffres, tout simplement parce que ces num´ros peuvent commencer par un 0, ce qui, en e informatique, n’est pas possible avec un entier. 4. Le seul inconv´nient de cette num´rotation arbitraire est qu’il devient possible ` une table de poss´der deux fois la e e a e mˆme ligne (avec deux num´ros diff´rents). Le conseil reste pourtant largement avantageux e e e www.tifawt.com
  • www.tifawt.com ` ´ MODELE CONCEPTUEL DE DONNEES (MCD) 1 12 base et celles des attributs calcul´s, comme sur la figure 12(b). e D’autres d’attributs calculables classiques sont ` ´viter, comme l’ˆge (qui est calculable ` partir de ae a a la date de naissance) ou encore le d´partement (calculable ` partir d’une sous-chaˆ du code postal). e a ıne Normalisation des attributs des associations (importante) : les attributs d’une association doivent d´pendre directement des identifiants de toutes les entit´s en association. e e Par exemple, sur la figure 5 la quantit´ command´e d´pend ` la fois du num´ro de client et du e e e a e num´ro d’article, par contre la date de commande non. Il faut donc faire une entit´ commandes ` part, e e a idem pour les livraisons (figure 13). clients - - quantité commandée - numéro article 0,n - désignation - prix unitaire de vente fournisseurs concerner (2) 1,n 1,n commandes 1,! - n° fournisseur - nom contact - n° téléphone contact - quantité livrée 1,n 1,n passer articles concerner (1) numéro client nom client prénom adresse client livraisons - n° commande - date commande - n° livraison - date de livraison 1,n livrer 1,! - nom du livreur Fig. 13 – Normalisation des attributs des associations L’inconv´nient de cette r`gle de normalisation est qu’elle est difficile ` appliquer pour les associations e e a qui ne poss`dent pas d’attribut. Pour v´rifier malgr´ tout qu’une association sans attribut est bien nore e e malis´e, on peut donner temporairement ` cette association un attribut imaginaire (mais pertinent) qui e a permet de v´rifier la r`gle. e e Par exemple, entre les entit´s livres et auteurs de la figure 16, l’association ´crire ne poss`de pas e e e d’attribut. Imaginons que nous ajoutions un attribut pourcentage qui contient le pourcentage du livre ´crit par chaque auteur (du mˆme livre). Comme cet attribut pourcentage d´pend ` la fois du num´ro e e e a e de livre et du num´ro d’auteur, l’association ´crire est bien normalis´e. e e e Autre cons´quence de la normalisation des attributs des associations : une entit´ avec une cardinalit´ e e e de 1,1 ou 0,1 aspire les attributs de l’association (figure 14). fournisseurs - n° fournisseur - nom contact - n° téléphone contact livraisons livrer 1,n - nom du livreur 1,1 - n° livraison - date de livraison - cet attribut passe ici Fig. 14 – Cardinalit´ 1,1 et attributs d’une association e www.tifawt.com
  • 1 www.tifawt.com ` ´ MODELE CONCEPTUEL DE DONNEES (MCD) 13 Normalisation des associations (importante) : il faut ´liminer les associations fantˆmes (figure 15(a)), e o redondantes (figure 15(b)) ou en plusieurs exemplaires (figure 15(c)). fournisseurs 1,1 - n° fournisseur - nom fournisseur - adresse fournisseurs - travailler chez fusion contacts - n° contact - nom du contact - n° téléphone du contact 1,1 n° fournisseur nom fournisseur adresse nom du contact n° téléphone du contact (a) les cardinalit´s sont toutes 1,1 donc c’est une association fantˆme e o règlements payer 0,n clients - numéro client - nom client 0,n 1,1 - n° règlement - date règlement - montant factures recevoir 1,1 correspondre 0,n 1,1 - n° facture - date facture - montant total (b) si un client ne peut pas r´gler la facture d’un autre client, alors l’association e payer est inutile et doit ˆtre supprim´e (dans le cas contraire, l’association payer e e doit ˆtre maintenue) e joueurs de tennis 0,n joueur 1 n° joueur nom genre classement 0,n joueur 2 1,1 joueurs de tennis 1,1 - 0,n 0,n 0,n co-équipier 1 0,1 n° joueur nom genre classement co-équipier 2 jouer normalisation 0,1 matchs de tennis - n° match - date 2,4 ou plutôt 1,n matchs de tennis - n° match - date (c) une association suffit pour remplacer les 4 associations participer en tant que ... Fig. 15 – Contre-exemples de la normalisation des associations www.tifawt.com
  • www.tifawt.com ` ´ MODELE CONCEPTUEL DE DONNEES (MCD) 1 14 En ce qui concerne les associations redondantes, cela signifie que s’il existe deux chemins pour se rendre d’une entit´ ` une autre, alors ils doivent avoir deux significations ou deux dur´es de vie diff´rentes. Siea e e non, il faut supprimer le chemin le plus court, car il est d´ductible ` partir de l’autre chemin. Dans notre e a exemple de la figure 15(b), si on supprime l’association payer, on peut retrouver le client qui a pay´ le e r`glement en passant par la facture qui correspond. e Remarque : une autre solution pour le probl`me de la figure 15(b) consiste ` retirer l’entit´ r`glements e a e e et d’ajouter une association r´gler avec les mˆmes attributs (sauf l’identifiant) entre les entit´s clients e e e et factures. Normalisation des cardinalit´s : une cardinalit´ minimale est toujours 0 ou 1 (et pas 2, 3 ou n) e e et une cardinalit´ maximale est toujours 1 ou n (et pas 2, 3, ...). e Cela signifie que si une cardinalit´ maximale est connue et vaut 2, 3 ou plus (comme sur la figure 15(c) ` e a droite, ou pour un nombre limit´ d’emprunts dans une biblioth`que), alors nous consid´rons quand mˆme e e e e qu’elle est ind´termin´e et vaut n. Cela se justifie par le fait que mˆme si nous connaissons n au moment e e e de la conception, il se peut que cette valeur ´volue au cours du temps. Il vaut donc mieux consid´rer n e e comme une inconnue d`s le d´part. e e Cela signifie ´galement qu’on ne mod´lise pas les cardinalit´s minimales qui valent plus de 1 car ce e e e genre de valeur est aussi amen´e ` ´voluer. Par ailleurs, avec une cardinalit´ maximale de 0, l’association e ae e n’aurait aucune signification. Dans un SGBD relationnel, nous pourrions assurer les cardinalit´s valant 2, 3 ou plus, via l’utilisation e de d´clencheurs. Mais cette notion n’est pas abord´e dans ce document qui se contente, au contraire, de e e d´crire ce qu’il est possible de faire sans utiliser de d´clencheur. e e 1.2.2 Les formes normales ` A ces 6 r`gles de normalisation, il convient d’ajouter les 3 premi`res formes normales traditionnele e lement ´nonc´es pour les sch´mas relationnels, mais qui trouvent tout aussi bien leur place en ce qui e e e concerne les sch´mas entit´s-associations. e e Premi`re forme normale : ` un instant donn´ dans une entit´, pour un individu, un attribut ne e a e e peut prendre qu’une valeur et non pas, un ensemble ou une liste de valeurs. Si un attribut prend plusieurs valeurs, alors ces valeurs doivent faire l’objet d’une entit´ suppl´mentaire, e e en association avec la premi`re (figure 16). e livres - numéro livre titre auteurs éditeur nombre de pages année livres 1 ère forme normale - numéro livre titre éditeur nombre de pages année écrire 1,n auteurs 1,n - numéro auteur - nom Fig. 16 – Application de la premi`re forme normale : il peut y avoir plusieurs auteurs pour un livre donn´ e e www.tifawt.com
  • 1 www.tifawt.com ` ´ MODELE CONCEPTUEL DE DONNEES (MCD) 15 Deuxi`me forme normale : l’identifiant peut ˆtre compos´ de plusieurs attributs mais les autres e e e attributs de l’entit´ doivent d´pendre de l’identifiant en entier (et non pas une partie de cet identifiant). e e Cette deuxi`me forme normales peut ˆtre oubli´e si on suit le conseil de n’utiliser que des identifiants e e e non compos´s et de type entier. En v´rit´, elle a ´t´ vid´e de sa substance par la r`gle de normalisation e e e ee e e des attributs des associations (page 12). Consid´rons malgr´ tout le contre-exemple suivant : dans une entit´ clients dont l’identifiant est e e e compos´ des attributs nom et pr´nom, la date de fˆte d’un client ne d´pend pas de son identifiant en e e e e entier mais seulement de pr´nom. Elle ne doit pas figurer dans l’entit´ clients, il faut donc faire une e e entit´ calendrier ` part, en association avec l’entit´ clients. e a e Troisi`me forme normale de Boyce-Codd (importante) : tous les attributs d’une entit´ doivent e e d´pendre directement de son identifiant et d’aucun autre attribut. e Si ce n’est pas le cas, il faut placer l’attribut pathologique dans une entit´ s´par´e, mais en association e e e avec la premi`re. e num´ro avion e 1 2 3 constructeur Airbus Boeing Airbus mod`le e A380 B747 A380 capacit´ e 180 314 180 propri´taire e Air France British Airways KLM Tab. 1 – Il y a redondance (et donc risque d’incoh´rence) dans les colonnes constructeur et capacit´ e e Par exemple, l’entit´ avions (figure 17 ` gauche) dont les valeurs sont donn´es dans le tableau 1, e a e n’est pas en troisi`me forme normale de Boyce-Codd, car la capacit´ et le constructeur d’un avion e e ne d´pendent pas du num´ro d’avion mais de son mod`le. La solution normalis´e est donn´e figure 17 ` e e e e e a droite. avions - modèles d’avion numéro avion constructeur modèle capacité propriétaire avions 3ème forme normale - numéro avion - propriétaire être du 1,n 1,n - numéro modèle modèle constructeur capacité Fig. 17 – Application de la troisi`me forme normale de Boyce-Codd e www.tifawt.com
  • 1 www.tifawt.com ` ´ MODELE CONCEPTUEL DE DONNEES (MCD) 1.3 16 D´pendances fonctionnelles e Pour ´tablir efficacement un mod`le entit´s-associations bien normalis´, on peut ´tudier au pr´alable e e e e e e les d´pendances fonctionnelles entre les attributs puis, les organiser en graphe de couverture minimale. e Cette technique est traditionnellement employ´e pour normaliser des sch´mas relationnels, mais elle e e s’applique tr`s bien en amont, au niveau des mod`les conceptuels. e e 1.3.1 D´finitions et propri´t´s e e e Un attribut Y d´pend fonctionnellement d’un attribut X si et seulement si une valeur de X induit e une unique valeur de Y . On note une d´pendance fonctionnelle par une fl`che simple : X → Y . e e Par exemple, si X est le num´ro de client et Y le nom de client, alors on a bien X → Y . Par contre, e on a pas Y → X, car plusieurs clients de num´ros diff´rents peuvent porter le mˆme nom. e e e Transitivit´ : si X → Y et Y → Z alors X → Z. e Par exemple, on a num´ro de commande → num´ro de client → nom de client, donc on a aussi e e num´ro de commande → nom de client. Mais la d´pendance fonctionnelle num´ro de commande → nom e e e de client est dite transitive, car il faut passer par le num´ro de client pour l’obtenir. e Au contraire, la d´pendance fonctionnelle num´ro de client → nom de client est directe . Seules e e les d´pendances fonctionnelles directes nous int´ressent. D’autres exemples sont donn´es dans le tableau 2. e e e d´pendance fonctionnelle e num´ro de livraison → date de livraison e num´ro de livraison → num´ro du fournisseur e e num´ro du fournisseur → nom du fournisseur e num´ro de livraison → nom du fournisseur e directe ? oui oui oui non Tab. 2 – Exemples de d´pendances fonctionnelles e Un attribut Y peut avoir une d´pendance fonctionnelle qui repose sur la conjonction de plusieurs attrie buts, auquel cas la d´pendance est dite non ´l´mentaire . Les d´pendances fonctionnelles non ´l´mentaires e ee e ee sont not´es par une fl`che unique mais comportant plusieurs points d’entr´e (regroup´s autour d’un e e e e cercle). Par exemple, la quantit´ command´e (d’un article dans une commande) d´pend de deux attributs : e e e le num´ro de commande et le num´ro d’article (figure 18). Notons que cette d´pendance num´ro de e e e e commande + num´ro d’article → quantit´ est ` la fois non ´l´mentaire et directe. e e a ee numéro de commande quantité commandée numéro d’article Fig. 18 – D´pendance fonctionnelle non ´l´mentaire, mais directe e ee www.tifawt.com
  • 1 www.tifawt.com ` ´ MODELE CONCEPTUEL DE DONNEES (MCD) 1.3.2 17 Graphe de couverture minimale En repr´sentant tous les attributs et toutes les d´pendances fonctionnelles directes entre eux, nous e e obtenons un r´seau appel´ graphe de couverture minimale. Dans notre exemple sur les clients, les come e mandes et les articles, ce graphe est donn´ sur la figure 19. e numéro de commande numéro de client numéro d’article date de commande désignation quantité commandée nom du client adresse du client Fig. 19 – Graphe de couverture minimale La technique de traduction en un sch´ma entit´s-associations qui suit, suppose qu’aucun attribut n’a e e ´t´ oubli´ sur le graphe de couverture minimal et notamment, aucun identifiant. D’ailleurs toutes les ee e d´pendances fonctionnelles du graphe doivent partir d’un identifiant. Si ce n’est pas le cas, c’est qu’un e identifiant a ´t´ omis. ee 1.3.3 Traduction vers un sch´ma entit´s-associations e e ` A partir du graphe de couverture minimale (figure 19), le sch´ma entit´s-associations normalis´ core e e respondant apparaˆ naturellement (figure 20), en suivant quelques ´tapes simples. ıt e numéro de commande numéro de client numéro d’article date de commande désignation quantité commandée nom du client adresse du client Fig. 20 – Identification des entit´s et des associations sur un graphe de couverture minimale e ´ Etape 1 : il faut rep´rer et souligner les identifiants. e ´ Etape 2 : puis tous les attributs non identifiant qui d´pendent directement d’un identifiant et d’un e seul, forment une entit´ (avec l’identifiant, bien sˆr). e u ´ Etape 3 : ensuite, les d´pendances ´l´mentaires entre les identifiants forment des associations binaires e ee dont les cardinalit´s maximales sont 1 au d´part de la d´pendance fonctionnelle et n ` l’arriv´e. e e e a e ´ Etape 4 : sauf si entre deux identifiants se trouvent deux d´pendances ´l´mentaires r´flexives 5 , aue ee e quel cas l’association binaire a deux cardinalit´s maximales valant 1. e 5. c’est ` cause de cette ´tape 4 qu’il est pr´f´rable de ne pas traduire directement le graphe de couverture minimale en a e ee un sch´ma relationnel, cf. les commentaires de la r`gle 4 page 25 e e www.tifawt.com
  • 1 www.tifawt.com ` ´ MODELE CONCEPTUEL DE DONNEES (MCD) 18 ´ Etape 5 : enfin, les attributs (non identifiants) qui d´pendent de plusieurs identifiants sont les attrie buts d’une association suppl´mentaire dont les cardinalit´s maximales sont toutes n. e e La traduction du graphe de couverture minimale de la figure 20 en un sch´ma entit´s-associations e e normalis´ est donn´e sur la figure 21. e e passer commandes 1,1 articles - n° commande - date commande - numéro article - désignation 1,n 1,n clients - 0,n concerner numéro client nom client prénom adresse client - quantité commandée Fig. 21 – Sch´ma entit´s-associations normalis´ obtenu ` partir du graphe de couverture minimale e e e a Dans ce genre de traduction, il faut donner un nom aux entit´s et aux associations, car ce n’est pas e le cas sur le graphe de couverture minimale et il reste les cardinalit´s minimales ` ´tablir. e ae Remarquons ´galement qu’en r´alit´, il faut d´j` connaˆ les entit´s en pr´sence pour ´tablir core e e ea ıtre e e e rectement le graphe de couverture minimale, ne serait-ce que pour y faire figurer leurs identifiants. Donc finalement, cette technique n’est une aide pour ´tablir les associations entre les entit´s et pour normaliser e e les entit´s et leurs associations (jusqu’en troisi`me forme normale de Boyce-Codd). e e 1.3.4 Gestion des dates et du caract`re historique e Dans une biblioth`que, on peut vouloir stocker les emprunts en cours (figure 22) et/ou les emprunts e historiques (figure 23). Pour les emprunts en cours, la date de retour pr´vu est un attribut de l’entit´ e e numéro de livre livres traduction titre date d’ emprunt date de retour prévu numéro de membre nom - n° livres titre date d’emprunt date retour prévu emprunts en 0,1 cours membres 0,n - n° membre - nom - adresse adresse Fig. 22 – Sans historisation des emprunts, pas de probl`me e livres car un livre ne peut faire l’objet que d’un seul emprunt en cours. Dans ce cas, l’´tablissement du e graphe de couverture minimal ne pose aucun probl`me. e www.tifawt.com
  • 1 www.tifawt.com ` ´ MODELE CONCEPTUEL DE DONNEES (MCD) 19 Par contre, un livre peut faire l’objet de plusieurs emprunts historiques et dans ces conditions, la date d’emprunt est d´terminante pour connaˆ e ıtre la date de retour pr´vue (figure 23 en haut ` gauche). Or e a 6 et une d´pendance fonctionnelle ne peut partir que d’un ou plusieurs une date n’est pas un identifiant e identifiant(s). C’est le signe qu’il manque un identifiant : le num´ro d’emprunt (figure 23 en haut ` droite). e a numéro de livre numéro de livre date d’emprunt date d’emprunt numéro d’emprunt correction titre date de retour prévu date de retour effectif numéro de membre nom titre date de retour prévu - n° livre 0,n - titre concerner 1,1 adresse n ctio adu r emprunts historiques - numéro de membre nom adresse t livres date de retour effectif numéro d’emprunt date d’emprunt date de retour prévu date retour effectif 1,1 avoir effectuer membres 0,n - n° membre - nom - adresse Fig. 23 – Mˆme pour une entit´ historis´e, il vaut mieux ´viter que la date n’entre dans l’identifiant e e e e Notons que l’entit´ emprunts historiques suppl´mentaire qui apparaˆ apr`s traduction (figure 23 e e ıt e en bas) ne peut pas ˆtre transform´e en une association comme on pourrait le croire au simple examen e e des cardinalit´s qui l’entourent. En effet, les attributs de l’association qui en r´sulterait ne v´rifieraient e e e pas la normalisation des attributs des associations. Notamment, la date de retour effectif ne d´pend pas e du num´ro de livre et du num´ro de membre, mais du num´ro de livre et de la date d’emprunt. e e e ` La normalisation des entit´s ne s’applique donc pas aux entit´s qui ont un caract`re historique. A e e e moins que les dates ne soient regroup´es dans une entit´ s´par´e, ce qui n’est pas conseill´ tant qu’aucune e e e e e information li´e aux dates (comme le caract`re f´ri´, par exemple) n’est n´cessaire. e e e e e 6. Si on suit le pr´cieux conseil de n’utiliser que des entiers arbitraires et auto-incr´ment´s comme identifiant. e e e www.tifawt.com
  • 1 www.tifawt.com ` ´ MODELE CONCEPTUEL DE DONNEES (MCD) 1.3.5 20 D´pendances plurielles et r´flexives e e Une ou plusieurs d´pendances fonctionnelles peuvent partir ou arriver plusieurs fois du mˆme attrie e but. Pour clarifier la signification de chaque d´pendance fonctionnelle, on peut ajouter un commentaire e sur la fl`che (figure 24). Ce commentaire sert ensuite ` donner un nom aux associations correspondantes. e a père mère médecin remplacé numéro de médecin numéro de remplacement numéro personnel médecin remplaçant adresse professionnelle nom date de début date de fin nom (a) d´pendances plurielles e prénom (b) d´pendances r´flexives e e Fig. 24 – D´pendances fonctionnelles comment´es e e Les d´pendances fonctionnelles plurielles entre les m´decins et le remplacements (figure 24(a)) dee e viennent, apr`s traduction, des associations plurielles entre les entit´s m´decins et remplacements. Noe e e tons que l’entit´ remplacements ainsi g´n´r´e, a aussi un caract`re historique. e e ee e Les fonctionnelles r´flexives (X → X), quoique toujours vraies, ne pr´sentent aucun int´rˆt, ` moins e e ee a qu’elles aient une signification particuli`re. Un exemple de d´pendance r´flexive licite sur un graphe de e e e couverture minimale est la d´pendance fonctionnelle personne → personne, lorsqu’elle signifie ( diriger )), e ( ( ˆtre en couple avec ) ou ( ˆtre le p`re ou la m`re de ) (figure 24(b)). (e ) (e e e ) Dans le mˆme ordre d’id´e, il est inutile de faire figurer sur le graphe de couverture minimal des e e d´pendances fonctionnelles non ´l´mentaires vraies, mais idiotes, comme par exemple num´ro de commande e ee e + num´ro d’article → num´ro de commande. e e 1.3.6 Associations sans attributs La lacune majeure de cette m´thode reste tout de mˆme le fait que les associations dont toutes les e e cardinalit´s maximales sont n mais qui sont sans attribut ne figurent pas sur le graphe de couverture e minimale. Il faut alors, soit leur inventer temporairement un attribut (comme pour la normalisation des attributs des associations), soit introduire une notation sp´ciale (par exemple, une d´pendance non e e ´l´mentaire qui ne d´bouche sur aucun attribut). ee e Pour illustrer ce d´faut, prenons l’exemple des films et des acteurs (figure 25). Il n’y a pas d’attribut e numéro de film titre durée numéro d’acteur nom de scène films traduction date de naissance - n° film - titre - durée jouer dans 0,n acteurs 0,n - numéro acteur - nom de scène - date naissance Fig. 25 – Utilisation d’une d´pendance non ´l´mentaire et sans enfant sur un graphe de couverture e ee minimal qui d´pende ` la fois du num´ro de film et du num´ro d’acteur (` moins d’imaginer le temps d’apparition e a e e a a e ` l’´cran). Et pourtant, les deux entit´s films et acteurs sont en association. Grˆce ` la d´pendance e a a e non ´l´mentaire et sans enfant, on peut rendre compte de cette situation sur le graphe de couverture ee minimale et faire ainsi apparaˆ l’association sur le sch´ma entit´s-associations qui en est traduit. ıtre e e www.tifawt.com
  • 1 ` ´ MODELE CONCEPTUEL DE DONNEES (MCD) 1.4 www.tifawt.com 21 M´thodologie de base e Face ` une situation bien d´finie (soit ` travers un ´nonc´ pr´cis, soit ` travers une collection de fora e a e e e a mulaires ou d’´tats que le nouveau syst`me d’information est cens´ remplacer), nous pouvons proc´der e e e e sans ´tablir le graphe de couverture minimale : e – identifier les entit´s en pr´sence ; e e – lister leurs attributs ; – ajouter les identifiants (num´ro arbitraire et auto-incr´ment´) ; e e e – ´tablir les associations binaires entre les entit´s ; e e – lister leurs attributs ; – calculer les cardinalit´s ; e – v´rifier les r`gles de normalisation et en particulier, la normalisation des entit´s (c’est ` ce stade e e e a qu’apparaissent les associations non binaires), des associations et de leurs attributs ainsi que la troisi`me forme normale de Boyce-Codd ; e – effectuer les corrections n´cessaires. e Mais, il est parfois plus intuitif d’en passer par l’´tude des d´pendances fonctionnelles directes : e e – identifier les entit´s en pr´sence et leur donner un identifiant (num´ro arbitraire et auto-incr´ment´) ; e e e e e – ajouter l’ensemble des attributs et leur d´pendances fonctionnelles directes avec les identifiants (en e commen¸ant par les d´pendances ´l´mentaires) ; c e ee – traduire le graphe de couverture minimale obtenu en un sch´ma entit´s-associations ; e e – ajuster les cardinalit´s minimales et ; e – ` ce stade, la majorit´ des r`gles de normalisation devraient ˆtre v´rifi´es, il reste tout de mˆme a e e e e e e la normalisation des noms, la pr´sence d’attributs en plusieurs exemplaires et d’associations redone dantes ou en plusieurs exemplaires, ` corriger. a Il faut garder ´galement ` l’esprit que le mod`le doit ˆtre exhaustif (c’est-`-dire contenir toutes les e a e e a informations n´cessaires) et ´viter toute redondance qui, on ne le dira jamais assez, constitue une perte e e d’espace, une d´multiplication du travail de maintenance et un risque d’incoh´rence. e e e Il faut par ailleurs veiller ` ´liminer les synonymes (plusieurs signifiants pour un signifi´, exemple : ae nom, patronyme, appellation) et les polys`mes (plusieurs signifi´s pour un signifiant, exemples : qualit´, e e e statut). Il va de soi que cette m´thodologie ne doit pas ˆtre suivie pas-`-pas une bonne fois pour toute. Au e e a contraire, il faut it´rer plusieurs fois les ´tapes successives, pour esp´rer converger vers une mod´lisation e e e e pertinente de la situation. www.tifawt.com
  • 2 www.tifawt.com ` ´ MODELE LOGIQUE DE DONNEES (MLD) 2 22 Mod`le logique de donn´es (MLD) e e Maintenant que le MCD est ´tabli, on peut le traduire en diff´rents syst`mes logiques et notamment e e e les bases de donn´es relationnelles qui proposent une vision plus concr`te pour mod´liser la situation. e e e 2.1 Syst`mes logiques e Avant l’apparition des syst`mes de gestion de base de donn´es (SGBD ou DBMS pour Data Base e e Management System), les donn´es ´taient stock´es dans des fichiers binaires et g´r´es par des programmes e e e ee ex´cutables (d´velopp´s en Basic, Cobol ou Dbase, par exemple). [Gabay] propose ` ce sujet une traduce e e a tion d’un MPD vers un MLD fichier. Mais la maintenance des programmes (en cas de modification de la structure des donn´es, notamment) ´tait tr`s probl´matique. e e e e Sont alors apparus les SGBD hi´rarchiques dans lesquels les donn´es sont organis´es en arbre (IMSe e e e e e DL1 d’IBM, par exemple), puis les SGBD r´seaux dans lesquels les donn´es sont organis´es selon un graphe plus g´n´ral (IDS2 de Bull, par exemple). [Matheron, Nanci et al., Gabay] d´crivent la traduce e e tion d’un MPD vers un MLD Codasyl (base de donn´es r´seaux). Ces deux types de SGBD sont dit e e navigationnels car on peut retrouver l’information ` condition d’en connaˆ le chemin d’acc`s. a ıtre e Aujourd’hui, ils sont largement remplac´s par les SGBD relationnels (SGBDR) avec lesquels l’infore mation peut ˆtre obtenue par une requˆte formul´e dans un langage quasiment naturel (la langage SQL e e e pour Structured Query Langage). Parmi les SGBDR les plus r´pandus nous trouvons Oracle, SQL Server e et DB2. Nous nous contentons ici d’exposer le mod`le logique de donn´es relationnel (MLDR). e e Plus r´cemment, sont apparus le mod`le logique orient´ objet et mˆme des SGBD orient´s objets. e e e e e Pourtant, les SGBD relationnels restent extrˆmement majoritaires, tandis que l’approche orient´ objet e e est parfaitement adapt´e au d´veloppement d’applications clientes dynamiques et li´es aux donn´es du e e e e syst`me d’information. e 2.2 Mod`le logique relationnel e Concentrons-nous d´sormais sur le MLDR. e 2.2.1 Tables, lignes et colonnes Lorsque des donn´es ont la mˆme structure (comme par exemple, les renseignements relatifs aux e e clients), on peut les organiser en table dans laquelle les colonnes d´crivent les champs en commun et les e lignes contiennent les valeurs de ces champs pour chaque enregistrement (tableau 3). num´ro client e 1 2 3 4 ... nom Dupont Durand Dubois Dupuis ... pr´nom e Michel Jean Claire Marie ... adresse 127, rue... 314, boulevard... 51, avenue... 2, impasse... ... Tab. 3 – Contenu de la table clients, avec en premi`re ligne les intitul´s des colonnes e e 2.2.2 Cl´s primaires et cl´s ´trang`res e e e e Les lignes d’une table doivent ˆtre uniques, cela signifie qu’une colonne (au moins) doit servir ` les e a identifier. Il s’agit de la cl´ primaire de la table. e www.tifawt.com
  • 2 www.tifawt.com ` ´ MODELE LOGIQUE DE DONNEES (MLD) 23 L’absence de valeur dans une cl´ primaire ne doit pas ˆtre autoris´e. Autrement dit, la valeur vide e e e (NULL) est interdite dans une colonne qui sert de cl´ primaire, ce qui n’est pas forc´ment le cas des autres e e colonnes, dont certaines peuvent ne pas ˆtre renseign´es ` toutes les lignes. e e a De plus, la valeur de la cl´ primaire d’une ligne ne devrait pas, en principe, changer au cours du temps. e Par ailleurs, il se peut qu’une colonne Colonne1 d’une table ne doive contenir que des valeurs prises par la colonne Colonne2 d’une autre table (par exemple, le num´ro du client sur une commande doit e correspondre ` un vrai num´ro de client). La Colonne2 doit ˆtre sans doublons (bien souvent il s’agit a e e d’une cl´ primaire). On dit alors que la Colonne1 est cl´ ´trang`re et qu’elle r´f´rence la Colonne2. e ee e ee Par convention, on souligne les cl´s primaires et on fait pr´c´der les cl´s ´trang`res d’un di`se # dans e e e e e e e la description des colonnes d’une table : clients(num´ro client, nom client, pr´nom, adresse client) e e commandes(num´ro commande, date de commande, #num´ro client (non vide)) e e Remarques : – une mˆme table peut avoir plusieurs cl´s ´trang`res mais une seule cl´ primaire (´ventuellement e e e e e e compos´es de plusieurs colonnes) ; e – une colonne cl´ ´trang`re peut aussi ˆtre primaire (dans la mˆme table) ; ee e e e – une cl´ ´trang`re peut ˆtre compos´e (c’est le cas si la cl´ primaire r´f´renc´e est compos´e) ; ee e e e e ee e e – implicitement, chaque colonne qui compose une cl´ primaire ne peut pas recevoir la valeur vide e (NULL interdit) ; – par contre, si une colonne cl´ ´trang`re ne doit pas recevoir la valeur vide, alors il faut le pr´ciser ee e e dans la description des colonnes. Les SGBDR v´rifient au coup par coup que chaque cl´ ´trang`re ne prend pas de valeurs en dehors e ee e de celles d´j` prises par la ou les colonne(s) qu’elle r´f´rence. Ce m´canisme qui agit lors de l’insertion, ea ee e de la suppression ou de la mise ` jour de lignes dans les tables, garantit ce que l’on appelle l’int´grit´ a e e r´f´rentielle des donn´es. ee e 2.2.3 Sch´ma relationnel e On peut repr´senter les tables d’une base de donn´es relationnelle par un sch´ma relationnel dans e e e e e e e lequel les tables sont appel´es relations et les liens entre les cl´s ´trang`res et leur cl´ primaire est syme bolis´ par un connecteur (figure 26). e clients - commandes numéro client nom client prénom adresse client - n° commande - date commande - #numéro client (non vide) Fig. 26 – Sch´ma relationnel simple entre deux tables e Certains ´diteur inscrivent sur le connecteur un symbole 1 cˆt´ cl´ primaire et un symbole ∞ cˆt´ e oe e oe cl´ ´trang`re (` condition que celle-ci ne soit pas d´j` cl´ primaire). Il faut prendre garde avec cette e e e a ea e convention, car le symbole ∞ se trouve du cˆt´ oppos´ ` la cardinalit´ maximale n correspondante. oe ea e www.tifawt.com
  • 2 www.tifawt.com ` ´ MODELE LOGIQUE DE DONNEES (MLD) 2.3 24 Traduction d’un MCD en un MLDR Pour traduire un MCD en un MLDR, il suffit d’appliquer cinq r`gles. e Notations : on dit qu’une association binaire (entre deux entit´s ou r´flexive) est de type : e e – 1 : 1 (un ` un) si aucune des deux cardinalit´s maximales n’est n ; a e – 1 : n (un ` plusieurs) si une des deux cardinalit´s maximales est n ; a e – n : m (plusieurs ` plusieurs) si les deux cardinalit´s maximales sont n. a e En fait, un sch´ma relationnel ne peut faire la diff´rence entre 0,n et 1,n. Par contre, il peut la faire e e entre 0,1 et 1,1 (r`gles 2 et 4). e R`gle 1 : toute entit´ devient une table dans laquelle les attributs deviennent les colonnes. L’identie e fiant de l’entit´ constitue alors la cl´ primaire de la table. e e Par exemple, l’entit´ articles de la figure 13 devient la table : e articles(num´ro article, d´signation, prix unitaire de vente) e e R`gle 2 : une association binaire de type 1 : n disparaˆ au profit d’une cl´ ´trang`re dans la table e ıt, ee e cˆt´ 0,1 ou 1,1 qui r´f´rence la cl´ primaire de l’autre table. Cette cl´ ´trang`re ne peut pas recevoir la oe ee e ee e valeur vide si la cardinalit´ est 1,1. e Par exemple, l’association livrer de la figure 13 est traduite par : fournisseurs(n◦ fournisseur, nom contact, n◦ t´l´phone contact) e e livraisons(n◦ livraison, date de livraison, nom livreur, #n◦ fournisseur (non vide)) fournisseurs - n° fournisseur - nom contact - n° téléphone contact livraisons 1,n livrer - n° livraison 1,1 - date de livraison - nom livreur fournisseurs traduction - n° fournisseur - nom contact - n° téléphone contact livraisons - n° livraison - date de livraison - nom livreur - #n° fournisseur (non vide) Fig. 27 – Traduction d’une association de type 1 : n Il ne devrait pas y avoir d’attribut dans une association de type 1 : n, mais s’il en reste, alors ils glissent vers la table cˆt´ 1. oe www.tifawt.com
  • 2 www.tifawt.com ` ´ MODELE LOGIQUE DE DONNEES (MLD) 25 R`gle 3 : une association binaire de type n : m devient une table suppl´mentaire (parfois appel´e e e e table de jonction, table de jointure ou table d’association) dont la cl´ primaire est compos´e de deux e e cl´s ´trang`res (qui r´f´rencent les deux cl´s primaires des deux tables en association). Les attributs de e e e ee e l’association deviennent des colonnes de cette nouvelle table. Par exemple, l’association concerner (1) de la figure 13 est traduite par la table suppl´mentaire e lignes de commande : lignes de commande(#n◦ commande, #n◦ article, quantit´ command´e) e e commandes - n° commande - date commande 1,n concerner (1) commandes traduction - quantité commandée - n° commande - date commande 0,n lignes de commandes articles - #n° commande - #n° article - quantité commandée - numéro article - désignation - prix unitaire de vente articles - numéro article - désignation - prix unitaire de vente Fig. 28 – Traduction d’une association de type n : m e R`gle 4 : une association binaire de type 1 : 1 est traduite comme une association binaire de type 1 : n sauf que la cl´ ´trang`re se voit imposer une contrainte d’unicit´ en plus d’une ´ventuelle contrainte de ee e e e non vacuit´ (cette contrainte d’unicit´ impose ` la colonne correspondante de ne prendre que des valeurs e e a distinctes). Si les associations fantˆmes ont ´t´ ´limin´es, il devrait y avoir au moins un cˆt´ de cardinalit´ 0,1. o eee e oe e C’est alors dans la table du cˆt´ oppos´ que doit aller la cl´ ´trang`re. Si les deux cˆt´s sont de cardinalit´ oe e ee e oe e 0,1 alors la cl´ ´trang`re peut ˆtre plac´e indiff´remment dans l’une des deux tables. ee e e e e Par exemple, l’association diriger de la figure 29 est traduite par : e e services(n◦ service, nom service, #num´ro employ´ (non vide, unique)) employ´s(num´ro employ´s, nom) e e e services employés - n° employé - nom 0,1 diriger employés services 1,1 - n° service - nom service traduction - n° employé - nom Fig. 29 – Traduction d’une association de type 1 : 1 www.tifawt.com - n° service - nom service - #n° employé (unique, non vide)
  • 2 www.tifawt.com ` ´ MODELE LOGIQUE DE DONNEES (MLD) 26 En r´alit´, la r`gle 4 propos´e ici consid`re qu’une association binaire de type 1 : 1 correspond ` e e e e e a une association binaire de type 1 : n particuli`re. Une alternative consiste ` voir une association binaire e a de type 1 : 1 comme une association binaire de type n : m particuli`re. Il suffit pour cela d’ajouter une e contrainte d’unicit´ sur chacune des cl´s ´trang`res de la table de jonction suppl´mentaire : e e e e e services(n◦ service, nom service) directions(#n◦ service (unique), #num´ro employ´ (unique) e e employ´s(num´ro employ´s, nom) e e e directions employés - n° employé - nom services - #n° service (unique) - #n° employé (unique) - n° service - nom service Fig. 30 – Traduction alternative d’une association de type 1 : 1 Mais rien ne garantit, dans cette traduction alternative (figure 30), qu’un service poss`de un dirigeant, e alors que c’est obligatoire. La premi`re traduction (figure 29) est donc pr´f´rable. e ee Remarque : d’autres techniques sont parfois propos´es pour cette r`gle 4 (fusionner les tables, utiliser e e une cl´ primaire identique, utiliser deux cl´s ´trang`res r´flexives) mais elles ne sont pas exploitables dans e e e e e le cas g´n´ral. e e R`gle 5 : une association non binaire est traduite par une table suppl´mentaire dont la cl´ primaire e e e est compos´e d’autant de cl´s ´trang`res que d’entit´s en association. Les attributs de l’association dee e e e e viennent des colonnes de cette nouvelle table. Par exemple, l’association projeter de la figure 8 devient la table : projections(#n◦ film, #n◦ salle, #n◦ cr´neau, tarif) e créneaux horaires créneaux horaires - n° créneau - date - heure de début - n° créneau - date - heure de début 0,n projeter - tarif projections films 0,n - n° film - titre - durée traduction - films #n° film #n° salle #n° créneau tarif - n° film - titre - durée 0,n salles salles - n° salle - capacité - n° salle - capacité Fig. 31 – Traduction d’une association ternaire www.tifawt.com
  • 3 www.tifawt.com ` ´ MODELE PHYSIQUE DE DONNEES (MPD) 3 27 Mod`le physique de donn´es (MPD) e e Un mod`le physique de donn´es est l’impl´mentation particuli`re du mod`le logique de donn´es par e e e e e e un logiciel. 3.1 Distinction entre MLD et MPD La traduction d’un MLD conduit ` un MPD qui pr´cise notamment le stockage de chaque donn´e ` a e e a travers son type et sa taille (en octets ou en bits). Cette traduction est ´galement l’occasion d’un certain e nombre de libert´s prises par rapport aux r`gles de normalisation afin d’optimiser les performances du e e syst`me d’information. e La traduction d’un MLD relationnel en un mod`le physique est la cr´ation (par des requˆtes SQL e e e de type CREATE TABLE et ADD CONSTRAINT) d’une base de donn´es h´berg´e par un SGBD relationnel e e e particulier. Il peut s’agir d’une base Oracle, d’une base SQL Server, d’une base Access ou d’une base DB2, par exemple. Le fait que tous les SGBDR reposent sur le mˆme mod`le logique (le sch´ma relationnel) e e e permet ` la fois la communication entre des bases h´t´rog`nes et la conversion d’une base de donn´es a ee e e d’une SGBDR ` l’autre. a 3.2 Optimisations L’optimisation des performances en temps de calcul se fait toujours au d´triment de l’espace m´moire e e consomm´. Dans le pire des cas, r´duire les temps de r´ponse consiste ` d´normaliser volontairement le e e e a e syst`me d’information, avec tous les risques d’incoh´rence et les probl`mes de gestion que cela comporte. e e e Pour les bases de donn´es relationnelles, l’optimisation qui vise ` acc´l´rer les requˆtes peut passer e a ee e par : – l’ajout d’index aux tables (au minimum sur les colonnes cl´s primaires et cl´s ´trang`res) ; ces index e e e e consomment de l’espace m´moire suppl´mentaire, mais la base de donn´es reste normalis´e ; e e e e – l’ajout de colonnes calcul´es ou de certaines redondances pour ´viter des jointures coˆteuses (aue e u quel cas la base est d´normalis´e) ; il faut alors veiller ` ce que la coh´rence entre les colonnes e e a e soit respect´e, soit par l’utilisation de d´clencheurs, soit dans les applications clientes du syst`me e e e d’information ; – la suppression des contraintes d’unicit´, de non vacuit´ ou encore de cl´ ´trang`re (auquel cas, e e e e e l’int´grit´ des donn´es doit ˆtre assur´e par le code client du syst`me d’information). e e e e e e Par exemple, la table commandes de la figure 28 peut ˆtre supprim´e et la date de commande est e e alors ajout´e ` la table lignes de commandes. On renonce donc ` la troisi`me forme normale (figure 32) e a a e commandes - n° commande - date commande lignes de commandes lignes de commandes articles - #n° commande - #n° article - quantité commandée - numéro article - désignation - prix unitaire de vente dénormalisation - n° commande #n° article date commande quantité commandée Fig. 32 – Sacrifice de la troisi`me forme normale e www.tifawt.com articles - numéro article - désignation - prix unitaire de vente
  • 4 ´ RETRO-CONCEPTION www.tifawt.com 28 puisque la date de commande est r´p´t´e autant de fois qu’il y a de lignes dans la commande, mais on e ee ´vite ainsi une jointure coˆteuse en temps de calcul lors des requˆtes SQL. e u e Le conseil le plus pr´cieux, en mati`re d’optimisation, est de ne jamais optimiser a priori, mais toujours e e a posteriori, c’est-`-dire en r´ponse ` une lenteur que le SGBDR n’est pas capable de r´soudre tout seul. a e a e Il faut alors mesurer le gain de toute optimisation manuelle en effectuant des tests (chronom´trages e avant/apr`s) sur un volume de donn´es significatif et de pr´f´rence en exploitation. e e ee 4 R´tro-conception e Dans la majorit´ des cas, le travail du concepteur de bases de donn´es consiste non pas ` cr´er une e e a e base de donn´es ex nihilo, mais plutˆt ` corriger ou ´tendre une base existante. Dans ce cas, la mati`re de e o a e e travail initiale est un mod`le physique et la m´thode de r´tro-conception ou reverse engineering consiste e e e a ` traduire ce MPD en un mod`le conceptuel, modifier le MCD obtenu puis modifier le mod`le physique e e en cons´quence. e 4.1 Traduction inverse Dans le cadre des bases de donn´es relationnelles, il faut convertir le mod`le physique en un sch´ma e e e relationnel normalis´ (en d´tricotant les optimisations ´ventuelles et en renommant les colonnes des tables e e e pour assurer l’unicit´ et le caract`re explicite (non cod´) des noms), puis appliquer les r`gles de traduction e e e e de la section 2.3 dans le sens inverse. ´ Etape 1 : chaque table dont la cl´ primaire ne contient pas de cl´ ´trang`re devient une entit´ dont e ee e e l’identifiant est la cl´ primaire de la table et dont les attributs sont les colonnes de la table qui ne sont e pas cl´ ´trang`re. ee e ´ Etape 3 : chaque table dont la cl´ primaire est compos´e exclusivement de cl´s ´trang`res qui e e e e e r´f´rencent plusieurs cl´s primaires, devient une association autour de laquelle toutes les cardinalit´s ee e e maximales valent n, c’est-a-dire soit une association binaire de type n : m soit une association ternaire ou plus (les autres colonnes non cl´s ´trang`res de la table deviennent des attributs de l’association). e e e ´ Etape 5 : les colonnes cl´s ´trang`res restantes deviennent des associations binaires de type 1 : n s’il e e e n’y a pas de contrainte d’unicit´ ou de type 1 : 1 s’il y a une contrainte d’unicit´ (il faut trouver un nom e e a ` cette association). ´ Etape 6 : la cardinalit´ minimale vaut 1 pour les cl´s ´trang`res qui font partie d’une cl´ primaire e e e e e ou qui poss`dent une contrainte (non vide), sinon elle vaut 0. e www.tifawt.com
  • 4 www.tifawt.com ´ RETRO-CONCEPTION 4.2 29 Cas particuliers Malheureusement, ces quatres ´tapes ne suffisent pas pour traduire tous les sch´mas relationnels pose e sibles. Notamment, les tables de la figure 33 n´cessitent l’insertion d’´tapes suppl´mentaires. e e e chèques règlements - n° règlement - date règlement - montant - #n° règlement - n° chèque - nom banque paiements par carte parcours trous - n° parcours - nom parcours - #n° parcours - n° trou dans parcours - par - distance - #n° règlement - n° carte - date d’expiration (a) cl´ sur une colonne, mais ` la fois prie a maire et ´trang`re e e (b) cl´ primaire compos´e partiele e lement de cl´ ´trang`re ee e Fig. 33 – Tables particuli`res en r´tro-conception e e ´ Etape 2 : chaque table dont la cl´ primaire est compos´e exclusivement de cl´s ´trang`res qui e e e e e r´f´rencent une seule cl´ primaire, devient une sous-entit´ ou une sous-association (les autres colonnes ee e e non cl´s ´trang`res de la table deviennent des attributs de cette sous-entit´). e e e e ´ Etape 4 : chaque table dont la cl´ primaire est compos´e partiellement de cl´s ´trang`res provient e e e e e soit d’une optimisation qu’il faire d´faire (comme sur la figure 32) soit d’un identifiant relatif d’une entit´ e e comme dans la section 5.2 (auquel cas les autres colonnes non cl´s ´trang`res de la table deviennent des e e e attributs de cette entit´). e www.tifawt.com
  • 5 ´ COMPLEMENTS 5 www.tifawt.com 30 Compl´ments e Aucune situation compl`te, ou presque, ne peut ˆtre parfaitement mod´lis´e si le concepteur se e e e e contente des fonctionnalit´s abord´es ` ce stade du document. Ne serait-ce que pour comprendre l’´lae e a e boration des tables de la figure 33, il est n´cessaire d’introduire de nouvelles notations sur le sch´ma e e entit´s-associations. Les trois extensions majeures pr´sent´es dans cette section font partie de la vere e e sion 2 de Merise [Panet et al.]. Elles permettent de traiter davantage de situations r´elles et souvent de e mani`re plus simple. e Dans cette section, nous reprenons la d´marche qui consiste ` ´tudier les d´pendances fonctionnelles e ae e directes sur le graphe de couverture minimale, puis ` traduire ce graphe en sch´ma entit´s-associations, a e e pour obtenir finalement un sch´ma relationnel. Les notions abord´es ici ne permettent plus au sch´ma e e e relationnel d’ˆtre ´crit textuellement sans ambigu¨ e. Afin de lever toute ambigu¨ e pour savoir quelle e e ıt´ ıt´ cl´ primaire est r´f´renc´e par telle cl´ ´trang`re, il est imp´ratif de repr´senter le sch´ma relationnel de e ee e ee e e e e mani`re graphique, ce que nous nous contentons de faire. e 5.1 Agr´gation e Une association n’est pas forc´ment ´tablie exclusivement entre des entit´s. e e e 5.1.1 Association de type 1 : n Consid´rons l’exemple de la figure 34 issu du monde des courses hippiques. La d´pendance fonctione e ◦ cheval + n◦ course → n◦ jockey est la premi`re d´pendance fonctionnelle non ´l´mentaire nelle n e e ee vers un identifiant que nous rencontrons. Ce type de d´pendance fonctionnelle nous incite ` cr´er une e a e association binaire de type 1 : n entre l’entit´ jockeys et l’association binaire de type n : m qu’il y a entre e les entit´s chevaux et courses. D’un point de vue s´mantique, la logique est respect´e puisque un jockey e e e ne monte pas un cheval, mais un cheval-qui-participe-`-une-course. a Pour tenir compte de ce nouveau cas de d´pendance fonctionnelle, il convient d’ajouter une sixi`me e e ´tape ` la technique de traduction d’un graphe de couverture minimal en un sch´ma entit´s-associations, e a e e telle qu’elle est commenc´e section 1.3.3 : e ´ Etape 6 : lorsqu’un identifiant d´pend de plusieurs autres identifiants, son entit´ est en association e e de type 1 : n avec l’association qui lie les autres identifiants. www.tifawt.com
  • 5 www.tifawt.com ´ COMPLEMENTS 31 nom du cheval numéro de cheval date de naissance dossard nom du jockey numéro de jockey ordre d’arrivée prénom lieu de la course date de la course tra du cti on numéro de course chevaux - n° cheval - nom cheval - date naissance chevaux - n° cheval - nom cheval - date naissance 0,n participations participer 0,n #n° course #n° cheval dossard ordre d’arrivée #n° jockey (non vide) courses courses - n° course - lieu course - date course - n° course - lieu course - date course - dossard - ordre d’ arrivée jockeys 1,1 monter 0,n - n° jockey - nom jockey - prénom traduction - jockeys - n° jockey - nom jockey - prénom Fig. 34 – Association binaire de type 1 : n (monter), li´e ` une association binaire de type n : m e a (participer) Certains auteurs consid`rent que l’agr´gation des entit´s chevaux, courses et de l’association pare e e ticiper constitue une nouvelle entit´ participations qui englobe ces trois ´l´ments graphiques. Dans e ee ce cas, l’association monter fait le lien entre les deux entit´s (participations et jockeys). Le r´sultat e e final sur le sch´ma relationnel est le mˆme. Malheureusement, cette notation n’est pas tr`s pratique car e e e le sch´ma entit´s-associations devient vite illisible lorsqu’une entit´ participe ` plusieurs agr´gations. e e e a e Nous pr´f´rons donc autoriser, dans ce document, qu’une association puisse ˆtre li´e ` une associaee e e a tion binaire de type n : m ou ` une association ternaire (ou plus). Cependant pour ne pas confondre les a liens entres associations et entit´s avec les liens entres associations, nous encadrons soigneusement les e associations qui interviennent dans une agr´gation, comme sur la figure 34 en bas ` gauche. e a En tout cas, une association ne peut pas ˆtre li´e ` une association binaire de type 1 : n ou 1 : 1. Dans ce e e a cas, l’association doit ˆtre directement li´e ` l’entit´ qui se trouve du cˆt´ o` la cardinalit´ maximale est 1. e e a e oe u e Sur le sch´ma relationnel final (figure 34 en bas ` droite), la table de jonction participations re¸oit e a c une cl´ ´trang`re suppl´mentaire, mais qui contrairement aux autres, ne participe pas ` la cl´ primaire. ee e e a e www.tifawt.com
  • 5 www.tifawt.com ´ COMPLEMENTS 5.1.2 32 Association de type n : m ` ´ A pr´sent, ajoutons les parieurs ` notre exemple de la figure 34. Etant donn´ que nous avons la e a e ◦ cheval + n◦ course + n◦ parieur → montant de la mise (figure 35 en d´pendance fonctionnelle n e haut), nous pourrions avoir une association ternaire entre les entit´s chevaux, courses et parieurs. e Mais dans ce cas, un parieur peut miser sur un cheval dans une course, alors que ce cheval ne participe pas ` cette course. a nom du cheval numéro de cheval nom du parieur date de naissance dossard numéro de jockey numéro de parieur numéro de compte ordre d’arrivée montant nom du jockey prénom lieu de la course numéro de course correction date de la course nom du cheval numéro de cheval nom du parieur date de naissance dossard numéro de jockey numéro de parieur numéro de compte ordre d’arrivée montant numéro de course nom du jockey prénom lieu de la course date de la course Fig. 35 – Association ternaire remplac´e par deux associations binaires e Pour pallier cette lacune, on pourrait faire appel ` des d´clencheurs programm´s dans la base de a e e donn´es finale. Les d´clencheurs sont des proc´dures SQL qui, dans notre exemple, permettraient ` e e e a chaque insertion ou mise ` jour de lignes dans la table des paris, d’assurer qu’un pari ne puisse pas a concerner un cheval dans une course ` laquelle il ne participe pas. Cependant, il existe une solution plus a simple qui repose uniquement sur l’int´grit´ r´f´rentielle. e e ee En r´alit´ (figure 35 en bas), la vraie d´pendance fonctionnelle directe est (n◦ cheval + n◦ course) e e e ◦ parieur → montant, ce qui garantit qu’un parieur ne peut miser que sur un cheval-qui-participe+ n a `-une-course. Le fait qu’une association ternaire (ou plus) disparaissent au profit d’une ou plusieurs agr´gations e ` est tr`s fr´quent lorsque l’on mod´lise une situation compl`te. A tel point qu’on peut partir du principe e e e e qu’un sch´ma entit´s-associations sans agr´gation est g´n´ralement faux. e e e e e www.tifawt.com
  • 5 www.tifawt.com ´ COMPLEMENTS 33 Dans notre exemple, la traduction de la nouvelle d´pendance fonctionnelle en une association de type e n : m (figure 36 en haut) se fait en appliquant, comme d’habitude, l’´tape 4 de la section 1.3.3. e chevaux - n° cheval - nom cheval - date naissance 0,n participer parier parieurs - n° parieur 0,n - montant - nom parieur - n° compte 0,n - dossard - ordre d’ arrivée jockeys 1,1 monter 0,n - n° jockey - nom jockey - prénom 0,n traduction courses - n° course - lieu course - date course parieurs - n° parieur - nom parieur - n° compte paris - #n° parieur #n° course #n° cheval montant participations - #n° course #n° cheval dossard ordre arrivée #n° jockey (non vide) courses - n° course - lieu course - date course chevaux - n° cheval - nom cheval - date naissance jockeys - n° jockey - nom jockey - prénom Fig. 36 – Association binaire de type n : m (parier), li´e ` une autre association binaire de type n : m e a Sur le sch´ma relationnel obtenu (figure 36 en bas), la traduction de l’association binaire de type n : m e li´e ` une autre association binaire de type n : m fait apparaˆ dans la table paris une cl´ ´trang`re e a ıtre ee e composite qui r´f´rence la cl´ primaire composite de la table participations. ee e Rappelons qu’il est d´conseill´ d’utiliser des identifiants composites. Mais la cl´ primaire composite e e e de la table participations est l´gitime puisqu’elle est issue d’une association binaire de type n : m. En e cons´quence de quoi la cl´ ´trang`re composite de la table paris est ´galement l´gitime puisqu’elle est e ee e e e aussi issue d’une association binaire de type n : m. On peut ainsi imaginer avoir sur un sch´ma relationnel des cl´s primaires ou ´trang`res compos´es e e e e e d’un nombre arbitraire de colonnes, sans pour autant qu’il n’y ait un seul identifiant composite sur le sch´ma entit´s-associations correspondant. e e www.tifawt.com
  • 5 www.tifawt.com ´ COMPLEMENTS 5.1.3 34 Tables de codification ou tables de r´f´rence ee Certains attributs ne peuvent prendre qu’un jeu volontairement limit´ de valeurs. C’est le cas sur la e figure 37 ` gauche, pour les attributs enseignant et mati`re. Cela ´vite sur cet exemple qu’une mˆme a e e e mati`re ne soit d´crite de deux mani`res diff´rentes et qu’un mˆme nom d’enseignant ne soit orthographi´ e e e e e e deux fois. semaines dans l’année semaines dans l’année - n° semaine - date de début - n° semaine - date de début jours dans la semaine - n° jour - jour jours dans la semaine 0,n 0,n occuper - enseignant créneaux horaires 0,n - matière dans la journée - n° créneau - heure de début 0,n correction enseignants - n° enseignant - nom 0,n 0,n assurer - n° jour - jour 0,n créneaux horaires dans la journée - n° créneau - heure de début 0,n occuper 1,1 1,1 concerner 0,n 0,n salles salles matière - n° salle - capacité - n° salle - capacité - n° matière - libellé Fig. 37 – Agr´gation et entit´s de codification e e e e Il est recommand´ de regrouper ces valeurs au sein d’une entit´ dite de codification (qui donnera ensuite une table de codification). Si l’attribut concern´ appartient ` une entit´, alors cette entit´ est e a e e en association binaire de type 1 : n avec cette entit´ de codification. Par contre, si l’attribut fait partie e d’une association, il faut recourir ` l’agr´gation afin de mettre en association l’entit´ de codification avec a e e l’association de cet attribut (figure 37 a droite). ` Ainsi, l’agr´gation ´vite notamment aux entit´s de codification de transformer une association binaire e e e en une association ternaire (ou plus). www.tifawt.com
  • 5 www.tifawt.com ´ COMPLEMENTS 5.2 35 Identifiant relatif ou lien identifiant Mˆme en utilisant des agr´gations, il reste des situations o` tout le potentiel de l’int´grit´ r´f´rentielle e e u e e ee n’est pas exploit´. e 5.2.1 R´solution d’un probl`me sur le sch´ma relationnel e e e Prenons par exemple le sch´ma relationnel en haut de la figure 38, tir´ d’une base de donn´es pour e e e un centre de golf. Dans la table trous, la cl´ primaire n◦ trou est en incr´ment automatique, tandis que e e la colonne n◦ trou dans parcours est un nombre (g´n´ralement compris entre 1 et 18) qui correspond e e a ` la num´rotation des trous dans le parcours. e Le probl`me de ce sch´ma relationnel est qu’en l’´tat, il peut y avoir un score dans la table scores e e e pour un trou qui n’appartient pas au parcours sur lequel la partie se joue (le lecteur est invit´ ` bien e a observer la figure pour s’en apercevoir). participations parties - n° parcours - nom parcours - #n° golfeur - #n° partie trous - n° trou - #n° parcours (non vide) - n° trou dans parcours - par - distance scores - participations parties - n° partie - #n° parcours - date - n° golfeur - nom golfeur - handicap #n° golfeur #n° partie #n° trou score correction parcours - n° partie - #n° parcours (non vide) - date golfeurs - #n° golfeur - #n° partie - #n° parcours golfeurs - n° golfeur - nom golfeur - handicap parcours - n° parcours - nom parcours scores trous - #n° parcours - n° trou dans parcours - par - distance - #n° golfeur #n° partie #n° parcours #n° trou dans parcours - score Fig. 38 – Utilisation de cl´s primaires partiellement ´trang`res e e e Pour r´gler ce probl`me, on peut ` nouveau se reposer sur l’emploi de d´clencheurs. Mais l`-encore, e e a e a il existe une solution ne faisant appel qu’` l’int´grit´ r´f´rentielle. a e e ee Cette solution consiste ` faire entrer le num´ro de parcours dans la num´rotation des trous (rema e e pla¸ant ainsi le n◦ trou) ainsi que dans la num´rotation des parties (en conservant cette fois-ci le n◦ c e www.tifawt.com
  • 5 www.tifawt.com ´ COMPLEMENTS 36 partie en incr´ment automatique). Les tables trous et parties poss`dent alors une cl´ primaire come e e posite et partiellement ´trang`re (figure 38 en bas). e e Les cl´s ´trang`res des tables participations et scores qui r´f´rencent ces nouvelles cl´s primaires e e e ee e sont alors compl´t´es par une nouvelle colonne (le num´ro de parcours). Dans la table des scores, comme ee e cette colonne n◦ parcours n’est introduite qu’une fois, il n’est plus possible pour un joueur d’avoir un score sur un trou qui n’appartient pas au parcours sur lequel se joue la partie. 5.2.2 Mod`le conceptuel correspondant e En r´tro-conception, pour tenir compte du fait que le num´ro de parcours fera partie de la cl´ primaire e e e de la table trous sur le sch´ma entit´s-associations, il suffit de mettre entre parenth`ses la cardinalit´ 1,1 e e e e de l’association entre les entit´s trous et parcours (figure 39). L’identifiant de l’entit´ cˆt´ 1,1 devient e e oe alors relatif ` celui de l’autre entit´ en association. a e avoir lieu sur 0,n golfeurs parties (1,1) - n° partie - date 0,n participer 0,n - n° golfeur - nom golfeur - handicap parcours 0,n - n° parcours - nom parcours 0,n trous faire partie (1,1) - n° trou dans parcours - par - distance 0,n obtenir - score Fig. 39 – Repr´sentation des identifiants relatifs e De mˆme, sur le graphe de couverture minimal, nous introduisons une nouvelle notation (fl`che en e e pointill´s) pour repr´senter le caract`re relatif des identifiants (figure 40). e e e numéro de partie sur un parcours nom du golfeur numéro de golfeur handicap date score numéro de trou dans un parcours numéro de parcours nom du parcours par distance Fig. 40 – Repr´sentation des identifiants relatifs sur le graphe de couverture minimale e Si les fl`ches ´taient pleines, les num´ros de trou dans un parcours et de partie sur un parcours e e e figureraient dans des entit´s s´par´es et r´duites ` leur identifiant (` ´viter). e e e e a ae www.tifawt.com
  • 5 www.tifawt.com ´ COMPLEMENTS 5.2.3 37 Discussion autour de la num´rotation des exemplaires e Dans un magasin de location de vid´os, le g´rant peut vouloir num´roter s´par´ment les exemplaires e e e e e de chaque vid´o (figure 41 colonne de gauche), alors que le concepteur de la base de donn´es aurait e e tendance ` vouloir num´roter globalement l’ensemble des exemplaires (colonne de droite). a e titre date d’acquisition titre numéro d’exemplaire numéro de vidéo date d’acquisition numéro de vidéo numéro d’exemplaire emprunt emprunt numéro de membre date de téléphone réservation numéro de membre date d’emprunt date de téléphone réservation exemplaires vidéos correspondre - n° vidéo - titre 0,n correspondre 0,n membres 1,1 - n° exemplaire - date acquisition - date emprunt 0,1 réserver 0,n - n° membre - date réservation - nom - téléphone traduction 0,n exemplaires vidéos 0,n emprunter traduction (1,1) - n° exemplaire - date acquisition - date emprunt 0,n 0,1 membres emprunter réserver 0,n - n° membre 0,n - date réservation - nom - téléphone - n° vidéo - titre nom traduction traduction nom date d’emprunt vidéos exemplaires - n° vidéo - titre réservations membres - # n° vidéo - # n° membre - date réservation - n° membre - nom - téléphone - vidéos exemplaires # n° vidéo n° exemplaire date acquisition #n° membre date emprunt - n° vidéo - titre - # n° vidéo (non vide) - n° exemplaire - date acquisition - #n° membre - date emprunt réservations membres - # n° vidéo - # n° membre - date réservation - n° membre - nom - téléphone Fig. 41 – Num´rotations alternatives des exemplaires e La seule diff´rence entre les deux solutions est l’entr´e ou non de la colonne num´ro vid´o dans la cl´ e e e e e primaire de la table exemplaire. L’inconv´nient majeur de la solution avec identifiant relatif (colonne de e gauche), est le traitement de l’incr´ment automatique du num´ro d’exemplaire, car il faut un compteur e e pour chaque vid´o et non pas un compteur pour l’ensemble des vid´os, contrairement ` la solution de e e a la colonne de droite. Le concepteur devrait donc retenir sa solution pour la base de donn´es et proposer e une colonne suppl´mentaire avec la num´rotation du g´rant, afin de lui faire plaisir. e e e www.tifawt.com
  • 5 www.tifawt.com ´ COMPLEMENTS 5.3 38 H´ritage e Enfin, il est parfois utile de factoriser les attributs communs ` plusieurs entit´s au sein d’une entit´ a e e m`re. e 5.3.1 Sous-entit´ e Consid´rons l’exemple suivant : les factures d’une entreprise font l’objet d’un r`glement par ch`que e e e ou par carte. Cette entreprise souhaite connaˆ pour chaque r`glement la date, le montant et : ıtre e – le num´ro et le nom de la banque des ch`ques ; e e – ou le num´ro et la date d’expiration des paiements par carte. e On a donc une entit´ g´n´rique r`glements et deux entit´s sp´cialis´es ch`ques et paiements par e e e e e e e e carte. Ces deux sous-entit´s de l’entit´ r`glements ont des attributs propres mais pas d’identifiant e e e propre. Au niveau logique objet, on retrouve la notion d’h´ritage. e Conform´ment aux notations objets, sur le sch´ma entit´s-associations, on repr´sente le lien qui unit e e e e une sous-entit´ ` son entit´ g´n´rique par une fl`che creuse (figure 42 au centre). Ce lien remplace une asea e e e e sociation ^tre de type 1 : 1 (un ch`que ( est un ) r`glement et un paiement par carte ( est un ) r`glement). e e ( ) e ( ) e numéro de chèque numéro de règlement numéro de facture date de règlement et montant numéro de règlement règlements - n° chèque - nom banque 1,1 - n° règlement - date règlement - montant paiements par carte - n° carte - date d’expiration traduction correspondre numéro de carte chèques factures - n° facture 0,n - date facture - montant total nom de la banque date d’expiration traduction date de facture et montant total numéro de règlement chèques règlements factures - n° facture - date facture - montant total - n° règlement date règlement montant #n° facture (non vide) - #n° règlement - n° chèque - nom banque paiements par carte - #n° règlement - n° carte - date d’expiration Fig. 42 – Repr´sentation des sous-entit´s e e Toutefois, il ne faut pas voir d’h´ritage ` chaque fois que l’on peut dire ( est un ) car il faut en e a ( ), plus que l’entit´ m`re ne poss`de que les attributs communs de ses entit´s filles. Par exemple, un cercle e e e e ( est math´matiquement un ) ovale. Mais l’entit´ cercles (avec les attributs centre et rayon) n’est pas ( e ) e www.tifawt.com
  • 5 www.tifawt.com ´ COMPLEMENTS 39 une sous-entit´ de l’entit´ ovales car celle-ci poss`de davantage d’attributs (centre, rayon principal, e e e rayon secondaire et rotation). La traduction des sous-entit´s au niveau logique relationnel fait intervenir une cl´ primaire identique e e a ` celle de l’entit´ m`re, mais dans les sous-entit´s la cl´ primaire est aussi ´trang`re (figure 42 en bas). e e e e e e Sur le graphe de couverture minimale (figure 42 en haut), l’identifiant dont d´pendent les attributs e communs est volontairement dupliqu´ autant de fois que n´cessaire pour les attributs sp´cialis´s. Nous e e e e pouvons alors remarquer que les attributs qui d´pendent d’un mˆme identifiant peuvent ˆtre regroup´s e e e e avec des (( et )) logiques tandis que d`s qu’il est n´cessaire de faire appel ` un ( ou ) logique, c’est le signe e e a ( ) d’une sp´cialisation. e Sur la figure 42, il est tentant de traduire directement le graphe de couverture minimale en le sch´ma e relationnel, car il en est beaucoup plus proche que le sch´ma entit´s-associations. C’est une technique e e licite, ` condition de traduire correctement les associations de type 1 : 1 (´tape 4 page 17). a e 5.3.2 Utilisation de l’h´ritage pour s´parer les informations compl´mentaires e e e L’h´ritage peut ˆtre utilis´ mˆme lorsqu’il n’y a qu’une entit´ sp´cialis´e. C’est utile pour stocker e e e e e e e dans une table s´par´e des informations compl´mentaires. e e e Consid´rons la table clients dans laquelle nous stockons d´j` le num´ro, le nom et le code pose ea e tal. Nous souhaitons d´sormais stocker ´galement le num´ro de t´l´phone, l’adresse courier et l’adresse e e e ee ´lectronique. La premi`re id´e consiste ` ajouter trois colonnes suppl´mentaires dans la table clients. e e e a e Mais pour les clients qui ont d´j` ´t´ saisis dans la table, ces trois colonnes seront vides. eaee Pour gagner de la place, ces trois colonnes peuvent constituer une nouvelle table annuaire clients dont la cl´ primaire r´f´rence celle de la table clients (figure 43). Formellement, annuaire clients est e ee issue d’une sous-entit´ de l’entit´ clients. e e clients numéro de client - n° client - nom - code postal nom code postal téléphone clients - n° client - nom - code postal traduction traduction annuaire clients adresse numéro de client email - téléphone - adresse - email annuaire clients - # n° client téléphone adresse email Fig. 43 – S´paration des informations compl´mentaires par h´ritage e e e La configuration d’h´ritage sur le sch´ma relationnel (figure 43 a droite) constituera une occasion e e ` d’´crire des requˆtes SQL avec des jointures externes (c’est-`-dire facultatives). e e a www.tifawt.com
  • 5 www.tifawt.com ´ COMPLEMENTS 5.3.3 40 Sp´cialisation des associations e La notion d’h´ritage est valable ´galement pour les associations. Nous pouvons donc faire appel ` e e a des sous-associations avec des attributs sp´cifiques et des associations g´n´riques qui contiennent les e e e attributs communs. Mais sans aller jusqu’` l’introduction de sous-associations, d`s qu’un sch´ma entit´sa e e e associations fait appel ` des sous-entit´s, il est fr´quent que les associations concern´es par ces sous-entit´s a e e e e soient elles-mˆmes sp´cialis´es . e e e Consid´rons une entreprise artisanale qui vend non seulement des articles produits en s´rie ` prix e e a unitaire fixe, mais aussi des articles fait sur mesure et dont le prix unitaire est calcul´ ` partir de la e a dur´e de confection et d’un taux horaire. Dans ce cas, non seulement l’entit´ articles est sp´cialis´e e e e e en articles en s´rie et articles sur mesure, mais en plus, l’association concerner entre les entit´s e e commandes et article est sp´cialis´e selon qu’il s’agit d’un article en s´rie ou sur mesure (figure 44 au e e e centre). numéro d’article numéro d’article quantité prix unitaire de vente désignation tra numéro d’article durée numéro de commande taux horaire de facturation du ct i on concerner (1) articles en série articles 0,n - quantité commandée commandes - n° commande 1,n - date commande articles sur mesure - taux horaire de facturation - durée 1,n 1,1 concerner (2) articles - n° article - désignation articles sur mesure - #n° article - taux horaire de facturation - durée - #n° commande (non vide) lignes de commandes tr a articles en série - #n° article - prix unitaire de vente du c ti on - n° article - désignation - prix unitaire de vente - #n° commande - #n° article - quantité commandée commandes - n° commande - date commande Fig. 44 – Sp´cialisation des associations en pr´sence de sous-entit´s e e e Le fait d’avoir volontairement d´doubler l’identifiant commun des entit´s en h´ritage, permet d’utilie e e ser chaque identifiant dupliqu´ dans l’association qui le concerne. e Sur le sch´ma relationnel (figure 44 en bas), les associations sp´cialis´es sont traduites de mani`re e e e e ` classique. A charge ensuite pour le d´veloppeur du formulaire de facturation, d’effectuer la r´union des e e articles command´s. e www.tifawt.com
  • www.tifawt.com CONCLUSION 41 Conclusion Avec la pratique, vient un moment o` le concepteur peut se passer du mod`le entit´s-associations u e e et produire directement des sch´mas relationnels corrects. Pourtant, continuer de travailler ` un niveau e a conceptuel plutˆt qu’` un niveau logique reste une tactique payante pour lui, dans la mesure o` les o a u donn´es pourtant stock´es sous une forme relationnelle, doivent de nos jours ˆtre acc´d´es par des applie e e e e cations orient´es objet. Le mod`le conceptuel permet de faire le lien entre d’une part la repr´sentation e e e objet des donn´es et d’autre le stockage relationnel des mˆmes donn´es. e e e Par exemple, on peut tr`s bien imaginer qu’un sch´ma entit´s-associations soit d’un cˆt´ traduit en e e e oe un sch´ma relationnel puis impl´ment´ dans une base de donn´es Oracle ; tandis qu’en parall`le, il est e e e e e traduit en un diagramme de classe (mod`le logique objet), lui-mˆme impl´ment´ dans un ensemble de e e e e classes Java. Ces classes Java permettent ensuite aux d´veloppeurs de construire des applications clientes e orient´es objet et qui attaquent de mani`re transparente les donn´es de la base Oracle. Il s’agit d’une e e e solution de passage entre la mod´lisation orient´e objet (pertinente pour d´velopper des interfaces grae e e phiques) et la mod´lisation relationnelle (pertinente pour g´rer les donn´es). e e e Par ailleurs, la m´thodologie Merise est certes typiquement fran¸aise, mais en Grande-Bretagne, la e c m´thodologie standard s’appelle SSADM (Structured Systems Analysis ans Design Method) et repose e sur les mˆmes principes. Les nord-am´ricains quant ` eux utilisent ce qu’on appelle des diagrammes de e e a flux, dont les principes sont repris par la version 2 de Merise. Aujourd’hui, ce sont les mod´lisations objets et leur unification UML (Unified Modeling Language, e autrement dit langage unifi´ de mod´lisation) qui se placent ` la pointe de l’´tat de l’art. Malheureusee e a e ment, UML n’est qu’un ensemble de notations (d’ailleurs moins intuitives que celles des sch´mas entit´se e 7 ). La connaissance de ce langage ne permet donc pas au concepteur de faire l’´conomie d’une associations e m´thodologie de conception. Voil` pourquoi il n’est pas anachronique de r´-´diter en 2005 un document e a ee sur des m´thodes qui auront bientˆt 30 ans ;-) e o R´f´rences ee [Akoka et Comyn-Wattiau] Akoka, J. et Comyn-Wattiau I. Conception de bases de donn´es relatione nelles. Vuibert Informatique. Ce livre tr`s didactique contient de bon exercices sur la phase de conception d’un syst`me d’ine e formation. [Gabay] Gabay, J. Apprendre et pratiquer Merise. Masson, 1989. Ce livre tr`s synth´tique permet de s’exercer sur la m´thode. e e e [Matheron] Matheron, J.-P. Comprendre Merise. Eyrolles, 1994. Cet ouvrage tr`s accessible permet vraiment de comprendre la m´thode. e e [Nanci et al.] Nanci, D., Espinasse, B., Cohen, B. et Heckenroth, H. Ing´nierie des syst`mes d’ine e formation avec Merise. Sybex, 1992. Cet ouvrage complet d´taille la m´thode dans son ensemble. e e [Panet et al.] Panet, G., Letouche, R. et Tardieu, H. Merise/2 : Mod`les et techniques Merise e ´ avanc´s. Edition d’organisation, 1994. e Ce livre d´crit la version 2 de la m´thode. e e [Tardieu et al.] Tardieu, H., Rochfeld, A. et Coletti, R. La m´thode Merise. Principes et outils. e ´ Edition d’organisation, 1986. Il s’agit-l` du livre de r´f´rence par les auteurs de la m´thode. a ee e 7. qui sont facilement traduisibles en sch´mas UML, grˆce ` certains outils automatiques e a a www.tifawt.com
  • www.tifawt.com TABLE DES FIGURES 42 Table des figures 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 Entit´s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Attributs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identifiants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cardinalit´s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Associations plurielles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Association r´flexive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Entit´ rempla¸able par une association ternaire . . . . . . . . . . . . . . . . . . . . . . . . e c Contre-exemple : l’entit´ d´parts n’est pas rempla¸able par une association ternaire . . . e e c Exemple d’entit´ quaternaire ou 4-aire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Contre-exemples de la normalisation des noms . . . . . . . . . . . . . . . . . . . . . . . . . Contre-exemples de la normalisation des attributs . . . . . . . . . . . . . . . . . . . . . . . Normalisation des attributs des associations . . . . . . . . . . . . . . . . . . . . . . . . . . Cardinalit´ 1,1 et attributs d’une association . . . . . . . . . . . . . . . . . . . . . . . . . e Contre-exemples de la normalisation des associations . . . . . . . . . . . . . . . . . . . . . Application de la premi`re forme normale : il peut y avoir plusieurs auteurs pour un livre e donn´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Application de la troisi`me forme normale de Boyce-Codd . . . . . . . . . . . . . . . . . . e D´pendance fonctionnelle non ´l´mentaire, mais directe . . . . . . . . . . . . . . . . . . . e ee Graphe de couverture minimale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identification des entit´s et des associations sur un graphe de couverture minimale . . . . e Sch´ma entit´s-associations normalis´ obtenu ` partir du graphe de couverture minimale . e e e a Sans historisation des emprunts, pas de probl`me . . . . . . . . . . . . . . . . . . . . . . . e Mˆme pour une entit´ historis´e, il vaut mieux ´viter que la date n’entre dans l’identifiant e e e e D´pendances fonctionnelles comment´es . . . . . . . . . . . . . . . . . . . . . . . . . . . . e e Utilisation d’une d´pendance non ´l´mentaire et sans enfant sur un graphe de couverture e ee minimal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sch´ma relationnel simple entre deux tables . . . . . . . . . . . . . . . . . . . . . . . . . . e Traduction d’une association de type 1 : n . . . . . . . . . . . . . . . . . . . . . . . . . . . Traduction d’une association de type n : m . . . . . . . . . . . . . . . . . . . . . . . . . . . Traduction d’une association de type 1 : 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . Traduction alternative d’une association de type 1 : 1 . . . . . . . . . . . . . . . . . . . . . Traduction d’une association ternaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sacrifice de la troisi`me forme normale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Tables particuli`res en r´tro-conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . e e Association binaire de type 1 : n (monter), li´e ` une association binaire de type n : m e a (participer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Association ternaire remplac´e par deux associations binaires . . . . . . . . . . . . . . . . e Association binaire de type n : m (parier), li´e ` une autre association binaire de type n : m e a Agr´gation et entit´s de codification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e e Utilisation de cl´s primaires partiellement ´trang`res . . . . . . . . . . . . . . . . . . . . . e e e Repr´sentation des identifiants relatifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Repr´sentation des identifiants relatifs sur le graphe de couverture minimale . . . . . . . . e Num´rotations alternatives des exemplaires . . . . . . . . . . . . . . . . . . . . . . . . . . e Repr´sentation des sous-entit´s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e e S´paration des informations compl´mentaires par h´ritage . . . . . . . . . . . . . . . . . . e e e Sp´cialisation des associations en pr´sence de sous-entit´s . . . . . . . . . . . . . . . . . . e e e www.tifawt.com 4 4 5 5 6 7 7 8 9 9 10 11 12 12 13 14 15 16 17 17 18 18 19 20 20 23 24 25 25 26 26 27 29 31 32 33 34 35 36 36 37 38 39 40
  • www.tifawt.com INDEX 43 Index A transitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 diagramme de flux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 agr´gation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 e doublon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 aspiration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4-aire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 enregistrement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 binaire e e de type 1 : 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 entier auto-incr´ment´ . . . . . . . . . . . . . . . . . . . . . . . . . .11 entit´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 e de type 1 : n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 de codification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 de type n : m. . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 de r´f´rence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 ee en plusieurs exemplaires . . . . . . . . . . . . . . . . . . . . 13 des dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 fantˆme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 o rempla¸able . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 c plurielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 redondante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 e r´flexive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 exemplaires (num´rotation) . . . . . . . . . . . . . . . . . . . . 37 e sp´cialis´e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 exhaustif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 e e E F ternaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 attribut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 calculable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 factorisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 en plusieurs exemplaires . . . . . . . . . . . . . . . . . . . . 11 fichier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 e e imaginaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12, 20 fl`che pleine ou en pointill´s . . . . . . . . . . . . . . . . . . . . 36 forme normale deuxi`me . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 e premi`re . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 e cardinalit´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6, 24 e troisi`me de Boyce-Codd . . . . . . . . . . . . . . . . . . . 15 e maximale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 minimale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6, 14 question. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 ternaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 g´n´ricit´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 e e e cl´ e graphe de couverture minimale . . . . . . . . . . . . . . . . . 17 ´trang`re . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 e e particuli`re . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 e primaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 e Codasyl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 h´ritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 e coh´rence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5, 27 hi´rarchique (SGBD) . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 e historisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 colonne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 e e e commentaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 homog´n´it´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 C G H contrainte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 conversion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 I D identifiant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5, 11 relatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 incoh´rence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10, 11, 15 e incr´mentation automatique . . . . . . . . . . . . . . . . . . . . 11 e index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 int´grit´ r´f´rentielle . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 e e ee intitul´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 e it´ration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 e date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 d´clencheur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14, 32 e d´pendance fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . 16 e directe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 non ´l´mentaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 ee vers un identifiant. . . . . . . . . . . . . . . . . . . . . . . .30 non ´l´mentaire ee sans enfant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 jointure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 externe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 plurielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 r´flexive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 e J www.tifawt.com
  • www.tifawt.com INDEX 44 L SSADM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 symbole ∞ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 lien identifiant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 synonyme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 ligne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 syst`me d’information . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 e lisibilit´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 e M T maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 d’informations compl´mentaires . . . . . . . . . . . . 39 e MCD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 de codification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Merise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3, 41 de jonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3, 25 version 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 de r´f´rence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 ee MLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 des dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 MLDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 taille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 MPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 traduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17, 18 transitivit´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 e type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 navigationnel (SGBD) . . . . . . . . . . . . . . . . . . . . . . . . . . 22 N normalisation des associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 des attributs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 des associations . . . . . . . . . . . . . . . . . . . . . . . . . . 12 des cardinalit´s . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 e des entit´s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10, 19 e des identifiants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 des noms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 NULL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 O optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 orient´ objet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22, 41 e P performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 polys`me . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 e R redondance . . . . . . . . . . . . . . . . . . . . . . 10, 13, 15, 21, 27 r´f´rence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 ee relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 requˆte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 e r´seau (SGBD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 e r´tro-conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 e reverse engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 S sch´ma e entit´s-associations . . . . . . . . . . . . . . . . . . . . . . . . . . 6 e relationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 SGBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3, 22 SGBDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 sous-entit´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 e sp´cialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38, 40 e SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 www.tifawt.com U UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 unicit´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25, 28 e V vacuit´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 e vide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23