Discussion :

[JPhi33]

Bonjour,

Vous avez dérivé sur les clés mais je reviens sur la question de la date.

Cependant, conceptuellement, Date est bien une entité et il doit donc être considéré comme telle lors de l'implémentation, peu importe la manière spécifique dont c'est représenté logiquement.

Et bien non, c'est fsmrel qui a raison...

Non. Ce n'est qu'un type que l'on déguise en entité-type dans le contexte Merise, quand la dimension des associations-types est supérieure ou égale à 3. Sinon, si l’on vous suit, à chaque fois qu’une entité-type ou une association-type est porteuse d’un attribut de type Date (ou plusieurs, par exemple DateDébut, DateFin), il faudra l'en débarrasser et la connecter autant de fois que nécessaire sur la prétendue entité-type Date. Étonnant...

... mais je vais compléter son argumentaire.

On (A. FLORY, J. MOREJON) distingue des propriétés servant à indiquer une référence à l'espace ou au temps que l'on nomme "propriétés spatio-temporelles". Cette définition permet d'étendre la notion d'association en lui procurant un identifiant supplémentaire n'apparaissant pas comme identifiant d'une entité.
Ainsi, il est possible de faire participer une date (par exemple) à l'identification d'une association sans que la date soit elle-même identifiant d'une entité ; il s'agit d'une simple propriété. Graphiquement, une PST est représentée dans un simple rectangle : une boîte d'entité sans le rectangle nom de l'entité, comme ceci :

Code :

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

1
2
3
4
+--------------+
| DateCréation |
+--------------+

L'erreur de choix des pères de Merise, que fsmrel a mentionnée, a été rectifiée par leurs successeurs.

[Invité]

J'ai pas tout suivi...désolé

[Invité]

Si une variable relationnelle est en 3NF et si chacune de ses clés candidates ne comporte qu'un seul attribut, alors cette variable relationnelle est en 5NF.

Un seul attribut, c'est à dire une clé qui ne soit multiple (code1,code2,attribut) ?

[fsmrel]

Si une variable relationnelle est en 3NF et si chacune de ses clés candidates ne comporte qu'un seul attribut, alors cette variable relationnelle est en 5NF.

Un seul attribut, c'est à dire une clé qui ne soit multiple (code1,code2,attribut) ?

La paire {code1, code2} comporte deux attributs au lieu d'un seul : le théorème ne s'applique pas et il faudra en passer par le processus de normalisation classique en 5NF (ou PJ/NF), mais pour le moment, cela risque d'être hors de votre portée, à moins que vous n'assimiliez parfaitement ce qu'a écrit Fagin dans Normal forms and relational database operators.

[Invité]

http://michel-divine.developpez.com/...rlezVousMerise

Merci pour le lien, mais il ne semble pas y avoir de chapitre sur le formes normales ?

[Invité]

La paire {code1, code2} comporte deux attributs au lieu d'un seul : le théorème ne s'applique pas et il faudra en passer par le processus de normalisation classique en 5NF (ou PJ/NF), mais pour le moment, cela risque d'être hors de votre portée, à moins que vous n'assimiliez parfaitement ce qu'a écrit Fagin dans Normal forms and relational database operators.

Merci, disons qu'il va falloir approfondir mes connaissances sérieusement. Dans ce cas des listes de valeurs du genre (id,nom) sont en 5nf (minimum de dépendance) ?

[fsmrel]

http://michel-divine.developpez.com/...rlezVousMerise

Merci pour le lien, mais il ne semble pas y avoir de chapitre sur les formes normales ?

La théorie de la normalisation est une branche des mathématiques appliquées qui ne fait pas partie de la méthode Merise mais de la théorie relationnelle. L’ouvrage de Diviné traite donc de Merise mais pas de la théorie relationnelle. Pour que qui concerne les formes normales, reportez-vous à l’article de Fagin. Pour quelque chose de plus abordable, voyez l’ouvrage de Chris Date : An Introduction to Database Systems.

Dans ce cas des listes de valeurs du genre (id, nom) sont en 5nf (minimum de dépendance) ?

Je ne sais pas ce que vous voulez dire par « minimum de dépendance », mais je répète que si chaque clé candidate d’une variable relationnelle R est singleton (ne contient qu’un seul attribut), alors R respecte la 5NF. Dans votre exemple, c’est le cas.

[Invité]

Merci à tous pour vos réponses et votre patience.

[MacFly58]

Citation Fsmrel :

Pour reprendre votre exemple, puisque les règles de gestion des données sont les suivantes :

Un étudiant peut être promu plusieurs fois la même année pour différents cours,
Un étudiant ne peut être promu qu'une seule fois par an et par cours.

Alors la représentation conceptuelle suivante est nécessaire et suffisante :

cf. MCD que je n'ai pas pu copier/coller. Il se trouve page 1, contribution n°10

Dans ce MCD, il me semble que la date devrait être soulignée, pour montrer qu'il s'agit d'une partie de l'identifiant de la relation.

Pour éviter l'entité-type Date, il me semble plus opportun d'indiquer la clé de la relation en entier et de la souligner. Il s'agirait de la concaténation des identifiants des deux entités participants à la relation, auxquels s'ajoute la fameuse date.

Je ne suis pas un spécialiste de cette question, mais j'aimerai bien l'avis d'un spécialiste.

[CinePhil]

C'est effectivement ce que je fais. Je trouve ça plus pratique.

[fsmrel]

cf. MCD que je n'ai pas pu copier/coller. Il se trouve page 1, contribution n°10

Vous accédez aux propriétés de l’image, vous récupérez son adresse et vous utilisez la balise [IMG] :



=>

Dans ce MCD, il me semble que la date devrait être soulignée, pour montrer qu'il s'agit d'une partie de l'identifiant de la relation.

Comme le chantait le poète :

Chanté par Georges Brassens :
« L’avait l’ don, c’est vrai, j’en conviens,
L’avait l’ génie,
Mais sans technique, un don n’est rien
Qu’un’ sal’ manie... »

Modéliser à l’instinct ne suffit pas. Puisque vous affirmez que l’attribut PromoDate participe à l’identification de la relation PROMOTION, l’identifiant complet en est le suivant : {Eid, Cid, PromoDate}. Autrement dit vous changez les règles de gestion.

Ainsi la règle :

Un étudiant ne peut être promu qu'une seule fois par an et par cours

devient

Un étudiant peut être promu plusieurs fois par an et par cours

Auquel cas, du point de vue du système, la contrainte est devenue la suivante : les triplets de valeurs {Eid, Cid, PromoDate} doivent être uniques, et l’exemple ci-dessous est conforme :

Code :

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

1
2
3
4
 
Eid   PromoDate   Cid
e1       d1       c1 
e1       d2       c1

Par contre, si la règle est bien qu’un étudiant ne puisse être promu qu'une seule fois par an et par cours, les paires de valeurs {Eid, Cid} doivent être uniques et le système interdira que la paire {e1, c1} soit présente deux fois dans la base de données, contrairement à ce qui se produit avec l’exemple ci-dessus.

C'est effectivement ce que je fais. Je trouve ça plus pratique.

Mais pas forcément valide...

[MacFly58]

J'ai lu ce sujet en diagonal et le schéma de Juliendusud m'a induit en erreur.


J'ajoute le lien relatif à cette contribution car l'image ci-dessus ne s'agrandie pas Grrrrr^^
http://www.developpez.net/forums/d94...t/#post5300871


J'ai bêtement cru que le schéma de Fsmrel en découlait, et donc qu'un étudiant pouvait être promu plusieurs fois par an et par cours.

Autant pour moi.



Par ailleurs j'aimerai bien une petite précision :

Envoyé par FsmRel

Envoyé par CinePhil
C'est effectivement ce que je fais. Je trouve ça plus pratique.

Mais pas forcément valide...

Pour quelle(s) raison(s) ce ne serait pas valide ? (en se basant sur le schéma de Juliendusud)
Comment procédez-vous dans ce cas ? vous laissez l'entité-type "Date"

[fsmrel]

Oups, une erreur s'est glissée dans le diagramme, il faut ignorer la flèche descendante de Cours

La représentation graphique proposée par Julien est donc la suivante :

Pour quelle(s) raison(s) ce ne serait pas valide ? (en se basant sur le schéma de Juliendusud)
Comment procédez-vous dans ce cas ? vous laissez l'entité-type "Date"

La représentation graphique proposée par Julien correspond à la règle de gestion suivante :

RG01 - Un étudiant peut être promu plusieurs fois par an et par cours

Mais relisez son message :

Dans une école, on a des étudiants, des cours que ces étudiants reçoivent, et chaque année, il y a la promotion des étudiants. Chaque étudiant ne peut être promu qu'une seule fois par an et par cours , mais il peut être promu plusieurs fois au fil de ses études, et il peut être promu plusieurs fois sur une même année pour différents cours.

Il y a contradiction entre la règle correspondant à la représentation graphique et la règle écrite :

RG02 - Chaque étudiant ne peut être promu qu'une seule fois par an et par cours

Règle qui, comme je l’ai déjà dit, fait l’objet de la représentation graphique suivante :



Maintenant, si vous estimez que c’est la règle RG01 qui est valide, alors la date participe à l’identification de l’association-type PROMOTION et Merise vous contraint à mettre en œuvre une entité-type factice DATE (ou ANNEE ou ce que vous voulez), comme l'a fait Julien, ou encore à utiliser la représentation proposée par JPhi33.

Si vous estimez que c’est la règle RG02 qui est valide, alors la date ne peut pas participer à l’identification et elle fait l’objet d’une propriété portée par l’association-type PROMOTION.

That’s all.

[CinePhil]

La représentation graphique proposée par Julien est donc la suivante :





La représentation graphique proposée par Julien correspond à la règle de gestion suivante :

RG01 - Un étudiant peut être promu plusieurs fois par an et par cours

Ah bon ?
Selon moi l'identifiant de la table issue de l'association sera composé des 3 identifiants des trois tables issues des entités entrant en jeu dans l'association.
Les triplets {Etudiant, cours, année} seront donc uniques. On ne pourra pas avoir deux fois l'étudiant Fsmrel pour le cours Merise en 2010.

RG02 - Chaque étudiant ne peut être promu qu'une seule fois par an et par cours

Il me semble que cette représentation répond donc parfaitement à la règle de gestion.

Règle qui, comme je l’ai déjà dit, fait l’objet de la représentation graphique suivante :

Ce MCD veut dire selon moi qu'un étudiant ne peut être promu qu'une seule fois pour un cours et que l'association porte les données relatives à la date de la promotion et à la mention obtenue, ces données ne participant pas à l'identification de l'association.

[MacFly58]

J'ai relu tout ce sujet. Je pense qu'il comporte plusieurs erreurs qui découlent de l'erreur originelle suivante :

Fsmrel :

Un étudiant peut être promu plusieurs fois la même année pour différents cours,
Un étudiant ne peut être promu qu'une seule fois par an et par cours.

Alors la représentation conceptuelle suivante est nécessaire et suffisante :

Il me semble que ma première idée était justes et qu'il faudrait souligner la date dans le schéma de Fsmrel (ou créé une entité-type Date, ce qui revient au schéma de Julien).

Ce schéma me semble erroné car nous n'avons pas deux règles de gestion mais trois :

RG1 Chaque étudiant ne peut être promu qu'une seule fois par an et par cours
RG2 Chaque étudiant peut être promu plusieurs fois au fil de ses études
RG3 Chaque étudiant peut être promu plusieurs fois sur une même année pour différents cours

[fsmrel]

Selon moi l'identifiant de la table issue de l'association sera composé des 3 identifiants des trois tables issues des entités entrant en jeu dans l'association.

Fichtre ! Vous avez parfaitement raison. Ce que j’ai exprimé graphiquement est une règle trop restrictive, selon laquelle un étudiant ne peut être promu qu’une fois par cours. Je bats ma coulpe.

Ce schéma me semble erroné car nous n'avons pas deux règles de gestion mais trois
RG1 Chaque étudiant ne peut être promu qu'une seule fois par an et par cours
RG2 Chaque étudiant peut être promu plusieurs fois au fil de ses études
RG3 Chaque étudiant peut être promu plusieurs fois sur une même année pour différents cours

Supposons qu’un étudiant ne puisse être promu qu’une fois par cours (la règle trop restrictive). Il n’en demeure pas moins que les règles RG2 et RG3 sont respectées car la patte connectant l’entité-type ETUDIANT et l’association-type PROMOTION est porteuse d’une cardinalité maximale N, ce qui veut dire qu’une occurrence ETUDIANT peut participer plusieurs fois à l’association-type PROMOTION, donc qu’un étudiant peut être promu plusieurs fois.