IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Voir le flux RSS

fsmrel

DB-MAIN - Spécialisation, généralisation des entités-types (héritage)

Note : 3 votes pour une moyenne de 5,00.
par , 27/03/2016 à 20h56 (6553 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) :




_______________________________________________________________________________

Envoyer le billet « DB-MAIN - Spécialisation, généralisation des entités-types (héritage) » dans le blog Viadeo Envoyer le billet « DB-MAIN - Spécialisation, généralisation des entités-types (héritage) » dans le blog Twitter Envoyer le billet « DB-MAIN - Spécialisation, généralisation des entités-types (héritage) » dans le blog Google Envoyer le billet « DB-MAIN - Spécialisation, généralisation des entités-types (héritage) » dans le blog Facebook Envoyer le billet « DB-MAIN - Spécialisation, généralisation des entités-types (héritage) » dans le blog Digg Envoyer le billet « DB-MAIN - Spécialisation, généralisation des entités-types (héritage) » dans le blog Delicious Envoyer le billet « DB-MAIN - Spécialisation, généralisation des entités-types (héritage) » dans le blog MySpace Envoyer le billet « DB-MAIN - Spécialisation, généralisation des entités-types (héritage) » dans le blog Yahoo

Commentaires