Classe abstraite du diagramme UML au diagramme ER. Possible ? Comment?

Il existe essentiellement trois choix pour traduire la généralisation en un modèle de base de données

1. Un tableau par classe de béton

Créer des tables Admin , Teacher et Student . Chacune de ces tables contient des colonnes pour tous les attributs et relations de User

• Pro
  • Tous les champs d'une sous-classe concrète sont dans la même table, donc aucune jointure n'est nécessaire pour obtenir toutes les données des étudiants
  • Contraintes de validation des données faciles (telles que les champs obligatoires pour Student )
• Con
  • Tous les champs de User sont dupliqués dans chaque table de sous-classe
  • Clés étrangères vers User doivent être divisés en trois champs FK. Un pour Admin , un pour Teacher et un pour Student .

2. Sur table pour l'ensemble de généralisation

Dans ce cas, vous n'avez qu'un seul appel de table User qui contient tous les champs de User + tous les champs de toutes les sous-classes de User

• Pro
  • Tous les champs sont dans la même table, donc aucune jointure n'est nécessaire pour obtenir tous les User données
  • Aucun fractionnement des FK vers User
• Con
  • De nombreux champs ne sont jamais utilisés. Tous les champs spécifiques à Student et Teacher ne sont jamais remplis pour les Admins et vice versa
  • Validation des données telles que les champs obligatoires pour une classe concrète telle que Student devient assez complexe car il ne s'agit plus d'un simple Not Null contrainte.

3. Une table par classe concrète, et une pour la superclasse

Dans ce cas vous créez des tables pour chacune des sous-classes concrètes et vous créez une table pour la classe User . Chacune des tables de sous-classes concrètes a un FK obligatoire pour User

• Pro
  • Schéma le plus normalisé :pas de champs répétés pour les attributs de l'utilisateur et pas de champs inutilisés.
  • Aucun fractionnement des FK vers User
  • Contraintes de validation des données faciles (telles que les champs obligatoires pour Student )
• Con
  • Vous devez interroger deux tables si vous voulez toutes les données d'un Student
  • Des règles de validation complexes pour s'assurer que chaque User l'enregistrement a exactement un Admin , Teacher ou Student enregistrer.

Laquelle de ces options vous choisissez dépend d'un certain nombre de choses telles que le nombre de sous-classes, le nombre d'attributs dans la sous-classe ou la superclasse, le nombre de FK à la superclasse, et probablement quelques autres choses que je n'ai pas fait réfléchissez.