Modélisation d'un scénario dans lequel chaque artiste musical est un groupe ou un artiste solo

12

Je dois concevoir un diagramme entité-relation (ERD) pour un contexte commercial impliquant la délimitation d' artistes musicaux , comme je le détaillerai ci-dessous.

Description du scénario

  • Un artiste a un nom , et doit être soit un groupe ou un Performer Solo (mais pas les deux).

  • Un groupe est composé d'un ou de plusieurs artistes solo et a un nombre de membres (qui doit être calculé à partir du nombre d' artistes solo composant le groupe ).

  • Un artiste solo peut être membre de nombreux groupes ou d'aucun groupe et peut jouer un ou plusieurs instruments .

Question

Comment construire un ERD pour représenter un tel scénario? Je suis confus avec le «ou» la partie.

Boshir
la source

Réponses:

15

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é:

Diagramme amélioré de relation d'entité d'artistes musicaux

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,

  1. 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

  2. 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».

Artistes de musique Diagramme IDEF1X

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

MDCCL
la source
4

La réponse de MDCCL est fascinante, éducative et vraisemblablement correcte (bien qu'au-dessus de mon niveau de rémunération).

En revanche, j'ai réinterprété la question et je suis revenu à l'essentiel pour trouver la solution la plus simple possible. Peut-être que je triche et que je ne réponds pas vraiment à la question… mais c'est le cas de toute façon.

J'étais confus en lisant et en relisant la Question. En voyant le terme "artiste", je pensais à des personnes individuelles. Mais non, cela signifie dans le sens de "l'étiquetage de marque artistique", comme un album de disques de musique a un titre et un "artiste", que l'artiste soit un individu comme Johnny Cash ou un groupe comme The Cure .

Prenons comme exemple l'artiste désormais connu sous le nom de Prince . Il a publié des albums en tant que:

Tous les quatre seraient des exemples d '"Artiste". En particulier, il y avait deux femmes, Wendy Melvoin et Lisa Coleman, dans son groupe The Revolution mais pas dans New Power Generation , partis pour poursuivre leur carrière sous la marque Wendy & Lisa .

Ainsi, nous aurions encore une autre instance de "Artist" avec Wendy & Lisa tandis que les individus Melvoin et Coleman seraient chacun des interprètes mais pas "Artist". Ces femmes seraient assignées comme interprètes à deux «artistes» ((1) Prince & The Revolution , (2) Wendy & Lisa ).

Le diagramme suivant est une tentative maladroite de montrer cet exemple de données de manière compacte. Nous montrons les deux femmes soulignées (Interprètes) appartenant à deux groupes différents (Artistes). Et nous montrons l'homme en italique, Prince, appartenant à quatre groupes (Artistes) mais n'appartenant pas au dernier groupe (Artiste).

entrez la description de l'image ici

Si cela décrit le domaine d'activité, je proposerais la conception de tableau suivante (et ERD).

Diagramme de conception de table d'artiste, d'adhésion, d'interprète, de joueur, d'instrument

Fondamentalement, nous avons une paire de relations plusieurs à plusieurs:

  • Un artiste (qu'il soit en solo ou en groupe) est un ou plusieurs interprètes affectés. Et un interprète peut être membre d'un ou de plusieurs «artistes» / groupes.
  • Un artiste peut jouer un ou plusieurs instruments. Et chaque Instrument peut avoir de nombreux Performers répertoriés comme capables de le jouer.

Comme pour "Group" et "SoloPerformer":

  • Un "Solo" est simplement n'importe quel "Artiste" avec seulement un "Interprète" assigné.
    (Un seul enregistrement enfant dans la table Membership a cet ID d'artiste attribué comme clé étrangère.)
  • Un "groupe" est un "artiste" auquel plusieurs "interprètes" sont affectés.
    (Deux enregistrements enfants ou plus dans la table des membres ont cet ID d'artiste attribué comme clé étrangère.)

Si une partie de la logique métier consiste à faire la distinction entre les éléments Artiste qui sont Solo ou Groupe, nous pouvons en SQL effectuer des requêtes pour les lignes Artiste qui n'ont qu'une seule table d'appartenance par rapport à celles qui en ont plusieurs. Mais en pratique, il est probablement judicieux de dénormaliser ces informations en:

  • Ajout d'un booléen "Solo / Groupe" sur la table Artist, et…
  • Appliquez cette adhésion unique / multiple dans les applications.

Si le but de la Question était d'appliquer cette distinction Solo versus Groupe dans la structure de la base de données (ou ERD), alors j'ai échoué. Mais de toute façon, j'espère que cette réponse peut s'avérer intéressante et utile.

Basil Bourque
la source
Très bonne perspective
Pmpr
2

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:

  • Héritage de classe unique
  • Héritage de table de classe
  • Clé primaire partagée

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

Walter Mitty
la source