Discussion :

[chewing-gum]

Ensuite, je ne comprend pas trop l'utilisation du "inner join".

La jointure au niveau du where ne se fait plus, où n'est pas conseillé ? Ou ce sont juste 2 façons de faire différentes, mais qui reviennent à la même chose ?

Par exemple ne peut on pas écrire :
FROM Personne p, joueur j
where p.id = j.id
and p.Nom = 'Dupond' AND p.Prenom = 'Alain'

Ou alors vu la date du topique, peut être que c'est l'ancienne façon de faire ?
Merci de pouvoir m'éclairer sur ce sujet, bonne journée à tous et à toutes

Nec27

Bonjour,
Ta requête SQL donnée en exemple est correcte.

Par contre, pour comprendre la différentre entre le WHERE et le INNER JOIN, c'est expliqué ici :
http://mysql.developpez.com/faq/?pag...OINTURES_inner

Ou encore là :
http://sqlpro.developpez.com/cours/s...intures/#LII-B


Concernant ton mcd, j'ai l'impression qu'il y a une erreur :

En clair, je dispose d'une table :
--> type_materiel, contenant un id et une designation (clavier, souris, écran, carte mere, etc...)
-->materiel, contenant un id et une quantité, en relation avec la table type_materiel.

|type_materiel|--0.n--avoir--1.1--|materiel|

Cette table materiel est une entité père, où une nouvelle table est créée pour chaque type de matériel. J'ai donc une entité fils souris, une entité fils clavier, etc...

Ensuite donc pour chaque entité fils, je dispose d'autres tables mais je ne m'attarde beaucoup sur cela, juste par exemple le type de connecteur pour un clavier, la langue dans lequel il est conçu...

Si tu fais des entités pour chaque type de matériel, je pense que l'entité "type_matériel" ne sert plus à grand chose.
Il te suffira d'une jointure entre la table mère et la table fille pour savoir de quel type est le matériel.
Je n'en suis pas sûr à 100% donc attend l'avis de quelqu'un d'autre

[nec27]

Bonjour chewing-gum,

Tout d'abord, merci d'apporter un intérêt à ce sujet.
Et merci pour les liens, dès le premier j'ai bien compris. ^^

Ensuite en ce qui concerne le mcd en effet, je me suis posé plein de question et j'en ai abouti à faire comme cité ci-dessus, mais toujours sans grande conviction :s.

J'explique mon raisonnement (sûrement faux).
(je rajoute des informations afin d'avoir un exemple plus préçis.)

Un matériel possède un type, et un type possède ou non un et un seul matériel.
EDIT (Un matériel a un et un seul type de matériel, et un type de matériel a aucun ou plusieurs matériels.)

Donc on a bien :
typemateriel(idtm, designationtm)
materiel(idm,quantitem,#idtm)

ensuite la table clavier, étant sous-type de la table materiel.
clavier(idm,quantitem,#idtm,#idc)
Cette table clavier hérite bien de tous les champs du surtype ?

En ce qui concerne le champs #idc :
--> lien avec la table connectique contenant les types de port (usb, ps2, din...) que peuvent contenir un clavier (donc en relation avec la table clavier)

connectique(idc,libellec)

C'est à cause de cela que je bloque sur le mcd, car si en effet on retire la table type_materiel, comment savoir, hormis le nom de la table, que la table clavier possède comme type de matériel clavier ?
(mais je confirme que pour moi la table type_matériel est en trop, mais je ne vois pas comment l'enlever.)

Si besoin d'éclaircissements, ne pas hésiter, merci beaucoup d'avance ^^

[CinePhil]

Concernant l'INNER JOIN, j'espère que tu as bien compris que c'est LA bonne manière normalisée d'écrire les jointures ? Et ce depuis 1992 !

Si un prof t'a récemment appris l'ancienne syntaxe avec FROM WHERE sans te parler de la nouvelle, c'est qu'il a 18 ans de retard !

Concernant le message de Chewing-gum, ce qu'il voulait dire est qu'il y a redondance d'information entre le type enregistré dans la table du matériel et le fait que le matériel fasse partie d'une de ses tables filles. En plus ça peut engendrer des erreurs puisque rien n'interdit a priori qu'un matériel soit de type clavier et qu'il figure en fait dans la table des écrans.

Ce qu'il faut faire, c'est supprimer la table des types et faire des vues qui permettent de rassembler tous les attributs de la table mère avec ceux de la table fille :

Code sql :

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

1
2
3
4
CREATE VIEW v_ecran AS
SELECT *
FROM materiel m
INNER JOIN ecran e ON e.ecr_id_materiel = m.mat_id

Nota : j'ai mis SELECT * par commodité et parce que je ne connais pas la structure de tes tables mais il vaut mieux nommer explicitement les colonnes nécessaires de façon à éviter la guerre des étoiles !

J'ai aussi fait une supposition sur les colonnes de la condition de jointure. D'ailleurs, avec SELECT *, tu récupérerais deux fois l'identifiant du matériel.

Donc on a bien :
typemateriel(idtm, designationtm)
materiel(idm,quantitem,#idtm)

Oui sur le principe.

ensuite la table clavier, étant sous-type de la table materiel.
clavier(idm,quantitem,#idtm,#idc)

Non ici !
La table clavier peut par exemple avoir le nombre de touches qui est un attribut spécial du clavier et pas de tous les métariels :
clavier (clv_id_materiel, clv_nb_touches...)

Et si le clavier est associé à une table des langues :
clavier -1,1----nationaliser----0,n- Langue

Alors la table comporte aussi la clé étrangère référençant l'identifiant de la langue :
langue (lng_id, lng_libelle)
clavier (clv_id_materiel, clv_id_langue, clv_nb_touches...)

Et comme dit plus haut, c'est avec la vue que tu récupères tous les attributs du matériel en plus de ceux du clavier.
Ensuite si tu veux afficher toutes caractéristiques des claviers, tu interroge la vue et non pas la table.
Combien de claviers anglais en stock ?

Code sql :

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

1
2
3
4
SELECT COUNT(*) AS nb_claviers anglais
FROM v_clavier c
INNER JOIN langue l ON l.lng_id = c.clv_id_langue
WHERE l.lng_libelle = 'Anglais'

[nec27]

Bonjour CinePhil, tout d'abord, merci beaucoup de la réponse, j'y comprend déjà plus de choses ^^"

Cependant, quelques questions restent encore.

Je me permet de mettre ce que j'ai retravailler avec ta précieuse réponse, afin de voir si j'ai bien tout compris.

Donc j'oubli la table type_materiel.

Ensuite :

Code :

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

1
2
3
4
5
6
7
8
materiel(Mat_Id, Mat_Qte)

clavier(Clv_Id_Mat, Clv_Id_Lng)
langue(Lng_Id, Lng_Libelle)

souris(Srs_Id_Mat, Srs_Id_Typ)
type(Typ_Id, Typ_Libelle) /*mécanique, optique...*/

Donc ici une table matériel, contenant des souris et des claviers. Une souris possède un type et un clavier une langue. (exemple grossier, on ne va plus s'en sortir si je met tout^^)

Déjà est-ce bon ?

Donc ensuite tu me dis de créer des vues.
Ainsi je crée donc une vue pour chaque materiel ? Autrement dit une vue v_souris, une vue v_clavier...?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
create view v_clavier as
select Clv_Id_Mat, Clv_Id_Lng
from materiel m
inner join clavier c
on c.Clv_Id_Mat=m.Mat_Id

create view v_souris as
select Srs_Id_Mat, Srs_Id_Typ
from materiel m
inner join souris s
on s.Srs_Id_Mat=m.Mat_Id

Rien de mauvais ? :s

Autre question, sur le inner join:

Comment faire plusieurs jointures ? Par exemple ma table clavier est relié à la table langue, mais aussi à la table liaison /*filaire, sans-fil*/

Ensuite si tu veux afficher toutes caractéristiques des claviers, tu interroge la vue et non pas la table.
Combien de claviers anglais en stock ?
Code sql :

SELECT COUNT(*) AS nb_claviers_anglais
FROM v_clavier c
INNER JOIN langue l ON l.lng_id = c.clv_id_langue
WHERE l.lng_libelle = 'Anglais'

Admettons que je veuille donc faire 2 jointures.
Donc avoir la liste des claviers anglais filaire, je fais comme ceci ?

Code :

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

1
2
3
4
5
6
SELECT COUNT(*) AS nb_claviers_anglais_filaire
FROM v_clavier c
INNER JOIN langue la ON la.lng_id = c.clv_id_langue
INNER JOIN liaison li ON li.liaison_id = c.clv_id_liaison
WHERE la.lng_libelle = 'Anglais'
AND li.liaison_libelle = 'filaire'

C'est possible ?

Dernière question (désolé mais une bonne semaine que je travail sur la base de données, sans trouver de réponses concrètes à mes questions j'en profite ^^)

En ce qui concerne les filles des filles de la mère.

Je m'explique, j'ai une table matériel (mère), qui as des claviers, des souris, des câbles (jusque là c'est bon)

Cette table câble est donc table fille de la table matériel, mais cable est la table mère d'autres tables (alimentation, reseau,...)

Donc j'ai 3 niveaux de "famille".

Grand-mère^^ (materiel), mère(cable), filles(alimentation)(réseau).

Lorsque je fais une vue, sur les câbles réseaux, dois-je m'occuper de la table matériel ?

Ce qu'il faut faire, c'est supprimer la table des types et faire des vues qui permettent de rassembler tous les attributs de la table mère avec ceux de la table fille :
Code sql :

CREATE VIEW v_ecran AS
SELECT *
FROM materiel m
INNER JOIN ecran e ON e.ecr_id_materiel = m.mat_id

je ne m'occuperai donc que des tables alimentation et cable pour une vue sur les alimentations, où il faudra que je prenne aussi la table matériel ?

Je m'embrouille moi même :s

Désolé pour le roman, et merci beaucoup d'avance.

Edit : lors de ma création de table, sous phpmyadmin, pour la clé primaire de l'entité fille clavier (Clv_Id_Materiel), je met le champ en auto incrément ? Je pense que non mais j'ai un doute, de part le fait que je ne maitrise pas encore très bien les vues :s

merci !!

Nec27

[CinePhil]

Donc j'oublie la table type_materiel.

Ensuite :

Code :

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

1
2
3
4
5
6
7
8
materiel(Mat_Id, Mat_Qte)

clavier(Clv_Id_Mat, Clv_Id_Lng)
langue(Lng_Id, Lng_Libelle)

souris(Srs_Id_Mat, Srs_Id_Typ)
type(Typ_Id, Typ_Libelle) /*mécanique, optique...*/

Donc ici une table matériel, contenant des souris et des claviers. Une souris possède un type et un clavier une langue. (exemple grossier, on ne va plus s'en sortir si je met tout^^)

Déjà est-ce bon ?

Donc ensuite tu me dis de créer des vues.
Ainsi je crée donc une vue pour chaque materiel ? Autrement dit une vue v_souris, une vue v_clavier...?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
create view v_clavier as
select Clv_Id_Mat, Clv_Id_Lng
from materiel m
inner join clavier c
on c.Clv_Id_Mat=m.Mat_Id

create view v_souris as
select Srs_Id_Mat, Srs_Id_Typ
from materiel m
inner join souris s
on s.Srs_Id_Mat=m.Mat_Id

Rien de mauvais ? :s

À quoi te servent tes vues puisqu'elles ne contiennent que les colonnes des tables filles clavier et souris ?
=> Ajoute les colonnes de la table mère sauf l'identifiant puisque c'est le même que celui de la table fille.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
create view v_clavier as
select Clv_Id_Mat, Clv_Id_Lng, Mat_Qte
from materiel m
inner join clavier c
on c.Clv_Id_Mat=m.Mat_Id

create view v_souris as
select Srs_Id_Mat, Srs_Id_Typ, Mat_Qte
from materiel m
inner join souris s
on s.Srs_Id_Mat=m.Mat_Id

Autre question, sur le inner join:

Comment faire plusieurs jointures ? Par exemple ma table clavier est relié à la table langue, mais aussi à la table liaison /*filaire, sans-fil*/



Admettons que je veuille donc faire 2 jointures.
Donc avoir la liste des claviers anglais filaire, je fais comme ceci ?

Code :

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

1
2
3
4
5
6
SELECT COUNT(*) AS nb_claviers_anglais_filaire
FROM v_clavier c
INNER JOIN langue la ON la.lng_id = c.clv_id_langue
INNER JOIN liaison li ON li.liaison_id = c.clv_id_liaison
WHERE la.lng_libelle = 'Anglais'
AND li.liaison_libelle = 'filaire'

C'est possible ?

En ce qui concerne les filles des filles de la mère.

Je m'explique, j'ai une table matériel (mère), qui as des claviers, des souris, des câbles (jusque là c'est bon)

Cette table câble est donc table fille de la table matériel, mais cable est la table mère d'autres tables (alimentation, reseau,...)

Donc j'ai 3 niveaux de "famille".

Grand-mère^^ (materiel), mère(cable), filles(alimentation)(réseau).

Lorsque je fais une vue, sur les câbles réseaux, dois-je m'occuper de la table matériel ?

je ne m'occuperai donc que des tables alimentation et cable pour une vue sur les alimentations, où il faudra que je prenne aussi la table matériel ?

Les vues sont destinées à faciliter l'interrogation de la BDD et à protéger l'accès aux données si on en a besoin puisqu'on peut mettre des droits différents sur les vues et sur les tables.
Tu en crées autant que tu en as besoin !

Si tu sais que tu ne vas avoir besoin que des colonnes de cable et de réseau, inutile de faire la jointure avec la table matériel.

Edit : lors de ma création de table, sous phpmyadmin, pour la clé primaire de l'entité fille clavier (Clv_Id_Materiel), je met le champ en auto incrément ? Je pense que non mais j'ai un doute, de part le fait que je ne maitrise pas encore très bien les vues :s

Non bien sûr puisque la clé primaire de la table fille est aussi clé étrangère référençant la clé primaire de la table mère.
Et ça n'a rien à voir avec les vues qui ne sont que des requêtes enregistrées.

Bon courage pour la suite !

[nec27]

Bonjour à tous, bonjour CinePhil,

À quoi te servent tes vues puisqu'elles ne contiennent que les colonnes des tables filles clavier et souris ?
=> Ajoute les colonnes de la table mère sauf l'identifiant puisque c'est le même que celui de la table fille.

--> En effet j'ai un peu de mal avec les vues :s
Mais c'est compris et après réflexion (il m'en faut beaucoup parfois...) je trouve ça logique.

Et ça n'a rien à voir avec les vues qui ne sont que des requêtes enregistrées.

--> Tellement de mal avec les vues que je les vois partout !

Juste une dernière question,

Citation:
Edit : lors de ma création de table, sous phpmyadmin, pour la clé primaire de l'entité fille clavier (Clv_Id_Materiel), je met le champ en auto incrément ? Je pense que non mais j'ai un doute, de part le fait que je ne maitrise pas encore très bien les vues :s

Non bien sûr puisque la clé primaire de la table fille est aussi clé étrangère référençant la clé primaire de la table mère.
Et ça n'a rien à voir avec les vues qui ne sont que des requêtes enregistrées.

En ce qui concerne donc phpmyadmin, je laisse donc cette clé tel quel (sans auto incrément). Mais dans phpmyadmin, on ne peut pas faire de jointure 'en brut'. Enfin à ma connaissance. Cela signifie que je devrais remplir les deux champs (Mat_Id et Cmv_Id_Mat) en même temps via le code php ? est-ce optimisé, c'est bien la chose à faire ? Il n'y a pas un quelconque autre moyen de le faire ?

En tous cas, merci beaucoup pour ces deux réponses en or, c'est vraiment génial et très clair.

Très bonne journée à toi

Nec27

[CinePhil]

Mais dans phpmyadmin, on ne peut pas faire de jointure 'en brut'.

Que veux-tu dire par "jointure en brut" ?

Cela signifie que je devrais remplir les deux champs (Mat_Id et Cmv_Id_Mat) en même temps via le code php ?

Ne confonds-tu pas encore jointure et clé étrangère ?

Si tu veux insérer un nouveau clavier dans ta BDD, il faudra effectivement insérer d'abord le matériel dans la table du matériel puis récupérer en résultat de cette insertion l'identifiant inséré afin de pouvoir aussi l'utiliser dans la requête d'insertion du clavier dans la table clavier.

D'autres SGBD permettent de faire une requête INSERT sur une vue et le SGBD se débrouille avec mais je ne crois pas que ce soit possible avec MySQL.
Un rapide coup d'oeil à la [doc de Postgresql me laisse à penser que ce serait possible avec ce SGBD ; il est peut-être encore temps de changer de SGBD ?

J'avais dans l'idée de te suggérer de faire un trigger sur la vue pour automatiser tout ça et ne faire qu'une requête d'insertion en PHP mais j'ai vu dans la doc que c'est impossible avec MySQL.

Vous ne pouvez pas associer un déclencheur avec une table TEMPORARY ou une vue.

Par contre, tu peux aussi lancer une requête INSERT sur la table des claviers et mettre un trigger sur la table clavier qui va se charger de répartir les données dans la table matériel et dans la table clavier.

[nec27]

Ne confonds-tu pas encore jointure et clé étrangère ?

Non je ne pense pas confondre, je m'exprime mal voilà tout ^^"

Mais on va laisser tomber cette question car je ne vois pas comment m'expliquer. Mais pas d'importance. C'était une question inutile.

Si tu veux insérer un nouveau clavier dans ta BDD, il faudra effectivement insérer d'abord le matériel dans la table du matériel puis récupérer en résultat de cette insertion l'identifiant inséré afin de pouvoir aussi l'utiliser dans la requête d'insertion du clavier dans la table clavier.

Je pense que je vais rester sur cette façon de faire, les triggers ne me parlent pas du tous je ne connais que de nom, mais rien de plus, et il faudrait que j'avance sur le projet. Cette base m'a pris beaucoup trop de temps à mon goût :s

Mais je garde cette conversation en mémoire pour pouvoir travailler dessus sur un éventuel autre projet. Merci beaucoup pour l'aide apportée, bonne journée.

Nec27

[nec27]

J'ai un problème...

Pour changer. Etant donné que j'ai supprimé la table type-matériel (qui contenait souris, clavier, écran...), comment je peux afficher la liste de ces types matériels ? je n'ai plus d'endroits où la stocker.

Humm...

Explication de l'interface :

J'ai ma page réparti en 2, une partie à gauche, l'autre à droite.

La partie gauche liste les différents types de matériel, avec une quantité pour chaque type de matériel.

Mais bon, à part rajouter un champ type_materiel dans la table matériel, puis ensuite faire une requete sql avec un distinct pour ressortir toutes les sortes de types matériels, je ne vois pas comment faire. Sachant qu'il y aura un formulaire d'ajout de type matériel via le site intranet..

La table type_matériel été elle vraiment dispensable ?

[CinePhil]

Il y aurait bien une méthode qui permettrait de se passer de la table type_materiel mais tu ne vas pas aimer, surtout à cause de ton avant dernière phrase qui en plus poserait problème :

Sachant qu'il y aura un formulaire d'ajout de type matériel via le site intranet..

Si tu remets la table type_materiel, ce qui me semble a priori le plus simple, la rigueur voudrait qu'il y ait des contraintes CHECK à placer pour assurer que l'insertion dans une table fille est bien faite pour un matériel de ce type.
Là encore, si tu as l'intention de travailler avec MySQL, pas de contrainte CHECK, contrairement à tout bon SGBDR plus respectueux de la norme SQL. CHECK en MySQL doit être implémenté par des triggers et un mécanisme un peu particulier si on veut récupérer une erreur explicite. Bref, c'est un peu galère, une fois de plus, avec MySQL !

Mais bon la dernière fois j'avais évoqué MySQL parce que je pensais être dans ce forum, ce qui n'est pas le cas alors peut-être que tout ce j'ai dit dans cette discussion au sujet de ce SGBD est hors sujet.

[nec27]

ha...

Que me conseil tu de faire ?

Je crée un autre topique dans la section adaptée ? Sachant que je pense que la discussion est bientôt terminé. Je m'adapte à ce qu'il faut faire si besoin, car c'est de ma faute.

Bon je me permet juste de dire ce que je pense faire, et si tu pouvais me dire si cela est envisageable (hors contexte mysql).

Si je crée une table type-matériel, où :
materiel--1.1--avoir--0.n--type_materiel

donc de la même manière que dans mes premiers messages.

avec une vue sur clavier par exemple je récupère donc le type de matériel, afin de pouvoir déterminer une quantité. Je ne vois pas exactement le souci qu'il peut y avoir, car après tout, tout est géré via les requêtes sql non ?

Donc pour une insertion d'un clavier, je pourrai mettre

Code :

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

1
2
3
4
insert into materiel
values('',15,1) 
/*("id_materiel","qte","type_id_materiel") où 1 = type de matériel  (clavier)*/

Ensuite récupérer le code du matériel via php avec la fonction

Code :

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

1
2
$stock=mysql_insert_id(...)

Puis ensuite

Code :

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

1
2
3
4
insert into clavier
values ($stock,1)
/*(clv_id_materiel,clv_id_langue)*/

Est-ce que ce raisonnement est réellement inadapté ?

[CinePhil]

Est-ce que ce raisonnement est réellement inadapté ?

Ce n'est pas inadapté, et c'est même probablement courant, mais nous sommes ici dans la section de modélisation de la BDD et ce modèle n'interdit pas une incohérence des données, c'est à dire un type qui ne correspond pas à la table fille à laquelle appartient le matériel. C'est pour ça que dans ma réponse précédente, j'avais dit :

la rigueur voudrait

Avec ta solution, la responsabilité de la cohérence des données incombe au logiciel applicatif car le SGBD n'est pas programmé dans ce cas pour la garantir.

Bref...

Quelques petites remarques sur ce que tu as écrit dans ton dernier message et qui concernent plus le côté SQL que modélisation...

Donc pour une insertion d'un clavier, je pourrai mettre

Code :

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

1
2
3
insert into materiel
values('',15,1) 
/*("id_materiel","qte","type_id_materiel") où 1 = type de matériel  (clavier)*/

Comme id_materiel est auto-incrémenté, il vaut mieux ne pas l'inclure dans les insertion car c'est le SGBD qui va lui donner tout seul la bonne valeur :

Code :

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

1
2
INSERT INTO materiel (qte, type_id_materiel)
VALUES (15, 1)

Et au passage, vouloir donner une chaîne vide à cet id_materiel n'est pas très cohérent puisqu'une bonne clé est de type entier.