http://www.chicoree.fr/w/Relation_1-%C3%A0-1_sans_cl%C3%A9http://www.chicoree.fr/w/Relation_1-%C3%A0-1_sans_cl%C3%A9#Le_programme_incrimin.C3.A9Bien sûr, je ne vais pas reproduire ici l'intégralité du programme en cause. J'en ai extrait la partie sur laquelle je souhaite insister. Ce programme était une sorte d'application web sociale dans laquel un utilisateur s'inscrivait – et par la suite était connu des autres utilisateurs du système via son avatar. Dans la base de données, deux tables avaient été crées: une contenant les informations de l'utilisateur telles que son nom réel et la validité de son abonnement au site. L'autre contenait les données de l'avatar: pseudonyme, icône, etc. Un utilisateur ne peut avoir qu'un seul avatar. Il existe donc une relation un-à-un entre ces deux tables.

]]>http://www.chicoree.fr/w/Relation_1-%C3%A0-1_sans_cl%C3%A9#Jour_1:_tout_va_bienDans cette version, l'étudiant a créé la base de données et la table Utilisateur. Ce qui ressemble à ceci en utilisant Derby:

]]>http://www.chicoree.fr/w/Relation_1-%C3%A0-1_sans_cl%C3%A9#Jour_2:_rien_ne_va_plusIci, les choses vont se corser. L'étudiant a tout d'abord ajouté la table des avatars:

]]>http://www.chicoree.fr/w/Relation_1-%C3%A0-1_sans_cl%C3%A9#Ce_qui_ne_va_pasLe problème ici est une méconnaissance des principes fondamentaux d'une base de données relationnelle. Ici, l'étudiant s'est dit que le SELECT allait renvoyer les utilisateurs dans l'ordre dans lequel ils ont été rentrés, et les avatars dans l'ordre de leur création. En outre, puisque les utilisateurs et les avatars sont créés dans le même ordre, il lui a semblé logique que la première ligne récupérée dans rsa corresponde à la première ligne de rsu. Et ainsi de suite. En plus, le test du programme semble prouver que ce raisonnement est exact. Mais il ne l'est pas!

]]>http://www.chicoree.fr/w/Relation_1-%C3%A0-1_sans_cl%C3%A9#Preuve_par_l.27exempleVous voulez donc une preuve qu'un SELECT ne renvoie pas les données dans l'ordre de leur saisie? Et bien voici deux requêtes SELECT dénuées de clause ORDER BY. Et comme vous le verrez, l'ordre du résultat est clairement diffèrent!

]]>http://www.chicoree.fr/w/Relation_1-%C3%A0-1_sans_cl%C3%A9#Qu.27est_ce_qu.27il_faut_faireLa bonne solution ici est de rajouter dans une des tables un champ qui fait référence à la ligne correspondante dans l'autre table. C'est ce que l'on appelle une clé étrangère. C'est par l'intermédiaire de cette clé que les deux tables vont être associées. Nous avons deux options possibles:

]]>http://www.chicoree.fr/w/Relation_1-%C3%A0-1_sans_cl%C3%A9#ConclusionJe pense que maintenant le message est clairement passé: La seule manière valide d'associer des données provenant de tables différentes dans le modèle relationnel est en utilisant une jointure. Et surtout pas en faisant des suppositions hasardeuses sur l'ordre des données renvoyées par la requête SELECT.

]]>