"fusion" de trois tables avec traitement SQL

Bonsoir tout le monde!

Voilà un nouveau problème :

J'ai trois tables ayant cette structure:

Agence 1
date-------------note
17/02/03---------A
12/01/98---------B
12/07/02---------C

Agence 2
date-------------note
01/05/01---------A
29/10/03---------B
24/04/05---------C

Agence 3
date-------------note
17/09/03---------A
22/11/05---------B

je souhaiterais construire une seule table en regroupant ces informations de la façon suivante :

Il faut que je garde toutes les dates (sauf si deux dates sont identiques, auquel cas, ça ne correspond qu'à une ligne) et que je fasse correspondre les notes à chaque date :

Si la note est inconnue à une date, on met Null

Ainsi, avec mon exemple, on obtiendrait:

-------------note agence 1-----note agence 2-------- note agence 3

22/11/05-----------A-----------------C--------------------B
24/04/05-----------A-----------------C--------------------A
29/10/03-----------A-----------------B--------------------A
17/09/03-----------A-----------------A--------------------A
17/02/03-----------A-----------------A--------------------Null
12/07/02-----------C-----------------A--------------------Null
01/05/01-----------B-----------------A--------------------Null
12/01/98-----------B-----------------null------------------Null

Merci pour vos propositions; j'avoue ne pas savoir par où commencer :(

Les deux systèmes : une table par agence et une colonne par agence sont aussi mauvais l'un que l'autre, la bonne solution est : une agence par ligne...

hum.. et comment serait-ce possible ?

d'autre part, j'ai simplifié un peu, car normalement plusieurs dates correspondent à une entité :
ainsi, on a plutot :

Table 1 = Agence 1
Entité-----date-----------note
E1-------17/02/03---------A
E1-------12/01/98---------B
E1-------12/07/02---------C

Table 2 = Agence 2
Entité-----date-----------note
E1-------01/05/01---------A
E1-------29/10/03---------B
E1-------24/04/05---------C

Table 3 = Agence 3
Entité-----date-----------note
E1-------17/09/03---------A
E1-------22/11/05---------B



E2 avec d'autres dates (simple copier/coller ici)
Agence 1
Entité-----date-----------note
E2-------17/02/03---------A
E2-------12/01/98---------B
E2-------12/07/02---------C

Agence 2
Entité-----date-----------note
E2-------01/05/01---------A
E2-------29/10/03---------B
E2-------24/04/05---------C

Agence 3
Entité-----date-----------note
E2-------17/09/03---------A
E2-------22/11/05---------B

Citation:

---

Envoyé par Médiat

Les deux systèmes : une table par agence et une colonne par agence sont aussi mauvais l'un que l'autre, la bonne solution est : une agence par ligne...

---

ah! sur une ligne, tu aurais :
3 fois la même date :

22/11/05-----------A--------------Agence1
22/11/05-----------C--------------Agence2
22/11/05-----------A--------------Agence3

24/04/05-----------A--------------Agence1
24/04/05-----------C--------------Agence2
24/04/05-----------A--------------Agence3


29/10/03-----------A--------------Agence1
29/10/03-----------B--------------Agence2
29/10/03-----------A--------------Agence3

tu le vois ainsi ?

Oui, si tu regardes bien, tu as 3 fois la même date, 3 fois la même agence, mais une seule fois le couple (Agence, Date)... Et je ne vois pas où est le problème. Tu verras que les choses seront beaucoup plus simple lorsque qu'une 4ième Agence va arriver...

Ok, merci pour ton point de vue, je cherche dans cette voie :)
A+

l'intérét du relationnel c'est de travailler avec des ensembles. Les histoires de normalisation sont secondaires voire inutiles.
Ici on voit bien un seul ensemble de données E(numagence,entité,date, note)
E={(Agence 1,E1-------17/02/03---------A),
(Agence1,E1-------12/01/98---------B),
....
(Agence 3,E1-------17/09/03---------A)
}
donc une seule table.
Si vraiment le revival eighties te branche, tu peux faire comme si ton disque dur faisait 200 Mo et mettre des tables de correspondance pour "déporter " les infos répétitives comme le nom de l'agence. Et ça sera normalisé, et sémantiquement adéquat.

Citation:

---

Envoyé par j6m

l'intérét du relationnel c'est de travailler avec des ensembles. Les histoires de normalisation sont secondaires voire inutiles ...

---

Absolument pas ... Pour moi les formes normales sont fondamentales pour construire un modéle de données correct ...

Sinon on risque, aux mieux de gérer des données redondantes, au pire d'avoir de graves anomalies de mises à jour ...

D'ailleurs la solution proposée au problème posé (sans doute simplifié) est parfaitement normalisée ...

Citation:

---

Envoyé par Luc Orient

Absolument pas ... Pour moi les formes normales sont fondamentales pour construire un modéle de données correct ...

---

+1000... hors systèmes décisionnels (dans ceux-là : pas de mise à jour, insertion par des robots, performance des SELECT primordiale)

Citation:

---

Envoyé par j6m

Les histoires de normalisation sont secondaires voire inutiles.

---

tu es sérieux ou c'est de la provoc ?

Citation:

---

Envoyé par j6m

tu peux faire comme si ton disque dur faisait 200 Mo et mettre des tables de correspondance pour "déporter " les infos répétitives comme le nom de l'agence. Et ça sera normalisé, et sémantiquement adéquat.

---

eh non ! Ce n'est pas parce qu'on ''déporte'' dans des ''tables de correspondance'' à l'arrache que le résultat est ''sémantiquement adéquat''.
Les FN fournissent des règles pour éviter qu'une fois dans le sgbdr, les données ne deviennent un joyeux fatras incompréhensible à utiliser par les utilisateurs et à gérer par les admins.

Citation:

---

Envoyé par TheLeadingEdge

tu es sérieux ou c'est de la provoc ?

---

D'un autre côté, cela assure du travail aux auditeurs de bases de données et aux modélisateurs, à titre personnel : merci j6m !

Merci pour vos réflexions.

Pour ma part, je m'oriente vers cette solution :
j'ai :

Agence 1
date-------------note
17/02/03---------A
12/01/98---------B
12/07/02---------C

Agence 2
date-------------note
01/05/01---------A
29/10/03---------B
24/04/05---------C

Agence 3
date-------------note
17/09/03---------A
22/11/05---------B

Je souhaite obtenir :
date--------note-------agence
22/11/05-----A----------A1
22/11/05-----C----------A2
22/11/05-----B----------A3

24/04/05-----A----------A1
24/04/05-----C----------A2
24/04/05-----A----------A3

29/10/03-----A----------A1
29/10/03-----B----------A2
29/10/03-----A----------A3

17/09/03-----A----------A1
17/09/03-----A----------A2
17/09/03-----A----------A3
...

La difficulté est de trouver la note à une date fixée pour chaque agence, étant donné que chaque agence a sa date de notation et elles sont en général différentes.

vous avez des idées ? Merci

ok, j'ai une méthode :

je fusionne les tables:

date-------------note---agence
17/02/03---------A------A1
12/01/98---------B------A1
12/07/02---------C------A1
01/05/01---------A------A2
29/10/03---------B------A2
24/04/05---------C------A2
17/09/03---------A------A3
22/11/05---------B------A3

puis pour chaque ligne, je vais chercher la note que chaque agence avait fixé à la date juste inférieure ou égale.

Ainsi pr la 1ere ligne
ti=17/02/03---------A------A1

je cherche la note des agences A2 et A3 à tm=max(t) avec t<=ti
je trouve :
01/05/01---------A------A2
Null pour A3, car il n'y a aucune date inférieure à 17/02/03 (donc pas de note)

Qu'en pensez vous ?
j'espère que le code ne sera pas trop compliqué :(

E={(Agence 1,E1-------17/02/03---------A),
(Agence1,E1-------12/01/98---------B),
....
(Agence 3,E1-------17/09/03---------A)
}
ceci est la définition en extension d'une relation en 3 FN.

la normalisation est indispensable à la construction du MCD. C'est une étape déterminante dans le fonctionnement ultérieur de l'appli.: 8O 8O 8O