Comment sont super et le sous-type de relations dans ER diagrammes représentés comme des tables?

ER Notation

Il y a plusieurs ER les notations. Je ne suis pas familier avec celui que vous utilisez, mais il est assez clair que vous essayez de représenter un sous-type (aka. l'héritage, la catégorie, la sous-classe, la généralisation de la hiérarchie...). C'est le relationnel cousin de la programmation orientée objet à l'héritage.

Lors de sous-typage, vous sont généralement intéressés à la suite de décisions de conception:

• Abstrait vs concret: du parent sont instanciés? Dans votre exemple: un Vehicle existent sans également 2WD ou 4WD?¹
• Inclusive vs exclusif: Peut plus d'un enfant à être instancié pour le même parent? Dans votre exemple, peut Vehicle être les deux 2WD et 4WD?²
• Complet vs incomplète: attendez-vous à plus d'enfants d'être ajoutées dans le futur? Dans votre exemple, ne vous attendez une Bike ou un Plane (etc...) pourrait être ajouté plus tard pour le modèle de base de données?

L'Ingénierie de l'Information de la notation de la distinction entre inclusion et d'exclusion du sous-type de relation. IDEF1X notation, d'autre part, n'est pas (directement) de reconnaître cette différence, mais il ne se différencient entre complètes et incomplètes sous-type (IE n'est pas).

Le diagramme suivant de la ERwin Méthodes De Guide (Chapitre 5, sous-type de Relations) illustre la différence:

Ni IE ni IDEF1X directement autoriser abstrait vs concret parent.

Représentation Physique

Malheureusement, en pratique, les bases de données ne sont pas directement en charge de l'héritage, de sorte que vous aurez besoin de transformer ce schéma de vraies tables. Il y a généralement 3 approches:

1. Mettre toutes les classes de la même table et laisser l'enfant des champs NULL. Vous pouvez alors avoir une VÉRIFICATION pour s'assurer que le bon sous-ensemble des champs de la non-NULL.
   • Avantages: Pas de Rejoindre, de sorte que certaines requêtes peuvent bénéficier. Pouvez appliquer des parents au niveau des touches (par exemple, si vous voulez éviter les différentes 2WD et 4WD les véhicules ayant le même IDENTIFIANT). Pouvez facilement appliquer inclusive vs exclusive des enfants et abstrait vs concret parent (en variant juste le VÉRIFIER).
   • Inconvénients: Certaines requêtes peuvent être plus lents car ils doivent filtrer "inintéressant" des enfants. En fonction de votre SGBD, spécifique à l'enfant de contraintes peut être problématique. Beaucoup de Zéros peut de stockage des déchets. Moins adapté pour le sous-typage incomplète - l'ajout de l'enfant exige modifier la table existante, ce qui peut être problématique dans un environnement de production.
2. Mettre tous les enfants dans des tables distinctes, mais n'ont pas une table pour le parent (au lieu de cela, répétez les parents des champs et des contraintes pour l'ensemble des enfants). A la plupart des caractéristiques de (3), tout en évitant les Jointures, au prix de la baisse de la maintenabilité (à cause de tous ces champs et de la contrainte, répétitions) et l'incapacité à faire respecter parent-clés au niveau ou représenter un béton parent.
3. Mettre à la fois le parent et les enfants dans des tables distinctes.
   • Pour: Nettoyer. Pas de champs de contraintes doivent être artificiellement répété. Applique parent au niveau des clés et facile d'ajouter de l'enfant des contraintes spécifiques. Adapté pour le sous-typage incomplète (relativement facile d'ajouter plusieurs tables enfants). Certaines requêtes peuvent bénéficier en regardant uniquement "intéressant" table enfant(s).
   • Inconvénients: Certaines requêtes peuvent être REJOIGNEZ-lourds. Peut être difficile à appliquer inclusive vs exclusive des enfants et abstrait vs concret parents (ceux-ci peuvent être appliquées de manière déclarative si le SGBD prend en charge la circulaire et différés clés étrangères, mais de les faire respecter au niveau de l'application est généralement considérée comme un moindre mal).

Comme vous pouvez le voir, la situation est moins idéale, vous aurez besoin de faire des compromis en ce quelle que soit l'approche que vous choisissez. L'approche (3) devrait être votre point de départ, et ne choisissez l'une des options si il ya une raison impérieuse de le faire.

---

¹ je suppose que c'est ce que l'épaisseur de la ligne des stands pour dans vos diagrammes.

² je suppose que c'est ce que la présence ou l'absence de "disjoints" signifie dans vos diagrammes.

OriginalL'auteur Branko Dimitrijevic

Ce que d'autres intervenants, a déclaré, en plus de la suite qui va dans les clés primaires pour la sous-classe des tables.

Votre cas ressemble à une instance du modèle de conception connue comme “la Généralisation Spécialisation” , ou Gen-Spec pour faire court. La question de savoir comment gen-spec à l'aide de tables de base de données arrive tout le temps dans la.

Si vous avez été la modélisation gen-spec dans un OOPL tels que Java, vous pouvez utiliser l'héritage de classes facilité à prendre soin des détails pour vous. Il vous suffit de définir une classe pour prendre soin de la généralisation d'objets, puis de définir une collection de sous-classes, une pour chaque type de spécialisés de l'objet. Chaque sous-classe permettrait d'étendre la généralisation de la classe. Il est facile et simple.

Malheureusement, le modèle de données relationnel n'ont pas d'héritage de classes intégrées, et la base de données SQL systèmes n'offrent pas une telle installation, à ma connaissance. Mais vous n'êtes pas hors de la chance. Vous pouvez concevoir vos tables de gen-spec dans une manière qui est parallèle à la structure de classe de la programmation orientée objet. Ensuite, vous aurez à prendre des dispositions pour mettre en œuvre votre propre mécanisme d'héritage lorsque de nouveaux éléments sont ajoutés à la généralisation de la classe. Suivent des détails.

De la structure de classe est assez simple, avec une table pour le gen classe et une table pour chaque spec sous-classe. Voici une belle illustration, de Martin Fowler site web. La Classe De L'Héritage De Table. Noter que dans ce schéma, le joueur de Cricket est à la fois une sous-classe et une super-classe. Vous devez choisir les attributs à aller dans les tables. Le schéma montre un exemple d'attribut dans chaque table.

Le délicat détail la manière dont vous définissez les clés primaires de ces tables. La gen table de classe devient une clé primaire dans la manière habituelle (à moins que ce tableau est une spécialisation d'une autre généralisation, comme les Joueurs de cricket). La plupart des concepteurs de donner la clé primaire d'un nom standard, comme “Id”. Ils utilisent la fonctionnalité de numérotation automatique pour remplir le champ Id. La spécification de la classe de tableaux obtenir une clé primaire, ce qui peut être nommé “Id”, mais la numérotation automatique fonctionnalité n'est pas utilisée. Au lieu de la clé primaire de chaque sous-classe de la table est contraint de se référer à la clé primaire de la généralisation de la table. Cela rend chaque spécialisée clés primaires de la clé étrangère ainsi que d'une clé primaire. Notez que dans le cas de Joueurs de cricket, le champ Id de référence le champ Id dans les Joueurs, mais le champ Id dans les Quilleurs référence le champ Id dans les Joueurs de cricket.

Maintenant, lorsque vous ajoutez de nouveaux éléments, vous avez pour maintenir l'intégrité référentielle, Voici comment.

Vous d'abord insérer une nouvelle ligne dans le tableau, fournissant des données pour l'ensemble de ses attributs, à l'exception de la clé primaire. La numérotation automatique mécanisme génère une clé primaire unique. Ensuite, vous insérez une nouvelle ligne dans le spec de table, y compris les données pour l'ensemble de ses attributs, y compris la clé primaire. La clé primaire est une copie de la nouvelle marque de la clé primaire qui vient d'être généré. Cette propagation de la clé primaire peut être appelé “pauvre homme héritage”.

Maintenant, quand vous voulez toutes les données généralisé avec l'ensemble des données spécialisée à partir d'une seule sous-classe, tout ce que vous avez à faire est de joindre les deux tables sur la commune de les touches. Toutes les données qui ne sont pas liés à la sous-classe en question d'abandon de la jointure. Il est lisse, facile, et rapide.

OriginalL'auteur Walter Mitty