A parte do cenário com a qual você está confuso pode ser modelada com uma construção clássica chamada estrutura supertipo-subtipo 1 .
Vou (1) apresentar algumas idéias preliminares pertinentes, (2) detalhar como delinearia - no nível conceitual - o contexto de negócios em consideração e (3) forneceria material relacionado adicional - por exemplo, a representação em nível lógico correspondente via SQL Declarações -DDL - da seguinte maneira.
Introdução
Uma estrutura dessa natureza ocorre quando, em um determinado ambiente de negócios, existe um cluster de tipos de entidades dentro do qual o supertipo possui uma ou mais propriedades (ou atributos) compartilhadas pelo restante dos tipos de entidades no cluster, ou seja, , os subtipos . Cada subtipo possui, por sua vez, um conjunto específico de propriedades aplicáveis apenas a si próprio.
Os clusters de supertipos e subtipos podem ser de dois tipos:
Exclusivo . Ocorre quando uma instância do tipo superentidade deve sempre ter um e apenas um equivalente de subtipo; portanto, as possíveis ocorrências de subtipo em questão são mutuamente exclusivas . Esse é o tipo que interessa ao seu cenário.
Um caso típico em que ocorre um supertipo-subtipo exclusivo é um domínio comercial em que uma organização e uma pessoa são consideradas partes legais , como na situação deliberada nesta série de postagens .
Não exclusivo . Apresenta-se quando uma instância de supertipo pode ser complementada por várias ocorrências de subtipo , cada uma das quais é obrigada a pertencer a uma categoria diferente .
Um exemplo desse tipo de supertipo-subtipo é tratado nessas postagens .
Notas : Vale ressaltar que as estruturas de supertipo-subtipo - sendo elementos de caráter conceitual - não pertencem a uma estrutura teórica específica de gerenciamento de dados, seja relacional, de rede ou hierárquica - cuja estrutura específica oferece estruturas para representar elementos conceituais -.
Também é oportuno ressaltar que, embora os clusters de supertipo-subtipo tenham certa semelhança com a herança e o polimorfismo da programação de aplicativos orientada a objetos (OOP) , eles são, na verdade, dispositivos distintos porque servem a propósitos diferentes. Em um modelo conceitual de banco de dados - que deve representar aspectos do mundo real -, lida-se com características estruturais para descrever requisitos informacionais , enquanto no polimorfismo e herança de POO, entre outras coisas, um (a) esboços e (b) implementa características computacionais e comportamentais , aspectos que decididamente pertencem ao design e à programação do programa de aplicativos.
Além disso, uma classe OOP individual - sendo um componente do programa aplicativo -, não precisa necessariamente "espelhar" a estrutura de um tipo de entidade individual que pertence ao nível conceitual do banco de dados em questão. A esse respeito, um programador de aplicativos pode criar tipicamente, por exemplo, uma única classe que “combina” todas as propriedades de dois (ou mais) diferentes tipos de entidade em nível conceitual, e essa classe também pode incluir propriedades computadas.
Usando construções de relacionamento de entidade para representar um modelo conceitual com estruturas de supertipo-subtipo
Você solicitou um diagrama de entidade-relacionamento (ERD por brevidade), mas, apesar de ser uma plataforma de modelagem extraordinária, o método original - como introduzido pelo Dr. Peter Pin-Shan Chen 2 - não forneceu construções suficientes para representar cenários do tipo que está sendo discutido com a precisão exigida por um modelo conceitual de banco de dados adequado.
Consequentemente, foi necessário fazer algumas extensões ao referido método, situação que resultou no desenvolvimento de uma abordagem que auxilia na criação de diagramas aprimorados de relacionamento entre entidades (EERDs) que, naturalmente, enriqueceram a técnica inicial de diagramação com novas características expressivas. . Uma dessas características é, precisamente, a possibilidade de representar estruturas de supertipo-subtipo.
Modelando seu contexto de interesse
A ilustração mostrada na Figura 1 é um EERD (usando símbolos semelhantes aos propostos por Ramez A. Elmasri e Shamkant B. Navathe 3 , que se referem a estruturas como superclasse / subclasse ) onde modelei o domínio comercial que você descreve considerando todas as especificações. Também está disponível como um PDF que pode ser baixado do Dropbox .
Como você pode ver no diagrama acima, ambos Groupe SoloPerformersão exibidos como subtipos exclusivos do Artisttipo superentidade:
Descrição do diagrama
Para iniciar a descrição do EERD, é importante ressaltar que sua sentença
- “Um artista deve ser quer um grupo ou um SoloPerformer (mas não tanto)”
está relacionado aos aspectos de desarticulação e integralidade do cluster de supertipo-subtipo em questão.
Disjunção
O recurso disjunção é particularmente importante porque é aqui onde o “ou a parte” que você mencionou entra em jogo, devido ao fato de que um Artisttem que ser quer uma instância subtipo ou outro, que eu especificado no EERD através da pequena círculo contendo a letra "d", uma construção que recebe o nome de regra disjunta .
Quando um supertipo pode ser complementado por um ou mais de seus possíveis subtipos, esse ponto deve ser expresso por um pequeno círculo segurando um rótulo com a letra “o”, um símbolo chamado regra de sobreposição .
Propriedade discriminadora
Também no âmbito da disjunção fator desta associação supertipo-subtipo, vale a pena prestar muita atenção à Artist.Typepropriedade, uma vez que realiza uma tarefa muito relevante neste acordo: ele funciona como o subtipo discriminador . É nomeado dessa maneira, pois é a propriedade que aponta o tipo exclusivo de subtipo com o qual uma instância específica de um Artistse relaciona.
Nos casos de clusters não exclusivos , o uso de uma propriedade discriminadora é desnecessário, pois um determinado supertipo pode ter vários subtipos como complementos (como mencionado acima).
Regra de especialização total e completude
O requisito que estipula que todos Artistdevem sempre ter uma instância de subtipo suplementar tem a ver com a característica de integridade deste cluster. Isso é delineado por meio de uma regra de especialização total , demonstrada pelo símbolo de linha dupla que conecta (a) o Artistsupertipo com (b) a construção de regra disjunta.
Relacionando grupos com artistas solo
Avaliando as frases
- "Um grupo é composto por um ou mais SoloPerformers "
e
- "Um SoloPerformer pode ser membro de muitos grupos ou de nenhum grupo ",
pode-se reconhecer que ambos os subtipos estão envolvidos em uma associação (ou relacionamento) muitos para muitos (M: N), que eu representei com a caixa em forma de diamante rotulada como Group-SoloPerformer.
Se implementado em um relacional banco de dados como uma base de mesa, este componente seria muito útil para derive (ou seja, para realizar o cálculo do) o total Numberdos SoloPerformersque compõem um concreto Group(um dos requisitos especificados).
A associação entre artistas solo e instrumentos
A estipulação
- “Um SoloPerformer […] pode tocar um ou mais instrumentos”
permite inferir que, ao mesmo tempo,
- “Um instrumento é tocado por zero, um ou mais SoloPerformers”.
Portanto, esse é outro exemplo de associação M: N e usei a figura em forma de diamante designada SoloPerformer-Instrumentpara expô-la.
Material adicional
Para expor o escopo das estruturas de supertipo-subtipo, incluirei mais dois recursos, ou seja,
um diagrama do IDEF1X 4 apresentado na Figura 2 ( e você também pode baixá-lo do Dropbox como PDF ) que ilustra os recursos expressivos desse tipo de diagramas em relação ao domínio comercial em questão; e
a respectiva estrutura lógica DDL expositiva que exemplifica como gerenciar o cenário completo em discussão em virtude de um sistema de gerenciamento de banco de dados SQL.
1. Representação IDEF1X
A técnica de modelagem de informações IDEF1X certamente oferece a capacidade de retratar estruturas de supertipo-subtipo, embora com uma limitação: não empresta um mecanismo visual para indicar se um cluster preciso é de um tipo exclusivo ou não-excludente (seus símbolos "nativos" só podem se comunicar a identificação completa ou incompleta de todos os possíveis tipos de significância de subentidade). Felizmente, pode-se empregar a notação de Engenharia da Informação (IE) para mostrar esse aspecto primordial com mais precisão, enquanto aproveita o poder descritivo do padrão IDEF1X.
Nesta técnica, o principal recurso da sua pergunta é denominado "relacionamento de categorização", em que um supertipo é referido como "entidade genérica" e um subtipo recebe o nome de "entidade da categoria". No entanto, continuarei aplicando o termo supertipo-subtipo neste post porque (1) foi usado pelo Dr. Edgar Frank Codd, o criador do modelo relacional, (2) é mais conhecido e (3) a notação IE é usado em vez do "nativo".
Chaves estrangeiras e clusters de supertipos e subtipos
Como demonstrado, o IDEF1X oferece uma vantagem adicional: os meios para exibir definições de CHAVE ESTRANGEIRA (FK), elementos de primordial importância se um profissional representar uma associação de supertipo-subtipo em um banco de dados relacional .
A fim de retratar um tal tipo de associação, a propriedade PRIMARY KEY (PK) do supertipo, ou seja Artist.ArtistNumber, tem de migrar para Groupe SoloPerformer, embora tenha sido atribuído dois diferentes nomes de função 5, 6 , GroupNumbere SoloPerformerNumber, respectivamente, com a finalidade de enfatizar o significado transmitido pela propriedade no contexto de cada tipo de subentidade.
Além de serem caracterizadas como PKs, as propriedades Group.GroupNumbere SoloPerformer.SoloPerformerNumbersão, ao mesmo tempo, representadas como FOREIGN KEYs (FKs) que fazem referência à Artist.ArtistNumberpropriedade PK do supertipo.
Então, uma vez que cada SoloPerformere Groupocorrência é dependente da existência de um exato Artistexemplo, esses tipos de entidade estão envolvidos em uma associação identificação que tem efeito por meio do processo de migração propriedade PK delineado nos parágrafos anteriores.
Chaves estrangeiras e tipos de entidade associativa
O diagrama IDEF1X serve também para ilustrar as FKs que compõem as PKs dos dois tipos de relevância associativa de entidade , ou seja, GroupMembere SoloPerformerInstrument; o primeiro conecta os dois subtipos e o segundo vincula um subtipo a um tipo de entidade independente, ou seja Instrument,.
2. Declarações lógicas SQL-DDL expositivas
Como explicado anteriormente, uma estrutura de supertipo-subtipo é um meio de expressar certos tipos de conceituações específicas do domínio de negócios em relação a requisitos de informação, que por sua vez podem ser representados em um banco de dados por meio de construções distintas que devem corresponder às oferecidas pelo particular paradigma teórico (seja relacional, de rede ou hierárquico) seguido pelo sistema de gerenciamento de banco de dados utilizado pelo designer.
Uma das múltiplas vantagens do paradigma relacional é que ele permite representar as informações em sua estrutura natural, e as aproximações mais populares aos sistemas propostos na teoria relacional são os vários sistemas de gerenciamento de banco de dados SQL.
Então, finalmente, aqui estão algumas instruções DDL de amostra - incluindo (a) esquemas de tabelas base e (b) algumas das restrições pertinentes - que representam, no nível lógico da abstração, o exercício de modelagem conceitual tratado acima:
--
--
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)
);
--
--
Considerações sobre integridade e consistência dos dados
De acordo com tudo o que foi explicado anteriormente, o projetista deve garantir que cada linha do “supertipo” seja sempre complementada por sua contraparte do “subtipo” que acompanha e, por sua vez, verifique se a linha do “subtipo” é compatível com o valor contido na coluna "discriminador" do supertipo.
Seria muito prático e elegante aplicar essas circunstâncias declarativamente (como a estrutura relacional propõe), mas, infelizmente, nenhuma das principais plataformas SQL forneceu os mecanismos adequados para isso (tanto quanto eu sei). Portanto, é altamente conveniente empregar TRANSACÇÕES ÁCIDAS para que essas condições sejam sempre atendidas em um banco de dados (outra opção seria usar TRIGGERS, mas elas tendem a tornar as coisas desarrumadas).
Considerações sobre derivação de dados
Um dos principais aspectos do modelo relacional é que ele considera a derivação de dados como um fator primordial no gerenciamento de dados. Em conformidade, facilita a criação de (A) de base relações -ou base de tabelas no SQL, como mostrado na DDL declarações acima e (b) derivados relações - derivados tabelas em SQL, ou seja, as declaradas por força de operações SELECT que pode ser fixo como visões para exploração adicional—.
Portanto, pode-se declarar uma visão que reúne os pontos de dados do grupo “completos” :
CREATE VIEW FullGroup AS
SELECT G.GroupNumber,
A.Name,
A.CreatedDateTime,
G.FormationDate
FROM Artist A
JOIN MyGroup G
ON G.GroupNumber = A.ArtistNumber;
E outra visão que combina as informações "completas" do 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;
Dessa maneira, é muito fácil manipular - de forma declarativa - todos os dados significativos por meio do mesmo dispositivo de nível lógico, ou seja, a relação ou tabela (seja de base ou derivada). Evidentemente, o uso de visualizações é mais eficaz quando os tipos de entidade conceitual representados em um banco de dados relacional possuem mais propriedades de interesse, mas é uma possibilidade que vale a pena ilustrar com o cenário atual.
Referências
1 Codd, EF (dezembro de 1979). Estendendo o modelo relacional do banco de dados para captar mais significado , transações do ACM em sistemas de banco de dados , volume 4, edição 4 (pp. 397-434). Nova York, NY, EUA.
2 Chen, PP (março de 1976). Modelo de Entidade-Relacionamento - Rumo a uma visão unificada dos dados , transações da ACM em sistemas de banco de dados - Edição especial: Artigos da Conferência Internacional sobre Bases de Dados Muito Grandes: 22 a 24 de setembro de 1975, Framingham, MA , Volume 1, Edição 1 (pp. 9-36). Nova York, NY, EUA.
3 Elmasri, R & Navathe, SB (2003). Fundamentos de sistemas de banco de dados , quarta edição. Addison-Wesley Longman Publishing Co., Inc. Boston, MA, EUA.
4 Instituto Nacional de Padrões e Tecnologia (EUA) [NIST] (dezembro de 1993). Definição de Integração para Modelagem de Informações (IDEF1X), Publicação Federal de Padrões de Processamento de Informações , Volume 184. EUA.
5 Codd, EF (junho de 1970). Um modelo relacional de dados para grandes bancos de dados compartilhados , Communications of the ACM , Volume 13 Edição 6 (pp. 377-387). Nova York, NY, EUA.
6 Ver referência 4
