Pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter, inscrivez-vous gratuitement !

 

  1. #1
    Membre habitué
    Inscrit en
    juin 2007
    Messages
    258
    Détails du profil
    Informations forums :
    Inscription : juin 2007
    Messages : 258
    Points : 165
    Points
    165

    Par défaut Héritage - Types d'expériences

    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

  2. #2
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 757
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 757
    Points : 8 604
    Points
    8 604
    Billets dans le blog
    1

    Par défaut

    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

  3. #3
    Membre habitué
    Inscrit en
    juin 2007
    Messages
    258
    Détails du profil
    Informations forums :
    Inscription : juin 2007
    Messages : 258
    Points : 165
    Points
    165

    Par défaut

    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.

  4. #4
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 757
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 757
    Points : 8 604
    Points
    8 604
    Billets dans le blog
    1

    Par défaut

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

  5. #5
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    15 800
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 15 800
    Points : 31 246
    Points
    31 246
    Billets dans le blog
    4

    Par défaut

    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.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  6. #6
    Membre habitué
    Inscrit en
    juin 2007
    Messages
    258
    Détails du profil
    Informations forums :
    Inscription : juin 2007
    Messages : 258
    Points : 165
    Points
    165

    Par défaut

    Citation Envoyé par CinePhil Voir le message
    )

    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.

  7. #7
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    15 800
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 15 800
    Points : 31 246
    Points
    31 246
    Billets dans le blog
    4

    Par défaut

    Citation Envoyé par fabrice91
    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
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  8. #8
    Membre habitué
    Inscrit en
    juin 2007
    Messages
    258
    Détails du profil
    Informations forums :
    Inscription : juin 2007
    Messages : 258
    Points : 165
    Points
    165

    Par défaut

    Citation Envoyé par escartefigue Voir le message
    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 ?

  9. #9
    Membre habitué
    Inscrit en
    juin 2007
    Messages
    258
    Détails du profil
    Informations forums :
    Inscription : juin 2007
    Messages : 258
    Points : 165
    Points
    165

    Par défaut

    Citation Envoyé par CinePhil Voir le message
    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

  10. #10
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 757
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 757
    Points : 8 604
    Points
    8 604
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par fabrice91 Voir le message
    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

  11. #11
    Membre habitué
    Inscrit en
    juin 2007
    Messages
    258
    Détails du profil
    Informations forums :
    Inscription : juin 2007
    Messages : 258
    Points : 165
    Points
    165

    Par défaut

    Merci pour ces précisions

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 1
    Dernier message: 06/07/2017, 21h50
  2. Réponses: 4
    Dernier message: 06/07/2016, 14h18
  3. Réponses: 5
    Dernier message: 11/03/2012, 14h58
  4. Une requête qui bloque d'autres tables
    Par iubito dans le forum Administration
    Réponses: 0
    Dernier message: 04/01/2012, 08h48
  5. Données d'une table deviennent colonne dans autre table?
    Par christophe1245 dans le forum Access
    Réponses: 8
    Dernier message: 19/12/2005, 22h01

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo