Discussion :

[iceksy]

Bonjour !

Je bosse depuis peu sur un projet perso qui me tente depuis un moment: Un site d'histoires interactives, dans le même genre que les "livres dont vous êtes le héros" si ça dit quelque chose

J'ai établi mes règles de gestion qui sont les suivantes:

- Un Utilisateur écrit 0 ou plusieurs Histoires
- Une Histoire est écrite par 1 seul Utilisateur

- Une Histoire contient 0 ou plusieurs Pages
- Une Page est contenue dans une seule Histoire

- Un Utilisateur joue 0 ou plusieurs Personnages
- Un Personnage est joué par un seul Utilisateur

- Une Histoire fait participer 0 ou plusieurs Personnages
- Un personnage participe à une seule Histoire.

- Une Histoire définie 0 ou plusieurs Aptitudes
- Une Aptitude est définie dans 1 ou plusieurs Histoires

- Un Personnage connait 0 ou plusieurs Aptitudes
- Une Aptitude est connue par 0 ou plusieurs Personnages

- Une Histoire propose 0 ou plusieurs Objets
- Un Objet est proposé par 1 ou plusieurs Histoires

- Un Personnage possède 0 ou plusieurs Objets
- Un Objet est possédé par 0 ou plusieurs Personnages

- Un Objet est définie par un seul Type
- Un Type définie 0 ou plusieurs Objets

J'ai fais une modélisation via Mysql Workbench (mais étant habitué à PowerAMC, j'ai peut être fait des boulettes dans les relations ^^) visible ici: http://nsa29.casimages.com/img/2012/...1900815458.jpg


J'admet que la conception de BDD n'est pas mon fort, c'est pourquoi je poste ici pour demander conseils et astuces !

Voyez vous quelque chose dans mes règles ou dans ma modélisation qui puisse être amélioré, voire qui soit carrément une grosse erreur ?

Grand merci d'avance pour votre aide !

[CinePhil]

Tu devrais nommer tes tables au singulier puisque les règles de gestion sont établies à chaque fois pour une instance :

- Un Utilisateur écrit 0 ou plusieurs Histoires
- Une Histoire est écrite par 1 seul Utilisateur

OK pour la modélisation de cette première règle, à un détail près qui va se retrouver sur toutes tes associations : toutes tes cardinalités mini sont à 1 (mode par défaut dans MySQL Workbench).
Pour cette première règle, tu devrais avoir le schéma suivant :


Pour rétablir les cardinalités mini à zéro, double-clique sur le lien entre les tables puis sélectionne l'onglet "Foreign Key" et décoche la case Mandatory du côté où doit apparaître la cardinalité zéro.

- Une Histoire contient 0 ou plusieurs Pages
- Une Page est contenue dans une seule Histoire

Ce que tu appelles "Page" ici est probablement ce que tu as nommé "Contenu" dans ton schéma ?
Pourquoi avoir changé de nom ?

C'est bien d'avoir pensé à l'identification relative de la page par rapport à l'histoire !

- Une Histoire fait participer 0 ou plusieurs Personnages
- Un personnage participe à une seule Histoire.

Une identification relative serait peut-être judicieuse ici aussi.

- Une Histoire définie 0 ou plusieurs Aptitudes
- Une Aptitude est définie dans 1 ou plusieurs Histoires

OK

- Un Personnage connait 0 ou plusieurs Aptitudes
- Une Aptitude est connue par 0 ou plusieurs Personnages

OK

Mais si on prend les deux dernières règles, avec ton schéma, rien n'interdit un personne P de connaître une aptitude A définie dans une histoire H qui n'est pas celle du personnage P !

Selon moi, les aptitudes sont plutôt des propriétés des personnages que des histoires. En supprimant la règle définissant les aptitudes dans les histoires, je peux retrouver quand même les aptitudes utilisées par une histoire H à travers les personnages de cette histoire.
La table associative "Histoire_has_aptitude" est donc inutile.
Au passage, ça va te permettre de réorganiser ton schéma pour éviter des croisement qui rendent sa lecture difficile.

- Une Histoire propose 0 ou plusieurs Objets
- Un Objet est proposé par 1 ou plusieurs Histoires

Dans ton schéma, Un Objet est proposé par 1 seule Histoire !

- Un Personnage possède 0 ou plusieurs Objets
- Un Objet est possédé par 0 ou plusieurs Personnages

Même problème !
Un personnage P peut posséder un objet O qui n'est pas proposé par l'histoire H à laquelle il participe.

Il va falloir prendre en compte cette contrainte au niveau code SQL d'un trigger à l'insertion dans la table "personnage_has_objet".

- Un Objet est définie par un seul Type
- Un Type définie 0 ou plusieurs Objets

Pas d'identification relative ici à mon avis !

Dans l'ensemble, c'est pas mal !

Révise quand même la taille de certaines colonnes ; 45 caractères pour une adrel ou une description par exemple, c'est un peu court !

[iceksy]

Pour rétablir les cardinalités mini à zéro, double-clique sur le lien entre les tables puis sélectionne l'onglet "Foreign Key" et décoche la case Mandatory du côté où doit apparaître la cardinalité zéro.

Je vais le refaire rapido, voir ce que ça donne, et je le ferais bien beau sur PowerAMC ce soir

- Une Histoire contient 0 ou plusieurs Pages
- Une Page est contenue dans une seule Histoire

Ce que tu appelles "Page" ici est probablement ce que tu as nommé "Contenu" dans ton schéma ?
Pourquoi avoir changé de nom ?

Simplement pour l'écriture de la règle de gestion. "Un contenu est contenu ..", ça faisait pas beau

C'est bien d'avoir pensé à l'identification relative de la page par rapport à l'histoire !

Hum, j'ai rien pensé de spécial, qu'est ce donc qu'une identification relative ?
Le fait que le contenu possède Histoire_HIS_ID en clé primaire ?

- Une Histoire fait participer 0 ou plusieurs Personnages
- Un personnage participe à une seule Histoire.

Une identification relative serait peut-être judicieuse ici aussi.

j'attends la réponse à ma question au dessus pour changer

Mais si on prend les deux dernières règles, avec ton schéma, rien n'interdit un personne P de connaître une aptitude A définie dans une histoire H qui n'est pas celle du personnage P !

Selon moi, les aptitudes sont plutôt des propriétés des personnages que des histoires. En supprimant la règle définissant les aptitudes dans les histoires, je peux retrouver quand même les aptitudes utilisées par une histoire H à travers les personnages de cette histoire.
La table associative "Histoire_has_aptitude" est donc inutile.
Au passage, ça va te permettre de réorganiser ton schéma pour éviter des croisement qui rendent sa lecture difficile.

Avec les objets, ce sont les 2 choses qui me posent le plus de problèmes ..

L'utilisateur, en écrivant son histoire, va proposer plusieurs aptitudes à choisir en début de partie (Sixieme sens, chasse, protection psychique, ...): 2 choix sur 6 aptitudes au total par exemple.

Je vois pas trop comment faire en mettant les aptitudes en propriétés de personnages ..

Je pourrais supprimer la table "Histoire_has_aptitude" et mettre l'ID d'Histoires dans la table Aptitudes en clé étrangère, mais si l'auteur sort une deuxième histoire, une suite par exemple, il faudra cloner les Aptitudes communes.

- Une Histoire propose 0 ou plusieurs Objets
- Un Objet est proposé par 1 ou plusieurs Histoires

Dans ton schéma, Un Objet est proposé par 1 seule Histoire !

Probablement ma méconnaissance du logiciel et le fait que j'ai changé un peu d'avis en écrivant mes règles de gestion ici ^^

A la base, un objet avait une seule histoire possible, avec possibilité de copier un objet d'une histoire existante (clonage de l'objet) mais je me suis dit qu'il serait probablement plus simple de mettre la possibilité d'utiliser le même objet pour plusieurs histoires, pour éviter d'avoir 36 fois le même objet dans la base.

- Un Objet est définie par un seul Type
- Un Type définie 0 ou plusieurs Objets

Pas d'identification relative ici à mon avis !

Donc je passe Types_TYP_ID en clé étrangère ?

Tu devrais nommer tes tables au singulier puisque les règles de gestion sont établies à chaque fois pour une instance

Mon prof de BDD m'a appris à mettre les tables au pluriel, et de nommer les relations par un verbe à l'infinitif, donc j'ai continué de faire comme ça ^^

Révise quand même la taille de certaines colonnes ; 45 caractères pour une adrel ou une description par exemple, c'est un peu court !

Je n'ai pas touché aux datatypes par défaut, ce sont plus les relations qui me posent des soucis.
Je m'en occuperais une fois que tout sera bon de ce coté la !

[CinePhil]

Hum, j'ai rien pensé de spécial, qu'est ce donc qu'une identification relative ?
Le fait que le contenu possède Histoire_HIS_ID en clé primaire ?

Oui.
Typiquement, la page ne peut pas exister sans l'histoire, tout comme une chambre d'hôtel ne peut exister sans l'hôtel. Et dans chaque histoire la numérotation des pages recommence à 1, comme dans chaque hôtel la numérotation des chambres.

Sur MySQL Workbench, c'est l'icône "Identifying relationship" qui trace un trait plein entre les deux tables concernées et qui fait participer à la clé primaire de la table référençante l'identifiant de l'autre table.

L'utilisateur, en écrivant son histoire, va proposer plusieurs aptitudes à choisir en début de partie (Sixieme sens, chasse, protection psychique, ...): 2 choix sur 6 aptitudes au total par exemple.

Je vois pas trop comment faire en mettant les aptitudes en propriétés de personnages ..

Alors il faut associer Personnage à Histoire_has_Aptitude et écrire un trigger qui vérifie que l'histoire est bien celle du personnage.

Je pourrais supprimer la table "Histoire_has_aptitude" et mettre l'ID d'Histoires dans la table Aptitudes en clé étrangère, sinon

Ceci aurait pour conséquence qu'une aptitude ne serait définie que par une seule histoire, ce qui est non-conforme à l'une de tes règles de gestion.

A la base, un objet avait une seule histoire possible, avec possibilité de copier un objet d'une histoire existante (clonage de l'objet) mais je me suis dit qu'il serait probablement plus simple de mettre la possibilité d'utiliser le même objet pour plusieurs histoires, pour éviter d'avoir 36 fois le même objet dans la base.

Bon réflexe mais il faut alors changer l'association dans le schéma.

Donc je passe Types_TYP_ID en clé étrangère ?

Oui.

Mon prof de BDD m'a appris à mettre les tables au pluriel, et de nommer les relations par un verbe à l'infinitif, donc j'ai continué de faire comme ça ^^

Et bien il a tort !
J'ai donné la raison du singulier. En plus, le pluriel introduit de l'ambiguïté sémantique dans la BDD : la colonne Utilisateurs_UTI_ID fait-elle référence aux identifiants de plusieurs utilisateurs pour une histoire ? Avec le singulier, pas d'ambiguïté !

Je n'ai pas touché aux datatypes par défaut, ce sont plus les relations qui me posent des soucis.
Je m'en occuperais une fois que tout sera bon de ce coté la !

C'est bien ce que j'avais compris. Je disais cela juste pour mémoire.

[iceksy]

Je pourrais supprimer la table "Histoire_has_aptitude" et mettre l'ID d'Histoires dans la table Aptitudes en clé étrangère, sinon

Ceci aurait pour conséquence qu'une aptitude ne serait définie que par une seule histoire, ce qui est non-conforme à l'une de tes règles de gestion.

J'ai édité ma phrase pendant ta réponse, manifestement
La mise en conformité à ma règle de gestion m'obligerait à cloner les aptitudes pour chaque histoire, donc je garde la table.

Alors il faut associer Personnage à Histoire_has_Aptitude et écrire un trigger qui vérifie que l'histoire est bien celle du personnage.

C'est ce que je pensais faire.
Soit un trigger, soit une vérification en PHP, je verrais ce qui est le plus simple pour moi.

A la base, un objet avait une seule histoire possible, avec possibilité de copier un objet d'une histoire existante (clonage de l'objet) mais je me suis dit qu'il serait probablement plus simple de mettre la possibilité d'utiliser le même objet pour plusieurs histoires, pour éviter d'avoir 36 fois le même objet dans la base.

Bon réflexe mais il faut alors changer l'association dans le schéma.

C'est ce que j'ai fais, on arrive à la même chose que les aptitudes.

J'ai donné la raison du singulier. En plus, le pluriel introduit de l'ambiguïté sémantique dans la BDD : la colonne Utilisateurs_UTI_ID fait-elle référence aux identifiants de plusieurs utilisateurs pour une histoire ? Avec le singulier, pas d'ambiguïté !

C'est modifié

Pour le schema, ça donne ça : http://nsa30.casimages.com/img/2012/...4000681259.jpg

Y a p'tete encore quelques soucis de relation, mais je corrigerais tout ça ce soir, je suis pas à l'aise avec Mysql Workbench ..