Discussion :

[CinePhil]

Bonjour,
Si deux entités ont les mêmes attributs et une association similaire avec une troisième entité mais que seule les cardinalités de cette association change, doit-on faire un héritage ?

Cas concret :
1) Association Planète - Joueur
Une planète ne peut appartenir qu'à un seul joueur.
Un joueur peut posséder plusieurs planètes.
Planète -0,1----Appartenir----0,n- Joueur

2) Entité Flotte
Une flotte appartient à un seul joueur.
Un joueur ne peut posséder qu'une flotte.
Flotte -1,1----Appartenir----0,1- Joueur

Dans les deux cas, les attributs de Planète et Flotte sont :
- Identifiant
- Nom
- Coordonnée X
- Coordonnée Y
- Puissance
- Date-Heure info

Pourrais-je regrouper ces deux entités en une seule, Objet Spatial, et faire un héritage pour spécifier mes deux associations légèrement différentes ?

J'aurais alors les tables :
Joueurs(J_Id, J_Nom, ...)
ObjetsSpatiaux(OS_Id, OS_Nom, OS_CoordX, OS_CoordY, OS_Puissance, OS_DateInfo)
Planetes(P_IdObjetSpatial, P_IdJoueur)
Flottes(F_IdObjetSpatial, F_IdJoueur)

On voit ci-dessus que Planetes et Flottes ont les mêmes colonnes, ce qui peut sembler bizarre pour un héritage.

Qu'en pensez-vous ?

[chaplin]

Faire cette démarche suppose qu'il y a des ObjetsSpatiaux sans être ni une planète ni une flotte. Si on rajoute la clause, soit planète soit flotte et rien d'autre, il s'agit d'une contrainte de partition d'exclusion, alors l'entité ObjetsSpaciaux est abstraite.

Si on va au fond du raisonnement, ça ne sert à rien de créer une table si on y stocke aucune information dans la mesure ou elle est stocké parmis les entités descendantes.

[CinePhil]

Au contraire, dans le modèle que j'ai décrit ci-dessus, je stocke l'essentiel des infos dans la table ObjetSpatiaux et les tables filles ne contiennent que l'identifiant du joueur avec une cardinalité différente.

[chaplin]

Je parle de la théorie, en pratique, je suis tenté de suivre cette démarche.

Il y a une autre solution qui s'appelle la décomposition ascendante qui consiste a mettre tous les attributs (Planète et Flotte) dans la même table.
Chacun fait comme il veut.

[CinePhil]

Dans la pratique, je pense que je vais devoir ajouter des attributs différents pour les flottes (coût, énergie, population requise...) et les planètes (type de planète) donc je vais adopter l'héritage je pense.
Mais le cas d'école était intéressant à examiner je pense.

Merci pour les réponses.

[chaplin]

Je pense qu'il faut voir l'héritage par rapport à une approche objet en liaison avec UML, car c'est un concept très fort, donc il faut bien avoir conscience de son utilisation pas juste de se contenter de factoriser des attributs communs à des tables.

Faire une requêtre sur une table, ou faire une jointure sur deux tables, à l'usage, c'est discutable. A ce niveau, la théorie permet quand même de mettre en garde sur certaine pratique à priori "simplificatrice".

[wazup]

Je pense que cet héritage est correct.

Il faut adopter cette stratégie d'autant plus, concernant les informations des entités, et en cas d'évolution du modèle, que d'autres informations spécifiques à chaque sous-type risquent d'apparaitre :

par exemple,
natureAtmosphere pour une planète,
nombreVaisseaux pour une flotte,....

on a intérêt à avoir déjà des sous-types différentiés.

Quant à la similitude des informations de planète et flotte, c'est normal puisqu'on a ici qu'un identifiant et une clé étrangère...

Mais, si ça évolue, le modèle est déjà prêt.

Enfin, quant à la remarque de chaplin sur les jointures dans les requêtes, je répondrai qu'il s'agit ici d'un modèle CONCEPTUEL, ce qui n'empêche pas de dénormaliser au niveau modele physique et de faire alors des raccourcis de requête.

Ce qui compte avant tout en conceptualisation, c'est de refleter la REALITE du systeme, les considerations de lourdeur ou de performance se faisant à l'implementation (MPD).

Ceci évidemment peut paraitre superflu sur un tel modèle "d'école", mais sur des modèles de l'ordre de la centaine d'entités, ceci révèle son efficacité.

[chaplin]

En cherchant un peu dans la Merise, on y trouve tous les cas de figures:

http://merise.developpez.com/faq/?pa...LD_MCDSousType