Discussion :

[Circenses]

Bonjour,

Je butte depuis plusieurs jours sur la conception d'une base de données. Voici en quelques mots la problématique (simplifiée) :

Des personnes font des demandes pour consulter plusieurs articles sur plusieurs années. (Les articles sont à prendre dans le sens "catalogue" du terme : un article est identique sur plusieurs année.)

Particularité : ces demandes sont nombreuses et très souvent identiques : elles concernent toutes généralement les trois dernières années, et les articles demandés sont très souvent les mêmes (généralement 5 articles).

Je vous détaille les différentes solutions qui me sont venues à l'esprit.

Dans un premier temps (assez court ), j'ai envisagé de tout mettre dans la même table DEMANDE (id, n°_demande, id_personne, annee, id_article) : exemple d'une demande de id_personne=1, concernant les articles 15 à 19 pour les années 2008 et 2009 :

table DEMANDE

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 id | n°_demande | id_personne | annee | id_article
---------------------------------------------------
  1 |          1 |           1 |  2008 |         15
  2 |          1 |           1 |  2008 |         16
  3 |          1 |           1 |  2008 |         17
  4 |          1 |           1 |  2008 |         18
  5 |          1 |           1 |  2008 |         19
  6 |          1 |           1 |  2009 |         15
  7 |          1 |           1 |  2009 |         16
  8 |          1 |           1 |  2009 |         17
  9 |          1 |           1 |  2009 |         18
 10 |          1 |           1 |  2009 |         19

Pour une demande, j'ai 10 lignes ! La table grossit donc très vite (en moyenne 15 lignes par demande !).

Et si une autre personne (id_personne = 2) fait la même demande que la personne (id_personne = 1), ce qui dans mon cas est extrèmement fréquent, j'ai une forte redondance d'informations :

table 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
id | n°_demande | id_personne | annee | id_article
---------------------------------------------
 1 |         1 |           1 |  2008 |         15
 2 |         1 |           1 |  2008 |         16
...|         1 |           1 |  2008 |         17
   |         1 |           1 |  2008 |         18
   |         1 |           1 |  2008 |         19
   |         1 |           1 |  2009 |         15
   |         1 |           1 |  2009 |         16
   |         1 |           1 |  2009 |         17
   |         1 |           1 |  2009 |         18
   |         1 |           1 |  2009 |         19
---------------------------------------------
   |         2 |           2 |  2008 |         15
   |         2 |           2 |  2008 |         16
   |         2 |           2 |  2008 |         17
   |         2 |           2 |  2008 |         18
   |         2 |           2 |  2008 |         19
   |         2 |           2 |  2009 |         15
   |         2 |           2 |  2009 |         16
   |         2 |           2 |  2009 |         17
   |         2 |           2 |  2009 |         18
   |         2 |           2 |  2009 |         19

Bref, j'ai écarté cette solution, et j'ai créé une table "cascadée", REQUETE (id, id_lot_requete, annee, id_article), afin de ne garder qu'une ligne par demande et de limiter la redondance :

table DEMANDE

Code :

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

1
2
3
4
id_demande | id_personne | id_lot_requete
-----------------------------------------
         1 |           1 |              1

table REQUETE

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
id | id_lot_req | annee | id_article
------------------------------------
 1 |          1 |  2008 |         15
 2 |          1 |  2008 |         16
 3 |          1 |  2008 |         17
 4 |          1 |  2008 |         18
 5 |          1 |  2008 |         19
 5 |          1 |  2009 |         15
 6 |          1 |  2009 |         16
 7 |          1 |  2009 |         17
...|          1 |  2009 |         18
   |          1 |  2009 |         19

(Le champ id n'est qu'un identifiant technique, je ne les ai pas tous écrits.)

Avantage : si une deuxième personne fait la même requête, la table REQUETE ne bouge pas, et la table DEMANDE ne prend qu'une ligne, avec une "pointeur" sur l'id_lot_req = 1

table DEMANDE

Code :

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

1
2
3
4
5
id_demande | id_personne | id_lot_req
-------------------------------------
         1 |           1 |          1
         2 |           2 |          1

Problème : je trouve que cette cascade complique pas mal les futures insertions de demande : il va falloir que je parcours la table REQUETE à chaque fois, pour voir si la requête n'a pas déjà été soumise.

Et pour être franc, je ne vois pas comment je peux faire ce genre d'insertion.

Par ailleurs, la table REQUETE repète pas mal d'info (la liste des articles). J'hésite à refaire une "cascade", avec une table LOT_ARTICLE du genre :

table LOT_ARTICLE

Code :

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

1
2
3
4
5
6
7
8
id | id_lot_art | id_article
----------------------------
 1 |          1 |         15
 2 |          1 |         16
 3 |          1 |         17
 4 |          1 |         18
 5 |          1 |         19

La table REQUETE deviendrait :

table REQUETE

Code :

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

1
2
3
4
5
id | id_lot_req | annee | id_lot_art
------------------------------------
 1 |          1 |  2008 |          1
 2 |          1 |  2009 |          1

Problème : les insertions deviennent encore plus compliquées !

Bref, je me demande si je suis sur la bonne piste, avec cette idée de "lots". Voyez-vous une autre façon de concevoir cette base de données (quitte à tout remettre en question) ? Voire à remettre en question les fondements des bases de données relationnelles (mettre la liste des articles dans un même champ "15-16-17-18-19") ?

Merci pour votre aide !

[Richard_35]

Bonjour Circenses,

Tout d'abord, bravo pour la documentation de ta problématique !

Sur le fond, plusieurs précisions :

• tu veux donc stocker toutes les demandes de consultations d'articles, OK ?
• lors d'une nouvelle demande, veux-tu prévoir le cas de sélectionner une demande déjà référencée, mais pouvoir en supprimer quelques articles ?

[Circenses]

Bonjour Richard,

1) Oui, je souhaite stocker toutes les demandes de consultation, et pour chaque demande, je souhaite stocker tous les articles consultés.

2) Je ne suis pas certain de bien saisir ta question... Il est possible qu'une nouvelle demande concerne un "sous-ensemble" d'articles d'une ancienne demande, oui.

Mais ces deux demandes sont différentes et je ne prévois pas d'afficher une ancienne demande lorsqu'un utilisateur saisit une nouvelle demande.

Pour chaque demande, tous les articles sont proposés à l'utilisateur, qui les sélectionne selon ses besoins.

[Richard_35]

Oui, tu as bien compris les deux questions.

Tu ne semble donc pas avoir besoin d'une entité "Lot" : l'historique des demandes lui-même, groupé par ensemble article/année, constitue ces "lots" : une vue SQL (dynamique, donc) satisferait à ce besoin.

Tu aurais donc :

Personne ---0,n---[demander (date)]---0,n--- Article

ce qui donnerait :

Personne(IdPersonne, Nom, ...) ;
Article(idArticle, Année, Texte, ...) ;
DemandeEntete(IdDemande, #IdPersonne, Date, ...) ;
DemandeDetail(#IdDemande, #idArticle, #Année, ...).

Fonctionnellement, lors d'une nouvelle demande d'un article, tu pourrais proposer une liste existante (groupée) dans laquelle apparaîtrait l'article en question. Si l'utilisateur ne choisit pas de liste existante, mais choisit un autre article, tu pourrais proposer une liste existante (groupée) dans laquelle apparaîtraient les deux articles, et ainsi de suite...

[Circenses]

On n'a pas besoin de la table "lot", mais son avantage est de réduire considérablement la taille de la table qui contient le détail de la demande de l'utilisateur.

Dans la table DemandeDetail(#IdDemande, #idArticle, #Année, ...), on retrouve les 15 lignes par demande. Conséquence : une table qui grossit vite et beaucoup d'informations redondées, ce que j'aurais souhaité éviter...

Après, c'est évidemment un choix entre simplicité et performance.

[CinePhil]

Ta table s'appelle "demande" mais chaque demande n'est pas identifiée individuellement puisque l'id_demande n'est pas unique.

Il te faut revenir à des règles de gestion claires pour faciliter ta modélisation.

En première approche, on peut déjà définir cette règle de gestion :
Une personne peut effectuer plusieurs demandes et une demande est effectuée par une seule personne.

Ce qui donne ce morceau de MCD :
personne -0,n----effectuer----1,1- demande

Ensuite, il faudrait que tu clarifies cette notion d'article et d'année.
S'agit-il d'articles de journaux, scientifiques... bref, des publications ?
Auquel cas il me semble qu'un article n'a qu'une seule année (de publication).

S'agit-il plutôt d'articles dans un catalogue donc en fait des objets qui peuvent évoluer au cours des années ?

[Circenses]

Bonjour CinePhil,

L'id_demande n'est pas unique, mais uniquement dans ma 1re tentative de modélisation que j'ai pour le moins baclée. (Je corrige tout de suite.) Je souhaiterais justement qu'il le soit, et c'est le cas dans le second modèle.

Je ne suis pas rentré dans les détails, car les articles en question ne sont pas à proprement parler des articles "de journaux", mais plutôt des articles de catalogue. Ils sont de fait identiques sur plusieurs années.

[Richard_35]

On n'a pas besoin de la table "lot", mais son avantage est de réduire considérablement la taille de la table qui contient le détail de la demande de l'utilisateur.

==> l'historique fait office de lots, non ?
Si tu crées une table "historique des demandes", la table "lot" est forcément incluse dedans.

personne -0,n----effectuer----1,1- demande

==> donnerait :

DemandeEntete(IdDemande, #IdPersonne, Date, ...) ;
DemandeDetail(#IdDemande, #idArticle, #Année, ...).

{#idArticle, #Année} étant l'identifiant d'un article. Car :

personne -0,n----effectuer----1,1- demande -1,n----concerne----0,n- article

[CinePhil]

Je ne suis pas rentré dans les détails, car les articles en question ne sont pas à proprement parler des articles "de journaux", mais plutôt des articles de catalogue. Ils sont de fait identiques sur plusieurs années.

Donc un article ne change pas au cours des années ? Que représente alors l'année dans tes données ?
- l'année de fabrication de l'article ?
- l'année à laquelle la demande de consultation est faite ?
- l'année à laquelle l'article est disponible au catalogue ?

Je crois qu'il faudrait que tu nous expliques un peu mieux de quoi il s'agit.

Pour le moment, j'en arrive au même MCD que Richard :

personne -0,n----effectuer----1,1- demande -1,n----concerne----0,n- article

Ce qui donnerait pour moi les tables suivantes :
personne (prs_id, prs_nom...)
article (art_id, art_nom...)
demande (dmd_id, dmd_id_personne...)
dmd_concerner_art (dca_id_demande, dca_id_article...)

Mais je ne sais pas où caser cette année dont la signification m'échappe !