Requête SQL et base de donnée relationnelle
Fermé
Datura48000
Messages postés
2
Date d'inscription
jeudi 11 avril 2019
Statut
Membre
Dernière intervention
11 avril 2019
-
11 avril 2019 à 11:11
Reivax962 Messages postés 3671 Date d'inscription jeudi 16 juin 2005 Statut Membre Dernière intervention 11 février 2021 - 12 avril 2019 à 10:10
Reivax962 Messages postés 3671 Date d'inscription jeudi 16 juin 2005 Statut Membre Dernière intervention 11 février 2021 - 12 avril 2019 à 10:10
A voir également:
- Requête SQL et base de donnée relationnelle
- Formules excel de base - Guide
- Afficher les tables d'une base de données sql ✓ - Forum Programmation
- Sql (+) - Forum Programmation
- La base de données de sécurité du serveur n'a pas de compte d'ordinateur pour la relation ✓ - Forum Réseau
- Supprimer une base de données phpmyadmin ✓ - Forum Logiciels
1 réponse
Reivax962
Messages postés
3671
Date d'inscription
jeudi 16 juin 2005
Statut
Membre
Dernière intervention
11 février 2021
1 011
Modifié le 11 avril 2019 à 13:26
Modifié le 11 avril 2019 à 13:26
Bonjour,
Je n'ai pas de tuto sous la main, mais je peux essayer de t'expliquer succinctement le concept de jointure, qui est essentiel dans une base de données relationnelle.
Imagine que tu veuilles stocker des personnes, et la ville d'où ils viennent.
Tu pourrais faire une table PERSONNE (Nom, Prénom, Ville).
Seulement en faisant ça, tu t'exposes à plusieurs écueils :
- Redondance des données : on enregistrera plusieurs fois les mêmes noms de ville, ce qui peut prendre de la place pour rien. Par ailleurs si tu veux changer un nom de ville il faut le changer dans toute la table.
- Incohérence des données : tu peux te retrouver avec la même ville écrite de façons différentes (Saint-Étienne, Saint-Etienne, saint-étienne, Saint étienne...)
- Indifférenciation : certaines villes peuvent avoir le même nom. Du coup, là, on n'a plus de moyen de les distinguer...
Pour éviter ces problèmes, on va stocker les villes dans une table dédiée, et on ne place dans la table PERSONNE qu'une référence vers la bonne ville. Ce processus s'appelle la normalisation de ta base, et cette référence s'appelle une clef étrangère. C'est sur elle que s'appuiera la jointure.
Du coup on a maintenant deux tables :
PERSONNE (Nom, Prénom, Ville_Id)
VILLE (Id, Nom)
Où Ville_Id est un identifiant qui sera égal à l'Id d'une ville...
Et on en vient à la jointure : le but est, par exemple, de récupérer toutes les personnes habitant à Paris :
SELECT * FROM PERSONNE ne te surprendra pas, on cherche des informations sur les personnes, donc voilà.
INNER JOIN VILLE => On indique qu'on a besoin d'associer aux personnes les informations sur la ville à laquelle elles sont rattachées.
Mais il faut également rappeler comment se fait ce lien : ON PERSONNE.Ville_Id = VILLE.Id
On indique donc que le champ Ville_Id de la table PERSONNE correspond au champ Id de la table VILLE.
WHERE VILLE.Nom = 'Paris' : comme on a inclus la table VILLE, on peut en utiliser les champs dans la clause WHERE, et donc ne prendre que les gens dont la ville s'appelle Paris.
Voilà, si tu as des questions, j'essaierai d'y répondre.
Xavier
Je n'ai pas de tuto sous la main, mais je peux essayer de t'expliquer succinctement le concept de jointure, qui est essentiel dans une base de données relationnelle.
Imagine que tu veuilles stocker des personnes, et la ville d'où ils viennent.
Tu pourrais faire une table PERSONNE (Nom, Prénom, Ville).
Seulement en faisant ça, tu t'exposes à plusieurs écueils :
- Redondance des données : on enregistrera plusieurs fois les mêmes noms de ville, ce qui peut prendre de la place pour rien. Par ailleurs si tu veux changer un nom de ville il faut le changer dans toute la table.
- Incohérence des données : tu peux te retrouver avec la même ville écrite de façons différentes (Saint-Étienne, Saint-Etienne, saint-étienne, Saint étienne...)
- Indifférenciation : certaines villes peuvent avoir le même nom. Du coup, là, on n'a plus de moyen de les distinguer...
Pour éviter ces problèmes, on va stocker les villes dans une table dédiée, et on ne place dans la table PERSONNE qu'une référence vers la bonne ville. Ce processus s'appelle la normalisation de ta base, et cette référence s'appelle une clef étrangère. C'est sur elle que s'appuiera la jointure.
Du coup on a maintenant deux tables :
PERSONNE (Nom, Prénom, Ville_Id)
VILLE (Id, Nom)
Où Ville_Id est un identifiant qui sera égal à l'Id d'une ville...
Et on en vient à la jointure : le but est, par exemple, de récupérer toutes les personnes habitant à Paris :
SELECT * FROM PERSONNE INNER JOIN VILLE ON PERSONNE.Ville_Id = VILLE.Id WHERE VILLE.Nom = 'Paris'
SELECT * FROM PERSONNE ne te surprendra pas, on cherche des informations sur les personnes, donc voilà.
INNER JOIN VILLE => On indique qu'on a besoin d'associer aux personnes les informations sur la ville à laquelle elles sont rattachées.
Mais il faut également rappeler comment se fait ce lien : ON PERSONNE.Ville_Id = VILLE.Id
On indique donc que le champ Ville_Id de la table PERSONNE correspond au champ Id de la table VILLE.
WHERE VILLE.Nom = 'Paris' : comme on a inclus la table VILLE, on peut en utiliser les champs dans la clause WHERE, et donc ne prendre que les gens dont la ville s'appelle Paris.
Voilà, si tu as des questions, j'essaierai d'y répondre.
Xavier
11 avril 2019 à 13:41
J'ai reussi à faire apparaitre le bon résultat, mais la manip n'est pas correct...
(https://colibri.unistra.fr/fr/course/practice/notions-de-base-en-sql/les-jointures/33)
12 avril 2019 à 10:10
Je ne connais pas exactement ta base et ton modèle de données, mais il y a des choses qui semblent problématiques :
Clients.villeclie = Locations.codefilm
On dirait que tu demandes à deux choses qui n'ont rien à voir d'être égales...
Fais
select * from clients
et
select * from locations
Regarde les colonnes villeclie et codefilm, et imagine que SQL met en relation les lignes qui ont la même valeur dans ces colonnes.
Tu devrais plutôt avoir dans locations un Codeclie qui vaut le Code de la table Clients, ou quelque chose dans ce goût-là.
Xavier