Discussion :

[billyrose]

Bonjour a tous,

Je souhaiterais creer une base de donnes mais j'ai des problemes pour la modeliser.
voila j'ai une table items (item_id,item_name,item_description) , mais je ne sais pas comment representer le fait qu'un item peut dependre (si j'ai l'item A, je dois aussi avoir l'item B ou alors je ne dois pas avoir l'item C) de plusieurs autres items, sachant que tous les items sont dans la table items.

Comment puis je changer la structure de ma table pour tenir compte de ces dependences ou alors dois je creer une autre table?

Merci a tous pour votre aide.

Billyrose

[Sekigawa]

Salut,

Bah tu sais dans une table un enregistrement peut dépendre d'un autre genre

On a une table personne et on sait qu'une personne peut etre marié à une autre on aura par exemple Personne(id_pers, nom_pers..., id_conjoint)

Où id_conjoint ne sera finalement qu'une autre personne

Aprés si un item peut dependre de plusieurs autres item il te faudra une table intermédiare ou table association genre

itemsByItems(id_item1, id_item2)

Qui reprendra toutes les dépendances...

Ai-je répondu à ta question ??

[billyrose]

Je pense que la table association ItemByItem est une bonne idee. cette table association ItemByItem fera seulement reference a la table items?

id_item1 et id_item2 sont tous les deux lies a id_item de la table items?

Merci de ton aide

Billy

[Sekigawa]

Oui en faites u représenter ça comme le dessin que je t'ai fait

Vu que les cardinalités mini sont à 0 un item n'est pas nécessairement relié à 1 ou plusieurs items.

Après à toi de gérer le truc

[billyrose]

je pense que les cardinalites minimales devraient etre a 1. les champs de itembyitem seront en juste item_id, item_id_dep. peut etre est ce que je le concois mal mais voila ce que je voyais (j'ai fait un bref schema pour simplifier):

[f-leb]

bjour,

donc une entité "item" en association avec elle-même.

Comment puis je changer la structure de ma table pour tenir compte de ces dependences ou alors dois je creer une autre table?

ben ça dépend. imagine que tes "items" soient des personnes.

Une personne (dans le rôle de parent) peut avoir plusieurs personnes (dans le rôle d'enfant)
Une personne (dans le rôle d'enfant) peut avoir plusieurs personnes (dans le rôle de parent, ouais je sais deux parents en général, mais elle a quand même pas fait un bébé toute seule non plus)
donc au niveau du MCD, une asso plusieurs-plusieurs et une table de plus lors du passage au MLD.

une personne (dans le rôle de chef) peut avoir plusieurs personnes (dans le rôle de larbin)
une personne (dans le rôle de larbin) peut avoir au maximum une personne (dans le rôle de chef)
donc au niveau du MCD, une asso un-plusieurs.

donc dans ton cas tout dépend des rôles joués par tes "items" et des cardinalités maxi de l'association entre ces items.

allez, dis nous c'est quoi ces items?

[Sekigawa]

je pense que les cardinalites minimales devraient etre a 1. les champs de itembyitem seront en juste item_id, item_id_dep. peut etre est ce que je le concois mal mais voila ce que je voyais (j'ai fait un bref schéma pour simplifier):

Bah au niveau des cardinalités ça dépend de ce que tu veux faire, si un item est obligatoirement dépend d'au moins un autre item alors la minimale sera à 1 bien sûr.
Par contre si un item peut n'être dépendant d'aucun item alors elle sera à 0...

ça dépend de ce que tu veux faire aprés...

Ensuite je te montre un mini mcd juste pour que tu visualise ce que je veux te dire, c'est à dite que "itemByItems" est une table association dans le schéma, quand tu fera ta base ta bdd elle deviendra une table à part entière ^^

[CinePhil]

Autre possibilité si des items peuvent être associés à d'autres items qui eux-même peuvent être associés à d'autres items qui... et qu'il faut parfois remonter toute la famille : la modélisation arborescente par représentation intervallaire.

[billyrose]

bjour,

donc une entité "item" en association avec elle-même.



ben ça dépend. imagine que tes "items" soient des personnes.

Une personne (dans le rôle de parent) peut avoir plusieurs personnes (dans le rôle d'enfant)
Une personne (dans le rôle d'enfant) peut avoir plusieurs personnes (dans le rôle de parent, ouais je sais deux parents en général, mais elle a quand même pas fait un bébé toute seule non plus)
donc au niveau du MCD, une asso plusieurs-plusieurs et une table de plus lors du passage au MLD.

une personne (dans le rôle de chef) peut avoir plusieurs personnes (dans le rôle de larbin)
une personne (dans le rôle de larbin) peut avoir au maximum une personne (dans le rôle de chef)
donc au niveau du MCD, une asso un-plusieurs.

donc dans ton cas tout dépend des rôles joués par tes "items" et des cardinalités maxi de l'association entre ces items.

allez, dis nous c'est quoi ces items?

En fait ces items sont juste une aggregation des fonctionalites d'un logiciel.

[billyrose]

Bonjour a tous,
je vous remercie de vos reponses.

Comme je le disais ces items sont une aggregation des fonctionalites d'un logiciel, et de ce fait parfois pour avoir un item donne disons A par exemple, il faut d'abord avoir un autre item B et ca arrive mm que parfois il ne faut pas avoir l'item C.

[billyrose]

Autre possibilité si des items peuvent être associés à d'autres items qui eux-même peuvent être associés à d'autres items qui... et qu'il faut parfois remonter toute la famille : la modélisation arborescente par représentation intervallaire.

c'est vrai que d'un un item A depend d'un item B qui lui meme depend d'un item D mais je me dis que au niveau de la modelisation je m'arrete au niveau le plus proche ie A depend de B puisque de toute facon B depend de D se retrouvera aussi. en fait je veux eviter la modelisation en arborescence.

[JPhi33]

Bonjour billyrose,

Le représentation proposée par Sekigawa accompagnée des explications de f-leb et la représentation intervallaire suggérée par CinePhil sont des solutions acceptables et adaptées à ton cas.

Tu n'a plus qu'à faire ton choix !


JPhi33