Discussion :

[__mathieu__]

Bonjour,

Je débute sur le MCD et j'avoue être bien perdu dans le cours de l'organisme qui donne l'enseignement (je préfère taire le nom).

Je dois rendre un devoir, le but je le reconnais est déjà de valider mon UE...qui m'a coûté 150 euros et pour laquelle le prof ne répond à quasiment aucune de mes questions. C'est pour cela que je suis venu sur ce forum. Hier j'y ai passé toute mon après-midi et le soir jusqu'à plus de minuit, pour au final toujours avoir des doutes si ce que je fais est correct ou non, parce que je fais l'exercice au ressenti, vu que certains points du cours pour lequel je n'ai pas de réponse, bah je ne sais pas comment faire pour avancer. Il faut donc aussi que j'apprenne quelque chose et que cela me serve dans l'avenir.

Est-ce que quelqu'un pourrait me recommander des liens Internet vers des cours vers lesquels je pourrais apprendre le MCD ?

D'autre part j'ai un devoir à rendre, est-ce que quelqu'un pourrait jeter un oeil et me dire ce qu'elle/il en pense ?

Le sujet :
https://drive.google.com/file/d/1-A2...ew?usp=sharing

Ce que j'ai fait :
https://drive.google.com/file/d/1J3d...ew?usp=sharing

Merci par avance

Cordialement

Mathieu

[escartefigue]

Bonjour

J'ai répondu à un sujet similaire et proposé un MCD qui pourra vous aider dans votre reflexion, cf. ce lien, réponse n° 8
https://www.developpez.net/forums/d2...i-cardinalite/

Pour les cours, recherchez "parlez-vous merise" de Michel Diviné, il est gratuit et accessible sur la toile

[fsmrel]

Bonjour Mathieu,

Est-ce que quelqu'un pourrait me recommander des liens Internet vers des cours vers lesquels je pourrais apprendre le MCD ?

 
Il existe fondamentalement l’ouvrage remarquable de D. Nanci (RIP) et B Espinasse Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), c’est l’ouvrage de référence. Le chapitre à étudier est le chapitre 7 (« Modélisation conceptuelle des données »).

J’ai des remarques à faire concernant votre MCD.

Pour modéliser il est bien préférable que vous utilisiez Looping, gracieusement proposé par le professeur Patrick Bergougnoux (Paprick).

[escartefigue]

Après un parcours rapide de votre MCD, quelques remarques


Entité-type abonné
Il est préférable d'externaliser le n° de téléphone et de l'associer à un type de téléphone (fixe perso, fixe bureau, portable pro...)
ABONNE 0,n --- utiliser --- 1,1 TELEPHONE 1,1 --- typer --- 0,n TYPE_TEL



Entité-type gestionnaire
un gestionnaire est une personne et devrait donc être un sous-type par héritage ce qui vous évitera d'avoir des attributs redondants tels que le nom, le prénom...



Entité-type éditeur
fuyez systématiquement l'utilisation d'une colonne ayant un sens fonctionnel comme identifiant primaire.
L'identifiant primaire doit être stable et pour se faire asémantique. La raison est que l'id primaire se propage via les contraintes d'intégrité dans d'autres tables.
Si la valeur est modifiée (ce qui arrive souvent aux contenus fonctionnels. Ex: l'éditeur change de nom), alors ça va propager plein de modifs inutiles dans les tables filles. Donc, faites comme pour les autres types d'entité : un chrono attribué par le SGBD sera parfait



Association emprunter
il y a à la fois une date de début, de fin et une durée.
Attention aux incohérences du coup!
il est préférable d'avoir une date de début et une durée ou alors une date de début et une date de fin
EDIT :
- par ailleurs, l'abonné emprunte un exemplaire, pas un livre !
- je ne vois rien dans l'énoncé qui justifie d'associer le gestionnaire à l'emprunt. On devrait donc avoir une asso binaire entre exemplaire et abonné.



Association acheter
La cardinalité 1,1 coté date ne va pas : elle implique qu'un gestionnaire ne peut acheter qu'un seul exemplaire à une certaine date
Comme il y a 4000 exemplaires achetés par an, il va falloir embaucher un paquet de gestionnaires
Dans une association ternaire, les cardinalités maxi sont "n"
Comme un exemplaire n'est acheté que par un seul gestionnaire et une seule fois, la relation est une binaire simple :
EXEMPLAIRE 1,1 --- acheter --- 0,n GESTIONNAIRE



Association écrire
L'attribut nbr_oeuvre, s'il sert à donner le nombre d'oeuvres écrites par un auteur, alors c'est une redondance à supprimer.
Ce nombre sera déduit par le nombre d'occurrences de l'association (et donc, au niveau SQL, le nombre de fois où la jointure de personne vers livre est satisfaite)



Association inscrire
nbr_insription : même remarque que pour nbr_oeuvre



EDIT : Entité-type personne
Même remarque que pour l'éditeur, surtout pas d'identifiant fonctionnel
Et là c'est pire, le nom étant unique, deux personnes ne pourront pas avoir le même nom de famille

[fsmrel]

Concernant les achats d’exemplaires, Escartefigue vous a expliqué votre erreur montré la bonne modélisation :

EXEMPLAIRE 1,1 --- acheter --- 0,n GESTIONNAIRE

Question subsidiaire à cent sous, Mathieu, où ferez-vous figurer la date d’achat ? 


N.B. Votre énoncé et votre MCD doivent figurer dans votre message. Vous avez mis un lien vers des images qui disparaîtront un jour, et lorsque d’autres voudront les afficher, ils seront alors forcément frustrés...

[__mathieu__]

Bonjour,

Merci à tous pour vos rapides retours.

@fsmrel : merci beaucoup je vais étudier le cours.
Dans votre commentaire vous précisez que vous avez des remarques sur le MCD.
Par la suite vous parlez seulement du logiciel de modélisation.
Est-ce que vous aviez d'autres commentaires ?

@escartefigue : merci beaucoup pour vos remarques.

Entité-type abonné
Il est préférable d'externaliser le n° de téléphone et de l'associer à un type de téléphone (fixe perso, fixe bureau, portable pro...)
ABONNE 0,n --- utiliser --- 1,1 TELEPHONE 1,1 --- typer --- 0,n TYPE_TEL

OK, je prends note.

Entité-type gestionnaire
un gestionnaire est une personne et devrait donc être un sous-type par héritage ce qui vous évitera d'avoir des attributs redondants tels que le nom, le prénom...

Du coup, je mettrais une entité PERSONNE et de cette entité hériteraient AUTEUR, ABONNE et GESTIONNAIRE ? Est-ce bien cela ?
Nous n'avons pas traité ce point en cours, je pense que le prof pense à quelque chose de plus classique, même si cela peut fonctionner.
Dans le cas où je définis un héritage, comment ferais-je pour créer une association entre AUTEUR et ABONNE ?
Justement j'avais écrit :
PERSONNE --- EstUn ABONNE pour éviter d'avoir une association que l'on m'a expliqué être maladroite :
ABONNE --- emprunter --- LIVRE --- écrire --- AUTEUR

Entité-type éditeur
fuyez systématiquement l'utilisation d'une colonne ayant un sens fonctionnel comme identifiant primaire.
L'identifiant primaire doit être stable et pour se faire asémantique. La raison est que l'id primaire se propage via les contraintes d'intégrité dans d'autres tables.
Si la valeur est modifiée (ce qui arrive souvent aux contenus fonctionnels. Ex: l'éditeur change de nom), alors ça va propager plein de modifs inutiles dans les tables filles. Donc, faites comme pour les autres types d'entité : un chrono attribué par le SGBD sera parfait

Si je comprends bien pour EDITEUR il ne faut pas mettre comme identifiant son libellé mais un code_éditeur ?

Association emprunter
il y a à la fois une date de début, de fin et une durée.
Attention aux incohérences du coup!
il est préférable d'avoir une date de début et une durée ou alors une date de début et une date de fin

Vous avez raison, dans l'énoncé il est dit :

Les prêts sont accordés pour une durée de 30 jours, éventuellement renouvelable, si aucune demande de ce livre n’a eu lieu entre temps. Il faut donc connaître à chaque instant pour chaque livre emprunté, la date d’emprunt et la date de retour.

Mais aussi :

Les prêts sont accordés pour une durée de 30 jours, éventuellement renouvelable, si aucune demande de ce livre n’a eu lieu entre temps.

Je vais donc retirer l'attribut durée_emprunt de l'association emprunter, la durée de l'emprunt étant déductible par la différence entre date_fin et date_emprunt et la date_retour

EDIT :
- par ailleurs, l'abonné emprunte un exemplaire, pas un livre !

Je suis d'accord avec vous. Cette phrase dans l'éononcé m'a poussé à créer l'association avec LIVRE et non avec EXEMPLAIRE.

La gestion des prêts implique la possibilité de connaître à tout moment la liste des livres détenus par un abonné, et inversement, qu’on puisse retrouver le nom des abonnés détenant un livre donné.

Du coup, je ne sais pas si je dois déroger à l'énoncé et le mettre comme hypothèse ou est-ce que je dois respecter l'énoncé.

EDIT :
- je ne vois rien dans l'énoncé qui justifie d'associer le gestionnaire à l'emprunt. On devrait donc avoir une asso binaire entre exemplaire et abonné.

J'ai associé le GESTIONNAIRE à l'emprunt parce qu'il est dit dans l'énoncé que le GESTIONNAIRE doit mettre à jour le code_usure du LIVRE dès son retour de prêt.

Pour suivre de près l’état du stock, la bibliothèque utilise un code indiquant l’état d’usure de chaque livre. Ce code d’usure est mis à jour par un gestionnaire à chaque retour d’un livre en prêt.

il va falloir embaucher un paquet de gestionnaires

Association acheter
La cardinalité 1,1 coté date ne va pas : elle implique qu'un gestionnaire ne peut acheter qu'un seul exemplaire à une certaine date
Comme il y a 4000 exemplaires achetés par an, il va falloir embaucher un paquet de gestionnaires
Dans une association ternaire, les cardinalités maxi sont "n"
Comme un exemplaire n'est acheté que par un seul gestionnaire et une seule fois, la relation est une binaire simple :
EXEMPLAIRE 1,1 --- acheter --- 0,n GESTIONNAIRE

Pour la cardinalité 1, 1 entre DATE et achète je l'avais interprété de la façon suivante, surement erronée.

Vous avez raison, je vais corriger la cardinalité à 1, n. J'ai confondu le code unique du code différent de chaque article.

Ici le prof veut que l'on fasse ce qu'il l'appelle de l'historisation, pour savoir que tel exemplaire a été acheté en 2000 ou en 2010.

Chaque livre est acheté en un ou plusieurs exemplaires et le système doit pouvoir stocker la date d’acquisition.

Il nous a inlassablement répété que le ternaire c'est souvent pour historiser.

Dans mon MCD par rapport à l'énoncé là où j'ai eu le plus de mal cela a été de répondre à ce point suivant dans l'énoncé :

L’abonné doit pouvoir connaître la liste des livres d’un auteur ou la liste par éditeur ou bien encore la liste par genre (bande dessinée, science-fiction, policier,...)

Comment je peux faire pour qu'ABONNE puisse connaitre la liste des LIVRES écrit par un AUTEUR. En effet si ABONNE emprunte un LIVRE "Les Misérables" de Victor HUGO, comment peut-il savoir qu'il a aussi écrit "Notre Dame de Paris" ?

Ce nombre sera déduit par le nombre d'occurrences de l'association (et donc, au niveau SQL, le nombre de fois où la jointure de personne vers livre est satisfaite)

Association inscrire
nbr_insription : même remarque que pour nbr_oeuvre

Je comprends ce que vous dites.

EDIT : Entité-type personne
Même remarque que pour l'éditeur, surtout pas d'identifiant fonctionnel
Et là c'est pire, le nom étant unique, deux personnes ne pourront pas avoir le même nom de famille

C'est effectivement une grosse faute. Merci, j'ai bien compris.

Un autre doute est :

L’abonné doit pouvoir connaître la liste des livres d’un auteur ou la liste par éditeur ou bien encore la liste par genre (bande dessinée, science-fiction, policier,...)

On m'a conseillé de mettre des clés étrangères nomAuteur et nomEditeur dans LIVRE mais je ne suis pas certain que cela soit correct.

Merci par avance

Cordialement

Mathieu

[fsmrel]

Bonsoir Mathieu,

@fsmrel : merci beaucoup je vais étudier le cours.
Dans votre commentaire vous précisez que vous avez des remarques sur le MCD.
Par la suite vous parlez seulement du logiciel de modélisation.
Est-ce que vous aviez d'autres commentaires ?

Mes commentaires sont inclus dans ceux qu’a fait Escartefigue, par exemple concernant l’association ternaire ACHETER :

EXEMPLAIRE 1,1 --- acheter --- 0,n GESTIONNAIRE

Question subsidiaire à cent sous, Mathieu, où ferez-vous figurer la date d’achat des exemplaires ? 

Du coup, je mettrais une entité PERSONNE et de cette entité hériteraient AUTEUR, ABONNE et GESTIONNAIRE ? Est-ce bien cela ?

Effectivement. Je vous renvoie à l’ouvrage de Nanci et Espinasse (et qui, j’espère, figure dans votre bibliothèque ), au paragraphe « Types et sous-types d’entités : spécialisation/généralisation », pages 106 et suivantes.

Nous n'avons pas traité ce point en cours, je pense que le prof pense à quelque chose de plus classique, même si cela peut fonctionner.

Heu... ça fonctionne à merveille, et ça existe officiellement depuis 30 ans, dans le document suivant :

afcet - Le formalisme de données Merise - Extensions du pouvoir d’expression - Journée d’étude organisée par le Groupe de Travail 135 « Conception des systèmes d’information » (Collège AFCET-GID) - Jeudi 15 novembre 1990, Paris.

Si votre AGL de modélisation ne vous permet pas de mettre en oeuvre la spécialisation/généralisation des entités-types, utilisez Looping.


En passant, votre énoncé parle de fichiers : il va falloir que quelqu’un mette ça à niveau, on n’est plus en 1970 :...

Dans le cas où je définis un héritage, comment ferais-je pour créer une association entre AUTEUR et ABONNE ?

Comme pour toutes les associations entre entités-types. Cela dit, pourquoi une association entre AUTEUR et ABONNE ?

J'ai associé le GESTIONNAIRE à l'emprunt parce qu'il est dit dans l'énoncé que le GESTIONNAIRE doit mettre à jour le code_usure du LIVRE dès son retour de prêt.

Selon votre association EMPRUNTER, tous les gestionnaires peuvent être impliqués dans un emprunt donné, alors qu’il n’y en n’a qu’un seul qui puisse l’être : pour garantir cette contrainte, il doit y avoir une association entre EMPRUNTER et GESTIONNAIRE, mais ceci est interdit en Merise : cette association devrait donc être transformée en entité-type.


Je passe la main aux collègues car il se fait tard.

N.B. Votre énoncé et votre MCD doivent figurer dans votre message. Vous avez mis un lien vers des images qui disparaîtront un jour (nous sommes tous confrontés à ça...), et lorsque d’autres voudront les afficher, ils seront alors forcément frustrés...

[escartefigue]

Bonjour,

Voici une modélisation possible

Pièce jointe 583299

L'héritage est utilisé pour les auteurs, abonnés et gestionnaires qui sont tous des personnes.
C'est un héritage de type "XT" qui signifie que chaque sous-type est mutuellement exclusif et que toute personne appartient à un sous-type.
Si un auteur peut être gestionnaire, un abonné être auteur ou autre, il faut adapter le type d'héritage.

Le téléphone est externalisé comme proposé plus haut, vous pouvez ainsi enregistrer plusieurs téléphones pour une même personne et identifier le type d'usage du téléphone (fixe pro, fixe domicile, portable perso...)
On peut aussi nommer cette entité-type "media" plutôt que telephone et y enregistrer aussi les numero de fax, adresse courriel etc. en ajoutant ces types dans type_media (plutôt que type_tel)

L'entité type "calendrier" sert à faire participer la date à l'association emprunter. En l'absence, un abonné ne pourrait pas emprunter un même exemplaire à des dates différentes.
Le nom de cette entité-type est entre parenthèses, c'est la symbolique utilisée par looping pour matérialiser le fait qu'elle ne deviendra pas une table (case à cocher) dont n'aurions que faire.
La flêche de l'association "emprunter" côté "abonné" matérialise la Contrainte d'Intégrité Fonctionnelle (CIF) qui stipule qu'un exemplaire, à une date ne concerne qu'un seul abonné

Par "purisme" j'ai distingué le "manuscrit", document rédigé par le ou les auteurs et porteur d'un titre, d'une date d'écriture, d'un résumé... du livre qui est l'oeuvre publiée directement par l'auteur (cas rare et qui justifie la cardinalité zéro coté livre de l'association "éditer") ou plus souvent par un éditeur.
Plusieurs éditions d'un même livre portent un ISBN différent, par contre, le titre et la date d'écriture sont les mêmes, d'où la distinction de ces deux entité-types.

Le script correspondant à ce MCD est le suivant (généré pour SQL server) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
CREATE TABLE PE_personne(
   PE_ident INT IDENTITY,
   PE_nom INT IDENTITY NOT NULL,
   PE_prenom VARCHAR(50) NOT NULL,
   PE_dtnai DATE NOT NULL,
   PRIMARY KEY(PE_ident)
);

CREATE TABLE AB_abonnne(
   PE_ident INT,
   AB_numero SMALLINT NOT NULL,
   AB_dtadh VARCHAR(50) NOT NULL,
   PRIMARY KEY(PE_ident),
   UNIQUE(AB_numero),
   FOREIGN KEY(PE_ident) REFERENCES PE_personne(PE_ident)
);

CREATE TABLE GE_gestionnaire(
   PE_ident INT,
   PRIMARY KEY(PE_ident),
   FOREIGN KEY(PE_ident) REFERENCES PE_personne(PE_ident)
);

CREATE TABLE YT_type_tel(
   YT_ident INT IDENTITY,
   YT_code CHAR(4) NOT NULL,
   YT_libelle VARCHAR(50) NOT NULL,
   PRIMARY KEY(YT_ident),
   UNIQUE(YT_code)
);

CREATE TABLE AU_auteur(
   PE_ident INT,
   AU_pseudo VARCHAR(50) NOT NULL,
   PRIMARY KEY(PE_ident),
   FOREIGN KEY(PE_ident) REFERENCES PE_personne(PE_ident)
);

CREATE TABLE MN_manuscrit(
   MN_ident INT IDENTITY,
   MN_dtecr DATE NOT NULL,
   MN_titre VARCHAR(255) NOT NULL,
   MN_resume VARCHAR(255),
   PRIMARY KEY(MN_ident)
);

CREATE TABLE ED_editeur(
   ED_ident INT IDENTITY,
   ED_code CHAR(10) NOT NULL,
   ED_nom VARCHAR(128) NOT NULL,
   PRIMARY KEY(ED_ident),
   UNIQUE(ED_code)
);

CREATE TABLE TL_telephone(
   TL_ident INT IDENTITY,
   TL_numero CHAR(25) NOT NULL,
   YT_ident INT NOT NULL,
   PE_ident INT NOT NULL,
   PRIMARY KEY(TL_ident),
   FOREIGN KEY(YT_ident) REFERENCES YT_type_tel(YT_ident),
   FOREIGN KEY(PE_ident) REFERENCES PE_personne(PE_ident)
);

CREATE TABLE LI_livre(
   MN_ident INT,
   LI_ident SMALLINT,
   LI_ISBN CHAR(13) NOT NULL,
   ED_ident INT,
   PRIMARY KEY(MN_ident, LI_ident),
   UNIQUE(LI_ISBN),
   FOREIGN KEY(MN_ident) REFERENCES MN_manuscrit(MN_ident),
   FOREIGN KEY(ED_ident) REFERENCES ED_editeur(ED_ident)
);

CREATE TABLE EX_exemplaire(
   MN_ident INT,
   LI_ident SMALLINT,
   EX_ident SMALLINT,
   EX_dtimp DATE NOT NULL,
   EX_dtach DATE NOT NULL,
   EX_codbar SMALLINT NOT NULL,
   PE_ident INT NOT NULL,
   PRIMARY KEY(MN_ident, LI_ident, EX_ident),
   UNIQUE(EX_codbar),
   FOREIGN KEY(MN_ident, LI_ident) REFERENCES LI_livre(MN_ident, LI_ident),
   FOREIGN KEY(PE_ident) REFERENCES GE_gestionnaire(PE_ident)
);

CREATE TABLE AX_emprunter(
   MN_ident INT,
   LI_ident SMALLINT,
   EX_ident SMALLINT,
   CA_date DATE,
   PE_ident INT NOT NULL,
   PRIMARY KEY(MN_ident, LI_ident, EX_ident, CA_date),
   FOREIGN KEY(MN_ident, LI_ident, EX_ident) REFERENCES EX_exemplaire(MN_ident, LI_ident, EX_ident),
   FOREIGN KEY(PE_ident) REFERENCES AB_abonnne(PE_ident)
);

CREATE TABLE EC_ecrire(
   PE_ident INT,
   MN_ident INT,
   PRIMARY KEY(PE_ident, MN_ident),
   FOREIGN KEY(PE_ident) REFERENCES AU_auteur(PE_ident),
   FOREIGN KEY(MN_ident) REFERENCES MN_manuscrit(MN_ident)
);

EDIT : ajout du MCD looping zipé, le format natif (extension .LOO n'étant pas accepté en pièce jointe)

[escartefigue]

J'ai associé le GESTIONNAIRE à l'emprunt parce qu'il est dit dans l'énoncé que le GESTIONNAIRE doit mettre à jour le code_usure du LIVRE dès son retour de prêt.

L'état n'est pas un attribut de l'emprunt, mais de l'exemplaire (et non pas du livre non plus) : que l'exemplaire soit emprunté ou pas, il a bien un certain état.
Ce que doit donc faire le gestionnaire, c'est mettre à jour l'état de l'exemplaire lors du retour (et éventuellement demander le remplacement de l'exemplaire par l'abonné si cet exemplaire a été sévèrement dégradé)
@François : sur ce point, nous divergeons, qu'en penses-tu ?

[__mathieu__]

Merci beaucoup pour vos retours.

Désolé mais je ne saisis pas deux points.

Comment l'ABONNE fait pour connaitre tous les MANUSCRITS écrit par un même AUTEUR ou savoir quelles sont l'ensemble des EXEMPLAIRES publiés par un EDITEUR ?
D'autre part, comment faire pour gérer si un ABONNE a déjà été emprunté un EXEMPLAIRE ?
Est-ce que je peux mettre un booléen pour préciser si un ABONNE est "dit prioritaire" pour être le prochain à emprunter un EXEMPLAIRE ?

Les dates de retour je peux la mettre dans l'entité CALENDRIER ?

Merci par avance

Cordialement

Mathieu

[escartefigue]

Comment l'ABONNE fait pour connaitre tous les MANUSCRITS écrit par un même AUTEUR

Pour rappel, un auteur est un sous type des personnes, son identifiant est donc celui des personnes (PE_ident dans mon exemple) et comme un auteur peut écrire plusieurs manuscrits et qu'un manuscrit peut avoir plusieurs auteurs, l'association EC_ecrire (toujours dans mon exemple) devient une table qui contient à la fois l'identifiant de la personne et donc de l'auteur et celui du manuscrit.

ou savoir quel est l'ensemble des EXEMPLAIRES publiés par un EDITEUR ?

Dans mon exemple, l'exemplaire est identifié relativement au livre, ça signifie que l'identifiant du livre est une composante de la PK de l'exemplaire. Et comme dans le livre on trouve en FK l'identifiant de l'éditeur, le chemin pour assembler le tout est assez simple

Pour ce genre de questions, consultez le script (ordres CREATE TABLE) que j'ai fourni plus haut, on en déduit le cheminement grâce aux "foreign keys" FK

[__mathieu__]

Merci pour votre réponse,

J'avoue ne plus rien comprendre.
Le prof nous dit de ne surtout pas utiliser le terme de table quand on commence le MCD.

Si je rends un exercice comme cela il va comprendre que je ne l'ai pas fait (ce qui serait en parti faux), mais il va surtout me mettre un 0.

Je vais étudier le cours sur le lien qu'il m'a été communiqué et déjà bien comprendre.

Merci pour votre aide.

Cordialement

Mathieu

[Paprick]

Bonjour,

J'avoue ne plus rien comprendre.
Le prof nous dit de ne surtout pas utiliser le terme de table quand on commence le MCD.

Chaque terme doit être utilisé à sa place !
Au niveau MCD, votre enseignant a raison : on parle de classes d'entités et d'associations.
Par contre, dès que l'on génère le schéma relationnel correspondant (MLD, puis script SQL avec les CREATE TABLE), il est bel et bien question de tables au sein du SGBD.

[fsmrel]

Bonjour Mathieu,  


Avant d’entrer dans quelques points de modélisation.

J'avoue ne plus rien comprendre.
Le prof nous dit de ne surtout pas utiliser le terme de table quand on commence le MCD.

J’ai été devancé par l’excellent Paprick, donc je vais redonder, mais ceci n’est pas forcément un défaut...

Le prof a parfaitement raison. Mais chaque MCD a pour vocation d’être la source pour son MLD cible, et et à ce 2e stade on ne parle plus d’entités-types mais de tables, on ne parle plus d’identifiants mais de clés candidates (primaires et alternatives), d’associations mais de clés étrangères, etc. (tous ces sont concepts bien antérieurs à Merise, inventés dès 1969 par E. F. Codd). Pour utiliser une analogie, le MCD (niveau conceptuel) est la dunette du bateau, le MLD le pont (niveau logique), tandis que le code SQL représente la soute (niveau physique).

Escartefigue a traité des problèmes rencontrés quant à la construction de la dunette, puis vous a fourni en plus l’organisation qui s’en suit du pont et de la de la soute. Il est évident que l’objet de la manœuvre est de s’assurer que la soute sera correcte une fois opérationnelle. Mais de tout cela vous n’en parlerez pas au prof !

En conséquence, dans vos relations avec le prof, vous n’utiliserez que les termes entité-type (ou classe d’entités), identifiant, propriétés (ou rubriques ou attributs), association (ou relation), cardinalités portées par les pattes d’association, héritage (en espérant que le prof ne tienne pas à en rester aux années quatre-vingts, alors que le concept de spécialisation/généralisation a été adopté avec enthousiasme par les pères de Merise à la fin de ces années quatre-vingts).

[escartefigue]

Bonsoir à tous

Au niveau MCD, votre enseignant a raison : on parle de classes d'entités et d'associations.
Par contre, dès que l'on génère le schéma relationnel correspondant (MLD, puis script SQL avec les CREATE TABLE), il est bel et bien question de tables au sein du SGBD.

Nous sommes bien d'accord

Bonjour Mathieu,  
Escartefigue a traité des problèmes rencontrés quant à la construction de la dunette, puis vous a fourni en plus l’organisation qui s’en suit du pont et de la de la soute. Il est évident que l’objet de la manœuvre est de s’assurer que la soute sera correcte une fois opérationnelle. Mais de tout cela vous n’en parlerez pas au prof !

Là aussi, rien à ajouter

Comment l'ABONNE fait pour connaitre tous les MANUSCRITS écrit par un même AUTEUR ou savoir quelles sont l'ensemble des EXEMPLAIRES publiés par un EDITEUR ?

Et voici : la question était "COMMENT" or, le comment nécessite de passer au niveau tabulaire et aux ordres SQL qui vont bien, alors que le "QUOI" qui est l'objet du MCD ne se préoccupe, comme l'ont justement argumenté Paprick et Fsmrel, que des entités, associations et identifiants.
C'est bien pour répondre au "COMMENT" que j'ai fait une digression vers les tables, mais ce faisant, je suis sorti des limites du terrain du MCD, j'espère ne pas mériter le carton rouge

[fsmrel]

On m'a conseillé de mettre des clés étrangères nomAuteur et nomEditeur dans LIVRE mais je ne suis pas certain que cela soit correct.

Qui est « on » ? Je rappelle que dans un MCD on utilise le terme « association », le terme « clé étrangère » faisant partie du vocabulaire utilisé sur le pont (MLD) et dans la soute (SQL) !


Mathieu, à propos de l’entité-type LIVRE :

Vous avez attribué à cette entité-type un identifiant {Code_catalogue, Code_exemplaire}, autrement dit l’existence d’un livre est conditionnée par celle de chacun de ses exemplaires : ne pensez-vous pas que c’es plutôt l’inverse, qu’on ne peut disposer des exemplaires qu’une fois le livre lui-même existant ?


Du code usure : suite logique de qui précède ce code ne concerne que les exemplaires, sinon si vous le faites figurer dans l’entité-type LIVRE, alors tous les exemplaires d’un livre ont le même code usure...

Des mots clés Vous avez fait figurer un attribut mots-clés dans l’entité-type LIVRE. Puisqu’un livre peut faire l’objet de plusieurs mots clés, cet attribut ne peut être qu’un vecteur. Il est plus raisonnable de définir une entité-type MOT_CLE associable à l’entité-type LIVRE :

[LIVRE]---0,n---()---0,n---[MOT_CLE]

Du genre des livres

Plusieurs livres pouvant être du même genre, il est sage que le nom de ce genre soit le même pour tous les livres concernés, d’où la mise en oeuvre d’une entité-type GENRE. Ses relations avec LIVRE sont les suivantes :

[LIVRE]---1,1---()---0,n---[GENRE]

Les éditions successives d’un livre :

Dans le post #3, j’ai évoqué l’ouvrage remarquable de D. Nanci et B. Espinasse, Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001). L’éditeur en est Vuibert. Avant 2001, j’utilisais la 3e édition de l’ouvrage, paru chez Sybex (1996). Il est donc nécessaire de mettre en oeuvre une association, ou plutôt une entité-type EDITION (à cause des exemplaires).

Même combat pour Le rouge et le Noir qui n’en est pas à son 1er éditeur !

Si donc vous voulez modéliser les éditeurs, il faut tenir compte des éditions :

[LIVRE]---1,n---()---1,1(R)---[EDITION]---1,1---()---0,n---[EDITEUR]

Notez l’identification relative (1,1(R)), expliquée à la page 130 de l’ouvrage de D. Nanci et B. Espinasse.


Les exemplaires :

A ce stade, les deux exemplaires dont je dispose de l’ouvrage de D. Nanci et B. Espinasse se rapportent chacun à une édition différente, d’où la modélisation :

[EXEMPLAIRE]---1,1---()---0,n---[EDITION]

Notez que la cardinalité 0,n signifie que pour telle édition, il n’y a pas encore eu d’achat.

Pour ce qui concerne les livres, en résumé :

Problème délicat de l’identification des entités-types

Vous pouvez consulter mon article De l’invariance des clés primaires, lequel traite des problèmes de clés au niveau du pont (MLD), mais aussi de la dunette (MCD) où je cite un très grand champion de Merise, à savoir Yves Tabourier.

Pour le moment j’en reste là, mais ne manquerai de poursuivre avec les abonnés, gestionnaires et auteurs, ainsi que des emprunts.

savoir quelles sont l'ensemble des EXEMPLAIRES publiés par un EDITEUR ?

Evitons-de causer SQL alors que c’est quand même bien pratique de faire des jointures pour traiter du problème... Mais bon, dans la vue ci-dessus du MCD un exemplaire détermine une édition (fait référence à une et une seule édition), donc on sait obtenir exactement tous les exemplaires dont dispose la bibliothèque pour une édition donnée. A son tour, une édition détermine un éditeur, donc on sait obtenir exactement toutes les éditions dont dispose la bibliothèque pour un éditeur donné. Par transitivité on sait donc obtenir exactement tous les exemplaires dont dispose la bibliothèque pour un éditeur donné (et bien sûr pour tous les éditeurs).

[fsmrel]

Modélisation des personnes


Je ne traite pas ici des prêts, je le ferai un peu plus tard.

Je ne traite pas non plus des manuscrits, voyez avec Escartefigue.

Cela dit, toutes choses égales, dans la vue ci-dessous du MCD, pour savoir quels livres un auteur a écrits, c’est l’association ECRIRE qui fournit la réponse.

Notez au passage la mise en oeuvre de l’entité-type CATEGORIE_PROF. Il serait bien de définir un code catégorie.

[escartefigue]

Je ne traite pas non plus des manuscrits, voyez avec Escartefigue.

Sauf erreur de ma part, nous somme sur le même modèle, mais avec des noms différents pour les types d'entité

Tu as choisi EDITION pour ce que j'ai nommé LIVRE (ayant dans les deux cas l'ISBN pour attribut)
et tu as choisi LIVRE pour ce que j'ai nommé MANUSCRIT (ayant le titre et la date d'écriture pour attributs)

J'ai mis le résumé dans MANUSCRIT mais je n'en suis pas certain. Peut être le résumé est il différent selon l'édition, à vérifier.

Nous n'avons pas utilisé exactement les mêmes cardinalités : j'ai tenu compte du fait que certains manuscrits étaient publiés directement par l'auteur sans passer par un éditeur. Le cas est marginal, mais il existe

[Paprick]

Bonsoir,

Nous n'avons pas utilisé exactement les mêmes cardinalités : j'ai tenu compte du fait que certains manuscrits étaient publiés directement par l'auteur sans passer par un éditeur. Le cas est marginal, mais il existe

Pas si marginal que ça si l'on considère l'autoédition qui se développe beaucoup ces derniers temps : c'est d'ailleurs la solution que j'ai choisie pour mon livre !
Néanmoins, on peut aussi considérer ces auto-éditeurs comme des éditeurs classiques : l'auteur est alors également éditeur.

[fsmrel]

j'ai tenu compte du fait que certains manuscrits étaient publiés directement par l'auteur sans passer par un éditeur. Le cas est marginal, mais il existe

Exact. En l’occurrence, Matthieu, faites comme Escartefigue.

Du point de vue du MCD, rien à dire. Mais (ce qui suit ne concerne qu’Escartefigue et Paprick, Matthieu, fermez les yeux ) conséquence de la cardinalité 0,1 portée par la patte connectant LI_livre et ED_editeur, dans la soute la table LI_livre est dotée d’une colonne ED_ident pouvant être marquée NULL, avec les conséquences que cela sur la clé étrangère {ED_ident}. Pour éviter ça, je propose :

[EDITEUR]--0,n--()--1,1--[EDITION_EDITEUR]--1,1(R)--()--0,1--[EDITION]

Et là, comme dit le poète, le bonhomme NULL peut aller se rhabiller...

Matthieu, vous pouvez rouvrir les yeux.

on peut aussi considérer ces auto-éditeurs comme des éditeurs classiques : l'auteur est alors également éditeur.

Certes, mais si je comprends bien les gestionnaires devront t’intégrer deux fois dans la base de données, une fois en tant qu’auteur et une fois en tant qu’éditeur. Hum...