Discussion :

[Bakura]

Bonjour,

Je fais appel à vos conseils sur un bout d'un MCD préliminaire. La modélisation n'étant pas ma spécialité, j'aimerais avoir vos avis. J'ai notamment quelques interrogations :

- Quelle est la manière correcte de modélisation la "notation" (que j'ai exprimé sous la forme "Evalue (a)" et "Evalue (b)", car les deux entités peuvent "s'évaluer" mutuellement, mais suivant des critères différents (l'entité Etudiant ne peut évaluer l'employeur que sur un unique critère).

- Je ne suis absolument pas sûr de la modélisation d'une "messagerie". En gros, les deux entités Etudiant / Employeur ont la possibilité de créer des discussions "entre eux" (en fait, ce sera toujours le cas, il n'y a pas de discussion possible entre deux étudiants ou deux employeurs).

Merci de vos réponses

EDIT : je précise que beaucoup de relations sont 0...N et non 1..N car la plupart des informations sont optionnelles.

[ok.Idriss]

Bonjour.

Deux premières remarques (je prendrai le temps d'analyser le MCD plus en détail plus tard ) :

- une association ayant pour cardinalité 1,1 ne peut être porteuse de données
- une association ternaire ne peut avoir pour cardinalité 1,1

En effet la cardinalité 1,1 se traduit par une clef étrangère et non une table associative au niveau relationnel ... ces modélisations ne peut donc être traduite.

Les associations Crée, Ecrit et Poste sont donc à revoir ...

Cordialement,
Idriss

[fsmrel]

Bonjour,


L’association-type Ecrit n'offre aucun intérêt, elle est redondante et, au nom du rasoir d'Occam, doit disparaître. En effet, l’étudiant et l’employeur concernés sont connus via la discussion (transitivité).

La partie « Discussions » pourrait ressembler à ceci :

une association ayant pour cardinalité 1,1 ne peut être porteuse de données.

Légende et dogme. Bien sûr qu'elle le peut, même s'il est d'usage depuis plus de trente ans de déclarer incorrecte cette façon de procéder. Après tout, une cardinalité 1,1 est un cas particulier de la cardinalité 1,N, pour laquelle, si l’association-type est porteuse de propriétés, celles-ci doivent y rester, respect de la règle merisienne de vérification oblige (aka 1NF). Dans le cas général, rien n’empêche de modéliser une x,y--(R)--1,1 telle que R soit porteuse de données.

ces modélisations ne peut donc être traduite.

Sophisme. Au niveau du MLD, vous êtes libre de définir une table associative ou non.

une association ternaire ne peut avoir pour cardinalité 1,1

Légende encore. Bien sûr qu'elle le peut, même s'il est préférable de remplacer la ternaire par deux binaires, comme le recommande Y. Tabourier (De l'autre côté de Merise, page 88), je cite : « Manque d’intérêt des cardinalités maximum à 1 pour les relations à plus de deux pattes ». Dans le cas particulier de Bakura, il est nettement préférable de remplacer les ternaires par des paires de binaires.

ces modélisations ne peut donc être traduite.

Sophisme. Bien sûr que si. Au niveau du MLD, vous définirez deux clés étrangères, sans problème.

Maintenant, l'outil de modélisation utilisé étant AnalyseSI, ce sont ses propres règles de dérivation du MCD en MLD qui peuvent forcer Bakura à changer de style de modélisation et par exemple faire migrer la propriété date_fil_discussion dans l’entité-type Discussion, etc.

[ok.Idriss]

Re bonjour.

Hum dans ce cas là cela signifie qu'on pourrait créer des tables associatives partout (donc au finale n'utiliser que des cardinalités de type 0/1,n ?) ? Pourquoi ne pas simplement mettre les données portées dans l'entité qui portera la clef étrangère.

Si on crée une table associative, les dépendances fonctionnelles sont-elles vraiment respectées ? Une association reliant deux entités avec une cardinalité 1,1 est carractérisée par l'existence d'une dépendance fonctionnelle entre l'identifiant de l'entité côté 1,1 et l'identifiant côté 0/1,n :

entité_1 --- 1,1 --- (association) --- 0/1,n --- entité_2

la DF est la suivante : id_entité_1 -> id_entité_2

La création d'une table associative ne respecte plus cette DF qui est une règle de gestion, non ?

Enfin du moins c'est comme ça que j'avais appris dans mon ancienne formation.

De toute façon dans le cas de l'association Poste, ici présent : pourquoi ne pas remplacer la cardinalité 1,1 par une cardinalité 1,n si on concerve la date du poste en donnée portée ? Dans le cas contraire ou l'on souhaiterai un seul poste par employé comme occurrence (cardinalité 1,1) la donnée date serait en dépendance fonctionnelle directe avec l'id de l'entité Emploi et donc ne devrait pas apparaitre dans une table associative si l'on souhaite rester en
2FN qui stipule que les attributs d'une relation doivent dépendre de la totalité de la clef primaire (les DF doivent être élémentaires). N'est-ce pas ?

N'y voyez pas de contradiction, je ne fait que poser des questions et demander des éclaircissements la dessus car cela met en doute l'enseignement que j'ai reçus (qui n'est peut être pas totalement juste, je sais que cela arrive souvent malheureusement).

Cordialement,
Idriss

[Bakura]

Merci beaucoup pour vos réponses, je prends tout ça en compte (vous ne m'avez pas répondu sur les évaluations par contre, si c'est bien modélisé à ce niveau).

Je reposterai dans deux semaines (vacances et tout...) le modèle complété et corrigé afin d'avoir vos avis sur la suite .

[ok.Idriss]

Eh bien si j'ai bien compris. L'une des deux associations concerne l'évaluation de l'étudiant par l'employé et l'autre concerne l'évaluation de l'employé par l'étudiant, c'est bien cela ?

Si oui, les critères d'évaluations n'apparaissent pas dans l'une des deux associations (et si j'ai bien compris, ce sont des critères différents). Pour être plus à même de vous répondre, pourriez-vous détailler un peu plus ces critères et ce à quoi correspondent les données portées par l'association évaluer (a) ?

D'ailleurs, il serait bien aussi de donner des noms plus significatifs à ces associations pour que l'on sache qui évalue qui dans chacune d'elle (par exemple evalue_emp_etu et evalue_etu_emp) mais bon si cela est clair pour vous ce n'est pas une obligation (dans ce cas, il faudrait nous le détailler ).

Cordialement,
Idriss

[Bakura]

Eh bien si j'ai bien compris. L'une des deux associations concerne l'évaluation de l'étudiant par l'employé et l'autre concerne l'évaluation de l'employé par l'étudiant, c'est bien cela ?

Si oui, les critères d'évaluations n'apparaissent pas dans l'une des deux associations (et si j'ai bien compris, ce sont des critères différents). Pour être plus à même de vous répondre, pourriez-vous détailler un peu plus ces critères et ce à quoi correspondent les données portées par l'association évaluer (a) ?

D'ailleurs, il serait bien aussi de donner des noms plus significatifs à ces associations pour que l'on sache qui évalue qui dans chacune d'elle (par exemple evalue_emp_etu et evalue_etu_emp) mais bon si cela est clair pour vous ce n'est pas une obligation (dans ce cas, il faudrait nous le détailler ).

Cordialement,
Idriss

Effectivement j'ai oublié de le préciser. Concrètement, l'entreprise doit noter l'étudiant sur plusieurs critères (3 exactement) + une description textuel, tandis que l'étudiant ne peut donner qu'une note globale sur l'employeur. (je précise les notes sont un entier entre 1 et 5).

[ok.Idriss]

Dans ce cas il manque une donnée portée qui correspondrait à cette note globale dans Evalue (a) je pense ...

Cordialement,
Idriss

[Bakura]

Dans ce cas il manque une donnée portée qui correspondrait à cette note globale dans Evalue (a) je pense ...

Cordialement,
Idriss

Cette note globale étant la moyenne des trois autres notes... puisque c'est une moyenne que je peux calculer, faut-il également la mettre dans le modèle conceptuel?

[ok.Idriss]

Cette note globale étant la moyenne des trois autres notes... puisque c'est une moyenne que je peux calculer, faut-il également la mettre dans le modèle conceptuel?

Je ne suis pas certain d'avoir bien compris : l'employeur note l'étudiant sur 3 critères (donc 3 notes) et étudiant donne une note globale à l'employeur ... comment cette dernière peut être une moyenne des 3 autres ? Si c'était le cas ce ne serait pas l'étudiant qui noterai l'employeur et la seconde association serait inutile ...

Sinon en effet, il est rarement intéressant de faire figurer une donnée calculée sur un MCD (autrement dit de la conserver en base).

Cordialement,
Idriss

[Bakura]

Je ne suis pas certain d'avoir bien compris : l'employeur note l'étudiant sur 3 critères (donc 3 notes) et étudiant donne une note globale à l'employeur ... comment cette dernière peut être une moyenne des 3 autres ? Si c'était le cas ce ne serait pas l'étudiant qui noterai l'employeur et la seconde association serait inutile ...

Sinon en effet, il est rarement intéressant de faire figurer une donnée calculée sur un MCD (autrement dit de la conserver en base).

Cordialement,
Idriss

Autant pour moi, j'ai mal compris, je pensais que tu parlais justement de l'absence de la moyenne. Effectivement il manque un champ "note_generale" sur l'une des associations.

[fsmrel]

Bonsoir,

Hum dans ce cas là cela signifie qu'on pourrait créer des tables associatives partout (donc au finale n'utiliser que des cardinalités de type 0/1,n ?) ? Pourquoi ne pas simplement mettre les données portées dans l'entité qui portera la clef étrangère.

Je suppose que vous voulez dire que pour chaque association-type R (porteuse ou non de propriétés) telle que celle qui figure ci-dessous, je préconise que cette association-type fasse l’objet d’une table au niveau du MLD : je réponds bien sûr négativement.

Considérons la structure suivante :

Une entité-type A dont l’en-tête est composé des propriétés A1, A2, ..., Ap, et dont l’identifiant est un sous-ensemble (au sens de la théorie des ensembles) de ces propriétés, par exemple {A1, A2, A3} ;

Une entité-type B dont l’en-tête est composé des propriétés B1, B2, ..., Bn, et dont l’identifiant est un sous-ensemble (au sens de la théorie des ensembles) de ces propriétés, par exemple {B1, B2} ;

Une association-type R dont l’en-tête est composé des propriétés R1, R2, ..., Rm ;

R mettant en relation A et B ainsi :

[ A ] -- 1,1 -- (R) -- x,n -- [B]

Au stade du MLD SQL, la situation sera a priori la suivante la suivante :

Montage 1

Code SQL :

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

1
2
3
TABLE A {A1, A2, ..., Ap, B1, B2, R1, R2, ..., Rm}
PRIMARY KEY {A1, A2, A3}
FOREIGN KEY {B1, B2} REFERENCES B {B1, B2}

Mais c’est là qu’intervient l’administrateur de la base de données (DBA), qui est responsable notamment de la performance des applications, de la sécurité des données, etc.

Supposons que les données soient globalement stables (peu mises à jour), à l’exception de la colonne R1 qui est indexée et passe son temps à être mise à jour. La table A ci-dessus (index compris) risque de devoir être réorganisée plus qu’elle ne le devrait. Par ailleurs, les tâches concurrentes pour mettre à jour R1 vont se bloquer les unes les autres et A (qui comme par hasard est très fortement consultée) va finir par être continuellement verrouillée, au grand dam des utilisateurs.

Que faire ? La table A comporte notamment la dépendance fonctionnelle (au sens de la théorie relationnelle et non pas de Merise) :

{A1, A2, A3} -> {B1, B2, R1}

et en vertu du théorème de Heath, le montage peut devenir le suivant :

Montage 2

Code SQL :

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

1
2
3
4
5
6
7
TABLE A {A1, A2, ..., Ap, R2, ..., Rm}
PRIMARY KEY {A1, A2, A3}
 
TABLE R {A1, A2, A3, B1, B2, R1}
PRIMARY KEY {A1, A2, A3}
FOREIGN KEY {A1, A2, A3} REFERENCES A {A1, A2, A3}
FOREIGN KEY {B1, B2} REFERENCES B {B1, B2}

Désormais la table A n’est plus polluée par les mises à jour de la colonne R1 et les utilisateurs qui consultent cette table seront contents.

Quant aux concurrences d’accès (table R), c'est à la charge du malheureux DBA de poursuivre ses investigations...

Tout cela relève de l’optimisation, mais il n’en demeure pas moins que si le 1er montage est à recommander, il ne représente pas un absolu, il ne doit pas être la conséquence d'un dogme.

Si on crée une table associative, les dépendances fonctionnelles sont-elles vraiment respectées ? Une association reliant deux entités avec une cardinalité 1,1 est caractérisée par l'existence d'une dépendance fonctionnelle entre l'identifiant de l'entité côté 1,1 et l'identifiant côté 0/1,n :

entité_1 --- 1,1 --- (association) --- 0/1,n --- entité_2

la DF est la suivante : id_entité_1 -> id_entité_2

La création d'une table associative ne respecte plus cette DF qui est une règle de gestion, non ?

Enfin du moins c'est comme ça que j'avais appris dans mon ancienne formation.

Parce que la création d’une table associative s’appuie sur le théorème de Heath, la règle de gestion selon laquelle chaque occurrence de entite_1 fait référence à exactement une occurrence de entite_2 est donc respectée.

=>

Signalez l’existence du théorème de Heath à votre ancien formateur...

De toute façon dans le cas de l'association Poste , ici présent : pourquoi ne pas remplacer la cardinalité 1,1 par une cardinalité 1,n si on conserve la date du poste en donnée portée ? Dans le cas contraire ou l'on souhaiterait un seul poste par employé comme occurrence (cardinalité 1,1) la donnée date serait en dépendance fonctionnelle directe avec l'id de l'entité Emploi et donc ne devrait pas apparaitre dans une table associative si l'on souhaite rester en
2FN qui stipule que les attributs d'une relation doivent dépendre de la totalité de la clef primaire (les DF doivent être élémentaires). N'est-ce pas ?

Pourquoi vouloir remplacer 1,1 par 1,n ?

La règle de gestion est la suivante :

Un emploi donné est posté exactement par un employeur.

En remplaçant 1,1 par 1,n, vous changeriez la règle :

Um emploi donné est posté par au moins un employeur.

Ce qui serait une faute...


Concernant la 2NF, vous utilisez les termes relation et clé primaire. Soit vous vous situez dans le contexte SQL et vous devriez utiliser le terme table plutôt que le terme relation, soit vous vous situez dans le contexte du Modèle Relationnel de Données et vous remplacerez l'expression clé primaire (désormais disqualifiée) par clé candidate ou tout simplement clé.

Quoi qu’il en soit, la 2NF n’est pas définie en termes de respect de la clé primaire, mais de l’ensemble des clés [candidates].


Dans le MCD proposé par Bakura, vous avez une organisation semblable à celle qui précède, et au niveau MLD (au comportement près d’AnalyseSI) la structure normalement attendue peut être la suivante :

Code SQL :

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

1
2
3
4
5
6
7
EMPLOI {IdEmploi, NomEmploi, etc.}
PRIMARY KEY {IdEmploi}
 
POSTE {IdEmploi, DateEmploi, IdEmployeur}
PRIMARY KEY {IdEmploi}
FOREIGN KEY {IdEmploi} REFERENCES EMPLOI {IdEmploi}
FOREIGN KEY {IdEmployeur} REFERENCES EMPLOYEUR {IdEmployeur}

Ou la suivante :

Code SQL :

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

1
2
3
EMPLOI {IdEmploi, NomEmploi, etc., DateEmploi, IdEmployeur}
PRIMARY KEY {IdEmploi}
FOREIGN KEY {IdEmployeur} REFERENCES EMPLOYEUR {IdEmployeur}

Configuration qui par application du théorème de Heath peut donner lieu à la précédente, et tout ça respecte la 5NF.

N'y voyez pas de contradiction, je ne fait que poser des questions et demander des éclaircissements la dessus car cela met en doute l'enseignement que j'ai reçus (qui n'est peut être pas totalement juste, je sais que cela arrive souvent malheureusement).

Votre attitude vous honore. J’espère pour ma part vous avoir un peu éclairé, et quand vous avez des doutes, n’hésitez pas à les exposer. En Merise la référence chez DVP est (pour moi) JPhi33 ; je suis ès matière un peu (beaucoup) iconoclaste, parce que j’ai beaucoup, beaucoup bourlingué et crapahuté dans les MCD. Pour le Modèle Relationnel de Données, n’hésitez pas à investir dans les ouvrages de C. J. Date, en particulier An Introduction to Database Systems, 8th Edition.

[ok.Idriss]

Re bonjour.

Pourquoi vouloir remplacer 1,1 par 1,n ?

La règle de gestion est la suivante :

Un emploi donné est posté exactement par un employeur.

En remplaçant 1,1 par 1,n, vous changeriez la règle :

Um emploi donné est posté par au moins un employeur.

Ce qui serait une faute...

Bien entendu, changer une règle de gestion est une faute (sauf si on fait évoluer la conception). Je voulais simplement dire que dans le cas d'une cardinalité 1,1 j'aurais plutôt mis la donnée date dans l'entité du côté 1,1 mais bon à partir du moment ou l'on peut créer une table associative, ça change tout ...

J'aurais toutefois une dernière question (qui ne relève plus de la conception) :

entité_1 --- 1,1 --- (association) --- 0,n --- entité_2

Les deux traductions suivantes sont donc possibles :

relation_1 (id_1, ..., id_2#)
relation_2 (id_2, ...)

et

relation_1 (id_1, ...)
relation_2 (id_2, ...)
relation_a (id_1#, id_2#)

Mais la première solution n'est-elle pas plus optimisée en terme de place qui sera occupée par le SGBDR sur un grand nombre d'occurrences ?

En tout cas je vous remercie grandement de vos explications précises et détaillées ainsi que de vos conseils qui me serviront (notamment les explications sur le modèle relationnel et les FN, le théorème de Heath et la référence à l'ouvrage de C. J. Date) .

Cordialement,
Idriss

[fsmrel]

Bonjour Idriss,


En attendant le retour de Bakura...

Bien entendu, changer une règle de gestion est une faute (sauf si on fait évoluer la conception). Je voulais simplement dire que dans le cas d'une cardinalité 1,1 j'aurais plutôt mis la donnée date dans l'entité du côté 1,1 mais bon à partir du moment ou l'on peut créer une table associative, ça change tout ...

A l’avenir, vous aurez à vous prononcer sur d’autres MCD comportant des pattes à cardinalités 1,1, où les associations-types connectées sont porteuses de propriétés. Comme je l’ai déjà précisé, il faut rappeler aux concepteurs que ces propriétés doivent de préférence figurer au sein des entités-types qui sont du côté 1,1. Cela est impérieux pour les étudiants qui rendent leur copie, car les professeurs ne sont pas forcément tous des DBA . En revanche, dans le contexte de la Production informatique, pour les motifs que j’ai déjà évoqués (il peut y en avoir d’autres, tels que la confidentialité : propriétés visibles seulement par certaines personnes), le DBA peut être amené à mettre en œuvre une ou plusieurs tables « associatives ».

Maintenant, vous aurez compris qu’il faut du doigté, et éviter d’écrire :

« En effet la cardinalité 1,1 se traduit par une clef étrangère et non une table associative au niveau relationnel ... ces modélisations ne peut donc être traduite. »

De mon côté, j’essaie de garder à l'esprit cette formule de H.L. Mencken, cité par Claude Gagnière (Pour tout l’or des mots) :

« Lorsqu’un diplomate dit oui, cela signifie peut-être. Lorsqu’il dit peut-être, cela veut dire non... et quand il dit non, cela veut dire qu’il n’est pas un diplomate ».

Claude Gagnière poursuit :

« Lorsqu’une lady dit non, cela signifie peut-être. Lorsqu’elle dit peut-être, cela veut dire oui. Mais si elle dit oui, cela signifie... qu’elle n’est pas une lady ! ».

Et comme l'a dit je ne sais plus qui :

« Lorsqu’un militaire dit oui, cela veut dire oui. Lorsqu’il dit non, cela veut dire non. Mais s’il dit peut-être, cela veut dire qu’il n’est pas un militaire... »

relation_1 (id_1, ...)
relation_2 (id_2, ...)
relation_a (id_1#, id_2#)

Attention ! id_2# ne participe pas à la clé de relation_a. Il faut écrire :

relation_1 (id_1, ...)
relation_2 (id_2, ...)
relation_a (id_1#, id_2#)

Sinon cela revient à transformer 1,1 en 1,N. N'oubliez pas la contrainte d'irréductibilité des clés candidates.

Mais la première solution n'est-elle pas plus optimisée en termes de place qui sera occupée par le SGBDR sur un grand nombre d'occurrences ?

A la façon du diplomate, je répondrais : « peut-être »... En effet, vu de la production, cela fait trois fichiers de plus, un pour le table space hébergeant la table relation_a, deux pour les index. Si la table contient un milliard de lignes, on y regardera à deux fois, en mettant en balance les avantages/inconvénients recensés, tels que les contentions (inter-blocages en mise à jour). En fait, le nombre d’occurrences n’est qu’un paramètre parmi d’autres, la partie émergée de l’iceberg visible par les non DBA. Par exemple, si la table relation_a est fortement chahutée à cause des mises à jour affectant tel ou tel attribut, cette fois-ci, indépendamment de la mauvaise qualité du service rendu aux utilisateurs, ce sont les fichiers journaux qui vont devenir obèses, les tâches de sauvegarde de réorganisation qui seront fortement consommatrices de ressources (en temps et en espace), et les conclusions des DBA pourront aller dans le sens de la mise en œuvre de la table relation_a, plutôt que de la simple clé étrangère permettant à relation_1 de référencer relation_2.

=>

La modélisation conceptuelle est une chose, les décisions finales reviennent à la Production. Mais je ne sais pas si on enseigne cela aux étudiants. En tout cas, sur le terrain, on acquiert des techniques et un savoir qui sont le fruit des enseignements du vécu, le sien propre et celui des anciens.

Keep up the good job.

[ok.Idriss]

Attention ! id_2# ne participe pas à la clé de relation_a. Il faut écrire :

relation_1 (id_1, ...)
relation_2 (id_2, ...)
relation_a (id_1#, id_2#)

Sinon cela revient à transformer 1,1 en 1,N. N'oubliez pas la contrainte d'irréductibilité des clés candidates.

Oui en effet ... j'ai corrigé

Merci beaucoup pour vos éclaircissements (et pour vos citations ).

Idriss

[Bakura]

En attendant le retour de Bakura...

Je suis en vacances jusqu'au 28, si je ne vous répond pas maintenant c'est pas que je vous aime pas hein .

[ok.Idriss]

Je suis en vacances jusqu'au 28, si je ne vous répond pas maintenant c'est pas que je vous aime pas hein .

Je ne pense pas que c'était un reproche

Idriss

[fsmrel]

Hello Bakura,


Don't worry, à partir du 28 on vous confie les clefs...

Merci de laisser ce qu'il faut dans le frigo, des fois qu'on ait soif en arrivant !

En attendant, bonne trempette.

[Bakura]

En attendant, bonne trempette.

Je suis en Ecosse. Effectivement, on fait trempette mais pas de la manière dont tu penses :o (désolé, c'est la seule section de DVP que je fréquente ou vous vous vouvoyez :o)...

[Bakura]

Bonjour à tous,

Tout d'abord merci pour toutes vos réponses (même si vous vous êtes un peu engueulés entre vous et que j'ai pas compris toutes vos réponses :o).

J'ai avancé mon MCD, en prenant en compte vos remarques, en complétant certaines entités, et en modifiant quelques petites choses pour respecter la... hum deuxième forme normale je crois (avec les adresses, et les langues).

J'aimerais avoir vos avis sur ce nouveau modèle afin de l'affiner et de l'améliorer afin de moins galérer ensuite. Une bonne partie y est, il me faudra quand même voir avec mon ami si j'ai bien respecté le cahier des charges (il me manque deux trois fonctionnalités dont il faut qu'on parle, je le mettrai à jour donc plus tard). Mais pour l'instant, c'est déjà pas mal .

PS : désolé pour les noms des variables, AnalyseSI n'autorisant pas les variables de même nom, pareil pour les associations, il n'autorise pas les noms "vides" donc j'ai du laisser les "Association 57" .


EDIT : la relation "Se trouve" pour l'entreprise n'est pas relié à "Commune" mais à "Adresse", désolé de l'erreur.