Discussion :

[Tamzoro]

Bonsoir,

Je suis actuellement en train de m'exercer à apprendre à produire un MCD correctement cependant, je rencontre quelques difficultés. Je suis parfaitement conscient que je n'ai pas du tout la bonne logique cependant j'aimerais bien avoir un retour afin que je puisse prendre note de mes erreurs. Je remercie d'avance celles et ceux qui pourront m'aider.

Énoncé de l'exercice:

Une école de conduite désir s'informatiser pour gérer plus facilement les élèves inscrits.

- il y aura une table nommée élèves, qui contiendra les champs suivants(id_eleve, numeroEleveCIN, Nom, Prénom, DateNaissance,Sexe, Adresse,Email,Profession, Téléphone).

il y a 2 types de leçons de conduite(code & pratique)

- la table CoursCode est présentée avec les champs suivants (id_Code, DateSeance, Prix)
- la table CoursPratique est composée des champs suivants (id_CoursPratique, DateCoursPratique, Prix)

- l'entité moniteur sera constituée ainsi (id_moniteur, nom, prénom)

- l'entité factures contiendra les champs suivants (id_facture, numero CIN, nom de l'élève, prénom de l'élève, le montant, nombre de séance du code, nombre de séance pratique)

- la table voitures sera présentée avec les champs suivants (id_voiture, marque, immatriculation)

- L'application sera gérée par un administrateur et par un employé

Voilà en résumé ce que j'aimerais bien réaliser correctement. Le truc c'est que je rencontre déjà deux soucis:

1) faut-il créer deux tables différentes pour l'administrateur et l'employé ? Comment faut-il présenter cela dans mon MCD ?
2) la table factures doit être reliée à l'entité élèves, coursCode, coursPratique c'est bien ça ? Car je suis perdu dans mon schéma...

Voici ci-dessous, mon MCD, je vous remercie pour le temps que vous allez me consacrer à me corriger.

[escartefigue]

Bonjour,

Il y a beaucoup à dire sur cet énoncé

- il est incomplet : il n'y a aucune règle de gestion qui permette d'établir les relation entre les types d'entité (et non pas les entités comme mentionné)
- il mélange des termes liés à la modélisation conceptuelle (les types d'entité) avec d'autres liés au modèle logique (les tables) et d'autres complètement hors sujets (les champs qui sont des notions liées aux formulaires ou aux états, pour les bases de données on parle d'attribut ou de colonne).
- il profère des énormités, par exemple, dire que l'entité(-type) facture contient le nom et le prénom de l'élève est une véritable hérésie en terme de modélisation
C'est le document facture qui comportera ces informations, mais certainement pas l'entité-type facture !

Si vous ne disposez vraiment que de cet énoncé, on ne peut faire que des suppositions

Quelques remarques tout de même
Entité-type PERSONNE
Si vous n'avez qu'une et une seule adresse pour une personne (encore une fois faute de règle de gestion il faut faire des hypothèses) vous pouvez en effet stocker l'adresse à ce niveau.
Par contre, il faut plusieurs attributs pour une adresse. Référez vous aux normes de codifications des adresses postales. Quelques clics dans un moteur de recherche vous donneront les réponses à ce sujet


Héritage
Avoir utilisé l'héritage pour les administrateurs et les employés, c'est bien sous réserve que ces sous-types possèdent des attributs qui leur soient propres, or ça ne semble pas être le cas
Par contre vous auriez pu utiliser l'héritage pour les élèves et les moniteurs qui sont également des personnes et qui ont peut être des attributs spécifiques.
De plus, avec l'héritage, le sous-type n'a pas d'identifiant propre : l'identifiant d'un administrateur ou d'un employé c'est l'identifiant de la personne.


partie Facturation
En principe, la facture est en relation avec une ou plusieurs lignes de facture que vous n'avez pas modélisées. Chaque ligne de facture est en relation avec une prestation suivie par un élève.
De plus la double relation entre FACTURE et ELEVE d'une part et FACTURE et PERSONNE d'autre part est suspecte.
Une facture doit concerner un et un seul client, ce client est très probablement l'élève dans votre cas.


Relation suit
L'élève suit un cours de code ou de conduite à une certaine date. L'attribut date n'est pas dépendant du cours seul mais de la relation entre l'élève et le cours. A déplacer donc dans la relation.


L'énoncé ne parle pas des forfaits souvent utilisés dans les auto-école, s'il s'agit d'un exercice scolaire pouquoi pas, mais dans la vraie vie c'est certainement un manque.

[Tamzoro]

Bonjour escartefigue,

Merci pour toutes tes explications, je vais dans un premier temps me documenter un peu plus sur le MCD/MLD.