La partie du scénario avec laquelle vous êtes confus peut être modélisée avec une construction classique appelée structure supertype-sous-type 1 .
Je vais (1) présenter quelques idées préliminaires pertinentes, (2) détailler comment je définirais - au niveau conceptuel - le contexte commercial considéré, et (3) fournir des éléments connexes supplémentaires - par exemple, la représentation correspondante au niveau logique via SQL -DDL déclarations— comme suit.
introduction
Une structure de cette nature a lieu lorsque, dans un environnement commercial donné, il existe un cluster de types d'entités au sein duquel le supertype a une ou plusieurs propriétés (ou attributs) qui sont partagées par le reste des types d'entités du cluster, c'est-à-dire , les sous - types . Chaque sous-type a, à son tour, un ensemble particulier de propriétés qui ne s'appliquent qu'à lui-même.
Les clusters de supertype-sous-type peuvent être de deux types:
Exclusif . Se produit lorsqu'une instance du type superentité doit toujours avoir un et un seul homologue de sous-type; par conséquent, les occurrences potentielles de sous-types en question s'excluent mutuellement . C'est le genre qui concerne votre scénario.
Un cas typique dans lequel un sous-type de supertype exclusif se produit est un domaine commercial où une organisation et une personne sont considérées comme des parties légales , comme dans la situation délibérée dans cette série de messages .
Non exclusif . Se présente lorsqu'une instance de supertype peut être complétée par plusieurs occurrences de sous-type , chacune étant obligée d'être d'une catégorie différente .
Un exemple de ce type de supertype-sous-type est traité dans ces articles .
Notes : Il convient de mentionner que les structures de supertype-sous-type - étant des éléments de caractère conceptuel - n'appartiennent pas à un cadre théorique spécifique de gestion des données, que ce soit relationnel, réseau ou hiérarchique - chacune offrant des structures particulières pour représenter des éléments conceptuels -.
Il est également opportun de souligner que, bien que les clusters supertype-sous-type présentent une certaine ressemblance avec l' héritage et le polymorphisme de la programmation d'applications orientées objet (POO) , ils sont en fait des dispositifs distincts car ils servent à des fins différentes. Dans un modèle conceptuel de base de données - qui doit représenter des aspects du monde réel - on traite des caractéristiques structurelles afin de décrire les exigences informationnelles , tandis que dans le polymorphisme OOP et l'héritage, entre autres, un (a) esquisse et (b) implémente des caractéristiques computationnelles et comportementales , aspects qui appartiennent décidément à la conception et à la programmation de programmes d'application.
En dehors de cela, une classe OOP individuelle - étant un composant de programme d'application -, n'a pas nécessairement à «refléter» la structure d'un type d'entité individuel qui appartient au niveau conceptuel de la base de données en question. À cet égard, un programmeur d'application peut généralement créer, par exemple, une seule classe qui «combine» toutes les propriétés de deux (ou plus) types d'entités de niveau conceptuel différents, et une telle classe peut également inclure des propriétés calculées.
Utilisation de constructions entité-relation pour représenter un modèle conceptuel avec des structures supertype-sous-type
Vous avez demandé un diagramme entité-relation (ERD pour la brièveté) mais, bien qu'étant une plate-forme de modélisation extraordinaire, la méthode originale - telle qu'introduite par le Dr Peter Pin-Shan Chen 2 - ne fournissait pas suffisamment de constructions pour représenter des scénarios de la sorte étant discuté avec la précision requise par un modèle conceptuel de base de données approprié.
Par conséquent, il a été nécessaire d'apporter quelques extensions à cette méthode, situation qui a abouti à l'élaboration d'une approche qui aide à la création de diagrammes entité-relation améliorés (EERD) qui, naturellement, ont enrichi la technique de schématisation initiale de nouvelles caractéristiques expressives. . L'une de ces caractéristiques est, précisément, la possibilité de représenter des structures supertype-sous-type.
Modéliser votre contexte d'intérêt
L'illustration de la figure 1 est un EERD (utilisant des symboles similaires à ceux proposés par Ramez A. Elmasri et Shamkant B. Navathe 3 , qui se réfèrent à des structures telles que superclasse / sous-classe ) où j'ai modélisé le domaine commercial que vous décrivez en tenant compte de tous les Caractéristiques. Il est également disponible en format PDF téléchargeable depuis Dropbox .
Comme vous pouvez le voir dans le diagramme susmentionné, les deux Groupet SoloPerformersont affichés en tant que sous-types exclusifs du Artisttype superentité:
Description du diagramme
Pour commencer la description de l’EERD, il est important de souligner que votre phrase
- "Un Artiste doit être soit un Groupe soit un SoloPerformer (mais pas les deux)"
est liée aux aspects de disjonction et d' exhaustivité du cluster supertype-sous-type à portée de main.
Disjonction
La fonctionnalité de disjonction est particulièrement importante car elle se trouve ici même où le «ou la partie» que vous avez mentionné entre en jeu, car an Artistdoit être soit une instance de sous-type, soit l'autre, que j'ai spécifié dans l'EERD à travers le petit cercle contenant la lettre «d», une construction qui reçoit le nom de la règle disjointe .
Lorsqu'un sur-type peut être complété par un ou plusieurs de ses sous-types possibles, ce point doit être exprimé par un petit cercle contenant une étiquette avec la lettre «o», un symbole appelé règle de chevauchement .
Propriété discriminante
Toujours dans le cadre du facteur de disjonction de cette association supertype-sous-type, il convient de prêter une attention particulière à la Artist.Typepropriété, car elle accomplit une tâche très pertinente dans cet arrangement: elle fonctionne comme discriminateur de sous-type . Il est nommé de cette manière car c'est la propriété qui indique le type exclusif de sous-type auquel une instance spécifique d'un se Artistrapporte.
Dans les cas de clusters non exclusifs , l'utilisation d'une propriété discriminante est inutile, car un certain supertype peut avoir plusieurs sous-types en complément (comme mentionné ci-dessus).
Règle de spécialisation totale et exhaustivité
L'exigence qui stipule que chaque Artistdoit toujours avoir une instance de sous-type supplémentaire a à voir avec la caractéristique d'exhaustivité de ce cluster. Ceci est délimité au moyen d'une règle de spécialisation totale , démontrée par le symbole à deux lignes reliant (a) le Artistsupertype à (b) la construction de la règle disjointe.
Mise en relation de groupes avec des artistes solo
Évaluation des phrases
- "Un Groupe est composé d'un ou plusieurs SoloPerformers "
et
- "Un SoloPerformer peut être membre de plusieurs Groupes ou d'aucun Groupe ",
on peut reconnaître que les deux sous-types sont impliqués dans une association (ou relation) plusieurs-à-plusieurs (M: N), que j'ai représentée avec la boîte en forme de losange appelée Group-SoloPerformer.
S'il est implémenté dans une base de données relationnelle en tant que table de base , ce composant serait très utile pour dériver (c'est-à-dire pour effectuer le calcul) le total Numberde ce SoloPerformersqui constitue un béton Group(l'une des exigences que vous avez spécifiées).
L'association entre artistes solo et instruments
La stipulation
- «Un SoloPerformer […] peut jouer un ou plusieurs instruments»
nous permet de déduire que, en même temps,
- "Un Instrument est joué par zéro, un ou plusieurs SoloPerformers".
Ainsi, c'est un autre exemple d'une association M: N, et j'ai utilisé la figure en forme de diamant désignée SoloPerformer-Instrumentpour l'exposer.
Matériels supplémentaires
Afin d'expliquer la portée des structures supertype-sous-type, je vais inclure deux autres ressources, à savoir,
un diagramme IDEF1X 4 présenté à la figure 2 ( et vous pouvez également le télécharger à partir de Dropbox au format PDF ) qui illustre les capacités expressives de ce type de diagrammes concernant le domaine commercial en cause; et
la structure logique DDL de l'exposé respectif qui illustre comment gérer le scénario complet en cours de discussion grâce à un système de gestion de base de données SQL.
1. Représentation IDEF1X
La technique de modélisation de l'information IDEF1X offre certainement la capacité de représenter des structures de supertype-sous-type, mais avec une limitation: elle ne prête pas un mécanisme visuel pour indiquer si un cluster précis est de type exclusif ou non exclusif (ses symboles «natifs» ne peuvent communiquer que l' identification complète ou incomplète de tous les types possibles de sous-entité d'importance). Heureusement, on peut utiliser la notation d'Ingénierie de l'Information (IE) pour montrer plus précisément cet aspect primordial tout en profitant de la puissance descriptive de la norme IDEF1X.
Dans cette technique, la principale caractéristique de votre question est dénommée «relation de catégorisation», où un supertype est appelé «entité générique» et un sous-type reçoit le nom «entité de catégorie». Cependant, je continuerai d'appliquer le terme supertype-subtype dans ce post parce que (1) il a été utilisé par le Dr Edgar Frank Codd, à l'origine du modèle relationnel, (2) il est plus largement connu et (3) la notation IE est utilisé à la place de celui «natif».
Clés étrangères et clusters de sous-type supertype
Comme démontré, IDEF1X offre un autre avantage: les moyens d'exposer les définitions de FOREIGN KEY (FK), éléments de première importance si un praticien va représenter une association de supertype-sous-type dans une base de données relationnelle .
Afin de présenter une telle sorte d'association, la clé primaire (PK) propriété du super - type, à savoir Artist.ArtistNumber, doit migrer vers Groupet SoloPerformer, bien qu'il ait été attribué deux différents noms de rôle 5, 6 , GroupNumberet SoloPerformerNumberrespectivement, dans le but de mettre l' accent la signification véhiculée par la propriété dans le contexte de chaque type de sous-entité.
En plus d'être caractérisées comme PK, les propriétés Group.GroupNumberet SoloPerformer.SoloPerformerNumbersont, en même temps, décrites comme des CLÉS ÉTRANGÈRES (FK) qui font référence à Artist.ArtistNumberla propriété PK de supertype.
Ainsi, étant donné que chaque SoloPerformeret Groupoccurrence est dépendant de l' existence sur une exacte par Artistexemple, ces types d'entités sont impliqués dans une association identifiant qui prend effet par le biais du processus de migration de la propriété PK définie dans les paragraphes précédents.
Clés étrangères et types d'entités associatives
Le diagramme IDEF1X sert également à illustrer les FK qui composent les PK des deux types d'entité associative pertinents, c'est-à-dire, GroupMemberet SoloPerformerInstrument; le premier relie les deux sous-types et le second relie un sous-type à un type d'entité indépendant, c'est-à-dire Instrument.
2. Déclarations logiques SQL-DDL expositoires
Comme expliqué précédemment, une structure de supertype-sous-type est un moyen d'exprimer certains types de conceptualisations spécifiques au domaine métier concernant les exigences d'information, qui peuvent à leur tour être représentées dans une base de données au moyen de constructions distinctes qui doivent correspondre à celles offertes par le particulier paradigme théorique (qu'il soit relationnel, réseau ou hiérarchique) suivi par le système de gestion de base de données utilisé par le concepteur.
L'un des multiples avantages du paradigme relationnel est qu'il permet de représenter l'information dans sa structure naturelle, et les approximations les plus populaires des systèmes proposés dans la théorie relationnelle sont les différents systèmes de gestion de base de données SQL.
Donc, enfin, voici quelques exemples d'instructions DDL - y compris (a) les schémas des tables de base ainsi que (b) certaines des contraintes pertinentes - qui représentent, au niveau logique de l'abstraction, l'exercice de modélisation conceptuelle traité ci-dessus:
--
--
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)
);
--
--
Considérations relatives à l'intégrité et à la cohérence des données
En accord avec tout ce qui a été expliqué précédemment, le concepteur doit garantir que chaque ligne de «supertype» est à tout moment complétée par son homologue «sous-type» qui l'accompagne et, à son tour, s'assurer que ladite ligne de «sous-type» est compatible avec la valeur contenue dans la colonne du «super discriminant».
Il serait très pratique et élégant d'appliquer ces circonstances de manière déclarative (comme le propose le cadre relationnel) mais, hélas, aucune des principales plateformes SQL n'a fourni les mécanismes appropriés pour le faire (pour autant que je sache). Par conséquent, il est très pratique d'utiliser des TRANSACTIONS ACIDES pour que ces conditions soient toujours remplies dans une base de données (une autre option serait d'utiliser TRIGGERS, mais elles ont tendance à rendre les choses désordonnées).
Considérations sur la dérivation des données
L'un des principaux aspects du modèle relationnel est qu'il considère la dérivation des données comme un facteur primordial dans la gestion des données. Conformément, il facilite la création (a) la base des relations -ou base de tables dans SQL, comme indiqué dans les énoncés ci - dessus et DDL (b) dérivées des relations - dérivées tables dans SQL, par exemple, ceux qui sont déclarés à force d'opérations SELECT qui peuvent être fixées comme vues pour une exploitation ultérieure—.
Ainsi, on peut déclarer une vue qui rassemble les points de données de groupe «complets» :
CREATE VIEW FullGroup AS
SELECT G.GroupNumber,
A.Name,
A.CreatedDateTime,
G.FormationDate
FROM Artist A
JOIN MyGroup G
ON G.GroupNumber = A.ArtistNumber;
Et une autre vue qui combine les informations «complètes» 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 cette manière, il est très facile de manipuler - de manière déclarative - toutes les données significatives via le même périphérique de niveau logique, c'est-à-dire la relation ou la table (qu'elle soit de base ou dérivée). De toute évidence, l'utilisation des vues est plus efficace lorsque les types d'entités conceptuelles représentées dans une base de données relationnelle possèdent plus de propriétés d'intérêt, mais c'est une possibilité qui mérite d'être illustrée avec le scénario actuel.
Les références
1 Codd, EF (déc. 1979). Étendre le modèle relationnel de base de données pour obtenir plus de sens , Transactions ACM sur les systèmes de base de données , volume 4, numéro 4 (pp. 397-434). New York, NY, États-Unis.
2 Chen, PP (mars 1976). The Entity-Relationship Model — Toward a Unified View of Data , ACM Transactions on Database Systems - Special issue: Papers from the International Conference on Very Large Data Bases: 22-24 septembre 1975, Framingham, MA , Volume 1 Issue 1 (pp 9-36). New York, NY, États-Unis.
3 Elmasri, R & Navathe, SB (2003). Fundamentals of Database Systems , quatrième édition. Addison-Wesley Longman Publishing Co., Inc. Boston, MA, États-Unis.
4 Institut national des normes et de la technologie (États-Unis) [NIST] (déc. 1993). Définition d'intégration pour la modélisation de l'information (IDEF1X), publication Federal Information Processing Standards , volume 184. USA.
5 Codd, EF (juin 1970). A Relational Model of Data for Large Shared Data Banks , Communications of the ACM , Volume 13 Issue 6 (pp. 377-387). New York, NY, États-Unis.
6 Voir référence 4
La réponse de MDCCL est un superbe résumé des concepts sous-jacents à la superclasse / sous-classe ou à la généralisation / spécialisation tels qu'ils sont décrits au niveau de l'EERD.
Cette réponse vise à mettre en évidence trois modèles ou techniques de conception qui valent la peine d'être connus lorsque vient le temps de transformer l'EERD en une conception relationnelle, basée sur des tables définies avec des colonnes définies.
Voici les trois:
Les deux premiers sont des alternatives, l'un est bon pour les cas simples où presque toutes les données se rapportent à la superclasse. La seconde est plus compliquée, mais peut fonctionner mieux lorsque beaucoup de données se rapportent aux différentes sous-classes. Le mot «héritage» est utilisé pour indiquer que la conception fournit une partie du même pouvoir expressif que l'héritage fournirait dans un modèle d'objet.
La clé primaire partagée est une technique par laquelle les entrées dans les tables de sous-classe peuvent acquérir une identité en "héritant" de l'identité de l'entrée correspondante dans la table de superclasse.
Dans SO, il y a trois balises avec ces noms. L'onglet Info sous chaque balise fournit une description et de nombreuses questions sont regroupées sous les balises.
Il existe également de nombreux sites Web qui présentent ces techniques. Je recommande ceux de Martin Fowler. J'aime la façon dont il le présente. Voici quelques pages Web:
Héritage de table unique Classe Héritage de table
la source