Supertype / sous-type décidant entre les catégories: chevauchement disjoint complet ou incomplet
Je crée une base de données d'inventaire qui stocke le matériel informatique, comme les ordinateurs de bureau, les ordinateurs portables, les commutateurs, les routeurs, les téléphones mobiles, etc. J'utilise un modèle de supertype/sous-type, où tous les appareils sont stockés dans une seule table et des informations spécifiques est placé dans des tables de sous-types. Mon dilemme est de choisir entre les deux modèles suivants:
Dans le diagramme du haut, tous les appareils partagent des sous-types communs. Par exemple, les ordinateurs de bureau et les ordinateurs portables auraient des enregistrements dans les tableaux suivants: Device, NetworkDevice. Un commutateur aurait des enregistrements dans: Device, NetworkDevice. Un routeur aurait des enregistrements dans: Device, NetworkDevice, WANDevice. Tout appareil dont nous suivons l'emplacement aura un enregistrement dans Emplacement. Quelques avantages et inconvénients auxquels j'ai pensé pour cette configuration:
- Pro: la sélection d'enregistrements basée sur un champ commun, comme Hostname ou LocationID est plus facile.
- Pro: Aucun champ nul.
- Inconvénients: les tables qui devraient être incluses dans les opérations CRUD pour un périphérique particulier ne sont pas évidentes et peuvent confondre les futurs DBA.
Dans le diagramme du bas, tous les appareils ont leur propre sous-type (il y a plus de classes d'appareils qui ne sont pas affichées ici). Dans cette situation, il est évident à partir de quels enregistrements de tables être insérés ou sélectionnés. Les ordinateurs de bureau et les ordinateurs portables vont dans Ordinateur, etc. Quelques avantages et inconvénients auxquels j'ai pensé pour cette configuration:
- Pro: Il est immédiatement évident quelles tables utiliser pour les opérations CRUD pour les sous-types.
- Pro: Il suffit d'utiliser une seule table pour les opérations CRUD.
- Contre: la sélection d'enregistrements sur la base de champs de sous-type communs nécessite que toutes les tables soient combinées, par exemple la recherche par nom d'hôte ou LocationID.
Dans les deux cas, le champ ClassDiscriminator est placé dans des tables de sous-types à utiliser avec une contrainte CHECK pour contrôler les types qui peuvent être insérés.
Y a-t-il des recommandations pour lesquelles la conception est meilleure, ou est-ce complètement une question d'opinion et dépend-elle du but prévu de la base de données?
EDIT: Une question spécifique que j'ai à propos de la nature qui se chevauchent du tableau "NetworkDevice". Ce tableau est destiné à contenir les informations réseau de tout appareil doté d'un nom d'hôte et/ou d'une adresse IP, qu'il s'agisse d'un ordinateur, d'un commutateur ou d'un routeur. La nature chevauchante de ce tableau peut-elle causer des problèmes, ou est-ce correct de l'implémenter de cette façon?
Merci d'avance pour toute contribution fournie. Veuillez demander si des informations supplémentaires sont nécessaires.
L'implémentation physique du sous-typage dans une base de données est un problème complexe. Sauf si vous avez une situation où il offre des avantages convaincants (voir ci-dessous pour un ou deux exemples), il ajoute de la complexité à la mise en œuvre tout en fournissant relativement peu de valeur.
Après avoir fait cela avec un sous-typage vraiment complexe (applications et condamnations sur un système de gestion des affaires judiciaires, structures de contrats d'assurance commerciale à risques combinés disparates), je suppose que j'ai quelques observations à ce sujet. Certains cas d'angle importants sont:
Si le nombre total de champs de base de données dans les sous-types est relativement faible (disons: moins de 100) ou s'il existe des points communs importants entre les sous-types, la division des sous-types en tables physiques distinctes est probablement de peu de valeur. Cela ajoutera des frais généraux importants aux rapports de requêtes et de recherches. Dans la plupart des cas, il est préférable d'avoir une seule table et de gérer votre sous-typage dans l'application. (Probablement le plus proche de votre problème)
Si votre sous-typage est très disjoint et que différents sous-types ont des structures de données dépendantes du type qui les suspendent (c'est-à-dire des tables enfants ou des structures plus complexes), alors les tables de sous-types ont du sens. Dans ce cas, chaque sous-type a probablement relativement peu de points communs dans l'application (c'est-à-dire qu'il y a probablement un sous-système entier dans l'application dédié à ce sous-type). La plupart des rapports et des requêtes se produiront probablement au sein d'un sous-type donné, les requêtes de type croisé étant principalement limitées à une poignée de champs communs. (Système de gestion des affaires judiciaires)
Si vous avez un grand nombre de sous-types avec des attributs disparates et/ou une exigence pour le rendre configurable, une structure générique et des métadonnées supplémentaires peuvent être plus appropriées. Voir ceci SO affichage pour un aperçu de certaines approches possibles. (Système d'administration des polices d'assurance)
Si vous avez un très grand nombre de champs avec peu de similitude entre vos sous-types et peu d'exigence d'interroger les tables de sous-type (c.-à-d. Rien de très important dans la manière des jointures externes multidirectionnelles contre vos tables de sous-type), alors sous- les tables de types peuvent aider à gérer l'étalement des colonnes. (Version pathologiquement complexe de votre problème)
Certains mappeurs O/R peuvent uniquement prendre en charge une approche particulière de la gestion des sous-classes.
Dans la plupart des cas, les tables de sous-types physiques dans un schéma de base de données sont un peu une solution à la recherche d'un problème, car elles ont potentiellement des effets secondaires indésirables.
Dans votre cas, je suppose que vous avez un nombre relativement modeste de sous-types et un nombre gérable d'attributs. Votre diagramme et votre question n'indiquent aucune intention de suspendre les tables enfants des enregistrements. Je suggère que vous envisagiez d'utiliser la première option suggérée ci-dessus et de maintenir une table et de gérer le sous-typage dans votre application.
Envisagez d'abord de développer un modèle de données logique solide en utilisant les règles de la hiérarchie de classification de la modélisation des données trouvées dans Enterprise Model Patterns , un livre de David Hay. Lors de la création d'une hiérarchie de classification, chaque occurrence (ligne) doit être d'un et d'un seul sous-type. Cela signifie que les sous-types s'excluent mutuellement. La classification doit être basée sur une caractéristique unique, fondamentale et immuable. L'utilisation de cette règle de base apportera beaucoup de clarté à votre modèle. Dans le modèle que vous avez, la seule caractéristique à classer est le but de l'appareil - un téléphone, un commutateur réseau, un ordinateur, un routeur, etc. Chaque appareil doit être d'un et d'un seul de ces types. Ainsi, par exemple, l'emplacement ne serait pas un sous-type. Les attributs tels que l'adresse IP appartiennent au super type.
Je pense que vous constaterez que le nombre de types d'appareils sera suffisamment grand pour justifier un modèle EAV comme mentionné dans une autre réponse. Le livre de David Hay que je référence couvre ce modèle très efficacement. Cependant, si le nombre de sous-types est peu élevé, vous pouvez en règle générale décider de n'implémenter qu'une table de super-type avec de nombreuses colonnes annulables, uniquement des tables de sous-types avec des colonnes dupliquées, ou les deux. Si chaque sous-type varie considérablement dans ses attributs et n'a aucune relation au niveau du super-type, vous pouvez utiliser uniquement des tables de sous-types. Si l'inverse est vrai, vous pouvez utiliser uniquement des tables de super-type. S'il y a un mélange, implémentez les deux.
Notez enfin que vous pouvez toujours implémenter un modèle EAV en tant que schéma de table de base, puis créer une couche d'abstraction de vue qui présente les données à l'application sous forme de tables de super et sous-types. Cela vous donne de la flexibilité au niveau de la couche de stockage mais de la compréhension au niveau de la couche de vue d'application.
Un produit n'est pas un inventaire. L'inventaire et les produits sont distincts.
Un produit est vraiment une spécification d'un produit, pas une chose physique.
La chose physique est un actif que l'entreprise possède (ou stocke). Vous pouvez avoir des actifs que vous suivez par numéro de série (actifs discrets) ou des actifs que vous suivez uniquement par quantité (actifs en stock).
Je regarderais le livre de ressources du modèle de données de Silverston Vol 1. Il a un bon schéma pour les fierté, les fonctionnalités, les prix, l'inventaire. Cela vous fera gagner beaucoup de temps.
L'une des questions que je poserais est la suivante: pourquoi suivez-vous les différents attributs de vos articles en stock? - Ou, plus précisément, que faites-vous avec ces informations d'attribut?
Si vous avez beaucoup de rapports ou de formulaires qui donnent un sens spécifique à des attributs particuliers, vous devez utiliser l'approche recommandée par ConcernedOfTunbridgeWell. Si d'un autre côté, ces attributs sont enregistrés dans le but de les répertorier, ou éventuellement de les comparer avec des attributs similaires d'appareils similaires, alors vous pouvez en fait avoir une (rare) bonne excuse pour utiliser EAV. Je sais que "l'EAV est du mal pur" pour de nombreuses raisons, sauf dans de très rares cas où ces raisons n'ont pas d'importance pour une application spécifique. La vôtre pourrait être une telle application.
Jetez un œil à cette réponse concernant la conception d'un système d'inventaire des appareils et cette réponse concernant la conception d'un système de catalogue de produits pour voir comment une approche EAV pourrait simplifier votre application avec une discussion sur quels sont exactement les risques de l'EAV et comment juger si ces risques peuvent ne pas s'appliquer à votre application spécifique.