Études de cas avancés (Correction)

Schéma conceptuel global

Schéma Conceptuel

  • Il y a une relation d’héritage inclusive entre Stagiaire/Enseignant et Personne.
  • Il y a une relation d’héritage excluvise entre Vacataire/Permament et Enseignant.

Alternatives A - Enseignants et départements

Niveau conceptuel

Niveau conceptuel

Niveau logique

Niveau logiquel

Gestion de l’héritage

L’héritage enseignant/vacataire/permanent est traité avec la première solution (une table par classe participant à l’héritage) présentée dans le TD précédent, voir cas de l’héritage.

La gestion de l’héritage ne se fait pas facilement. Plusieurs choix sont possibles avec leurs avantages et inconvénients. Observons l’exemple ENSEIGNANT, VACATAIRE_EXTERIEUR, PERMANENT.

Solution 1 : On garde la classe mère et la classe fille - Solution choisie

ENSEIGNANT(id, nom, prenom, adresse, mail)

VACATAIRE_EXTERIEUR(id, employeur_principal) où id référence ENSEIGNANT(id)

PERMANENT(id, appelation) où id référence ENSEIGNANT(id)

  • La relation ENSEIGNANT factorise les informations communes.
  • Inconvénient : un enseignant peut être répertorié à la fois comme vacataire et permanent. L’héritage exclusif n’est donc pas garanti.

Solution 2 : On ne garde que les classes filles

VACATAIRE_EXTERIEUR(id, nom, prenom, adresse, mail, employeur_principal)

PERMANENT(id, nom, prenom, adresse, mail, appelation)

  • Inconvénient : il n’y a plus de relation qui factorise les informations communes et la liste de tous les enseignants devient la liste des permanents + celle des vacataires.

Solution 3 : On ne garde que la classe mère

ENSEIGNANT(id, nom, prenom, adresse, mail, statut, employeur_principal, appelation)

  • Avantage : ça a l’air la plus simple
  • Inconvénients : il faut gérer des contraintes en fonctions du status et on aura plus de valeur NULL pour certains attributs. On ne peut plus différencier des associations spécifiques à l’un des deux classes (par exemple l’appartenance à un département).

Gestion de plusieurs associations entre deux classes

Observons l’exemple des membres et chefs de département. Il existe deux associations entre les classes Permanentet Département.

  • L’association appartient est une association 1-N, son traitement est classique et ne pose aucun problème : clé étrangère id_departement dans la table permanent.
  • Pour l’association a pour chef, ici aussi, deux solutions sont possibles avec aucune solution ne respecte totalement la contrainte exprimée au niveau conceptuel :

Solution 1

PERMANENT(id, ref_departement, chef) où ref_departement référence DEPARTEMENT(id)

DEPARTEMENT(id, nom)

On ajoute dans la table permanent une colonne chef de type booléen.

  • Inconvénient : on n’a pas de contrôle sur la cardinalité 1..1 : on ne peut pas contraindre dans la base de données ni le nombre maximal de chefs (1) ni le nombre minimal (1 aussi). Dans les cas extrêmes, tous les membres d’un département ont la valeur true pour la colonne chef, ou tous les membres ont la valeur false (c’est-à-dire que personne n’est désigné comme chef).
  • Avantages :
    • En revanche, la cardinalité O..1 est gérée correctement : chaque permanent peut être chef d’aucun département (valeur null possible) ou d’un seul au maximum.
    • On est sûr de respecter la contrainte “le chef est membre du département dont il est chef”.

Solution 2 :

PERMANENT(id, ref_departement) où ref_departement référence DEPARTEMENT(id)

DEPARTEMENT(id, nom, ref_chef) où ref_chef référence PERMANENT(id)

  • Inconvénients :
    • Il y a aussi un problème de gestion des cardinalités qui est inverse de la solution précédente. La cardinalité O..1 n’est pas gérée correctement : un permanent peut être chef de plusieurs départements (N départements peuvent pointer sur le même permanent).
    • On n’est pas sûr de respecter la contrainte “le chef est membre du département dont il est chef”.
  • Avantage :
    • On est ici sûr de la cardinalité 1..1 : en positionnant une contrainte not null sur la colonne ref_chef dans la table departement, on s’assure bien qu’il y a au moins 1 chef. De plus, comme on ne peut y mettre qu’une seule référence, on assure également qu’au maximum un seul permanent peut être chef.

Alternatives B - Modules

Niveau conceptuel

Schéma Conceptuel

A noter que si le choix est fait de dire qu’une activité peut-être associée à plusieurs modules, il est alors nécessaire de conserver une association entre séance et module afin de pouvoir savoir à quel module est affectée la séance. Toujours dans ce même cas, l’ordre doit alors être géré par une association portée.

Niveau logique - Solution 1 (Gestion de la cardinalité 1..2)

PERMANENT(id, appelation)

MODULE(id, titre, ref_responsable1, ref_responsable2) où ref_responsable1 référence PERMANENT(id) et ref_responsable2 référence PERMANENT(id)

  • Avantage :
    • contrôle de la cardinalité.
  • Inconvénient :
    • l’application ne peut pas facilement évoluer vers plus de responsables.

Niveau logique - Solution 2 (Gestion de la cardinalité 1..2)

PERMANENT(id, appelation)

RESPONSABLE(ref_responsable, ref_module) où ref_responsable référence PERMANENT(id) et ref_module référence MODULE(id)

MODULE(id, titre)

  • Avantage :
    • l’application peut facilement évoluer sur le nombre de responsables.
  • Inconvénient :
    • aucun contrôle de la cardinalité au niveau du schéma, il faut rajouter des contraintes au niveau applicatif.

Alternative C - Stagiaires

Schéma Conceptuel)

Schéma Logique Global

STAGIAIRE(id, nom, prenom, adresse, mail, ref_formation) où ref_formation référence FORMATION(id)

ENSEIGNANT(id, nom, prenom, adresse, mail)

VACATAIRE_EXTERIEUR(id, employeur_principal) où id référence ENSEIGNANT(id)

PERMANENT(id, appelation, ref_departement) où id référence ENSEIGNANT(id) et ref_departement référence DEPARTEMENT(id)

DEPARTEMENT(id, nom, ref_chef) où ref_chef référence PERMANENT(id)

FORMATION(id, titre)

MODULE(id, titre, ref_responsable1, ref_responsable2, ref_formation) où ref_responsable1 référence PERMANENT(id), ref_responsable2 référence PERMANENT(id) et ref_formation référence FORMATION(id)

ACTIVITE(id, titre, type, ordre, ref_modules) où ref_module référence MODULE(id)

SEANCE(id, titre, salle, date, ref_activite) où ref_activité référence ACTIVITE(id)

ENCADRE(ref_enseignant, ref_seance) où ref_enseignant référence ENSEIGNANT(id) et ref_seance référence SEANCE(id)