Discussion :

[arnobod]

Bonjour à tous,

Je suis étudiant en deuxième année de baccalauréat en informatique de gestion en Belgique. Pour un cours d'analyse, je suis chargé de la réalisation d'un MCD permettant la gestion d'un cinéma. Ayant déjà relu mon document, étant au début du cours, je me demandais quels conseils, remarques ou corrections vous pourriez me communiquer.

A bientôt

[MarieKisSlaJoue]

Le première chose qui me chose c'est ton association "faire référence à" avec du 1.1 de chaque coté. Et tu bien sur de savoir ce que représentent tes cardinalités ? du 1.1 de chaque coté, soit tu as de mauvaises cardinalités, soit tu as fait 2 tables pour rien. ce qu'il y as dans ton association "dépend" aussi. le Nom_employe ainsi que le satut_employe, il dépend de ton service aussi ? Il dépend plutôt de l'employe je pense il devrai donc être dans sa table. nombre_employer je le vois plutôt dans ta table service.
Du coup maintenant qu'il n'y à plus rien dans cette association. La cardinalité du coté de employe devrai plutôt être du 1.1 (sauf si il peu appartenir à plusieurs service cf ton énoncer)

Je me suis arrêté pour l'instant, mais je pense que tu devrais vérifier les formes normales ça pourrai d'aider à mieux comprendre où mettre quoi.

Edit : l'association "contiennent" à les même erreur que "dépend". Si tu as bien compris ce que j'ai dit (et si j'ai étais clair, car fatigué.) Tu devrais pouvoir la corriger.

[fsmrel]

Bonsoir,


Remarque concernant les noms

Une entité-type (symbolisée par un rectangle) n’est pas une énumération, mais par définition un type. Son nom doit donc figurer au singulier : il faudra renommer FILMS en FILM, ACTEURS en ACTEUR, EMPLOYES en EMPLOYE, SALLES en SALLE, etc.
Par voie de conséquence, il en va de même pour le nom des associations-types : renommer CONTIENNENT en CONTIENNE, et tant qu’à faire à l’infinitif : CONTENIR, et mieux encore en utilisant un verbe sémantiquement plus approprié, du genre JOUER (demandez conseil à CinePhil).


Remarque concernant les cardinalités

J’ai l’impression que vous utilisez la notation anglo-saxonne (de Chen) quand vous écrivez :



Un fidèle de Chen lit : une salle donnée possède une certaine capacité et une capacité donnée peut concerner plusieurs salles.

So far so good, mais dans le forum Schéma, 999 concepteurs sur 1000 utilisent la notation Merise (celle du reste de l’outil que vous utilisez) et celle-ci fonctionne dans l’autre sens : tel Dagobert vous devez donc remettre les choses à l’endroit :



Là encore, CinePhil peut vous aider à interpréter plus facilement cette représentation graphique.


Normalisation des associations

Comme dit le panda, le nom d’un employé ne dépend pas du Service mais seulement de l’employé : il doit être rapatrié dans l’entité-type EMPLOYE (même chose pour le statut, à moins que celui-ci soit aussi fonction du service) : en Merise on dit que l’on normalise l’association-type DEPENDRE (ne pas confondre la normalisation merisienne et la normalisation au sens du Modèle Relationnel de Données : la normalisation merisienne correspond disons à la deuxième forme normale du Modèle Relationnel de Données).


Données calculables

Le nombre d’employés correspond à une donnée calculable (cette donnée n'est pas essentielle, c'est-à-dire qu’on saura la calculer au niveau de la base de données à l’aide d’une fonction d’agrégation du genre COUNT) : la propriété Nombre_employes devrait disparaître. De toute façon, au nom de la normalisation merisienne, elle n’est pas à sa place car vous êtes en train de dire que pour chaque employé et chaque service, il faut fournir ce nombre. Si l’on matérialise l’association-type :

Code :

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

1
2
3
4
5
6
7
8
Employé    Service      Nombre employés

Albert     Entretien                 15
Bernard    Entretien                 15
Carole     Entretien                 15
...        ...                      ...
Albert     Secrétariat                8
Denis      Secrétariat                8

On se rend compte que pour chaque paire {employé, service} on fournit le nombre d’employés du service, ce qui est particulièrement redondant et évidemment à éviter.


Thésaurus des termes employés

Certains concepts sont interprétables sans difficultés (film, acteur, salle), d’autres laissent perplexes : merci de donner une définition des concepts moins courants (qu’est-ce par exemple que le pointage ? A quoi correspond le statut du client ? Client fidèle ? mauvais coucheur ?)


Divers

Un annuaire n’a pas de nom/prénom : en principe l’entité-type ANNUAIRE_CLIENT devrait être renommée en CLIENT, mais il existe déjà une entité-type portant ce nom. A quoi correspond ce distinguo ? Par ailleurs L’entité-type ANNUAIRE_CLIENT est bien sagement dans son coin, mais au vu des cardinalités on ne sait pas ce qu’un paiement détermine. Sont-ce des clients ? Merci d'expliquer cela posément, en détail.

Bon courage et bon apprentissage.

[CinePhil]

Voilà un sujet pour moi !

Il y a effectivement pas mal de choses confuses dans votre MCD !

Qu'est-ce qu'un "Service" ?
Au vu de ses propriétés, il semble qu'il s'agisse d'un sous-ensemble du personnel du cinéma, tel que "comptabilité", "direction", "cabine de projection", "caisse"...
Mais l'association de ce service avec les séances laisse perplexe car je vois mal le comptable assurer une séance (projeter le film ?), à moins qu'il s'agisse d'un ancien projectionniste et qu'il soit polyvalent !

Écrivez les règles de gestion des données de votre cinéma et corrigez votre MCD car il y aurait en l'état trop à dire.

Bon courage !