DB-MAIN - Spécialisation, généralisation des entités-types (héritage)
par
, 27/03/2016 à 20h56 (6846 Affichages)
____________________________________________________________________________________________________
On a vu comment créer des entités-types et leurs associations avec DB-MAIN. Il s’agit ici de modéliser la spécialisation - généralisation des entités-types (héritage).
(1) Situation initiale
Partons de la situation suivante, dans laquelle on a à modéliser le fait que des tiers sont ou bien des clients, ou bien des fournisseurs de l’entreprise Dubicobit :
(2) Actions portant sur les entités-types devant jouer le rôle de sous-type
Pour faire de l’entité-type CLIENT un sous-type, une spécialisation de l’entité-type TIERS, on clique sur l’entité-type CLIENT pour provoquer l’affichage de la boîte de propriétés qui lui correspond, et dans laquelle on va s’intéresser en particulier à la propriété « supertypes » :
En cliquant sur le bouton associé à la propriété « supertypes », on provoque l’ouverture de la fenêtre « Multiple choice dialog » qui fournit la liste des noms des entités-types pouvant être surtypes de CLIENT :
Dans la boîte de dialogue, on clique sur "TIERS" puis sur le bouton « <<Add first », ce qui provoque le transfert de "TIERS" à gauche :
On clique sur « Ok » et le MCD a subi la transformation attendue, l’entité-type TIERS est devenue surtype de l’entité-type CLIENT :
On fait subir à l’entité-type FOURNISSEUR un régime analogue à celui de l’entité-type CLIENT, et l’on aboutit à la situation suivante, dans laquelle ces deux entités-types sont sous-types de TIERS :
A titre indicatif, le code SQL de création des tables sera très voisin de celui-ci (se référer au billet où l’on traite de la production du MLD et du script SQL de définition des tables) :
CREATE TABLE TIERS ( TiersId INT NOT NULL, TiersNom VARCHAR(32) NOT NULL, TiersSiret DECIMAL(14) NOT NULL, TiersIban VARCHAR(27) NOT NULL, CONSTRAINT TIERS_PK PRIMARY KEY (TiersId), CONSTRAINT TIERS_SIRET_AK UNIQUE (TiersSiret), CONSTRAINT TIERS_IBAN_AK UNIQUE (TiersIban) ); CREATE TABLE CLIENT ( TiersId INT NOT NULL, CondTarifaire CHAR(1) NOT NULL, CONSTRAINT CLIENT_PK PRIMARY KEY (TiersId) ); CREATE TABLE FOURNISSEUR ( TiersId INT NOT NULL, TauxRemise DECIMAL(4,2) NOT NULL, CONSTRAINT FOURNISSEUR_PK PRIMARY KEY (TiersId) ); ALTER TABLE CLIENT ADD CONSTRAINT CLIENT_TIERS_FK FOREIGN KEY (TiersId) REFERENCES TIERS (TiersId) ; ALTER TABLE FOURNISSEUR ADD CONSTRAINT CLIENT_FOURNISSEUR_FK FOREIGN KEY (TiersId) REFERENCES TIERS (TiersId) ;
(3) Actions portant sur les entités-types devant jouer le rôle de surtype
Si un tiers est forcément un client ou un fournisseur, c'est-à-dire si l’ensemble des tiers est égal à l’union (au sens ensembliste) des clients et des fournisseurs, alors on définit une contrainte de totalité. Pour cela, on clique sur l’entité-type TIERS, laquelle joue le rôle de surtype, et dans la boîte de propriétés on coche la case « total » :
Au résultat :
Si un tiers ne peut pas être à la fois client et fournisseur, on définit une contrainte d’exclusion. Pour cela, on clique sur l’entité-type TIERS, et dans la boîte de propriétés on coche la case « disjoint » :
Au résultat :
La contrainte de partitionnement est la fois contrainte de totalité et contrainte d’exclusion. Pour mettre en œuvre cette contrainte, on clique sur l’entité-type TIERS, et dans la boîte de propriétés on coche les deux cases « total » et « disjoint » :
Au résultat (Comme dit Pierre Dac : « Le monde des uns n’est pas celui des autres, bien que le monde des uns et des autres soit le monde de tout le monde » ) :
Mais ces contraintes seront à programmer, facilement à l’aide de contraintes en relationnel pur, difficilement en SQL, à l’aide de palliatifs tels que des triggers (en ce qui concerne l’exclusion), ou de solutions tordues, par exemple à coup de clés étrangères inverses (cas de la totalité), mais pouvant laisser des erreurs se glisser.
(4) Spécialisation-généralisation à tous les étages
Rien n’interdit qu’une entité-type joue à la fois le rôle de surtype et de sous-type, cas de l’entité-type TIERS ci-dessous, devenant sous-type de l’entité-type PERSONNE, tout comme l’entité-type COLLABORATEUR (utilisée pour modéliser les employés de l’entreprise Dubicobit) :
_______________________________________________________________________________