Discussion :

[woshou]

Bonjour à tous ,

J'ai le problème suivant à résoudre via un diagramme de classe



Voici ma résolution :



Le corrigé que j'ai n'utilise pas de composition , est-ce que vous pensez que ma résolution est valide?

Bien à vous,

[bruno_pages]

Bonjour,

Si la destruction d'une agence entrainait la destruction des comptes qui y sont gérés cela voudrait dire que les clients associés à ces comptes perdrait leur argent, j'ose espéré que cela n'est pas le cas

En cas de fermeture d'une agence les comptes qui y étaient gérés sont donc préalablement transférés dans une autre agence => lors de la fermeture d'une l'agence celle-ci ne gère plus de compte => la composition entre agence et compte ne sert à rien et donc autant ne pas l'avoir.

Dans le cas ou la banque centre disparait purement et simplement il peut en être de même pour les agences, mais dans le cas où la banque est rachetée par une autre banque (ou les deux fusionnent, etc, peut importe) la banque centrale initiale disparait mais les agences peuvent toujours exister et être attachées à la nouvelle entité => pas de composition

Je ne mettrais pas les multiplicités à 1..* mais à * : une agence existe avant d'avoir des clients, et une banque existe avant d'avoir des agences

[escartefigue]

Bonjour,

Une banque ou une agence ne disparaissent pas, elles sont fusionnées avec une autre banque ou une autre agence.
Le compte du client n'est donc pas en péril.
Il faut donc, comme toujours en matière de modélisation, choisir un identifiant de banque et un identifiant d'agence non fonctionnels pour en garantir la stabilité
Ainsi, le modèle proposé par Woshou est valide sous réserve de ne pas utiliser le code banque et le code guichet comme clefs primaires. Ces codes pourront être utilisés comme clefs alternatives, mais surtout pas primaires.
En cas de fusion, on renumérotera simplement ces codes et l'opération sera indolore (pas d'effet cascade lié à l'intégrité)

Pour rappel, le RIB est composé du code banque (5)+code guichet ou agence (5)+numéro de compte (11)+clef RIB(2)
Du coup, si l'on souhaite que le RIB du client soit stable, même en cas de fusion d'agence ou de banque, alors on stockera celui-ci au niveau du compte et le tour est joué.

Ce qui donne



Dans ce modèle,

• BQ_ident, AG_ident et CT_ident sont des identifiants techniques attribués par le SGBD, il sont asémantiques et donc stables et de type integer et donc concis et performants
• BQ_code est le code banque, AG_code est le code guichet (ou code agence) et CT_numero est le numéro de compte. Ces 3 attributs ont un sens fonctionnel et peuvent donc changer à tout moment. Ils sont de type char, car il ne feront l'objet d'aucun calcul et dépendent d'une nomenclature externe qui peut changer à tout moment (et éventuellement contenir des caractères alpha).
• AG_code n'est pas unique en soi, il n'est unique que pour un code banque BQ_banque
• même remarque concernant CT_numero qui n'est unique que pour un code banque et un code guichet