Discussion :

[LNa]

Bonjour,

j'ai parcouru en long en large et en travers les tutos et FAQ, mais j'ai encore trois tonnes de questions que je n'arrive pas à résoudre... Voici mon problème (du moment !) :
je souhaite modéliser la gestion d'objets (de type variable) dans laquelle interviennent différentes personnes (de type variable également...) à des dates (dont la précision n'est pas toujours la même).
Les personnes peuvent CONTROLER ou INTERVENIR sur les objets à une date donnée.

Mon problème se situe au niveau du contrôle -> j'ai pour l'instant sur cette partie du modèle :
OBJET = {id_objet} (dont héritent de nombreux types d'objets, qui ont chacun des propriétés de nature différente)
PERSONNE = {id_personne} (dont héritent d'une part une table personne_morale et d'autre part une table personne_physique)
PRECISION_DATE = { id_precision_date, lib_precision_date} (table qui "précise" les dates -> à dix jours près, au mois près, à la saison près, etc)
CONTROLER = { #id_objet, #id_personne, #id_date, #id_precision_date }

Le souci est que dans la table d'association "contrôler", j'intègre également les propriétés du contrôle (propriétés qui contituent la description de l'état d'un objet par une personne à une date), qui varient en fonction de la nature de l'objet...
Je pensais faire un héritage sur cette table d'association (des tables controle_station, controle_eqpt_hydrau, controle_eqpt_signalisation, etc....) , mais je ne sais pas s'il est correct de le faire, et je me demande si je ne suis pas en train de compliquer les choses...

Ma question est donc la suivante -> dans ce cas de figure, est-il plus pertinent :
* de conserver la table "objet" dont héritent plusieurs tables, et de créer autant de tables qui hériteront de la table d'association "contrôler", et qui auront la même clé primaire que la table "contrôle" -> id_objet, id_personne, id_date (si c'est correct ?)
* de relier indépendamment chaque table d'objets à la table "personne" par une table "controle" différente pour chaque type d'objet ???

Merci beaucoup
(houla, j'en ai mis une tartine, désolée...)

[ego]

Avant de parler des tables, tu devrais faire un modèle de classes (UML) ou MCD (Merise) pour bien y définir les propriétés des objets ainsi que leur relations.
Ensuite, tu pourras passer au modèle logique/physique.

[LNa]

Merci pour ta réponse

Béh en fait j'ai fait mon mcd.... Sur papier (j'ai tenté le coup avec AnalyseSI mais je ne parviens pas à modéliser l'héritage avec : soit ce n'est pas possible, soit je n'ai pas trouvé le truc).
C'est pourquoi j'avais mis ici le modèle logique auquel j'aboutissais (sur cette partie du modèle car il est loin d'être terminé).
Je l'ai donc 'dessiné' sous word (on ne rit pas ) pour pouvoir vous le montrer et voici ce que cela donne pour le moment (il est encore très partiel, et certainement très imparfait...) :



En fait mon problème d'hier s'est... 'déplacé'.
J'ai finalement dans l'association 'Contrôle' les propriétés 'etat' et 'problème', quelque soit le type d'objet contrôlé.
[Au départ je souhaitais pouvoir spécialiser les propriétés de 'contrôle' en fonction du type d'objet contrôlé pour pouvoir créer des tables de codification et encadrer davantage la saisie (d'où la question initiale -> liste variable de propriétés pour une table d'association), mais je me suis en fait rendu compte qu'il serait impossible de lister tous les éléments potentiellement issus d'un contrôle sur un type d'objet, et qu'il valait mieux généraliser en 'etat' et 'probleme'. (oups, je ne suis pas très claire, là, si ?)]
Seulement, là, je bloque : le contrôle d'un objet par une personne à une date donnée met en évidence une ou plusieurs actions à effectuer à une date plus ou moins précise (par exemple : remplacer un ouvrage dans deux mois, contrôler l'etat d'un ouvrage l'année prochaine, faucher un tronçon à l'automne, etc.), et je n'arrive pas du tout à modéliser ça, dans la mesure ou 'contrôle' est une association et non une entité...

Qu'en pensez-vous ? Faut-il que je fasse de 'contrôle' une entité ?
Et d'une manière générale, mon mcd est-il truffé d'âneries ?

Merci mille fois.

[ego]

ben crées une entité "Contrôle" !

[LNa]

Merci ego.
Désolée de revenir là-dessus (j'ai l'impression de te saouler...), mais il y a un petit truc dont je ne suis pas sûre si je crée une entité contrôle :
pour le moment, ma clé primaire pour 'contrôle' est composée de id_date, id_objet et id_personne. Si je crée une entité 'contrôle', puis-je garder cette même clé primaire, et si oui, comment cela se représente-t-il dans le mcd ?

Sinon, sur le morceau de mcd... Est-ce que quelqu'un veut bien le regarder un peu pour me donner son avis ? Merci beaucoup.

[ego]

Je ne suis pas un pro de Merise, je suis plutôt calé en UML mais je doute que l'on parle de clé dans un MCD !?

[LNa]

Non, bien sûr, pas de clé étrangère dans le mcd : c'est dans le mld que l'on arrive à une clé primaire pour 'contrôle' qui est composée de id_personne, id_date et id_objet, puisqu'il s'agit d'une association.
Ma question porte sur le fait que si je fais de 'contrôle' une entité, elle doit avoir un identifiant propre (non ?), disons 'id_controle', et que je ne vois pas vraiment l'intérêt de créer cet identifiant, sachant que de toute façon un contrôle se définit par un objet une date et une personne (cela aboutirait concrètement à avoir dans la base la clé primaire id_contrôle, ainsi que les clés étrangères id_date id_objet et id_personne, et qu'il faudrait ensuite que je m'arrange pour qu'il n'y ait pas de doublon id_objet&id_personne&id_date).
Je souhaiterais donc que la clé primaire de 'contrôle' reste composée de id_personne, id_date et id_objet dans le mld, mais je ne sais pas comment le représenter dans le mcd.
Quelqu'un peut-il m'éclairer là-dessus ?
Merci

[ego]

la règle que je peux te donner c'est de ne pas te servir d'informations fonctionnels pour définir l'id d'un objet quelconque.
Tu peux donc tout à fait définir un 'id' pour ton objet Contrôle sans que cet 'id' n'ai de lien avec d'autres objets/clé étrangère,...C'est même mieux selon moi (cf. règle précédente)

[LNa]

OK. Donc d'après toi, il vaut mieux que je crée un id_contrôle et que je garantisse qu'il n'existe pas plusieurs contrôles pour un tuple {date, personne, objet} par un autre moyen qu'en faisant de ces trois champs la clé primaire de la table ?
Je ne percevais pas ces trois identifiants (date objet et personne) comme étant des informations fonctionnelles du contrôle, je pensais juste logique qu'ils composent la clé primaire du contrôle dans la mesure où une date, une personne et un objet définissent un contrôle.
Je vais continuer à bosser sur le mcd et quand j'aurai quelquechose de plus abouti je le mettrai dans un nouveau post pour demander des avis...
Merci encore.

[ego]

Autant pour moi, j'avais oublié que ces infos étaient les id des autres objets.
Donc oui, tu peux les utiliser pour créer ta clé primaire de "Contrôle" dès lors que le tuple doit être unique. Attention, il faut qu'effectivement se trio définisse un et un seul Contrôle. En d'autres termes que l'on ne peut pas avoir 2 contrôle effectués par la même personne à la même date; sachant que ça dépend aussi de la précision de ta date.
Avec ces 3 ids, on peut ne pas être très loin d'une infos "métier"

[LNa]

Oui, c'est bien le cas. Un seul contrôle pour une date, une personne et un objet. Je n'ai pas trouvé comment représenter ça dans le mcd mais tant que c'est correct pas de souci. Merci.