Discussion :

[cfried]

Bonjour, je voudrais vous soumettre mon MCD pour avoir vos remarques et vos conseils.

Il représente la gestion de l'organigramme d'une communauté d'agglomération.
Chaque service est dirigé par un employé.
Les services peuvent être regroupés (ou rapprochés) sous la direction d'un superviseur (c'est pour ça que j'ai créé l'entité Groupe de service).

Info : La propriété "dirige" de l'association "est_de" est de type booléen :
* 1 si l'employé dirige le service
* 0 sinon

Merci de m'indiquer mes erreurs

[SmileSoft]

salut,

Les services peuvent être regroupés (ou rapprochés) sous la direction d'un superviseur (c'est pour ça que j'ai créé l'entité Groupe de service).

je devine qu'un groupe de service est supervisé par 1 et 1 seul employé, donc la cardinalité de l'association supervise du coté Groupe_Service doit être 1.1

on ne peut pas avoir un service avec 0 employé, donc la cardinalité de l'association est_dans (coté service) doit changer en 1.n

[cfried]

je devine qu'un groupe de service est supervisé par 1 et 1 seul employé, donc la cardinalité de l'association supervise du coté Groupe_Service doit être 1.1

il y a des cas dans lesquels il y a deux superviseurs, un pour la partie compta, un pour la partie informatique (je dis n'importe quoi hein). Je me suis mal exprimé en laissant penser qu'il ne pouvait y en avoir qu'un.

on ne peut pas avoir un service avec 0 employé, donc la cardinalité de l'association est_dans (coté service) doit changer en 1.n

C'est pas faux

Sinon concernant la propriété "dirige" de l'association "est_dans" j'ai lu qu'on ne pouvait pas mettre de propriété à une association dont les cardinalités sont 1,1 - 0,n : Info/Intox ? ! Si OUI pourquoi ?

[SmileSoft]

Sinon concernant la propriété "dirige" de l'association "est_dans" j'ai lu qu'on ne pouvait pas mettre de propriété à une association dont les cardinalités sont 1,1 - 0,n : Info/Intox ?

oui c'est vrai et cette propriété dois figurer comme attribut dans l'entité fils donc dans personnel.

! Si OUI pourquoi ?

la réponse dans la fac

[JPhi33]

Bonjour cfried,

Ton MCD peut être amélioré de manière à le rendre plus sémantique et à faciliter la gestion de la base de données qui en sera issue.

Chaque service est dirigé par un employé.
[...]
Info : La propriété "dirige" de l'association "est_de" est de type booléen :
* 1 si l'employé dirige le service
* 0 sinon

D'accord mais chaque employé ne dirige pas un service. Et la solution ne se trouve pas avec la propriété booléenne dirige dans l'association est_dans.

En préambule, comme l'a souligné SmileSoft, la présence de cette propriété dans une association de ce type (c'est-à-dire 1,1 - 0,n) est une anomalie de conception. Lors de la dérivation du MCD en MLD, elle va "migrer" dans la table issue de l'entité côté cardinalité 1,1, donc dans la table issue de personnel. Autant l'inclure, dès le MCD, dans l'entité personnel.

Quoi qu'il en soit, on pourrait s'en contenter car la propriété dirige, faisant partie de la l'entité personnel, permet de distinguer un personnel dirigeant d'un personnel qui ne l'est pas.

Cette approche comporte un inconvénient : elle restreint l'évolutivité du modèle. En effet, imaginons que l'on souhaite, plus tard, ajouter des propriétés spécifiques aux dirigeants de services (date de prise en charge du service, niveau d'accréditation sécurité, etc.) Chaque personnel se trouvera alors affublé de ces informations, alors qu'elles ne concernent qu'une (petite) partie d'entre eux : les dirigeants de services ; avec la conséquence fâcheuse pour la base de données de recevoir la valeur Null pour chaque personnel non dirigeant.


La solution plus sémantique et facilitant la gestion de la base de données consiste à spécialiser l'entité personnel en une "sous-entité", dirigeant par exemple. Ce qui donnerait ceci :

[ dirigeant ]===>[ personnel ]

qui se lit : un dirigeant est un personnel (mais l'inverse n'est pas vrai).

Le mécanisme d'héritage permet à dirigeant d'avoir les mêmes propriétés que personnel.


Cette partie du modèle devient :

[ personnel ]--1,1----( est_dans )----1,n->[ service ]

[ dirigeant ]--1,1----( dirige )----1,1--[ service ]


Attention : il faudra choisir le sens d'orientation de l'association dirige afin de déterminer quelle table du MLD contient l'identifiant de l'autre table en clé étrangère.

Les services peuvent être regroupés (ou rapprochés) sous la direction d'un superviseur (c'est pour ça que j'ai créé l'entité Groupe de service).

On pourra vérifier la pertinence d'une spécialisation en entité superviseur.


JPhi33

[cfried]

Tout d'abord, merci à tous pour vos réponses !

J'ai bien pris en compte la remarque concernant la propriété d'une association de cardinalité 1,1 - 0,n : j'ai modifié mon modèle en conséquence.

La solution plus sémantique et facilitant la gestion de la base de données consiste à spécialiser l'entité personnel en une "sous-entité", dirigeant par exemple. Ce qui donnerait ceci :

[ dirigeant ]===>[ personnel ]

qui se lit : un dirigeant est un personnel (mais l'inverse n'est pas vrai).

Le mécanisme d'héritage permet à dirigeant d'avoir les mêmes propriétés que personnel.

Cette partie du modèle devient :

[ personnel ]--1,1----( est_dans )----1,n->[ service ]

[ dirigeant ]--1,1----( dirige )----1,1--[ service ]


Attention : il faudra choisir le sens d'orientation de l'association dirige afin de déterminer quelle table du MLD contient l'identifiant de l'autre table en clé étrangère.

J'ai effectué cette solution plus sémantique car la possibilité d'évolution de l'application est une des contraintes au cahier des charges. Corrigez moi si il y a encore des erreurs. Au niveau des cardinalités, il ne faut pas s'inquiéter pour le 1,n de l'association dirige du coté de l'entité service : il y a des cas de co-direction (pareil pour les co-supervisions).

On pourra vérifier la pertinence d'une spécialisation en entité superviseur.

Je me demandais si il était possible de passer cette notion de superviseur par l'entité fraichement créée de dirigeant mais je bloque au niveau des cardinalités sur cette solution ? !

Merci chaudement pour vos éclairages avisés !

[cfried]

Bonjour, après m'être mis au travail de développement je me suis rendu compte que l'entité groupe_services m'était inutile et surtout qu'elle m'obligeait à mettre en place de nombreux traitements car elle était également récursive avec une auto-association.

J'ai repris mon mcd, en créant juste une entité type.
ATTENTION : j'ai une version d'essais de Win'Design : je n'ai donc pas eu le courage de recommencer mon MCD à chaque erreur ^^
Celui-ci est celui qui s'en approche le plus, les erreurs que j'ai corrigé sont :

• cardinalités de l'association père/fils depend_de : 0,n - 0,n au lieu de 0,1 - 0,n
• 1,1 coté service pour l'association de_type au lieu de 0,n

Si il y a des erreurs dans ma correction (et c'est possible !!), merci de me tenir au courant

A+ et merci pour votre expertise :p

[JPhi33]

Bonjour cfried,

les erreurs que j'ai corrigé sont :

• cardinalités de l'association père/fils depend_de : 0,n - 0,n au lieu de 0,1 - 0,n

On est donc dans le cas une organisation non hiérarchique : un service S peut dépendre de plusieurs services (a, b et c, par exemple) et plusieurs services (x, y et z, par exemple) peuvent dépendre de S. Avec, en outre, la possibilité qu'un ou plusieurs des services a, b, c dépendent d'un ou plusieurs des services x, y, z ou inversement.

Habituellement, les organisations en services des entreprises sont plutôt pyramidales : 0 ou 1 père, 0 à n fils.
C'est donc une organisation un peu atypique (mais pourquoi pas).


Bon courage pour le développement !

[cfried]

Bonjour cfried,


On est donc dans le cas une organisation non hiérarchique : un service S peut dépendre de plusieurs services (a, b et c, par exemple) et plusieurs services (x, y et z, par exemple) peuvent dépendre de S. Avec, en outre, la possibilité qu'un ou plusieurs des services a, b, c dépendent d'un ou plusieurs des services x, y, z ou inversement.

Habituellement, les organisations en services des entreprises sont plutôt pyramidales : 0 ou 1 père, 0 à n fils.
C'est donc une organisation un peu atypique (mais pourquoi pas).


Bon courage pour le développement !

Oui on peut dire que c'est atypique, c'est une communauté de communes

Merci pour ton aide en tout cas

Je vous tiendrai au courant de mon application, là je vais un peu squatter le forum Dojo je pense :p ^^

A+ pour d'autres modélisations, avec plaisir