1. #1
    Futur Membre du Club
    Homme Profil pro
    Chargé d'affaire
    Inscrit en
    juillet 2017
    Messages
    20
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Chargé d'affaire

    Informations forums :
    Inscription : juillet 2017
    Messages : 20
    Points : 8
    Points
    8

    Par défaut Structurer une "classe" dans un SGBD

    Bonjour.

    Je rencontre plusieurs difficultés pour avoir une modèle acceptable de base de données. Voici ma problématique :

    Nous souhaitons stocker des références produits ayant une liste de propriétés variables selon la référence.
    Nous devons donc créer une "classe" pour chaque type de produit selon le principe suivant

    [PRODUIT] (1,1) ----- (APPARTENIR) ----- (0,N) [TYPE_PRODUIT] (0,N) ----- (AVOIR) ----- (0,N) [PROPRIETES]

    Exemple 1 : Un ordinateur (produit) est un produit informatique (type) et dispose des propriétés qui lui sont propres (ram, processeur,...)
    Exemple 2 : Un lave-linge (produit) est un produit blanc (type) et dispose des propriétés qui lui sont propres (classe energétique, marque,...)

    J'ai pensé à une association entre type/produit/propriété avec un champ 'valeur', mais cela est incorrect : une référence pourrait appartenir à plusieurs type ou avoir des propriétés qui ne lui sont pas associables. Du coup je ne sais donc pas comment stocker la valeur des propriétés de mes produits.

    Avez vous des idées à ce sujet ? Merci

  2. #2
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 972
    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 : 2 972
    Points : 6 533
    Points
    6 533
    Billets dans le blog
    1

    Par défaut

    Bonjour,

    La modélisation classique par héritage ne vous convient pas ?

    Une entité-type pour mutualiser ce qui est commun à tous les produits (poids, longueur, largeur, référence commerciale, désignation)
    Un sous-type pour chaque ensemble de propriétés propres à un type de produit

    L'identifiant est commun à l'ensemble des sous-type (c'est celui du sur-type)

    cf. https://merise.developpez.com/faq/?page=MCD

  3. #3
    Futur Membre du Club
    Homme Profil pro
    Chargé d'affaire
    Inscrit en
    juillet 2017
    Messages
    20
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Chargé d'affaire

    Informations forums :
    Inscription : juillet 2017
    Messages : 20
    Points : 8
    Points
    8

    Par défaut

    Bonjour.

    L'exemple du cours fourni (merci au passage, des piqûres de rappel ne font jamais de mal) illustre très bien mon probleme et j'ai pensé à cette solution initiale.

    C'est tout à fait envisageable, mais pour passer du modèle conceptuel au modèle relationnel comment intègre-t-on les sous types ?
    Images attachées Images attachées  

  4. #4
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 972
    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 : 2 972
    Points : 6 533
    Points
    6 533
    Billets dans le blog
    1

    Par défaut

    Le schéma issu du cours que vous avez reproduit ne correspond pas à l'utilisation d'un héritage mais d'une métamodélisation.
    Ce choix est le plus pertinent s'il y a énormément de types différents avec chacun des caractéristiques spécifiques.

    La solution par héritage correspond au 1er schéma du cours, cette solution est adaptée s'il n'y a que peu de sous-types.

    Avec la solution 3 du tuto (métamodélisation) pour les cardinalités retenues, le MLD est composé des 3 tables issues de chaque entité-type + 2 tables issues des relations naires de part et d'autre, soit 5 tables en tout

    Avec la solution 1 du tuto (héritage) le nombre de tables dépend directement du nombre de sous-types.

    Autre solution évoquée dans le tuto, la plus simple, est de ne faire qu'une seule table avec des attributs facultatifs.

    La solution à mettre en œuvre dépend du contexte.

  5. #5
    Futur Membre du Club
    Homme Profil pro
    Chargé d'affaire
    Inscrit en
    juillet 2017
    Messages
    20
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Chargé d'affaire

    Informations forums :
    Inscription : juillet 2017
    Messages : 20
    Points : 8
    Points
    8

    Par défaut

    Oups en effet ce n'est pas la bonne image. la bonne image est celle juste au-dessus dans le tuto.

    J'en suis arrivé à la même conclusion de créer plusieurs tables selon les sous types. mais dans mon cas ce n'est pas envisageable du fait que j'ai traitements a faire sur des ensembles de différents types et provenant donc de différentes tables. Autant dire que les étapes suivantes de développement vont très vite se montrer compliquées.

    J'ai trouvé une méthode alternative qui se rapproche de la seconde solution proposée : créer une seule table avec l'ensemble des propriétés dans ta table référence. Pour l'ajout d'une propriété je devrai l'ajouter dans la table propriétés pour définir les spécificités du type_produit, puis mettre à jour la structure de la table des référence en y ajoutant les nouvelles propriétés en tant que champ propre.

    Merci pour votre aide.

  6. #6
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    14 990
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    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 : 14 990
    Points : 28 829
    Points
    28 829
    Billets dans le blog
    4

    Par défaut

    J'en suis arrivé à la même conclusion de créer plusieurs tables selon les sous types. mais dans mon cas ce n'est pas envisageable du fait que j'ai traitements a faire sur des ensembles de différents types
    Et alors ?
    1) Il peut y avoir des sous-sous-types :
    [------------------------------------------>Véhicule sans moteur->Vélo
    Véhicule ->Véhicule terrestre->Véhicule à moteur->Voiture
    |--------------------------------------------------------------------->Camion
    [---------------------------------------------------------------------->Moto

    2) Rappel : dans le cadre d'un héritage, on met seulement les propriétés spécifiques au sous-type dans les sous-types donc un traitement sur tous les véhicules à moteur, par exemple, ne posera pas de problème.

    J'ai trouvé une méthode alternative qui se rapproche de la seconde solution proposée : créer une seule table avec l'ensemble des propriétés dans ta table référence. Pour l'ajout d'une propriété je devrai l'ajouter dans la table propriétés pour définir les spécificités du type_produit, puis mettre à jour la structure de la table des référence en y ajoutant les nouvelles propriétés en tant que champ propre.
    Là j'ai peur de comprendre un truc qui m'effraie !
    Si sur tous vos types de produits, vous avez 100 caractéristiques, vous aurez 100 colonnes dans la table ?
    Avec des vides sur toutes les lignes puisque aucun produit n'aura toutes les caractéristiques ?

    Si vous avez trop de types pour faire de l'héritage, prenez la solution du schéma que vous avez donné par erreur. Il y manque une contrainte pour que un matériel M du type T1 ne soit pas décrit par les caractéristiques d'un type T2. En l'état, le MCD le permet.

    Solution en schéma pour contourner ça...

    Règles de gestion :
    R1 : Un type de matériel est caractérisé par une à plusieurs caractéristiques et une caractéristique peut s'appliquer à plusieurs types de matériel.
    R2 : Un matériel est typé par un seul type de matériel et un type de matériel peut typer plusieurs matériels.

    MCD :
    Materiel -1,1----typer----0,n- type_materiel -1,n----caracteriser----0,n- Caracteristique

    Continuons avec la valorisation des caractéristiques d'un matériel...

    Règle de gestion :
    R3 : Un matériel est défini par une à plusieurs caractéristiques (de son type de matériel) et une caractéristique peut définir plusieurs matériels (selon le type de matériel).

    MCD brut :
    Materiel -1,1----typer----0,n- type_materiel -1,n----caracteriser----0,n- Caracteristique
    |-------------1,n----------------------------------définir---------------------------0,n-----------|

    Ça ne résout pas le problème : Un matériel M de type T1 peut être défini par des caractéristiques du type T2.

    Solution : On identifie le matériel relativement à son type et on transforme l'association caractériser en entité-type associative :

    MCD modifié :
    Materiel -(1,1)----typer----0,n- type_materiel -1,n----(1,1)- carac_type (1,1)----0,n- Caracteristique
    |-------------1,n----------------------------------définir-----------------0,n--|

    Les cardinalités entre parenthèses représentent une identification relative, ce qui signifie que la clé étrangère référençant le type de matériel fera partie de la clé primaire de la table issue de l'entité-type Materiel.

    Passons aux tables...
    tr_type_materiel_tym (tym_id, tym_code, tym_libelle...)
    te_caracteristique_car (car_id, car_code, car_libelle, car_unite...)
    te_materiel_mat (mat_id_type_materiel, mat_numero, mat_reference, mat_nom...)
    te_carac_type_cty (cty_id_caracteristique, cty_id_type_materiel)
    tj_cty_definir_mat_cdm (cdm_id_materiel, cdm_id_type_materiel, cdm_id_caracteristique, cdm_valeur...)

    Clés primaires soulignées et clés étrangères en italique

    On remarque que dans tj_cty_definir_mat_cdm, la clé étrangère cdm_id_type_materiel n'existe qu'une fois et ne peut donc être que celle du type du matériel et de la caractéristique du type de matériel. Il devient impossible qu'un matériel M du type T1 soit défini par des caractéristiques du type T2.
    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 !

  7. #7
    Futur Membre du Club
    Homme Profil pro
    Chargé d'affaire
    Inscrit en
    juillet 2017
    Messages
    20
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Chargé d'affaire

    Informations forums :
    Inscription : juillet 2017
    Messages : 20
    Points : 8
    Points
    8

    Par défaut

    Citation Envoyé par CinePhil Voir le message
    Et alors ?
    1) Il peut y avoir des sous-sous-types :
    [------------------------------------------>Véhicule sans moteur->Vélo
    Véhicule ->Véhicule terrestre->Véhicule à moteur->Voiture
    |--------------------------------------------------------------------->Camion
    [---------------------------------------------------------------------->Moto

    2) Rappel : dans le cadre d'un héritage, on met seulement les propriétés spécifiques au sous-type dans les sous-types donc un traitement sur tous les véhicules à moteur, par exemple, ne posera pas de problème.
    Aucun problème la dessus, j'ai bien assimilé ce concept

    Citation Envoyé par CinePhil Voir le message
    Là j'ai peur de comprendre un truc qui m'effraie !
    Si sur tous vos types de produits, vous avez 100 caractéristiques, vous aurez 100 colonnes dans la table ?
    Avec des vides sur toutes les lignes puisque aucun produit n'aura toutes les caractéristiques ?
    La ou je suis, la solution actuelle correspond à ceci (d'ou la nécessité de changer )

    la solution proposée est au top, je ne savais pas ou et comment devait être placée la contrainte supplémentaire.

    Mes cheveux vous remercient

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

Discussions similaires

  1. Réponses: 7
    Dernier message: 03/12/2008, 15h18
  2. Une seule classe public dans un package
    Par bubulemaster dans le forum Débuter
    Réponses: 2
    Dernier message: 30/05/2008, 21h06
  3. Savoir si un objet d'une certaine classe est dans une liste
    Par Denti-fritz dans le forum Langage
    Réponses: 3
    Dernier message: 26/04/2007, 09h05

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