Discussion :

[louya]

Bonjour,

J'aurais voulu avoir votre aide pour me dire si mon travail était correcte (ce que je doute ^^) ou me pointer mes erreurs/oublis.

Il m'a fallu créer un Schéma relationnel à partir d'un schéma Entités-Associations.

• Voilà déjà le schéma Entités-Associations :

http://img535.imageshack.us/img535/2984/img001vr.jpg

• Et ce que j'ai réalisé concernant le MLR :

Lecteur(numLecteur, nom, prenom, adresse, telephone, #numLecteur_Parrain)
Emprunter(#numLecteur, #idExemplaire, DateEmprunt, DateRetour)
Exemplaire(idExemplaire, dateAchat, #ISBN)
Livre(ISBN, DateParution, Preface, #SIRET)
Editeur(SIRET, RaisonSociale, Adresse)
Implémenter(#ISBN, #idOuvrage)
Ouvrage(idOuvrage, TitreVo, TitreTraduit, AnneePremiereParution, #idType, #idStyle)
Type(idType, DescriptifType)
Style(idStyle, NomStyle, DescriptifStyle)
Ecrire(#idOuvrage, #idAuteur)
Auteur(idAuteur, NomPlume)

CONTRAINTES
Lecteur.numLecteur_Parrain = Lecteur.numLecteur

C'est surtout par rapport à l'entité Lecteur et l'association Parrain que j'ai des doutes.

Merci d'avance.

[fsmrel]

Bonjour,


Pour éviter la présence du bonhomme NULL, il serait préférable de mettre en œuvre une table pour le parrainage des lecteurs :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
TABLE LECTEUR {NumLecteur, ...}
PRIMARY KEY {NumLecteur} ;

TABLE PARRAINAGE {NumLecteur, NumLecteurParrain}
PRIMARY KEY {NumLecteur}
FOREIGN KEY {NumLecteur} REFERENCES LECTEUR {NumLecteur}
FOREIGN KEY {NumLecteurParrain} REFERENCES LECTEUR {NumLecteur} ;

[fsmrel]

Comme vous utilisez Open ModelSphere, votre MLD devrait ressembler à ceci en ce qui concerne le parrainage :

[louya]

Merci pour vos réponses.

Mais j'aurais peut-être dû préciser que c'est un exercice de "cours".
Je fais mes débuts avec MERISE, et cela sans utiliser de logiciel pour le moment, en restant avec les bases sur papier.

Je ne sais pas s'il est permis de modifier la structure du schéma, et faire passer PARRAIN en entité ?

En fait, j'avais vu quelque part qu'il fallait, pour cette entité-association ajouter une contrainte en utilisant des clefs étrangères. C'est ce que j'ai essayer de faire. Est-ce que là-dessus vous sauriez me dire si c'est convenable ?
Ou si mon schéma ne marcherait pas ?

Merci, merci.

[fsmrel]

Scolairement parlant, votre MLD est correct, notamment en ce qui concerne la table Lecteur :

Lecteur(numLecteur, nom, prenom, adresse, telephone, #numLecteur_Parrain)

A noter que la convention de représentation que vous utilisez a une faiblesse : stricto sensu, le nom d’attribut numLecteur_Parrain devrait exister en tant que nom d’attribut participant à la clé primaire d’une table, mais ce système tousse du fait de l’auto-référence.

Anyway. Il est quand étonnant de lire :

CONTRAINTES
Lecteur.numLecteur_Parrain = Lecteur.numLecteur

En effet cela voudrait dire que Toto est son propre parrain ou alors le rôle de l’égalité est obscur... : virez-moi ça.


Cela dit, il est préférable d’utiliser une notation non ambiguë, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
TABLE LECTEUR {NumLecteur, nom, prenom, adresse, telephone, NumLecteur_Parrain}
    PRIMARY KEY {NumLecteur}
    FOREIGN KEY {NumLecteurParrain} REFERENCES LECTEUR {NumLecteur} ;

Si l’on quitte le monde scolaire, non seulement il est permis mais il est en fait recommandé de procéder comme je vous l’ai indiqué, donc de mettre en œuvre une entité-type PARRAINAGE, comme je vous l’ai montré précédemment.

La cause des problèmes est en réalité la cardinalité 0,1 portée par la patte connectant LECTEUR et PARRAINER. Voyez à ce sujet la discussion ouverte par Nico128.

Une observation concernant les identifiants :

Avant de passer au MLD, si vous étiez dans un contexte opérationnel, il serait impératif d’utiliser des identifiants prenant des valeurs invariantes. Par exemple, Le n° SIRET devrait devenir un identifiant alternatif.

Je répète pour la (n+1)ième fois ce qu’à écrit Yves Tabourier à ce sujet (De l’autre côté de MERISE page 81) :

« ... 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... »

Je vous renvoie à ce sujet à une réflexion sur les vertus que doit avoir une clé primaire.

[louya]

Sur votre dernier point je comprends tout à fait et moi même j'ai tendance à mettre des "ID" partout.
Sans avoir utilisé Merise dans ma vie, j'ai eu l'occasion d'apprendre la gestion de bases de données avec MySQL, et c'est comme cela que je procédais.

Mais je reste là dans le cadre scolaire : je reprends simplement les termes tels qu'ils me sont imposés.

Mais autrement, je note bien ce que vous me dites. Lorsque nous auront quitté les bases, en approfondissant Merise, nous seront peut-être amenés à être plus "correcte" dans l'utilisation de cette méthode, à ce moment là j'appliquerais concrêtement ce que vous m'expliquez

Merci beaucoup.