Discussion :

[Betanaelle]

Bonjour,

Suite à mon précédent passage sur le forum j'ai continué la modélisation de ma BDD.

J'ai ajouté plusieurs tables à celle que vous aviez pu découvrir. Voici donc les explications sur ces tables et mes questions.
Les bâtiments qui sont créés ne poussent pas par magie, ils le sont dans des villes bien sur, pour respecter le RP du jeu j'ai choisi de le nommer Camp
camp 0,n -- construire -- 1,1 batiment
1 batiment est obligatoirement construit dans une ville
dans une ville il peut y a voir 0 ou plusieurs bâtiment, jusque là ça va.
Un camp est créé sur une seule case, sur une case il ne peut y avoir qu'un camp
camp 1,1 -- créer -- 0,1 case

Les personnages peuvent s'associer en créant un groupe, en pratique c'est un perso qui crée un groupe et qui en devient le chef et qui peut prendre d'autre perso dans le groupe. J'en ai déduit les relations suivantes.
perso 0,1 -- créer -- 1,1 groupe
perso 0,1 -- composer -- 1,n groupe

Comme Cinephil me l'a apprit j'ai une relation d'héritage entre perso et groupe, ce qui me semble logique et entre case et camp, ce qui l'est aussi.

Il y a plusieurs interactions possibles avec ces 3 tables suivant le RolePlay et Gameplay du jeu.

D'abord pour ce qui concerne l'habitation dans un camp :
- un camp est créé par un perso qui en devient de facto le chef
- le chef à certaine possibilité sur son camp, il peut gérer les entrées et sorties (la sécurité), il peut construire des bâtiments (c'est un architecte), il gère les stocks dans les bâtiments (c'est un comptable)
- dans un camp il peut y avoir 0 ou plusieurs perso
- dans un camp il peut donc y avoir 0 ou plusieurs groupe
- le chef peut donner son titre à un autre perso
- le chef peut donner et reprendre une de ses trois attributions à un ou plusieurs autres persos. Là je bloque, je ne vois pas comment on peut savoir qui possède ces droits.
perso 0,1 -- habiter -- 0,n camp
groupe 0,1 -- habiter -- 0,n camp
perso 0,1 -- diriger -- 0,1 camp 1 ou n, car s'il y a un chef, il y a la possibilité que 3 autres persos est des droits sur le camp ! J'ai ajouté à l'association diriger 4 attributs chef, sécurité, architecte et comptable en booléen ! ! C'est vraiment ici que je bloque.

Pour le commerce :
- Un perso peut commercer avec des persos ou avec un camp (via son comptable), un camp ne peut commercer qu'avec des persos.
- Un perso ne peut commercer que sur la case où il se trouve
Le commerce c'est donc s'échanger des objets
perso 0,n -- commercer -- 0,n perso
perso 0,1 -- commercer -- 0,n camp

Pour le combat :
- un perso peut attaquer, 1 autre perso, 1 groupe ou 1 camp
- un groupe peut attaquer, 1 perso, 1 groupe ou 1 camp
- un camp peut attaquer 1 perso ou 1 groupe
- il n'y a qu'une attaque possible par tour
perso 0,1 -- attaquer -- 0,1 perso
perso 0,1 -- attaquer -- 0,1 groupe
perso 0,1 -- attaquer -- 0,1 camp
groupe 0,1 -- attaquer -- 0,1 groupe
groupe 0,1 -- attaquer -- 0,1 camp

Pour l'envoi de message :
- un perso peut envoyer 0 ou plusieurs messages à un perso, un groupe ou un camp
- un groupe et un camp ne peuvent pas envoyer de message
- un perso, un groupe et un camp peuvent recevoir 0 ou plusieurs messages
- les messages reçus doivent disparaitre au bout de 48heures, sauf s'ils ont été archivé.
- il n'y aura pas de copie des messages envoyés.
perso 0,n -- envoyer -- 0,n message
message 0,n -- réception -- 0,n perso
message 0,n -- réception -- 0,n groupe
message 0,n -- réception -- 0.n camp

Vous trouverez la relation qui me bloque en PJ, pour les autres je n'ai pas à priori de soucis, sauf si vous en voyez un bien sur.

S'il manque des renseignements ou une image de tout ça, je vous le ferai parvenir.

[JPhi33]

Bonsoir Betanaelle,

Je pense qu'il serait plus simple de considérer qu'un camp est administré au moyen de 3 attributions, lesquelles sont exercées par un ou plusieurs persos. Ce qui donnerait, traduit en MCD :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
    [ Camp ]--1,1----------( a pour chef )----------------+
        |                                                 |
       0,n                                               0,1
        |                                                 |
        |                                                 v
( Administration )--1,1----( est exercé par )----0,n->[ Perso ]
        |
        |
       0,n
        |
 [ Attribution ]

On peut aussi considérer que "Chef" est une attribution auquel cas, la table Attribution est enrichie du rôle de chef et l'association "a pour chef" disparait.


Au niveau tabulaire, nous obtenons :

Camp(id_camp, ..., #id_perso) c'est l'id_perso du chef
Attribution(id_attribution, nom_attribution)
Administration(#id_camp, #id_attribution, #id_perso)

La table Attribution contiendrait
1, sécu
2, archi
3, compta


Exemples
1. Le camp Betan a pour chef Betanaelle, qui a conservé ses 3 attributions :

Table Camp
Betan, ..., Betanaelle

Table Administration
Betan, sécu, Betanaelle
Betan, archi, Betanaelle
Betan, compta, Betanaelle

2. Betanaelle délègue son rôle de chef à JPhi33 mais garde ses 3 attributions :

Table Camp
Betan, ..., JPhi33

3. Betanaelle délègue son attribution de comptable à un autre perso, par exemple "toto"

Table Administration
Betan, sécu, Betanaelle
Betan, archi, Betanaelle
Betan, compta, toto

Etc.

Tous les cas de figures sont gérés et on change facilement de chef, keuf, comptable et architecte. De plus, s'il te prend l'envie de créer une nouvelle attribution (médecin, par exemple), il suffit de la rajouter dans la table Attribution et d'y affecter un perso dans chaque camp.

[Betanaelle]

Génial

Je vais mettre ça au propre.

Désolé de ne pas être passé plus tôt, j'étais assez occupée cette semaine dernière.

Je t'accepte sans hésiter comme architecte, c'est tout bien carré.

Je vous posterai la correction pour être sur que ça tient la route, car c'est la première fois que je vois 2 relations reliées entre elle

[CinePhil]

c'est la première fois que je vois 2 relations reliées entre elle

En principe, ça ne se fait pas dans un MCD Merise.
Il est plus rigoureux de transformer d'abord l'association en entité.

À partir de l'association suivante :
A -0,n----associer----0,n- B

Je peux faire ces deux associations :
A -0,n----X----(1,1)- Association -(1,1)----Y----0,n- B

L'association "associer" est devenue une entité "Association" identifiée relativement à A et à B.

Les deux schémas génèreront les mêmes tables.

Maintenant, je peux associer l'entité "Association" à une autre entité :
A -0,n----X----(1,1)- Association -(1,1)----Y----0,n- B
C -0,n----Z----1,1------------|

La difficulté est souvent de trouver les verbes des nouvelles associations en X et Y.

Désolé de n'avoir pas trouvé le temps d'analyser la suite de ton problème.

[JPhi33]

Bonjour CinePhil,

En principe, ça ne se fait pas dans un MCD Merise.

Si, si, ça se fait, depuis "La méthode Merise, tome 1" en 1983 (page 144 de l'édition de 1989) où il est écrit (avec schéma à l'appui) que la source d'une CIF peut être une association, ce qui est bien le cas de la CIF "est exercé par" dans le schéma que j'ai proposé. Je trouve très dommage qu'aucun éditeur de logiciel de modélisation s'appuyant sur Merise n'ait jamais tenu compte de cette phrase. Mais ce n'est pas une raison pour ignorer une règle figurant dès le début dans Merise.

En revanche, relier une association et une entité par une association n,n (donc pas une CIF), voire associer deux associations entre elles, n'a été proposé que plus tard, d'abord par Morejon (en 1987) puis par Rochfeld/Morejon/Negros (en 1990). Là encore, cette extension de Merise n'a été suivie d'aucun effet dans les logiciels de modélisation.

[CinePhil]

Oh punaise !
JPhi33 est le fils caché de fsmrel !

Je m'incline !

[fsmrel]

Bonsoir,


Ben alors CinePhil, on n'a plus sa tête ? Vous ne vous souvenez pas de la figure 9 ici ? De la figure 4 là ? Ou de la figure 8 de la même discussion ? De la figure 9 ?
De Morejon, un exemple qui parle de lui-même :



De son côté, il y a plus de 30 ans, Ted Codd (RIP) qui ne passait pas pour quelqu’un manquant de rigueur classifiait ainsi les types d’entités dans RM/T (Relational Model / Tasmania) [Codd79] :

Kernels : entités ayant une existence autonome (disons entités-types fortes).

Characteristics : entités dont l’existence dépend de celle d’autres entités (on peut parler d’entités faibles).

Associations : entités dont la fonction est de représenter des relations entre deux ou plusieurs entités (on retrouve les relations merisiennes).

Il est bon de noter qu’en RM/T, une characteristic peut dépendre de n’importe quel type d’entité : kernel, characteristic ou association.
De même, une association peut mettre en relation n’importe quel type d’entité : kernel, characteristic ou association.

Avec RM/T, il est donc possible d’associer des associations. Personnellement ça me convient tout à fait, car pourquoi mettre des contraintes là où ça n’est pas indispensable et affaiblir de facto la puissance d’un système ?

____________________________
[Codd79] E.F. Codd. “Extending the Database Relational Model to Capture More Meaning” ACM TODS V4, N4 (December 1979), pp 397-433.

[CinePhil]

Je ne suis pas un encyclopédiste du Relationland ni de Merise comme toi mais je pense me débrouiller pas mal en modélisation de données en appliquant notamment la rigueur qui m'a été enseignée par M. Mazet au CNAM de Toulouse : dans un MCD on ne relie pas deux patates ! Autrement dit, on n'associe pas une association.

Les principes que j'applique et qui évitent de faire des bêtises :
- On nomme les entités (ou entité-type selon ta rigueur mais que je trouve décidément bien lourde pour le coup ; j'ai du mal à m'y mettre) avec des noms au singulier et les associations avec des verbes à l'infinitif ;
- Une patte d'une association ne va que vers une entité.

D'ailleurs, la non application de ces principes simples dans le schéma que tu m'avais envoyé suite à mon billet de blog "Quand faut-il une table associative ?", m'avait fait répondre :

J'ai plus de mal à traduire la seconde association de ce même schéma comprenant une cardinalité supérieure à 1 :
personne -0,1----compte_bancaire----1,2- domiciliation

Pour moi, un compte bancaire serait plutôt une entité type et la domiciliation une association !

Comme quoi, pour qu'un MCD soit lisible, il vaut mieux utiliser des verbes pour les associations et des noms pour les entités types !

De plus, le système que je préconise quand on est amené à vouloir faire pointer une association vers une autre association - transformer l'association en ce que j'appelle une "entité associative" - conduit naturellement à utiliser l'identification relative que tu recommandes bien souvent.

Mais bon, on s'éloigne du sujet principal de cette discussion et j'espère que nous n'embrouillons pas trop Betanaelle.

Bon réveillon à tous !

[fsmrel]

Bonsoir,

je pense me débrouiller pas mal en modélisation de données

Personne ne peut en douter, et s’il y a en a un qui mérite la médaille du sauvetage des modèles en péril, c’est bien le valeureux CinePhil !

Mais rien n’est figé en ce bas-monde et de temps en temps un petit tour de l'autre côté du miroir n'est pas inintéressant...

Bonnes fêtes itou !

[JPhi33]

Bonjour à tous,

Nonobstant nos débats "d'experts", et en guise de conclusion, retenons l'essentiel qui est que Betanaelle semble satisfait(e ?) par la solution.

Génial
[...] c'est tout bien carré.