Según mi interpretación de sus especificaciones, desea encontrar un método para implementar dos estructuras de subtipo de supertipo diferentes (pero conectadas ) .
Para exponer un enfoque para lograr la tarea mencionada, voy a agregar al escenario en cuestión los dos tipos clásicos de entidades hipotéticas llamadas Fooy Bar, que detallaré a continuación.
Reglas del negocio
Aquí hay algunas declaraciones que me ayudarán a crear un modelo lógico:
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
Modelo lógico
Y luego, el modelo lógico IDEF1X [1] resultante se muestra en la Figura 1 (y también puede descargarlo de Dropbox como PDF ):
La adición de Foo y Bar
No agregué Fooy Barpara que el modelo se vea mejor, sino para hacerlo más expresivo. Considero que son importantes debido a lo siguiente:
Como Ay Bcomparte el atributo nombrado E, esta característica sugiere que son tipos de subentidad de un tipo distinto (pero relacionado) de concepto , evento , persona , medida , etc., que representé por medio del Bartipo de superentidad que, a su vez, es Un tipo de subentidad Foo, que mantiene el Datributo en la parte superior de la jerarquía.
Como Csolo comparte un atributo con el resto de los tipos de entidad en discusión, es decir, Deste aspecto insinúa que es un tipo de subentidad de otro tipo de concepto , evento , persona , medida , etc., así que describí esta circunstancia en virtud de El Footipo de super entidad.
Sin embargo, estos son solo supuestos, y dado que una base de datos relacional está destinada a reflejar con precisión la semántica de un determinado contexto comercial , debe identificar y clasificar todas las cosas de interés en su dominio específico para que pueda, precisamente, capturar más significado .
Factores importantes en la fase de diseño.
Es bastante útil tener en cuenta el hecho de que, dejando a un lado toda la terminología, un clúster exclusivo de supertipo-subtipo es una relación ordinaria. Describamos la situación de la siguiente manera:
- Cada aparición de tipo de superentidad exclusiva está relacionada con un solo complemento de tipo de subentidad .
Por lo tanto, hay una correspondencia (o cardinalidad) de uno a uno (1: 1) en estos casos.
Como sabe por sus publicaciones anteriores, el atributo discriminador (columna, cuando se implementa) desempeña un papel primordial al crear una asociación de esta naturaleza, porque indica la instancia de subtipo correcta con la que está conectado el supertipo . La migración de la CLAVE PRIMARIA de (i) el supertipo a (ii) los subtipos también es de importancia primordial.
Estructura de hormigón DDL
Y luego escribí una estructura DDL que se basa en el modelo lógico presentado anteriormente:
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)
);
Con esta estructura, evita el almacenamiento de marcas NULL en sus tablas base (o relaciones ), lo que introduciría ambigüedad en su base de datos.
Integridad, consistencia y otras consideraciones.
Una vez que esté implementando su base de datos, debe asegurarse de que (a) cada fila de supertipo exclusiva siempre se complemente con su correspondiente contratipo de subtipo y, a su vez, garantice que (b) dicha fila de subtipo sea compatible con el valor contenido en la columna discriminadora de supertipo . Por lo tanto, es bastante conveniente emplear ACID TRANSACTIONSpara asegurarse de que se cumplan estas condiciones en su base de datos.
No debe renunciar a la solidez lógica, la autoexpresividad y la precisión de su base de datos, estos son aspectos que decididamente hacen que su base de datos sea más sólida.
Las dos respuestas publicadas anteriormente ya incluyen puntos pertinentes que sin duda vale la pena tener en cuenta al diseñar, crear y administrar su base de datos y sus programas de aplicación.
Recuperando datos por medio de definiciones VIEW
Puede configurar algunas vistas que combinen columnas de los diferentes grupos de subtipos de supertipos , de modo que pueda recuperar los datos disponibles sin, por ejemplo, escribir las cláusulas JOIN necesarias cada vez. De esta manera, puede seleccionar directamente desde la vista (una relación derivada o tabla ) de interés con facilidad.
Como puede ver, "Ted" Codd fue, sin duda, un genio. Las herramientas que legó son bastante fuertes y elegantes, y, por supuesto, están bien integradas entre sí.
Recursos Relacionados
Si desea analizar una base de datos extensa que involucra relaciones de supertipo-subtipo, encontrará valiosas las respuestas extraordinarias propuestas por @PerformanceDBA a las siguientes preguntas de desbordamiento de pila:
Nota
1. La definición de integración para el modelado de información ( IDEF1X ) es una técnica de modelado de datos muy recomendable que fue establecida como estándar en diciembre de 1993 por el Instituto Nacional de Estándares y Tecnología de los Estados Unidos ( NIST ). Se basa sólidamente en (a) el material teórico inicial escrito por el Dr. EF Codd; en (b) la vista de datos Entidad-Relación , desarrollada por el Dr. PP Chen ; y también en (c) la Técnica de diseño de base de datos lógica, creada por Robert G. Brown. Vale la pena señalar que IDEF1X se formalizó a través de la lógica de primer orden.