Compter les lignes et dépendances fonctionnelles [Résolu]

[oneagaindoguys]

Bonjour je cherche à trouver une requête mais je ne vois pas comment m'y prendre.

J'ai une table qui a trois a attributs : A B et C pour faire simple
le triplet ABC est ma clé primaire.
J'ai une dépendance fonctionnelle (non implémentée ici) en A et B
C'est à dire que pour tout élément de A distinct, la valeur de B n'a qu'une seule possibilté

Par exemple

A B C
---------
1 2 3
1 2 4
1 2 5
8 9 4
8 9 0
8 9 5
7 2 1
7 2 8


Si A vaut 1 alors B vaut 2 ais si B vaut 2 alors je ne connais pas A (ici 1 et 7)

Or dans ma base actuelle j'aimerais récupérer toutes les valeurs de A et B qui ne respecte pas cette condition.

J'ai essayé avec des count(*), having count et group mais n'ai pas réussi.

Comment dois-je m'y prendre ?

[CinePhil]

Essaie ceci :

Code :

1
2
3
4
SELECT A
FROM la_table
GROUP BY A
HAVING COUNT(DISTINCT B) > 1

[tatayo]

Bonjour,

Envoyé par oneagaindoguys

C'est à dire que pour tout élément de A distinct, la valeur de B n'a qu'une seule possibilté

Par exemple

A B C
---------
1 2 3
1 2 4
1 2 5
8 9 4
8 9 0
8 9 5
7 2 1
7 2 8

D'après l'énoncé, je ne vois pas pourquoi les lignes de l'exemple ne respectent pas cette condition: pour toute valeur de A, B ne doit prendre qu'une seule valeur.
Dans l'exemple, quand A vaut 1, B vaut 2, quand A vaut 8, B vaut 9 et quand A vaut 7, B vaut 2.
Il n'y a pas inversion de A et B quelquepart dans l'énoncé ?

Tatayo.

[oneagaindoguys]

C'est presque ça !
Il me sort quelque chose qui pourrait être ce que je cherche. Par contre il ne sort la ligne qu'une seule fois

J'ai fais

Code :

1
2
3
4
5
6
 
SELECT A,B
FROM la_table
GROUP BY A
HAVING COUNT(DISTINCT B) > 1
ORDER BY A;

Les A apparaissent une seule fois. J'aurais voulu avoir tous les B qui y sont associés.

[oneagaindoguys]

Envoyé par tatayo

Bonjour,


D'après l'énoncé, je ne vois pas pourquoi les lignes de l'exemple ne respectent pas cette condition: pour toute valeur de A, B ne doit prendre qu'une seule valeur.
Dans l'exemple, quand A vaut 1, B vaut 2, quand A vaut 8, B vaut 9 et quand A vaut 7, B vaut 2.
Il n'y a pas inversion de A et B quelquepart dans l'énoncé ?

Tatayo.

Cet exemple est l'idéal. C'est à dire le but recherché

Or visiblement j'ai ça :

A B C
---------
1 2 3
1 2 4
1 2 5
8 9 4
8 9 0
8 9 5
7 2 1
7 2 8
7 9 4
7 6 1

Si A vaut 7 alors B vaut soit 2 soit 9 soit 6, mais pas plus d'un à la fois...
J'aimerais intervenir pour corriger

[tatayo]

Et avec ceci:

Code SQL :

1
2
3
4
 
SELECT DISTINCT t1.A,T1.B
FROM latable T1
INNER JOIN latable.T2 ON T1.A = T2.A AND T1.B <> T2.B

Tatayo.

[fsmrel]

Bonsoir,

Envoyé par oneagaindoguys

J'ai une table qui a trois a attributs : A B et C pour faire simple
le triplet ABC est ma clé primaire.
J'ai une dépendance fonctionnelle (non implémentée ici) en A et B

Le triplet {A, B, C} n’est pas clé, mais c’est plutôt la paire {A, C}. En effet, du fait de la dépendance fonctionnelle, le triplet viole la règle d’irréductibilité des clés candidates.

Par ailleurs, toujours du fait de la dépendance fonctionnelle, la table viole la deuxième forme normale et devrait théoriquement être décomposée en deux tables :

T1 {A, B} de clé primaire {A}
T2 {A, C} de clé primaire {A, C}, avec clé étrangère {A} référençant T1.

Quand vous aurez réparé les dégâts, normalisez en mettant en œuvre T1 et T2, et, pour respecter la 9e des 12 règles de Codd, définissez une vue qui soit la jointure naturelle de T1 et T2 et représente votre table actuelle.

Si on vous empêche de procéder ainsi, mettez au moins en œuvre un trigger permettant de faire respecter la dépendance fonctionnelle {A} -> {B}.

[oneagaindoguys]

Tatayo : merci beaucoup ça fonctionne niquel !! J'ai rajouté un distinct pour ne garder qu'un exemplaire des lignes

fsmrel : C'est vrai tu as raison, du fait que j'ai une dépendance fonctionnelle.
Sinon, merci, je commence à comprendre l'intérêt des vues.
Par contre, en quoi cette architecture poserait problème ?

[fsmrel]

Envoyé par oneagaindoguys

en quoi cette architecture poserait problème ?

La dépendance fonctionnelle {A} -> {B} est la traduction d’une règle de gestion de votre système d’information. Ne pas la prendre en compte conduit — entre autres — aux anomalies que vous êtes amené à corriger (et qui ne manqueront pas de se reproduire), et heureusement que des gens comme CinePhil et tatayo sont là pour vous aider à sortir du pétrin...

Par ailleurs, le viol de la deuxième forme normale engendre des redondances, du genre de celles qui apparaissent dans votre exemple : si l’on apprend n fois que A = 1, vous devez répéter n fois que B = 2 alors qu’une fois suffit. Si n = cent millions, avouez qu’il y a de la grosse gabegie. Si vous avez plusieurs tables dans cette situation, ça fait vraiment désordre et la situation devient plus que périlleuse. Par ailleurs, tenez compte des avertissements classiques concernant les difficultés de mise à jour inhérentes à votre architecture.

Appliquez le théorème de Heath et après décomposition de votre table, les choses ressembleront à ceci, à supposer que si A vaut 1, B doit valoir 2, etc.) :

Code :

1
2
3
4
5
6
7
8
9
10
T1 {A, B}     T2 {A, C}
    1  2          1  3
    8  9          1  4
    7  2          1  5
                  8  4
                  8  0
                  8  5
                  7  1
                  7  8
                  7  4

Par ailleurs, comme votre clé primaire n’est pas la bonne, parce qu’elle est réductible à {A, C}, vous noterez qu’elle n’est pas conforme aux règles de gestion et ainsi, vous avez plus d’une fois dans votre table la paire {A= 7, C = 1}.

Bref, visez à construire des structures saines, notamment en maîtrisant la normalisation des bases de données.