Initiation Merise

Initiation la conception de bases de donnes relationnelles avec MERISE
par Idriss NEUMANN Erielle
Date de publication : 28 fvrier 2012 Dernire mise jour : 17 octobre 2012
Ce cours est conu pour ceux qui souhaitent s'initier rapidement la conception d'une base de donnes relationnelle l'aide de la mthode d'analyse MERISE. Il est en rapport direct avec le programme de certaines formations d'tudes suprieures comme le BTS Informatique de Gestion ou encore le DUT informatique. Vous pouvez commenter l'article en suivant ce lien :
Initiation la conception de bases de donnes relationnelles avec MERISE par Idriss NEUMANN
Erielle
I - MERISE au service des systmes d'information....................................................................................................3 I-A - Le systme d'information............................................................................................................................... 3 I-B - MERISE..........................................................................................................................................................3 II - Modlisation d'une base de donnes au niveau conceptuel.................................................................................3 II-A - Les rgles de gestion mtiers...................................................................................................................... 4 II-B - Le dictionnaire des donnes.........................................................................................................................4 II-C - Les dpendances fonctionnelles.................................................................................................................. 7 II-D - Le Modle Conceptuel de Donnes (MCD)................................................................................................. 8 II-D-1 - Les entits............................................................................................................................................ 8 II-D-2 - Les associations...................................................................................................................................9 II-D-3 - laboration du MCD...........................................................................................................................10 III - Modlisation d'une base de donnes au niveau logique et passage au SQL.................................................... 12 III-A - Le passage du MCD au MLD et SQL....................................................................................................... 12 III-A-1 - Les relations...................................................................................................................................... 12 III-A-2 - Rgles de conversion........................................................................................................................13 III-A-2-a - Rgle 1 - conversion d'une entit.............................................................................................13 III-A-2-b - Rgle 2 - conversion d'associations n'ayant que des cardinalits de type 0/1,N......................13 III-A-2-c - Rgle 3 - conversion des associations ayant au moins une cardinalit de type 1,1................. 14 III-A-2-d - Rgle 4 - conversion des associations ayant au moins une cardinalit de type 0,1 (et dont les autres cardinalits sont de type 0,1/N)..................................................................................................... 15 III-A-3 - laboration du MLD et passage au SQL.......................................................................................... 16 III-B - Rgles de vrification des niveaux de normalisation................................................................................ 18 III-C - Cas particuliers.......................................................................................................................................... 18 III-C-1 - Les associations rflexives............................................................................................................... 18 III-C-2 - Rgle de conversion exceptionnelle pour certaines entits simples.................................................20 IV - Les extensions apportes par MERISE II.......................................................................................................... 20 IV-A - L'identification relative................................................................................................................................20 IV-B - L'hritage et ses limites.............................................................................................................................21 IV-B-1 - L'hritage par disjonction (ou exclusion).......................................................................................... 23 IV-B-2 - L'hritage par couverture (ou totalit)...............................................................................................24 IV-B-3 - L'hritage par partition (totalit et exclusion).................................................................................... 25 IV-B-4 - Passage au niveau relationnel et limites.......................................................................................... 25 IV-C - Les contraintes entre associations............................................................................................................26 IV-C-1 - La contrainte d'inclusion................................................................................................................... 26 IV-C-2 - La contrainte d'exclusion.................................................................................................................. 27 IV-C-3 - La contrainte de totalit.................................................................................................................... 27 IV-C-4 - La contrainte d'galit.......................................................................................................................27 IV-C-5 - Combinaison entre contraintes......................................................................................................... 28 IV-D - Les CIF (contraintes d'intgrits fonctionnelles) et agrgations................................................................28 V - Conclusion........................................................................................................................................................... 30 VI - Remerciements................................................................................................................................................... 30
-2Copyright 2012 Idriss NEUMANN. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts. Cette page est dpose la SACD.
http://ineumann.developpez.com/tutoriels/merise/initiation-merise/
Erielle
I - MERISE au service des systmes d'information I-A - Le systme d'information

Le systme d'information ou SI, peut tre dfini comme tant l'ensemble des moyens humains, matriels et immatriels mis en uvre afin de grer l'information au sein d'une unit, une entreprise par exemple. Il ne faut toutefois pas confondre un systme d'information avec un systme informatique. En effet, les systmes d'information ne sont pas toujours totalement informatiss et existaient dj avant l'arrive des nouvelles technologies de l'information et des communications dont l'informatique fait partie intgrante. Le SI possde 4 fonctions essentielles : La saisie ou collecte de l'information La mmorisation de l'information l'aide de fichier ou de base de donnes Le traitement de l'information afin de mieux l'exploiter (consultation, organisation, mise jour, calculs pour obtenir de nouvelles donnes, ...) La diffusion de l'information
Autrefois, l'information tait stocke sur papier l'aide de formulaires, de dossiers, et il existait des procdures manuelles pour la traiter. Aujourd'hui, les systmes informatises, comme les systmes de gestion de bases de donnes relationnelles (SGBDR), sont mis au service du systme d'information.
I-B - MERISE
MERISE est une mthode franaise ne dans les annes 70, dveloppe initialement par Hubert Tardieu. Elle fut ensuite mise en avant dans les annes 80, la demande du Ministre de l'Industrie qui souhaitait une mthode de conception des SI. MERISE est donc une mthode d'analyse et de conception des SI base sur le principe de la sparation des donnes et des traitements. Elle possde un certain nombre de modles (ou schmas) qui sont rpartis sur 3 niveaux : Le niveau conceptuel, Le niveau logique ou organisationnel, Le niveau physique.
Dans ce cours, nous ne nous intresserons qu' certains schmas permettant la conception d'une base de donnes relationnelle puis sa ralisation sur un SGBDR.
II - Modlisation d'une base de donnes au niveau conceptuel

Il s'agit de l'laboration du modle conceptuel des donnes (MCD) qui est une reprsentation graphique et structure des informations mmorises par un SI. Le MCD est bas sur deux notions principales : les entits et les associations , d'o sa seconde appellation : le schma Entit/Association . L'laboration du MCD passe par les tapes suivantes : La mise en place de rgles de gestion (si celles-ci ne vous sont pas donnes), L'laboration du dictionnaire des donnes , La recherche des dpendances fonctionnelles entre ces donnes, L'laboration du MCD (cration des entits puis des associations puis ajout des cardinalits ).
Erielle
II-A - Les rgles de gestion mtiers

Avant de vous lancer dans la cration de vos tables (ou mme de vos entits et associations pour rester dans un vocabulaire conceptuel), il vous faut recueillir les besoins des futurs utilisateurs de votre application. Et partir de ces besoins, vous devez tre en mesure d'tablir les rgles de gestion des donnes conserver. Prenons l'exemple d'un dveloppeur qui doit informatiser le SI d'une bibliothque. On lui fixe les rgles de gestion suivantes : Pour chaque livre, on doit connatre le titre, l'anne de parution, un rsum et le type (roman, posie, science fiction, ...). Un livre peut tre rdig par aucun (dans le cas d'une uvre anonyme), un ou plusieurs auteurs dont on connat le nom, le prnom, la date de naissance et le pays d'origine. Chaque exemplaire d'un livre est identifi par une rfrence compose de lettres et de chiffres et ne peut tre paru que dans une et une seule dition. Un inscrit est identifi par un numro et on doit mmoriser son nom, prnom, adresse, tlphone et adresse e-mail. Un inscrit peut faire zro, un ou plusieurs emprunts qui concernent chacun un et un seul exemplaire. Pour chaque emprunt, on connat la date et le dlai accord (en nombre de jours).
Ces rgles vous sont parfois donnes mais vous pouvez tre amen les tablir vous-mme dans deux cas : Vous tes la fois matrise d'uvre (MOE) et matrise d'ouvrage (MOA), et vous dveloppez une application pour votre compte et/ou selon vos propres directives. Ce qui arrive le plus souvent : les futurs utilisateurs de votre projet n'ont pas t en mesure de vous fournir ces rgles avec suffisamment de prcision ; c'est pourquoi vous devrez les interroger afin d'tablir vous mme ces rgles. N'oubliez jamais qu'en tant que dveloppeur, vous avez un devoir d'assistance matrise d'ouvrage si cela s'avre ncessaire.
II-B - Le dictionnaire des donnes

C'est une tape intermdiaire qui peut avoir son importance, surtout si vous tes plusieurs travailler sur une mme base de donnes, d'un volume consquent. Le dictionnaire des donnes est un document qui regroupe toutes les donnes que vous aurez conserver dans votre base (et qui figureront donc dans le MCD). Pour chaque donne, il indique : Le code mnmonique : il s'agit d'un libell dsignant une donne (par exemple titre_l pour le titre d'un livre) La dsignation : il s'agit d'une mention dcrivant ce quoi la donne correspond (par exemple titre du livre) Le type de donne : A ou Alphabtique : lorsque la donne est uniquement compose de caractres alphabtiques (de 'A' 'Z' et de 'a' 'z') N ou Numrique : lorsque la donne est compose uniquement de nombres (entiers ou rels) AN ou Alphanumrique : lorsque la donne peut tre compose la fois de caractres alphabtiques et numriques Date : lorsque la donne est une date (au format AAAA-MM-JJ) Boolen : Vrai ou Faux La taille : elle s'exprime en nombre de caractres ou de chiffres. Dans le cas d'une date au format AAAA-JJMM, on compte galement le nombre de caractres, soit 10 caractres. Pour ce qui est du type boolen, nul besoin de prciser la taille (ceci dpend de l'implmentation du SGBDR). Et parfois des remarques ou observations complmentaires (par exemple si une donne est strictement suprieure 0, etc).
Erielle
Reprenons l'exemple de notre bibliothque et du systme de gestion des emprunts que nous sommes chargs d'informatiser. Aprs l'tude des rgles de gestion, nous pouvons tablir le dictionnaire des donnes suivant : Code mnmonique id_i Dsignation Type N A A AN A AN AN AN 30 30 50 50 5 15 15 Taille Remarque
Identifiant numrique d'un inscrit nom_i Nom d'un inscrit prenom_i Prnom d'un inscrit rue_i Rue o habite un inscrit ville_i Ville o habite un inscrit cp_i Code postal d'un inscrit tel_i Numro de tlphone fixe d'un inscrit tel_port_i Numro de tlphone portable d'un inscrit email_i Adresse e-mail d'un inscrit date_naissance_i Date de naissance d'un inscrit id_l Identifiant numrique d'un livre titre_l Titre d'un livre annee_l Anne de parution d'un livre resume_l Rsum d'un livre ref_e Code de rfrence d'un exemplaire d'un livre
AN Date N AN N AN AN
100 10 Au format AAAAJJ-MM
50 4 1000 15 Cette rfrence servira galement
Erielle
id_t
Identifiant numrique d'un type de livre libelle_t Libell d'un type de livre id_ed Identifiant numrique d'une dition de livre nom_ed Nom d'une dition de livre id_a Identifiant numrique d'un auteur nom_a Nom d'un auteur prenom_a Prnom d'un auteur date_naissance_aDate de naissance d'un auteur id_p Identifiant numrique d'un pays nom_p Nom d'un pays id_em Identifiant numrique d'un emprunt date_em Date de l'emprunt delais_em Dlai autoris lors de l'emprunt du livre . Remarques :
N AN N AN N A A Date N A N Date N 3 50 30 30 30 6 30
d'identifiant dans ce systme
Au format AAAAJJ-MM
Au format AAAAJJ-MM S'exprime en nombre de jours
Les donnes qui figurent dans le MCD (et donc dans le dictionnaire des donnes) doivent tre, dans la plupart des cas, lmentaires : Elles ne doivent pas tre calcules : les donnes calcules doivent tre obtenues, par le calcul, partir de donnes lmentaires qui, elles, sont conserves en base. Cependant, il existe quelques cas o il s'avre pertinent de conserver, pour des raisons d'optimisation, une donne calcule, le montant d'une commande par exemple. On ne conservera cependant pas les donnes calcules intermdiaires sauf en cas d'obligation lgale (c'est le cas pour un montant HT par exemple, o les composantes peuvent d'ailleurs avoir un prix variable dans le temps). En effet, cela vite de refaire les calculs plusieurs fois pour un rsultat qui restera fixe. Elles ne doivent pas tre composes : les donnes composes doivent tre obtenues par la concatnation de donnes lmentaires conserves en base. Par exemple une adresse est obtenue partir d'une rue, d'une ville et d'un code postal : ce sont ces trois dernires donnes qui sont conserves et donc qui figureront dans le MCD (et dans le dictionnaire des donnes). Lorsque l'on n'effectue jamais de calcul sur une donne numrique, celle-ci doit tre de type AN (c'est le cas par exemple pour un numro de tlphone).
Erielle
II-C - Les dpendances fonctionnelles

Soit deux proprits (ou donnes) P1 et P2. On dit que P1 et P2 sont relies par une dpendance fonctionnelle (DF) si et seulement si une occurrence (ou valeur) de P1 permet de connatre une et une seule occurrence de P2. Cette dpendance est reprsente comme ceci : P1 P2 On dit que P1 est la source de la DF et que P2 en est le but . Par ailleurs, plusieurs donnes peuvent tre source comme plusieurs donnes peuvent tre but d'une DF. Exemples : P1,P2 P3 P1 P2,P3 P1, P2 P3,P4,P5 En reprenant les donnes du dictionnaire prcdent, on peut tablir les DF suivantes : id_em date_em, delais_em, id_i, ref_e id_i nom_i, prenom_i, rue_i, ville_i, cp_i, tel_i, tel_port_i, email_i, date_naissance_i ref_e id_l id_l titre_l, annee_l, resume_l, id_t, id_ed id_t libelle_t id_ed nom_ed id_a nom_a, prenom_a, date_naissance_a, nom_p On peut dduire les conclusions suivantes de ces DF : partir d'un numro d'emprunt, on obtient une date d'emprunt, un dlai, l'identifiant de l'inscrit ayant effectu l'emprunt, la rfrence de l'exemplaire emprunt. partir d'une rfrence d'exemplaire, on obtient l'identifiant du livre correspondant. partir d'un numro de livre, on obtient son titre, son anne de parution, un rsum, l'identifiant du type correspondant, son numro d'dition. ...
Remarque : Une DF doit tre : lmentaire : C'est l'intgralit de la source qui doit dterminer le but d'une DF. Par exemple si P1 P3 alors P1,P2 P3 n'est pas lmentaire. directe : La DF ne doit pas tre obtenue par transitivit. Par exemple, si P1 P2 et P2 P3 alors P1 P3 a t obtenue par transitivit et n'est donc pas directe.
Conclusion : Les DF qui existent entre les donnes sont parfois videntes et ne ncessitent pas toujours une modlisation mais celle-ci peut s'avrer utile car elle permet, entre autres, de distinguer les futures entits du MCD et leur identifiants.
Erielle
II-D - Le Modle Conceptuel de Donnes (MCD) II-D-1 - Les entits

Chaque entit est unique et est dcrite par un ensemble de proprits encore appeles attributs ou caractristiques. Une des proprits de l'entit est l'identifiant. Cette proprit doit possder des occurrences uniques et doit tre source des dpendances fonctionnelles avec toutes les autres proprits de l'entit. Bien souvent, on utilise une donne de type entier qui s'incrmente pour chaque occurrence, ou encore un code unique spcifique du contexte. Le formalisme d'une entit est le suivant :
Ainsi, si on reprend notre dictionnaire de donnes prcdent, on schmatise par exemple une entit Auteur comme ceci :
partir de cette entit, on peut retrouver la rgle de gestion suivante : un auteur est identifi par un numro unique (id_a) et est caractris par un nom, un prnom et une date de naissance. Une entit peut n'avoir aucune, une ou plusieurs occurrences. Pour illustrer ce terme d'occurrence qui a dj t utilis plusieurs fois, voici un exemple de table d'occurrences de l'entit Auteur : id_a nom_a Hugo Rimbaud de Maupassant prenom_a Victor Arthur Guy date_naissance_a 1802-02-26 1854-10-20 1850-08-05
1 2 3
Cette table est compose de trois occurrences de l'entit Auteur . Remarques : Les occurrences sont parfois appels tuples . Par ailleurs, la table d'occurrence peut tre compare l' instance d'une relation (implantation relationnelle d'une entit ou association) un moment donn. Nous reviendrons sur cette notion de relation dans la partie III. Au niveau conceptuel, on devrait plutt parler d' entits-types , les entits tant en fait des instances d'entits-types. Par soucis de simplicit, on gardera les termes d'entits et associations tout au long du cours.
Erielle
II-D-2 - Les associations

Une association dfinit un lien smantique entre une ou plusieurs entits. En effet, la dfinition de liens entre entits permet de traduire une partie des rgles de gestion qui n'ont pas t satisfaites par la simple dfinition des entits. Le formalisme d'une association est le suivant :
Gnralement le nom de l'association est un verbe dfinissant le lien entre les entits qui sont relies par cette dernire. Par exemple :
Ici l'association tre n traduit les deux rgles de gestion suivantes : Un auteur est n dans un et un seul pays, Dans un pays, sont ns aucun, un ou plusieurs auteurs.
Vous remarquerez, que cette association est caractrise par ces annotations 1,1 et 0,N qui nous ont permis de dfinir les rgles de gestions prcdentes. Ces annotations sont appeles les cardinalits . Une cardinalit est dfinie comme ceci : minimum, maximum Les cardinalits les plus rpandues sont les suivantes : 0,N ; 1,N ; 0,1 ; 1,1 . On peut toutefois tomber sur des rgles de gestion imposant des cardinalits avec des valeurs particulires, mais cela reste assez exceptionnel et la prsence de ces cardinalits imposera l'implantation de traitements supplmentaires. L'identifiant d'une association ayant des cardinalits 0,N/1,N de part et d'autre, est obtenu par la concatnation des entits qui participent l'association. Imaginons l'association suivante :
Erielle
Ici un auteur rdige au moins un ou plusieurs livres et pour chaque livre, on connat le nombre de chapitres rdigs par l'auteur (on connat aussi le nombre total de chapitres pour chaque livre). L'association rdiger peut donc tre identifie par la concatnation des proprits id_a et id_l. Ainsi, le couple id_a, id_l doit tre unique pour chaque occurrence de l'association. On peut galement dfinir la dpendance fonctionnelle suivante : id_a, id_l nb_chapitres On dit que nb_chapitres (nombre de chapitres rdigs par un auteur, pour un livre) est une donne porte par l'association rdiger. Cette association est donc une association porteuse de donnes. Pour une association ayant au moins une cardinalit de type 0,1 ou 1,1 considrons dans un premier temps que cette dernire ne peut tre porteuse de donnes et qu'elle est identifie par l'identifiant de l'entit porteuse de la cardinalit 0,1 ou 1,1. Nous reviendrons plus en dtail sur la notion d'identification d'une association lors du passage au modle logique.
II-D-3 - laboration du MCD

Avec toutes ces connaissances, il nous est donc possible d'laborer le MCD complet partir des donnes prsentes dans le dictionnaire des donnes :
- 10 Copyright 2012 Idriss NEUMANN. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts. Cette page est dpose la SACD.
Erielle
Remarques : Souvent, pour un mme ensemble de rgles de gestion, plusieurs solutions sont possibles au niveau conceptuel. Par exemple, rien ne nous obligeait ici crer une entit Type . Une simple donne porte par l'entit Livre aurait pu convenir galement. Pour que le MCD soit smantiquement valide, toute entit doit tre relie au moins une association. Les entits et les proprits peuvent tre historises. Dans ce cas on met un (H) la fin du nom de l'entit ou de la proprit que l'on souhaite historiser (cela permet de prciser que l'on archivera toutes les modifications sur une entit ou une proprit donne). Cela doit galement rpondre une rgle de gestion. Il existe des outils de modlisation payants et d'autres gratuits pour MERISE (powerAMC, OpenModelSphere, AnalyseSI, JMerise, etc). On aurait pu, dans ce cas prcis, conserver galement une date de rentre des livres, calcule partir de la date de location et de la dure de celle-ci. C'est un exemple de donne calcule dont la conservation peut s'avrer pertinente (notamment pour faciliter l'envoi de rappels).
Erielle
III - Modlisation d'une base de donnes au niveau logique et passage au SQL

Dans cette partie, nous allons voir comment tablir une modlisation des donnes au niveau logique (ou relationnel) partir d'un modle conceptuel, puis comment passer l'tape de cration des tables (cela suppose d'avoir une connaissance pralable des requtes SQL de cration de tables).
III-A - Le passage du MCD au MLD et SQL III-A-1 - Les relations

Le modle logique de donnes (MLD) est compos uniquement de ce que l'on appelle des relations . Ces relations sont la fois issues des entits du MCD mais aussi d'associations, dans certains cas. Ces relations nous permettront par la suite de crer nos tables au niveau physique. Une relation est compose d'attributs. Ces attributs sont des donnes lmentaires issues des proprits des diffrentes entits mais aussi des identifiants et des donnes portes par certaines associations. Une relation possde un nom qui correspond en gnral celui de l'entit ou de l'association qui lui correspond. Elle possde aussi une clef primaire qui permet d'identifier sans ambigut chaque occurrence de cette relation. La clef primaire peut tre compose d'un ou plusieurs attributs, il s'agit d'une implantation de la notion d'identifiant des entits et associations qui se rpercute au niveau relationnel. Voici un premier exemple de relation (issue de l'entit Edition de notre prcdant MCD) : Edition ( id_ed , nom_ed) Lgende : x : relation x : clef primaire Remarques : Ce premier MLD est reprsent de manire textuelle. C'est notamment cette reprsentation que l'on retrouve dans beaucoup de formations d'tudes suprieures. Il existe toutefois une reprsentation graphique quivalente. Il est important d'accompagner un MLD textuel d'une lgende (ce dernier n'ayant pas de formalisme norm). Ceci est d'ailleurs exig dans certaines formations.
Il existe un autre type de clef appel clef trangre . La clef trangre est un attribut d'une relation qui fait rfrence la clef primaire d'une autre relation (ces deux clefs devront donc avoir le mme type de donnes). Compltons notre premier exemple avec une autre relation o apparat une clef trangre : Edition ( id_ed , nom_ed) Exemplaire ( ref_e , id_ed #) Lgende : x : relation x : clef primaire x # : clef trangre Remarques : Au niveau relationnel, on devrait plutt parler de clef candidate qui permet d'identifier sans ambigut une occurrence de la relation pour les clefs primaires. De mme, on devrait dsigner une clef trangre par
Erielle
une contrainte d'inclusion vers une clef candidate. Par souci de simplicit, on gardera les termes de clefs primaires et trangres. Par convention, on fait prcder ou suivre la clef trangre du symbole #. Ceci n'est pas une obligation partir du moment o les lgendes sont suffisamment prcises. Ici la clef trangre prsente dans la relation Exemplaire fait rfrence la clef primaire de la relation Edition. Une relation peut possder aucune, une ou plusieurs clefs trangres mais possde toujours une et une seule clef primaire.
Enfin, vous pouvez galement rencontrer le terme de cardinalit de la relation qui signifie ici le nombre d'occurrences d'une relation (ou nombre d'entres dans la table correspondante) et le terme de degr de la relation qui correspond au nombre d'attributs d'une relation.
III-A-2 - Rgles de conversion

Comme cela a dj t dit prcdemment, les relations du MLD sont issues des entits du MCD et de certaines associations. Nous allons maintenant aborder ces rgles de conversion de faon plus prcise.
III-A-2-a - Rgle 1 - conversion d'une entit

En rgle gnrale, toute entit du MCD devient une relation dont la clef est l'identifiant de cette entit. Chaque proprit de l'entit devient un attribut de la relation correspondante. Il existe toutefois quelques cas particuliers que vous pourrez voir au paragraphe III.C.2 .
III-A-2-b - Rgle 2 - conversion d'associations n'ayant que des cardinalits de type 0/1,N
Une association ayant des cardinalits 0,N ou 1,N de part et d'autre devient une relation dont la clef est constitue des identifiants des entits relies par cette association. Ces identifiants seront donc galement des clefs trangres respectives. On parle de relations associatives . Les cardinalits plus restrictives (comme 2,3 ; 1,7 ; ...) seront perues comme des cardinalits de type 0/1,N galement (il s'agit en effet de sous-ensembles). Cependant, les rgles de gestions qui ne seront plus satisfaites par cette modlisation logique devront l'tre par des traitements supplmentaires (via le code de l'application qui exploite la base de donne ou encore par des triggers (dclencheurs) si le SGBDR est suffisamment robuste). Voici un exemple de relation associative issu de l'association rdiger de notre MCD : Rediger ( id_a Lgende : x : relation x : clef primaire x # : clef trangre Dans le cas d'associations porteuses de donnes, les donnes portes deviennent des attributs de la relation correspondante. Si l'on reprend cet exemple : #, id_l # )
Erielle
L'association rdiger devrait maintenant tre traduite comme ceci : Rediger ( id_a #, Lgende : x : relation x : clef primaire x # : clef trangre id_l # , nb_chapitres)
III-A-2-c - Rgle 3 - conversion des associations ayant au moins une cardinalit de type 1,1
Plusieurs possibilits s'offrent nous pour ce cas de figure. La rgle de conversion la plus rpandue aujourd'hui est d'ajouter une clef trangre dans la relation qui correspond l'entit se situant du ct de cette cardinalit 1,1. Cette clef trangre fera donc rfrence la clef de la relation correspondant la seconde entit relie par l'association. Prenons un exemple issu de l'association tre originaire de et des entits Auteur et Pays : Pays ( nom_p ) Auteur ( id_a , nom_a, prenom_a, date_naissance_a, nom_p #) Lgende : x : relation x : clef primaire x # : clef trangre Lorsque l'on applique cette rgle de conversion, deux restrictions s'imposent : L'association ne peut tre porteuse de donnes. Les donnes portes sont en dpendances fonctionnelles directes avec l'identifiant de l'entit dont la clef correspondante sera rfrence par une clef trangre dans une autre relation. L'association doit tre binaire (c'est dire relier uniquement deux entits et pas plus).
Lorsque deux entits sont toutes deux relies avec une cardinalit 1,1 par une mme association, on peut placer la clef trangre de n'importe quel ct. Par convention, on choisit de la placer du ct de la relation correspondant l'entit ayant le plus de liaisons avec les autres. Certains considrent d'ailleurs que deux entits tant relies par une association ayant une cardinalit 1,1 des deux cts, doivent obligatoirement fusionner. Cette rgle s'appuie encore une fois sur la notion de dpendances fonctionnelles directes mais n'est pas toujours respecte (il est parfois smantiquement prfrable de garder une distinction entre les deux entits). Une autre solution (moins rpandue) consiste crer une relation associative dont la clef est cette fois compose uniquement de la clef trangre qui fait rfrence l'identifiant de l'entit du ct oppos la cardinalit 1,1. Si on reprend le mme exemple, voici ce que l'on devrait obtenir : Pays ( nom_p ) Auteur ( id_a , nom_a, prenom_a, date_naissance_a) EtreOriginaireDe ( id_a # , nom_p #)
Erielle
Lgende : x : relation x : clef primaire x # : clef trangre Dans ce cas, l'association peut tre porteuse de donnes. Ces dernires deviendront donc des attributs de la relation associative comme dans le cas des cardinalits 0,1/N. Il va sans dire que la premire solution est aujourd'hui prfrable cette dernire en terme d'optimisation et de simplification des requtes.
III-A-2-d - Rgle 4 - conversion des associations ayant au moins une cardinalit de type 0,1 (et dont les autres cardinalits sont de type 0,1/N)
De mme que pour les cardinalits 1,1, une association ayant une cardinalit 0,1 doit tre binaire, et les deux mmes possibilits s'offrent nous : Crer la clef trangre dans la relation correspondant l'entit du ct de la cardinalit 0,1. Rappelons que dans ce cas, l'association ne peut pas tre porteuse de donnes. Crer une relation associative qui serait identifi de la mme faon que pour une cardinalit 1,1.
Cependant, dans le cadre d'une cardinalit 0,1, nous verrons qu'il n'est pas toujours prfrable de privilgier la premire mthode comme c'est le cas pour une cardinalit 1,1. Imaginons par exemple qu'un livre puisse appartenir 0 ou 1 catgories, on obtient le MCD suivant :
Certains diront que toutes les associations binaires de type pre-fils ayant des cardinalits 1,N/0,N - 1,1/0,1 sont caractrises par l'existence d'une dpendance fonctionnelle entre l'identifiant de l'entit pre (ici id_cat) et de l'entit fils (ici id_l). Cette dpendance fonctionnelle se schmatiserait ainsi : id_l id_cat Dans ce cas, il apparat logique de traduire le MCD de cette faon (premire mthode) : Categorie ( id_cat , libelle_cat) Livre (id _l , titre_l, annee_l, resume_l, id_cat #) Lgende : x : relation x : clef primaire x # : clef trangre Cependant mme si les SGBD le permettent (avec la valeur NULL par dfaut), il n'est normalement pas permis d'avoir une clef trangre sans valeur pour laquelle on retrouverait l'occurrence dans la relation sur laquelle on fait rfrence. C'est pourquoi d'autres pensent (avec raison) qu'il vaut mieux crer une relation associative de cette manire (seconde mthode) :
Erielle
Categorie ( id_cat , libelle_cat) Livre ( id_l , titre_l, annee_l, resume_l) Appartenir ( id_l #, id_cat #) Lgende : x : relation x : clef primaire x # : clef trangre La pertinence de l'une ou l'autre mthode varie en fonction du nombre d'occurrences caractrises par la cardinalit 0 ou la cardinalit 1. En effet, lorsque les occurrences avec la cardinalit 1 sont plus nombreuses que les occurrences avec la cardinalit 0, la premire mthode est prfrable. Dans le cas contraire, c'est la seconde mthode qui est la plus adapte. Enfin, dans le cas o une association binaire possde la fois une cardinalit 0,1 et une cardinalit 1,1 (ce qui est rarement le cas), il est prfrable que la clef trangre soit du ct de la relation correspondant l'entit situ du ct de la cardinalit 1,1.
III-A-3 - laboration du MLD et passage au SQL

Avec ces diffrentes rgles de conversion, il nous est dj possible de convertir notre MCD au complet : Pays ( id_p , nom_p) Auteur ( id_a , nom_a, prenom_a, date_naissance_a, id_p #) TypeLivre ( id_t , libelle_t) Livre ( id_l , titre_l, annee_l, resume_l, id_t #) Rediger ( id_a #, id_l # ) Edition ( id_ed , nom_ed) Exemplaire ( ref_e , id_ed #, id_l #) Inscrit ( id_i , nom_i, prenom_i, date_naissance_i, rue_i, ville_i, cp_i, email_i, tel_i, tel_portable_i) Emprunt (id_em, date_em, delais_em, id_i #, ref_e #) Lgende : x : relation x : clef primaire x # : clef trangre Comme vous pouvez le constater, le schma de la base est dj fait. Les rgles de passage au SQL sont assez simples : chaque relation devient une table chaque attribut de la relation devient une colonne de la table correspondante chaque clef primaire devient une PRIMARY KEY chaque clef trangre devient une FOREIGN KEY
Voici ce que cela donnerait :

CREATE TABLE Pays ( id_p INT NOT NULL, nom_p VARCHAR(50), PRIMARY KEY (id_p) ); CREATE TABLE Auteur ( id_a INT NOT NULL, nom_a VARCHAR (30), prenom_a VARCHAR (30), date_naissance_a DATE, id_p INT NOT NULL, FOREIGN KEY (id_p) REFERENCES Pays(id_p),
Initiation la conception de bases de donnes relationnelles avec MERISE par Idriss NEUMANN PRIMARY KEY (id_a)
Erielle
);
CREATE TABLE TypeLivre ( id_t INT NOT NULL, libelle_t VARCHAR (30), PRIMARY KEY (id_t) ); CREATE TABLE Livre ( id_l INT NOT NULL, titre_l VARCHAR (254), annee_l VARCHAR (4), resume_l TEXT, id_t INT NOT NULL, FOREIGN KEY (id_t) REFERENCES TypeLivre(id_t), PRIMARY KEY (id_l) ); CREATE TABLE Rediger ( id_a INT NOT NULL, id_l INT NOT NULL, FOREIGN KEY (id_a) REFERENCES Auteur(id_a), FOREIGN KEY (id_l) REFERENCES Livre (id_l), PRIMARY KEY (id_a, id_l) ); CREATE TABLE Edition ( id_ed INT NOT NULL, nom_ed VARCHAR (254), PRIMARY KEY (id_ed) ); CREATE TABLE Exemplaire ( ref_e VARCHAR(254) NOT NULL, id_ed INT NOT NULL, id_l INT NOT NULL, FOREIGN KEY (id_ed) REFERENCES Edition (id_ed), FOREIGN KEY (id_l) REFERENCES Livre(id_l), PRIMARY KEY (ref_e) ); CREATE TABLE Inscrit ( id_i INT NOT NULL, nom_i VARCHAR (30), prenom_i VARCHAR (30), date_naissance_i DATE, rue_i VARCHAR(50), ville_i VARCHAR(50), cp_i VARCHAR (5), tel_i VARCHAR(15), tel_portable_i VARCHAR(15) , email_i VARCHAR(100), PRIMARY KEY (id_i) ); CREATE TABLE Emprunt ( id_em INT NOT NULL, date_em DATE, delais_em INT DEFAULT 0, id_i INT NOT NULL, ref_e VARCHAR (254) NOT NULL, FOREIGN KEY (id_i) REFERENCES Inscrit(id_i), FOREIGN KEY (ref_e) REFERENCES Exemplaire(ref_e), PRIMARY KEY (id_em) );
Remarque : Il est possible de ne pas avoir grer l'incrmentation des identifiants par soi-mme lors des INSERT avec la plupart des SGBD. Exemple d'auto-incrmentation sous MySQL :
Initiation la conception de bases de donnes relationnelles avec MERISE par Idriss NEUMANN CREATE TABLE TypeLivre ( id_t INT AUTO_INCREMENT, libelle_t VARCHAR (30), PRIMARY KEY (id_t) );
Erielle
Sous PostgreSQL :
CREATE TABLE TypeLivre ( id_t SERIAL, libelle_t VARCHAR (30), PRIMARY KEY (id_t) );
SERIAL crera implicitement une squence qui s'incrmente avec un pas de 1. Sous Oracle, il faudrait crer soimme cette squence.
III-B - Rgles de vrification des niveaux de normalisation

Il existe diffrents niveaux de normalisation (ou formes normales). Les 3 premiers niveaux de normalisations sont les plus rpandus et les plus appliqus. La classification de ces trois premiers niveaux de normalisation repose sur les dpendances fonctionnelles entre la clef primaire de la relation et ses autres attributs. Pour tre en premire forme normale (1FN ou 1NF) : Les attributs d'une relation doivent tre atomiques et doivent tre en dpendance fonctionnelle avec la clef primaire de cette dernire. Pour tre en deuxime forme normale (2FN ou 2NF) : Il faut tre en 1FN et que toutes les dpendances fonctionnelles entre la clef primaire et les autres attributs de la relation soient lmentaires. Autrement dit, les attributs doivent dpendre de la totalit de la clef. Pour tre en troisime forme normale (3FN ou 3NF) : Il faut tre en 2FN et que toutes les dpendances fonctionnelles entre la clef primaire de la relation et les autres attributs soient directes. Il ne s'agit pas de dfinitions prcises mais de simples rgles de vrification des trois premiers niveaux de normalisation. Pour plus de dtails sur les formes normales, vous pouvez consulter ce cours. Remarques : Pour que le MLD soit valide, il faut que chacune de ses relations soit au moins en 3FN. Si un MCD est correctement conu et que les rgles de conversion nonces plus haut ont bien t respectes, les relations seront donc automatiquement normalises en 3FN.
III-C - Cas particuliers III-C-1 - Les associations rflexives

Il est possible de relier une entit elle mme par une association, on parle dans ce cas l d' association rflexive. Imaginons que l'on veuille connatre les inscrits qui sont maris entre eux tout en conservant leur date de mariage, voici ce que l'on obtiendrait au niveau conceptuel :
Erielle
Dans ce cas, c'est la mme rgle qui s'applique pour la conversion d'une association ayant des cardinalits de type 0/1,N de part et d'autres. Il faudra cependant diffrencier les noms des clefs trangres de la table associative correspondantes tout en rfrenant la mme clef primaire : Inscrit ( id_i , nom_i, prenom_i, date_naissance_i, rue_i, ville_i, cp_i, email_i, tel_i, tel_portable_i) EtreMarie ( id_epoux #, id_epouse # , date_mariage_i) Lgende : x : relation x : clef primaire x # : clef trangre On aurait pu choisir des cardinalits 1,1 et mettre la date de mariage comme donne de l'entit Inscrit. Ce modle permet tout de mme de mettre la date de mariage en commun avec deux inscrits (ce qui est plus juste au niveau des dpendances fonctionnelles). Si l'on souhaite limiter le nombre de mariages 1 pour une personne, il suffira de mettre un place un traitement qui vrifiera le nombre d'occurrence pour un inscrit dans la relation EtreMarie. Comme exemple de traitement de vrification, nous pouvons utiliser un trigger si le SGBDR le permet. Voici un exemple de trigger avec une procdure stocke vrifiant la prsence d'une occurrence pour un identifiant donne dans la table EtreMarie :
/* Procdure stocke se chargeant de la vrification */ CREATE OR REPLACE FUNCTION verif_mariage () RETURNS TRIGGER AS $$ DECLARE nb INT; BEGIN SELECT INTO nb COUNT(*) FROM EtreMarie WHERE id_epoux = NEW.epoux OR id_epouse = NEW.id_epouse; IF (nb >= 1) THEN /* Le RAISE EXCEPTION bloquera la suite des traitements dont L'INSERT */ RAISE EXCEPTION 'Mariage impossible !'; END IF; RETURN NEW; END; $$ LANGUAGE plpgsql; /* Trigger qui se dclenchera avant chaque INSERT dans la table EtreMarie */ CREATE TRIGGER t_verif_mariage BEFORE INSERT ON auteur FOR EACH ROW EXECUTE PROCEDURE verif_mariage();
Pour cet exemple, nous avons choisi le langage PL/PgSQL qui est propre au SGBDR PostgreSQL. Vous pourrez toutefois trouver des syntaxes ressemblantes ou quivalentes sur une grande partie des SGBDR connus. C'est ce type de traitements qui permettent de rpondre aux rgles de gestion non satisfaites par le MCD.
Erielle
Ne pas limiter le nombre d'occurrences de cette relation, permettrai en outre de conserver les diffrents mariages des inscrits en cas de divorce (l'intrt est certes trs limit dans le contexte de la gestion des emprunts pour une bibliothque).
III-C-2 - Rgle de conversion exceptionnelle pour certaines entits simples

Dans certains cas, il n'est pas toujours pertinent de convertir une entit au niveau conceptuel, par une relation au niveau logique. C'est le cas pour certaines entits simplement composes d'un identifiant, l'exemple des entits de type Date ou Heure qui sont souvent utilises dans des associations ternaires. Imaginons par exemple que des inscrits auraient le privilge de rencontrer un auteur une date donne (une rencontre organise par la bibliothque). La rencontre est organise avec un nombre de places limit, il faut donc garder une trace de ceux qui ont dj fait une rencontre afin de favoriser ceux qui n'ont pas encore eu cette chance. Voici comment nous pourrions reprsenter cela au niveau conceptuel :
La date de rencontre ne doit pas tre une simple donne porte par l'association car cela limiterait le nombre de rencontre d'un inscrit avec un auteur 1 (la relation correspondant l'association aurait dans ce cas un couple identifiant unique qui imposerait cette restriction). Le fait de crer une relation Date aurait pour incidence de crer de la redondance inutile, c'est pourquoi, il est recommand dans ce cas de figure, de passer au niveau logique de cette faon : Inscrit ( id_i , nom_i, prenom_i, date_naissance_i, rue_i, ville_i, cp_i, email_i, tel_i, tel_portable_i) Auteur ( id_a , nom_a, prenom_a, date_naissance_a, nom_p #) Rencontrer ( id_a #, id_i #, date_rencontre ) Lgende : x : relation x : clef primaire x # : clef trangre
IV - Les extensions apportes par MERISE II IV-A - L'identification relative

Elle intervient lorsque l'identifiant d'une entit ne suffit pas l'identifier de manire unique. Quelques exemples de cas o cela peut arriver :
Erielle
On identifie un immeuble par son numro de rue, or il faut connatre le nom ou l'identifiant de la rue pour trouver l'immeuble (14 rue du gnral Leclerc, ...). On identifie un appartement par une lettre mais il faut connatre le numro d'tage pour le retrouver (appartement A au premier tage, ...). Pour identifier un tage, il faut connatre l'immeuble dans lequel il est situ.
Voici comment on pourrait schmatiser ces rgles de gestions au niveau conceptuel :
Les parenthses autour des cardinalits signifient que les entits du ct de ces cardinalits seront identifies par la concatnation de leurs identifiants (qui ne suffisent pas les identifier de manire unique) avec l'identifiant de l'entit oppose. Ainsi on obtient au niveau relationnel : Rue (code_rue, nom_rue) Immeuble (num_immeuble, code_rue#, nb_etages_total) Etage (num_etage, num_immeuble#, code_rue#, nb_appartements_tot) Appartement (lettre_appartement, num_etage#, num_immeuble#, code_rue#, nb_pieces_total) Lgende : x : relation x : clef primaire x # : clef trangre
IV-B - L'hritage et ses limites

Dsormais, MERISE II permet aussi de modliser l'hritage entre les entits. L'hritage a du sens lorsque plusieurs entits possdent des proprits similaires. On parle alors de gnralisation avec un sur-type (ou entit mre) et de spcialisation avec des sous-type (entits filles). Voici comment on pourrait reprsenter un hritage sur notre MCD :
Erielle
Dans cette partie, les types des proprits apparaissent (ceci est d au logiciel utilis qui est plus adapt pour reprsenter l'hritage). Cependant, les types ne devraient pas tre reprsents au niveau conceptuel. Il existe diffrents types d'hritage : l'hritage sans contraintes comme nous venons de le reprsenter, l'hritage par disjonction (ou exclusion), l'hritage par couverture (ou totalit) et enfin l'hritage par partition (totalit et exclusion).
Erielle
IV-B-1 - L'hritage par disjonction (ou exclusion)
Toutes les occurrences du sur-type ne peuvent se trouver que dans aucun ou un seul sous-type. Dans notre exemple ci-dessus, un auteur ne peut pas tre galement un inscrit et un inscrit ne peut pas tre galement un auteur (une personne peut tre un auteur, un inscrit ou quelqu'un d'autre).
Erielle
IV-B-2 - L'hritage par couverture (ou totalit)
Toutes les occurrences du sur-type se trouvent dans au moins un des sous-type existants. Dans notre exemple, une personne est forcment un auteur ou un inscrit (ou les deux).
Erielle
IV-B-3 - L'hritage par partition (totalit et exclusion)
Il s'agit d'une combinaison des deux hritages prcdents : toutes les occurrences du sur-type se trouvent forcement dans un et un seul des sous-types. Une personne est soit un auteur, soit un inscrit. Cette contrainte est parfois note +.
IV-B-4 - Passage au niveau relationnel et limites

son apparition avec Merise II, l'hritage n'tait pas encore implant sur l'ensemble des SGBDR rpandus (ce n'est d'ailleurs toujours pas le cas aujourd'hui). Il a donc fallu le simuler au point de vue relationnel. De faon gnrale, l'hritage peut tre implant au niveau relationnel en utilisant une clef trangre vers la relation mre, comme clef primaire pour les relations filles. Reprenons notre exemple prcdent : Personne ( id_p , nom_p, prenom_p, date_naissance_p) Inscrit ( id_p # , rue_i, ville_i, cp_i, email_i, tel_i, tel_portable_i) Auteur ( id_p # ) Lgende : x : relation x : clef primaire x # : clef trangre Ainsi pour satisfaire les contraintes de totalit, d'exclusion ou de partition il faudra mettre en place des traitements supplmentaires au niveau de la base de prfrence (triggers, procdures stockes). Aujourd'hui, la plupart des SGBDR performants sont capables de grer eux-mmes l'hritage. C'est notamment le cas avec la clause INHERITS de PostgreSQL. Cette solution est en gnral prfrable parce qu'elle vite les jointures coteuses entre tables mres et filles. En effet les attributs du sur-type seront automatiquement accessibles depuis le sous-type. Par consquent, une insertion, modification ou suppression dans le sous-type se rpercutera galement
Erielle
dans l'entit mre. Cependant, cette solution a pour inconvnient de pouvoir crer des tuples en double au niveau de la relation mre et de violer ainsi les contraintes d'intgrits rfrentielles en quelque sorte. Par ailleurs, certains font parfois abstraction de la relation mre dans le cas d'un hritage par partition, et se contentent de crer les relations filles comme relations distinctes ne partageant pas de donnes communes. Exemple : Auteur ( id_a , nom_a, prenom_a, date_naissance_a) Inscrit ( id_i , nom_i, prenom_i, date_naissance_i, rue_i, ville_i, cp_i, email_i, tel_i, tel_portable_i) Lgende : x : relation x : clef primaire x # : clef trangre Cette solution est galement acceptable mais peut nous amener nous interroger sur la pertinence de l'hritage tant donn que ce dernier n'est pas implant au niveau relationnel. Cependant, la contrainte de partition reste une rgle de gestion satisfaire d'o l'importance de la modlisation de celle-ci au niveau conceptuel. Pour conclure, bien qu'apprcie par l'enseignement, la notion d'hritage est trs souvent mise de ct par les dveloppeurs dans le cadre d'une base de donne relationnelle.
IV-C - Les contraintes entre associations

De mme que pour l'hritage, il existe diffrentes contraintes qui peuvent exister entre deux ou plusieurs associations. Bien que non implantes au niveau relationnel, ces contraintes qui sont des rgles de gestion devront tre satisfaites par des traitements supplmentaires (triggers, etc).
IV-C-1 - La contrainte d'inclusion

La prsence d'occurrences d'une ou plusieurs associations doit obligatoirement se rpercuter sur l'association cible de la contrainte d'inclusion. Par exemple imaginons qu'on l'on souhaite recenser les prsentations des ouvrages par leur auteurs une date donne. Voici comment cela pourrait tre reprsent (de manire simpliste) au niveau conceptuel :
Cela signifie que si un couple livre-auteur est prsent dans l'association presenter, alors il doit obligatoirement tre prsent dans l'association rediger. Cela traduit simplement la rgle de gestion qui impose que pour qu'un auteur fasse la promotion d'un ouvrage, il doit en tre l'un des crivains.
Erielle
IV-C-2 - La contrainte d'exclusion

Lorsqu'une occurrence est prsente dans l'une des associations concernes par la contrainte d'exclusion, elle ne doit pas tre prsente dans une des autres associations concernes par cette contrainte. Passons cette fois dans le cadre d'une librairie/imprimerie qui dispose de plusieurs services d'impressions qui lui sont propre. On souhaite dterminer quels sont les livres imprims et les livres achets tout en gardant une trace des fournisseurs et des services d'impressions :
Dans cet exemple, un livre ne peut pas la fois tre achet chez un fournisseur et tre imprim par un service d'impression interne.
IV-C-3 - La contrainte de totalit

Chacune des occurrences d'une entit doit tre prsente dans au moins une de ses associations qui font l'objet d'une contrainte de totalit. Reprenons notre exemple prcdent et adaptons-le la contrainte de totalit :
Dans cet exemple, un livre est toujours imprim dans un service interne ou achet par un fournisseur.
IV-C-4 - La contrainte d'galit

Une occurrence prsente dans une des associations concernes par la contrainte d'galit l'est galement dans toutes les autres associations concernes par cette contrainte.
Erielle
Prenons l'exemple d'un magasin qui vend des livres et qui souhaite archiver les dpts et les imprimeries du livre :
Un livre achet dans un dpt sera donc galement imprim dans une imprimerie et vice et versa.
IV-C-5 - Combinaison entre contraintes

Comme dans le cadre d'un hritage, il est possible de combiner les contraintes (TI, T=, XT ou + pour la partition, etc). Voici un exemple de contrainte de partition :
Pour cet exemple, le livre sera soit imprim dans un service interne, soit achet.
IV-D - Les CIF (contraintes d'intgrits fonctionnelles) et agrgations

Il s'agit de dpendances fonctionnelles qui sont directement reprsentes sur le MCD afin de rduire les identifiants d'associations jugs trop larges. Ces DF sont des rgles de gestion faire apparatre sur votre schma. Reprenons l'exemple de l'auteur qui fait la promotion de son ouvrage une date donne :
Erielle
Cela se traduit par la dpendance fonctionnelle suivante : id_a, vdate id_l Ainsi, l'association presenter serait implante comme ceci au niveau relationnel : Presenter ( id_a Lgende : x : relation x : clef primaire x # : clef trangre #, vdate , id_l #)
L'identifiant du livre ne fait donc plus partie de la clef primaire afin de garder une dpendance fonctionnelle directe et lmentaire. Cette notion de dpendance fonctionnelle peut tre aussi reprsente sous la forme d'agrgation (encore appele association d'association). Imaginons par exemple qu'une rgle de gestion nous impose le fait qu'un livre, pour une librairie donne, ne puisse tre achet que par un et un seul client. La rgle de gestion serait ici implante par la dpendance fonctionnelle suivante : id_lib, ref_l id_c Cette DF pourrait trs bien faire l'objet d'une CIF au niveau conceptuel, o bien tre reprsente sous cette forme :
Erielle
Voici comment cela se traduirait au niveau relationnel : Librairie ( id_lib , rue_lib, ville_l, cp_l) Livre ( ref_l , titre_l, resume_l) Client ( id_c , nom_c, prenom_c) ProposerEnVente ( id_lib #, ref_l Lgende : x : relation x : clef primaire x # : clef trangre
# , id_c #)
On retrouve bien la mme implantation au niveau relationnel que l'on aurait eu pour une CIF.
V - Conclusion
Avec les diffrentes notions abordes dans ce cours et quelques connaissance en SQL, il vous est maintenant possible de concevoir et raliser des bases de donnes relationnelles. Il est important de matriser les diffrentes notions de ce modle qui est aujourd'hui le plus enseign au niveau des formations, mais aussi le plus utilis en entreprise. Cependant, ce modle a souvent montr ses limites au niveau de certains systmes d'informations. Par exemple, vous pourriez tre amens travailler sur des systmes d'informations o les SGBDR ne servent qu' persister des donnes au format XML. Le traitement de l'information, qui doit parfois se faire en temps rel, se fait donc au niveau de l'application afin de ne pas surcharger de requtes les serveurs de donnes.
VI - Remerciements
Je souhaite remercier alassanediakite, CinePhil, fsmrel, LittleWhite, et MacFly58 pour leur relecture technique et leurs conseils. Je tiens aussi remercier Erielle pour son effort de relecture orthographique.

Initiation Merise

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Initiation Merise

Hochgeladen von

Copyright:

Verfügbare Formate

Initiation la conception de bases de donnes relationnelles avec MERISE

par Idriss NEUMANN Erielle

Date de publication : 28 fvrier 2012 Dernire mise jour : 17 octobre 2012

I - MERISE au service des systmes d'information I-A - Le systme d'information

II - Modlisation d'une base de donnes au niveau conceptuel

II-A - Les rgles de gestion mtiers

II-B - Le dictionnaire des donnes

100 10 Au format AAAAJJ-MM

50 4 1000 15 Cette rfrence servira galement

d'identifiant dans ce systme

Au format AAAAJJ-MM S'exprime en nombre de jours

II-C - Les dpendances fonctionnelles

II-D - Le Modle Conceptuel de Donnes (MCD) II-D-1 - Les entits

II-D-2 - Les associations

II-D-3 - laboration du MCD

III - Modlisation d'une base de donnes au niveau logique et passage au SQL

III-A - Le passage du MCD au MLD et SQL III-A-1 - Les relations

III-A-2 - Rgles de conversion

III-A-2-a - Rgle 1 - conversion d'une entit

III-A-3 - laboration du MLD et passage au SQL

Voici ce que cela donnerait :

III-B - Rgles de vrification des niveaux de normalisation

III-C - Cas particuliers III-C-1 - Les associations rflexives

III-C-2 - Rgle de conversion exceptionnelle pour certaines entits simples

IV - Les extensions apportes par MERISE II IV-A - L'identification relative

Voici comment on pourrait schmatiser ces rgles de gestions au niveau conceptuel :

IV-B - L'hritage et ses limites

IV-B-1 - L'hritage par disjonction (ou exclusion)

IV-B-2 - L'hritage par couverture (ou totalit)

IV-B-3 - L'hritage par partition (totalit et exclusion)

IV-B-4 - Passage au niveau relationnel et limites

IV-C - Les contraintes entre associations

IV-C-1 - La contrainte d'inclusion

IV-C-2 - La contrainte d'exclusion

IV-C-3 - La contrainte de totalit

IV-C-4 - La contrainte d'galit

IV-C-5 - Combinaison entre contraintes

IV-D - Les CIF (contraintes d'intgrits fonctionnelles) et agrgations

Das könnte Ihnen auch gefallen