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
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    novembre 2019
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 20
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : novembre 2019
    Messages : 3
    Points : 1
    Points
    1
    Par défaut 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…
    DM1.pdf

    Pour la question 1, j'ai essayé de faire un schéma du MCD correspondant :
    Nom : CSI.PNG
Affichages : 142
Taille : 26,1 Ko


    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
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 867
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 867
    Points : 25 553
    Points
    25 553
    Billets dans le blog
    16
    Par défaut
     


    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]


    Citation Envoyé par Hugo_Loup
    je n'arrive pas à limiter le nombre de prêts pour un abonné
    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 votre prof
    L’historique des prêts doit être conservé sur une période de un an
    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) :


    [LIVRE]----0,N----()----1,1(R)----[PRET{pretDate}]----1,1(R)----()----0,10----[ABONNE]


    De façon plus certaine au stade SQL :

    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)
    )
    ;
    
    Le code SQL est évidemment à compléter.


    Je regarderai les mots clés plus tard (à moins qu’Escartefigue ne soit intervenu entre temps ).

     
    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
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 867
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 867
    Points : 25 553
    Points
    25 553
    Billets dans le blog
    16
    Par défaut
     

    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 :

    Nom : Hugo_Loup_ bibliotheque_mots_cles.png
Affichages : 106
Taille : 7,7 Ko

    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
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    novembre 2019
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 20
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : novembre 2019
    Messages : 3
    Points : 1
    Points
    1
    Par défaut
    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) :
    Nom : CSI.PNG
Affichages : 96
Taille : 18,2 Ko

    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
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 867
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 867
    Points : 25 553
    Points
    25 553
    Billets dans le blog
    16
    Par défaut
     

    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
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    novembre 2019
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 20
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : novembre 2019
    Messages : 3
    Points : 1
    Points
    1
    Par défaut
    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
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 867
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 867
    Points : 25 553
    Points
    25 553
    Billets dans le blog
    16
    Par défaut
     

    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 :


    Nom : Hugo_Loup_ prets_histo.png
Affichages : 70
Taille : 9,9 Ko

    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

Discussions similaires

  1. Gestion d'une bibliothèque
    Par mimosa803 dans le forum Diagrammes de Classes
    Réponses: 5
    Dernier message: 30/05/2013, 10h35
  2. BiblioISSATS : Gestion d'une bibliothèque universitaire
    Par Chatbour dans le forum Vos contributions VB6
    Réponses: 3
    Dernier message: 25/10/2010, 18h40
  3. Gestion d'une bibliothèque
    Par hamady's dans le forum Débuter
    Réponses: 14
    Dernier message: 04/06/2009, 13h30
  4. SQlite : Gestion d'une bibliothèque
    Par comtois dans le forum PureBasic
    Réponses: 0
    Dernier message: 30/11/2008, 21h35
  5. Gestion d'une bibliothèque en Windev
    Par Lenalyon dans le forum WinDev
    Réponses: 5
    Dernier message: 23/08/2007, 16h01

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo