La parte dello scenario con cui sei confuso può essere modellata con un costrutto classico chiamato supertipo-sottotipo 1 struttura.
(1) introdurrò alcune idee preliminari pertinenti, (2) descriverò in dettaglio come definirei - a livello concettuale - il contesto aziendale in esame, e (3) fornirò materiale correlato aggiuntivo —eg, la corrispondente rappresentazione a livello logico tramite SQL -DDL dichiarazioni— come segue.
introduzione
Una struttura di questa natura ha luogo quando, in un determinato ambiente aziendale, esiste un cluster di tipi di entità all'interno del quale il supertipo ha una o più proprietà (o attributi) condivise dal resto dei tipi di entità nel cluster, ovvero , i sottotipi . Ogni sottotipo ha, a sua volta, un particolare insieme di proprietà applicabili solo a se stesso.
I cluster supertipo e sottotipi possono essere di due tipi:
Esclusivo . Si verifica quando un'istanza del tipo di superentity deve sempre avere una e una sola controparte del sottotipo; pertanto, le potenziali occorrenze del sottotipo in questione si escludono a vicenda . Questo è il tipo che riguarda il tuo scenario.
Un caso tipico in cui si verifica un sottotipo di sottotipo esclusivo è un settore commerciale in cui sia un'organizzazione che una persona sono considerate parti legali , come nella situazione deliberata in questa serie di post .
Nessuno . Si presenta quando un'istanza di supertipo può essere integrata da più occorrenze di sottotipi , ognuna delle quali è costretta a appartenere a una categoria diversa .
Un esempio di questo tipo di sottotipo di supertipo è trattato in questi post .
Note : Vale la pena ricordare che le strutture di sottotipo di sottotipo - elementi di carattere concettuale - non appartengono a un quadro teorico di gestione dei dati specifico, sia esso relazionale, di rete o gerarchico, ciascuna delle quali offre particolari strutture per rappresentare elementi concettuali—.
È anche opportuno sottolineare che sebbene i cluster di sottotipi di sottotipo presentino una certa somiglianza con l' ereditarietà e il polimorfismo della programmazione orientata agli oggetti (OOP) , in realtà sono dispositivi distinti perché servono a scopi diversi. In un modello concettuale di database - che deve rappresentare gli aspetti del mondo reale - si tratta di caratteristiche strutturali al fine di descrivere i requisiti informativi , mentre nel polimorfismo OOP e nell'ereditarietà, tra le altre cose, uno (a) schizzi e (b) implementa le caratteristiche computazionali e comportamentali , aspetti che appartengono decisamente alla progettazione e alla programmazione del programma di moltiplicazione.
A parte questo, una singola classe OOP - essendo un componente del programma applicativo - non deve necessariamente "rispecchiare" la struttura di un tipo di entità individuale che appartiene al livello concettuale del database a portata di mano. A questo proposito, un programmatore di applicazioni può in genere creare, ad esempio, una singola classe che "combina" tutte le proprietà di due (o più) diversi tipi di entità a livello concettuale e tale classe può anche includere proprietà calcolate.
Usare costrutti entità-relazione per rappresentare un modello concettuale con strutture di sottotipo-sottotipo
Hai chiesto un diagramma entità-relazione (ERD per brevità) ma, pur essendo una straordinaria piattaforma di modellazione, il metodo originale - come introdotto dal Dr. Peter Pin-Shan Chen 2 - non forniva abbastanza costrutti per rappresentare scenari del genere discusso con la precisione richiesta da un modello concettuale di database adeguato.
Di conseguenza, è stato necessario apportare alcune estensioni a tale metodo, situazione che ha prodotto risultati nello sviluppo di un approccio che aiuta nella creazione di diagrammi entità-relazione avanzati (EERD) che, naturalmente, hanno arricchito la tecnica iniziale di diagrammi con nuove caratteristiche espressive . Una di queste caratteristiche è, appunto, la possibilità di rappresentare strutture di sottotipo-sottotipo.
Modellare il tuo contesto di interesse
L'illustrazione mostrata nella Figura 1 è un EERD (usando simboli simili a quelli proposti da Ramez A. Elmasri e Shamkant B. Navathe 3 , che si riferiscono a strutture come superclasse / sottoclasse ) in cui ho modellato il dominio aziendale che descrivi considerando tutti i specifiche. È anche disponibile come PDF che può essere scaricato da Dropbox .
Come puoi vedere nel diagramma di cui sopra, entrambi Groupe SoloPerformervengono visualizzati come sottotipi esclusivi del Artisttipo di superentity:
Descrizione del diagramma
Per iniziare la descrizione dell'EERD, è importante sottolineare che la tua frase
- “Un artista deve essere sia un gruppo o di un SoloPerformer (ma non entrambi)”
è legato alla disgiunzione e agli aspetti di completezza del cluster di sottotipo e sottotipo a portata di mano.
disgiunzione
La funzione di disgiunzione è particolarmente importante perché è proprio qui dove la “o di parte” che lei ha citato entra in gioco, a causa del fatto che un Artistdeve essere sia un caso sottotipo o l'altro, che ho specificato nel EERD attraverso la piccola cerchio contenente la lettera "d", un costrutto che riceve il nome della regola disgiunta .
Quando un supertipo può essere integrato da uno o più dei suoi possibili sottotipi, questo punto deve essere espresso da un piccolo cerchio con un'etichetta con la lettera "o", un simbolo chiamato regola di sovrapposizione .
Proprietà del discriminatore
Anche nell'ambito del fattore di disgiunzione di questa associazione di sottotipo-sottotipo, vale la pena prestare molta attenzione alla Artist.Typeproprietà, poiché svolge un compito molto rilevante in questa disposizione: funziona come discriminatore del sottotipo . È chiamato in questo modo in quanto è la proprietà che indica il tipo esclusivo di sottotipo con cui si Artistriferisce un'istanza specifica di un .
Nei casi di cluster non esclusivi , l'uso di una proprietà discriminante è inutile, poiché un certo supertipo può avere più sottotipi come complementi (come indicato sopra).
Regola di specializzazione totale e completezza
Il requisito che stabilisce che ognuno Artistdeve sempre avere un'istanza di sottotipo supplementare ha a che fare con la caratteristica di completezza di questo cluster. Questo è delineato per mezzo di una regola di specializzazione totale , dimostrata tramite il simbolo della doppia linea che collega (a) il Artistsupertipo con (b) il costrutto della regola disgiunta.
Gruppi correlati con artisti solisti
Valutare le frasi
- "Un gruppo è composto da uno o più SoloPerformer "
e
- "Un SoloPerformer può essere membro di molti gruppi o di nessun gruppo ",
si può riconoscere che entrambi i sottotipi sono coinvolti in un'associazione (o relazione) molti-a-molti (M: N), che ho rappresentato con la scatola a forma di diamante etichettata come Group-SoloPerformer.
Se implementato in un database relazionale come tabella di base , questo componente sarebbe molto utile per ricavare (cioè per eseguire il calcolo di) il totale Numberdi SoloPerformersquello che costituisce un concreto Group(uno dei requisiti specificati).
L'associazione tra artisti solisti e strumenti
La stipulazione
- "Un SoloPerformer [...] può suonare uno o più strumenti"
ci permette di dedurre che, allo stesso tempo,
- "Uno strumento è suonato da zero, uno o più SoloPerformer".
Quindi, questo è un altro esempio di associazione M: N e ho usato la figura a forma di diamante designata SoloPerformer-Instrumentper esporla.
Materiale aggiuntivo
Per illustrare il campo di applicazione delle strutture dei sottotipi di sottotipi, includerò altre due risorse, ovvero
un diagramma IDEF1X 4 presentato nella Figura 2 ( e puoi scaricarlo da Dropbox anche in formato PDF ) che illustra le capacità espressive di questo tipo di diagrammi relativi al dominio aziendale in questione; e
la rispettiva struttura logica DDL espositiva che esemplifica come gestire l'intero scenario in discussione in virtù di un sistema di gestione del database SQL.
1. Rappresentazione IDEF1X
La tecnica di modellazione delle informazioni IDEF1X offre certamente la capacità di rappresentare strutture di sottotipi di sottotipi, sebbene con una limitazione: non fornisce un meccanismo visivo per indicare se un cluster preciso è di tipo esclusivo o non inclusivo (i suoi simboli "nativi" possono solo comunicare l' identificazione completa o incompleta di tutti i possibili tipi di significati di subentità). Fortunatamente, si può usare la notazione di ingegneria informatica (IE) per mostrare questo aspetto fondamentale in modo più accurato sfruttando il potere descrittivo dello standard IDEF1X.
In questa tecnica, la caratteristica principale della tua domanda è denominata "relazione di categorizzazione", in cui un supertipo viene indicato come "entità generica" e un sottotipo riceve il nome di "entità di categoria". Tuttavia, continuerò ad applicare il termine supertipo-sottotipo in questo post perché (1) è stato utilizzato dal Dr. Edgar Frank Codd, il creatore del modello relazionale, (2) è più ampiamente conosciuto e (3) la notazione IE è usato al posto di quello "nativo".
Chiavi esterne e cluster di sottotipi di sottotipi
Come dimostrato, IDEF1X offre un ulteriore vantaggio: i mezzi per esibire definizioni CHIAVE ESTERA (FK), elementi di primaria importanza se un professionista rappresenterà un'associazione di sottotipo-sottotipo in un database relazionale .
Per ritrarre una sorta di associazione, la chiave primaria (PK) proprietà del supertipo, cioè Artist.ArtistNumber, deve migrare verso Groupe SoloPerformer, anche se è stato assegnato due diversi nomi dei ruoli 5, 6 , GroupNumbere SoloPerformerNumber, rispettivamente, allo scopo di mettere in risalto il significato trasmesso dalla proprietà nel contesto di ciascun tipo di subentità.
Oltre ad essere caratterizzato come PK, le proprietà Group.GroupNumbere SoloPerformer.SoloPerformerNumbersono, allo stesso tempo, rappresentate come FOREIGN KEYs (FK) che fanno riferimento alla Artist.ArtistNumberproprietà PK del supertipo.
Quindi, poiché ogni SoloPerformere Groupoccorrenza dipende dall'esistenza diArtist un'istanza esatta , questi tipi di entità sono coinvolti in un'associazione di identificazione che ha effetto tramite il processo di migrazione delle proprietà PK delineato nei paragrafi precedenti.
Chiavi esterne e tipi di entità associativa
Il diagramma IDEF1X serve anche per illustrare gli FK che compongono i PK dei due tipi di entità associativa di pertinenza, ovvero, GroupMembere SoloPerformerInstrument; il primo collega i due sottotipi e il secondo collega un sottotipo con un tipo di entità indipendente, ovvero Instrument.
2. Dichiarazioni logiche Expository SQL-DDL
Come spiegato in precedenza, una struttura di sottotipo di supertipo è un mezzo per esprimere alcuni tipi di concettualizzazioni specifiche del dominio aziendale in merito ai requisiti informativi, che a loro volta possono essere rappresentati in un database mediante costrutti distinti che devono corrispondere a quelli offerti dal particolare paradigma teorico (sia esso relazionale, di rete o gerarchico) seguito dal sistema di gestione del database utilizzato dal progettista.
Uno dei molteplici vantaggi del paradigma relazionale è che consente di rappresentare le informazioni nella sua struttura naturale, e le approssimazioni più popolari ai sistemi proposti nella teoria relazionale sono i vari sistemi di gestione del database SQL.
Quindi, finalmente, ecco alcune istruzioni DDL di esempio - tra cui (a) schemi di tabelle di base insieme a (b) alcuni dei vincoli pertinenti - che rappresentano, a livello logico di astrazione, l'esercizio di modellazione concettuale trattato sopra:
--
--
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)
);
--
--
Considerazioni sull'integrità e la coerenza dei dati
In accordo con tutto ciò che è stato precedentemente spiegato, il progettista deve garantire che ogni riga del "sottotipo" sia sempre integrata dalla relativa controparte "del sottotipo" e, a sua volta, assicurarsi che detta riga del "sottotipo" sia compatibile con il valore contenuto nella colonna "discriminatore" del supertipo.
Sarebbe molto pratico ed elegante far valere tali circostanze in modo dichiarativo (come propone il quadro relazionale) ma, purtroppo, nessuna delle principali piattaforme SQL ha fornito i meccanismi adeguati per farlo (per quanto ne so). Pertanto, è molto conveniente utilizzare OPERAZIONI ACIDI in modo che queste condizioni siano sempre soddisfatte in un database (un'altra opzione sarebbe quella di utilizzare TRIGGERS, ma tendono a rendere le cose disordinate).
Considerazioni sulla derivazione dei dati
Uno degli aspetti principali del modello relazionale è che considera la derivazione dei dati come un fattore fondamentale nella gestione dei dati. Conformemente, facilita la creazione di (a) di base relazioni -o basi tabelle in SQL, come illustrato nella DDL dichiarazioni superiore alla e (b) derivati relazioni - derivati tabelle in SQL, cioè, quelli dichiarati forza di operazioni SELECT che può essere riparato come viste per ulteriore sfruttamento—.
Quindi, si può dichiarare una vista che raccoglie i punti di dati di gruppo "completi" :
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 un'altra vista che combina le informazioni "complete" di 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;
In questo modo, è molto facile manipolare - in modo dichiarativo - tutti i dati significativi attraverso lo stesso dispositivo a livello logico, cioè la relazione o la tabella (sia essa base o derivata). Evidentemente, l'uso delle viste è più efficace quando i tipi di entità concettuali rappresentati in un database relazionale possiedono più proprietà di interesse, ma è una possibilità che vale la pena illustrare con il presente scenario.
Riferimenti
1 Codd, EF (dicembre 1979). Estensione del modello relazionale del database per acquisire maggiore significato , Transazioni ACM su sistemi di database , Volume 4 Numero 4 (pagg. 397-434). New York, New York, Stati Uniti.
2 Chen, PP (marzo 1976). Il modello-Verso entità-relazione unificata visualizzazione dei dati , transazioni ACM su Database Systems - Numero speciale: documenti della Conferenza Internazionale sulla molto grandi basi dati: settembre 22-24, 1975, Framingham, MA , Volume 1 Issue 1 (pp . 9-36). New York, New York, Stati Uniti.
3 Elmasri, R & Navathe, SB (2003). Fondamenti di sistemi di database , quarta edizione. Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA.
4 National Institute of Standards and Technology (US) [NIST] (dicembre 1993). Definizione di integrazione per la modellizzazione delle informazioni (IDEF1X), pubblicazione sugli standard di elaborazione delle informazioni federali , volume 184. USA.
5 Codd, EF (giugno 1970). Un modello relazionale di dati per grandi banche dati condivise , comunicazioni dell'ACM , volume 13 Numero 6 (pagg. 377-387). New York, New York, Stati Uniti.
6 Vedi riferimento 4
