Discussion :

[ganguill]

Bonjour,

j'ai quelques questions au sujet d'une base de données très particulière que je dois traiter... Quelques tables sont assez volumineuses (plusieurs millions de lignes), voilà pourquoi je voulais créer des clés primaires/étrangères afin d'accélerer la recherche lors de futures jointures.

J'ai donc une table T1 avec plusieurs informations, dont une clé primaire (numéro de téléphone).
Je possède également une autre table T2 avec un champ numéro de téléphone également, mais ici de temps en temps certaines occurences sont en double (donc pas de clé étrangère possible de T1 vers T2).

1ère question: les clés primaires et étrangères sont-elles forcément obligatoires dans une base de données?
2ème question: si quelques tables n'ont pas de relations primaires/étrangères (mais possèdent pourtant des infos communes afin de les jointer), mais que d'autres dans la base sont elles reliées par des clés primaires/étrangères, est-ce grave?

ps: je suis sous Oracle10g via Sql*Plus, bien que ce ne soit pas important ici

Merci à tous

[Waldar]

Je possède également une autre table T2 avec un champ numéro de téléphone également, mais ici de temps en temps certaines occurences sont en double (donc pas de clé étrangère possible de T1 vers T2).

Mais vous pouvez faire une clef étrangère de T2 vers T1, après est-ce que c'est correct, je ne sais pas.

1ère question: les clés primaires et étrangères sont-elles forcément obligatoires dans une base de données?

Rien n'est obligatoire au niveau de la base de données, mais en terme de modélisation, si vous n'avez aucune contrainte ça peut être catastrophique.

2ème question: si quelques tables n'ont pas de relations primaires/étrangères[...]

Non ce n'est pas nécessairement grave ni faux... mais encore une fois ce n'est pas la partie base de donnée qui le requiert, mais la modélisation !

[mnitu]

...Quelques tables sont assez volumineuses (plusieurs millions de lignes), voilà pourquoi je voulais créer des clés primaires/étrangères afin d'accélerer la recherche lors de futures jointures.

Les clés n'accélère rien; ce sont les indexes qui servent à ça. Les clés sont la en principal pour assurer l’intégrité des données.

...
Je possède également une autre table T2 avec un champ numéro de téléphone également, mais ici de temps en temps certaines occurences sont en double (donc pas de clé étrangère possible de T1 vers T2).

Le fait que les valeurs sont en "double" (mais que est-ce que ça signifie vraiment) ne vous empêche pas de définir des clés étrangères.

...
1ère question: les clés primaires et étrangères sont-elles forcément obligatoires dans une base de données?

Non, mais fortement conseillées.

[ganguill]

Pour visualiser un peu le tout, partons du principe que je possède une table T1 comme ceci:
T1
TEL_T1 | NOM | PRENOM
0445653433 | MARTIN | MICHEL
etc..


Et une table T2 comme ceci:
T2
TEL_T2 | VALEUR
0445653433 | tata
0445653433 | toto


En testant donc de définir une clé étrangère de T2 vers T1 (solution proposée par Waldar), j'obtiens cette erreur:

Code :

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

1
2
3
4
5
 
ALTER TABLE T2 ADD CONSTRAINT fk_TEL FOREIGN KEY(TEL_T2) REFERENCES T1(TEL_T1);
 
ERREUR à la ligne 2 :
ORA-02298: cannot validate (xxx.FK_ND) - parent keys not found

Si je veux simplement créer une clé étrangère de T1 vers T2, j'obtiens cette erreur:

Code :

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

1
2
3
4
ALTER TABLE T1 ADD CONSTRAINT fk_TEL FOREIGN KEY(TEL_T1) REFERENCES T2(TEL_T2)
                                                            *
ERREUR à la ligne 2 :
ORA-02270: no matching unique or primary key for this column-list

Pour cette deuxième solution, il semblerait qu'Oracle me demande que TEL_T2 soit unique ou clé primaire de T2...

Donc là, je ne vois pas du tout ce que je peux faire pour relier ces deux tables

ps: Merci beaucoup de votre aide

[sgora]

Ca veut dire que tu as des numéros de téléphones qui sont dans T2 et pas dans T1. Je ne sais pas si c'est normal, mais si c'est le cas t'es mal parti pour mettre une foreign key sur T2.

[ganguill]

Ca veut dire que tu as des numéros de téléphones qui sont dans T2 et pas dans T1. Je ne sais pas si c'est normal, mais si c'est le cas t'es mal parti pour mettre une foreign key sur T2.

Ben le problème c'est que c'est normal... Ces fichiers appartiennent à France Télécom. Maintenant je vais me renseigner afin de savoir si je peux voir quels numéros sont en trop dans T2, et surtout savoir si je peux les supprimer..

Merci beaucoup pour l'aide en tout cas

[mnitu]

...Si je veux simplement créer une clé étrangère de T1 vers T2 (donc solution de mnitu...

J’apprécierais beaucoup si vous ne m’attribuez pas des choses que je n’ai jamais dites ou suggérées.

[ganguill]

J’apprécierais beaucoup si vous ne m’attribuez pas des choses que je n’ai jamais dites ou suggérées.

Ne le prenez pas comme ça, je vais éditer.. au passage voilà quand même votre message : "Le fait que les valeurs sont en "double" (mais que est-ce que ça signifie vraiment) ne vous empêche pas de définir des clés étrangères.
"
Voilà pourquoi j'ai tout simplement tenté de créer une clé étrangère malgré ces valeurs en doubles dans T2. Maintenant je ne vois pas ce qu'il y a qui pose problème dans ce que j'ai dit.. Mais bon passons

[sgora]

Tu ne peux pas avoir de clé étrangère dans le sens T1 -> T2, dans ce cas tu devrais avoir une condition d'unicité sur les n° de tél dans T2, ce qui n'est pas le cas.

Et mnitu ne t'a aucunement conseillé cette solution, qui n'est pas possible, tu lui attribues donc une solution qui ne peut fonctionner. Tu comprends pourquoi il n'apprécie guère ?

[ganguill]

Tu ne peux pas avoir de clé étrangère dans le sens T1 -> T2, dans ce cas tu devrais avoir une condition d'unicité sur les n° de tél dans T2, ce qui n'est pas le cas.

Et mnitu ne t'a aucunement conseillé cette solution, qui n'est pas possible, tu lui attribues donc une solution qui ne peut fonctionner. Tu comprends pourquoi il n'apprécie guère ?

Je suis actuellement en train d'exécuter une requête qui me donnera le nombre de numéros étant dans T2 mais pas dans T1. Ensuite je verrais si je peux les supprimer, et je ferais alors une clé étrangère de T2 vers T1 (sinon ben tant pis ).
Pour minitu, pas de soucis je comprends ce qu'il a voulu dire. Mais je ne voulais pas attribuer quoi que ce soit à qui que ce soit (ce sont MES tests, et que ça marche ou non j'en assûme les conséquences)! Maintenant je n'ai pas pris ça comme un conseil, mais plutôt comme une phrase disant que théoriquement ça devait marcher (voilà pourquoi j'ai essayé, et je le répète c'est bien moi qui l'a décidé).

J'espère que tout est clair maintenant Merci pour ton aide sgora!

[pachot]

Bonjour,

Les clés n'accélère rien; ce sont les indexes qui servent à ça. Les clés sont la en principal pour assurer l’intégrité des données.

Ce n'est pas tout à fait juste. Les contraintes d'intégrité donne une indication sur les données, qu'Oracle utilise lors de l'optimisation des requêtes.

L'optimiseur estime le nombre de ligne retournées par les prédicats de la clause where, afin de choisir le meilleur accès. Cette estimation est d'autant plus juste que les contraintes sont renseignées: PK veut dire aussi not null, c'est une indication que toutes les lignes sont référencées dans l'index. PK et unique permettent de savoir lorsqu'un prédicat ramène une seule ligne au maximum. FK aussi, et peut même éviter d'aller voir une table si on a pas besoin des colonnes non-clé...

En bref, elles ne sont pas obligatoires mais très utiles (tout comme créer des index, ce n'est pas obligatoire, ou définir les bons types de données avec leur bonne taille, ... )

Cordialement,
Franck.

[ganguill]

Bonjour,



Ce n'est pas tout à fait juste. Les contraintes d'intégrité donne une indication sur les données, qu'Oracle utilise lors de l'optimisation des requêtes.

L'optimiseur estime le nombre de ligne retournées par les prédicats de la clause where, afin de choisir le meilleur accès. Cette estimation est d'autant plus juste que les contraintes sont renseignées: PK veut dire aussi not null, c'est une indication que toutes les lignes sont référencées dans l'index. PK et unique permettent de savoir lorsqu'un prédicat ramène une seule ligne au maximum. FK aussi, et peut même éviter d'aller voir une table si on a pas besoin des colonnes non-clé...

En bref, elles ne sont pas obligatoires mais très utiles (tout comme créer des index, ce n'est pas obligatoire, ou définir les bons types de données avec leur bonne taille, ... )

Cordialement,
Franck.

Merci beaucoup pour les renseignements
J'aurais dailleurs une petite question au sujet de mes valeurs qui seraient dans T2 mais pas dans T1.. Pour les trouver j'ai testé cette requête que j'ai fait, mais qui doit être fausse vu qu'elle fait planter Oracle... (je l'ai laissé tourné toute la nuit, mais il ne répond plus ce matin..) :

Code :

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

1
2
 
SELECT TEL_T2 FROM T2 WHERE T2 NOT IN(SELECT TEL_T1 FROM T1);

J'ai également testé ça afin de connaître le nombre (étant donné que ça avait l'air très long de tous les afficher. Mais au final ça na rien changé..) :

Code :

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

1
2
 
SELECT count(TEL_T2) FROM T2 WHERE T2 NOT IN(SELECT TEL_T1 FROM T1);

Ces requêtes seraient-elles fausses? (d'un point de vue "grammatical" ça paraît logique.. maintenant je ne sais pas

Merci à tous encore une fois

[sgora]

Tu te compliques la vie, fais plutôt un truc dans ce goût là :

Code :

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

1
2
3
4
 
select tel from t2 
minus
select tel from t1

Tu auras tous les tél de T2 qui sont absents de T1

[ganguill]

Tu te compliques la vie, fais plutôt un truc dans ce goût là :

Code :

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

1
2
3
4
 
select tel from t2 
minus
select tel from t1

Tu auras tous les tél de T2 qui sont absents de T1

Oh merci sgora, je ne connaissais pas "minus" Je testerai ça tout à l'heure!

Le problème avec mon ancienne requête c'est qu'Oracle devait à chaque fois comparer le numéro courant de T2 avec toute la table T1, puis le numéro suivant de T2 avec toute la table T1 etc... donc à chaque fois Oracle devait se faire plusieurs millions de lignes plusieurs millions de fois (du moins c'est ce que je pense)