Selon mon interprétation de vos spécifications, vous souhaitez trouver une méthode pour implémenter deux structures supertype-sous-type différentes (mais connectées ) .
Afin d'exposer une approche pour réaliser la tâche susmentionnée, je vais ajouter au scénario en cause les deux types d'entités hypothétiques classiques appelés Fooand Bar, que je détaillerai ci-dessous.
Règles métier
Voici quelques déclarations qui m'aideront à créer un modèle logique:
A Foo is either one Bar or one CA Foo is categorized by one FooTypeA Bar is either one A or one CA Bar is classified by one BarType
Modèle logique
Et puis, le modèle logique IDEF1X [1] résultant est illustré à la figure 1 (et vous pouvez également le télécharger depuis Dropbox au format PDF ):
L'ajout de Foo et Bar
Je n'ai pas ajouté Fooet Barpour rendre le modèle plus beau, mais pour le rendre plus expressif. Je considère qu'ils sont importants pour les raisons suivantes:
Comme Aet Bpartager l'attribut nommé E, cette fonctionnalité suggère qu'il s'agit de types de sous-entité d'un type distinct (mais lié) de concept , d' événement , de personne , de mesure , etc., que j'ai représenté au moyen du Bartype de superentité qui, à son tour, est un type de sous-entité de Foo, qui contient l' Dattribut en haut de la hiérarchie.
Puisqu'il Cne partage qu'un seul attribut avec le reste des types d'entités en discussion, c'est-à-dire que Dcet aspect insinue qu'il s'agit d'un type de sous-entité d'un autre type de concept , événement , personne , mesure , etc., j'ai donc décrit cette circonstance en vertu de le Footype super entité.
Cependant, ce ne sont que des hypothèses, et comme une base de données relationnelle est censée refléter avec précision la sémantique d'un certain contexte commercial , vous devez identifier et classer toutes les choses d'intérêt dans votre domaine spécifique afin que vous puissiez, précisément, capturer plus de sens .
Facteurs importants lors de la phase de conception
Il est très utile d'être conscient du fait que, en mettant toute la terminologie de côté, un cluster exclusif de supertype-sous-type est une relation ordinaire. Décrivons la situation de la manière suivante:
- Chaque occurrence de type superentité exclusive est liée à un seul complément de type sous-entité .
Ainsi, il y a une correspondance (ou cardinalité) de un à un (1: 1) dans ces cas.
Comme vous le savez d'après vos publications précédentes, l' attribut discriminateur (colonne, lorsqu'il est implémenté) joue un rôle primordial lors de la création d'une association de cette nature, car il indique l'instance de sous-type correcte avec laquelle le supertype est connecté . La migration de la CLÉ PRIMAIRE de (i) le supertype vers (ii) les sous-types est également d'une importance primordiale.
Structure DDL en béton
Et puis j'ai écrit une structure DDL basée sur le modèle logique présenté ci-dessus:
CREATE TABLE FooType -- Look-up table.
(
FooTypeCode CHAR(2) NOT NULL,
Description CHAR(90) NOT NULL,
CreatedDateTime DATETIME NOT NULL,
CONSTRAINT PK_FooType PRIMARY KEY (FooTypeCode),
CONSTRAINT AK_FooType_Description UNIQUE (Description)
);
CREATE TABLE Foo -- Supertype
(
FooId INT NOT NULL, -- This PK migrates (1) to ‘Bar’ as ‘BarId’, (2) to ‘A’ as ‘AId’, (3) to ‘B’ as ‘BId’, and (4) to ‘C’ as ‘CId’.
FooTypeCode CHAR(2) NOT NULL, -- Discriminator column.
D INT NOT NULL, -- Column that applies to ‘Bar’ (and therefore to ‘A’ and ‘B’) and ‘C’.
CreatedDateTime DATETIME NOT NULL,
CONSTRAINT PK_Foo PRIMARY KEY (FooId),
CONSTRAINT FK_from_Foo_to_FooType FOREIGN KEY (FooTypeCode)
REFERENCES FooType (FooTypeCode)
);
CREATE TABLE BarType -- Look-up table.
(
BarTypeCode CHAR(1) NOT NULL,
Description CHAR(90) NOT NULL,
CONSTRAINT PK_BarType PRIMARY KEY (BarTypeCode),
CONSTRAINT AK_BarType_Description UNIQUE (Description)
);
CREATE TABLE Bar -- Subtype of ‘Foo’.
(
BarId INT NOT NULL, -- PK and FK.
BarTypeCode CHAR(1) NOT NULL, -- Discriminator column.
E INT NOT NULL, -- Column that applies to ‘A’ and ‘B’.
CONSTRAINT PK_Bar PRIMARY KEY (BarId),
CONSTRAINT FK_from_Bar_to_Foo FOREIGN KEY (BarId)
REFERENCES Foo (FooId),
CONSTRAINT FK_from_Bar_to_BarType FOREIGN KEY (BarTypeCode)
REFERENCES BarType (BarTypeCode)
);
CREATE TABLE A -- Subtype of ‘Bar’.
(
AId INT NOT NULL, -- PK and FK.
X INT NOT NULL, -- Particular column.
CONSTRAINT PK_A PRIMARY KEY (AId),
CONSTRAINT FK_from_A_to_Bar FOREIGN KEY (AId)
REFERENCES Bar (BarId)
);
CREATE TABLE B -- (1) Subtype of ‘Bar’ and (2) supertype of ‘A’ and ‘B’.
(
BId INT NOT NULL, -- PK and FK.
Y INT NOT NULL, -- Particular column.
CONSTRAINT PK_B PRIMARY KEY (BId),
CONSTRAINT FK_from_B_to_Bar FOREIGN KEY (BId)
REFERENCES Bar (BarId)
);
CREATE TABLE C -- Subtype of ‘Foo’.
(
CId INT NOT NULL, -- PK and FK.
Z INT NOT NULL, -- Particular column.
CONSTRAINT PK_C PRIMARY KEY (CId),
CONSTRAINT FK_from_C_to_Foo FOREIGN KEY (FooId)
REFERENCES Foo (FooId)
);
Avec cette structure, vous évitez le stockage de marques NULL dans vos tables de base (ou relations ), ce qui introduirait une ambiguïté dans votre base de données.
Intégrité, cohérence et autres considérations
Une fois que vous implémentez votre base de données, vous devez vous assurer que (a) chaque ligne de supertype exclusive est toujours complétée par son homologue de sous-type correspondante et, à son tour, garantir que (b) cette ligne de sous-type est compatible avec la valeur contenue dans la colonne de discrimination de supertype . Par conséquent, il est assez pratique d'utiliser ACID TRANSACTIONSpour vous assurer que ces conditions sont remplies dans votre base de données.
Vous ne devez pas abandonner la solidité logique, l'auto-expressivité et la précision de votre base de données, ce sont des aspects qui rendent décidément votre base de données plus solide.
Les deux réponses précédemment publiées contiennent déjà des points pertinents qui méritent certainement d'être pris en compte lors de la conception, de la création et de la gestion de votre base de données et de ses programmes d'application.
Récupération de données via des définitions VIEW
Vous pouvez configurer certaines vues qui combinent des colonnes des différents groupes de supertype-sous-type , de sorte que vous pouvez récupérer les données à portée de main sans, par exemple, écrire les clauses JOIN nécessaires à chaque fois. De cette façon, vous pouvez sélectionner directement à partir de la VUE (une relation dérivée ou une table ) d'intérêt avec facilité.
Comme vous pouvez le voir, "Ted" Codd était, sans aucun doute, un génie. Les outils qu'il a légués sont assez solides et élégants et, bien sûr, bien intégrés les uns aux autres.
Ressources associées
Si vous souhaitez analyser une base de données étendue qui implique des relations supertype-sous-type, vous trouverez utile les réponses extraordinaires proposées par @PerformanceDBA aux questions de débordement de pile suivantes:
Remarque
1. La définition d'intégration pour la modélisation de l'information ( IDEF1X ) est une technique de modélisation de données hautement recommandable qui a été établie comme norme en décembre 1993 par le National Institute of Standards and Technology ( NIST ) des États-Unis . Il est solidement fondé sur (a) les premiers éléments théoriques rédigés par le Dr EF Codd; sur (b) la vue Entité-Relation des données, développée par le Dr PP Chen ; et aussi sur (c) la technique de conception de bases de données logiques, créée par Robert G. Brown. Il convient de noter que IDEF1X a été formalisé au moyen d'une logique de premier ordre.