La parte del escenario con la que se confunde puede modelarse con una construcción clásica llamada estructura de supertipo-subtipo 1 .
Presentaré (1) algunas ideas preliminares pertinentes, (2) detallaré cómo delinearía, a nivel conceptual, el contexto comercial en consideración y (3) proporcionaré material relacionado adicional, por ejemplo, la representación de nivel lógico correspondiente a través de SQL -DDL declaraciones: de la siguiente manera.
Introducción
Una estructura de esta naturaleza tiene lugar cuando, en un entorno empresarial dado, hay un grupo de tipos de entidad dentro del cual el supertipo tiene una o más propiedades (o atributos) que son compartidas por el resto de los tipos de entidad en el grupo, es decir , los subtipos . Cada subtipo tiene, a su vez, un conjunto particular de propiedades que son aplicables solo a sí mismo.
Los grupos de subtipos de supertipo pueden ser de dos tipos:
Exclusivo . Se produce cuando una instancia del tipo de superentidad debe tener siempre un solo subtipo de contraparte; por lo tanto, las posibles ocurrencias de subtipos en cuestión son mutuamente excluyentes . Este es el tipo que concierne a su escenario.
Un caso típico en el que se produce un subtipo de supertipo exclusivo es un dominio comercial en el que tanto una organización como una persona se consideran partes legales , como en la situación deliberada en esta serie de publicaciones .
No exclusivo . Se presenta cuando una instancia de supertipo puede complementarse con múltiples ocurrencias de subtipos , cada una de las cuales se ve obligada a pertenecer a una categoría diferente .
Un ejemplo de este tipo de supertipo-subtipo se trata en estas publicaciones .
Notas : Vale la pena mencionar que las estructuras de supertipo-subtipo, al ser elementos de carácter conceptual, no pertenecen a un marco teórico específico de gestión de datos, ya sea relacional, de red o jerárquico, cada uno de los cuales ofrece estructuras particulares para representar elementos conceptuales.
También es oportuno señalar que, aunque los grupos de subtipos de supertipo tienen cierta semejanza con la herencia de programación de aplicaciones orientadas a objetos (OOP) y el polimorfismo , en realidad son dispositivos distintos porque tienen diferentes propósitos. En un modelo conceptual de base de datos , que debe representar aspectos del mundo real, uno se ocupa de las características estructurales para describir los requisitos de información , mientras que en el polimorfismo y la herencia de OOP, entre otras cosas, uno (a) bosqueja y (b) implementa características computacionales y de comportamiento , aspectos que definitivamente pertenecen al diseño y programación del programa de aplicación.
Aparte de eso, una clase de OOP individual , al ser un componente del programa de aplicación, no necesariamente tiene que "reflejar" la estructura de un tipo de entidad individual que pertenece al nivel conceptual de la base de datos en cuestión. A este respecto, un programador de aplicaciones normalmente puede crear, por ejemplo, una sola clase que "combina" todas las propiedades de dos (o más) tipos de entidad de nivel conceptual diferentes, y dicha clase también puede incluir propiedades calculadas.
Uso de construcciones de entidad-relación para representar un modelo conceptual con estructuras de supertipo-subtipo
Usted solicitó un diagrama de entidad-relación (ERD por brevedad) pero, a pesar de ser una plataforma de modelado extraordinaria, el método original, tal como lo introdujo el Dr. Peter Pin-Shan Chen 2 , no proporcionó suficientes construcciones para representar escenarios de ese tipo. discutido con la precisión que requiere un modelo conceptual de base de datos adecuado.
En consecuencia, fue necesario hacer algunas extensiones a dicho método, situación que dio como resultado el desarrollo de un enfoque que ayuda a la creación de diagramas de relación de entidad mejorados (EERD) que, naturalmente, enriquecieron la técnica de diagramación inicial con nuevas características expresivas. . Una de esas características es, precisamente, la posibilidad de representar estructuras de supertipo-subtipo.
Modelando su contexto de interés
La ilustración que se muestra en la Figura 1 es un EERD (que usa símbolos similares a los propuestos por Ramez A. Elmasri y Shamkant B. Navathe 3 , quienes se refieren a estructuras tales como superclase / subclase ) donde modelé el dominio comercial que usted describe considerando todas las especificaciones. También está disponible como PDF que se puede descargar de Dropbox .
Como se puede ver en el diagrama anterior, tanto Groupy SoloPerformerse muestran como exclusivos subtipos del Artisttipo superentidad:
Descripción del diagrama
Para comenzar la descripción de la EERD, es importante señalar que su oración
- “Un artista debe ser ya sea un grupo o una SoloPerformer (pero no ambos)”
está relacionado con la desunión y los aspectos de integridad del clúster de supertipo-subtipo en cuestión.
Disyunción
La característica de disyunción es particularmente importante, ya que es aquí donde la “o parte” que usted ha mencionado entra en juego, debido al hecho de que una Artisttiene que ser ya sea una instancia subtipo o la otra, lo que he especificado en el EERD a través de la pequeña círculo que contiene la letra "d", una construcción que recibe el nombre de regla disjunta .
Cuando un supertipo puede complementarse con uno o más de sus posibles subtipos, este punto debe expresarse mediante un pequeño círculo que contenga una etiqueta con la letra "o", un símbolo llamado regla de superposición .
Propiedad discriminatoria
También dentro del alcance de la disjointness el factor de esta asociación supertipo-subtipo, vale la pena prestar mucha atención a la Artist.Typepropiedad, ya que realiza una tarea muy relevante en este arreglo: Funciona como el subtipo discriminador . Se nombra de esta manera ya que es la propiedad que señala el tipo exclusivo de subtipo con el que se relaciona una instancia específica de un Artist.
En los casos de clústeres no exclusivos , el uso de una propiedad discriminadora no es necesario, ya que cierto supertipo puede tener múltiples subtipos como complementos (como se mencionó anteriormente).
Regla de especialización total y completitud
El requisito que estipula que cada uno Artistdebe tener siempre una instancia de subtipo suplementario tiene que ver con la característica de completitud de este clúster. Esto se define mediante una regla de especialización total , demostrada mediante el símbolo de doble línea que conecta (a) el Artistsupertipo con (b) la construcción de la regla disjunta.
Relacionar grupos con artistas solistas
Evaluando las oraciones
- "Un grupo está formado por uno o más SoloPerformers "
y
- "Un SoloPerformer puede ser miembro de muchos Grupos o de ningún Grupo ",
uno puede reconocer que ambos subtipos están involucrados en una asociación (o relación) de muchos a muchos (M: N), que representé con la caja en forma de diamante etiquetada como Group-SoloPerformer.
Si se implementa en una base de datos relacional como una tabla base , este componente sería muy útil para obtener (es decir, llevar a cabo el cálculo de) el total Numberde SoloPerformerseso constituye un concreto Group(uno de los requisitos que especificó).
La asociación entre intérpretes solistas e instrumentos
La estipulación
- "Un SoloPerformer [...] puede tocar uno o más instrumentos"
nos permite inferir que, al mismo tiempo,
- "Un Instrumento es tocado por cero, uno o más SoloPerformers".
Por lo tanto, este es otro ejemplo de una asociación M: N, y utilicé la figura en forma de diamante designada SoloPerformer-Instrumentpara exponerla.
Material adicional
Para exponer el alcance de las estructuras de supertipo-subtipo, voy a incluir dos recursos más, es decir,
un diagrama IDEF1X 4 presentado en la Figura 2 ( y también puede descargarlo de Dropbox como PDF ) que ilustra las capacidades expresivas de este tipo de diagramas con respecto al dominio comercial en cuestión; y
la estructura lógica DDL expositiva respectiva que ejemplifica cómo administrar el escenario completo en discusión en virtud de un sistema de administración de bases de datos SQL.
1. Representación IDEF1X
La técnica de modelado de información IDEF1X ciertamente ofrece la capacidad de representar estructuras de subtipo de supertipo, aunque con una limitación: no presta un mecanismo visual para indicar si un grupo preciso es de un tipo exclusivo o no exclusivo (sus símbolos "nativos" solo pueden comunicarse la identificación completa o incompleta de todos los posibles tipos de significancia de subentidad). Afortunadamente, uno puede emplear la notación de Ingeniería de la Información (IE) para mostrar este aspecto primordial con mayor precisión mientras aprovecha el poder descriptivo del estándar IDEF1X.
En esta técnica, la característica principal de su pregunta se denomina "relación de categorización", donde un supertipo se denomina "entidad genérica" y un subtipo recibe el nombre de "entidad de categoría". Sin embargo, continuaré aplicando el término supertipo-subtipo en esta publicación porque (1) fue utilizado por el Dr. Edgar Frank Codd, el creador del modelo relacional, (2) es más ampliamente conocido y (3) la notación IE es usado en lugar del "nativo".
Claves foráneas y grupos de subtipos de supertipo
Como se demostró, IDEF1X proporciona una ventaja adicional: los medios para exhibir definiciones de CLAVE EXTRANJERA (FK), elementos de gran importancia si un profesional va a representar una asociación de supertipo-subtipo en una base de datos relacional .
Con el fin de representar una especie de asociación de este tipo, la clave PRIMARIA (PK) Propiedad del supertipo, es decir Artist.ArtistNumber, tiene que migrar a Groupy SoloPerformer, a pesar de que se ha asignado dos diferentes nombres de función 5, 6 , GroupNumbery SoloPerformerNumberrespectivamente, para el propósito de enfatizar El significado transmitido por la propiedad en el contexto de cada tipo de subentidad.
Además de caracterizarse como PK, las propiedades Group.GroupNumbery SoloPerformer.SoloPerformerNumberse representan, al mismo tiempo, como CLAVES EXTRANJERAS (FK) que hacen referencia a Artist.ArtistNumberla propiedad PK de supertipo.
Por lo tanto, ya que cada SoloPerformery Groupocurrencia es existencia dependiente en una exacta Artistejemplo, estos tipos de entidades están involucrados en una asociación de identificación que se lleva a efecto por medio del proceso de migración propiedad PK delineado en los párrafos anteriores.
Claves foráneas y tipos de entidad asociativa
El diagrama IDEF1X sirve también para ilustrar las FK que componen las PK de los dos tipos de entidad asociativa de relevancia, es decir, GroupMembery SoloPerformerInstrument; el primero se conecta los dos subtipos, y el segundo une un subtipo con un tipo de entidad independiente, es decir, Instrument.
2. Declaraciones lógicas expositivas SQL-DDL
Como se explicó anteriormente, una estructura de subtipo de supertipo es un medio para expresar ciertos tipos de conceptualizaciones específicas del dominio empresarial con respecto a los requisitos de información, que a su vez pueden representarse en una base de datos mediante construcciones distintas que deben corresponder a las ofrecidas por el particular paradigma teórico (ya sea relacional, de red o jerárquico) seguido por el sistema de gestión de la base de datos utilizado por el diseñador.
Una de las múltiples ventajas del paradigma relacional es que permite representar la información en su estructura natural, y las aproximaciones más populares a los sistemas propuestos en la teoría relacional son los diversos sistemas de gestión de bases de datos SQL.
Entonces, finalmente, aquí hay algunas declaraciones DDL de muestra, que incluyen (a) esquemas de tablas base junto con (b) algunas de las restricciones pertinentes, que representan, en el nivel lógico de abstracción, el ejercicio de modelado conceptual tratado anteriormente:
--
--
CREATE TABLE Artist ( -- Stands for the supertype.
ArtistNumber INT NOT NULL,
Name CHAR(30) NOT NULL,
Type CHAR(1) NOT NULL, -- Holds the discriminator values.
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT Artist_PK PRIMARY KEY (ArtistNumber),
CONSTRAINT Artist_AK UNIQUE (Name), -- ALTERNATE KEY.
CONSTRAINT Artist_Type_CK CHECK (Type IN ('G', 'S')) -- Enforces retaining either ‘G’, for ‘Group’, or ‘S’, for ‘SoloPerformer’, only.
);
CREATE TABLE MyGroup ( -- Represents one subtype.
GroupNumber INT NOT NULL, -- To be constrained as PK and FK simultaneously.
FormationDate DATE NOT NULL,
--
CONSTRAINT MyGroup_PK PRIMARY KEY (GroupNumber),
CONSTRAINT MyGroupToArtist_FK FOREIGN KEY (GroupNumber)
REFERENCES Artist (ArtistNumber)
);
CREATE TABLE SoloPerformer ( -- Denotes the other subtype.
SoloPerformerNumber INT NOT NULL, -- To be constrained as PK and FK simultaneously.
BirthDate DATE NOT NULL,
--
CONSTRAINT SoloPerformer_PK PRIMARY KEY (SoloPerformerNumber),
CONSTRAINT SoloPerformerNumberToArtist_FK FOREIGN KEY (SoloPerformerNumber)
REFERENCES Artist (ArtistNumber)
);
CREATE TABLE GroupMember ( -- Stands for a M:N association involving the two subtypes.
MemberNumber INT NOT NULL,
GroupNumber INT NOT NULL,
JoinedDate DATE NOT NULL,
--
CONSTRAINT GroupMember_PK PRIMARY KEY (MemberNumber, GroupNumber), -- Composite PK.
CONSTRAINT GroupMemberToSoloPerformer_FK FOREIGN KEY (MemberNumber)
REFERENCES SoloPerformer (SoloPerformerNumber),
CONSTRAINT GroupMemberToMyGroup_FK FOREIGN KEY (GroupNumber)
REFERENCES MyGroup (GroupNumber)
);
CREATE TABLE Instrument ( -- Represents an independent entity type.
InstrumentNumber INT NOT NULL,
Name CHAR(30) NOT NULL,
--
CONSTRAINT Instrument_PK PRIMARY KEY (InstrumentNumber),
CONSTRAINT Instrument_AK UNIQUE (Name) -- ALTERNATE KEY.
);
CREATE TABLE SoloPerformerInstrument ( -- Denotes another M:N association, in this case between a subtype and an independent entity type.
SoloPerformerNumber INT NOT NULL,
InstrumentNumber INT NOT NULL,
CreatedDate DATE NOT NULL,
--
CONSTRAINT SoloPerformerInstrument_PK PRIMARY KEY (SoloPerformerNumber, InstrumentNumber), -- Composite PK.
CONSTRAINT SoloPerformerInstrumentToSoloPerformer_FK FOREIGN KEY (SoloPerformerNumber)
REFERENCES SoloPerformer (SoloPerformerNumber),
CONSTRAINT SoloPerformerInstrumentToInstrument_FK FOREIGN KEY (InstrumentNumber)
REFERENCES Instrument (InstrumentNumber)
);
--
--
Integridad de datos y consideraciones de coherencia
De acuerdo con todo lo que se ha explicado anteriormente, el diseñador debe garantizar que cada fila de "supertipo" esté en todo momento complementada por su contraparte "subtipo" y, a su vez, asegúrese de que dicha fila de "subtipo" sea compatible con el valor contenido en la columna "discriminador" de supertipo.
Sería muy práctico y elegante hacer cumplir dichas circunstancias de manera declarativa (como propone el marco relacional) pero, por desgracia, ninguna de las principales plataformas SQL ha proporcionado los mecanismos adecuados para hacerlo (que yo sepa). Por lo tanto, es muy conveniente emplear TRANSACCIONES ÁCIDAS para que estas condiciones siempre se cumplan en una base de datos (otra opción sería utilizar DISPARADORES, pero tienden a poner las cosas en orden).
Consideraciones de derivación de datos
Uno de los aspectos principales del modelo relacional es que considera la derivación de datos como un factor primordial en la gestión de datos. De conformidad, facilita la creación de (a) de base relaciones -o base de tablas en SQL, como se muestra en la DDL declaraciones anteriormente y (b) derivados relaciones - derivados tablas en SQL, es decir, los declarados a fuerza de operaciones SELECT que puede ser fijadas como vistas para una mayor explotación.
Por lo tanto, se puede declarar una vista que reúne los puntos de datos del Grupo "completo" :
CREATE VIEW FullGroup AS
SELECT G.GroupNumber,
A.Name,
A.CreatedDateTime,
G.FormationDate
FROM Artist A
JOIN MyGroup G
ON G.GroupNumber = A.ArtistNumber;
Y otra vista que combina la información "completa" de SoloPerformer :
CREATE VIEW FullSoloPerformer AS
SELECT SP.SoloPerformerNumber,
A.Name,
A.CreatedDateTime,
SP.BirthDate
FROM Artist A
JOIN SoloPerformer SP
ON SP.SoloPerformerNumber = A.ArtistNumber;
De esta manera, es muy fácil manipular —declarativamente— todos los datos significativos a través del mismo dispositivo de nivel lógico, es decir, la relación o tabla (ya sea base o derivada). Evidentemente, el uso de vistas es más efectivo cuando los tipos de entidades conceptuales representados en una base de datos relacional poseen más propiedades de interés, pero es una posibilidad que vale la pena ilustrar con el escenario actual.
Referencias
1 Codd, EF (diciembre de 1979). Ampliación del modelo relacional de bases de datos para capturar más significado , transacciones de ACM en sistemas de bases de datos , Volumen 4, Edición 4 (págs. 397-434). Nueva York, NY, Estados Unidos.
2 Chen, PP (marzo de 1976). El modelo de entidad-relación: hacia una vista unificada de datos , transacciones ACM en sistemas de bases de datos - Número especial: documentos de la Conferencia internacional sobre bases de datos muy grandes: 22-24 de septiembre de 1975, Framingham, MA , volumen 1, número 1 (pp 9-36). Nueva York, NY, Estados Unidos.
3 Elmasri, R y Navathe, SB (2003). Fundamentos de los sistemas de bases de datos , cuarta edición. Addison-Wesley Longman Publishing Co., Inc. Boston, MA, EE. UU.
4 Instituto Nacional de Estándares y Tecnología (EE. UU.) [NIST] (diciembre de 1993). Definición de integración para el modelado de información (IDEF1X), publicación de normas federales de procesamiento de información , volumen 184. Estados Unidos.
5 Codd, EF (junio de 1970). Un modelo relacional de datos para grandes bancos de datos compartidos , Comunicaciones de la ACM , Volumen 13, número 6 (pp. 377-387). Nueva York, NY, Estados Unidos.
6 Ver referencia 4
La respuesta de MDCCL es un excelente resumen de los conceptos detrás de la superclase / subclase o generalización / especialización como se muestra en el nivel EERD.
Esta respuesta tiene como objetivo señalar tres patrones de diseño o técnicas que vale la pena saber cuando llegue el momento de convertir el EERD en un diseño relacional, basado en tablas definidas con columnas definidas.
Aquí están los tres:
Las dos primeras son alternativas, una es buena para casos simples donde casi todos los datos pertenecen a la superclase. El segundo es más complicado, pero puede funcionar mejor cuando muchos de los datos pertenecen a varias subclases. La palabra "Herencia" se usa para indicar que el diseño proporciona algo del mismo poder expresivo que la herencia proporcionaría en un modelo de objeto.
La clave primaria compartida es una técnica mediante la cual las entradas en las tablas de subclase pueden adquirir una identidad al "heredar" la identidad de la entrada correspondiente en la tabla de superclase.
En SO, hay tres etiquetas con estos nombres. La pestaña Información debajo de cada etiqueta proporciona una descripción, y hay muchas preguntas agrupadas debajo de las etiquetas.
También hay muchos sitios web que presentan estas técnicas. Recomiendo los de Martin Fowler. Me gusta cómo lo presenta. Aquí hay un par de páginas web:
Herencia de tabla única Herencia de tabla de clase
fuente