"fusion" de trois tables avec traitement SQL

**Requin15** · 05/06/2006, 18h27

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

**Médiat** · 05/06/2006, 19h05

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...

**Requin15** · 05/06/2006, 19h15

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

**Requin15** · 05/06/2006, 19h19

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 ?

**Médiat** · 05/06/2006, 20h07

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...

**Requin15** · 05/06/2006, 20h13

Ok, merci pour ton point de vue, je cherche dans cette voie

A+

**j6m** · 05/06/2006, 22h18

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.

**Luc Orient** · 05/06/2006, 23h45

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 ...

**Médiat** · 06/06/2006, 05h21

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)

**TheLeadingEdge** · 06/06/2006, 06h00

Envoyé par j6m

Les histoires de normalisation sont secondaires voire inutiles.

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

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.

**Médiat** · 06/06/2006, 08h21

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 !

**Requin15** · 06/06/2006, 12h05

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

**Requin15** · 06/06/2006, 12h29

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é

**j6m** · 09/11/2006, 21h34

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.:

"fusion" de trois tables avec traitement SQL

Langage SQL

Discussions similaires

Partager

Partager