Discussion :

[Snipah]

Bonjour à tous,

J'ai rencontré un dilemme de modélisation sur une partie de mon projet que j'aimerais bien vous soumettre. Je m'excuse pour le titre évasif, je n'ai pas su mieux résumer... la problématique s'apparente à ça:
- Un livre peut avoir 1 ou n auteurs.
- Un auteur peut avoir écrit 1 ou n livres.

Code :

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

1
2
3
auteur (id_auteur, nom_auteur)
livre (id_livre, nom_livre)
auteur_livre (id_auteur, id_livre)

Nous nous intéressons maintenant aux annexes:
- Une annexe a 1 et 1 seul auteur.
- Un auteur peut avoir écrit 0 ou n annexes.
- Une annexe peut concerner 0 ou 1 livre.

Code :

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

1
2
annexe (id_annexe, id_auteur)
annexe_livre (id_annexe, id_livre)

Jusque là, ça me semble relativement simple, même si ça fait un moment que je n'ai pas fait de modélisation !
Et voici la règle supplémentaire qui me fait me questionner:
- Si l'annexe concerne un livre, son auteur doit figurer parmi les auteurs du livre.

Niveau base de données, je pensais m'en assurer avec un trigger lors de l'insert/update sur annexe_livre, pour vérifier que le couple auteur de l'annexe & livre concerné figure bien dans la table d'association auteur_livre.
Mais je ne vois pas comment faire figurer cela dans mon modèle, ni même si elle doit y figurer. J'avais presque envisagé de référencer directement l'association auteur_livre (annexe_auteur_livre (id_annexe, id_auteur, id_livre)), mais reste qu'il faut s'assurer que l'auteur du couple auteur_livre référencé est bien l'auteur de l'annexe. Et ça me semble pas très correct de référencer une association, sans certitude ceci dit...

Voilà, si vous avez des conseils sur la meilleure méthode à adopter, que ce soit en terme de représentation sur le modèle que sur l'implémentation niveau BDD, ce serait sympathique!
Dites-moi si j'ai omis les infos importantes, merci et bonne journée

[fsmrel]

Bonjour snipah,

Le mieux est d’en passer par la mise en oeuvre d’une entité-type associative (AL ci-dessous) connectée aux entités-types A (Auteur) et L (Livre) : AL est à la fois entité-type et association. A cet effet on utilise l’identification relative 1,1(R). On connecte alors les entités-types AL et X (Annexe) en se servant à nouveau de l’identification relative.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
|A|--0,N--(r1)--1,1(R)--|AL|--1,1(R)--(r2)--1,N--|L|
                         |
                         |
                        0,N
                         |
                        (r3)
                         |
                       1,1(R)
                         |
                         |
                        |X|

Pour cela utilisez Looping, lequel vous produira en sus et gracieusement le code SQL à votre demande :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
CREATE TABLE Auteur
(
   AuteurId INT,
   AuteurNom VARCHAR(50) NOT NULL,
   PRIMARY KEY(AuteurId)
);

CREATE TABLE Livre
(
   LivreId INT,
   LivreTitre VARCHAR(50) NOT NULL,
   PRIMARY KEY(LivreId)
);

CREATE TABLE Aut_Livre
(
   LivreId INT,
   AuteurId INT,
   PRIMARY KEY(LivreId, AuteurId),
   FOREIGN KEY(LivreId) REFERENCES Livre(LivreId),
   FOREIGN KEY(AuteurId) REFERENCES Auteur(AuteurId)
);

CREATE TABLE Annexe
(
   LivreId INT,
   AuteurId INT,
   AnnexeId INT,
   AnnexeTitre VARCHAR(50) NOT NULL,
   PRIMARY KEY(LivreId, AuteurId, AnnexeId),
   FOREIGN KEY(LivreId, AuteurId) REFERENCES Aut_Livre(LivreId, AuteurId)
);

[Snipah]

Bonjour Fsmrel,

Il se trouve qu'une annexe est nécessairement écrite par un et un seul auteur, mais peut ne concerner aucun livre (j'admets que c'est un peu contre-intuitif!).
Dans ce cas, elle référencera seulement un auteur, et la clé étrangère (LivreId, AuteurId) ne serait pas vérifiée, si j'ai bien compris votre proposition?
Devrait-on avoir deux associations, annexe_auteur (AnnexeId, AuteurId) et annexe_auteur_livre (AnnexeId, AuteurId, LivreId)? En reprenant votre schéma:

Code :

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

1
2
3
4
5
6
7
8
9
|A|--0,N--(r1)--1,1(R)--|AL|--1,1(R)--(r2)--1,N--|L|
 |                       |
0,N                     0,N
 |                       |
(r4)                    (r3)
 |                       |
0,1                     0,1
 |                       |
 ----------|X|------------

Il faudrait pour cela s'assurer qu'une annexe ne figure que dans une de ces deux relations, et le modèle physique qui en découle ne me semble pas très pratique...
Je vais me replonger sérieusement dans les concepts de modélisation, et regarder cet outil que vous avez cité!

Je vous remercie pour votre réponse et vous souhaite une bonne soirée

[escartefigue]

Bonjour,

Une autre façon de considérer la chose est de voir les annexes liées à un livre et les autres annexes comme deux individus différents et donc deux types d'entités au niveau conceptuel.
Les attributs des deux types d'annexes sont ils les mêmes ?
Au niveau SQL une vue faisant l'union des unes et des autres permettra de les consolider.

[fsmrel]

Voyons voir avec la spécialisation des annexes...

[Snipah]

Bonjour Escartefigue, Fsmrel,

Oui, les annexes ont toujours les mêmes attributs.
Donc, en reprenant cela sur Looping:



Ce qui nous donne le MLD suivant:

Code :

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

1
2
3
4
5
6
7
8
Annexe = (Annexe_ID VARCHAR(50), Annexe_Titre VARCHAR(50));
Auteur = (Auteur_ID INT, Auteur_Nom VARCHAR(50), Auteur_Prenom VARCHAR(50));
Livre = (Livre_ID INT, Livre_Titre VARCHAR(50), Livre_Date_Publication DATE);

Auteur_Livre = (#Auteur_ID, #Livre_ID);

Annexe_Auteur = (#Annexe_ID, #Auteur_ID);
Annexe_Livre = (#Annexe_ID, #(#Auteur_ID, #Livre_ID));

Niveau base de données, je vois bien l'utilisation de triggers sur insert sur Annexe_Auteur et Annexe_Livre pour s'assurer qu'une annexe n'est pas des deux types à la fois.
Par contre, comment s'assurer qu'une annexe est nécessairement d'un des deux types? Ce n'est pas forcément un soucis majeur et on s'éloigne du conceptuel, mais je ne vois pas de solution simple pour ça.

Merci pour votre aide et bonne journée!

[escartefigue]

Avec ce modèle, l'insertion d'une annexe doit concerner simultanément le sur-type et le sous-type.
L'ordre INSERT ne sera commité qu'après insertion dans les deux tables concernées : soit ANNEXE et ANNEXE_AUTEUR, soit ANNEXE et ANNEXE_LIVRE

Ce faisant, inutile de s'encombrer d'un trigger ou d'autres artifices.

Eventuellement, créez une procédure stockée pour chaque type d'insertion

[mach1974]

Je rappelle que pour un MERISE, une relation N,M est une nouvelle entité

[fsmrel]

Je rappelle que pour un MERISE, une relation N,M est une nouvelle entité

mach1974, revoyez votre copie. Une relation est une relation ! Relisez Nanci, Tardieu, Tabourier !
Et n'hésitez pas à découvrir le remarquable Looping, gracieusement proposé par le professeur Patrick Bergougnoux (merci Paprick !)

Peut-être vous situez-vous déjà au stade SQL ?

[Snipah]

Ok tout est clair pour moi maintenant, je passe le sujet en résolu.
Et effectivement looping m'a l'air très bon, et super simple d'utilisation.
Merci encore pour votre aide et bonne soirée!

[escartefigue]

Et effectivement looping m'a l'air très bon, et super simple d'utilisation.

L'essayer c'est l'adopter, merci encore à Paprick

[fsmrel]

L'essayer c'est l'adopter, merci encore à Paprick

Je dirais même plus, très grand merci, Paprick