Discussion :

[cedy-kassy]

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]

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]

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]

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

@++

[cedy-kassy]

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]

Bonsoir,

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 :

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]

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]

Bonsoir,

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.

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]

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...