Règles de passage du MCD au MLD pour les associations binaires
Bonjour,
Plusieurs sujets parlent du passage du MCD au MLD et débouchent sur des règles qui entrent en contradiction avec une grande partie de la littérature sur Merise, y compris sur le site Developpez.com :
Petit guide d'analyse des données à l'aide de la méthode MERISE
http://sqlpro.developpez.com/cours/m...passage#L5.1.2
FAQ Merise
http://merise.developpez.com/faq/?pa...LD_PasserAuMLD
Je vais donc tenter, sous votre contrôle, de synthétiser les différentes idées issues de plusieurs sujets, et de redéfinir les principales règles permettant de créer des tables à partir d'un MCD (pour les associations binaires).
Pour une association binaire, 10 cas sont possibles :
0,1 - 0,1
0,1 - 1,1
0,1 - 0,n
0,1 - 1,n
1,1 - 0,n
Pour ces 5 premiers cas, la création d'une table associative permet d'éviter les NULL, le MLD correspondant comportera donc 3 tables pour chacun des cas.
1,1 - 1,1
Dans ce cas soit nous obtenons 2 tables, soit les deux entités sont fusionnées pour obtenir 1 table.
1,n - 1,1
Ici nous obtenons 2 tables (et l'identifiant de l'entité "père" devient une clé étrangère dans la table "fille")
0,n - 0,n
0,n - 1,n
1,n - 1,n
Pour ces trois derniers cas, nous obtenons 3 tables.
En conclusion, on peut dire :
- Si au moins une cardinalité minimum vaut zéro, on crée une table associative pour éviter les NULL.
- Si les deux cardinalités maximales sont à n, on crée une table associative.
- pour une relation 1,1 - 1,1, il est possible de fusionner les tables.
- pour une relation 1,n - 1,1, on crée deux tables et l'on ajoute une clé étrangère dans la table fille.
Je souhaite limiter cette discussion sur ces règles élémentaires pour éviter que l'on se disperse (plus tard, nous pourrons par exemple compléter ce sujet en parlant des clés, des relations unaires ou n-aires, de l'identification relative, etc...).
Dans un premier temps j'aimerai voir si nous parvenons à obtenir un consensus sur ces règles.
L'objectif du sujet sera d'obtenir un consensus sur un algorithme simple et optimisé qui permettra de passer d'un MCD validé à un MLD.
Problème d'interprétation
Bonjour
Citation:
J’ai tendance à croire que la finalité est qu’une commande doit être réglée (même si cela n’arrive qu’ultérieurement) et qu’au niveau du MCD on devrait dans ce cas écrire :
Commande---1,1----payer-----1,1----Règlement
J’interprète peut-être mal mais ça me trouble ce côté "ultérieur" qui du coup rendrait le règlement comme " facultatif" mais seulement temporairement…
Le modèle doit prendre en compte la réalité de la situation et non sa finalité.
L'association Commande---0,1----payer-----1,1----Règlement ne signifie pas que le règlement est facultatif mais qu'à un instant T (considéré comme un état stable du système), une commande peut exister sans règlement. Ce qui est généralement le cas au moment de la transaction de création de la commande.
Par ailleurs, l'association entre la commande et le règlement peut être totalement différente selon le contexte :
- Lorsque le client décide de ne pas payer, il y a des commandes sans règlement.
- Lorsque le fournisseur fait un cadeau à son client, il y a des commandes sans règlement.
- Lorsque la commande nécessite un échéancier de paiement, il y a plusieurs règlements pour une seule commande
- Lorsqu'un client possède une grosse ardoise chez son fournisseur, il verse un seul règlement pour un ensemble de commandes.
Pour revenir au sujet principal du post, dans le cas d'une relation d'héritage, le choix sur le nombre de tables peut varier selon le besoin.
Même si conceptuellement il peut être intéressant de distinguer l'employé de la personne par l'association Employe --- (1,1) --- Etre --- 0,1 --- Personne
La construction au niveau logique pourra être différente car on peut ne vouloir qu'une seule table.
C'est le même type de problème pour une relation 1,1 - 1,1. Soit on veut une table, soit on veut 2 tables. L'algorithme pour passer du MCD au MLD ne peut pas faire l'économie de cette question.