Relation n-aire : aberrant ?

**cedy-kassy** · 18/04/2012, 14h08

Bonjour,
Je voudrais savoir si dans une analyse, c'est stupide d'avoir une relation n-aire(avec n> 3, soit dit en passant) entre entités. Je pose la question parce que je suis sur le point de mettre en place une BD avec une table association à 7 pattes( voir code qui suit).

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/* -----------------------------------------------------------------------------
      TABLE : AFFAIRES
----------------------------------------------------------------------------- */
 
create table AFFAIRES
  (
     ID_SITE smallint  not null  ,
     ID_PROCDET smallint  not null  ,
     ID_RANGE smallint  not null  ,
     ID_PROD smallint  not null  ,
     ID_CLIENT int  not null  ,
     ID_DATE int null,
     ID_TRANCHE int null,
     UNIT_POWER_MW real  null  ,
     UNIT_POWER real  null  ,
     CONTRACT_AWARD smallint  null  ,
     COMMISSIONING int  null  ,
 
     constraint PK_AFFAIRES primary key (ID_SITE, ID_PROCDET, ID_RANGE, ID_PROD, ID_CLIENT, ID_DATE, ID_TRANCHE)
  ) 
go

.
Cela peut sembler bourrin, mais c'est la seule façon que j'ai trouvée de satisfaire les contraintes à moi imposées par le fonctionnement du "domaine "que j'étudie.

Alors, est-ce que je peux le faire sans que ce soit un crime prononcé à l'encontre de l'élégance de l'analyse SI

?

**SQLpro** · 18/04/2012, 18h13

Déjà conceptuellement les associations ternaires sont logiquement rares... Demandez à mon collègue Christian Soutou, co auteur de UML pour les bases de données ce qu'il en pense. On s'est engueulé la dessus, car il trouvait que cela ne devait pas exister car on peut systématiquement modifier !

Mais alors à 7 branche, dans ma déjà longue carrière de modélisation, j'ai jamais vu ça.

Donc je parierait pour une erreur dramatique de conception...

Décrivez nous les 7 tables satellites et ce qu'elle sont censé faire sur le plna sémantique, avec un petit exemple.

Au passage on modélise une BD avec u MCD pas dans le niveau physique !!!

A +

**elsuket** · 18/04/2012, 18h15

Bonjour,

Cela est difficile à dire sans savoir ce que vous avez besoin de réaliser (le contexte) et sans avoir le MCD ... 7 branches c'est beaucoup quand même

Mais le fait que vous puissiez mettre une contrainte de clé primaire sur l'ensemble des clés étrangères montre que ce que vous avez fait est à priori correct.
La relation est qualifiée par quelques attributs, ce qui justifie la présence de la table.

En revanche une clé primaire aussi large n'est probablement pas le meilleur choix en termes de performances.
On peut penser à mettre une clé subrogée de type entier avec propriété d'auto-incrémentation (à voir si elle doit être clustérisée ou non), et une contrainte d'unicité sur ce qui est l'actuelle clé primaire.

Quelle est la colonne la plus sélective ? est-ce que c'est la même colonne que celle par laquelle la plus grande partie des SELECT seront filtrés ?

@++

**elsuket** · 18/04/2012, 18h17

Ha bah y'a eu un peu de télescopage avec SQLPro

@++

**cedy-kassy** · 19/04/2012, 16h23

Salut tout le monde!!!
Merci SQLPro, votre réaction rend ma question légitime

(moi non plus, j'ai jamais vu ça de mon expérience de...lecteur

).
C'est vrai que j'aurais dû présenter le MCD, mais lors de l'édition, mon windesign a planté sans sauvegarder, mais j'avais déja effectué la génération de script SQL. et comme j'avais la flemme de tout reprendre à zéro....

En Pièce jointe un aperçu de MCD du domaine que j'étudie. En fait il s'agit de la gestion des affaires d'un... "Marchand d'affaires" , appelons le comme ça.

Comme elsuket l'a suggéré, j'ai modifié le MCD afin de créer une entité AFFAIRE, reliée aux autres par des relations 1-n (afin de permettre la migration des clés étrangères...).Ne tenez pour l'instant pas compte des traits en pointillés sur la table Affaires.

Brèves Explications:

Il s'agit en fait de pouvoir gérer des affaires.
-----------------------------------------------------------
-->Un Produit (Product line dans le modèle) contient des technologies(Range)
-->Une technologie peut être retrouvée dans plusieurs produits (cas rares, mais existant), d'où la relation n-n.
-->Les sites sont répartis en "Régions"
--> Sur un site on peut avoir plusieurs process, et on peut avoir le même process sur plusieurs sites.
-----------------------------------------------------------
-->Un client(personne morale) peut faire plusieurs affaires
-->Pour un client donné, on a un contact(personne physique) qui peut varier en fonction de l'affaire.
-->le champ "Contract Award" représente l'année de mise en fonction.

--> Une affaire c'est: Un client, un site, un process, un produit, une technologie, ainsi que les autres attributs de la table affaire.
--> Il existe des affaires pour lesquelles TOUT est identique, sauf les champs "contract Award"(date) et "commissioning"(mise à jour) .
--> De même, toutes les caractéristiques peuvent être pareilles sauf le nombre de tranches (champ "NB Tranches").
Dans ces cas, la contrainte d'unicité aurait-t-elle raison d'exister? ou alors on la mettrait sur TOUS les champs de la table?

---------------------------------------------------------
Explication liens en pointillés:
____________________________________________________________
Afin de pouvoir retrouver un contact pour une affaire donnée et son client, je projette de faire une relation ternaire entre affaire-Client-Contact, et supprimer par la même l'association binaire qui reliait Affaire et client jusqu'ici.
C'est la même logique qui guide les autres liens (Affaire-Site-process et Affaire-Range-Product-line).
---------------------------------------------------------
Est-ce acceptable comme proposition?

**fsmrel** · 20/04/2012, 17h36

Bonsoir,

Envoyé par cedy-kassy

Sur un site on peut avoir plusieurs process, et on peut avoir le même process sur plusieurs sites.

Au niveau MLD (Modèle logique de données), la représentation est celle-ci :

On peut inférer que si une affaire fait référence au process P1 et au site S1, la paire <S1, P1> doit faire partie des valeurs prises par la paire d’attributs {SiteId, ProcessId} de la table PROCESS_SITE qui représente en quelque sorte le catalogue des paires légales. A défaut, des viols de règle pourraient se produire.

Ce principe vaut pour les produits et les ranges :

Envoyé par cedy-kassy

Il existe des affaires pour lesquelles TOUT est identique, sauf les champs "contract Award"(date) et "commissioning"(mise à jour)

On devrait donc pouvoir mettre en œuvre une entité-type (table au niveau MLD), appelons-la AFFAIRE_TYPE qui soit une référence pour les affaires (table AFFAIRE) et qui fasse référence aux paires légales précédemment définies :

Les attributs de la table AFFAIRE ne concernent plus que ce qui est vraiment propre à chaque affaire et qui ne peut être factorisé par le biais de la table AFFAIRE_TYPE.

Concernant les contacts, vos règles sont ambiguës. Question : une affaire (table AFFAIRE) fait-elle mention d’un seul contact ? Peut-elle faire mention de plusieurs contacts ?

N.B. J'ai utilisé MySQL Workbench pour représenter le MLD.

**cedy-kassy** · 23/04/2012, 09h16

Bonjour,
Merci pour ces explications détaillées fmsrel,
En ce qui concerne les contacts, je dirais qu'en effet il peut y avoir plusieurs contacts( d'un même client) par affaire.
Par contre, je n'ai pas très bien compris l'ajout de la table AFFAIRE_TYPE dans le MLD. En fait, je comprend très bien la logique à ce niveau, ce que je comprend moins c'est comment représenter le lien entre une table et une association au niveau conceptuel sans que ça se transforme en ternaire.

.
En effet même si je crée une entité Affaire-type au MCD relié aux associations "Process_site" et "Range_prod" avec une patte à 1,1 (ce qui est déja assez bizarre

), lors du passage au MLD les associations "Process_site" et "Range_prod" disparaitraient....

**fsmrel** · 24/04/2012, 02h50

Bonsoir,

Envoyé par cedy-kassy

comment représenter le lien entre une table et une association au niveau conceptuel sans que ça se transforme en ternaire.

Le plus simple est de faire de PROCESS_SITE une entité-type faible (identifiée relativement à PROCESS et SITE), même principe pour RANGE_PROD :

Incidemment, cela fait 20 ans que des auteurs reconnus comme José Moréjon pratiquent l’association d’association, sous forme par exemple de contraintes d’inclusion (cf. son ouvrage Principes et conception d’une base de données relationnelle, aux Editions d’organisation). En ce qui concerne votre modèle, ces contraintes sont en l’occurrence représentables par AFFPS et AFFRP (mais qu’en est-il avec votre AGL ?) :

On peut encore utiliser l’agrégation (au sens E/R), mais en général les merisiens n’aiment pas trop.

Avec votre AGL (dont je ne dispose pas), vous pourriez sans doute en passer par des CIF, mais j’ai le sentiment que ce serait au prix d’une certaine lourdeur.

Envoyé par cedy-kassy

En ce qui concerne les contacts, je dirais qu'en effet il peut y avoir plusieurs contacts( d'un même client) par affaire.

D’accord. Une affaire concerne donc au moins un contact. Je suppose qu’un contact s’occupe d’au moins une affaire de son client. Est-ce exact ?

**cedy-kassy** · 24/04/2012, 09h22

bonjour,

D’accord. Une affaire concerne donc au moins un contact. Je suppose qu’un contact s’occupe d’au moins une affaire de son client. Est-ce exact ?

.
En effet, c'est tout à fait exact.

Incidemment, cela fait 20 ans que des auteurs reconnus comme José Moréjon pratiquent l’association d’association, sous forme par exemple de contraintes d’inclusion (cf. son ouvrage Principes et conception d’une base de données relationnelle, aux Editions d’organisation). En ce qui concerne votre modèle, ces contraintes sont en l’occurrence représentables par AFFPS et AFFRP (mais qu’en est-il avec votre AGL ?) :

.
J'utilise Windesign 11(bien qu'en version démo), mais il ne permet pas d les associations d'associations(sinon, j'aurais même pas posé la question précédente...

)

Finalement ce que j'ai fait hier a été de laisser une relation n-n entre product et range (idem pour process et site) au niveau conceptuel, et au niveau logique j'ai juste eu à "relier" manuellement les tables-associations Product_range et process_site à ma table AffaireType(déja créée, bien entendue).

Votre solution est bien plus élégante(pas étonnant

), et je m'en vais sur-le-champ modifier mon MCD. C'est fou à quel point des propriétés en apparence "simples" peuvent nous sauver la vie...

**fsmrel** · 24/04/2012, 14h41

Bonjour,

Envoyé par cedy-kassy

Afin de pouvoir retrouver un contact pour une affaire donnée et son client, je projette de faire une relation ternaire entre affaire-Client-Contact, et supprimer par la même l'association binaire qui reliait Affaire et client jusqu'ici.

Supprimer cette association binaire serait une erreur car elle exprime une règle de gestion essentielle, à savoir qu’une affaire appartient à un client et un seul : la supprimer voudrait dire qu’une affaire deviendrait multi-clients.

Encore une question : une personne physique ne peut vraiment être en relation qu’avec un seul client ? Dans ces conditions, si un certain Jean Martin joue le rôle de contact pour le client C1, s’il doit devenir aussi contact pour le client C2, il fera alors l’objet de deux instances (entités) distinctes dans la base de données, mais ayant mêmes caractéristiques (nom, adresse de courriel, N° de téléphone, etc. Qu’en est-il ?

Exemple :

Code :

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

1
2
3
4
5
6
CONTACT {ContactId, Nom,          Téléphone,   AdrCourriel, ...}
            ...     ...           ...          ...          ...
            071     Jean Martin   0123456789   jm@dvp.xy    ...
            ...     ...           ...          ...          ...
            245     Jean Martin   0123456789   jm@dvp.xy    ...
            ...     ...           ...          ...          ...

**cedy-kassy** · 24/04/2012, 15h51

Salut,

Encore une question : une personne physique ne peut vraiment être en relation qu’avec un seul client ? Dans ces conditions, si un certain Jean Martin joue le rôle de contact pour le client C1, s’il doit devenir aussi contact pour le client C2, il fera alors l’objet de deux instances (entités) distinctes dans la base de données, mais ayant mêmes caractéristiques (nom, adresse de courriel, N° de téléphone, etc. Qu’en est-il ?

Fondamentalement, le contact est un commercial de chez le client (Ex: Contact: M. DUPOND Alexandre employé chez le client ATOS), or le client peut avoir plusieurs affaires avec notre "Marchand d'affaires", donc le même contact peut s'occuper d'une autre affaire pour le compte du même client!!

J'ai une autre question:

On devrait donc pouvoir mettre en œuvre une entité-type (table au niveau MLD), appelons-la AFFAIRE_TYPE qui soit une référence pour les affaires (table AFFAIRE) et qui fasse référence aux paires légales précédemment définies :

Cela n'alourdit-il pas le procédé lors d'une insertion? puisqu'il faudrait
1.Insérer les données de la table Produit
2.Insérer celles de la table Range
3.Effectuer les correspondances dans la table PROD_RANGE
4.Insérer les données de la table Site
5.Insérer celles de la table Process
6.Et enfin(Et c'est ce qui me dérange un petit peu), copier les données des tables PROD_RANGE et SITE_PROCESS vers la table AFFAIRE_TYPE. ??

**fsmrel** · 25/04/2012, 03h08

Bonsoir,

Pour résumer :

Un contact est un employé d’un client et on pourrait aller jusqu’à dire que l’entité-type CONTACT est une propriété multivaluée de l’entité-type CLIENT (relation de composition). On peut dire encore que CONTACT est une entité-type faible, c'est-à-dire que si on supprime un client, ses contacts sont supprimés aussi sec.
Une affaire est la chose du client, et là encore l’entité-type AFFAIRE est une propriété multivaluée de l’entité-type CLIENT.
Un contact s’occupe d’au moins une affaire et une affaire est du ressort d’au moins un contact.

Un premier MCD pourrait ressembler à ceci :

Toutefois, on détecte une faiblesse : rien n’empêche d’associer les contacts d’un client aux affaires d’autres clients...

Pour pallier, il faudra prévoir une assertion au niveau SQL :

Code SQL :

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

1
2
3
4
5
6
 
CREATE ASSERTION Assert031 CHECK
    (NOT EXISTS (SELECT  x.AffaireId
                 FROM    AFCT AS x JOIN AFFAIRE AS y ON x.AffaireId = y.AffaireId
                                   JOIN CONTACT AS z ON x.ContactId = z.ContactId
                 WHERE  y.ClientId <> z.ClientId)) ;

Vous me direz que SQL Server ne permet pas de programmer des assertions : il faudra en passer par un trigger pour les inserts et un autre pour les updates (bon courage...

)

Je vous propose toutefois une alternative, que j’évoque à l’occasion, quand pour aller du point A au point B il y a deux chemins possibles, avec le risque de l’erreur d’aiguillage nécessitant la mise en œuvre de l’assertion précédente (ou du trigger palliatif). Le principe consiste à en passer par l’identification relative des entités-types faibles (CONTACT et AFFAIRE donc) :

Lors de la dérivation du MCD en MLD, les AGL produisent une table AFCT telle que celle-ci (avec Power AMC en l’espèce) :

La table AFCT comporte deux colonnes faisant référence à CLIENT : ClientId et ClientId2. En effet, un AGL n’est pas censé savoir que ces deux colonnes devraient n’en faire qu’une, c'est-à-dire que le client d’une affaire est aussi celui du contact. Si l’AGL ne propose pas de case à cocher en ce sens, on agit manuellement, pour obtenir finalement le MLD suivant (mise à niveau de la clé étrangère <fk2> puis élimination de la colonne ClientId2) :

Pour fixer les idées, la génération SQL donne lieu aux tables :

Table CLIENT :

Code SQL :

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

1
2
3
4
CREATE TABLE CLIENT (
   ClientId             INT                  NOT NULL,
   ClientNom            VARCHAR(64)          NOT NULL,
   CONSTRAINT CLIENT_PK PRIMARY KEY  (ClientId)) ;

Table CONTACT :

Code SQL :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE CONTACT (
   ClientId             INT                  NOT NULL,
   ContactId            INT                  NOT NULL,
   ContactNom           VARCHAR(64)          NOT NULL,
   ContactTel           VARCHAR(24)          NOT NULL,
   ContactCourriel      VARCHAR(64)          NOT NULL,
   CONSTRAINT CONTACT_PK PRIMARY KEY  (ClientId, ContactId),
   CONSTRAINT CONTACT_CLIENT_FK FOREIGN KEY (ClientId)
      REFERENCES Client (ClientId)) ;

Table AFFAIRE (sans faire référence ici à la table AFFAIRE_TYPE) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE AFFAIRE (
   ClientId             INT                  NOT NULL,
   AffaireId            INT                  NOT NULL,
   Commissioning        INT                  NOT NULL,
   Award                INT                  NOT NULL,
   NbTranches           INT                  NOT NULL,
   CONSTRAINT AFFAIRE_PK PRIMARY KEY  (ClientId, AffaireId),
   CONSTRAINT AFFAIRE_CLIENT_FK FOREIGN KEY (ClientId)
      REFERENCES Client (ClientId)) ;

Table AFCT :

Code SQL :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE AFCT (
   ClientId             INT              NOT NULL,
   ContactId            INT              NOT NULL,
   AffaireId            INT              NOT NULL,
   CONSTRAINT AFCT_PK PRIMARY KEY  (ClientId, ContactId, AffaireId),
   CONSTRAINT AFCT_CONTACT_FK FOREIGN KEY (ClientId, ContactId)
      REFERENCES Contact (ClientId, ContactId),
   CONSTRAINT AFCT_AFFAIRE_FK FOREIGN KEY (ClientId, AffaireId)
      REFERENCES Affaire (ClientId, AffaireId)) ;

Un début de jeu d’essai :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
INSERT INTO CLIENT VALUES (1, 'Dubicobit') ;
INSERT INTO CLIENT VALUES (2, 'MacroSoft') ;
 
INSERT INTO CONTACT VALUES (1, 1, 'Jean', '0123456789', 'Jean@dvp.xy') ;
INSERT INTO CONTACT VALUES (1, 2, 'René', '0234567890', 'Rene@dvp.xy') ;
INSERT INTO CONTACT VALUES (2, 3, 'Line', '0345678901', 'Line@abc.xy') ;
INSERT INTO CONTACT VALUES (1, 4, 'Léon', '0456789012', 'Leon@cde.xy') ;
 
INSERT INTO AFFAIRE VALUES (1, 1, '1000', '500', 5) ;
INSERT INTO AFFAIRE VALUES (1, 2, '1500', '200', 3) ;
INSERT INTO AFFAIRE VALUES (1, 3, '1000', '800', 4) ;
INSERT INTO AFFAIRE VALUES (2, 4, '2000', '200', 2) ;
 
INSERT INTO AFCT VALUES (1, 1, 1) ;
INSERT INTO AFCT VALUES (1, 2, 1) ;

=> Pas moyen d'associer les contacts d'un client aux affaires d'autres clients : pas besoin de trigger.

**fsmrel** · 25/04/2012, 03h29

En complément

Envoyé par cedy-kassy

Cela n'alourdit-il pas le procédé lors d'une insertion? puisqu'il faudrait
1.Insérer les données de la table Produit
2.Insérer celles de la table Range
3.Effectuer les correspondances dans la table PROD_RANGE
4.Insérer les données de la table Site
5.Insérer celles de la table Process
6.Et enfin(Et c'est ce qui me dérange un petit peu), copier les données des tables PROD_RANGE et SITE_PROCESS vers la table AFFAIRE_TYPE. ??

Je ne connais pas votre application, mais je pars du principe que les tables PRODUIT, RANGE et PROD_RANGE, SITE, PROCESS et SITE_PROCESS constituent un catalogue (du genre catalogue PRODUITS dans le monde de la banque, de l’assurance, des caisses de retraite, etc.) et les données qu’elles contiennent préexistent donc largement aux affaires. S’il n’en est pas ainsi, c’est que vous créez les données de référence en même temps que les affaires. Quoi qu’il en soit, dans cette dernière hypothèse puisqu’une affaire référence un seul produit, un seul range, un seul site, et un seul process, cela représente au plus l’insert d’une ligne par table de référence (PRODUIT, RANGE, SITE, PROCESS) et l’insert d’une ligne pour les tables d’association PROD_RANGE et SITE_PROCESS. Coût global de l’opération : au pire quelques dizaines de millisecondes.

Par ailleurs, l’insert d’une affaire-type dans la table AFFAIRE_TYPE n’est pas quelque chose de bien compliqué.

Supposons que l’on veuille créer l’affaire-type 27, faisant référence au range nommé 'range 14', au produit nommé 'prod 114', au process nommé 'process 952' et au site nommé 'Paris'. Si on connaît les valeurs des identifiants correspondants, disons respectivement 874, 56, 541 et 10, l’ajout de l’affaire-type peut être effectué ainsi :

Code SQL :

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

1
2
INSERT INTO AFFAIRE_TYPE (AffaireTypeId, RangeId, ProdId, ProcessId, SiteId) 
       VALUES (27, 874, 56, 541, 10) ;

Ou encore :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
DECLARE @AffaireTypeId AS INT, @RangeId AS INT, @ProdId AS INT, @ProcessId AS INT, @SiteId AS INT 
 
SET @AffaireTypeId = 27 ;
SET @RangeId = 874 ;
SET @ProdId = 56 ;
SET @ProcessId = 541 ;
SET @SiteId = 10 ;
 
INSERT INTO AFFAIRE_TYPE (AffaireTypeId, RangeId, ProdId, ProcessId, SiteId) 
       VALUES (@AffaireTypeId, @RangeId, @ProdId, @ProcessId, @SiteId) ;

Et si l’on n’a pas accès aux valeurs des identifiants, mais seulement à celles des noms :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
DECLARE @AffaireTypeId AS INT, @RangeId AS INT, @ProdId AS INT, @ProcessId AS INT, @SiteId AS INT 
 
SET @AffaireTypeId = 27 ;
SET @RangeId = (SELECT RangeId FROM RANGE_ WHERE RangeNom = 'range 14') ;
SET @ProdId = (SELECT ProdId FROM PROD WHERE ProdNom = 'prod 114') ;
SET @ProcessId = (SELECT ProcessId FROM PROCESS WHERE ProcessNom = 'process 952') ;
SET @SiteId = (SELECT SiteId FROM SITE WHERE SiteNom = 'Paris') ;
 
INSERT INTO AFFAIRE_TYPE (AffaireTypeId, RangeId, ProdId, ProcessId, SiteId) 
       VALUES (@AffaireTypeId, @RangeId, @ProdId, @ProcessId, @SiteId) ;

Tout en ayant défini les index pertinents pour les colonnes RangeNom, ProdNom, etc.

**cedy-kassy** · 25/04/2012, 15h44

Merci infiniment fmsrel, pour vos explications si simples, détaillées et facilement compréhensibles

Merci surtout pour m'avoir éviter l'écriture des triggers et autres, parce que j'aurais certainement galéré...

Avant de considérer ce sujet comme résolu, permettez-moi de vous poser quelques questions supplémentaires:

Envoyé par fsmrel

1--> En ce qui concerne la suppression de la clé ClientId en trop, j'ai pas trop compris en quoi consistait la mise à niveau? moi j'ai eu juste à supprimer manuellement sous Windesign, par contre les contraintes FK_AFCT_CONTACT et FK_AFCT_AFFAIRE (noms adaptés au schéma ci-dessus, bien évidemment

)contiennent encore ClientId. J'ai "visuellement" la même chose que vous proposez, mais même lors de la génération du script sQL, il est fait mention de " ClientId" dans les FK_AFCT_....

2-->Maintenant j'essaye d'importer des données à partir d'un fichier excel pour les insérer dans ma base, et j'ai un petit souci (Explications encore adaptées au schéma ci-dessus):
*-->L'attribut ClientId est autoincrémenté, donc j'insère "ClientNom", je récupère la clé générée
*-->J'insère la valeur de la clé précédente dans "CONTACT.ClientId" et "AFFAIRE.ClientId" (qui dans ce cas ne sont pas autoincrémentés)
*-->Les attributs ContactId et AffaireId sont autoincrémentés, et je devrais à priori remplir les autres attributs, récupérer les clés à nouveau et les insérer dans la table AFCT pour finir.

Pourtant j'ai un message d'erreur "L'instruction INSERT est en conflit avec la contrainte FOREIGN KEY "FK_AFCT_CONTACT". Le conflit s'est produit dans la base de données "Bd_Truc", table "dbo.CONTACT"..
Quelle peut en être l'origine?
Je ne m'étais encore jamais posé la question, mais est-il seulement possible que dans le cas d'une clé primaire composée, l'un des attributs seulement soit autoincrémenté et pas l'autre?

**Waldar** · 25/04/2012, 16h06

fsmrel mérite beaucoup plus de

sur l'ensemble de ses interventions !

**elsuket** · 25/04/2012, 17h59

Fmsrel habite vraiment dans relation-land.
Merci de ta participation

@++

**fsmrel** · 26/04/2012, 03h51

Bonsoir,

@Waldar & elsuket,

Merci à vous valeureux forumeurs !

Je pense que cedy aura besoin de vous au sujet de l'auto-incrémentation...

@cedy,

Comme je l’ai précisé hier, on ne peut pas impunément supprimer la colonne devenue inutile (ClientId2 dans mon MLD) sans prendre quelques précautions préalables : il faut commencer par modifier la clé étrangère impliquée, à savoir FK_AFCT_AFFAIRE dans la représentation ci-dessous, en y remplaçant ClientId2 par ClientId :

Dans le cas de Power AMC, je dois intervenir sur « Colonne de la table enfant » (avec Win Design on doit disposer d’une fonctionnalité semblable) :

Je sélectionne la colonne ClientId :

Au résultat, la clé étrangère FK_AFCT_AFFAIRE est cette fois-ci composée de la paire {ClientId, AffaireId} :

La colonne ClientId2 ne participe plus à quelque clé étrangère que ce soit :

Alors seulement maintenant on peut supprimer cette colonne :

J'espère que la manip ne vous posera pas de problème avec Win Design.

**cedy-kassy** · 26/04/2012, 10h38

Bonjour tout le monde!!
fmsrel, j'ai réussi à effectuer la modification sous windesign, et au cas où ça intéresserait quelqu'un je joins l'image de la manip(Toute petite manip somme toute).Désolé, mais je sais pas encore insérer d"'image...

Au fait il suffit de:
--> cliquer sur le lien en question
-->Puis cliquer sur l'onglet "jointure"
--> Et enfin, beh, c'est exactement comme l'a expliqué fmsrel.

bon, je vais aller réessayer,
A +!

**fsmrel** · 26/04/2012, 16h29

Au fait, cedy, si quelqu’un vous posait maintenant la question :

Je voudrais savoir si dans une analyse, c'est stupide d'avoir une relation n-aire (avec n> 3, soit dit en passant) entre entités. Je pose la question parce que je suis sur le point de mettre en place une BD avec une table association à 7 pattes.

Que lui répondriez-vous ?

**cedy-kassy** · 26/04/2012, 21h25

Exxxxxxxcellente question fmsrel

Je crois que je répondrais sans hésiter qu'il s'agirait d'une erreur dramatique de conception (comme SqlPro

), puis je l'aiguillerais sur la piste des identifiants relatifs et des entités-faibles, en lui faisant comprendre subtilement certaines erreurs après des exemples qu'il/elle m'aurait fourni.
Vous l'aurez compris, je suivrais la même méthode que vous

, avec joie.

Relation n-aire : aberrant ?

MS SQL Server

Discussions similaires

Partager

Partager