Discussion :

[new_wave]

bonjour,

D'après les règles de passage du mcd vers le mld, la règle n°3, qui est la suivante me pose problème

REGLE n°3: UNE ASSOCIATION DE DIMENSION 2 AVEC CARDINALITES PLUSIEURS A PLUSIEURS
SE REECRIT EN :
- créant une relation particulière qui contient comme attributs les identifiants des 2 entités associées
- ces attributs constituent à eux 2 la clé primaire de la relation
- ils sont individuellement clés étrangères
- ajoutant la ou les éventuelles propriétés de l'association à cette relation.

Je comprends donc qu'il est nécessaire , dans ce cas, de créer une table de jointure qui contient comme attributs les identifiants des deux entités associées.
Mais au niveau physique, est il nécessaire de créer quand même cette table qui, s'il n'existe pas de propriétés à l'association qui relie les deux entites, ne sert à rien.

Dans le cas où l'association qui relie les deux entités est porteuse d'une propriété, est-il nécéssaire de créer une nouvelle table dans la base de données( je pense fortement que oui, mais je voudrais une confirmation).

Sinon, pourquoi considère -t-on que les deux attributs qui constituent la clé primaire de cette nouvelle table sont des clés étrangères?

Merci beaucoup de votre aide.
cordialement.
Nathalie

[Mike888]

http://merise.developpez.com/faq/?pa...LD_PasserAuMLD

[new_wave]

Bonjour et merci,

Je suis désolée, j'avais déjà lu ce cours mais ce que je cherche à savoir n'est pas clairement exprimé dans ce cours.
Cordialement.
Nathalie

[JPhi33]

Mais au niveau physique, est il nécessaire de créer quand même cette table qui, s'il n'existe pas de propriétés à l'association qui relie les deux entites, ne sert à rien.

Dans une bibliothèque, on gère des adhérents et des livres. Admettons que tu souhaites savoir quels livres sont empruntés par les adhérents (en supposant qu'un adhérent n'emprunte qu'une seule fois un même livre). Tu modélises :

[ Adhérent ]--0,n----( Emprunter )----0,n--[ Livre ]

L'association Emprunter est de dimension 2 avec cardinalités plusieurs à plusieurs et n'a pas de propriété. On est donc bien dans les conditions du cas qui te pose un problème.
Que se passe-t-il au niveau physique ? Tu as 2 tables, Adhérent et Livre.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
Adherent
---------
Aline
Bertrand
Charlotte

Livre
--------------
MERISE tome 1
Guerre et Paix
Madame Bovary

Puisque, selon ton raisonnement, la table issue de l'association ne sert à rien, comment fais-tu pour savoir que :
Aline a emprunté MERISE tome 1
Aline a emprunté Madame Bovary
Charlotte a emprunté Guerre et Paix
Charlotte a emprunté MERISE tome 1
?

Seule la table Emprunter peut te donner cette information :

Code :

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

1
2
3
4
5
6
7
8
9
Emprunter
--------------------------
Adhérent    Livre
---------   --------------
Aline       MERISE tome 1
Aline       Madame Bovary
Charlotte   Guerre et Paix
Charlotte   MERISE tome 1

La clé de la table Emprunter est Adhérent + Livre.

Dans le cas où l'association qui relie les deux entités est porteuse d'une propriété, est-il nécéssaire de créer une nouvelle table dans la base de données( je pense fortement que oui, mais je voudrais une confirmation).

Pas une nouvelle table mais la même avec une colonne non clé en plus, par exemple la Date d'emprunt :

Code :

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

1
2
3
4
5
6
7
8
9
Emprunter
---------------------------------------
Adhérent    Livre            Date
---------   --------------   ----------
Aline       MERISE tome 1    08/11/2007
Aline       Madame Bovary    08/11/2007
Charlotte   Guerre et Paix   08/11/2007
Charlotte   MERISE tome 1    01/10/2007

Sinon, pourquoi considère -t-on que les deux attributs qui constituent la clé primaire de cette nouvelle table sont des clés étrangères?

Dans la table Emprunter, la colonne Adhérent fait référence à la colonne Adhérent de la table Adhérent et la colonne Livre fait référence à la colonne Livre de la table Livre. Puisqu'elles "font référence à", ce sont des clés étrangères. La conséquence est que, dans la table Emprunter, tu ne peux pas insérer, par exemple, les lignes :

Code :

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

1
2
3
4
5
6
7
8
Emprunter
--------------------------
Adhérent    Livre
---------   --------------
Déborah     MERISE tome 1   --> Déborah n'existe pas dans la table Adhérent 
Aline       MERISE tome 2   --> MERISE tome 2 n'existe pas dans la table Livre
Etienne     Dune            --> ni l'adhérent ni le livre n'existent

En espérant que ce petit exemple t'aura permis de comprendre ces notions de base (donc fondamentales !)

[new_wave]

Bonjour,

Je te remercie beaucoup de ton aide.
Je comprends donc que les tables de jointures doivent être physiquement créées.
Bien.
Le problème est que dans mon cas, je en vois pas comment je pourrais créer des requêtes d'insertion dans ces tables.
L'application que je gère n'a pas besoin d'insertion dans une table de jointure, tout d'abord
-parce que les tables de jointure n'ont pas d'attribut(s) qui ne sont pas des identifiants
-parce que l'application ne prévoit pas d'insertion dans ces tables sinon dans chacune des tables concernée par la jointure.

Il y a peut être de ma part une grosse erreur commise donc, j'aimerais le savoir.
Merci à vous de votre aide.
Cordialement.
Nathalie

[Mike888]

Le problème est que dans mon cas, je en vois pas comment je pourrais créer des requêtes d'insertion dans ces tables.
L'application que je gère n'a pas besoin d'insertion dans une table de jointure, tout d'abord
-parce que les tables de jointure n'ont pas d'attribut(s) qui ne sont pas des identifiants
-parce que l'application ne prévoit pas d'insertion dans ces tables sinon dans chacune des tables concernée par la jointure.

A mon avis, t'as toujours pas compris le principe...

Cherche encore sur Google d'autres exemples de relation n,n. Cherche aussi à comprendre le fonctionnement des jointures (et principalement "internes" -> INNER JOIN).

[fsmrel]

Bonjour Nathalie,

La mayonnaise n’a manifestement pas encore pris. JPhi33 a fourni un exemple illustrant parfaitement le sujet traité.

Pour le moment, vous en êtes à un stade où la bibliothèque a des adhérents qui n’ont jamais emprunté le moindre livre et a des livres qu’aucun adhérent n’a lu. Autant fermer la boutique...

Sinon, à chaque fois qu’un emprunt est effectué, le fait doit être consigné dans la table Emprunter (ou Emprunt, c’est comme vous voulez) :

L’adhérent Aline a emprunté le livre "Merise Tome1", etc.

Vous dites que "l'application ne prévoit pas d'insertion dans ces tables sinon dans chacune des tables concernée par la jointure" :

Si l’emprunt ne soit pas être consigné dans la table Emprunter, précisez-nous dans quelle table vous souhaitez que cela se fasse : Adhérent ? Livre ? (Ceci est possible, mais à éviter pour l’instant...)

En outre, l’application doit-elle se préoccuper de tables ? Ne serait-ce pas plutôt d’entités-types et d’associations ? L’application traite en principe des choses au niveau conceptuel.

[Luc Orient]

... Le problème est que dans mon cas, je en vois pas comment je pourrais créer des requêtes d'insertion dans ces tables.
L'application que je gère n'a pas besoin d'insertion dans une table de jointure, tout d'abord
-parce que les tables de jointure n'ont pas d'attribut(s) qui ne sont pas des identifiants

Faux ... la notion de date d'emprunt, qui a déjà été donnée, est un bon contre exemple ...

-parce que l'application ne prévoit pas d'insertion dans ces tables sinon dans chacune des tables concernée par la jointure.

Etonnant ... l'application fera ce que son(sa) concepteur(trice) aura décidé qu'elle doit faire ...