Discussion :

[Ashgenesis]

Bonjour, pour un projet j'ai besoin d'une table dans laquelle je stocke une arborescence de catégories par représentation intervallaire.
Les champs de ma table sont

Code :

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

id | borne_gauche | borne_droite | nom | description

La question que je me pose, est-ce qu'il serait pertinent de séparer cette table en deux tables ?

Code :

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

1
2
TableA -> id | borne_gauche | borne_droite
TableB -> id | nom | description

Qu'est ce que cela pourrait apporter finalement ?
C'est une idée que l'on m'a soumit mais je n'arrive pas vraiment à voir un intérêt à séparer la table.

[hed62]

Pour eviter la redondance des informations :

1/ Sans séparer :

Code :

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

1
2
3
4
 
1 0  50 toto description_de_toto
2 51 90 toto description_de_toto
3 0  99 tata description_de_tata

2/ en séparant :

Code :

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

1
2
3
 
1 toto description_de_toto
2 tata description_de_tata

Code :

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

1
2
3
4
 
1 0  50
1 51 90
2 0  99

[Ashgenesis]

ok, mais cela pose un soucis de récupération de données au niveau de l'arborescence.
Prenons une structure pour réfléchir dessus, je vois mal un telle arborescence séparée en 2 tables. Je ne vois pas comment éviter la redondance d'informations. Ici les catégories "kikis" ne peuvent qu'être répétées.

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
racine -> tutu1 -> toto
                -> kikis -> kiki1
                         -> kiki2
       -> tutu2 -> toto
                -> kikis -> kiki1
                         -> kiki2

Dans une table cela correspondrait à
id  | B_G   | B_D   | Nom       | Description
---------------------------------------------
1   | 1     | 22    | racine    | Description
2   | 2     | 11    | tutu1     | Description
3   | 3     | 8     | kikis     | Description
4   | 4     | 5     | kiki2     | Description
5   | 6     | 7     | kiki1     | Description
6   | 9     | 10    | toto      | Description
7   | 12    | 21    | tutu2     | Description
8   | 13    | 18    | kikis     | Description
9   | 14    | 15    | kiki2     | Description
10  | 16    | 17    | kiki1     | Description
11  | 19    | 20    | toto      | Description

Si l'on sépare en 2 tables tout en respectant les identifiants cela ne risque-t-il pas rendre plus complexe les requêtes pour pas grands choses? Il y aurait-il une manière plus correcte de séparée les tables si cela est pertinent.

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
25
26
27
28
29
30
31
-----TABLE A-----
-----------------
id  | B_G   | B_D
-----------------
1   | 1     | 22 
2   | 2     | 11 
3   | 3     | 8  
4   | 4     | 5  
5   | 6     | 7  
6   | 9     | 10 
7   | 12    | 21 
8   | 13    | 18 
9   | 14    | 15 
10  | 16    | 17 
11  | 19    | 20 

-----TABLE B-----
-----------------
id  | Nom       | Description
-----------------------------
1   | racine    | Description
2   | tutu1     | Description
3   | kikis     | Description
4   | kiki2     | Description
5   | kiki1     | Description
6   | toto      | Description
7   | tutu2     | Description
8   | kikis     | Description
9   | kiki2     | Description
10  | kiki1     | Description
11  | toto      | Description

[hed62]

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
25
26
27
28
-----TABLE A-----
-----------------
id  | B_G   | B_D
-----------------
1   | 1     | 22 
2   | 2     | 11 
3   | 3     | 8  
4   | 4     | 5  
5   | 6     | 7  
6   | 9     | 10 
7   | 12    | 21 
8   | 13    | 18 
4   | 14    | 15 
5  | 16    | 17 
6  | 19    | 20 

-----TABLE B-----
-----------------
id  | Nom       | Description
-----------------------------
1   | racine    | Description
2   | tutu1     | Description
3   | kikis     | Description
4   | kiki2     | Description
5   | kiki1     | Description
6   | toto      | Description
7   | tutu2     | Description
8   | kikis     | Description

La clé étant les triplets : id+BG+BD dans Table A

[JPhi33]

Bonjour,

Dans ta dernière réponse, hed62, tu ne respectes pas la contrainte de départ qui est que, selon toute vraisemblance (*), la clé est "id" uniquement. Partant d'une hypothèse différente, tu arrives à une conclusion qui, même si elle est correcte, ne peut pas répondre à la question.

(*) Ashgenesis, tu as oublié de donner la clé de ta table ; même si c'est clair dans ton esprit, tu peux imaginer que ça ne l'est pas obligatoirement dans celui de tes interlocuteurs. Cependant, dans ton message initial, tu dis vouloir séparer ta table d'origine en deux tables :

TableA -> id | borne_gauche | borne_droite
TableB -> id | nom | description

Comme seul "id" est répété dans les deux tables, on peut raisonnablement supposer que la clé est "id". Pourrais-tu le confirmer ?


Ceci dit, c'est une mode typiquement "conception orientée objet" que de mettre des "id_xxx" partout, même là où il n'y en a pas besoin. Si cette table était issue d'une modélisation conceptuelle de données "classique", voici ce qu'on aurait probablement obtenu (et là, j'apporte un bémol car je ne peux me baser que sur les exemples donnés dans les messages précédents) :

arbo(borne_gauche, borne_droite, nom, description)

et il ne faut pas 3 heures pour se rendre compte qu'on ne peut pas séparer cette table en deux. En effet, il existe les dépendances fonctionnelles suivantes :

{borne_gauche, borne_droite} -> nom
{borne_gauche, borne_droite} -> description

Il n'y a aucune décomposition possible. Donc, réponse à ta question : séparer cette table en 2 n'est pas pertinent et cela peut t'apporter... des ennuis, comme tu le subodores en disant que cela risque de rendre plus complexe les requêtes pour pas grand chose.

Le fait d'avoir rajouté un identifiant artificiel "masque" les DF. Elles existent toujours mais on n'y fait plus attention. Ce qui fait germer dans l'esprit de tes petits camarades ce genre d'idées qui sèment le doute !


JPhi33

[hed62]

Effectivement, je me basais sur la description des tables laissant la clé libre, sans penser aux DF... C'est une erreur que je commet parfois (trop souvent)

[Ashgenesis]

(*) Ashgenesis, tu as oublié de donner la clé de ta table ; même si c'est clair dans ton esprit, tu peux imaginer que ça ne l'est pas obligatoirement dans celui de tes interlocuteurs. Cependant, dans ton message initial, tu dis vouloir séparer ta table d'origine en deux tables :

Tout à fait, c'est en général trop clair dans mon esprit pour penser que ça peux ne pas l'être pour quelqu'un d'autre. Et je confirme donc ton hypothèse id est bien ma clé.

Le champ id a été rajouté afin d'avoir un identifiant unique de manière à ne pas avoir de soucis lors de requêtes ultérieure. La description ainsi que le nom pouvant être changé à n'importe quel moment. Il y a aussi le fait que l'arborescence peux changer. Donc, afin d'avoir toujours une concordance, j'ai rajouté l'id me permettant donc de travailler uniquement dessus sans autres contraintes.
J'avais bien pensé à prendre les 2 bornes comme clé mais le problème survient lors d'un changement d'ordres de l'arborescence. La clé serait toujours unique mais différente pour le même nom.

L'objectif que l'on m'a soumis à la base était de séparer les tables afin d'avoir à ne travailler que sur une table simple et d'avoir un rapport avec l'autre table via les id. Mais après réflexion cela me pose plus de problème qu'autre chose. Si l'on a besoin de ne travailler que sur 2 champs on ne récupère que cela.

Je n'ai pas de connaissances sur les dépendances fonctionnelles. Il y a-t-il des cours/tutos particuliers pour cela?

Merci pour votre aide à tous 2