Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

Etude de cas : Gestion d'une bibliothèque


Sujet :

Schéma

  1. #1
    Futur Membre du Club
    Etude de cas : Gestion d'une bibliothèque
    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…


    Pour la question 1, j'ai essayé de faire un schéma du MCD correspondant :



    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 !

  2. #2
    Expert éminent sénior
    Ce message n'a pas pu être affiché car il comporte des erreurs.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  3. #3
    Expert éminent sénior
     

    Citation Envoyé par votre PDF
    un mot clé générique pourra être « père » de plusieurs autres mots clés


    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 :



    Dans ces histoires de nomenclatures, graphes, etc. pensez à faire figurer les rôles, par exemple parent, enfant, composé, composant, etc.

     
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  4. #4
    Futur Membre du Club
    Merci de vos réponses ! J'ai pu peaufiner mon MCD

    Aussi, pour le schéma relationnel, j'ai présenté comme cela (c'est ce qui est demandé par mon professeur) :


    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 !

  5. #5
    Expert éminent sénior
     

    Bonjour Hugo,

    Citation Envoyé par Hugo_Loup
    Il m'est demandé de justifier mes choix de traduction


    On peut supposer qu’il s’agit des règles de passage du MCD au schéma relationnel.

    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 , 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

    Citation Envoyé par fsmrel
    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.
    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.


    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é.



    Citation Envoyé par Hugo_Loup
    Comment représenter la composition du mot clé et le parent et le fils ?


    Je laisse le soin à Looping de vous montrer ce qu’il produit, mais on en reparlera.



    Citation Envoyé par Hugo_Loup
    Est-ce que je dois rajouter des clés dans certaines entités ?


    Là encore, Looping vous montrera. Mais je reviendrai sur ce point.



    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é.

     
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  6. #6
    Futur Membre du Club
    Bonsoir,

    Citation Envoyé par fsmrel Voir le message
     
    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.
     
    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 Voir le message
     
    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é.
     
    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 :

    [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


    Belle journée !

  7. #7
    Expert éminent sénior
     

    Bonjour Hugo,


    Citation Envoyé par Hugo_Loup Voir le message
    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.
    Oui, tout en dotant DIVERS de l’attribut anneeEdition puisque celui-ci est à supprimer dans OUVRAGE.


    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.

     
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

###raw>template_hook.ano_emploi###