Discussion :

[alexandremaneta]

Bonjour à tous,

Je dois réaliser un projet de base de données mais ce dernier s'avère être compliqué.
J'aimerais avoir des conseils vis à vis du projet et du MCD que j'ai construit.
Certains éléments ne sont pas encore présent mais la grosse partie du MCD est déja faite.

[SQLpro]

Je vois déjà une erreur majeure, cet héritage qui part de candidat.... Visiblement vous ne savez pas ce qu'est un héritage !

A +

[escartefigue]

Je vois déjà une erreur majeure, cet héritage qui part de candidat.... Visiblement vous ne savez pas ce qu'est un héritage !

A +

Oui et c'est d'autant plus dommage que vous auriez pu utiliser l'héritage pour un autre usage : vous avez modélisé 4 entité-type pour les différentes personnes (candidats, agents de sécurité, correcteurs et surveillants) alors que vous auriez pu, ou plutôt dû mutualiser ce qui leur est commun (nom, prénom...) dans une entité-type "personne" et utiliser l'héritage pour ce qui est spécifique à chacune d'entre elles

La relation ternaire "attribue" est suspecte, à quelle règle de gestion répond elle ? à exliquer

Le téléphone ne doit pas être attribut d'une personne, mais une entité-type spécifique, en relation 1,n ou 0,n avec l'entité-type personne :
PERSONNE 0,n --- communiquer --- (1,1) MEDIA 1,1 --- Typer --- 0,n TYPE_MEDIA

Vous pouvez avantageusement utiliser l'identification relative pour les salles, comme matérialisé ci-dessous par les parenthèses :
SALLE (1,1) --- situer --- 1,n BATIMENT

Je doute qu'un correcteur affecte une note à un module, la note concerne la copie d'une personne or votre module est décorrelé de la notion de personne (du candidat), ca ne va pas

[alexandremaneta]

Effectivement j'ai commis une erreur sur les héritages. Elles ne sont pas censées prendre des clés primaires puisqu'elles héritent de la table mère.

Je comprends votre remarque escartefigue mais en faisant cela, il faudrait alors rajouter une relation entre les modules et l'entité Personne pour signifier qu'elle surveille l'épreuve, me trompe-je ?

Merci pour vos remarques.

[alexandremaneta]

En ce qui concerne les notes, il faudrait créer une entité concernant une copie. Mais je ne vois pas réellement quels sont les liens qu'elle entretien avec les autres entités.
Et pour signifier qu'il y a un chef parmi les correcteurs et les surveillants en appliquant l'héritage sur la table personne, faut-il faire une relation réflexive sur les deux entités filles précédemment citées.
Et pour le moyen d'ouverture du bâtiment, je suis dans le flou le plus total, comment faut-il procéder ?

Bien cordialement.

[escartefigue]

Effectivement j'ai commis une erreur sur les héritages. Elles ne sont pas censées prendre des clés primaires puisqu'elles héritent de la table mère.

Effectivement et aussi, l'héritage doit concerner des sous-types qui partagent les attributs de l'entité mère
Or, si on examine votre sous-type "formation" par exemple, il ne partage certainement pas les attributs "nom" et "prénom" de l'entité-mère !
Il en va de même avec vos autres sous-types

Je comprends votre remarque escartefigue mais en faisant cela, il faudrait alors rajouter une relation entre les modules et l'entité Personne pour signifier qu'elle surveille l'épreuve, me trompe-je ?

Il faut que votre modèle permette de savoir quelle note a obtenu un candidat pour chacun des 10 modules liés à l'examen.

Une modélisation possible serait quelque-chose de ce genre :

CANDIDAT 0,n --- présenter --- 0,n EXAMEN 1,n --- inclure ---(1,1) MODULE
.....0,n.└-----------------------------------------------noter(note, date)----┘

Avec une CIF de type inclusion entre la relation "noter" et la relation "présenter" (un candidat ne peut obtenir une note que pour un module d'un examen qu'il présente )
L'identification du module relativement à l'examen, permet de mettre en œuvre cette contrainte

[alexandremaneta]

Oui et c'est d'autant plus dommage que vous auriez pu utiliser l'héritage pour un autre usage : vous avez modélisé 4 entité-type pour les différentes personnes (candidats, agents de sécurité, correcteurs et surveillants) alors que vous auriez pu, ou plutôt dû mutualiser ce qui leur est commun (nom, prénom...) dans une entité-type "personne" et utiliser l'héritage pour ce qui est spécifique à chacune d'entre elles

Très bien, je comprends. Par conséquent ce qui concerne la formation et le candidat ne doit pas être traduit par un héritage mais une relation.

CANDIDAT 0,n --- présenter --- 0,n EXAMEN 1,n --- inclure ---(1,1) MODULE
.....0,n.└-----------------------------------------------noter(note, date)----┘

En prenant en compte ces relations, il n'est donc plus nécessaire de créer une entité module puisque qu'il il y a un lien entre le module et le candidat ?
Corrigez moi si je me trompe dans l'interpétation

Merci pour votre aide précieuse

[escartefigue]

Le type d'entité "MODULE" est requis au contraire !

Commencez par le commencement en lisant quelques ouvrages de vulgarisation sur la modélisation.
Le tuto Merise peut vous y aider, c'est ici : https://www.developpez.net/forums/d3...ls-f-q-merise/

[alexandremaneta]

Mes excuses je ne voulais pas dire module mais plutôt COPIE en parlant de l'entité. Normalement, une note est attribuée par un correcteur à une copie . Or dans votre réponse je ne vois pas comment l'on peut connaître la personne qui attribué la note.

Merci, je m'empresse de lire l'ouvrage sur le lien que vous m'avez recommandé.

[escartefigue]

Pour ce qui concerne le sous ensemble candidat / notes / modules, voici une proposition

MCD :

Pièce jointe 335021


MLD résultant :

Pièce jointe 335025

A adapter en fonction de vos règles de gestion : un candidat peut il aussi être correcteur pour un autre examen ? un correcteur peut il être surveillant etc...

[alexandremaneta]

C'est très clair merci beaucoup de votre aide sur ce point.

En revanche une zone d'ombre persiste. Pour le moyen d'ouverture du bâtiment, il est dépendant d'un certain calendrier. Or sur les liens que vous m'avez donné, j'ai cru comprendre que les entités de "time/date" sont déconseillées mais je ne vois pas comment faire du coup. J'aurais tendance à faire une ternaire entre l'entité bâtiment, moyen d'ouverture et enfin l'entité relative au calendrier.
Ce ne sont là que des supputations. Peut-être existe-t-il un moyen plus facile dans la mise en forme de ces relations ?

Merci beaucoup.

[escartefigue]

Sur ce point, l'énoncé n'est pas clair, il est fait mention à la fois
- de la personne en charge de la sécurité
- des horaires d'ouverture
- du moyen d'ouvrir le bâtiment

C'est quoi le moyen ? mystère...

Pour la personne en charge, deux solutions

La plus simple est de considérer qu'on ne s'intéresse qu'à un et un seul responsable de la sécurité par bâtiment, auquel cas on peut modéliser :

PE_PERSONNE <--- AS_AGENT_SECURITE 0,n ---- securiser --- 1,1 BATIMENT 0,n --- contenir --- (1,1) SOUS_BATIMENT

Mais on peut également considérer qu'il y a un responsable sécurité, un ou plusieurs adjoints (sinon qui ouvre en l'absence du responsable ?), d'autres types de personnes (administrateur, responsable du nettoyage...) auquel cas il faut modéliser une entité-type "ROLE" et une relation à 3 comme suit :
PE_PERSONNE 0,n ---- gérer --- 1,1 BATIMENT 0,n --- contenir --- (1,1) SOUS_BATIMENT
....................................│
............ ROLE 0,n -------┘

Pour les horaires d'ouverture, il faut utiliser un calendrier.
Cf. l'artice suivant : http://sqlpro.developpez.com/cours/gestiontemps/

[UndeadangerousK]

Je pense qu'il y aura un problème de gestion sur les salles et les batiments. Je pense qu'il est nécessaire d'avoir un identifiant relatif car si le batiment A et le batiment B ont tout deux des salles identiques, on risque d'avoir un problème dans la base -> ici, le numéro de la salle est son identifiant. Donc une salle 210 ne peut pas etre situé dans deux batiments.

[escartefigue]

Je pense qu'il y aura un problème de gestion sur les salles et les batiments. Je pense qu'il est nécessaire d'avoir un identifiant relatif car si le batiment A et le batiment B ont tout deux des salles identiques, on risque d'avoir un problème dans la base -> ici, le numéro de la salle est son identifiant. Donc une salle 210 ne peut pas etre situé dans deux batiments.

C'est exactement ce que j'ai proposé dans mon post précédent : les cardinalités 1,1 entourées de parenthèses symbolisent justement l'identification du "sous-bâtiment" relativement au bâtiment dont il dépend. Cette symbolique est celle de Power-AMC, je ne l'avais pas précisé car c'est l'un des logiciels de modélisation les plus connus en entreprise

[UndeadangerousK]

C'est exactement ce que j'ai proposé dans mon post précédent : les cardinalités 1,1 entourées de parenthèses symbolisent justement l'identification du "sous-bâtiment" relativement au bâtiment dont il dépend. Cette symbolique est celle de Power-AMC, je ne l'avais pas précisé car c'est l'un des logiciels de modélisation les plus connus en entreprise

Au temps pour moi, j'ai zappé cette partie