Version imprimable
Bonjour.
Voici ce que j'essaie de transcrire dans ma bd :
http://o2reu.free.fr/a/composite.png
Et voici mon schéma relationnel :
Element(id_elem);
Article(#id_elem, titre,...);
Categorie(#id_elem => id_cat, nom...);
elem_cat(#id_elem, #id_cat, ordre...);
Je veux éviter d'avoir une table qui ne contient qu'un seul champ.
Des idées pour améliorer ça tout en restant souple ?
Pour etre sur de comprendre; qu'as tu represente? agregation ou composition? Tu parles de composition alors que tu representes une agregation.
Sinon ta relation heritage/agregation (ou composition) me paraitrait plus que bizarre
Oui en regardant de plus près, j'ai du confondre le losange plein (composition ?) et le losange creux (agrégation ?)
C'est le design pattern composite que j'ai essayé de faire.
S'il n'existe pas d'élément qui ne soit Article ou Catégorie, la table Element n'a pas lieu d'exister.Citation:
Envoyé par hpavavar
Il essaie de faire cela : http://www.dofactory.com/Patterns/PatternComposite.aspx .
Perso, j'utilise une base de données objets (db4o), donc je ne me pose pas la question du mappage. Mais la réponse m'interesse, je suis curieux de voir comment on stocke de manière efficace des objets composites dans une base relationnelle.
Hmm il faudra que j'aille réviser les schémas de bases de données, j'ai du mal à interpréter le tien...
Il y a 2 tables, ou ce sont des lignes d'une même tables ?
2 tables, prends comme exemple Composite : Immeuble et Composant : Appartement.
Je ne suis pas sûr de comprendre. Immeuble et appartement ne me semblent pas des exemples de design pattern Composite. Pour qu'ils le soient, il faudrait des appartements qui contiennent des immeubles.
Voici un exemple de composite, tiré de l’excellent livre Head First sur les design patterns.
http://img47.imageshack.us/img47/767...siteew6.th.jpg
Ce sont des ingrédients de recettes de cuisine. Il y a des ingrédients de base (deux sont représentés ici, la farine et le sel). Mais tu peux aussi avoir des ingrédients qui ont été préparés avant, par exemple une sauce vinaigrette. Cet ingrédient sera de la classe IngredientComposite, il contient une liste d’ingrédients, qui eux-mêmes peuvent être simples ou composites. C’est typiquement le genre de structure que l’on explore dans un TreeView.
Donc, si je te comprends bien, il y aurait deux tables, une pour les ingrédients simples et l’autre pour les composites ? Et je me pose une autre question, comment est représenté l’héritage, dans ce cas-là ?
Je veux dire qu'un immeuble contient des appartements. Quand un immeuble disparaît, les apparts aussi doivent être détruits.Citation:
Envoyé par Promeneur
Pour l'héritage, plusieurs modèles relationnels peuvent être mis en oeuvre. Cela dépendra des propriétés contenues dans les classes et de l'existence d'objets dans les différents niveaux.Citation:
Envoyé par Promeneur
Dans ton exemple, il manque les multiplicités mais on pourrait imaginer les relations suivantes si on considère qu'un ingrédient peut être mélangé à d'autres :
Ingredient(id, ...)
Farine(id#,...)
Sel(id#,...)
IngredientComposite(id1#,id2#)
J'ai l'impression que tu confonds "composition" et design pattern Objet Composite. Regarde les liens donnés, tu verras que c'est plus compliqué à gérer dans une base de données qu'une composition.Citation:
Envoyé par Soutou
Dans l'exemple cité en URL, je pense qu'on peut mettre en oeuvre le modèle relationnel :
Client(numcli, ...)
Component(id,... numcli#)
Composite(id#, idcomponent#...)
Leaf(id#, ...)
idcomponent référençeant le composite (père) d'un composant donné.
Hmm à priori il ne devrait pas y avoir de table Component, non ? Et un composite peut être référencé par un composite. Donc, tu aurais 3 tables, Client, composite et leaf ?Citation:
Envoyé par Soutou
En reprenant l'exemple de la recette, pour la recette du gabloufis aux niorks, on aurait (je parle en objets, pas en tables)
une liste list<ingredient> qui contientrait les ingrédients suivants :
- Farine
- sel
- Niork (composite contenant une list<ingredient>) :
-------sucre
-------frambroise
-------lait
-------Sauce royale (composite contenant une list<ingredient>) :
-----------eau
-----------sel
-----------jus de poisson fermenté
- levain
Comme tu le vois, un comoosite contient une collection d'élements qui descendent du type abstrait ingrédeients et qui sont soit des leafs (comme sel ou levain) soit des composites (comme niork ou sauce royale).
ah, bon appétit :D ...
C'est une structure hiérarchique qui n'est pas facile à manipuler avec SQL.
Pour la recette du gabloufis aux niorks
Component(id,... numcli#)
Farine,...
sel,...
Niork ,...
Sauce royale ,...
levain,...
Composite(id#, idcomponent#...)
sucre , Niork
frambroise, Niork
lait, Niork
Sauce royale , Niork
eau, Sauce royale
sel, Sauce royale
jus de poisson fermenté, Sauce royale
Sens-tu l'odeur du plat là?
heu, je n'ai pas faim, là...
Donc 2 tables, une pour les ingrédients et une pour les ingrédients de composite, si je comprends bien, ou tout cela dans la meme table ?
Au final voici ce que j'ai fais :
Element:
id_elem pk
id_article rk
id_cat rk
(avec comme contrainte : une seule des clé externe doit être non nulle)
Article:
id_article pk
titre....
Categorie:
id_cat pk
nom categorie...
Elem_Cat:
id_elem rk
id_cat rk
(id_elem, id_cat) PK
Ca marche assez bien ! J'ai toute la souplesse que je voulais: Ajouter un nouvelle entité qui hérite d'élément revient à créer une colonne dans la table élément.
L'élément racine d'elem_cat est trouvable en cherchant la ligne d'elem_cat qui contient en même temps un id_cat et son id_elem correspondant.
(Je me suis imposé de ne créer qu'une seule racine)
Au niveau performance j'ai un soucis : lorsque je veux à partir d'un element, trouver sa catégorie mère, puis la grand-mère, puis... jusqu'a la racine.
Ca m'oblige a faire une requête par niveau.
"Ajouter une nouvelle entité", c'est ajouter une nouvelle classe dans le modèle objet, pas une nouvelle donnée ?Citation:
Envoyé par hpavavar
Oui je l'entend sous le sens ajouter une nouvelle classe