[Résolu] Eviter les redondances dans un rapport

[ClayStone]

Bonjour à tous,

Je dispose d'une base de données comportant les articles d'un magazine et ses propriétés (date, auteur, index thématique...).
Je tente de faire des listings papier de ces articles, mais je rencontre plusieurs difficultés.
Voici la première : je construit un listing chronologique des articles en mentionnant pour chacun d'eux ses auteurs et ses index (cf. le rapport rp1 de la base jointe)
Le problème est que je n'arrive pas à éviter des redondances.
exemple : si un article possède 2 auteurs et 2 thèmes, j'aimerai obtenir

Titre
auteur 1 index 1
auteur 2 index 2

ou

Titre
auteur1
auteur 2
index1
index 2

Mais j'obtiens

Titre
auteur 1 index 1
auteur 2 index 1
auteur 1 index 2
auteur 2 index 2

ou

Titre
auteur 1
index 1
auteur 2
index 1
auteur 1
index 2
auteur 2
index 2

Quelqu'un aurait-il une idée pour m'aider à régler le problème ?
Merci d'avance

[Dude]

Salut,

Comme toujours, lorsqu'on n'arrive pas à extraire les données, c'est que le modèle relationnel n'est pas bon.

Commence par nous détailler tes tables et leurs relations :

no_problemo.png

Parce que tu nous parles d'auteur et de thème alors qu'il n'y a aucune table de ce nom.

[ClayStone]

Bonjour Dude, et merci
En effet, j’aurais dû détailler. C'est clair dans ma tête, mais je suis le seul à y être... dans ma tête.

Ma table principale, c’est la table ARTICLE avec comme champs :

• Le titre et le sous-titre (qui peut être vide) de l’article
  une relation 1 to n avec la table parution qui indique la date et le n° de parution
  le n° de la page (et éventuellement bis ou ter) de l’article (dans le n° indiqué par la table parution)

la table ARTICLE est liée (n to n) avec les table SUR_INDEX et INDEX qui renseignent le thème de l’article (table REL_ARTICLE_INDEX)

la table ARTICLE est liée (n to n) avec les tables NOM et COUSIN qui renseignent l’identité (Nom et Prenom) de
- l’auteur de l’article (table REL_ARTICLE_AUTEUR)
- le personnage dont il est question dans l’article (table REL_ARTICLE_PERSON)

Les champs lbl_nom et lbl_prenom sont dans deux tables différentes pour limiter la longueur des listes lors de la saisie (de nombreux cousins ont le même nom de famille),
Les champs n_sur_index et n_sous_index sont dans deux tables différentes pour la même raison (limiter la longueur des listes lors de la saisie)


donc, et personne ne pouvait deviner…

auteur : identifié par COUSIN.id_cousin (et donc REL_ARTICLE_AUTEUR.ref_cousin_auteur)
dans mon rapport, c’est une concaténation des champs NOM.lbl_nom et COUSIN.lbl_prénom

thème (ou index) : identifié par INDEX.id_index (et donc REL_ARTICLE_INDEX.ref_index)
dans mon rapport, c’est une concaténation des champs SUR_INDEX.n_sur_index et INDEX.n_sous_index

Mon problème se résume à :

Sans titre.png

Et donc à obtenir :
(on gagne en nombre de tables et de champs à traiter, mais on perd en lisibilité... Pas grave, pour obtenir les auteurs et index lisibles, je saurai me débrouiller en modifiant la requête source du rapport)

ARTICLE.titre
REL_ARICLE_AUTEUR.ref_cousin_auteur 1 REL_ARICLE_INDEX.ref_index 1
REL_ARICLE_AUTEUR.ref_cousin_auteur 2 REL_ARICLE_INDEX.ref_index 2

ou

ARTICLE.titre
REL_ARICLE_AUTEUR.ref_cousin_auteur1
REL_ARICLE_AUTEUR.ref_cousin_auteur 2
REL_ARICLE_INDEX.ref_index1
REL_ARICLE_INDEX.ref_index 2

Mais pas

ARTICLE.titre
REL_ARICLE_AUTEUR.ref_cousin_auteur 1 REL_ARICLE_INDEX.ref_index 1
REL_ARICLE_AUTEUR.ref_cousin_auteur 2 REL_ARICLE_INDEX.ref_index 1
REL_ARICLE_AUTEUR.ref_cousin_auteur 1 REL_ARICLE_INDEX.ref_index 2
REL_ARICLE_AUTEUR.ref_cousin_auteur 2 REL_ARICLE_INDEX.ref_index 2

ou

ARTICLE.titre
REL_ARICLE_AUTEUR.ref_cousin_auteur 1
REL_ARICLE_INDEX.ref_index 1
REL_ARICLE_AUTEUR.ref_cousin_auteur 2
REL_ARICLE_INDEX.ref_index 1
REL_ARICLE_AUTEUR.ref_cousin_auteur 1
REL_ARICLE_INDEX.ref_index 2
REL_ARICLE_AUTEUR.ref_cousin_auteur 2
REL_ARICLE_INDEX.ref_index 2

Euh... C'est clair ??

[Dude]

Je n'ai toujours pas compris ce qu'était un cousin ?
Pour moi, cette information doit figurer de manière unique dans une table auteur.
En revanche, un article peut être écrit par plusieurs auteurs et un auteur peut écrire plusieurs articles.
Donc, il faut une table intermédiaire.

[ClayStone]

En effet, j'ai bien besoin de la table intermédiaire pour les relations n to n.
Mais, oublie pour l'instant la structure de ma base, je ne crois pas que mon problème vient de là. J'ai le même problème avec une base plus simple (voir la base jointe). Je pense plutôt que c'est dans la création de mon rapport que se trouve le problème.

Je formule la question différemment, et je simplifie ma base de test.
J'ai des articles écrits par un ou plusieurs auteurs, et abordant un ou plusieurs thèmes.
Je souhaite obtenir la liste des auteurs et des thèmes pour chaque article.
En créant mon rapport, dès qu'un article possède deux auteurs, j'obtiens une réplétion du thème (et inversement). c'est cette répétition que je ne souhaite pas voir apparaître.
J'obtiens ceci,

pb1.png

j'aimerai obtenir quelque chose comme ça

rapp1.png

Mais ça n'est peut-être pas possible avec les rapports de libreoffice...

[Piaf]

Bonjour
Tu peux déjà faire un second regroupement par Auteurs

Rapport.png

A+

[ClayStone]

Merci Piaf,
En effet, ça enlève la moitié des répétitions. Mais ça ne me satisfait pas vraiment : il reste l'autre moitié.
Est-ce que dans la requête source, il y a moyen de renvoyer une concaténation auteur+thème qui respecte une condition du genre "ne pas doubler un auteur ou un thème" ?

[Piaf]

Bonsoir
Voir [Base] Contournement Group_Concat
Une solution éventuelle en SQL direct à partir de ta base

Rapport.png

A+

[ClayStone]

Intéressant, ton lien,
Je regarde ce que je peux en faire, et je reviens (mais pas tout de suite)

[Piaf]

Bonjour
Pour éviter toutes redondances, tu peux à partir de la requête rConcatThemes créer ce type de rapport en effectuant un regroupement sur chaque champ.et en mettant à 0 la hauteur de la section détail.

Rapport.png

Il serait également possible d'appliquer le principe des thèmes aux auteurs pour les avoir sur une seul ligne.

Rapport.png

A+

[ClayStone]

Bonsoir Piaf,
Parfait ! c'est pile ce que je souhaitais
Je ne connaissais pas le concept de vue. Ca a aussi résolu ailleurs d'autres problèmes que j'avais en appelant des requêtes depuis d'autres requêtes. Merci pour ce nouvel outil !

Pour aller plus loin, et avant un [Résolu], 2 questions...
Pour concaténer les champs auteur et thème par ordre alphabetique, y-a-t-il une solution autre qu'un balayage et une boucle dans une macro ?

Ajout : Oui, j’ai trouvé une solution que je détaille ici

Même question pour concaténer N (maximum de GroupeTheme) themes , à la place de 2 ou 4) ?

... et une remarque : Pourquoi avoir modifié la table REL_ARTICLE_THEME (2 colonnes, double clé primaire (maClayStone.odb)--> 3 colonne 1 clé primaire (taClayStone.odb)) ?
Ta solution semble fonctionner aussi avec ma table REL_ARTICLE_THEME à 2 colonnes, (et ça m'arrange !) en selectionnant ref_theme (et pas IdArtThem)

[micmac]

Bonjour,

Pour aller plus loin, et avant un [Résolu], 2 questions

Non, non. Après la réponse que vous recevrez suite à

et une remarque

, vous clôturez ce sujet en en ouvrez autant que vous avez de questions à poser.

La règle n° 7 stipule qu'il ne faut mettre qu'une question par fil.

Poser plusieurs questions complique la compréhension et n'encourage pas les réponses : il vaut donc mieux découper votre problème. Le titre de votre question ne peut pas refléter l'ensemble des problèmes exposés.

Afin que nous puissions avoir une base de connaissance efficace lors d'une recherche sur un seul de vos problèmes, nous vous prions de créer autant de fils que de questions.

Merci de votre collaboration.

[ClayStone]

Désolé Grand Sachem (micmac... ok )
C'est noté,
Comme tout fonctionne comme je le souhaite, le balise le sujet [résolu]
et à bientôt sur un autre sujet