Version imprimable
bonjour,
je veux savoir pourquoi est ce que les clès primaires migrent des entités de cardinalités fortes vers les entités de cardinalités faibles ?
en fait comment est ce qu'on peut expliquer cette règle du passage du mcd vers le mld ?
merci beaucoup d'avance pour toute réponse :)
Qu'entendez-vous par "cardinalités fortes" ou "faibles" ?
Sur mon blog, je donne tous les cas de cardinalités entre deux entités types et leurs conséquences pour l'implémentation des tables dans la BDD, donc les clés étrangères dans le MLD.
Bonsoir,
Considérez le bordereau de saisie des commandes ci-dessous :
http://www.fsmwarden.com/developpez_...eau_saisie.png
Fin des années soixante-dix, avec Merise (1re génération) on modélisait les lignes de commande au moyen d’une association (Commander dans l’exemple) :
http://www.fsmwarden.com/developpez_...se)OldTime.jpg
Ou en appelant un chat, un chat :
http://www.fsmwarden.com/developpez_...dTime_Lcde.jpg
Sémantiquement parlant, la ligne de commande peut être néanmoins considérée non pas comme une association entre la commande et le produit, mais, à l’image de ce qu’on perçoit dans le bordereau de saisie, plutôt comme une propriété multivaluée de la commande : LigneCommande est une entité-type faible (weak entity-type) au sens de Chen, Codd et tutti. Avec Merise 2e génération, on a eu la possibilité d’utiliser l’identification relative pour implémenter cela. Avec PowerAMC :
http://www.fsmwarden.com/developpez_...rise)IdRel.png
Avec WinDesign (noter la dépendance fonctionnelle merisienne LigneCommande -> Commande) :
http://www.fsmwarden.com/developpez_...e)IdRel_WD.png
Les AGL transforment ainsi le MCD en MLD :
http://www.fsmwarden.com/developpez_...)IdRel_MLD.png
La clé de la table est la paire {CommandeId, NoLigne}. L’attribut CommandeId de la table LigneCommande est par construction hérité de l’attribut CommandeId de la table Commande. Par convention (mais ça n’est pas un impératif), pour une valeur C de l’attribut CommandeId de la table LigneCommande, si la commande C comporte Nc lignes de commande, l’attribut NoLigne est numéroté de 1 à N, ligne de commande par ligne de commande. Même principe pour chaque commande.
Mais attention, pour une commande et un produit donnés il n’y a qu’une quantité et un montant (ce qui est garanti quand la ligne de commande fait l’objet d’une association, comme dans les exemples ci-dessus faisant référence à Merise 1re génération). Il faut donc définir une contrainte sous forme de clé alternative {CommandeId, ProduitId} pour la table LigneCommande :
http://www.fsmwarden.com/developpez_...Rel_MLD_AK.png
Quoi qu’il en soit, Pour mettre en œuvre la numérotation des lignes de commande (attribut NoLigne), voyez le billet Trigger pour incrémentation relative proposé par CinePhil.
Merci à tous pour les réponse mais ma question n'est pas "comment passer du mcd au mld ?" je metrise la méthode mais
ma question est pourquoi si on a d'une part (1,n) et de l'autre (1,1) la clès de la première sera inscrite dans la table de la seconde ?
merci d'avance pour toute réponse
Ben tu as la réponse dans mon billet de blog !
Tu as l'association suivante :Citation:
pourquoi si on a d'une part (1,n) et de l'autre (1,1) la clès de la première sera inscrite dans la table de la seconde ?
A -1,n----associer----1,1- B
Elle est issue de la règle de gestion suivante :
Un A est associé à un à plusieurs B et un B est associé à un seul A.
Le MLD détermine la composition des tables de la future BDD. Et dans un SGBDR, les tables sont associées par des clés étrangères référençant les clés primaires d'autres tables.
Dans le cas de cette association, si je mets dans la table A une clé étrangère référençant B, je ne pourrai au maximum référencer qu'un seul B pour un A, ce qui est contraire à la règle de gestion et aux cardinalités 1,n du MCD. Par contre, en mettant dans B une clé étrangère référençant A, j'obéis bien à la règle de gestion et aux cardinalités 1,1 du MCD et je n'interdit nullement qu'un A soit référencé par plusieurs B.
Pour respecter totalement la règle de gestion et le MCD, il faudra tout de même prévoir, dans le SGBD, un processus, trigger ou procédure, pour que, lors de la création d'un A, au moins un B lui soit immédiatement associé. Et comme le B en question ne peut être associé qu'à un seul A, il faut donc créer le B en même temps que le A.