Modéliser une contrainte d'unicité sur des attributs d'entités différentes

Bonjour à tous,

Quelle serait la meilleure manière de modéliser, sur un MCD, une contrainte d'unicité sur deux attributs provenant de deux entités différentes ?
Voici un exemple illustrant le MPD qu'il faudrait obtenir à partir de ce MCD :

Pièce jointe 144290

On peut remarquer les deux clés alternatives sit-id et box-ref dans la table [Box] représentant la contrainte d'unicité sur ce couple de colonnes (c'est ce qui est souhaité ici). La colonne sit-id étant une clé étrangère provenant de la table [Site].

Comment alors représenter, ici sous PowerAMC, cette contrainte d'unicité sur le couple sit-id et box-ref ?

Pièce jointe 144294

Merci d'avance pour vos éclaircissements.

Bonjour Kwadz,

Ma compréhension de la chose :

• 1 site peut posséder 0 ou plusieurs box ;
• 1 box appartient, forcément, à 1 et 1 seul site ;
• 1 même site ne peut pas avoir plusieurs box de même référence.

==> et tu souhaites modéliser la 3ème règle de gestion.

Si cette compréhension est bonne, je pense que cette 3ème règle de gestion ne se modélise pas car elle est interne à une même entité. La contrainte d'unicité du couple sit-id/box-ref peut être résolue en créant, pour la table Box, un index unique sur ce couple.

Effectivement c'est bien cette 3ème règle de gestion que je souhaiterais modéliser en MCD.

Citation:

---

Envoyé par Richard_35

Je pense que cette 3ème règle de gestion ne se modélise pas car elle est interne à une même entité. La contrainte d'unicité du couple sit-id/box-ref peut être résolue en créant, pour la table Box, un index unique sur ce couple.

---

==> OK ?

Citation:

---

Envoyé par Richard_35

==> OK ?

---

Pas tout à fait.

Citation:

---

Envoyé par Richard_35

Je pense que cette 3ème règle de gestion ne se modélise pas car elle est interne à une même entité.

---

Si tu précises "je pense" c'est qu'il s'agit d'une hypothèse. J'aurais besoin de faits concrets ou d'un peu plus de certitude ;)

Concernant le fait que la règle de gestion soit interne à une même entité je ne suis pas vraiment d'accord, puisqu'elle est liée aux deux entités. A moins que tu voulais dire table ?

Pour le reste, la question n'est pas de savoir comment créer cette contrainte sur le MPD (ceci étant déjà réalisé) mais bien de la créer sur le MCD, si cela est possible.

Merci.

Bonsoir Kwadz,


Si vous êtes d’accord avec l’approche d’Yves Tabourier des choses, l’attribut SiteId (entité-type SITE) n’est là que pour respecter la règle selon laquelle l’identifiant d’une entité-type doit être invariant, donc sans signification : du point de vue des opérations, cet attribut sert fondamentalement pour les jointures, et ne concerne en rien l’utilisateur (c'est-à-dire qu’on peut lui cacher) : celui-ci n’accède aux données de l’entité-type SITE (ou plutôt de la table si l’on se situe niveau SQL) qu’au moyen de l’attribut SiteCode (identifiant alternatif de votre entité-type SITE).

Mutatis mutandis, à son tour, l’attribut BoxId n’est manifestement là que pour faire respecter la règle d’invariance des identifiants. Aussi devrait-on pouvoir modéliser ainsi :

http://www.fsmwarden.com/developpez_..._idrel_MCD.png

C’est l’effet Dagobert...

Voyez par exemple ici pour la mise en œuvre de l’identification relative avec PowerAMC.

MLD produit par l'AGL :

http://www.fsmwarden.com/developpez_..._idrel_MLD.png


Je précise que du point de vue de la théorie relationnelle, au niveau tabulaire, il n’y a pas de distinction entre clé primaire et clé alternative, il n’y a que des clés candidates.

Quant aux clés étrangères qui pourraient référencer la table BOX, il n’y a pas d'impact si dans les clauses REFERENCES (en SQL) vous laissez PowerAMC nommer les attributs de la clé (primaire ou alternée) référencée.

Bonjour Fsmrel,

Je ne vois pas la modélisation de la contrainte suivante :
1 même site ne peut pas avoir plusieurs box de même référence.

Sachant que, si j'ai bien compris, Boxref n'est pas unique dans la table Box.

Ave Richard,


La table BOX a deux clés candidates :

K1 = {SiteId, BoxRef}

K2 = {BoxId}

Selon K1, un site peut avoir plusieurs références, mais pas deux fois la même. Si l'on cherche à assosier aux box b1 et b2 la référence r1, on produit les doublons <s1, r1>, ce qui n'est pas possible vu la clé K1.


Sinon, Guingamp ou Rennes ? :whistle:

Bonjour François,

Eh bien, Guingamp, donc...

Citation:

---

Envoyé par Fsmrel

Selon K1, un site peut avoir plusieurs références, mais pas deux fois la même.

---

==> cela répond à ta question, Kwadz :

Citation:

---

Envoyé par Richard_35

La contrainte d'unicité du couple sit-id/box-ref peut être résolue en créant, pour la table Box, un index unique sur ce couple.

---

Bonkour à vous deux,

Citation:

---

Envoyé par Richard_35

Citation:

---

Envoyé par Richard_35

Bonjour Kwadz,
La contrainte d'unicité du couple sit-id/box-ref peut être résolue en créant, pour la table Box, un index unique sur ce couple.

---

==> cela répond à ta question, Kwad

---

Non ! On ne se situe pas au niveau de la tuyauterie, mais au dessus. On doit donc déclarer une clé candidate, à savoir (SiteId, BoxRef) dans le cas de la table BOX.

TABLE SITE

Code:

---

1 2 3 4 5 6 7 8

CREATE TABLE SITE ( SiteId INT NOT NULL, SiteCode CHAR(8) NOT NULL, SiteLibelle VARCHAR(64) NOT NULL, CONSTRAINT SITE_PK PRIMARY KEY (SiteId), CONSTRAINT SITE_AK UNIQUE (SiteCode) ) ;

---

TABLE BOX

Code:

---

1 2 3 4 5 6 7 8 9

CREATE TABLE BOX ( SiteId INT NOT NULL, BoxRef CHAR(8) NOT NULL, BoxId INT NOT NULL, CONSTRAINT BOX_PK PRIMARY KEY (SiteId, BoxRef), CONSTRAINT BOX_AK UNIQUE (BoxId), CONSTRAINT BOX_SITE_FK FOREIGN KEY (SiteId) REFERENCES SITE (SiteId) ) ;

---

Que le SGBD implémente un index de type UNIQUE si ça lui chante, ça reste sous le capot. On peut aussi le faire pour définir les caractéristiques physiques fines des index, mais ceci est un autre sujet, qui intéresse seulement les DBA.

Hum... bien vu !

Mais, quelque part, cette astuce me dérange...

Ceci :

Code:

---

1 2 3 4 5 6 7 8 9

CREATE TABLE BOX ( SiteId INT NOT NULL, BoxRef CHAR(8) NOT NULL, BoxId INT NOT NULL, CONSTRAINT BOX_PK PRIMARY KEY (BoxId), CONSTRAINT BOX_AK UNIQUE (SiteId, BoxRef), CONSTRAINT BOX_SITE_FK FOREIGN KEY (SiteId) REFERENCES SITE (SiteId) ) ;

---

==> paraît mieux, conceptuellement, non ?

Ceci dit, cela revient pratiquement au même.

D’un point de vue conceptuel, on peut préférer que {BoxId} soit identifiant de l’entité-type BOX. Du point de vue de la théorie relationnelle, peu importe, puisque le concept de clé primaire n’en fait pas partie : il y a des clés candidate et seulement des clés candidates. Du point de vue SQL, puisque les contraintes d’unicité seront respectées, on choisit comme on veut.

Un point dont j’ai oublié de parler : Il faut aussi tenir compte des possibilités de l’AGL.

Avec PowerAMC, au niveau MCD, l’identification relative de BOX par rapport à SITE n’est possible qu’en faisant participer la clé primaire {BoxId} de la table BOX, ce qui n’est évidemment pas le but recherché. En revanche, avec DB-MAIN, pas de problème :


http://www.fsmwarden.com/developpez_...D(Db-main).png

L’identifiant « id:BoxId » fera l’objet de la clé primaire de la table BOX, tandis que l’identifiant « id’:R.SITE, BoxRef » fera l’objet d’une clé alternative.

Bonjour Kwadz,

... si le sujet t'intéresse toujours...

Citation:

---

Envoyé par fsmrel

Un point dont j’ai oublié de parler : Il faut aussi tenir compte des possibilités de l’AGL.

Avec PowerAMC, au niveau MCD, l’identification relative de BOX par rapport à SITE n’est possible qu’en faisant participer la clé primaire {BoxId} de la table BOX, ce qui n’est évidemment pas le but recherché. En revanche, avec DB-MAIN, pas de problème :


http://www.fsmwarden.com/developpez_...D(Db-main).png

L’identifiant « id:BoxId » fera l’objet de la clé primaire de la table BOX, tandis que l’identifiant « id’:R.SITE, BoxRef » fera l’objet d’une clé alternative.

---

Bonjour,
Discussion trés intéressante: je cherche à faire la même chose avec PowerDesigner 12, sans succés pour l'instant.
Cela veut-il dire que c'est définitivement mort ?

Quel contournement puis-je employer pour arriver à mes fins :

• definir BoxId comme identifiant primaire dans le MCD,
• décocher la case 'Dependent' dans la boite de propriétés de la relation dans le MCD
• et ajouter un élément ('je ne sais pas comment cela s'appelle en francais') dans l'onglet Keys de la table Box dans le MLD?

Je trouve cela assez lourd et à chaque itération sur mon MCD, le merge du MLD dans PowerDesigner me reproposera les même suppressions des éléments cutomisés dans le MLD.

Merci de vos commentaires.
Mins

Bonjour Mins,


De fait, on peut conserver {Boxid} comme identifiant primaire de BOX, et décocher la case « Dependent » pour l’association entre SITE et BOX, en attendant d’agir au niveau MLD.

Dans le cas de PowerAMC, dans le MLD, l’attribut SiteId fait désormais partie de l’en-tête de la table BOX. A partir de l’onglet « Identifiants », on peut donc définir un identifiant alternatif (IDENTIFIANT_2 ci-dessous) :

http://www.fsmwarden.com/developpez_...el_AK_2_AK.png


Cet identifiant alternatif est à composer des attributs SiteId et BoxRef :

http://www.fsmwarden.com/developpez_..._Attributs.png


L’opération n’est pas bien lourde. Maintenant, dans la mesure où, suite à un changement dans le MCD, on doit passer à nouveau par l’étape de dérivation du MCD en MLD, on demandera à l’AGL (PowerAMC dans mon cas) de conserver les modifications qu’on a déjà effectuées, en conséquence de quoi on ne perdra rien (ou alors je n’ai pas compris le sens de votre phrase : « A à chaque itération sur mon MCD, le merge du MLD dans PowerDesigner me reproposera les même suppressions des éléments customisés dans le MLD », ou bien encore PowerDesigner ne fonctionne pas comme PowerAMC) :

http://www.fsmwarden.com/developpez_...K_4_Fusion.png

Pfiou !!! Quelle réactivité, je suis impressionné.

Merci de la réponse.

Mins

Merci Mins,


Je me suis basé sur PowerAMC, mais est-ce que ça marche de la même façon avec PowerDesigner ?

Citation:

---

Envoyé par fsmrel

Merci Mins,


Je me suis basé sur PowerAMC, mais est-ce que ça marche de la même façon avec PowerDesigner ?

---

Oui, oui. A ce qui me semble PowerAMC = AMC PowerDesigner.
Mis à a part l'option Merise, je ne pense pas qu'il y ait de grande difference entre les deux.

Citation:

---

Envoyé par Minskaya

Oui, oui. A ce qui me semble PowerAMC = AMC PowerDesigner.
Mis à a part l'option Merise, je ne pense pas qu'il y ait de grande difference entre les deux.

---

Ah, on me glisse dans l'oreillette que Merise ne fait même plus partie des différences depuis la v7, seule la langue change !

Pour une fois que l'on a une version spécifique d'un produit pour notre langue, cocorico !