Discussion :

[adreno]

bonjour,
je suis amené a réaliser un MCD pour la gestion d'un lycée(sa scolarité,note,élève...).
j'ai une entité "élève" avec une relation "inscription" la relation elle est porteuse de propriétés "année d'inscription et niveau" et la deuxième entité Branche.
un élève peut être inscrit dans une et une seule branche.
une branche peut avoir 1 ou plusieurs élève.
Ce que je veux savoir c'est est ce que cette conception est bonne.
et dans le passage vers le MLD les propriétés de la relation "année d'inscription et niveau" je vais les mettre ou??
Merci d'avance.

[CinePhil]

un élève peut être inscrit dans une et une seule branche.
une branche peut avoir 1 ou plusieurs élève.

Je dirais plutôt qu'une branche peut avoir 0 à plusieurs élèves.
On peut en effet décider en fin d'année scolaire 2008/2009 de créer une nouvelle branche pour la rentrée prochaine sans avoir encore d'élèves inscrits dans celle-ci. De plus, d'une manière générale, il vaut mieux éviter les cardinalités minimales à 1 des deux côtés d'une association car ça pose problème lors de l'implantation en BDD.

Ce que je veux savoir c'est est ce que cette conception est bonne.

En dehors de la remarque ci-dessus, et sans connaître les contraintes du cahier des charges, je dirais que oui.

et dans le passage vers le MLD les propriétés de la relation "année d'inscription et niveau" je vais les mettre ou?

Il y a plusieurs manières de voir les choses.
1) Un élève ne peut être inscrit que dans une branche et se fout de savoir s'il a déjà été inscrit dans une autre branche une autre année.
Alors les propriétés de l'association sont en fait des propriétés de l'élève.

MCD :
Eleve -1,1----Inscrire----0,n- Branche

Tables :
Branche (B_Id, B_Libelle, ...)
Eleve (E_Id, E_IdBranche, E_Nom, E_Prenom, E_AnneeInscription, E_Niveau, ...)

2) On garde en mémoire le parcours de l'élève.
On fait alors de l'inscription une entité à part entière.

MCD :
Eleve -0,n----Enregistrer----1,1- Inscription -1,1----Concerner----0,n- Branche

Tables :
Branche (B_Id, B_Libelle, ...)
Eleve (E_Id, E_Nom, E_Prenom, ...)
Inscription (I_Id, I_IdEleve, I_Id_Branche, I_Annee, I_Niveau, ...)

3) On peut aussi considérer qu'un élève ne peut être inscrit qu'à une branche pour une année et mettre en place un mécanisme d'identification relative.

MCD :
Eleve -(0,n)----Inscrire----(0,n)- Branche

Tables :
Branche (B_Id, B_Libelle, ...)
Eleve (E_Id, E_Nom, E_Prenom, ...)
Inscription (I_IdEleve, I_Id_Branche, I_Annee, I_Niveau, ...)

La table Inscription est cette fois une table associative dotée d'une clé primaire triple composée des identifiants relatifs de l'élève et de la branche + l'année.

[adreno]

Merci pour ta réponse,

donc voulant enregistrer le parcours de l'élève je dois avoir une entité inscription.
on aura donc : un élève peut enregistrer 0.n inscription.
une inscription peut être enregistrée par 1,1 élève
une inscription concerne 1.1 branche
une branche peut avoir 0.n inscription.
c'est ça?
et si j'ai bien compris c'est quand on souhaite garder en mémoire une information je dois l'avoir obligatoirement sous forme d'une entité a part??
si tous ça est juste ça me donne l'exemple en pièces jointes

[JPhi33]

Bonjour,

et si j'ai bien compris c'est quand on souhaite garder en mémoire une information je dois l'avoir obligatoirement sous forme d'une entité a part??

Non, ce qui est gardé en mémoire, c'est la totalité du MCD, pour peu qu'il fasse l'objet d'une implémentation en base de données après transformation en MLD puis MPD.

si tous ça est juste ça me donne l'exemple en pièces jointes

L'entité note n'est pas justifiée. D'ailleurs, quelles sont les occurrences de id_note ? Dans un MCD, toute propriété DOIT être porteuse d'une sémantique bien définie. S'il s'agit d'ajouter une clé pour des besoins d'implémentation en bdd, c'est l'affaire du MPD, à la rigueur du MLD mais certainement pas du MCD.

En réalité, dans cette entité, les propriétés ayant une valeur sémantique sont note_cc (contrôle continu ?) et note_exam. Grossièrement, un élève a un couple de notes (note_cc, note_exam) par semestre et par matière. La représentation est donc la suivante.

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
 [ ELEVE ]
     |
    0,n
     |
     |
 ( NOTE )----0,n--[ SEMESTRE ]
     |
     |
    0,n
     |
[ MATIERE ]


Légende :
[ ENTITE ]
( ASSOCIATION )

[CinePhil]

Je ne suis pas d'accord avec ça :

S'il s'agit d'ajouter une clé pour des besoins d'implémentation en bdd, c'est l'affaire du MPD, à la rigueur du MLD mais certainement pas du MCD.

Une bonne clé est de type entier non signé, non nulle, et auto-incrémentée.
Si on considère par exemple qu'un véhicule est identifié par son numéro d'immatriculation, celui-ci deviendra, selon ton principe, la clé de l'entité Véhicule dans le MCD.
A la génération du MLD à partir du MCD à l'aide d'un logiciel de modélisation, cette clé deviendra celle de la future table et servira aussi de clé étrangère dans les autres tables associées.
Et comme le numéro d'immatriculation est de type VARCHAR, c'est une mauvaise clé.

Il vaut donc mieux mettre les bonnes clés identifiantes dès le MCD afin de ne pas avoir à corriger le MLD plus tard.

[adreno]

bonjour,
Merci pour vos réponses.

Et comme le numéro d'immatriculation est de type VARCHAR, c'est une mauvaise clé.

ça veut dire que la bonne clé dans un MCD doit être de type entier non signé, non nulle, et auto-incrémentée forcément.

En réalité, dans cette entité, les propriétés ayant une valeur sémantique sont note_cc (contrôle continu ?) et note_exam. Grossièrement, un élève a un couple de notes (note_cc, note_exam) par semestre et par matière. La représentation est donc la suivante.

Dans ce cas je dois mettre l'entité note sous forme d'une association porteuse des deux propriétés note_cc(effectivement contrôle continu) et note_exam.

D'après ce qu'on dit et ce que je connais un MCD n'a pas de règles fixes et chacun comment est ce qu'il voit la conception et la modélisation de sa manière.
Mais ce que je veux savoir aussi c'est ce mélange qu'on fait entre le MPD et le MLD!!!?? est ce la même chose??

[JPhi33]

Bonjour à tous,

Une bonne clé est de type entier non signé, non nulle, et auto-incrémentée.

On parle de MCD et, dans ce cadre, ce genre de discours est malheureusement propre à jeter la confusion dans les esprits des personnes peu averties ou débutantes.


MCD

Essayons d'y voir plus clair. Le cycle d'abstraction Merise nous aide à remettre les choses à leur place en nous rappelant quelle est la préoccupation de chaque niveau (ou couche), s'agissant des données :

• Niveau conceptuel (MCD). QUOI. Limites du domaine et vocabulaire de l'entreprise - Invariant par rapport au SGBD et à la répartition des données
• Niveau logique (MLD). D'OÙ, QUI, QUAND. Etat de l'art technologique - Invariant par rapport au SGBD
• Niveau physique (MPD) : OÙ, COMMENT. Adapté au SGBD.

Merise/2 nomme les deux derniers niveaux différemment (i.e. Organisationnel, Logique) mais les invariants restent les mêmes.

Lorsqu'on parle d'entité, on se situe au niveau conceptuel. Ce qui guide la réflexion dans la construction d'un MCD, c'est le QUOI. On raisonne sur la sémantique des données. La question du format de ces données ne doit pas être évoqué, ce n'est pas la préoccupation de ce niveau.
La raison en est simple. Un MCD doit pouvoir aboutir à la construction de la base de données quel que soit le SGBD choisi (respect de l'invariant). C'est pourquoi des termes comme type entier ou auto-incrémenté ne peuvent pas faire partie des préoccupations de ce niveau. Tout au plus, on peut donner une indication macroscopique de type : date, montant, texte, etc.


Identifiant d'une entité conceptuelle

Une entité conceptuelle n'a pas de clé, elle a un identifiant. Bien que certains auteurs utilisent le terme de clé pour l'entité, le concept sous-jacent reste celui d'identifiant. C'est donc une contradiction que de parler de "clé de l'entité Véhicule dans le MCD".

Pour autant, il n'est pas dit qu'un identifiant conceptuel ne doive pas respecter certaines règles.
Les voici, selon MOREJON dans Merise, Vers une modélisation orientée objet (Les Editions d'Organisation, 1995), qu'il reprend de SIBERTIN-BLANC dans L'identification des occurrences d'entités dans le formalisme individuel (Journée AFCET, 1990).

1. L'identifiant d'une entité est une propriété (ou un ensemble de propriétés) dont chaque valeur caractérise au plus une occurrence de l'entité. Il s'agit d'une fonction de caractérisation depuis l'ensemble des valeurs de l'identifiant dans l'ensemble des occurrences.
2. Cette fonction est stable : une valeur de l'identifiant est toujours associé à la même occurrence.
3. Cette fonction est injective : des valeurs distinctes de l'identifiant sont toujours associées à des occurrences distinctes de l'entité. Donc une occurrence ne peut être caractérisée par deux identifiants.

On trouve aussi des définitions moins précises, par exemple :

• Une entité est identifiée à l'aide d'une propriété particulière appelée identifiant. La valeur d'une occurrence d'identifiant identifie de façon unique une occurrence d'entité. (TARDIEU, ROCHFELD, COLLETTI dans La méthode Merise, Les Editions d'Organisation, 1989)
• Nous utilisons un sous-ensemble de propriétés constitutives de l'entité permettant de distinguer chaque ligne des autres. Ce sous-ensemble est le plus petit possible. Il est appelé identifiant de l'entité. C'est lui qui désigne sans ambiguïté l'occurrence. (ANDRE, VAILLY, Conception des systèmes d'information, ellipses 2001)

On remarquera qu'aucune de ces définitions n'impose un format précis aux identifiants. A ma connaissance, aucune définition n'impose que tous les identifiants soient numériques de type entier non signé, non nul, et auto-incrémenté.

Par contre, si, dans une table, le format de la clé, issue d'un identifiant, ne donne pas entière satisfaction vis-à-vis des performances, par exemple, il n'est pas interdit de créer une clé alternative qui, elle, pourra avoir toutes les caractéristiques d'une bonne clé, c'est-à-dire numérique de type entier non signé, non nulle et auto-incrémentée.

Si on considère par exemple qu'un véhicule est identifié par son numéro d'immatriculation, celui-ci deviendra, selon ton principe, la clé de l'entité Véhicule dans le MCD.
A la génération du MLD à partir du MCD à l'aide d'un logiciel de modélisation, cette clé deviendra celle de la future table et servira aussi de clé étrangère dans les autres tables associées.
Et comme le numéro d'immatriculation est de type VARCHAR, c'est une mauvaise clé.

Cet exemple est bien mal choisi car le numéro d'immatriculation (qu'il soit VARCHAR ou autre) est un mauvais identifiant. En effet, il contrevient à la règle 3 puisque chacun sait qu'un véhicule peut changer plusieurs fois d'immatriculation au cours de sa vie.

[adreno]

bonjour,
Donc :

Au niveau MCD on parle d'entité et 'association,identifiants,attributs.
Au niveau MLD on parle de relation puisque c'est qui fait l'action et quand
et d'où vient l'action (relationnel).
Au niveau MPD c'est l'implémentation du MLD dans le SGBD ,la on parle de clé primaire,champs et de tables. c'est ce qui explique le ou et le comment???