Discussion :

[goulehi_depaul]

Salut à tous ceux qui liront ce message. Je réalise en ce moment une base de données pour la gestion d'une école et ceci représente le module scolarité. comprenant ainsi les inscriptions, les notes, moyennes, les manuels scolaires et autres... Je l'ai conçu en Power Amc et je n'ai pas eu le temps de le mettre en pdf. Je voudrais que vous les professionnels, m'aidiez à réaliser un mcd optimal. Ainsi vos critiques seront les bien venus. J'attends aussi vos questions pour plus d'éclairage

Très cordialement,
depaul

[fsmrel]

Bonjour,


De l'urbanisation

Votre MCD est difficile à lire...

Un défi est de faire tenir les objets-types (entités-types et associations-types) sur une seule page A4. Pour vous, cela revient à « urbaniser » votre MCD, procéder à la mise en place de vues (sous forme de diagrammes) en fonction des différents sujets que ce MCD regroupe.

Par exemple, vous pouvez représenter un domaine tel que celui des classes, un autre qui serait celui des examens, etc.

Pour parvenir à cela (attention, j’utilise la V11 de PowerAMC, il peut y avoir des différences avec la V12 que je ne connais pas), sélectionnez :

Vue > Diagramme > Nouveau diagramme

Donnez un nom au nouveau diagramme, par exemple Classe.

Pour y faire figurer les objets-types :

Vue > Diagramme > Nouveau diagramme > Sélectionner un diagramme

(Vous pouvez aussi sélectionner le diagramme à partir de l’explorateur d’objets).

Le diagramme est vide. Pour y faire apparaître les objets-types :

Symbole > Afficher les symboles.

L’onglet Entité est sélectionné : cochez les cases correspondant à CLASSE, FILIERE, SERIE, NIVEAU, MATIERE. Pour aller plus vite, vous sélectionnez de préférence l’onglet Association et vous cochez les cases APPARTENIR1, APPARTENIR2 et APPARTENIR3, INSCRIPTION et DISPENSER : les entités-types connectées seront sélectionnées d'office.

Au résultat :



Même principe pour les examens, etc. :



Bien entendu, votre diagramme général n’est pas altéré.


Pertinence de l’association-type INSCRIPTION

Le diagramme Classe met en évidence un mouton à cinq pattes, cas très rare, à savoir l’association-type INSCRIPTION. Cette association-type est la rencontre indispensable d’une classe, d’un règlement, d’un établissement, d’une année scolaire et d’un élève.

Comment justifiez-vous par exemple le rôle que joue la classe par rapport au montant versé ? Si la classe n'a rien à voir dans le règlement de la facture, l'association-type est à casser...

Selon votre représentation, rien n’interdit qu’un élève fasse l’objet d’une inscription dans une classe d’un établissement qu’il ne fréquente pas, etc., etc.


A propos des identifiants

Un identifiant doit être invariant (affecté par le système, non modifiable) et non significatif (non porteur d’information). Par ailleurs, au niveau opérationnel (base de données en production), il doit occuper le moins de place possible, pour des raisons de performance des turbos (les index). Hâtez-vous de changer leur type et n’utilisez qu’INTEGER en la matière.

Si l'utilisateur a ses propres codifications, rien n'empêche d'en faire des identifiants alternatifs, modifiables par l'utilisateur, mais ce ne sont que des points d'entrée dans la base de données.


A propos du caractère facultatif des attributs

En théorie, les données sont facultatives, sauf pour les identifiants. Le défi est de les rendre obligatoires.


Sous-type NON CANDIDAT

Vous avez spécialisé l’entité-type ELEVE en CANDIDAT et NON CANDIDAT, Soit. Cela dit, au niveau opérationnel, on traînera une table NON CANDIDAT parfaitement inutile. Dans la fenêtre « Propriétés de l’entité NON CANDIDAT », décochez la case « Générer ».


Voilà pour le moment, affaire à suivre.