Discussion :

[ikayoo]

Bonjour,

Je tiens avant tout à préciser que je débute en sql. Je pense maîtriser les notions de bases et là j'essaie d'attaquer un peu le "monde" des déclencheurs.

Donc voilà je me demandais s'il était possible de lier des tables en fonction de la valeur d'un attribut.

Par exemple, j'ai une table magasin qui contient tous les produits d'un magasin. Mais ces produits peuvent être de différentes catégories (électronique, vêtement, nourriture,...) et donc en fonction de la catégorie ils contiendront certains champs (une table pour l'électronique avec ses attributs propres, une autre pour les vêtements, et ainsi de suite).

Au départ ma table est vide et j'aimerais bien commencer par remplir la table magasin en insérant la catégorie du matériel. Une fois que tout a été ajouté, je souhaiterais recevoir le formulaire permettant de remplir les champs de la table correspondant à la catégorie.

Donc en gros écrire un trigger qui va lier la table magasin avec une des tables correspondant à la catégorie choisie.

Je sais pas si j'ai été assez claire mais n'hésitez pas à me poser autant de questions qu'il le faudra

En un grand merci d'avance




PS :Voilà ce à quoi j'avais pensé mais je bloque et je sais vraiment pas si je suis dans le bon ou si je fais vraiment de la m****
et puis ça me permettrait seulement de lire l'information et pas de remplir le formulaire et donc d'écrire dans la table

CREATE DEFINER=`root`@`localhost` TRIGGER `chose_cat` AFTER UPDATE on `magasin`
FOR EACH ROW
BEGIN
DECLARE selectcat VARCHAR;
SET selectcat = ( SELECT categorie FROM magasin)
IF (selectcat = 'electronique)
INNER JOIN tb_electronique
WHERE magasin.id=tb_electronique.fk_id
IF (selectcat = 'vêtement)
...

[CinePhil]

Votre description manque de clarté. Pouvez-vous nous donner le schéma de votre base de données ?

[ikayoo]

Votre description manque de clarté. Pouvez-vous nous donner le schéma de votre base de données ?

Voici une capture du schéma



Comme on peut le voir il y a une table du magasin et 3 tables pour les catégories (j'ai réduit la liste des catégories). Chaque matériel du magasin sera lié à la table de la catégorie(cat_*) en fonction de la valeur de l'attribut catégorie de la table magasin.

[CinePhil]

Par exemple, j'ai une table magasin qui contient tous les produits d'un magasin.

Je n'avais pas remarqué ça à la première lecture mais ça devient évident avec votre schéma.

Une entité-type d'un modèle conceptuel de données (méthode Merise) ou d'un schéma entité-association (les schémas par défaut de MySQL Workbench que vous utilisez) représente des choses réelles.
Dans votre schéma, l'entité-type "magasin" contient des propriétés qui ne caractérisent pas un magasin mais un produit.

ces produits peuvent être de différentes catégories (électronique, vêtement, nourriture,...) et donc en fonction de la catégorie ils contiendront certains champs (une table pour l'électronique avec ses attributs propres, une autre pour les vêtements, et ainsi de suite).

Vous voyez d'ailleurs maintenant que vous parlez de produits et non plus de magasins !

Votre situation est celle typique d'une modélisation d'héritage de données.

Règles de gestion :
Un mobile est un produit et un produit peut être un mobile.
Une télévision est un produit et un produit peut être une télévision.
Un ordinateur est un produit et un produit peut être un ordinateur.

Ces règles de gestion entraînes le schéma (MCD) suivant :
mobile -(1,1)----être----0,1- produit
television -(1,1)----être----0,1---|
ordinateur -(1,1)----être----0,1--|

Les cardinalités entre parenthèses signifient une identification relative. Le mobile est identifié relativement au produit, ce qui signifie que l'entité-type, puis la table issue de cette entité-type, n'auront pas d'identifiant propre mais que cet identifiant sera celui du produit.

Le schéma ci-dessus entraîne la création des tables suivantes (j'utilise un nommage inspiré de celui de SQLPro) :
te_produit_prd (prd_id, prd_nom, prd_num_serie, [propriétés communes à tous les produits])
th_mobile_mob (mob_id_produit, mob_memoire, [propriétés spécifiques à tous les mobiles])
th_television_tv (tv_id_produit, tvresolution, [propriétés spécifiques à toutes les télévisions])
th_ordinateur_ord (ord_id_produit, [propriétés spécifiques à toutes les ordinateurs])

Ci-dessus, les clés primaires sont soulignées et les clés étrangères sont en italique. La clé primaire de chaque table d'héritage est donc la clé étrangère référençant la clé primaire de la table te_produit_prd. C'est ainsi qu'on fait une identification relative dans un modèle en héritage de données.

Complémentairement, vous avez aussi des propriétés qui devraient être externalisées dans des tables de référence, afin d'éviter la répétition des données, voire l'écriture de la même données sous des formes différentes. Par exemple, l'OS de l'ordinateur (Windows, Linux, IOS...) pourrait, si vous laissez ainsi une colonne de type VARCHAR dans la table des ordinateurs, être écrit une fois "Windows", une autre "W7", ou encore une autre "Windows 7" ou "Seven". Il convient donc de faire une table des OS et de l'associer à la table des ordinateurs.

Règle de gestion :
Un ordinateur fonctionne sous un système d'exploitation et un système d'exploitation peut faire fonctionner plusieurs ordinateurs.

MCD :
ordinateur -1,1----fonctionner----0,n- systeme_exploitation

Tables :
te_systeme_exploitation_os (os_id, os_nom...)
th_ordinateur_ord (ord_id_produit, [propriétés spécifiques à toutes les ordinateurs])

Un mobile a aussi un OS et la table des OS peut donc être associée aussi à la table des mobiles :
th_mobile_mob (mob_id_produit, mob_id_os, mob_memoire, [propriétés spécifiques à tous les mobiles])

À vous de trouver les autres propriétés externalisables.

[ikayoo]

Un énorme merci. C'est plus clair maintenant.

J'étais partie sur les déclencheurs car j'avais en tête que les liens entre tables devaient être "déclenchés" et je pensais qu'une seule table ne pouvait avoir plusieurs enfants pour une même clé primaire...


Je me rends compte, en fait, que je suis vraiment encore loin d'être une pro en sql


Encore merci