Discussion :

[LePoussain]

Bonjour à tous,

actuellement en stage dans une collectivité territoriale dans le cadre d'un BTS SIO, je dois trouver une solution pour que les bons de commande soient émis si le budget alloué à ce type dépense le permet.
Mon (premier) problème concerne le MCD de la base que l'application exploitera. En effet, je dois mémoriser, pour chaque bon de commande émis -ou voulant l'être, le nom de l'agent qui l'édite mais aussi le nom de l'agent responsable du projet.
Je pensais au début à une association réflexive assez simple (0,n/ 0,1), comme on en trouve dans beaucoup de sujets, jusqu'à ce que j'apprenne que cette hiérarchisation n'était valable que pour une action. Un agent sous un autre agent dans un projet peut être simultanément sur ce même autre agent dans un autre projet.
Je n'arrive pas à concevoir si c'est un problème ou pas de laisser l'association réflexive sur l'entité 'Agents' dans ce cas mais n'ai pas encore trouvé d'autres solutions.

Voilà une partie du MCD, il manque cependant l'association réflexive sur l'entité 'Agents'


Avez-vous un avis là-dessus ?
Merci
Poussain

[fsmrel]

Bonsoir Poussain,

Un agent sous un autre agent dans un projet peut être simultanément sur ce même autre agent.

La bête à deux dos alternative ? Ça est scabreux cette histoire, une fois, savez-vous ?



Bref, pourquoi pas un MCD de ce genre ?




Au départ, AFFECTATION est une association, entre AGENT et PROJET, mais comme on ne peut associer l’association EDTION_COMMANDE à cette association, J’ai transformé AFFECTATION en entité-type, avec identification relative à AGENT et PROJET.


Version équivalente avec DB-MAIN (gratuit), qui a sa façon à lui de permettre l’identification relative :

[LePoussain]

Merci beaucoup pour votre réponse que je vais éplucher avec le plus grand intérêt, encore une fois !

[LePoussain]

Il vaut mieux penser à l'héritage avant qu'il ne soit trop tard...
Je crois que ce n'est pas très judicieux d'avoir des tables vides, mais pourquoi pas ?


Enfin plutôt un héritage avec totalité d'ailleurs...

[fsmrel]

Bonsoir Poussain,

Il vaut mieux penser à l'héritage avant qu'il ne soit trop tard...

Selon votre nouveau MCD, un agent est invariablement soit éditeur, soit responsable, indépendamment des projets, ce qui contredit ce que vous aviez précédemment écrit :

Un agent sous un autre agent dans un projet peut être simultanément sur ce même autre agent.

Si le besoin est réel de modéliser la hiérarchie de l’entreprise, alors il faut le faire, mais cette hiérarchie est administrative, elle est indépendante des affectations des agents aux projets. Comme disait le bon vieil Ockham : « Pluralitas non est ponenda sine necessitate », autrement dit, on ne modélise que ce qui doit l’être.


En passant : dans votre MCD, une patte d’association entre COMMANDE et ARTICLE est porteuse d’une cardinalité 1,1 : chaque commande ne concernerait donc qu’un seul article ?

[LePoussain]

Bonjour,

de nouveaux éléments sont venus perturber le modèle élaboré la semaine dernière. Je me vois donc contraint de dé-résoudre cette discussion...

En effet, j'ai appris qu'un budget primitif (BP) est en fait alloué à une action pour chaque article. Ce budget peut être nul.
Du coup, il ne me semble pas nécessaire de mémoriser le BP par article -comme je l'avais fait dans mes premiers MCD, puisqu'on peut le retrouver en additionnant simplement le BP par action par article.
De même, on peut aussi retrouver par le calcul le montant total alloué à une action en additionnant tous les budgets primitifs pour cette action.

Un bon de commande, édité par un seul agent, ne va concerner qu'un article et qu'une action.

Voilà le MCD que j'ai imaginé avec ces nouvelles règles de gestion :


Le contrôleur ne me signale pas d'erreur syntaxique(ni information ni alerte d'ailleurs) mais c'est plus au niveau sémantique que je me fais du souci. Ce MCD respecte-t-il les règles énoncées plus haut, notamment au niveau des cardinalités autour de l'association ALLOCATION? Vais-je bien pouvoir allouer un BP à tous les articles pour toutes les actions de cette façon ?

Merci d'avoir pris le temps de me lire et peut-être de me donner quelques pistes de réflexion !


PS : Quand je parle d'articles, il s'agit d'articles comptables, d'où la cardinalité 1,1 initiale entre COMMANDES ET ARTICLES. Les travaux ou fournitures commandés ne sont pas à mémoriser pour le moment...

[fsmrel]

Bonsoir Poussain,

j'ai appris qu'un budget primitif (BP) est en fait alloué à une action pour chaque article. Ce budget peut être nul.
Du coup, il ne me semble pas nécessaire de mémoriser le BP par article -comme je l'avais fait dans mes premiers MCD, puisqu'on peut le retrouver en additionnant simplement le BP par action par article.
De même, on peut aussi retrouver par le calcul le montant total alloué à une action en additionnant tous les budgets primitifs pour cette action.

L’association ALLOCATION est justifiée et l’attribut budgetPrimitif de l‘entité-type ARTICLE devient de facto redondant puisqu’égal à la somme des budgets primitifs établis par allocation.

Ce MCD respecte-t-il les règles énoncées plus haut, notamment au niveau des cardinalités autour de l'association ALLOCATION? Vais-je bien pouvoir allouer un BP à tous les articles pour toutes les actions de cette façon ?

Si par «Ce budget peut être nul » est à interpréter par absence de budget pour une paire (action, article), le MCD est a priori correct : en effet, si la commande CD1 fait référence à l’action AC1 et à l’article AR1, et que la paire <AC1, AR1> est absente de ALLOCATION, littéralement cela signifie qu’en l’occurrence il y a absence d’allocation.

Attention : Allouer un budget à chaque article se traduit dans le MCD par une cardinalité 1,N portée par la patte connectant ARTICLE et ALLOCATION, alors que la cardinalité que vous prévoyez est 0,N. Exemple : l’article AR1 fait l’objet d’un budget égal à 1500 pour l’action AC5 (peut-être elle seule).

Revenons sur le triplet <CD1, AC1, AR1>. Comme on l’a vu, la paire <AC1, AR1> étant absente de ALLOCATION, cela signifie qu’en l’occurrence il n’y a pas d’allocation. Mais si cette absence d’allocation est la conséquence de l’oubli au niveau de la production de cette paire ? (Notez que j’ai écrit « a priori correct »). Il serait sans doute prudent de dire que chaque paire (action, article) fait l’objet d’une allocation, quitte à ce que celle-ci soit égale à zéro. Dans ces conditions, on blinde le système, en utilisant une contrainte d’inclusion traduisant l’énoncé : si la paire <AC1, AR1> appartient à une occurrence de COMMANDE, alors cette paire doit d’abord appartenir à une occurrence de ALLOCATION. AU niveau MLD, cela se traduira par une clé étrangère {idAction, codeArticle} de la table COMMANDE, référençant la clé primaire {idAction, codeArticle} de la table ALLOCATION (et dans ces conditions, les clés étrangères de la table COMMANDE, référençant les clés primaires des tables ACTION et ARTICLE sont rendues redondantes, donc inutiles, donc à passer au rasoir d’Ockham).

[LePoussain]

Encore une fois, merci !
Ce sont encore des pistes de réflexion très intéressantes que vous m'offrez là!
Il n'y a plus qu'à voir si ça peut faire avec les nouveaux éléments du cahier des charges qui évolue tous les jours...