Discussion :

[symfony_dev]

Bonjour,

J'ai un soucis au niveau de la conception d'une base de données.

J'ai plusieurs équipements du genre extincteur, climatisation, lampe, etc... Chaque équipement a des attributs différents. Je souhaiterais avoir un genre de table référentielle contenant la liste des équipements mais je ne sais pas du coup comment procéder.

Voici une première ébauche


Merci.

[Kyuudan]

Salut !

Personnellement j'aurais utilisé des héritages par rapport à une classe "equipements" qui regroupent les principaux attributs.



Après je suis peut-être complètement à côté de la plaque...

Cordialement,

[symfony_dev]

Merci pour ta réponse.

J'ai également pensé à l'héritage mais dans ce cas, à chaque fois que je veux ajouter un équipement, cela ajoutera une ligne dans la classe "mère". Et donc, pour avoir une liste des "types d'équipement", je serais obligé de faire un select distinct, ce n'est pas une mauvaise solution mais j'aurais préféré avoir une table référentielle du genre "equipement_types".

[fsmrel]

Bonsoir,

J'ai plusieurs équipements du genre extincteur, climatisation, lampe, etc.

Votre présentation est succincte, aussi ne peut-on qu’essayer d’entamer une ébauche de modélisation. En tout cas, la spécialisation/généralisation (par héritage) risque de ne pas convenir, dans la mesure où la liste des sous-types (sous-classes selon les coutumes locales) n’est pas limitée à Extincteur, Climatisation, Lampe, il y a ce « etc. » préoccupant. On se retrouve un peu dans le contexte de l’heuristique papoue : « Comment comptent les papous ? » Réponse : « un, deux, beaucoup » et cela s’applique en particulier à la généralisation/spécialisation des entités-types (classes) : on part avec ce type de modélisation, puis à un moment donné on sent qu'il est préférable de changer son fusil d'épaule, car comme avec l'alcool, on peut user mais il ne faut pas abuser... A cette occasion, je reprends ce que j’ai déjà deux ou trois raconté chez DVP :

Il y a plus de 20 ans, sans lui avoir hélas ! préalablement parlé des papous, j'avais expliqué l'héritage à un concepteur, dans le domaine de l'Assurance. Avec enthousiasme (avant d’être finalement au bord de la dépression), celui-ci produisit (en mon absence) un MCD où l'on trouvait une entité-type Intervenant (intervenant dans un sinistre), faisant l'objet d'une quinzaine de sous-types : Assuré, Victime, Témoin, Ambulancier, Commissaire, Voleur, etc. Un truc à utiliser une ramette de papier au format A3 pour représenter un MCD « mille-pattes »¹... En fait, à part l’assuré, les autres intervenants ne jouaient qu’un rôle tout à fait secondaire : on a replié tout ça, en se contentant d'associer l'entité-type Intervenant à une entité-type Rôle (un intervenant pouvant au besoin jouer plusieurs rôles), avec redistribution des propriétés (que je n’ai plus en tête, il y a prescription...), c'est-à-dire qu’on a appliqué l'heuristique papoue. Deux ou trois sous-types pour un surtype, c’est bon, mais après ça peut craindre, la dépression peut vous guetter...

Bref, supposons que vous ayez une foultitude de types d’équipements et de pièces et appelons toutes ces choses par exemple « éléments », ou tout autre qualificatif qui vous convient.

Comme vous utilisez MySQL Workbench, je vous renvoie à l’article que je lui ai consacré, et étant donné que cet outil se situe au niveau relationnel (on y parle de tables, clés primaires, étrangères, etc.), j’utiliserai le terme table en lieu et place de celui d’entité-type (type d’entité, type d’individu, classe).

On peut mettre en évidence une table ELEMENT : un élément peut être un certain climatiseur, une certaine lampe, un certain extincteur, etc. Un élément a une référence, un statut (l’état dans lequel il se trouve), il est d’un certain type (et un type d’élément peut concerner un nombre quelconque d’éléments) : un certain climatiseur est du type climatiseur, etc.

Un élément peut avoir plusieurs caractéristiques et une caractéristique peut concerner des éléments de type distinct : à vous de voir si ce concept de caractéristique vous intéresse, et quel sens lui donner...

Un élément peut être l’objet d’interventions diverses et variées, datées (voire horodatées) et ayant requis une certaine durée. Là encore, à vous de voir...

Les éléments peuvent faire d’une nomenclature. Par exemple, une aile d’avion est composée d’un aileron, cinq longerons, un train d’atterrissage et cent rivets. Un aileron est composé de deux charnières et cinq rivets. Un train comporte trois charnières et huit rivets. Un longeron comporte dix rivets et une charnière de 4 rivets (Question : Combien faut-il de rivets en tout pour une aile ? Accessoirement, quel est l’âge du capitaine ?)

Si vous souhaitez représenter une nomenclature, vous pourrez consulter le paragraphe 7 de l’article : Associations réflexives (nomenclatures, hiérarchies).


Une ébauche de diagramme :



Tout ce que je viens de raconter est purement hypothétique et peut ne vous concerner que modérément, à vous de voir si cela peut quand même vous donner des idées. Surtout, n’oubliez pas de décrire avec précision vos besoins exacts, en illustrant par l’exemple...


____________________________

¹ Je profite encore de l’occasion pour relayer l’annonce passée dans le numéro 61 de l’OS à Moelle, bien qu’elle ne soit pas de la 1re fraîcheur (juillet 1939) : « Mille-pattes cherche partenaire sérieux pour numéro de claquettes. »

[symfony_dev]

Merci pour ta réponse très instructive !

Il est vrai que les besoins ne sont pas encore très clairement définis.

J'ai utilisé ta solution sur une gestion de produit. C'eette solution à l'avantage d'avoir des types de produit totalement administrable par le client. L’inconvénient est qu'il faut gérer le type de donnée et faire des conversions.

J'utiliserais cette solution si il n'est vraiment pas possible d'avoir une table par type d'élément.