Discussion :

[champomy62]

Bonjour a tous,

J'ai découvert l'identification relative grace aux forums de developpez! J'aimerai savoir jusqu'a ou peut-on propager cette identification ? Autant qu'on veut ou doit-on se fixer une limite ? Comment savoir cette limite ? Quels conseils donneriez-vous ?

Infos: Je travail sur une base de données de plus de 100 tables

Merci

[fsmrel]

Bonsoir champomy62,


Je rappelle que l’identification relative permet d’exprimer une relation de composition entre deux entités-types, l’une étant considérée comme forte et l’autre faible (weak entity type). L’exemple classique : une commande est composée de lignes de commande : la ligne de commande peut être considérée comme une propriété multivaluée de la 1re ; ainsi, en relationnel pur, la relvar (variable relationnelle) COMMANDE peut avoir comme attributs les classiques numéro de commande, date de commande, montant, mais aussi la ligne de commande qui fait alors l’objet d’un RVA (Relation Valued Attribute).

A son tour, la ligne de commande peut être considérée comme forte par rapport aux engagements sur lignes de commandes, etc. Ainsi, l’analogie avec les poupées russes est frappante (si je jette la grande, je les jette toutes, si je supprime une commande, je supprime tout ce qu'elle contient).




Plus traditionnellement, de la ligne de commande on fait une entité-type LIGNE_COMMANDE, identifiée relativement à l’entité-type COMMANDE. A son tour, de l’entité-type ENGAGEMENT on fait une entité-type faible relativement à entité-type LIGNE_COMMANDE, etc. Le système de l’identification relative ne date pas d’aujourd’hui, on peut l’attribuer à Ted Codd, qui montre dans son article fondateur A Relational Model of Data for Large Shared Data Banks comment normaliser (attention, il n’utilisait pas de RVA, car à l’époque il n’avait pas encore inventé le mécanisme du nommage des attributs).

Vous aimeriez savoir jusqu'où peut-on propager l’identification relative.

Quelle limite fixer pour l’emboîtement les matriochkas ? Ci-dessus, il y a quatre poupées : on peut très bien en rajouter une autre, puis une autre, ad libitum :




Variante (non limitée non plus) :




Dans le cas des commandes, tant qu’une propriété est multivaluée, on en fait une entité-type faible, identifiée relativement à sa maman. C’est la sémantique qui commande.

Un des côtés pratiques de l'identification relative : le traitement des contraintes de chemin, voyez par exemple ici ou là (l’exemple des livraison des commandes) et là pour l'aspect performance.

[champomy62]

Vos réponses sont toujours aussi claires! Merci


donc je retiens de votre post, tant que l'identification relative a du sens elle peut etre utilise.

[fsmrel]

Bonsoir champomy,

Vos réponses sont toujours aussi claires! Merci

Alors n’hésitez pas à aller voir mon profil pro, onglet "Compétences" et voter en conséquence

[champomy62]

D'ailleurs j'ai une derniere question.

Sommes nous toujours obliger l'incrementation relative lorsqu'on utilise l'identification relative ?



(clavier qwerty)

[fsmrel]

Bonsoir champomy,

Sommes nous toujours obliger l'incrementation relative lorsqu'on utilise l'identification relative ?

Certes non ! Mais disons que c’est assez « logique ». Le point le important à traiter est en fait celui du 1er attribut figurant dans la liste des attributs composant la clé. Je raisonne là en DBA (db2 for z/OS), donc au niveau SGBD, SQL : pour reprendre l’exemple de la prise de commandes, si la table COMMANDE est identifiée relativement à la table CLIENT, peu importe les valeurs prises par l’attribut CommandeId en ce qui concerne la clé {ClientId, CommandeId}, la règle essentielle à respecter étant bien entendu que l’on n’essaie pas de créer des clés en double, car le SGBD nous jettera. Et bien entendu, utilisons des clés invariantes.

Maintenant, si la table COMMANDE n’est pas identifiée relativement à la table CLIENT, c'est-à-dire si elle est identifiée de façon absolue, avec {CommandeId} pour clé, l’incrémentation relative peut poser des problèmes, car si N utilisateurs créent en même temps des commandes, il va y avoir contention sur les pages physiques (tablespaces et index) suite à leur verrouillage du fait des mises à jour. J’ai bien connu cela du temps où je prototypais les performances des applications de prise de commande et semblables :
Le moyen d’éviter les contentions était que je hache les valeurs prises par les clés, de manière à les disperser loin les unes des autres dans les index et les tablespaces.

Mais dans le cas de l’identification relative, les matriochkas autres que la plus grande ne posent aucun problème, puisque leur dispersion physique suivra celle de la grande matriochka. Si vous voulez un exemple d’utilisation de l’incrémentation relative, voyez la discussion ici, notamment le message #4.

[champomy62]

Je vous pose cette question car sur mon domaine d'application, je ne vois aucun intérêt... J'utilise surtout l'identification relative pour résoudre les contraintes de chemin et peut-etre par la suite utiliser la clusterisation.

J'ai encore deux questions en rapport a l'identification relative:

1) Comment s'appelle identification relative en anglais ? Composite key ou relative identification ?
2) Lorsqu'on propage l'identification relative, est-ce l'ensemble doit faire parti de la clé primaire ? Un exemple sera plus parlant

Prenons 3 tables nommées A -> B -> C

La table A aura pour cle primaire [A_id]
La table B aura pour cle primaire [A_id, B_id]

La table C doit-t-elle avoir pour cle primaire:
[A_id, B_id, C_id]

Ou puis-je faire ceci:
[A_id, C_id] et en cle etrangere [B_id]

Je retourne bouquiner mon livre 'introduction sur les bases de donnees' de C.J Date

Merci

[fsmrel]

Bonsoir champomy,

Comment s'appelle identification relative en anglais ? Composite key ou relative identification ?

Certainement pas « Composite key », car si vous prenez le cas de la clé de la relvar SP de Chris Date : {S#, P#}, elle est composée (c'est-à-dire non singleton) sans pour autant que l’identification relative se manifeste.

Quant à la traduction en anglais de « relative identification », il faudrait vois si ça existe dans Power Designer, le petit frère de PowerAMC. Le père de l’approche E/R, Peter Chen pour sa part dit seulement ceci dans son article fondateur :

If relationships are used for Identifying the entities, we shall call it a weak entity relation.

Vous pouvez aussi fouiller dans la documentation de DB-MAIN.


A défaut, à vous l’honneur et la paternité de la traduction.

Lorsqu'on propage l'identification relative, est-ce l'ensemble doit faire partie de la clé primaire ?

Pour prendre votre exemple, vous pouvez bien entendu définir ainsi la clé primaire de la table C : {A_id, C_id}, la condition étant, si tant est qu’il faille le rappeler, que vous ne tentiez pas d’injecter des doublons. Par contre, la clé étrangère n’est pas le singleton {B_Id}, mais la paire {A_id, B_id}, puisque la table C fait référence à la table B qui a pour clé primaire {A_id, B_id}.

N.B. Une clé est un ensemble, il faut donc utiliser les accolades : {A_id, C_id} plutôt que les crochets [A_id, C_id].

Je retourne bouquiner mon livre 'introduction sur les bases de donnees' de C.J Date

Pieuse et édifiante lecture, que je ne peux que recommander à tous

[champomy62]

effectivement, je m'étais trompe sur la clé étrangère. Merci bien.

Je vais aller lire le document de Peter Chen, qui a l'air super interessant.

Encore merci pour votre aide.

[champomy62]

Oh une dernière question plutôt interessante.

Imaginons que je decide pour une table d'utiliser l'identification absolue et puis quelque temps apres je souhaite passer a l'identification relative car je me suis apercu que c'etait pas forcement la meilleure solution...

Comment proceder a la mise a jour sans tout casser ? Avez-vous quelques conseils a donner ?

Merci

[fsmrel]

Bonsoir champomy,

Comment procéder a la mise a jour sans tout casser ? Avez-vous quelques conseils a donner ?

1) Il s’agit d’abord de recenser les tables dont les clé primaires et étrangères vont être modifiées.

2) Y ajouter les colonnes qui devront être présentes dans la version « relative ».

3) Copier dans ces colonnes les valeurs des clés parentes.

4) Supprimer les (contraintes de) clés étrangères dont la structure va évoluer.

5) Supprimer les (contraintes de) clés primaires dont la structure va évoluer.

6) Définir les nouvelles (contraintes de) clés primaires.

7) Définir les nouvelles (contraintes de) clés étrangères.


Mais pour y voir plus clair, prenons un exemple, celui des devis, factures et livraisons chez Benallasiham, où l’on a les deux versions de l’identification : absolue et relative.


Version « absolue »




Version « relative »





Pour mémoire, les structures des tables identifiées en absolu sont les suivantes, accompagnées d’un jeu d’essai permettant de s’assurer qu’en cours de changement du système d’identification on ne se plante pas (les données existantes ne sont pas modifiées) :

CREATE TABLE ARTICLE
(
   ArticleId               INT                  NOT NULL,
   Designation             VARCHAR(64)          NOT NULL,
   CONSTRAINT ARTICLE_PK PRIMARY KEY (ArticleId)
) ;

CREATE TABLE CLIENT
(
        ClientId                INT                  NOT NULL,
        CLientNom               VARCHAR(64)          NOT NULL,
    CONSTRAINT CLIENT PK PRIMARY KEY (ClientId)
) ;

CREATE TABLE DEVIS 
(
        DevisId                 INT                  NOT NULL,
        ClientId                INT                  NOT NULL,
        DateEnvoi               DATETIME             NOT NULL,
        DateValidation          DATETIME             NOT NULL,
        DevisMontant            INT                  NOT NULL,
    CONSTRAINT DEVIS_PK PRIMARY KEY (DevisId),
    CONSTRAINT DEVIS_CLIENT_FK FOREIGN KEY (ClientId) REFERENCES CLIENT (ClientId) 
) ;

CREATE TABLE LIGNE_DEVIS
(
        LigneDevisId            INT                  NOT NULL,
        DevisId                 INT                  NOT NULL,
        ArticleId               INT                  NOT NULL,
        Quantite                INT                  NOT NULL,
        PrixHT                  INT                  NOT NULL,
        TVA                     DECIMAL(4,2)         NOT NULL,
    CONSTRAINT LIGNE_DEVIS_PK PRIMARY KEY (LigneDevisId),
    CONSTRAINT LIGNE_DEVIS_DEVIS_FK FOREIGN KEY (DevisId) REFERENCES DEVIS (DevisId),
    CONSTRAINT LIGNE_DEVIS_ARTICLE_FK FOREIGN KEY (ArticleId) REFERENCES ARTICLE (ArticleId)
) ;

CREATE TABLE FACTURE 
(
        FactureId               INT                  NOT NULL,
        ClientId                INT                  NOT NULL,
        FactureDate             DATETIME             NOT NULL,
    CONSTRAINT FACTURE_PK PRIMARY KEY (FactureId),
    CONSTRAINT FACTURE_CLIENT_FK FOREIGN KEY (ClientId) REFERENCES CLIENT (ClientId)
) ;

CREATE TABLE BON_LIVRAISON 
(
        BonId                   INT                  NOT NULL,
        FactureId               INT                  NOT NULL,
        DateLivraison           DATETIME             NOT NULL,
    CONSTRAINT BON_LIVRAISON_PK PRIMARY KEY (BonId),
    CONSTRAINT BON_LIVRAISON_FACTURE_FK FOREIGN KEY (FactureId) REFERENCES FACTURE (FactureId)
) ;

CREATE TABLE BON_DETAIL
(
        BonId                   INT                  NOT NULL,
        LigneDevisId            INT                  NOT NULL,
  CONSTRAINT BON_DETAIL_PK PRIMARY KEY (LigneDevisId),
  CONSTRAINT BON_DETAIL_BON_LIVRAISON_FK FOREIGN KEY (BonId) REFERENCES BON_LIVRAISON  (BonId),
  CONSTRAINT BON_DETAIL_LIGNE_DEVIS_FK FOREIGN KEY (LigneDevisId) REFERENCES LIGNE_DEVIS (LigneDevisId)
) ;


INSERT INTO ARTICLE (ArticleId, Designation) VALUES (1, 'schmilblick') ; 
INSERT INTO ARTICLE (ArticleId, Designation) VALUES (2, 'biglotron') ; 
INSERT INTO ARTICLE (ArticleId, Designation) VALUES (3, 'boulon') ; 

INSERT INTO CLIENT (ClientId, CLientNom) VALUES (1, 'Etablissements Naudin Montauban') ; 
INSERT INTO CLIENT (ClientId, CLientNom) VALUES (2, 'Volfoni Frères') ; 
INSERT INTO CLIENT (ClientId, CLientNom) VALUES (3, 'Delafoy, Instruments de ménage') ; 

INSERT INTO DEVIS (ClientId, DevisId, DateEnvoi, DateValidation, DevisMontant) VALUES (1, 1, '2013-08-01', '2013-08-05', 1500) ; 
INSERT INTO DEVIS (ClientId, DevisId, DateEnvoi, DateValidation, DevisMontant) VALUES (2, 2, '2013-07-14', '2013-08-02', 7000) ; 

INSERT INTO LIGNE_DEVIS (DevisId, LigneDevisId, ArticleId, Quantite, PrixHT, TVA) VALUES (1, 1, 1, 10, 100, 19.6) ; 
INSERT INTO LIGNE_DEVIS (DevisId, LigneDevisId, ArticleId, Quantite, PrixHT, TVA) VALUES (1, 3, 3, 40, 150, 19.6) ; 
INSERT INTO LIGNE_DEVIS (DevisId, LigneDevisId, ArticleId, Quantite, PrixHT, TVA) VALUES (1, 5, 3, 20, 200, 19.6) ; 
INSERT INTO LIGNE_DEVIS (DevisId, LigneDevisId, ArticleId, Quantite, PrixHT, TVA) VALUES (1, 6, 3, 20, 200, 19.6) ; 
INSERT INTO LIGNE_DEVIS (DevisId, LigneDevisId, ArticleId, Quantite, PrixHT, TVA) VALUES (2, 2, 2, 20, 200, 19.6) ; 
INSERT INTO LIGNE_DEVIS (DevisId, LigneDevisId, ArticleId, Quantite, PrixHT, TVA) VALUES (2, 4, 3, 20, 200, 19.6) ; 

INSERT INTO FACTURE (ClientId, FactureId, FactureDate) VALUES (1, 1, '2013-08-02') ; 
INSERT INTO FACTURE (ClientId, FactureId, FactureDate) VALUES (2, 2, '2013-07-28') ; 
INSERT INTO FACTURE (ClientId, FactureId, FactureDate) VALUES (1, 3, '2013-08-03') ; 
INSERT INTO FACTURE (ClientId, FactureId, FactureDate) VALUES (2, 4, '2013-08-03') ; 
INSERT INTO FACTURE (ClientId, FactureId, FactureDate) VALUES (1, 5, '2013-08-02') ; 

INSERT INTO BON_LIVRAISON (FactureId, BonId, DateLivraison) VALUES (1, 1, '2013-08-03') ; 
INSERT INTO BON_LIVRAISON (FactureId, BonId, DateLivraison) VALUES (1, 2, '2013-08-04') ; 
INSERT INTO BON_LIVRAISON (FactureId, BonId, DateLivraison) VALUES (2, 3, '2013-07-29') ; 
INSERT INTO BON_LIVRAISON (FactureId, BonId, DateLivraison) VALUES (3, 4, '2013-07-29') ; 
INSERT INTO BON_LIVRAISON (FactureId, BonId, DateLivraison) VALUES (4, 5, '2013-07-29') ; 
INSERT INTO BON_LIVRAISON (FactureId, BonId, DateLivraison) VALUES (5, 6, '2013-07-29') ; 

INSERT INTO BON_DETAIL (LigneDevisId, BonId) VALUES (1, 2) ; 
INSERT INTO BON_DETAIL (LigneDevisId, BonId) VALUES (5, 6) ; 
INSERT INTO BON_DETAIL (LigneDevisId, BonId) VALUES (2, 5) ;

Pour faire évoluer la version absolue, on peut commencer par ajouter les colonnes qui devront être présentes dans la version « relative ».

Sont concernées les tables BON_LIVRAISON, BON_DETAIL et LIGNE_DEVIS (j’utilise ici MySQL) :

ALTER TABLE BON_LIVRAISON
    ADD COLUMN ClientId INT NOT NULL DEFAULT 0 ;

ALTER TABLE BON_DETAIL
    ADD COLUMN ClientId INT NOT NULL DEFAULT 0,
    ADD COLUMN FactureId INT NOT NULL DEFAULT 0, 
    ADD COLUMN DevisId INT NOT NULL DEFAULT 0 ;

ALTER TABLE LIGNE_DEVIS
    ADD COLUMN ClientId INT NOT NULL DEFAULT 0  ;

Une fois les colonnes présentes, en tant que futures clés étrangères, on peut y recopier les valeurs des futures clés primaires des tables parentes :

UPDATE BON_LIVRAISON 
    SET ClientId = (SELECT ClientId FROM FACTURE WHERE BON_LIVRAISON.FactureId = FACTURE.FactureId) ;  

UPDATE BON_DETAIL 
    SET ClientId = (SELECT ClientId FROM BON_LIVRAISON WHERE BON_DETAIL.BonId = BON_LIVRAISON.BonId)
      , FactureId = (SELECT FactureId FROM BON_LIVRAISON WHERE BON_DETAIL.BonId = BON_LIVRAISON.BonId)
      , DevisId = (SELECT DevisId FROM LIGNE_DEVIS WHERE BON_DETAIL.LigneDevisId = LIGNE_DEVIS.LigneDevisId) ;

UPDATE LIGNE_DEVIS 
    SET ClientId = (SELECT ClientId FROM DEVIS WHERE LIGNE_DEVIS.DevisId = DEVIS.DevisId) ;  

On supprime les clés étrangères dont la composition va changer. Attention, l’ordre compte, soyons vigilants !

 
ALTER TABLE BON_DETAIL DROP FOREIGN KEY BON_DETAIL_BON_LIVRAISON_FK
                     , DROP FOREIGN KEY BON_DETAIL_LIGNE_DEVIS_FK ;
     
ALTER TABLE BON_LIVRAISON DROP FOREIGN KEY BON_LIVRAISON_FACTURE_FK ;

ALTER TABLE LIGNE_DEVIS DROP FOREIGN KEY LIGNE_DEVIS_DEVIS_FK ;

Une fois supprimées les clé étrangères, on peut supprimer les clés primaires dont la composition va aussi changer :

ALTER TABLE FACTURE DROP PRIMARY KEY ;
ALTER TABLE BON_LIVRAISON DROP PRIMARY KEY ;
ALTER TABLE BON_DETAIL DROP PRIMARY KEY ;
ALTER TABLE DEVIS DROP PRIMARY KEY ;
ALTER TABLE LIGNE_DEVIS DROP PRIMARY KEY ;

On définit ensuite les nouvelles clés primaires :

ALTER TABLE FACTURE ADD CONSTRAINT FACTURE_PK PRIMARY KEY (ClientId, FactureId) ;
ALTER TABLE BON_LIVRAISON ADD CONSTRAINT BON_LIVRAISON_PK PRIMARY KEY (ClientId, FactureId, BonId) ;
ALTER TABLE BON_DETAIL ADD CONSTRAINT BON_DETAIL_PK PRIMARY KEY (ClientId, DevisId, LigneDevisId) ;
ALTER TABLE DEVIS ADD CONSTRAINT DEVIS_PK PRIMARY KEY (ClientId, DevisId) ;
ALTER TABLE LIGNE_DEVIS ADD CONSTRAINT LIGNE_DEVIS_PK PRIMARY KEY (ClientId, DevisId, LigneDevisId) ;

Et on termine le travail en définissant les nouvelles clés étrangères :

ALTER TABLE BON_LIVRAISON ADD CONSTRAINT BON_LIVRAISON_FACTURE_FK 
    FOREIGN KEY (ClientId, FactureId) REFERENCES FACTURE (ClientId, FactureId) ;
                      
ALTER TABLE LIGNE_DEVIS ADD CONSTRAINT LIGNE_DEVIS_DEVIS_FK 
    FOREIGN KEY (ClientId, DevisId) REFERENCES DEVIS (ClientId, DevisId) ;
                     
ALTER TABLE BON_DETAIL ADD CONSTRAINT BON_DETAIL_BON_LIVRAISON_FK 
    FOREIGN KEY (ClientId, FactureId, BonId) REFERENCES BON_LIVRAISON (ClientId, FactureId, BonId) ;  

ALTER TABLE BON_DETAIL ADD CONSTRAINT BON_DETAIL_LIGNE_DEVIS_FK 
    FOREIGN KEY (ClientId, DevisId, LigneDevisId) REFERENCES LIGNE_DEVIS (ClientId, DevisId, LigneDevisId) ;

Bon, les valeurs relatives sont en fait les anciennes valeurs absolues, mais ça ne gêne pas. A partir de la nouvelle structure en place, on peut incrémenter sans problème dans le style relatif.

[champomy62]

Bonjour fsmrel, Merci de votre réponse

Disons que ça se prépare à l'avance... La plupart des étapes sont plutôt faciles sauf celle ou vous mentionnez :

On supprime les clés étrangères dont la composition va changer. Attention, l’ordre compte, soyons vigilants !

En tout cas l'identification relative est géniale (Sur une base de 120 tables environs, je n'ai que 4 triggers alors que si j'avais utilisais l'identification absolue j'aurai du en créer en pagailles...). Par contre ça signifie d'être en mesure de bien IDENTIFIER les clés primaires sinon bonjour la catastrophe...

D'ailleurs à ce sujet. A-t-on le droit de prendre des raccourcis avec l'identification relative, si elle permet de résoudre une contrainte de chemin et que j'évite le doublon ?

Je vous explique un peu le soucis:

Au départ pour une entitée donnée F, j'ai identifié sa clé primaire telles que {F_id (auto-inc, pk), A_id (int, fk), B_id(int, fk), C_id(int, fk), D_id(int, fk), E_id(int, fk)}

Grâce à cette clé primaire j'aurai pu résoudre une contrainte de chemin dans la sous entitée de F nommée F_A mais j'avais jugé que la clé primaire était trop longue mais c'était avant de vous poser la question. Contrainte de chemin qui se trouve dans l'entité nommée Z. Alors j'ai préféré utiliser l'identification absolue et j'ai du me résigner à créer un trigger.

Au fil du temps, je m'améliore, je vous embête par ci, par là avec toutes mes questions idiotes et m'est venue une idée.

Je voudrai faire un raccourci:

Pour l’entité donnée F, sa clé primaire serait {F_id (auto_increment, pk), B_id (int, fk), C_id (int, fk)}
B et C car sa me permettrait de résoudre la contrainte que je souhaite

Pour cette même entité, ses clés étrangères seraient {A_id(int, fk), C (int, fk), E_id(int, fk)}


Dans l’entité F_A, la clé primaire serait {F_id (int, fk), Y_id (int, fk)} => ça permet d'éviter un doublon ici
et par la même occasion de résoudre ma contrainte de chemine {B, C, Y} qui se trouve dans l'entité Z, car j'aurai propagé les clés nécessaires.

Donc ici je n'y vois que du bonus car j'évite le doublon mais aussi le trigger. Qu'en pensez vous ?




Merci

[fsmrel]

Bonjour champomy,

A-t-on le droit de prendre des raccourcis avec l'identification relative, si elle permet de résoudre une contrainte de chemin et que j'évite le doublon ?

Dans l’exemple que j’ai proposé, les clés sont « verbeuses », et l’on peut préférer l’identification relative en se limitant à des clés primaires bi-colonnes (donc même chose quant aux clés étrangères). Dans cet exemple, l’objectif est de propager la colonne ClientId pour résoudre la contrainte de chemin et éviter des triggers.

Ainsi, si l’on examine la table BON_DETAIL, c’est donc fondamentalement la colonne ClientId qui compte, alors qu’on peut se dispenser de la colonne FactureId.

Le processus de transformation des identifiants absolus peut se simplifier ainsi :


Ajout de la seule colonne ClientId dans les tables :

ALTER TABLE BON_LIVRAISON
    ADD COLUMN ClientId INT NOT NULL DEFAULT 0  ;

ALTER TABLE BON_DETAIL
    ADD COLUMN ClientId INT NOT NULL DEFAULT 0 ;

ALTER TABLE LIGNE_DEVIS
    ADD COLUMN ClientId INT NOT NULL DEFAULT 0 ;

Mise à jour de la colonne ClientId :

UPDATE BON_LIVRAISON 
    SET ClientId = (SELECT ClientId FROM FACTURE WHERE BON_LIVRAISON.FactureId = FACTURE.FactureId) ;

UPDATE BON_DETAIL 
    SET ClientId = (SELECT ClientId FROM BON_LIVRAISON WHERE BON_DETAIL.BonId = BON_LIVRAISON.BonId) ;

UPDATE LIGNE_DEVIS 
    SET ClientId = (SELECT ClientId FROM DEVIS WHERE LIGNE_DEVIS.DevisId = DEVIS.DevisId) ; 

Suppression des clés étrangères dont la composition va changer. Rappel : l’ordre compte !

 
ALTER TABLE BON_DETAIL DROP FOREIGN KEY BON_DETAIL_BON_LIVRAISON_FK
                     , DROP FOREIGN KEY BON_DETAIL_LIGNE_DEVIS_FK ;
     
ALTER TABLE BON_LIVRAISON DROP FOREIGN KEY BON_LIVRAISON_FACTURE_FK ;

ALTER TABLE LIGNE_DEVIS DROP FOREIGN KEY LIGNE_DEVIS_DEVIS_FK ;

Une fois supprimées les clé étrangères, suppression ses clés primaires dont la composition va changer :

           
ALTER TABLE FACTURE DROP PRIMARY KEY ;
ALTER TABLE BON_LIVRAISON DROP PRIMARY KEY ;
ALTER TABLE BON_DETAIL DROP PRIMARY KEY ;
ALTER TABLE DEVIS DROP PRIMARY KEY ;
ALTER TABLE LIGNE_DEVIS DROP PRIMARY KEY ;

Définition des nouvelles clés primaires (bi-colonnes) :

ALTER TABLE FACTURE ADD CONSTRAINT FACTURE_PK PRIMARY KEY (ClientId, FactureId) ;
ALTER TABLE BON_LIVRAISON ADD CONSTRAINT BON_LIVRAISON_PK PRIMARY KEY (ClientId, BonId) ;
ALTER TABLE BON_DETAIL ADD CONSTRAINT BON_DETAIL_PK PRIMARY KEY (ClientId, LigneDevisId) ;
ALTER TABLE DEVIS ADD CONSTRAINT DEVIS_PK PRIMARY KEY (ClientId, DevisId) ;
ALTER TABLE LIGNE_DEVIS ADD CONSTRAINT LIGNE_DEVIS_PK PRIMARY KEY (ClientId, LigneDevisId) ;

Et définition des nouvelles clés étrangères (bi-colonnes) :

ALTER TABLE BON_LIVRAISON ADD CONSTRAINT BON_LIVRAISON_FACTURE_FK 
    FOREIGN KEY (ClientId, FactureId) REFERENCES FACTURE (ClientId, FactureId) ;
                      
ALTER TABLE LIGNE_DEVIS ADD CONSTRAINT LIGNE_DEVIS_DEVIS_FK 
    FOREIGN KEY (ClientId, DevisId) REFERENCES DEVIS (ClientId, DevisId) ;
                     
ALTER TABLE BON_DETAIL ADD CONSTRAINT BON_DETAIL_BON_LIVRAISON_FK FOREIGN KEY (ClientId, BonId)
    REFERENCES BON_LIVRAISON (ClientId, BonId) ;  

ALTER TABLE BON_DETAIL ADD CONSTRAINT BON_DETAIL_LIGNE_DEVIS_FK FOREIGN KEY (ClientId, LigneDevisId)
    REFERENCES LIGNE_DEVIS (ClientId, LigneDevisId) ;

Do you agree tovaritch ?

[champomy62]

I agree chief!

Lundi, je sens que quelques triggers vont sauter


Merci fsmrel de vos réponses si détaillées.