Utilité des tables de liaisons ? [Résolu]

[justgreat]

Bonjour,

Je souhaite comprendre l'utilité des tables de jointures (jonctions/ASSOCIATIONS/LIAISON) dans les bases de données.
Quelqu'un pourra m'expliquer en détail l'interet de créer une telle table pour les relation n-n...avec si possible un exemple qui montre la différence entre l'utilisation d'une table de liaison entre deux tables et avoir deux tables avec un champs en commun sans table de liaison.

[CinePhil]

Règle de gestion :
"Une personne peut travailler sur plusieurs projets et un projet peut faire travailler plusieurs personnes."

MCD :
Personne -0,n----Travailler----0,n- Projet

Tables :
Personne (prs_id, prs_nom...)
Projet (prj_id, prj_nom...)
Travailler (trv_id_personne, trv_id_projet)

Si Paul travaille sur les projets 1 et 2 et que le projet 1 fais aussi travailler Jean et que le projet 2 fait aussi travailler Pierre, comment fais-tu pour implémenter ça sans la table associative Travailler ?

[justgreat]

CinePhil, merci beaucoup de vouloir aider, je ne suis pas expert, en fait j'aimerai bien comprendre la logique derrière qui nous a poussé à penser à utiliser ces tables associatives.
sinon, pour répondre à ta question, j'imaginais que ça se fait simplement en faisant quelque chose du genre :

Personne (prs_id, prs_nom,prj_id ...)
Projet (prj_id, prj_nom, prs_id...)



Peux tu me donner un exemple de select et son résultat qui montre la différence entre l'utilisation de table associative, et comment j'imaginais (sans table associative ) les choses...Peut etre en comparant les résultat je comprend mieux l'histoire des tables associatives.

Encore une fois, merci beaucoup

[CinePhil]

Envoyé par justgreat

j'imaginais que ça se fait simplement en faisant quelque chose du genre :

Personne (prs_id, prs_nom,prj_id ...)
Projet (prj_id, prj_nom, prs_id...)

OK, remplissons les tables à partir des exemples que j'ai donnés :

Paul travaille sur les projets 1 et 2 et que le projet 1 fais aussi travailler Jean et que le projet 2 fait aussi travailler Pierre

Sans table associative
Commençons sans les clés étrangères...
Personne (prs_id, prs_nom
1, Paul
2, Jean
3, Pierre

Projet (prj_id, prj_nom
1, Apprendre Merise
2, Modéliser BDD

Alimentons les clés étrangères...

Paul travaille sur les projets 1 et 2

Code :

1
2
3
UPDATE Projet
SET prs_id = 1
WHERE prj_id IN (1, 2)

Résultat :
Projet (prj_id, prj_nom, prs_id)
1, Apprendre Merise, 1
2, Modéliser BDD, 1

Jusque là, ça va !

Mais il faut aussi alimenter l'autre clé étrangère de la table des personnes !

Code :

1
2
3
UPDATE Personne
SET prj_id = -- 1 ou 2 ?
WHERE prs_id = 1

Aïe ! Ça coince !
J'enregistre le projet 1 ou le projet 2

Selon le bon principe des bases de données relationnelles et la première forme normale : 1 colonne d'1 ligne = 1 seule valeur

Si je continue, ça va poser les mêmes problèmes !

le projet 1 fais aussi travailler Jean

- On indique le projet chez Jean

Code :

1
2
3
UPDATE Personne
SET prj_id = 1
WHERE prs_id = 2

Jusque là tout va bien, mais il faut aussi indiquer dans le projet que Jean travaille dessus :

Code :

1
2
3
UPDATE projet
SET prs_id = 2
WHERE prj_id = 1

La requête passe mais j'ai écrasé la précédente valeur et, vu du projet, Paul ne travaille plus dessus !

Au mieux, sans la table associative et à condition de faire très attention, je peux mettre une personne dans la table projet et affecter le projet à une autre personne dans la table personne, soit au maximum deux personnes travaillant sur un projet.
Avec la table associative, c'est illimité.

Avec table associative...

Paul travaille sur les projets 1 et 2

Code :

1
2
INSERT INTO Travailler (trv_id_personne, trv_id_projet)
VALUES (1, 1), (1, 2)

le projet 1 fais aussi travailler Jean

Code :

1
2
INSERT INTO Travailler (trv_id_personne, trv_id_projet)
VALUES (2, 1)

le projet 2 fait aussi travailler Pierre

Code :

1
2
INSERT INTO Travailler (trv_id_personne, trv_id_projet)
 VALUES (3, 2)

Peux tu me donner un exemple de select et son résultat qui montre la différence entre l'utilisation de table associative, et comment j'imaginais (sans table associative ) les choses...Peut etre en comparant les résultat je comprend mieux l'histoire des tables associatives.

Quelles sont les personnes qui travaillent sur le projet 1 ?

Sans table associative

Code :

1
2
3
4
5
6
7
8
9
SELECT prs_id
FROM Projet
WHERE prj_id = 1
 
UNION
 
SELECT prs_id
FROM Personne
WHERE prj_id = 1

Chaque sous-requête retournera au plus 1 seule personne, l'union en retournera au maximum 2. S'il y a plus de deux personnes qui travailles sur un projet, on ne pourra pas l'enregistrer et donc pas l'obtenir par le SELECT.

Avec table associative

Code :

1
2
3
4
SELECT p.prs_id, p.prs_nom
FROM Personne p
INNER JOIN Travailler t ON t.trv_id_personne = p.prs_id
WHERE t.trv_id_projet = 1

j'aimerai bien comprendre la logique derrière qui nous a poussé à penser à utiliser ces tables associatives.

C'est la première forme normale expliquée plus haut qui impose l'atomicité des données dans les colonnes.

[justgreat]

Merci beaucoup CinePhil d'avoir pris le temps de m'expliquer tout ça, avec des exemples c'est toujours plus clair, mais si j'ai bien compris, j'aurais pu faire sans table associative quelque chose du genre répéter dans la table personne deux enregistrement pour dire que Jean travaille sur le projet 1 , et 2, et pareil dans la table projet dupliquer des enregistrements ... mais ça devient lourd je pense ..

En tout cas en principe j'ai compris, je te remercie beaucoup encore une fois

[CinePhil]

Envoyé par justgreat

Merci beaucoup CinePhil d'avoir pris le temps de m'expliquer tout ça, avec des exemples c'est toujours plus clair, mais si j'ai bien compris, j'aurais pu faire sans table associative quelque chose du genre répéter dans la table personne deux enregistrement pour dire que Jean travaille sur le projet 1 , et 2, et pareil dans la table projet dupliquer des enregistrements ... mais ça devient lourd je pense ..

Ça aurait dénormalisé le modèle de données !
La table des personnes ne doit contenir chaque personne qu'une seule fois et la table des projet ne doit contenir chaque projet qu'une seule fois. C'est le principe d'unicité des données.
Et effectivement, ça alourdit les requêtes puisque pour retrouver la liste des personnes ou des projets sans doublons il faut utiliser SELECT DISTINCT qui est évidemment moins performant qu'un simple SELECT sans DISTINCT.

[justgreat]

Merci encore une fois, oui je vois, mais je disais ça rien que pour vérifier si j'ai bien compris ton exemple ou pas , et apparemment que oui

D'ailleurs as-tu un lien vers un cours ou tutoriel où on explique les règles à respecter comme celle que tu viens de me citer ?

La table des personnes ne doit contenir chaque personne qu'une seule fois et la table des projet ne doit contenir chaque projet qu'une seule fois. C'est le principe d'unicité des données.

un lien qui explique qu'est ce qu'il faut éviter, quand est ce qu'il faut créer des tables de liaisons etc..une sorte de bonne pratique et initiation pour débutant ?

[CinePhil]

Envoyé par justgreat

D'ailleurs as-tu un liens vers un cours ou tutoriel où on expliques les règles à respecter comme celle que tu viens de me citer ?

un lien qui explique qu'est ce qu'il faut éviter, quand est ce qu'il faut créer des tables de liaisons etc..une sorte de bonne pratique et initiation pour débutant ?

Le livre téléchargeable de Michel Diviné sur la méthode Merise

Plus centré sur la modélisation des données, le tutoriel de SQLPro.

Très pointu mais plus difficile d'accès, le long article de fsmrel sur la normalisation des bases de données.

Peut-être plus abordable (je ne l'ai pas lu), le chapitre 3.2 du cours de Laurent Audibert sur la normalisation des bases de données relationnelles.

Bonne lecture et bon courage !

[justgreat]

Merci beaucoup CinePhil, je vais voir tout ça le week end.
bon week end et merci encore une fois