Version imprimable
Bonjour !
J'ai un devoir maison à faire en cours de conception des systèmes d'information sur la méthode MERISE, et j'aurais besoin d'aide…
Pièce jointe 515811
Pour la question 1, j'ai essayé de faire un schéma du MCD correspondant :
Pièce jointe 515813
Qu'en pensez-vous ?
J'ai encore quelques problèmes :
- je n'arrive pas à limiter le nombre de prêts pour un abonné
- je ne sais pas faire l'historique
- je ne suis pas sûr du tout pour les mots-clés
Merci d'avance :)
Bonne journée ! 8-)
Bonsoir Hugo,
Le MCD qui vous a été proposé dans le PDF est plutôt réducteur, en effet fonctionnellement un ouvrage ne peut faire l’objet que d’un seul prêt. Vous me direz qu’au stade opératoire il suffira de faire un update de la table OUVRAGE, à savoir de la clé étrangère faisant référence à ABONNE, mais bon, on anticipe...
Par référence à la règle d’or du très grand Merisien Yves Tabourier, les identifiants des entités-types doivent très préférablement être des attributs artificiels, tandis que les attributs naturels tels que REFOUV et COD_ABON sont à ravaler au rang d’identifiants alternatifs, garantissant évidemment la règle d’unicité des identifiants, mais ne se propageant pas dans la base de données (stade MLD puis SQL).
Je cite Tabourier (page 80 de son remarquable ouvrage De l’autre côté de Merise, Les Éditions d’organisation, 1986) :
« ... la fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques.
L’expérience montre d’ailleurs que l’usage des “identifiants significatifs” (ou “codes significatifs”) a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets ou, pis encore, leurs liens avec d’autres objets... »
Par ailleurs, le nom d’une entité-type symbolise un prédicat. Par exemple :
L’ouvrage identifié par REFOUV, ayant pour titre TITREOUV a été édité au cours de l’année AN_EDIT
Alors qu’il serait pour le moins curieux d’écrire :
Les ouvrages identifiés par REFOUV, ayant pour titre TITREOUV ont été édités au cours des années AN_EDIT
En conséquence quoi, il est préférable que les noms des entités-types soit au singulier (OUVRAGE, ABONNE).
Il est demandé de faire figurer le nom de l’éditeur et l’année d’édition des livres : quid des rééditions ? En l’état ça n’est pas prévu, problème à soulever auprès du rédacteur de l’énoncé qui vous a été soumis...
Un livre peut avoir des co-auteurs, mais le rédacteur de l’énoncé n’en fait pas mention. Vous avez choisi l’option la plus raisonnable (1,N), c’est bien.
Votre entité-type LIVRE contient un attribut ANNEE_EDITION :
C’est une redondance puisque l’année d’édition est déjà présente dans OUVRAGE, donc connue.
Soit vous assurez la redondance (assertion ou trigger SQL), soit vous supprimez l’attribut AN_EDIT dans l’entité-type OUVRAGE, dans la mesure où l’année d’édition ne concerne pas les revues qui ont leur propre système de datation. Maintenant, si vous prenez en compte les ouvrages autres que les livres et les revues, et qu’il soit en l’occurrence imposé de tenir compte de la date d’édition, vous pouvez définir à cet effet une entité-type ad-hoc, appelons-la par exemple DIVERS. C’est un sous-type d’OUVRAGE, au même titre que LIVRE et REVUE.
Votre entité-type REVUE comporte un attribut DATE_PREMIER_NUM redondant, donc à supprimer. En effet, la date de parution du 1er numéro d’une revue est connue grâce à l’entité-type NUM_REVUE.
Dans votre MCD, il manque une association entre vos entités-types REVUE et NUM_REVUE.
Votre entité-type NUM_REVUE a pour identifiant l’attribut NUM : en l’état, parmi l’ensemble des revues une seule peut avoir i pour numéro, alors que chaque revue y a droit ! A cet effet, utilisez l’identification relative :
[REVUE]----1,N----(Numeroter)----1,1(R)----[NUM_REVUE]
Votre cardinalité 0,10 portée par la patte d’association connectant ABONNE et PRET suffit pour attirer l’attention sur le nombre maximum de prêts, et au stade SQL il faudra prévoir une contrainte (assertion ou trigger) permettant de garantir la chose. Quant au fait qu’il faille une période d’au moins un mois avant d’autoriser un nouveau prêt, il est évident que, sauf peut-être à monter une usine à gaz, un MCD merisien n’est pas capable de rendre compte de cette contrainte, qui sera garantie par une assertion ou un trigger SQL.Citation:
Envoyé par Hugo_Loup
Dans la mesure où un livre L (je parle du nom du livre et non pas de l’exemplaire matérialisé qu’on emporte) a pu faire l’objet d’un prêt à la date D à la fois pour plus d’un abonné, qu’un abonné A peut à la date D avoir emprunté plus d’un livre, et qu’un abonné a pu emprunter le même livre a différentes dates, la modélisation devient la suivante (pretDate participant à l’identification et mise en oeuvre de l’identification relative) :Citation:
Envoyé par votre prof
[LIVRE]----0,N----()----1,1(R)----[PRET{pretDate}]----1,1(R)----()----0,10----[ABONNE]
De façon plus certaine au stade SQL :
Le code SQL est évidemment à compléter.CREATE TABLE OUVRAGE ( ouvrageId INT NOT NULL , ouvrgeRef VARCHAR(16) NOT NULL , ouvrageTitre VARCHAR(96) NOT NULL , CONSTRAINT OUVRAGE_PK PRIMARY KEY (ouvrageId) , CONSTRAINT OUVRAGE_AK UNIQUE (ouvrgeRef) ) ; CREATE TABLE LIVRE ( ouvrageId INT NOT NULL , editeur VARCHAR(48) NOT NULL , anneeEdition INT NOT NULL , CONSTRAINT LIVRE_PK PRIMARY KEY (ouvrageId) , CONSTRAINT LIVRE_OUVRAGE_FK FOREIGN KEY (ouvrageId) REFERENCES OUVRAGE (ouvrageId) ON DELETE CASCADE ) ; CREATE TABLE REVUE ( ouvrageId INT NOT NULL , periodicite VARCHAR(16) NOT NULL , CONSTRAINT REVUE_PK PRIMARY KEY (ouvrageId) , CONSTRAINT REVUE_OUVRAGE_FK FOREIGN KEY (ouvrageId) REFERENCES OUVRAGE (ouvrageId) ON DELETE CASCADE ) ; CREATE TABLE NUM_REVUE ( ouvrageId INT NOT NULL , numeroRevue INT NOT NULL , numeroTitre VARCHAR(48) NOT NULL , numeroDateParution DATE NOT NULL , CONSTRAINT NUM_REVUE_PK PRIMARY KEY (ouvrageId, numeroRevue) , CONSTRAINT NUM_REVUE_REVUE_FK FOREIGN KEY(ouvrageId) REFERENCES REVUE(ouvrageId) ON DELETE CASCADE ) ; CREATE TABLE DIVERS ( ouvrageId INT NOT NULL , anneeEdition INT NOT NULL , CONSTRAINT DIVERS_PK PRIMARY KEY (ouvrageId) , CONSTRAINT DIVERS_OUVRAGE_FK FOREIGN KEY (ouvrageId) REFERENCES OUVRAGE (ouvrageId) ON DELETE CASCADE ) ; CREATE TABLE ABONNE ( abonneId INT NOT NULL , abonneCode VARCHAR(16) NOT NULL , CONSTRAINT ABONNE_PK PRIMARY KEY(abonneId) , CONSTRAINT ABONNE_AK UNIQUE (abonneId) ) ; CREATE TABLE PRET ( abonneId INT NOT NULL , ouvrageId INT NOT NULL , pretDate DATE NOT NULL , CONSTRAINT PRET_PK PRIMARY KEY (abonneId, ouvrageId, pretDate) , CONSTRAINT PRET_ABONNE_FK FOREIGN KEY (abonneId) REFERENCES ABONNE(abonneId) , CONSTRAINT PRET_LIVRE_FK FOREIGN KEY (ouvrageId) REFERENCES LIVRE (ouvrageId) ) ;
Je regarderai les mots clés plus tard (à moins qu’Escartefigue ne soit intervenu entre temps ;)).
A moins que je ne me plante dans l’interprétation de l’adjectif générique, un mot clé pouvant être père de plusieurs mots, il y a une cardinalité 0,N à mettre en œuvre côté Parent :Citation:
Envoyé par votre PDF
Pièce jointe 515877
Dans ces histoires de nomenclatures, graphes, etc. pensez à faire figurer les rôles, par exemple parent, enfant, composé, composant, etc.
Merci de vos réponses ! J'ai pu peaufiner mon MCD :mrgreen:
Aussi, pour le schéma relationnel, j'ai présenté comme cela (c'est ce qui est demandé par mon professeur) :
Pièce jointe 516201
Mais j'ai encore du mal sur certains points …
- Comment représenter la composition du mot clé et le parent et le fils ?
- Est-ce que je dois rajouter des clés dans certaines entités ? Par exemple pour AUTEUR( ... , REF_OUV#) ?
Aussi il m'est demandé de justifier mes choix de traduction ? Avez-vous une idée de ce que je dois dire là-dedans ?
Merci encore de votre aide ! ;)
Bonjour Hugo,
On peut supposer qu’il s’agit des règles de passage du MCD au schéma relationnel.Citation:
Envoyé par Hugo_Loup
En l’occurrence, conformément à l’usage (cf. l’ouvrage de référence de D. Nanci et B. Espinasse Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), page 243), je cite :
R1. « Toute entité-type est transformée en table. Ses propriétés deviennent les attributs de la table. L’identifiant devient la clé primaire de la table »
Nanci fait aussi la remarque suivante :
« l’entité ne comportant que l’identité comme propriété présente un cas particulier. Il devient provisoirement une table avec sa clé primaire comme seul attribut. Il est fort probable que les optimisations ultérieures fassent disparaître cette table. »
Oh que oui ! Il s’agit surtout de la sempiternelle entité-type DATE. JPhi33 en a très bien parlé ici ou là, en évoquant les travaux de Flory et Morejon. Voir aussi dans mon blog Merise et MCD : à propos de l’entité-type DATE.
Nanci continue à propos des règles de transformation, à savoir la transformation des associations binaires dont une cardinalité est 1,1 et l’autre est 0,N ou 1,N :
R2. « On duplique la clé de la table issue de l’entité-type à cardinalité (0,N) ou (1,N) dans la table issue de l’entité-type à cardinalité (1,1) où elle devient une clé étrangère »
Nanci traite aussi de l’identification relative (cf. pages 255 et 256) auquel cas
R3. la clé de la table issue de l’entité-type à cardinalité (0,N) ou (1,N) vient compléter la clé de la table issue de l’entité-type à cardinalité (1,1).
Et bien entendu, Nanci traite des sous-types (LIVRE et REVUE chez vous), je vous renvoie aux pages 251 et suivantes).
Bref, je vous engage à lire crayon en main les règles de transformation décrites par Nanci.
A propos de votre représentation « relationnelle » :
Vos identifiants reprennent exactement ceux qui vous ont été fournis, mais ce sont des identifiants naturels aussi je rappelle à nouveau que dans les projets professionnels on risque le bouillon si on ne met pas en oeuvre la règle d’or de Tabourier (identifiants artificiels, dépourvus de signification, donc invariants, donc garantissant la stabilité des liens entre tables au stade opérationnel). Non seulement on risque le bouillon, mais on en arrive à repartir à zéro, j’ai souvent assisté à ça au cours de mes décennies d’intervention ès matière !
Il y a un couac quant à la numérotation des revues. Vous écrivez en effet :
NUMEROTER (REF_OUV#, NUM#, TITRE_NUM, DATE_PARU) ;
NUM_REVUE (NUM, TITRE_NUM, DATE_PARU) ;
Je rappelle que la modélisation correcte au niveau du MCD est la suivante (cf. le post #2) :
[REVUE]----1,N----(Numeroter)----1,1(R)----[NUM_REVUE]
Dans ces conditions, conséquence de la cardinalité 1,1 portée par la patte connectant l’entité-type NUM_REVUE et l’association Numeroter, cette dernière n’a pas à faire l’objet d’une table. La modélisation correcte au niveau « relationnel » est la suivante, conformément au point R3 ci-dessus :
NUM_REVUE (REF_OUV#, NUM, TITRE_NUM, DATE_PARU) ;
Entité-type DIVERS
Vous avez fait l’impasse sur cette entité-type DIVERS. Selon l’énoncé proposé, vous pouvez « éventuellement envisager qu’il existe d’autres ouvrages », autrement dit on ne vous interdit pas de faire cette impasse, soit. Mais signalez que le jour où cela s’imposera, il ne sera pas compliqué de mettre en oeuvre une telle entité-type.Citation:
Envoyé par fsmrel
Je signale que votre schéma « relationnel » est inexploitable...
Ça n’est pas de votre faute, mais vous êtes victime de merisiens qui, il y a au moins 30 ans, inventèrent cette façon de représenter les tables et les relations qu’elles entretiennent. Par exemple, après avoir codé légalement et légitimement :
OUVRAGE (REF_OUV, TITRE_OUV) ;
par voie de conséquence vous êtes astreint à coder ainsi les tables REVUE et LIVRE :
REVUE (#REF_OUV, PERIODICITE) ;
LIVRE (#REF_OUV, NOM_EDIT, AN_EDIT) ;
Et le piège s’est refermé, pour chacune de ces tables, « #REF_OUV » symbolise la clé primaire et la clé étrangère faisant référence à la clé primaire de la table OUVRAGE, et comme vous êtes obligé d’en faire autant pour la table NUM_REVUE :
NUM_REVUE (REF_OUV#, NUM#, TITRE_NUM, DATE_PARU) ;
Une ambiguïté apparaît : il n’y a aucun moyen de savoir si la table NUM_REVUE fait référence à la table OUVRAGE ou à la table REVUE ou à la table LIVRE, car ces 3 tables ont la même clé primaire, symbolisée par REF_OUV# ! Le système imaginé il y a 3 décennies est inexploitable...
Cette ambiguïté affecte évidemment les tables ECRIRE, PRET, ASSOCIER.
L’AGL Looping est lui aussi victime de la faiblesse du mode représentation des schémas relationnels. Je lui ai soumis un MCD proche du vôtre, et voici ce qu’il produit :
OUVRAGE (REF_OUV, TITRE_OUV) ;
REVUE (#REF_OUV, PERIODICITE) ;
LIVRE (#REF_OUV, NOM_EDIT, AN_EDIT) ;
NUM_REVUE (#(#REF_OUV),NUM, TITRE_NUM, DATE_PARU) ;
Manifestement NUM_REVUE ne fait pas référence à OUVRAGE (deux symboles « # » au lieu d’un seul), Mais il reste une ambiguïté, car on ne peut pas savoir si c’est REVUE ou LIVRE qui est référencé...
Cela dit, je vous engage à utiliser Looping, car au moins le code SQL qu’il produit est sans ambiguïté.
Je laisse le soin à Looping de vous montrer ce qu’il produit, mais on en reparlera.Citation:
Envoyé par Hugo_Loup
Là encore, Looping vous montrera. Mais je reviendrai sur ce point.Citation:
Envoyé par Hugo_Loup
On reviendra sur l’historisation, car selon votre table PRET, l’abonné A ne peut emprunter le livre L qu’une seule fois, or cette contrainte n’est pas mentionnée dans votre énoncé.
Bonsoir,
Si je veux prendre en compte une entité DIVERS, je dois simplement l'ajouter dans l'héritage aux côtés de REVUE et LIVRE ? Vu que je n'ai pas plus de détails.Citation:
Envoyé par fsmrel
Je n'arrive pas à représenter cela dans le MCD, débutant dans ce domaine je ne sais pas comment mettre en forme l'historisation :Citation:
Envoyé par fsmrel
[LIVRE]----0,N----()----1,1(R)----[PRET{pretDate}]----1,1(R)----()----0,10----[ABONNE]
Comment pourrais-je faire sur Looping ?
Au passage merci beaucoup ce logiciel m'est très utile :D
Belle journée !
Bonjour Hugo,
Oui, tout en dotant DIVERS de l’attribut anneeEdition puisque celui-ci est à supprimer dans OUVRAGE.Citation:
Envoyé par Hugo_Loup
Modélisation de l’historique
L’énoncé figurant dans le PDF est très vague : on ne sait pas si OUVRAGE représente le titre d’un ouvrage : « Théorie de Merise » ou un exemplaire du dit ouvrage, parmi les 1000 exemplaires correspondants, figurant sur les étagères de la bibliothèque.
On va considérer qu’il s’agit d’un exemplaire, car le MCD figurant dans le PDF est celui-ci :
[OUVRAGE]----0,1----(PRET)----0,N----[ABONNE]
Sinon, le MCD aurait été le suivant :
[OUVRAGE]----0,N----(PRET)----0,N----[ABONNE]
signifiant qu’un nombre quelconque d’exemplaires de « Théorie de Merise » pourraient être prêtés en même temps.
Dans cette affaire, il faut distinguer les prêts en cours et les prêts terminés.
Le MCD figurant dans le PDF correspond manifestement au prêt en cours d’un exemplaire. Comme Looping refuse qu’une association soit porteuse d’un attribut dès lors qu’une patte de l’association a une cardinalité maximale à 1, on doit déguiser l’association en entité-type. C’est ce qu’on fait pour PRET, tout en renommant tant qu’à faire cette entité-type en PRET_EN_COURS.
Pour la partie historique, en l’occurrence les ouvrages rendus par les abonnés, on met là aussi en oeuvre une entité-type ad-hoc, appelons-la PRET_HISTO. Un prêt historisé est caractérisé par une période (une date de début et une date de fin, laquelle n’a pas de sens pour un prêt en cours). Au cours d’un période, un exemplaire n’a pu être prêté qu’à un seul abonné, d’où la nécessité de rendre identifiant l’attribut pretDateDebut ci-dessous :
Notez l’identification relative 1,1(R) nécessaire.
