Discussion :

[fabrice91]

Bonjour,

J'ai un souci de conception des tables de ma base...
En gros j'ai une table qui décrit des expériences avec des champs type metadonnées, communs à toutes les expériences, donc rien de spécifique à ces expériences.

Table EXPERIENCE :
champ ID -> id de l'expérience
champ nom -> nom de l’expérience
champ type -> préparatoire, confirmation, validation
champ genre d’expérience : optique, mécanique, gazeux

Puis pour chaque genre d'expérience, j'ai autant de table que de genre d'expérience qui décrivent l'expérience en elle-même avec ses résultats :
C'est un exemple raccourci, chaque table a des champs totalement différents de l'une à l'autre, ce sont des expériences qui n'ont rien en commun, l'une aura 8 champs, l'autre 12 et la dernière 15.
Donc je DOIS avoir ces 3 tables séparées.

Table OPTIQUE :
champ id -> id
champ exp_id -> clé étrangère pour la table EXPERIENCE (id)
champ indice réfraction -> valeur mesurée
champ indice transmission -> valeur mesurée

Table MECANIQUE :
champ id -> id
champ exp_id -> clé étrangère pour la table EXPERIENCE (id)
champ dureté -> valeur mesurée
champ couple -> valeur mesurée

Table GAZEUX :
champ id -> id
champ exp_id -> clé étrangère pour la table EXPERIENCE (id)
champ pression -> valeur mesurée
champ dilatation -> valeur mesurée

Mon souci c'est que pour une EXPERIENCE donnée j'aurais un ID mais cet ID peut être affecté à une des trois tables. Et je sais la table dont il s'agit grâce au champs "genre d'expérience" qui va me renvoyer vers la bonne table.
Mais cette conception me gêne, je sens bien que ce n'est pas top, le champ "genre d'expérience" de la table EXPERIENCE est en fait une variable qui ira vers la table qui porte le même nom
Est-ce qu'il y aurait un moyen de s'en sortir autrement ?
Je pensais à une table d'association mais comment lui faire savoir que les résultats sont dans une table plutôt qu'une autre ?
Merci

[escartefigue]

Il s'agit d'un classique héritage de type exclusif, une expérience est soit d'un type, soit d'un autre mais pas de deux types à la fois

Comme cette question est sans lien avec le SGBD MySQL, si vous avez besoin d'aide sur la modélisation, vous pouvez ouvrir un sujet ICI

[fabrice91]

Merci pour cette première réponse, j'ai utilisé vos termes (héritage de type exclusif) pour faire quelques recherches et je tombe dans des thématiques que je ne connais ni ne maîtrise absolument pas...
J'ai du mal à dissocier la modélisation en faisant abstraction du type de SGBD (MySql) du coup je me contrains intellectuellement...
Je peux en effet aller poser mon problème dans la section modélisation et donc parler de CLASSES au lieu de TABLES si j'ai bien compris, par contre je ne connais pas les outils ni la sémantique qui sont utilisés.

[escartefigue]

voici un article qui explique le principe : https://sqlpro.developpez.com/cours/...tion/heritage/

[CinePhil]

Bonjour fabrice91

Comme l'a dit escartefigue, il s'agit d'un cas classique d'héritage de données.

Règles de gestion :
R1 : Une expérience optique est une expérience et une expérience peut être une expérience optique.
R2 : Une expérience gazeuse est une expérience et une expérience peut être une expérience gazeuse.
R3 : Une expérience mécanique est une expérience et une expérience peut être une expérience mécanique.

MCD :
experience_optique -(1,1)----être----0,1- expérience
experience_gazeuse -(1,1)----être----0,1-------|
experience_mecanique -(1,1)----être----0,1----|

Tables :
te_experience_exp (exp_id, [colonnes communes à tous les genres d'expérience])
th_experience_optique_exo (exo_id_experience, [colonnes spécifiques aux expériences optiques])
th_experience_gazeuse_exg (exg_id_experience, [colonnes spécifiques aux expériences gazeuses])
th_experience_mecanique_exm (exm_id_experience, [colonnes spécifiques aux expériences mécaniques])

Remarques :
1) Les champs sont à la campagne ou dans les formulaires, pas dans les tables SQL qui ne sont composées que de colonnes et de lignes.

2) Dans le MCD, les cardinalités entre parenthèses signifient une identification relative qui se traduit dans les tables par le fait que la clé primaire de la table fille (les tables qui commencent par th comme "table d'héritage) est la clé étrangère référençant la table mère (te_experience_exp).

3) Dans la description de mes tables, la clé primaire est soulignée et la clé étrangère est en italique.

4) Dans votre description de la table mère des expériences, vous avez prévu une colonne type -> préparatoire, confirmation, validation. Celle ci-devrait être une clé étrangère référençant une table des types d'expérience.

5) Votre colonne genre d’expérience : optique, mécanique, gazeux est en principe inutile.

[fabrice91]

)

Remarques :
2) Dans le MCD, les cardinalités entre parenthèses signifient une identification relative qui se traduit dans les tables par le fait que la clé primaire de la table fille (les tables qui commencent par th comme "table d'héritage) est la clé étrangère référençant la table mère (te_experience_exp).

Merci pour toutes ces précisions et remarques !
J'ai un problème tout de même concernant vos tables...
Si je veux les données pour une expérience dont j'ai le nom, je dois récupérer l'id de la table expérience pour ce nom mais comment retrouver la bonne table parmi les 3 tables th si je ne sais pas le type de mon expérience ?
Je dois chercher l'id de l'expérience dans les 3 tables en bouclant sur tous les id (clés étrangère) jusqu'à trouver la bonne qui correspond à ma table expérience ???
Merci.

[CinePhil]

Si je veux les données pour une expérience dont j'ai le nom, je dois récupérer l'id de la table expérience pour ce nom

Donc pas de difficulté sur ce point.

mais comment retrouver la bonne table parmi les 3 tables th si je ne sais pas le type de mon expérience ?

Grâce aux vues.

Exemple pour la vue donnant toutes les informations des expériences optiques

Code SQL :

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

1
2
3
4
5
CREATE VIEW v_experience_optique AS
SELECT e.exp_id, -- autres colonnes communes à tous les genres d'expérience
	-- colonnes spécifiques aux expériences optiques
FROM th_experience_optique_exo o
INNER JOIN te_experience_exp e ON e.exp_id = o.exo_id_experience

Autre vue donnant les données communes à toutes les expériences et le genre de l'expérience :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
CREATE VIEW v_experience_avec_genre AS
SELECT o.exo_id_experience, 'Optique' AS genre_exeperience, -- autres colonnes communes à tous les genres d'expérience
FROM th_experience_optique_exo o
INNER JOIN te_experience_exp e ON e.exp_id = o.exo_id_experience
UNION
SELECT g.exg_id_experience, 'Gazeux', -- autres colonnes communes à tous les genres d'expérience
FROM th_experience_gazeuse_exg g 
INNER JOIN te_experience_exp e ON e.exp_id = g.exg_id_experience
UNION
SELECT m.exm_id_experience, 'Mécanique', -- autres colonnes communes à tous les genres d'expérience
FROM th_experience_mecanique_exm m ON e.exp_id = m.exm_id_experience

[fabrice91]

voici un article qui explique le principe : https://sqlpro.developpez.com/cours/...tion/heritage/

Merci pour ce lien.
J'ai bien compris ce principe, c'est un peu ce que je voulais mettre en oeuvre.
On peut lire sur le point 2 :
"les tables filles n'héritent que de la clef de la table PERSONNE et il faut faire une jointure entre table fille et mèere pour retrouver toutes les données"
En prenant cet exemple, comment faire dans le cas où j'ai une PERSONNE et donc son ID, pour savoir si c'est un client, un employé ou un prospect ?
Je dois faire une jointure sur les 3 tables pour retrouver cet ID ?
Et si on rajoute une 4eme table pour un 4eme type de personne, il faudra changer le code pour ajouter une table à la jointure ?

[fabrice91]

Donc pas de difficulté sur ce point.


Grâce aux vues.

ok, je connais les vues et leur fonctionnement mais je ne les utilise jamais
Peut-être que je n'en voyais pas l’intérêt...
Avec cet exemple, c'est clair, donc je remplis mes tables d’expérience et de résultats mais je passe par les vues pour les exploiter au mieux et éviter des requêtes à rallonge biscornues

[escartefigue]

ok, je connais les vues et leur fonctionnement mais je ne les utilise jamais
Peut-être que je n'en voyais pas l’intérêt...
Avec cet exemple, c'est clair, donc je remplis mes tables d’expérience et de résultats mais je passe par les vues pour les exploiter au mieux et éviter des requêtes à rallonge biscornues

L'intérêt des vues ne se réduit pas à ce seul usage :
- les vues permettent de garantir l'indépendance entre la structure physique des données et la couche logique, c'est là leur principal intérêt, et c'est ce qui fait que certains sites interdisent l'accès direct aux tables.
- les vues permettent de faciliter la vie en stockant des requêtes
- les vues permettent de restreindre l'accès à certaines colonnes
- certaines vues particulières, les vues matérialisées accessibles dans certains SGBD, permettent d'optimiser les accès

[fabrice91]

Merci pour ces précisions