Implémentation héritage sans relation cyclique

**Driss35** · 01/08/2012, 17h00

Bonjour,

Comment peut-on implémenter l'héritage du diagramme de classe en image au niveau de la base de données sans avoir une relation cyclique ?

Merci d'avance.

**tmanta7** · 01/08/2012, 22h26

Tu n'as pas de relation cyclique, l'héritage (Personne/Proche, Personne/Employe) ce n'est pas de l'association

**fsmrel** · 02/08/2012, 01h55

Bonsoir,

Driss35 a précisé qu’il se positionnait au niveau de la base de données. Si cette base de données est SQL, il n’y a que des tables et la notion d’héritage ne vaut plus (la norme a prévu le concept de supertable/subtable pour les adeptes du "Relationnel/Objet" (sic !), mais cela ne change à rien à ce qui suit).

Le MLD produit par PowerAMC est le suivant :

Si l’on tente de supprimer une personne qui est un employé et si l’action de compensation prévue pour la contrainte référentielle liant EMPLOYE et LIEN_PARENTE est du type RESTRICT, l’opération de suppression n’est effective qu’à la condition que l’employé ne soit en relation avec aucun proche (en notant au passage que de manière naturelle, l'action de compensation prévue pour la contrainte référentielle liant PERSONNE et EMPLOYE est CASCADE) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
CREATE TABLE LIEN_PARENTE
(
        EmpId       INT           NOT NULL
      , ProcheId    INT           NOT NULL
      , LienParente VARCHAR(16)   NOT NULL
    , PRIMARY KEY (EmpId, ProcheId)
    , FOREIGN KEY (EmpId) REFERENCES EMPLOYE ON DELETE RESTRICT
    , FOREIGN KEY (ProcheId) REFERENCES PROCHE ON DELETE CASCADE
) ;

Si la suppression d’un employé doit entraîner celle de ses proches, alors RESTRICT doit être remplacé par CASCADE, mais ceci ne permet que de supprimer les liens, les stimuli ne remontent pas jusqu’aux proches (table PROCHE) qui resteraient orphelins. Dans ces conditions, il faut mettre en œuvre une vue qui soit la jointure naturelle des tables LIEN_PARENTE, PROCHE et PERSONNE, ainsi qu’un trigger propageant les DELETE sur les tables ROCHE et PERSONNE. Dans ces conditions, on a du reste mis en œuvre un cycle mais qui n’apparaît évidemment pas sur le diagramme.

N.B. Ne pas oublier de déclarer {Matricule} comme clé alternative de la table EMPLOYE (même chose pour {Nadhes} le cas échéant).

**Driss35** · 02/08/2012, 11h33

Bonjour,

Merci pour votre réactivité.

Donc, si je comprend bien, on ne peut pas éviter la relation cyclique au niveau de la base de données ?

**fsmrel** · 02/08/2012, 14h35

Au contraire ! Pour créer un cycle il faut vraiment le vouloir : d’abord créer une vue qui permette de le mettre en place, ainsi qu’une trigger pour le rendre opérationnel en mise à jour.

Le diagramme figurant dans mon message précédent montre seulement que pour aller de A à Z on passe par I ou J, on dit qu’on a deux chemins (conterminous paths) ou encore que Z peut être bombardé des deux côtes (pour que ce soit plus parlant, ci-dessous j’ai changé de notation pour le sens des flèches : hier j’ai utilisé la notation « relationnelle » et ci-dessous j’utilise la notation CODASYL, plus en phase avec le sens de la navigation) :

En revanche, selon le diagramme ci-dessous qui représente un cycle, si A lâche une bombe, celle-ci passe par J puis Z puis I et elle lui revient en pleine figure :

Ça me rappelle l'histoire de l’Australien qui a acheté un nouveau boomerang : il n’a jamais pu se débarrasser de l’ancien...