Bonsoir jolla,
En préambule.
Supposons que nous modélisions les factures et les livraisons des produits facturés. Au niveau du MCD :
[FACTURE]----1,1----(R)----1,1----[LIVRAISON]
On a établi une bijection entre les deux entités-types, donc un cycle comme on va le montrer, alors que ça ne saute pas aux yeux. Du fait de la présence des deux cardinalités 1,1, la tradition merisienne veut qu’on fusionne FACTURE et LIVRAISON, mais je me gratte la tête : quel motif moins succinct peut bien nous pousser à faire de la salade sémantique ? 
Du point de vue de la théorie relationnelle, il est en effet on ne peut plus légal et légitime ne pas réaliser la fusion. On écrit sans problème :
Relvar (variable relationnelle) FACTURE :
1
2
3
4
5
6
7
8
9
10
11
12
| VAR FACTURE BASE RELATION
{
FactureId FactureId
, FactureDate DATE
, FactureHorsTaxe Montant
, FactureTVA Montant
, LivraisonId LivraisonId
, ...
}
KEY {FactureId}
KEY {LivraisonId}
FOREIGN KEY {LivraisonId} REFERENCES LIVRAISON ; |
Relvar LIVRAISON :
1
2
3
4
5
6
7
8
9
10
11
12
| VAR LIVRAISON BASE RELATION
{
LivraisonId LivraisonId
, LivraisonDate DATE
, LivraisonAdresse CHAR
, LivraisonContact CHAR
, FactureId FactureId
, ...
}
KEY {LivraisonId}
KEY {FactureId}
FOREIGN KEY {FactureId} REFERENCES FACTURE ; |
Les deux clés étrangères (foreign keys) mettent formellement en évidence un cycle, mais il n’y a pas de problème au moment de créer une facture et la livraison correspondante, on procède par affectation multiple :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| INSERT FACTURE RELATION {TUPLE {FactureId FactureId(123),
FactureDate '2012_09_26',
FactureHorsTaxe 1000,
FactureTVA 50,
LivraisonId LivraisonId(314),
...
}
} ,
INSERT LIVRAISON RELATION {TUPLE {FactureId FactureId(123),
LivraisonDate '2012_09_28',
LivraisonAdresse '12 rue de la dalle en pente',
LivraisonContact 'Zorbec Legras',
LivraisonId LivraisonId(314),
...
}
} ; |
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.
En revanche, les SGBD SQL ne permettent pas aujourd’hui de procéder par affectation multiple, aussi les deux clés étrangères créent une situation de blocage : la solution expéditive consiste alors à fusionner FACTURE et LIVRAISON. Sous forme de table :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| CREATE TABLE FACTURE_LIVRAISON
(
FactureId INTEGER NOT NULL
, LivraisonId INTEGER NOT NULL
, FactureDate DATE NOT NULL
, FactureHorsTaxe INTEGER NOT NULL
, FactureTVA INTEGER NOT NULL
, LivraisonDate DATE NOT NULL
, LivraisonAdresse VARCHAR(80) NOT NULL
, LivraisonContact VARCHAR(80) NOT NULL
, ...
, PRIMARY KEY (FactureId)
, UNIQUE (LivraisonId)
) ; |
On appelle ça pudiquement (au moyen d’un anglicisme) : optimiser, or ça n’est qu’une conséquence d’une lacune du langage SQL. Ceci a des effets sur le MCD (fusion d'entités-types), mais du jour où les SGBD SQL permettront l’affectation multiple, leurs utilisateurs n’auront plus à répercuter cette faiblesse du langage et les concepteurs pourront revoir leur position...
Envoyé par
jolla
Sauf que je pense que dans certains cas, il peut être plus pratique d'avoir une association directe (et donc un cycle)
Pour en revenir à votre exemple, je vous engage à ne pas établir d’association directe entre GROUPE et MORCEAU, à moins bien sûr que les groupes jouent des morceaux non programmés dans les concerts :
[GROUPE]----1,N----(JOUER)----0,N----[MORCEAU]
En effet, l’association JOUER est à l’origine d’effets secondaires contre lesquels vous devrez vous blinder, à savoir créer une contrainte de chemin (conterminous path), dont je donne ici une représentation plus ou moins formelle (et sujette à discussion au niveau du métamodèle) :
.png)
Cette contrainte synthétise la règle suivante :
Si le concert C donné par le groupe G comporte le morceau M, alors ce morceau doit faire partie de ceux qui sont joués par le groupe G.
Cette représentation graphique ne comporte pas de cycle, mais bien deux chemins impliquant la paire {GROUPE, MORCEAU}, donnant l’illusion de cycle. Par contraste, la bijection établie entre FACTURE et LIVRAISON donne lieu à un cycle qui ne saute pas aux yeux, mais qui est authentique et mis en évidence par la présence des clés étrangères que comportent FACTURE et LIVRAISON au niveau logique.
La contrainte de chemin fera évidemment l'objet d'une assertion ou de triggers au niveau SQL.
De mon temps...
Je me souviens que du temps où l’on ne connaissait pas encore la théorie relationnelle (inventée quand même en 1969), et qu’on commençait à se servir de Merise, c'est-à-dire au début des années quatre-vingts, en modélisant on était pollué par l’utilisation des SGBD navigationnels (IDS/2 essentiellement en France), conformes à la norme CODASYL, et pour celle-ci il était techniquement impossible que FACTURE et LIVRAISON soient représentées (en l’occurrence à l’aide d’un diagramme de Bachman) comme ci-dessous :
Codasyl.png)
Il ne nous restait plus qu’a fusionner les deux entités-types.
Je pense que les problèmes techniques de jadis, du niveau logique, on encombré la tête des merisiens de problèmes existentiels au niveau conceptuel : pour ma part, après avoir clairement établi la distinction entre modèle entité-association (sémantique) et modèle relationnel (logico-mathématique), j’ai fait mon aggiornamento, ce qui ne m’empêche pas de surveiller les problèmes potentiels dus aux conterminous paths, tout en attendant que SQL soit mis à niveau (on peut rêver 
)...
Cycles dans un MCD
Répondre avec citation
DF_Morceau_determine_Groupe.png)
Cycle_Authentique(MCD).png)
Cycle_Graphique(MCD).png)
Cycle_Authentique(MLD).png)
Cycle_Graphique(MLD).png)
Partager