SQL : Clé de tables pour les jointures
Lucas
|
Yo ! J'ai récemment entendu parlé des foreign keys en SQL, qui -à-priori- servent lors des jointures. Est-ce que quelqu'un peut me dire si c'est vraiment utile, comment on s'en sert, et quel est l'intérêt ? |
Vanyali
|
ben en fait, en informatique, on n'apprend pas faire des base de donnée sans les foreign key(clé étrangères) permettent de mettre une contrainte entre deux tables, pour qu'un des champs d'une des la table aie une clé étrangère qui correspond à la clé primaire de l'autre, ainsi, si tu essaye de supprimer une ligne dans la table principale (celle sans clé étrangère) tu ne pourras pas (sauf si tu a choisis on delete cascade ou autre, suivant les SGBD) si il y a une ligne du deuxième tableau qui contient dans sa clé étrangère la clé primaire de la ligne que tu voulais supprimer (il faudra supprimer les lignes de la deuxième table avant). Cela donne moins de chance de se tromper lorsque l'on supprime et d'empecher de faire que des lignes du deuxième tableau ne serve a rien. il peut aussi y avoir des clés étrangères qui pointent(ça ressemble à des pointeurs un peu Après, suivant les SGBD, un index est créé dessus, et permet de réduire le temps des requêtes, ce qui est surtout utile pour des grosses bases de données. Enfin, c'est aussi utile pour rendre la base de donnée plus évidente, ou plutôt pour la modélisation : on sais avec quoi faire une jointure quand on voit qu'il y a une foreign key et après on peut regarder dans les contrainte pour voir d'où elle viens. ça permet de bien organiser sa base de donnée Bon, maintenant, petit exemple imaginons trois tables une table personne, une table voiture et une table euh je sais pas moi n'importe, allez, pourquoi pas l'adresse pour la décomposer. donc les tables on pour champs (sans les clés étrangères, les clés primaire sont soulignés) : Personne : ID_personne, Nom, prénom, Age, Sexe Voiture : ID_Voiture, Marque, Modèle, Age Adresse : ID_Adresse, numeroDeRue, NomDeRue, CodePostal, Ville Ensuite il faut réfléchir (ou modéliser la base de donnée avec UML ou la méthode Merise si vous connaissez imaginons qu'on veuille savoir a qui la personne est mariée, quelle est sa ou ses voitures(on considère dans ce cas qu'une voiture peut appartenir qu'à une seule personne même si ce n'est pas toujours la réalité) et si sa ou ses adresses (il peut en avoir plusieurs et à l'inverse, une adresse peut avoir plusieurs personnes, si ils habitent dans un seul immeuble ou s'ils sont mariés, ont des enfants... Comme ça on voit tout les cas communs Donc une personne peut posséder plusieurs voiture, donc on ne met pas la clé étrangère dedans ou sinon il faudrait créer autant de clé étrangère que de voiture possédée possible, mais ça serais trop aléatoire et ça alourdirais la table pour rien et comme la voiture n'appartient qu'à une seule personne on peut la mettre dedans par contre, plusieurs voitures différentes pourrons avoir la même foreign key, ce n'est pas important, l'important c'est qu'elle en ai qu'une seul qui pointe vers personne (sauf cas spécial, par exemple si on veut connaitre le réparateur , on mettra deux clés étrangères une pour le possesseur et une pour le réparateur). donc on rajoute un champ (d'habitude, on le modélise avec un # devant, mais dans la base de Donnée, le # disparait) appelé #ID_personne qui contiendras un l'ID de la personne (non , pas possible o_O). pour la personne,on voulais savoir si elle était mariée, et bien on met dans la table personne un champ clé étrangère #ID_Personne_mariee qui pointe vers l'ID d'une autre personne enfin, pour le cas de l'adresse, c'est plus complexe, vu qu'on a décidé de faire que plusieurs personnes peuvent avoir la même adresse et qu'une personne peut avoir plusieurs adresse, ON NE PEUT METTRE DE CLÉ ÉTRANGÈRE NI DANS PERSONNE NI DANS ADRESSE !! ou sinon, comme dis précédemment, ce serais lourd et aléatoire d'en mettre autant que de personne possible, surtout que la question serais : de quel coter la mettre ? Dans se cas, il y a une seule solution : créer une nouvelle table assez spéciale appelée association en modélisation, elle contient Uniquement deux clés étrangère(dans ce cas, parfois il peut y en avoir plus donc voilà quels seront les champs des tables au final : (je rappelle, je souligne les clés primaire et met # devant les clés étrangères pour dire où elles sont Personne : ID_personne, Nom, prénom, Age, Sexe, #ID_Mariee Voiture : ID_Voiture, Marque, Modèle, Age, #ID_personne Adresse : ID_Adresse, numeroDeRue, NomDeRue, CodePostal, Ville APourAdresse : #ID_personne, #ID_Adresse Plus concrètement, pour définir une clé étrangère, on crée toute les tables avec tout les champs, y compris les clés étrangères avec le même type que celui de la clé primaire vers lequel elle pointe(ou sinon, on pourras pas créer les clés étrangères et quand je veux voir les voiture de la personne appelée Machin par exemple je fait : Select * FROM Personne p JOIN Voiture v ON v.ID_Personne = p.ID_Personne WHERE P.Nom = Machin (je sais pas comment tu faisait avant, mais ça devais pas être bien différent) quand tu essaieras de supprimer une personne, il ne voudras pas tant que tu n'auras pas supprimer les voiture, ou mis leurs foreign key a nul ou fait un delete Cascade (ça supprimeras avec les voitures) ou si tu a mis dans la définition de tes tables ON DELETE DROP CONSTRAINTS (je me rappelle plus exactement où tu les mets Donc si tu veut faire une base de donnée réutilisable, plus sécurisée au niveau des suppressions possible, et plus rapide, les foreign key sont utiles, donc plutôt dans un cadre pro, dans un cadre de base de donnée pour son site perso, je pense pas que se soit vraiment utile si tu ais faire sans, moi j'ai appris a faire avec donc je le ferais toujours, mais si tu a appris sans, tant que c'est pour toi, fait comme tu veux EDIT : OMG LE PAVE |
|
Lucas
|
woahh ! merci bien pour ces très claires explications Ça a l'air pratique en effet, je vais sûrement m'en servir pour Gozom. Merci merci ! |
|
Vanyali
|
de rien si tu veux, j'ai trouvé un cours sur la modélisation de BDD avec Merise (je l'ai pas lut, mais ils sont plutôt sérieux sur dévellopez.net), il y a des choses différentes par rapport à ce que j'ai appris (genre les association, moi je fait des éllipse, eux des carrés a bord arrondis, et puis ils parlent de beaucoup de chose que j'ai pas vu j'ai l'impression, et j'ai vu d'autres choses que j'ai pas vu en survolant) mais en gros, ça reste pareil, après, l'utilité, c'est de voir comment ça rendrais, de faire travailler sa logique avant de coder et donc optimiser un peu plus avant de créer vraiment la BDD |
|
Lucas
|
Merci BEAUCOUP. Que demander de plus ? Vraiment, c'est super ! |
Kearz
|
Merise c'est bien pour les très gros projet quand même. Pour pas t’emmêler les pinceaux quoi, après si c'est pour un projet perso/petite ou moyenne envergure pas besoin d'aller aussi loin Moi ce que je conseil c'est de faire un MLD (Pas besoin de MCD, c'est exactement la même chose si on connait les moyens de transformation) histoire de justement pas se chier sur les clefs étrangères parce qu'elles sont bigrement importante elles. |
|
Vanyali
|
ben merise, c'est juste MCD/MLD pour moi je trouve que c'est les seul choses utiles, MCD pour bien visualiser a quoi va ressembler la base de donnée et MLD pour voir comment l'implanter, après, le reste, je m'en sert pas, j'utilise plutôt l'UML pour le reste (la partie MCT, MLT,...) |
|
Kearz
|
Ben nan Merise englobe les connerie du style MOT, diagramme des fluxs. (enfin moi j'l'ai vu comme ca) |
|
Vanyali
|
oui, MOT, je l'ai vu vite fait aussi, ça va avec les MCT et MLT (en fait, j'avais fait des MOT pas des MCT et MLT, même si ça existe |
), celle de la personne et celle de l'adresse, Qui sont aussi ses clés primaires !! , on appellera cette table APourAdresse par exemple ainsi, pour savoir quel sont les adresse d'une personne, il fraudas faire deux jointures successive pour les atteindre (c'est plus long a écrire, mais pour la base de donnée, ça iras plus vite que sans clé étrangère 
) et ensuite, on fait par exemple dans le cas de la voiture : ALTER TABLE voiture Add Constraint fk_voiture_personne (là, je nomme la contrainte pour plus de simplicité lorqu'il m'afficheras des erreur) FOREIGN KEY ID_Personne REFERENCES Personne (ID_PERSONNE)
) ce qui rendras tes foreign key a null en théorie, je l'ai jamais utilisé, on nous l'a fortement déconseillé
Kommunauty © Tous droits réservés
Contact /
Charte & Mentions légales /
Hebergement gratuit /
Bon plan hébergement /
Aide B2i
