Étude de cas simple (Correction)

Modélisation conceptuelle des données en UML

Dérivation d’un modèle conceptuel en schéma logique

Cas d’une cardinalité 1-N (un à plusieurs)

Niveau Conceptuel

Niveau logique

Script SQL correspondant

  create table module (
    id    integer     primary key,
    titre varchar(30) not null
  );

  create table seance (
    id        integer     primary key,
    titre     varchar(50) not null,
    id_module integer references module(id)
  );

Principes :

• Une clé primaire (Primary Key en anglais) est créée pour les relations (tables) seance et module : ici une valeur numérique nommée id.
• On introduit la clé primaire de la relation du côté de la cardinalité 1 (module), comme clé étrangère / référentielle(Foreign Key en anglais) dans la relation du côté de la cardinalité N (seance).
• La dérivation du niveau conceptuel vers le niveau logique est ici non ambigüe.

Le passage du niveau logique vers le niveau physique est montré ici avec un script SQL de création des tables qui utilise la syntaxe du SGBD PostgreSQL.

Cas d’une cardinalité N-M (plusieurs à plusieurs)

Niveau Conceptuel

Niveau logique

Script SQL correspondant

  create table stagiaire ( ... );

  create table module ( ... );

  create table inscription (
    id_stagiaire integer references stagiaire(id),
    id_module   integer references session(id),
    primary key (id_stagiaire, id_module)
  );

Principe :

• Création d’une table d’association (table intermédiaire), la table inscription, dont le but est de stocker les couples (identifiant de stagiaire, identifiant de session). Chaque élément du couple est clé étrangère vers les deux autres tables et la clé primaire de cette nouvelle table est le couple.
• La dérivation du niveau conceptuel vers le niveau logique est, comme pour une association 1-N, non ambigüe.

Cas de l’héritage

Niveau Conceptuel

Niveau logique (Solution 1) - Solution choisie

Niveau logique (Solution 2)

Niveau logique (Solution 3)

Le gestion de l’héritage dans un base de données se fait de manière imparfaite. Trois solutions sont possibles :

Solution 1 : on crée autant de tables que de classes qui participent à l’héritage, ici trois. Chaque table correpondant à une sous-classe possède une colonne qui a une contrainte de clé primaire et une contrainte de clé étrangère vers la table représentant la classe mère.

• Avantage : c’est la solution qui se rapproche le plus de la sémantique de l’héritage dans le modèle objet. La table qui correspond à la classe mère factorise les informations communes aux deux sous-classes.
• Inconvénient (ou pas…) : l’héritage est ici inclusif : une personne donnée peut être, à la fois, un stagiaire et un enseignant. En Java, l’héritage est exclusif : une personne est soit un stagiaire soit un enseignant.

Solution 2 : on crée autant de tables que de sous-classes. On ne factorise plus les données de la classe mère dans une table, les données sont réparties dans les tables qui correspondent aux sous-classes.

• Avantage : la solution est plus simple.
• Inconvénient (ou pas…) : - La factorisation des données communes n’existe plus. - L’héritage est exclusif : une personne est soit un stagiaire soit un enseignant.

Solution 3 : on ne crée qu’une seule table qui correspond à la classe mère. Les attributs des sous-classes (ici, l’ attribut appellation propre aux enseignants) sont remontés dans l’unique table. Une colonne est créée, colonne type ici, afin de permettre de connaître l’appartenance à la sous classe : les valeurs prises dans cette colonne peuvent fixées par une énumération (ou équivalent). Ici les valeurs possibles seront : stagiaire ou enseignant.

• Avantages :
  • La solution est encore plus simple que la solution 2.
  • La représentation correspond à un héritage exclusif : une personne est soit un stagiaire soit un enseignant, pas les deux.
• Inconvénient (ou pas…) : la gestion des attributs propres aux sous-classes peut être problématique. Les colonnes représentants les attributs sont remontées dans la table représentant la classe mère et sont donc présentes pour l’autre sous-classe. Elles doivent prendre la valeur null dans ce cas (c’est la cas ici pour la colonne appellation qui n’a aucun sens pour un stagiaire). Si ces colonnes ne peuvent pas prendre la valeur nulle, alors cette solution n’est pas adaptée.

Pour la gestion de l’héritage, la solution 1 ou la solution 3 sont généralement préférées.

Schéma logique global

Pour le schéma logique global, la gestion de l’héritage choisie est la solution 1.