Comment modéliser efficacement l'héritage dans une base de données ?

Question

Quelles sont les meilleures pratiques pour modéliser l'héritage dans les bases de données ?

Quels sont les compromis (par exemple, la possibilité d'interrogation) ?

(Je suis surtout intéressé par SQL Server et .NET, mais je veux aussi comprendre comment les autres plateformes abordent cette question).

Answer 1

Il existe plusieurs façons de modéliser l'héritage dans une base de données. Celle que vous choisissez dépend de vos besoins. Voici quelques options :

Table-Par-Type (TPT)

Chaque classe a son propre tableau. La classe de base contient tous les éléments de la classe de base, et chaque classe qui en dérive possède sa propre table, avec une clé primaire qui est également une clé étrangère à la table de la classe de base ; la classe de la table dérivée contient uniquement les différents éléments.

Donc, par exemple :

class Person {
    public int ID;
    public string FirstName;
    public string LastName;
}

class Employee : Person {
    public DateTime StartDate;
}

Cela donnerait des tableaux comme :

table Person
------------
int id (PK)
string firstname
string lastname

table Employee
--------------
int id (PK, FK)
datetime startdate

Table-Par-Hiérarchie (TPH)

Une seule table représente toute la hiérarchie de l'héritage, ce qui signifie que plusieurs des colonnes seront probablement clairsemées. Une colonne de discrimination est ajoutée pour indiquer au système de quel type de ligne il s'agit.

Compte tenu des classes ci-dessus, vous obtenez ce tableau :

table Person
------------
int id (PK)
int rowtype (0 = "Person", 1 = "Employee")
string firstname
string lastname
datetime startdate

Pour toutes les lignes dont le type de ligne est 0 (Personne), la date de début sera toujours nulle.

Table-Par-Béton (TPC)

Chaque classe a son propre tableau entièrement formé, sans référence à d'autres tableaux.

Compte tenu des classes ci-dessus, vous obtenez les tableaux suivants :

table Person
------------
int id (PK)
string firstname
string lastname

table Employee
--------------
int id (PK)
string firstname
string lastname
datetime startdate

Answer 2

Une bonne conception de base de données n'a rien à voir avec une bonne conception d'objet.

Si vous prévoyez d'utiliser la base de données pour autre chose que la simple sérialisation de vos objets (comme des rapports, des requêtes, une utilisation multi-applications, de la business intelligence, etc.), je ne recommande pas un simple mappage des objets aux tables.

De nombreuses personnes considèrent qu'une ligne d'une table de base de données est une entité (j'ai passé de nombreuses années à penser en ces termes), mais une ligne n'est pas une entité. C'est une proposition. Une relation de base de données (c'est-à-dire une table) représente une déclaration de fait sur le monde. La présence de la ligne indique que le fait est vrai (et inversement, son absence indique que le fait est faux).

Avec cette compréhension, vous pouvez voir qu'un seul type dans un programme orienté objet peut être stocké dans une douzaine de relations différentes. Et une variété de types (unis par l'héritage, l'association, l'agrégation, ou complètement non affiliés) peuvent être partiellement stockés dans une seule relation.

Il est préférable de se demander quels sont les faits que vous souhaitez conserver, les questions auxquelles vous souhaitez obtenir des réponses et les rapports que vous souhaitez générer.

Une fois que la conception appropriée de la base de données est créée, il est facile de créer des requêtes/vues qui vous permettent de sérialiser vos objets dans ces relations.

Exemple :

Dans un système de réservation d'hôtel, vous devrez peut-être enregistrer le fait que Jane Doe a réservé une chambre au Seaview Inn du 10 au 12 avril. S'agit-il d'un attribut de l'entité client ? Est-ce un attribut de l'entité hôtel ? S'agit-il d'une entité de réservation dont les propriétés incluent le client et l'hôtel ? Dans un système orienté objet, il peut s'agir de tout ou partie de ces éléments. Dans une base de données, ce n'est rien de tout cela. Il s'agit simplement d'un simple fait.

Pour voir la différence, considérez les deux requêtes suivantes. (1) Combien de réservations d'hôtel Jane Doe a-t-elle pour l'année prochaine ? (2) Combien de chambres sont réservées pour le 10 avril au Seaview Inn ?

Dans un système orienté objet, la requête (1) est un attribut de l'entité client, et la requête (2) est un attribut de l'entité hôtel. Ce sont les objets qui exposent ces propriétés dans leurs API. (Même si, évidemment, les mécanismes internes par lesquels ces valeurs sont obtenues peuvent impliquer des références à d'autres objets).

Dans un système de base de données relationnelle, les deux requêtes examineraient la relation de réservation pour obtenir leurs numéros et, d'un point de vue conceptuel, il n'est pas nécessaire de se préoccuper d'une autre "entité".

Ainsi, c'est en essayant de stocker des faits sur le monde - plutôt qu'en essayant de stocker des entités avec des attributs - qu'une base de données relationnelle correcte est construite. Et une fois qu'elle est correctement conçue, des requêtes utiles qui n'avaient pas été imaginées pendant la phase de conception peuvent être facilement construites, puisque tous les faits nécessaires pour répondre à ces requêtes sont à leur place.

Answer 3

Réponse courte : vous ne le faites pas.

Si vous avez besoin de sérialiser vos objets, utilisez un ORM, ou encore mieux quelque chose comme activerecord ou prevaylence.

Si vous avez besoin de stocker des données, stockez-les de manière relationnelle (en faisant attention à ce que vous stockez, et en prêtant attention à ce que Jeffrey L Whitledge vient de dire), et non pas de manière affectée par votre conception d'objet.

Answer 4

Il existe deux principaux types d'héritage que vous pouvez configurer dans une BD, la table par entité et la table par hiérarchie.

La table par entité consiste à avoir une table d'entité de base qui a des propriétés communes à toutes les classes enfantines. Vous avez ensuite une autre table par classe enfant, chacune contenant uniquement les propriétés applicables à cette classe. Elles sont liées 1:1 par leurs PK.

La table par hiérarchie est celle où toutes les classes partagent une table, et les propriétés optionnelles sont nullables. Il existe également un champ discriminant qui est un nombre indiquant le type de l'enregistrement actuel.

SessionTypeID est un discriminateur

La cible par hiérarchie est plus rapide à interroger car vous n'avez pas besoin de jointures (seulement la valeur du discriminateur), alors que la cible par entité vous devez faire des jointures complexes afin de détecter le type de quelque chose et de retrouver toutes ses données

Edit : Les images que je montre ici sont des captures d'écran d'un projet sur lequel je travaille. L'image de l'actif n'est pas complète, d'où sa vacuité, mais c'était principalement pour montrer comment il est configuré, pas ce qu'il faut mettre dans vos tables. C'est à vous de voir ;). La table de session contient les informations de la session de collaboration virtuelle, et peut être de plusieurs types de sessions selon le type de collaboration impliqué.

Answer 5

Vous normaliseriez votre base de données et cela refléterait votre héritage. Il pourrait y avoir une dégradation des performances, mais c'est ainsi que cela se passe avec la normalisation. Vous devrez probablement faire preuve de bon sens pour trouver l'équilibre.