Discussion :

[Darkaurora]

Bonjours, nous cherchons depuis quelques jours la meilleur solution à implémenter pour une refonte de projet.

Nous avons des objets au sens général du terme qui étaient clairement identifiés auparavant mais qui maintenant pourront être tout et n'importe quoi. Nous avions donc une table pour chaque objet puisqu'en plus de ça tous ces objets nécessite des règles de gestion strictes et définis. Or maintenant nous devons laisser le soin à l'utilisateur de pouvoir créer tout ce qu'il souhaite, et c'est maintenant que notre calvaire commence

Voici le modèle que mon supérieur nous a soumis:



Pour vous l'expliquer de la manière la plus simple possible je vais citer les règles de gestion suivantes:
1. Un objet est constitué au moins d'un ou de plusieurs éléments.
2. Chaque éléments possède un sous élément et un contenu qui correspondent simple à un attribut et sa valeur.
3. Un objet à un modèle d'objet et un élément à un model d'élément.
4. Enfin un modèle d'objet est constitué d'au moins un modèle d'élément.

Nous n'arrivons pas à nous mettre d'accord sur ce modèle, pour ma part je pense que les tables ELEMENT, MODELE_ELEMENT et MODELE_OBJET_has_MODELE_ELEMENT sont de trop. et que l'on pourrait contourner ces tables avec une simple représentation intervallaire ou une association réflexive.

Qu'en pensez vous ? Si je n'ai pas été suffisamment clair n'hésitez pas à me poser des questions.

D'avance merci.

[CinePhil]

Bonjour,

Votre schéma ressemble davantage à un diagramme de classes UML qu'à un MCD merisien.

Si un sous-élément est un élément, alors il n'y a pas besoin de faire une entité-type (ou classe en UML) 'sous-élément'. Une association réflexive sur l'élément est en principe suffisante, sauf si le sous-élément a des propriétés spécifiques.

Autre problème, il y a plusieurs boucles dans votre schéma, ce qui peut poser de gros problèmes de cohérence d'information.
Par exemple, si un modèle objet MObj1 a pour modèles éléments Mel1 et Mel2 et si l'objet Obj5 est de modèle objet MObj1, rien n'interdit dans votre schéma que Obj5 soit associé à l'élément El12 qui est de modèle élément Mel7 qui ne correspond pas au modèle objet MObj1.
Il y a donc des contraintes à spécifier pour résoudre ces cas délicats.

Ce sujet a déjà été abordé plusieurs fois dans le forum Schéma et peut-être aussi dans le forum UML.

Pourriez vous nous donner quelques exemples de ce que sont ces modèles d'objets et d'éléments, ces objets, éléments et sous-éléments ?

[Darkaurora]

D'abord merci de ta réponse rapide. Pour prendre un cas concret que nous gérons (et tel que je le vois). Nous travaillons sur des lampadaires. Un lampadaire est constitué d'un support (le mat) et d'un luminaire, le luminaire lui est constitué d'un vitre et d'une ampoule. Nous savons le gérer avec notre modèle actuel mais nous voudrions permettre à l'utilisateur de pouvoir créer n'importe quel objet comme par exemple un panneau publicitaire. Chaque objet a un certain nombre d'attribut (très peu en fait) qui leur sont commun d'ou l'utilité d'une entité objet.

Par la suite chaque objet peut avoir des caractéristiques qui lui sont propres et c'est à ce moment que SOUS_ELEMENT et CONTENU_SOUS_ELEMENT rentre en oeuvre.

Je dois également avouer que j'ai un problème de compréhension au niveau des modèles (OBJET et ELEMENT), je pense qu'il permettent simplement de grouper respectivement des éléments et des sous éléments.

Je vais chercher les topic sur le même sujet, encore merci.