Violer la sémantique d'un pseudo cycle

**Karly** · 27/05/2012, 23h22

Salut à tous, pour mon mémoire je développe une application android qui utilise une BDD sur un serveur. Un de mes profs se charge de valider nos schéma EA et il m'a juste laissé ce message sur le mien :

« il y a un pseudo-cycle entre information_remainrer/category/subcategory qui permet de violer la sémantique y associée

il faudrait idéalement transformer l’association belongs en entité et brancher information_remainder sur celle-ci »

par rapport à ce schéma la :

en gros je comprend que cette partie la soit un peut bizarre mais je comprend pas quelle relation il veut que ca devienne une table :p le belong entre information_reminder et category oubien le belong entre categorie et sous catégorie ... :S

Le truc c'est que une entité information_reminder doit obligatoirement faire partie d'une catégorie et peut faire partie d'une sous catégorie (qui appartient elle même obligatoirement à une catégorie)... Donc je trouvais que ce que j'avais fai collait :s je sais pas ce que vous en pensez ?

**f-leb** · 28/05/2012, 12h28

Bonjour,

Bon, je n’ai pas bien compris ce qu’a voulu dire ton prof mais d’après ce que tu écris :

une entité information_reminder doit obligatoirement faire partie d'une catégorie et peut faire partie d'une sous catégorie (qui appartient elle même obligatoirement à une catégorie)...

J’en déduis le bout de schéma :

InfoRappel----1,1---appartenir----0,n---Categorie

puis,

Categorie----0,1---EtreSousCategorie----(1,1)---SousCategorie

SousCategorie----1,1---AvoirCategorieParent---0,n---Categorie

Une catégorie peut être une sous-catégorie et dans ce cas a une catégorie parente.

Au niveau MLD :
SousCategorie(#idSousCategorie, #idCategorieParent)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Categorie :
idCategorie	NomCategorie
1		Catégorie 1
2		S/Catégorie 2
3		S/Catégorie 3

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SousCategorie :
idSousCategorie	idCategorieParent
2		1
3		1

Les catégories 2 et 3 sont des sous-catégories de la catégorie 1.

**JPhi33** · 28/05/2012, 15h11

Bonjour Karly et f_leb,

Il n'y a pas de pseudo-cycle dans le schéma. Mon interprétation du problème est différente de celle de Fabien.

Envoyé par Karly

une entité information_reminder doit obligatoirement faire partie d'une catégorie

[INFORMATION_REMINDER]--1,1----(belongs1)----0,n->[CATEGORY]

(comme sur le schéma)

Envoyé par Karly

et peut faire partie d'une sous catégorie

[INFORMATION_REMINDER]--0,1----(belongs2)----0,n->[SUBCATEGORY]

Envoyé par Karly

(qui appartient elle même obligatoirement à une catégorie)

[SUBCATEGORY]--1,1----(belongs3)----0,n->[CATEGORY]

C'est avec le schéma ci-dessus que le pseudo-cycle apparait (Le prof a-t-il donné une réponse stéréotypée ? S'est-il trompé d'élève ? Karly nous a-t-il montré un schéma modifié par rapport à celui qu'il a soumis à son prof ?).
En effet, (Règle de gestion) lorsqu'un INFORMATION_REMINDER appartient à une SUBCATEGORY (belongs2), il faut que cette SUBCATEGORY appartienne à la même CATEGORY (belongs3) que la CATEGORY à laquelle appartient INFORMATION_REMINDER (belongs1).

Exemple
On a les catégories / sous-catégories :
Conception / Données
Conception / Traitements
Programmation / Procédurale
Programmation / Objet

Si IR1 est de catégorie Conception, il ne peut pas appartenir à la sous-catégorie Objet (car Objet n'est pas une sous-catégorie de Conception).

La solution ne consiste pas à transformer une association en entité (ça, c'est du bricolage sémantique) mais à ajouter une contrainte sémantique spécifiant la Règle de gestion ci-dessus. Dans le cas présent, il s'agit d'une contrainte d'inclusion de belongs2 et belongs3 dans belongs1.

**Karly** · 28/05/2012, 15h17

sorry je m'étais trompé d'image :p :S je viens de changer l'image de l' EA c'est la dessus que mon prof avait fait son commentaire et non pas sur l autre :s !

**Karly** · 28/05/2012, 15h34

Envoyé par JPhi33

Bonjour Karly et f_leb,

Il n'y a pas de pseudo-cycle dans le schéma. Mon interprétation du problème est différente de celle de Fabien.

[INFORMATION_REMINDER]--1,1----(belongs1)----0,n->[CATEGORY]

(comme sur le schéma)

[INFORMATION_REMINDER]--0,1----(belongs2)----0,n->[SUBCATEGORY]

[SUBCATEGORY]--1,1----(belongs3)----0,n->[CATEGORY]

C'est avec le schéma ci-dessus que le pseudo-cycle apparait (Le prof a-t-il donné une réponse stéréotypée ? S'est-il trompé d'élève ? Karly nous a-t-il montré un schéma modifié par rapport à celui qu'il a soumis à son prof ?).
En effet, (Règle de gestion) lorsqu'un INFORMATION_REMINDER appartient à une SUBCATEGORY (belongs2), il faut que cette SUBCATEGORY appartienne à la même CATEGORY (belongs3) que la CATEGORY à laquelle appartient INFORMATION_REMINDER (belongs1).

Exemple
On a les catégories / sous-catégories :
Conception / Données
Conception / Traitements
Programmation / Procédurale
Programmation / Objet

Si IF1 est de catégorie Conception, il ne peut pas appartenir à la sous-catégorie Objet (car Objet n'est pas une sous-catégorie de Conception).

La solution ne consiste pas à transformer une association en entité (ça, c'est du bricolage sémantique) mais à ajouter une contrainte sémantique spécifiant la Règle de gestion ci-dessus. Dans le cas présent, il s'agit d'une contrainte d'inclusion de belongs2 et belongs3 dans belongs1.

Oui voila le probleme :-) mais si je comprend bien ce qu'aimerait mon prof c'est de supprimer la relation que tu as défini comme le belongs2 (relation "has" sur mon nouveau schéma) et de plutot relier mon information_reminder sur la relation belongs3 (entre subcategory et categegory) pour en faire une ternaire reliant les 3 tables et donc une fois en relationnel possèdant les 3 clé étrangères ... Si c'est ce que mon prof a voulu dire je trouve que ca tient la route non ? en quoi ce serait du bricolage ?

**f-leb** · 28/05/2012, 15h37

Envoyé par Karly

sorry je m'étais trompé d'image :p :S...

Envoyé par JPhi33

Karly nous a-t-il montré un schéma modifié par rapport à celui qu'il a soumis à son prof ?

Tu veux dire que tu t'étais rendu compte que Karly avait mis en ligne le mauvais schéma avant qu'il ne modifie son message ?

**JPhi33** · 28/05/2012, 15h37

Et bien c'est exactement le même schéma que celui que j'ai réalisé. Donc la solution que j'indique reste valable.

**JPhi33** · 28/05/2012, 15h39

Envoyé par f-leb

Tu veux dire que tu t'étais rendu compte que Karly avait mis en ligne le mauvais schéma avant qu'il ne modifie son message ?

C'était l'une des 3 hypothèses, oui

**Karly** · 28/05/2012, 16h26

Voila si j'ai bien compris la version de mon prof :

Mais ca a l air de déranger le fait que une sous catégorie appartient d office à une catégorie et niveau relationnel ca me parait un peu bizarre cette ternaire :S

**CinePhil** · 28/05/2012, 18h17

Je vois plus simple...

Règle de gestion :
Une categorie peut avoir une catégorie parente (c'est donc une sous-catégorie) et une catégorie peut être parente de plusieurs catégories.

MCD :
categorie -0,1----avoir_parent
|---------------0,n--------|

Tables :
categorie (cat_id, cat_nom...)
sous_categorie (sct_id_categorie, sct_id_categorie_parente)

Règle de gestion :
Une information appartient à une seule catégorie et une catégorie peut avoir plusieurs informations.

MCD :
information -1,1----appartenir----0,n- categorie

Tables :
information (inf_id, inf_idcategorie, inf_contenu...)

Ainsi, la catégorie à laquelle est rattaché l'information est :
- soit une catégorie simple qui n'est pas référencée dans la table sous-catégorie ;
- soit une sous-catégorie qui est référencée dans la clé primaire de la table sous-categorie ;
- soit une catégorie parente qui est référencée dans la seconde clé étrangère de la table sous-catégorie.

**Karly** · 28/05/2012, 20h02

Envoyé par CinePhil

Je vois plus simple...

Règle de gestion :
Une categorie peut avoir une catégorie parente (c'est donc une sous-catégorie) et une catégorie peut être parente de plusieurs catégories.

MCD :
categorie -0,1----avoir_parent
|---------------0,n--------|

Tables :
categorie (cat_id, cat_nom...)
sous_categorie (sct_id_categorie, sct_id_categorie_parente)

Règle de gestion :
Une information appartient à une seule catégorie et une catégorie peut avoir plusieurs informations.

MCD :
information -1,1----appartenir----0,n- categorie

Tables :
information (inf_id, inf_idcategorie, inf_contenu...)

Ainsi, la catégorie à laquelle est rattaché l'information est :
- soit une catégorie simple qui n'est pas référencée dans la table sous-catégorie ;
- soit une sous-catégorie qui est référencée dans la clé primaire de la table sous-categorie ;
- soit une catégorie parente qui est référencée dans la seconde clé étrangère de la table sous-catégorie.

Oulala je m embrouille un peu ... Est ce que tu veux dire que la table catégorie est récursif sur elle meme dans le genre

CATEG----(0-1)------avoir_parent-----(0-n)-------CATEG

Ca ca me parait pas mal et j'y avais pas pensé ! ce qui fait que si une information a comme catégorie (venant de la relation info--(1-1)--belongs--(0-n)--categ) une sous-catégorie on peut aisément retrouver si cette catégorie a bien un parent, lequel et donc qu'il sagit bien d'une sous categ ! ;-) C'est ca que tu voulais dire CinePhil ??