Discussion :

[AurelienG_]

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

[escartefigue]

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

[AurelienG_]

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 ?

[escartefigue]

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.

[AurelienG_]

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.

[CinePhil]

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.

[AurelienG_]

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

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