Discussion :

[NLS le pingouin]

Bonjour,
Je suis en train de concevoir un système de classement de documents.
J'utilise mysql comme SGBD.

J'ai une table Paper pour les infos sur les différents documents.
Cette table est reliée à une table Author via une association Published_by_author pour lister les auteurs.
Elle est aussi reliée à une table Org via une association Published_by_org pour lister les organisations responsables de la publications.
Et pour finir, elle aussi aussi reliée à une table Zine via une association From_issue pour indiquer que le document est tiré d'un magasine.

Pour un affichage des différents documents, j'ai fait cette requète :

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
 
 
SELECT
-- Paper stuff
	P1.title,
-- Author stuff
	GROUP_CONCAT(Author.name),
-- Org stuff
	GROUP_CONCAT(Org.name),
-- zine stuff
	From_issue.zine
FROM
	(Paper AS P1 JOIN Published_by_author ON P1.id = Published_by_author.paper) JOIN Author ON Author.id = Published_by_author.author,
	(Paper AS P2 JOIN Published_by_org ON P2.id = Published_by_org.paper) JOIN Org ON Org.name=Published_by_org.org,
	(Paper AS P3 JOIN From_issue ON P3.id=From_issue.paper)
GROUP BY P1.id, P2.id, P3.id
;

Le problème c'est que si un article n'est pas en relation avec une des tables Author, Org ou Zine, il apparait plusieurs fois avec chacun des résultat possible pour les relations manquante.

Pourriez-vous m'aider ?

Merci.

[asmduty]

Bonjour,

au lieu d'utiliser des "Inner Join", il faut utiliser des jointures externes (LEFT ou RIGHT join"

De plus tu met 3 jointures sur Paper ??????

Logiquement tu devrais plutôt avoir un truc comme ça :

Code :

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

1
2
3
4
5
FROM Paper AS P LEFT JOIN Published_by_author ON P.id = Published_by_author.paper
LEFT JOIN Author ON Author.id = Published_by_author.author
LEFT JOIN Org ON Org.name=Published_by_org.org
LEFT JOIN Published_by_org ON P.id = Published_by_org.paper
LEFT JOIN From_issue ON P.id=From_issue.paper

edit : J'avais oublié de remplacer un INNER pat LEFT

[CinePhil]

Cette table est reliée à une table Author via une association Published_by_author pour lister les auteurs.
Elle est aussi reliée à une table Org via une association Published_by_org pour lister les organisations responsables de la publications.
Et pour finir, elle aussi aussi reliée à une table Zine via une association From_issue pour indiquer que le document est tiré d'un magasine.

Ta structure et ta requête supposent le MCD suivant :
paper -0,n----publier----0,n- author
|----------0,n----publier----0,n- org
|----------0,n----publier----1,1- From_issue

La dernière association est bizarre ! Ne devrait-elle pas plutôt être celle-ci ?
paper -0,n----publier----0,n---- zine

Ou bien, si un paper n'est publié que par un seul zine ?
paper -1,1----publier----0,n- zine

Dans ta requête, il y a également une condition de jointure étonnante :

Code :

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

JOIN Org ON Org.name=Published_by_org.org

La table Org n'a t-elle pas un identifiant id comme les autres tables ? Ce serait mieux !

Ces bizarreries mises à part, essaie cette requête :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
SELECT p.title, 
	GROUP_CONCAT(a.name) AS Authors,
	GROUP_CONCAT(Org.name) AS Orgs,
	fi.zine
FROM Paper AS p
LEFT OUTER JOIN Published_by_author AS pa ON pa.paper = p.id
	LEFT OUTER JOIN Author AS a ON a.id = pa.author
LEFT OUTER JOIN Published_by_org AS po ON po.paper = p.id
	LEFT OUTER JOIN Org AS o ON o.id = po.org
LEFT OUTER JOIN From_issue AS fi ON fi.paper = p.id
GROUP BY p.title

[NLS le pingouin]

La dernière association est bizarre ! Ne devrait-elle pas plutôt être celle-ci ?
paper -0,n----publier----0,n---- zine

En fait, je sépare les magazine de leurs différents numéros (Issue). Pour l'instant, je ne gère que les articles. Mais à terme, je souhaite que les fondateurs des magazines ou organisations soient dans les tables. J'aurais donc besoin d'associations entre les magazines et leurs fondateurs indépendamment des numéros édités.
Mais je trouve aussi que ma table "From_issue" est assez maladroitement construite, il faudra que je me penche un peu plus dessus.

Paper(id, titre) -0,n --- From_issue(n°, date) --- 0,1 - Zine(nom)

Dans ta requête, il y a également une condition de jointure étonnante :

Code :

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

JOIN Org ON Org.name=Published_by_org.org

La table Org n'a t-elle pas un identifiant id comme les autres tables ? Ce serait mieux !

Le projet que je suis en train de mener avec ces tables doit me permettre de pouvoir mieux classer les articles que je trouve intéressant. Il s'agit de livre ou de d'articles trouvés sur internet. Donc je devais classer les auteurs selon leurs nom civil, ou leur pseudonyme sur Internet. Ceci, et le risque d'homonyme, m'ont fait mettre un ID sur la table des auteurs.
Au niveau des organisations, l'homonymie me semblait quand même moins fréquente. J'ai donc préféré mettre le nom comme clef principale.
Dans cette requête, je n'ai besoin que du nom des Organisations responsables de la publication, et non des autres informations stockées dans la table Org. C'est pourquoi je fais la jointure uniquement sur l'association Published_fro_org qui me fournit la donnée dont j'ai besoin.

Sinon, ta requête fonctionne très bien. Je n'ai plus qu'à en étudier le fonctionnement. Je te remercie de ta réponse, elle m'aide bien à avancer.
Je suis des cours de SQL à la fac, je suis obligé de travailler par moi-même pour espérer avoir un niveau correct à la fin de l'année sinon ça n'avancerait pas.
Si tu as des insultes à propos de la conception de ma base de donnée, n'hésite pas. J'ai passé pas mal de temps dessus, mais le seul moyen que j'ai de valider la conception c'est de tenter de l'intégrer dans un système d'information pour voir là où ça casse.

Edit :
Au passage, autre question. Les données extraites par cette requête seront traitées par du php pour les placer dans un tableau html.
J'ai prévu de formater en partie certains de ces éléments à coups de CONCAT et autre. Par exemple, les auteurs auront un lien hypertext vers une page donnant plus d'informations à leur sujet. Le fait de créer ce lien dans la requète est-il une absurdité ?
Je pensais faire comme ça pour pouvoir traiter une ligne à la fois, chaque ligne concernant un article précis.

[CinePhil]

En fait, je sépare les magazine de leurs différents numéros (Issue).

OK. Je n'avais pas compris ça comme ça, pas habitué à modéliser en anglais.
Tu as donc raison de vouloir faire ainsi.

Mais je trouve aussi que ma table "From_issue" est assez maladroitement construite, il faudra que je me penche un peu plus dessus.

Paper(id, titre) -0,n --- From_issue(n°, date) --- 0,1 - Zine(nom)

Je dirais plutôt ceci :
Paper(id, titre) -0,n --- From_issue(n°, date) --- 1,1 - Zine(nom)
Un numéro est forcément celui d'un magazine. D'ailleurs, encore une meilleure solution serait de faire une identification relative :
Paper(id, titre) -0,n --- From_issue(n°, date) --- (1,1) - Zine(nom)
Ce qui fait que la clé étrangère référençant le Zine participe à la clé primaire de la table associative From_issue.
From_issue (fi_id_zine, fi_numero, fi_date)

Ceci, et le risque d'homonyme, m'ont fait mettre un ID sur la table des auteurs.
Au niveau des organisations, l'homonymie me semblait quand même moins fréquente. J'ai donc préféré mettre le nom comme clef principale.

Une clé en VARCHAR est une mauvaise clé. Ajoute un identifiant auto-incrémenté à toute table issue d'une entité type du MCD, sauf en cas d'héritage ou d'identification relative.

Dans cette requête, je n'ai besoin que du nom des Organisations responsables de la publication, et non des autres informations stockées dans la table Org. C'est pourquoi je fais la jointure uniquement sur l'association Published_fro_org qui me fournit la donnée dont j'ai besoin.

Et pourtant, dans ta requête, tu faisais bien la jointure vers la table Org !

Sinon, ta requête fonctionne très bien. Je n'ai plus qu'à en étudier le fonctionnement. Je te remercie de ta réponse, elle m'aide bien à avancer.
Je suis des cours de SQL à la fac, je suis obligé de travailler par moi-même pour espérer avoir un niveau correct à la fin de l'année sinon ça n'avancerait pas.

Tu trouveras dans nos forums, sites, tutoriels et blogs, toute l'aide nécessaire.

Si tu as des insultes à propos de la conception de ma base de donnée, n'hésite pas. J'ai passé pas mal de temps dessus, mais le seul moyen que j'ai de valider la conception c'est de tenter de l'intégrer dans un système d'information pour voir là où ça casse.

Pour la conception de la BDD, tu peux proposer ton modèle dans le forum Schéma si tu as fait un MCD ou un MLD ou schéma équivalent ou alors dans le forum Diagrammes de classes si tu as utilisé UML.

Pour le moment, je ne vois pas d'énormités dans ton schéma, à part les petites remarques que j'ai déjà faites.

Edit :
Au passage, autre question. Les données extraites par cette requête seront traitées par du php pour les placer dans un tableau html.
J'ai prévu de formater en partie certains de ces éléments à coups de CONCAT et autre. Par exemple, les auteurs auront un lien hypertext vers une page donnant plus d'informations à leur sujet. Le fait de créer ce lien dans la requète est-il une absurdité ?
Je pensais faire comme ça pour pouvoir traiter une ligne à la fois, chaque ligne concernant un article précis.

Ce n'est pas une absurdité mais si le volume de données s'accroit, tu risques de finir par voir les performances se dégrader parce que le regroupement est plus gourmand donc plus long qu'un simple SELECT.

À noter quand même que GROUP_CONCAT n'est pas du standard SQL mais du spécifique à MySQL.

MySQL n'est pas le meilleur choix pour apprendre à bien faire les choses car il est trop permissif sur certains points, ce qui peut entraîner des erreurs, et trop limité sur d'autres, ce qui oblige à faire des requêtes plus complexes que nécessaire ou des procédures au lieu d'instructions SQL plus simples.

En Open source, Postgresql est bien meilleur !