Discussion :

[MacFly58]

Alors que je m'exprimais sur une relation 1,1 --- 1,1 d'un MCD de Idriss, CinePhil a éveillé ma curiosité.


Citation de CinePhil :

Sur le plan de la modélisation, si on a ceci :
A -1,1----Associer----1,1- B

Ça veut dire qu'une des entités est un "multi-attribut" de l'autre. Un seul A déterminant un seul B et vice versa, les deux entités devraient être fusionnées.

Mais sur le plan sémantique ça peut aussi être quelque peu incohérent de fusionner les deux entités, même si les règles de gestion imposent ces couples de cardinalités.

"Un directeur dirige une seule agence et une agence n'a qu'un directeur."

Directeur -1,1----Diriger----1,1- Agence

Il n'est sémantiquement pas logique de fusionner l'agence et son directeur. Il sera plus logique, dans le MLD puis dans les tables, de mettre l'identifiant du directeur en clé étrangère dans l'agence.

Pour ma part, cela ne me gène pas du tout de fusionner une agence et son directeur. Le nom d'un directeur me semble être un attribut d'une agence dans le cas exposé.

Auriez-vous en tête un autre cas qui mettrait en évidence votre raisonnement svp ?
Par ailleurs le mot "sémantiquement" me semble obscure. Voulez-vous par là évoquer le fond du problème plutôt que sa forme ?

[ok.Idriss]

Re

Personnellement, par rapport au MCD en question, je ne trouve pas logique de fusionner une entité facture et intervention (pareil pour un directeur et une agence) : il s'agit de deux choses bien distinctes même si d'un point de vue fonctionnel cela marcherai tout aussi bien. Après je n'ai pas dit que la fusion était interdite mais qu'elle n'était pas obligatoire (en gros chacun fait comme il préfère ou comme on lui impose) ...

J'ai appris de mon côté que le fait d'avoir des cardinalités 1,1 (ou 0,1) de part et d'autre d'une association était possible, qu'il suffisait ensuite de mettre la clef étrangère dans une seule des deux tables par la suite et que généralement, on choisi de mettre cette clef étrangère du côté la table dont l'entité, qui lui correspond, a le plus d'association avec les autres (même si cela aussi n'est pas obligatoire, on peut tout aussi bien la mettre de l'autre côté, il s'agit encore là d'une question de logique) ...

Pour ma part, cela ne me gène pas du tout de fusionner une agence et son directeur. Le nom d'un directeur me semble être un attribut d'une agence dans le cas exposé.

Si tu n'as que le nom ok mais si tu doit avoir toutes les propriétés d'une agence (id, nom, adresse, tel, etc) et toutes celles du directeur (matricule, nom, prenom, adresse, tel, email, date de naissance, etc) c'est autre chose ...

Auriez-vous en tête un autre cas qui mettrait en évidence votre raisonnement svp ?
Par ailleurs le mot "sémantiquement" me semble obscure. Voulez-vous par là évoquer le fond du problème plutôt que sa forme ?

Le fond du problème c'est que même si ça peut paraître plus optimisé de faire une chose dans un projet quelconque il faut que cela reste cohérent pour une plus grande compréhension de tous. Par exemple, il n'est pas cohérent d'avoir une seule et même table pour un directeur et une agence. Si une base de donnée comporte une nombre important de tables (plusieurs centaines par exemple) comme il arrive souvent en entreprise, il devient difficile pour un des mainteneurs (on n'est pas toujours tout seul à bosser) de retrouver certaines données si elles sont mal organisée => On perd plus de temps qu'on en gagne.

Pour rester cohérent et s'y retrouver même le simple nom des tables reste important et suit parfois un formalisme préconisé par l'entreprise en question, si on commence à fusionner des tables qui correspondent à des choses bien distinctes ...

Cordialement,
Idriss

[CinePhil]

Pour ma part, cela ne me gène pas du tout de fusionner une agence et son directeur. Le nom d'un directeur me semble être un attribut d'une agence dans le cas exposé.

Comme l'a très bien exprimé ok.Idriss, s'il n'y a que le nom, on le met en attribut de l'agence. S'il y a les informations complètes du directeur, on se retrouve clairement dans un cas de "multi-attribut", comme je l'avais appelé dans mon message.

Ça veut dire qu'une des entités est un "multi-attribut" de l'autre.

de plus, cette notion de Directeur peut être une entité fille qui hérite d'une entité Personne :
Directeur -(1,1)----Etre----0,1- Personne
|---------------1,1----Diriger----1,1- Agence

Auriez-vous en tête un autre cas qui mettrait en évidence votre raisonnement svp ?

On pourrait vouloir enregistrer des prototypes de véhicules à moteur avec le détail des caractéristiques du moteur.
Vehicule -1,1----Avoir----1,1- Moteur

Dans un club équestre, chaque cavalier pourrait se voir attribué un seul cheval :
Cheval -1,1----Attribuer----1,1- Cavalier

En cherchant un peu, on pourrait trouver sans doute moult autres exemples.

Par ailleurs le mot "sémantiquement" me semble obscur. Voulez-vous par là évoquer le fond du problème plutôt que sa forme ?

Sémantiquement : relatif à la sémantique, c'est à dire au sens. Il est clair qu'un directeur et une agence sont sémantiquement deux entités différentes, tout comme un véhicule et son moteur ou un cheval et son cavalier.

C'est donc pour ça que dans mon message je commençais par aborder le côté théorique de la conception :
A -1,1----Asssocier----1,1- B ==> Fusion de A et de B.
Mais si A est sémantiquement très différent de B, il peu être préférable de bien séparer A et B malgré les cardinalités.

Être confronté à ces cardinalités peut aussi conduire à se poser des questions sur la justesse des règles de gestion.
Ne serait-il pas plus pertinent de voir le scénario suivant :
1) Le groupe X souhaite lance le projet de créer une agence à Bordeaux.
2) On crée l'agence dans la BDD.
3) On nomme son directeur pour l'ouverture de l'agence.
4) On enregistre M. Dupont en tant que directeur de l'agence.

Dès lors, le MCD est plutôt le suivant :
Agence -0,1----Avoir----1,1- Directeur

Et cette fois la clé étrangère se trouve dans la table des directeurs et pas dans celle des agences.

[MacFly58]

C'est limpide, y compris pour les relations 0,1-1,1

Merci

[hmimoud]

Bonjour,

Désolé de revenir à ce sujet qui a déjà été marque résolu, mais en cherchant sur le forum une solution à mon problème d'une relation 1,1 --- 1,1 d'un MCD, j'ai trouvé cette discussion qui m'a levée une autre ambiguïté.

Dans l'exemple du directeur et de l'agence, si on adopte la solution de mettre par exemple dans le MLD l'identifiant du directeur en clé étrangère dans l'agence, il y aura un problème puisque cela sera traduit comme si le directeur dirige plusieurs agences, et du coup au niveau pratique, lorsque qu'un utilisateur tentera d’insérer plusieurs agences pour un même directeur cela sera accepté faute d'absence de contrainte pour gérer cela, ce qui n’obéit pas aux règles de gestion désirées.

Je souhaite savoir si la suggestion suivante que j'ai jugé sine qua non pour résoudre ce problème, l'est vraiment :

En plus de mettre l'identifiant du directeur en clé étrangère dans l'agence, la clé étrangère doit être défini comme unique !

Merci

[Richard_35]

Bonjour Hmimoud,

En plus de mettre l'identifiant du directeur en clé étrangère dans l'agence, la clé étrangère doit être défini comme unique !

==> pour moi, c'est OK (en fait, créer un index unique sur cette clé étrangère). De mon point de vue, cela équivaut à une contrainte "merisienne".

Reste à savoir si ça passera au "rasoir" de Fsmrel...

[Kropernic]

Si un directeur dirige une seule agence et qu'une agence est dirigée par un directeur, alors dans le MLD, la colonne directeur est une clef alternative de la table agence et se doit donc d'avoir sa contrainte d'unicité (au moyen d'un index unique en sql server par exemple).

[fsmrel]

Bonsoir,


Une mise au point à propos de l'intégrité référentielle.


Partons des règles de gestion :

(R1) Une agence a exactement un directeur ;

(R2) Un directeur dirige exactement une agence.

MCD correspondant :





MLD dérivé par l’AGL (PowerAMC ici) :

si on adopte la solution de mettre par exemple dans le MLD l'identifiant du directeur en clé étrangère dans l'agence

La dérivation du MCD par un AGL provoque automatiquement la présence de l’attribut DiirecteurId dans l’en-tête de la table AGENCE et la mise en oeuvre d’une clé étrangère {DirecteurId} faisant référence à la table DIRECTEUR.

Comme une association 1,1----1,1 correspond à une bijection, il ne doit donc pas y avoir de jaloux, c’est pourquoi l’AGL ne manque pas de faire figurer un attribut AgenceId dans l’en-tête de la table DIRECTEUR et de mettre en oeuvre une clé étrangère {AgenceId}.

il y aura un problème puisque cela sera traduit comme si le directeur dirige plusieurs agences.

Si l’AGL oublie qu’il y a des cardinalités maximales 1, il est évident que par respect des règles de gestion, à nous de pallier en faisant de {AgenceId} une clé alternative pour la table DIRECTEUR (cf. le mickey <ak>) et en faisant de {DirecteurId} une clé alternative pou la table AGENCE :

En plus de mettre l'identifiant du directeur en clé étrangère dans l'agence, la clé étrangère doit être définie comme unique !

Bien évidemment, l’unicité doit être respectée ! Si donc l’AGL est laxiste, on doit ajouter dans le MLD les clés alternatives manquantes, comme on vient de le faire ci-dessus.

Maintenant, dans le cas des bijections, comme dans cet exemple, les clés étrangères sont aussi efficaces que des cautères sur des jambes de bois... Autrement dit, le filet est troué, ces clés étrangères n’empêchent pas des infractions comme celle-ci :

DIRECTEUR                              AGENCE
+-------------+----------+             +----------+-------------+
| DirecteurId | AgenceId |             | AgenceId | DirecteurId |
|-------------+----------|             |----------+-------------|
|         123 |      314 |             |      314 |         456 |
|         456 |      271 |             |      271 |         123 |
+-------------+----------+             +----------+-------------+ 

Pour empêcher ce genre d’infraction, on remplace les clés étrangères inefficaces par une contrainte, exemple en Tutorial D :

Code D :

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

1
2
CONSTRAINT DIRECTION_CHK01
    DIRECTEUR {DirecteurId, AgenceId} = AGENCE {DirecteurId, AgenceId} ;

Ce qui se lit : La projection de DIRECTEUR sur les attributs DirecteurId et AgenceId doit être égale à la projection de AGENCE sur ces mêmes attributs.

En vrai relationnel, ceci ne pose aucune difficulté. Exemple :

Définissons les variables relationnelles (tables en SQL) :

Code D :

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

1
2
3
4
5
6
7
8
9
10
VAR DIRECTEUR BASE RELATION 
{
        DirecteurId        INTEGER
      , DirecteurNom       CHAR
      , AgenceId           INTEGER
      , ...
}
KEY {DirecteurId}
KEY {AgenceId}
;

Code D :

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

1
2
3
4
5
6
7
8
9
10
VAR AGENCE BASE RELATION 
{
        AgenceId             INTEGER
      , AgenceNom            CHAR
      , DirecteurId          INTEGER
      , ...
}
KEY {AgenceId}
KEY {DirecteurId}
 ;

On définit ensuite la contrainte DIRECTION_CHK01 présentée ci-dessus. A noter que les clés étrangères n’ont pas été définies puisqu’impuissantes à garantir l’intégrité.


Toujours en vrai relationnel, quand il s’agit d’effectuer les ajouts, on procède par affectation multiple :

Code D :

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

1
2
3
4
5
6
7
8
9
10
11
12
INSERT DIRECTEUR RELATION {TUPLE {DirecteurId         123,
                                  DirecteurNom        'Raoul',
                                  AgenceId            314,
                                  ... 
                                 }
                        } ,
INSERT AGENCE RELATION {TUPLE {AgenceId           314,
                               AgenceNom          'Agence Volfoni',
                               DirecteurId        123),
                               ... 
                              }
                     } ;

Les deux inserts font partie de la même instruction, ils y sont simplement séparés par une virgule ; la fin de l’instruction est marquée par un point-virgule. Les contraintes d’intégrité ne sont vérifiées qu’à des frontières de points-virgules : en l’occurrence tout se passera donc bien.


Cas de SQL

Disons que la contrainte DIRECTION_CHK01 fera l’objet d’une assertion ou plutôt d’un trigger, car généralement les SGBD SQL ne proposent pas l’instruction CREATE ASSERTION (laquelle n'offre du reste pas toutes garanties voulues). Ceci dit, SQL ne permet pas l’affectation multiple, ce qui veut dire qu’en soumettant un 1er INSERT disons dans la table DIRECTEUR, il sera rejeté par le trigger au motif du viol de la contrainte : on est confronté au problème de l’œuf et de la poule...
On s’en sort en appliquant les opérations de mise à jour à une vue de jointure, d’où le plus souvent la nécessité d’utiliser aussi un trigger associé à cette vue (exception faite de MySQL ).

Exemple :

Tables de base :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TABLE DIRECTEUR (
   DirecteurId            INT                  NOT NULL,
   DirecteurNom           VARCHAR(64)          NOT NULL,
   AgenceId               INT                  NOT NULL,
CONSTRAINT DIRECTEUR_PK PRIMARY KEY (DirecteurId),
CONSTRAINT DIRECTEUR_AK UNIQUE (AgenceId)) ; 
 
CREATE TABLE AGENCE (
   AgenceId               INT                  NOT NULL,
   AgenceNom              VARCHAR(64)          NOT NULL,
   DirecteurId            INT                  NOT NULL,
   CONSTRAINT AGENCE_PK PRIMARY KEY (AgenceId),
   CONSTRAINT AGENCE_AK UNIQUE (DirecteurId)) ;

Vue de jointure :

Code SQL :

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

1
2
3
4
CREATE VIEW DIRECTION_AGENCE (DirecteurId, AgenceId, DirecteurNom, AgenceNom)
AS 
    SELECT x.DirecteurId, x.AgenceId, x.DirecteurNom, y.AgenceNom
    FROM   DIRECTEUR AS x JOIN AGENCE AS y ON x.DirecteurId = y.DirecteurId ;

Trigger pour insert (SQL Server) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
CREATE TRIGGER DIRECTION_AGENCE_INSERT_TR ON DIRECTION_AGENCE INSTEAD OF INSERT AS
 
    INSERT INTO DIRECTEUR (DirecteurId, AgenceId, DirecteurNom)
           SELECT DirecteurId, AgenceId, DirecteurNom
           FROM   INSERTED ;
 
    INSERT INTO AGENCE (DirecteurId, AgenceId, AgenceNom)
           SELECT DirecteurId, AgenceId, AgenceNom
           FROM   INSERTED ;

Un bout de jeu d’essai :

Code SQL :

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

1
2
3
4
5
INSERT INTO DIRECTION_AGENCE (DirecteurId, AgenceId, DirecteurNom, AgenceNom) VALUES (123, 314, 'Raoul', 'Agence Volfoni') ;
INSERT INTO DIRECTION_AGENCE (DirecteurId, AgenceId, DirecteurNom, AgenceNom) VALUES (456, 271, 'Fernand', 'Agence Naudin') ; 
 
SELECT '' AS 'DIRECTEUR', * FROM DIRECTEUR ;
SELECT '' AS 'AGENCE', * FROM AGENCE ;

@Richard_35 & Kropernic :

Désolé, mais les index sont du niveau physique. Au niveau logique, on utilise une contrainte (cf. ci-dessus) :

Code SQL :

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

1
2
3
4
CREATE TABLE AGENCE
...
    CONSTRAINT AGENCE_AK UNIQUE (DirecteurId)
...