Est-ce une mauvaise pratique d'avoir plusieurs relations un à un mutuellement exclusives?
Par exemple, une table car a une relation univoque avec les tables electric_car, gas_car, et hybrid_car. Si un car est electric_car, il ne peut plus apparaître dans gas_car ou un hybrid_car, etc.
Y a-t-il quelque chose de mal avec une telle conception? Des problèmes qui peuvent survenir en cours de route?
Les différents types de voitures sont un exemple d'un problème général qui refait surface à maintes reprises dans la modélisation des données. Elle est appelée "généralisation/spécialisation" dans la modélisation ER et "superclasse/sous-classe" dans la modélisation d'objet.
Un modeleur d'objet utilise les fonctionnalités d'héritage intégrées au modèle d'objet pour résoudre le problème assez facilement. Les sous-classes étendent simplement la superclasse.
Le modeleur relationnel est confronté à un problème. comment concevoir les tables de manière à imiter les avantages que l'on retirerait de l'héritage?
La technique la plus simple est appelée héritage de table unique . Les données sur tous les types de voitures sont regroupées dans un seul tableau pour les voitures. Il existe une colonne, car_type, qui regroupe toutes les voitures d'un même type. Aucune voiture ne peut appartenir à plus d'un type. Si une colonne n'est pas pertinente pour, disons, les voitures électriques, elle sera laissée NULL dans les lignes qui concernent les voitures électriques.
Cette solution simple fonctionne bien pour les cas plus petits et plus simples. La présence d'un grand nombre de valeurs NULL ajoute un tout petit peu à la surcharge de stockage et un peu à la surcharge de récupération. Le développeur devra peut-être apprendre logique à trois valeurs SQL si les tests booléens sont effectués sur des colonnes nullables. Cela peut être déroutant au début, mais on s'y habitue.
Il existe une autre technique, appelée héritage de table de classe . Dans cette conception, il existe des tables distinctes pour gas_car, electric_car et hybrid_car, en plus d'une table combinée, car, pour chacune d'entre elles. Lorsque vous voulez toutes les données sur un type spécifique de voiture, vous joignez la table de voiture avec la table spécialisée appropriée. Il y a moins de NULL dans cette conception, mais vous faites plus de jointures. Cette technique fonctionne mieux dans les cas plus grands et plus complexes.
Il existe une troisième technique appelée clé primaire partagée. Cette technique est souvent utilisée en conjonction avec l'héritage de table de classe. Les tables spécialisées pour les sous-classes ont, comme clé primaire, une copie de la clé primaire de l'entrée correspondante dans la table car. Cette colonne id peut être déclarée à la fois comme clé primaire et comme clé étrangère.
Cela implique un peu de programmation supplémentaire lorsque de nouvelles voitures doivent être ajoutées, mais cela rend les jointures simples, faciles et rapides.
Les superclasses et sous-classes se produisent tout le temps dans le monde réel. N'ayez pas peur. Mais testez les performances de votre conception initiale. Si votre première tentative est simple et saine, vous pourrez l'ajuster pour l'accélérer.
Il n'y a rien de mal à avoir autant de sous-types d'entités dans votre modèle que nécessaire pour refléter la réalité des données que vous essayez de modéliser. La question n'est pas de savoir si les sous-types sont une mauvaise pratique. Le problème peut être un bon modèle?
Par exemple, dans votre exemple, que faites-vous avec quelque chose comme une Audi A4 eTron - qui est un hybride rechargeable? Est-ce une "voiture électrique" ou une "voiture hybride"?
L'autre question que vous devez vous poser est pourquoi vous sous-tapez du tout? Combien de prédicats distincts avez-vous dans vos sous-types? Certains de ces prédicats sont-ils partagés entre les sous-types? La situation pourrait se compliquer.
Le sous-typage n'est pas utilisé dans la conception de la base de données pour la classification. Vous pouvez effectuer une classification avec des codes, des clés étrangères vers des tables de codes ou avec des indicateurs. Le sous-typage est utilisé pour modéliser des ensembles de prédicats distincts pour différents types d'éléments d'intérêt. Si vous utilisez des sous-types uniquement pour la classification, c'est une mauvaise pratique.
Si vos sous-types modélisent clairement et sans ambiguïté différents ensembles de prédicats pour les éléments qui importent à votre base de données, alors c'est une bonne pratique, quel que soit le nombre de sous-types dont vous avez besoin.