Bonjour,

j'ai un projet perso de bibliothèque virtuelle. Mais j'ai un souci au niveau de la conception de la bdd.

La problématique :

1 livre contient plusieurs chapitres (qui sont différents d'un livre à l'autre)

1 utilisateur peut lire plusieurs livres en même temps avec donc un chapitre en cours de lecture différents d'un livre à l'autre

J'ai actuellement ça :

Je ne sais pas si je créé les tables book_chapiter et user read.

pour 2 raison différentes

pour book chapiter : car un 1 livre -> plusieurs chapitres est-ce pertinent d'avoir cette table intermédiaire ?

pour user_read : problème un peu similaire car les chapitres dépendent directement du livre auquel ils sont liés ?

Voilà un peu d'aide pour m'éclairer ... ou à lors je fais carrément fausse route.

Merci d'avance

Bonjour,

Pitchounvivi a écrit:

book_chapiter [...] est-ce pertinent d'avoir cette table intermédiaire ?

Non, en effet, la table de relation n'est ici pas nécessaire de par les cardinalités de la relation, par contre il faut une clé étrangère id_book dans la table chapter. Ce qui m'amène au conseil : toujours faire une MCD avant d'écrire le MLD (cf. donc "Conception BDD" dans ma signature).

Pitchounvivi a écrit:

user_read [...] les chapitres dépendent directement du livre auquel ils sont liés ?

Là, c'est juste la colonne id_book qu'il faut retirer de la table de relation, car tu a bien une relation n,n entre chapter et user.

Je verrai le MCD suivant (avec le MLD qui en découle) :

Avec ce modèle, pour chaque couple livre/utilisateur tu as un statut (par exemple : non lu, en cours de lecture, lu) et de même pour chaque couple utilisateur/chapitre.

Sans plus de contrôle, tu peux enregistrer en base le fait qu'un utilisateur soit lié à un chapitre d'un livre qu'il ne possède pas, cela se maîtriserait côté MPD avec la mise en place d'un TRIGGER BEFORE INSERT ON lecture.

Pitchounvivi a écrit:

book_chapiter

C'est chapter (sans le i) en anglais

hum, ok.

l'idée c'est d'avoir des Livres Dont Vous Etes Le Heros.

Est-ce que toi tu rajouterais des champs choix1 choix2 aux chapitres pour faire les liens ou tu gèrerais ça à part ?

Bah, on peut faire mieux ... carrément représenter le chemin d'un chapitre à un autre avec une table de relation ( chapitre provenance, chapitre destination ).

Et dans la relation lecture rajouter une colonne "ordre" pour représenter dans quel ordre les chapitres ont été parcouru ...

Intéressant, j'y pensais pas du tout.

En plus, si mon projet de base fonctionne, j'envisage de le développer ... J'ai déjà plein d'idée et le champ ordre serait utile à une des fonctionnalités que j'ai en tête.

Merci

Avoir une relation circulaire :

utilisateur-livre-chapitre-utilisateur

C'est autorisé ?

Je croyais que c'était pas une bonne pratique ?

Il n'y a pas de relation circulaire ici, lire et posséder sont deux relations distinctes exprimant deux choses bien différentes.

Au passage, c'était déjà le cas dans mon message précédent et tu n'avais rien dit

Et un petit rappel :

Benzouye a écrit:

Sans plus de contrôle, tu peux enregistrer en base le fait qu'un utilisateur soit lié à un chapitre d'un livre qu'il ne possède pas, cela se maîtriserait côté MPD avec la mise en place d'un TRIGGER BEFORE INSERT ON lecture.

-
Edité par Benzouye 20 octobre 2020 à 18:51:24

Benzouye a écrit:

Au passage, c'était déjà le cas dans mon message précédent et tu n'avais rien dit

-
Edité par Benzouye il y a environ 1 heure

Oui, c'est vrai, mais la nuit est passée par là ...

Je réfléchis mieux aujourd'hui.

-
Edité par Pitchounvivi 20 octobre 2020 à 23:04:19

Re moi,

alors j'ai développé un peu mon idée de départ. Et je m'attaque à la partie personnage.

J'ai désormais ce schéma :

Je suis embêtée pour la table confrontation. Une tite explication ?

J'aimerai pouvoir savoir comment monté le truc. Pour l'instant, on part sur l'idée qu'il s'agit de super héros.

- un livre possède plusieurs personnages

- un personnage peut être dans plusieurs livres

- un personnage peut appartenir à une équipe

Mais là ça commence à devenir compliqué. J'aimerai qu'on puisse savoir quelles sont les confrontations présentent dans un livre :

- on peut avoir 2 personnages solitaires l'un contre l'autre (celui du user/utilisateur contre un autre)

- un solitaire contre une équipe (le user pouvant être le solitaire ou faire parti de l'équipe)

- ou deux équipes l'une contre l'autre

J'ai décidé qu'on peut avoir des équipes temporaires (qui peuvent être improbable à la base). Exemple : Superman pourrait s'associer à un Méchant (le Parasite) contre un autre ...

En sachant également que j'aimerai garder la possibilité d'avoir plusieurs confrontations différentes dans un livre (pour pouvoir les compter à terme ?)

Après tout Superman pourrait avoir à se battre contre un Batman "possédé", avant de se battre contre le méchant manipulateur d'esprit (désolée trou de mémoire pour le nom).

Voilà, j'essaie d'envisager plusieurs possibilités ... en ayant les bonnes pratiques : norme NF, tables ouvertes, ...

On sait jamais si mon idée fonctionnait bien, ça pourrait devenir un vrai site ...

Benzouye a écrit:

toujours faire une MCD avant d'écrire le MLD (cf. donc "Conception BDD" dans ma signature).

Je pense que cela te faciliterai la vie ... Le fait de partir directement sur le MLD te contraint à une gymnastique non formalisée, et cela peut créer des incompréhensions ou ambiguïtés.

La plupart des logiciels de conception (JMerise, Looping, MoCoDo, etc.) te permettre de créer le MCD et de générer le MLD qui va avec.

Pour ta problématique de confrontation. Déjà, il semblerait qu'un personnage puisse avoir plusieurs équipes selon les livres et les moments. Il y a donc une relation n,n entre personnage et équipe.

Une confrontation serait en relation avec equipe et livre, ce qui créerait le lien indirect entre les personnages et les confrontations.

Ici il y a une boucle, ce qui imposera de mettre en place un contrôle empêchant de créer des confrontations sur des personnages n'apparaissant pas dans le livre associé (= TRIGGER BEFORE INSERT ON equipe_confrontation)

A méditer

-
Edité par Benzouye 22 octobre 2020 à 9:20:40

Ah, mais j'en avais fait un.

J'avais ça :

Mais je ne voyais pas trop comment formaliser les confrontations.

De plus j'en suis arrivée à me dire qu'on ne trouve que des liaisons n,n dans ma base de données.

Est-ce normal ?

Parce que j'ai potentiellement des 1,n. Mais des 1,1 ? Ca existe très peu en fait ?

C'est pourquoi, je me suis dit que ce MCD n'était pas bon et donc j'ai essayé le MLD.

Par contre, si je comprends bien dans ton MCD, il n'y a plus de confrontation : 1 perso contre 1 autre.

Dans la journée, j'y ai repensé et j'ai eu un truc comme ça :

Mais je n'étais pas très satisfaite non plus ...

Dans ce cas présent, on pense combat entre personnage sans faire de référence au fait qu'il soit ou non dans une équipe.

On a donc le perso contre perso, mais pas la problématique équipe contre équipe ou perso contre équipe.

C'est un peu comme personnage_présent_livre ... mais il faudrait pouvoir avoir un champ dans livre qui permettrait de "lister" chaque confrontation présente.

-
Edité par Pitchounvivi 22 octobre 2020 à 22:39:19

Dans ma proposition, pour faire du 1v1 il faut quand même créer une équipe pour chaque personnage, même si elle paraît inutile et temporaire. Cela permet surtout de simplifier le modèle ...

Une équipe de 1 en somme . Ok.

Si on part sur l'idée d'avoir une équipe de 1. Il faut créer une ligne : id, sans équipe, solitaire, (temporaire à voir comment je remplis ce champ).

Cette ligne pourra via la table de relation personnage_équipe être liée à différent personnage.

Cette ensemble perso_solitaire pouvant ensuite être utilisé dans la table confrontation.

Chaque confrontation pouvant être utilisée dans 1 à plusieurs livres.

C'est parfait, ça me semble vraiment top, comme ça. Merci.

Bon, j'ai trop d'idée de possibilité. Mais pour compter combien il y a de confrontation par type :

perso1 contre perso2, perso1 contre perso3, ...

Dans un livre, il me faudra lier les différentes confrontations dans confrontation_livre et faire un count(). Ca c'est ok.

Mais est-il possible de savoir combien il y a de confrontation perso1 contre perso2 autrement qu'en créant un champ spécifique dans livre et de l'écrire en "dur" ?

Non

Bon je vais y réfléchir, mais je crois que j'ai compris. J'avais pas envisager de créer une "équipe" de 1. Mais c'est vrai que là comme ça, ça correspond pas mal à la problématique et c'est plus simple à gérer.

Encore merci

Pitchounvivi a écrit:

Chaque confrontation pouvant être utilisée dans 1 à plusieurs livres

Dans ma proposition tu as une relation 1,n entre confrontation et livre. Une confrontation n'est liée qu'à un livre. Clé étrangère id_livre dans la table confrontation. Si tu veux qu'une confrontation apparaisse dans plusieurs livres, il faut créer une relation n,n entre les deux, ce qui génère une nouvelle table livre_confrontation ...

Pitchounvivi a écrit:

est-il possible de savoir combien il y a de confrontation perso1 contre perso2 autrement qu'en créant un champ spécifique dans livre et de l'écrire en "dur" ?

Surtout pas "en dur" ... tu imagines la mécanique à mettre en place pour tenir cette valeur à jour ...

Non, simplement avec une requête ...

SELECT COUNT(*) AS nb_confrontation
FROM
	personnage_equipe PE1 -- on part des équipes du perso 1 (cf. WHERE)
		INNER JOIN equipe_confrontation EC1 -- on joint aux confrontation de ses équipes
			ON PE1.id_equipe = EC1.id_equipe
		INNER JOIN equipe_confrontation EC2 -- on joint aux équipes adverses
			ON EC1.id_confrontation = EC2.id_confrontation -- même confrontation
			AND EC1.id_equipe <> EC2.id_equipe -- mais équipe différente
		INNER JOIN personnage_equipe PE2 -- on joint aux équipes du perso 2 (cf. WHERE)
			ON E2.id_equipe = PE2.id_equipe
WHERE
	PE1.id_personnage = 'id personnage 1'
	AND PE2.id_personnage = 'id personnage 2'

Bonsoir,

on m'a fait une remarque intéressante aujourd'hui. Et j'aimerai savoir si l'interprétation vient d'une mauvaise explication de ma part ou s'il s'agit d'une idée.

Parce que si on regarde dans ton schéma, pour perso_livre on sait quels sont les perso présents (dans le livre) mais pas s'ils sont dans une équipe ou seul.

Dans la table équipe : il y a les noms d'équipe (Avenger, ...), alliance de circonstance, solitaire.

Et donc si on lie équipe à confrontation, on ne sait pas si le personnage est ou non dans l'équipe. On sait seulement s'il y a un équipe ou un solitaire.

Voilà grosso modo, ce qu'on m'a proposé :

On peut garder la table confrontation (je l'ai juste enlevée pour avoir plus de place), qui permet de savoir combien il y a eut de confrontation dans un livre.

Question (pour plus tard potentiellement) : peut-on avoir des tables de relation qui "se suivent" ... un peu comme sur le dessin au dessus ?

personnage_équipe qui est liée à perso_équipe_livre ou vaut-il mieux mettre la clé étrangère du livre dans celle de perso_équipe.

-
Edité par Pitchounvivi 24 octobre 2020 à 0:06:13

Pitchounvivi a écrit:

si on regarde dans ton schéma, pour perso_livre on sait quels sont les perso présents (dans le livre) mais pas s'ils sont dans une équipe ou seul

Indirectement si ... un personnage est lié à des livres et à des équipes donc, si tu connais le livre tu connais les personnages, et si connais les personnages tu connais les équipes ...

Pitchounvivi a écrit:

si on lie équipe à confrontation, on ne sait pas si le personnage est ou non dans l'équipe

Là encore indirectement si ... un personnage est lié à des équipes, une équipe est liée à des confrontations donc, si tu connais la confrontation tu connais les équipes, et si tu connais les équipes, tu connais les personnages ...

Maintenant si tu veux qu'une équipe ne concerne qu'un seul livre ... et bien il faut encore changer les cardinalités et les relations ...

Pitchounvivi a écrit:

peut-on avoir des tables de relation qui "se suivent" ... un peu comme sur le dessin au dessus ?

personnage_équipe qui est liée à perso_équipe_livre ou vaut-il mieux mettre la clé étrangère du livre dans celle de perso_équipe.

Pas compris

Bonjour,

mon projet avance bien, j'ai pas mal avancé la partie back, mais j'ai un souci entre les livres et les auteurs ...

La table auteur est faite comme ça parce que un auteur peut être scénariste et/ou dessinateur et/ou encreur pour un livre

C'est un peu la même idée avec les couvertures de livres qui en plus appartiennent à 1 livre (édité en 1980), mais par forcément à sa réédition en 2005 

Et un auteur peut avoir travaillé avec des maisons d'édition différentes.

En fait, je bloque pour écrire la requête sql qui permettrait d'avoir :

nom du livre | nom du scénariste | nom du dessinateur | nom de l'encreur

Je pensais faire une jointure, 

Mais avoir 3 jointure sur la même table genre 

INNER JOIN auteur ON auteur.auteur_id = livre.livre_scenariste

INNER JOIN auteur ON auteur.auteur_id = livre.livre_dessinateur

INNER JOIN auteur ON auteur.auteur_id = livre.livre_encreur

ben ça marche pas ... et ça ne me choque pas parce que pour nous c'est clair, mais je comprend que cela ne le soit pas pour lui

Comment je peux me débrouiller avec ça 

Je maitrise pas très bien les sous-requêtes et je me disais que c'étais une solution, mais pour l'instant, j'ai pas abouti à ce que je voulais.

===============================================

Je viens d'essayer de remodéliser ça mais je ne suis pas sur du résultat

J'arrive pas à "voir" comment faire les différentes relations et les colonnes ...

===============================================

J'ai fait ce MLD à partir du schéma précédent

Mais maintenant je ne vois pas comment faire le lien avec livre et couverture.

L'idée étant :

qu'un livre à un scénariste, un dessinateur, un encreur

la couverture peut avoir un dessinateur et un encreur

et un auteur peut être soit un scénariste, soit un dessinateur, soit un encreur, soit une combinaison de 2 ou les 3 types

-
Edité par Pitchounvivi 14 novembre 2020 à 22:27:32

Pitchounvivi a écrit:

Je pensais faire une jointure, 

Mais avoir 3 jointure sur la même table genre 

INNER JOIN auteur ON auteur.auteur_id = livre.livre_scenariste

INNER JOIN auteur ON auteur.auteur_id = livre.livre_dessinateur

INNER JOIN auteur ON auteur.auteur_id = livre.livre_encreur

ben ça marche pas ...

Si, cela fonctionne, mais il faut expliquer au SGBD que ce sont 3 fois la même table mais indépendamment ... Cela se fait par le biais des alias :

FROM
	livre L
		INNER JOIN auteur S
			ON S.auteur_id = L.livre_scenariste
		INNER JOIN auteur D
			ON D.auteur_id = L.livre_dessinateur
		INNER JOIN auteur E
			ON E.auteur_id = L.livre_encreur

Mais je ne pense pas que cela soit la meilleure façon de fonctionner ...

Une solution plus souple et évolutive serait une relation ternaire :

Pour chaque livre tu stockes autant de couples métier/personne que nécessaire. Et si des nouveaux métiers apparaissent, pas de modif à faire, juste une insertion dans la table métier et ça fonctionne ...

Après, je me dis que ton système pour les éditions n'est pas terrible non plus ... Un même livre peut être édité plusieurs fois par des éditeurs différents, et à chaque fois la couverture peut être différente aussi avec des personnes différentes ...

Je pencherai pour une solution là encore plus souple et précise :

Cela fait 2 ternaires, une pour les personnes participant à un livre, et une pour celles participant à la couverture de l'édition.

Les éditions sont ici des "émanations" d'un livre et d'un éditeur.

D'après ton schéma, je n'étais pas très loin.

Il n'est donc pas possible de pouvoir réutiliser le tableau participation pour les couvertures aussi.

Par contre, je n'avais pas séparé la partie édition de la table livre.

C'est pas la première fois que je ne subdivise pas suffisamment une table.

Comment savoir si il faut rajouter des tables ou seulement des champs ?

-
Edité par Pitchounvivi 15 novembre 2020 à 0:22:58

Pitchounvivi a écrit:

Il n'est donc pas possible de pouvoir réutiliser le tableau participation pour les couvertures aussi.

Hélas non, c'est la même structure, mais avec une référence différente, pour le livre dans l'une et pour l'édition dans l'autre ... Sauf à bricoler un truc moche et pas très rigoureux : stocker le type "edition" ou "livre" comme attribut dans la ternaire et construire la requête en fonction ... mais beurk vraiment beurk ...

Pitchounvivi a écrit:

Comment savoir si il faut rajouter des tables ou seulement des champs ?

En réfléchissant bien aux entités / relations / cardinalités ... Si une édition est concerne un livre mais qu'un livre peut avoir plusieurs éditions c'est qu'édition est une entité à part entière ...

C'est vrai que c'est pour moi devenu plus ou moins un réflexe (hum ... sans prétention hein ...   ).

-
Edité par Benzouye 15 novembre 2020 à 0:33:02

L'expérience et la pratique en somme ...  

Par contre, j'ai réalisé que j'avais ce problème en essayant d'écrire une requête avec des jointures.

Si je veux afficher le titre d'un livre et les noms du scénaristes, du dessinateur et de l'encreur.

Ma requête d'origine était :

SELECT 
    livre_titre,
    A1.auteur_nom,
    A2.auteur_nom,
    A3.auteur_nom
FROM 
    livre AS L
INNER JOIN auteur AS A1
    ON A1.auteur_id = L.livre_scenariste
INNER JOIN auteur AS A2
    ON A2.auteur_id = L.livre_dessinateur
INNER JOIN auteur AS A3
    ON A3.auteur_id = L.livre_encreur;

La nouvelle requête doit donc ressembler à quelque chose comme ça :

SELECT 
    LI.titre,
    ME.libelle,
    PE.nom
FROM 
    participation AS PA
INNER JOIN metier as ME
    ON PA.id_metier = ME.id_metier 
INNER JOIN livre AS LI
    ON PA.id_livre = LI.id_livre 
INNER JOIN personne AS PE
    PA.id_personne = PE.id_personne 
;

-
Edité par Pitchounvivi 15 novembre 2020 à 15:15:11

Oui, cette requête va te retourner une ligne par personne, avec son métier.

Merci, donc j'ai avancé en suivant ton conseil et là j'ai ma requête qui fonctionne.

Merci

Bonjour,

j'ai une question modéliser une bdd ... toujours sur le même thème (j'explore plein de trucs, ce qui me fait me poser des questions).

J'aimerai que certains chapitres soient un peu spéciaux (avec des activités différentes genre : combat, énigme, ...)

Mais chaque activité à des besoins différents.

Comment on modélise une phrase qui ressemble à ça :

- Si le chapitre est de type combat : il utilise la ressource de la table PNJ associée au chapitre (dans un module en back qui gère le combat ), on peut rencontrer un ou plusieurs pnj avec des niveaux différents et normalement, ils ne sont pas les identiques, même si 2 chapitres du livre sont des combats.

- Si le chapitre est de type fuite : il utilise la ressource de la table fuite (dans un module qui gère en back le minuteur de la fuite et les évènements du lieu de façon aléatoire)

- Si le chapitre est de type dialogue/conversation : il utilise la ressource de la table dialogue (dans un module qui gère en back les phrases en fonction des choix fait par le perso. La table dialogue a la même fonction que la table choix. Mais les dialogues autorisés dépendent du chapitre).

- Si le chapitre est de type histoire : il utilise la ressource de la table histoire (du simple texte à lire), les choix dépendant du chapitre en cours

L'idée ça serait d'avoir un déroulement qui pourrait ressembler à ça :

chap 1 = histoire => choix(table) vers chap 2 ou 3

chap 3 = histoire => choix(table) vers chap 4 ou 5

chap 4 = combat ( module qui utilise la table pnj pour la gestion du combat) => choix(table) vers chap 6 ou 7

chap 7 = conversation (module qui utilise les tables : dialogue et phrase , les phrases disponibles dépendent du personnage du chapitre donc directement du chapitre en fait) => fin de conversation : choix(table) vers chap 8 ou 9

chap 9 = histoire => fin

J'ai commencé à modéliser en MCD (oui, oui !!)

comme dit précédemment, je ne sais pas trop comment faire les liaisons qui manquent car chaque type relie vers une table (pnj, énigme, poursuite, dialogue), mais cela dépend également du chapitre qui permettra de savoir quel pnj ou durée pour le minuteur dans quel lieu ou encore quel dialogue.

-
Edité par Pitchounvivi 23 décembre 2020 à 21:42:07

Si tu veux explorer, alors regarde la notion d'héritage : https://sqlpro.developpez.com/cours/modelisation/heritage/

Ici tu pourrais avoir une table mère "Chapitre", et autant de table fille que de type de chapitre. Ainsi les tables filles auraient des relations différentes et des attributs différents en fonction.

Je n'ai pas très bien compris toute la mécanique, mais l'idée serait :

MoCoDo ne gère pas (encore) l'héritage, avec Looping cela donne :

-
Edité par Benzouye 24 décembre 2020 à 9:44:11

Ah, mais c'est très intéressant !!!

J'ai pas encore regardé dans le détail, mais ça collerait très bien à mon envie/idée.

Je ne connaissais pas l'existence d'héritage en Base de Donnée.

Merci !

Bonjour,

j'espère que la fin d'année se passe bien...

Je me demandais, normalement dans une base de données, on de doit pas avoir de champs en double.

Alors avoir une table sauvegarde qui hérite de la table personnage, est-ce comme cela qu'il faut procéder ?

La table sauvegarde servant à faire une "photo" liée à un  moment donné dans mon cas un chapitre en cour.

Le problème c'est qu'on doit pouvoir avoir plusieurs sauvegardes du même personnage sur des chapitres différents mais aussi potentiellement sur le même chapitre.

Si j'ai bien compris, l'héritage fonctionne très bien pour des données "figées" tout du moins qui ne changent pas trop dans le temps : nom, adresse, numéro de téléphone.

Mais qu'en est-il pour des informations qui sont appelées à beaucoup changer : les valeurs de points de vie, magie, ... etc ?

Peut-on créer une table comme sauvegarde ?

Ou le fonctionnement doit se faire différemment ?

Merci d'avance et bonne fin d'année ... si vous le pouvez ... 

-
Edité par Pitchounvivi 30 décembre 2020 à 10:51:02

Il n'est pas question d'héritage dans ce contexte ...

Une sauvegarde est une entité à part entière qui DOIT reprendre les attributs de l'entité personnage pour conserver la photo justement ... même si cela semble faire doublon ...

Le modèle serait :

Bonne année à vous !!

Que cette année vous apporte ce dont vous avez besoin ...

Oui, avec un peu de recul, je pense que j'ai un peu pêché par excès ...