Discussion :

[aperikub]

Bonjour à tous,

je suis en train de modéliser la b.d d'une bibliothèque pour un cours, j'ai une association "emprunter" entre mes entités "livre", "abonné" et "emprunts" (l'entité emprunt sert à créer une liste de tous les emprunts).

cette association à pour attributs la date d'emprunt et la date à laquelle le livre doit être rendu, j'ai donc créé un attribut date_sortie qui contient un sous-attribut date_retour, je voudrais que date_retour soit égal à date_sortie + 15 jours mais je ne sais pas comment mettre une opération en tant que valeur par défaut (si c'est possible).

je voudrais également que les n-uplets de l'entité emprunts datant de plus de 3 mois soient supprimés mais je ne vois pas comment "automatiser" l'envoi d'une requête SQL soit tous les jours, soit à chaque fois qu'un nouvel emprunt est fait

voici mon mcd (qui est très basique mais je l'étofferai quand j'aurais moins l'impression d'être une poule assistant à un cours de physique quantique):


je galère aussi avec le principe de cardinalité et d'entité faible dans les associations ternaires:
dans l'association emprunte:
-un abonné peut emprunter de 0 à n livres et apparaitre dans 0 à n emprunts donc là tout va bien (0,n)
-un emprunt concerne 1 livre et 1 abonné, là aussi ça va (1,1)
-un livre est emprunté par 0 ou 1 abonné (0,1) mais peut apparaitre dans 0 à n emprunts (0,n) du coup quelle cardinalité doit avoir livre?

est-ce que l'entité emprunt est une entité de type faible? (un emprunt ne peut exister sans un livre et un abonné)





merci d'avance!

[escartefigue]

Bonjour aperikub

comme expliqué dans l'autre sujet ici :
https://www.developpez.net/forums/d2...i-cardinalite/

Ce n'est pas le livre qui est emprunté par le lecteur, mais l'exemplaire

D'ailleurs les attributs de votre entité-type "livre" le prouvent : si vous avez deux exemplaires d'un même livre, la date d'achat peut être différente
La date d'achat est donc un attribut de l'entité-type "exemplaire" manquante dans votre modèle.
Chaque exemplaire peut être emprunté simultanément ou à des dates différentes

Reprenez le MCD que j'avais proposé dans le lien ci-dessus (réponse n° 8 page 1) qui peut servir de base pour votre exercice.

A bientôt

[aperikub]

ah d'accord mais est-ce que la notion d'exemplaire n'est pas remplacée par l'identifiant ref_livre? un premier exemplaire aura une référence et un deuxième exemplaire en aura une autre avec chacun son éditeur et sa date d'achat. pour ce qui est du mcd que vous aviez proposé j'ai été le voir régulièrement pour y chercher des solutions, mais le modèle que je dois créer n'est pas libre, il est basé sur un modèle plus simple fourni dans l'exercice
---
EDIT: après échange de mail avec le prof il me dit de supprimer l'entité emprunts et de ne garder qu'une association binaire livre---0,n--- emprunter---0,n---abonné avec une clé primaire de type auto_increment pour l'association emprunter. ce qui apparemment n'est pas possible dans jmerise. du coup mon mcd donne ça:



par contre je ne vois pas de trace de ma contrainte sur la localisation dans le script sql. est-ce que les contraintes placées sur le mcd ne sont la que dans un cadre conceptuel?

[escartefigue]

EDIT: après échange de mail avec le prof il me dit de supprimer l'entité emprunts et de ne garder qu'une association binaire livre---0,n--- emprunter---0,n---abonné

Admettons, dans la mesure où l'exercice vous impose de simplifier et de ne donc pas distinguer le livre de l'exemplaire.
Mais bon, modélisé comme ça, l'auteur devra écrire autant de fois un livre que différents lecteurs voudront l'emprunter
Une chose est certaine, c'est que votre association ternaire ne correspond pas à la réalité.

avec une clé primaire de type auto_increment pour l'association emprunter. ce qui apparemment n'est pas possible dans jmerise.

Ca n'est pas possible car ça n'a pas de sens !
Une association ne possède pas d'identifiant.
Les identifiants sont à positionner dans les types d'entité (ou entités-type), pas dans les associations.



Enfin, c'est quoi un "centre" ? Pourquoi un livre est forcément dans un centre s'il n'est pas emprunté ?
Dans la vraie vie, un livre (enfin plutôt un exemplaire) peut être chez l'éditeur, chez le libraire, dans une médiathèque, chez l'auteur, chez un lecteur...

mais le modèle que je dois créer n'est pas libre, il est basé sur un modèle plus simple fourni dans l'exercice

Merci de communiquer ce modèle simplifié

[aperikub]

modélisé comme ça, l'auteur devra écrire autant de fois un livre que différents lecteurs voudront l'emprunter
Une chose est certaine, c'est que votre association ternaire ne correspond pas à la réalité.

oula j'ai encore un neurone qui vient de partir en fumée qu'est-ce que vous voulez dire par la? que quand un abonné emprunte un livre ça va ajouter une entrée dans la tabe "écrire"?
l'idée derrière mon modèle était que lorsque un abonné emprunte un livre on ajoute un n-uplet à la table emprunter: emprunter(ref_livre, ref_abonné, date_sortie, date_retour) avec date_retour valant NULL tant que le livre n'est pas rendu

Enfin, c'est quoi un "centre" ? Pourquoi un livre est forcément dans un centre s'il n'est pas emprunté ?
Dans la vraie vie, un livre (enfin plutôt un exemplaire) peut être chez l'éditeur, chez le libraire, dans une médiathèque, chez l'auteur, chez un lecteur...

la bibliothèque est composée de 5 centres, on peut emprunter un livre dans un centre et le rendre dans un autre.
si un livre est dans la base c'est que la bibliothèque l'a acheté donc il est soit dans un des centres soit chez un abonné.

Merci de communiquer ce modèle simplifié

voila:

[escartefigue]

Je ne répond qu'au premier point pour l'instant

oula j'ai encore un neurone qui vient de partir en fumée qu'est-ce que vous voulez dire par la? que quand un abonné emprunte un livre ça va ajouter une entrée dans la tabe "écrire"?
l'idée derrière mon modèle était que lorsque un abonné emprunte un livre on ajoute un n-uplet à la table emprunter: emprunter(ref_livre, ref_abonné, date_sortie, date_retour) avec date_retour valant NULL tant que le livre n'est pas rendu

Pour l'instant, oublions les tables.


Dans votre MCD l'auteur est en relation avec le livre via l'association "écrire" et le lecteur est également en relation avec le livre via l'association "emprunter"

Donc, si deux lecteurs veulent emprunter "la gloire de mon père" le même jour, vu que la notion d'exemplaire n'existe pas dans votre MCD, il faut que l'écrivain écrive une deuxième fois ce livre qui sera du coup enregistré avec un nouvel identifiant et une nouvelle date de parution, mais un même contenu.

Le souci c'est que Marcel Pagnol est décédé depuis fort longtemps et je ne suis pas convaincu qu'il aurait accepté de son vivant d'écrire autant de fois ce livre que de lecteurs aient souhaité le lire simultanément

Il n'y a pas à tergiverser : la notion d'exemplaire est obligatoire. Allez voir votre formateur en lui expliquant ce dilemme, il devra se résoudre à accepter cette entité-type incontournable !

[aperikub]

d'accord, décidément j'ai vraiment du mal avec cette logique

EDIT: j'ai beau retourner votre explication dans tous les sens, ça ne veut pas rentrer, si deux lecteurs empruntent "la gloire de mon père" en meme temps, c'est que la bibliothèque à acheté deux fois ce livre donc la b.d contient deux n-uplets de l'entité livre par exemple:

livre(ref_livre: 0237, titre:"la gloire de mon père", editeur:"plon", etat:"bon", date_achat: "2013-11-05")
livre(ref_livre: 0522, titre:"la gloire de mon père", editeur:"gallimard", etat:"neuf", date_achat: "2020-10-25")

je suis en train de refaire mon mcd avec une entité type exemplaire mais j'aimerai quand même comprendre


autrement, ma contrainte XT se tient ou pas? sachant qu'un livre qui n'est pas détenu par la bibliothèque ou emprunté n'a aucune raison d'être dans la base?
et du coup pourquoi est-ce que je n'en vois aucune trace dans le script sql? est-ce que cette contrainte doit être "fléchée"? ce n'est pas indiqué dans la faq de jmerise

[escartefigue]

oui mais votre modèle de données comporte des redondances avec les risques inhérents à ces redondances (incohérences, encombrement inutile...) : à chaque exemplaire du même livre, vous répétez son titre, l'identifiant de l'auteur, son résumé, etc.
Or, c'est exactement ce qu'il ne faut pas faire dans un modèle de données relationnel.

Dans un modèle bien conçu vous avez (j'oublie la notion d'ouvrage pour simplifier mais dans l'absolu, elle peut être intéressante, cf. ma réponse en lien URL sur l'autre sujet que vous aviez ouvert) vous avez :

LIVRE
Livre_id = 00340278
Livre_titre= "les misérables"
Auteur_id= 00000351 (pointe vers la table des auteurs pour trouver Victor Hugo)
Livre_resume="bla bla bla ...."


EXEMPLAIRE

Livre_id=00340278 (pointe vers la table des livres pour trouver "les misérables"
Exemplaire_id=0003
ISBN=....
Editeur_id = 0012 (pointe vers la table des éditeurs, pour trouver par exemple "galimard")

et également

Livre_id=00340278 (pointe vers la table des livres pour trouver à nouveau "les misérables"
Exemplaire_id=0004
ISBN=....
Editeur_id = 0027 (pointe vers la table des éditeurs, pour trouver par exemple "flammarion")

[aperikub]

d'accord la effectivement je vois le problème!
par contre étant donné que j'ai une cardinalité de 1,n entre livre et écrire (un livre peut avoir été écrit par un ou plusieurs auteurs), il n'y a pas de clé étrangère auteur dans l'entité livre et je ne peux la retrouver que dans l'association écrire est-ce que ce n'est pas problématique?

[escartefigue]

Effectivement, j'ai simplifié à outrance, il y a de nombreux livres ayant plusieurs auteurs.
La table associative est donc requise de ce point de vue, aucun problème.
Par contre les soucis liés à la redondance (et donc au non respect de la deuxième forme normale) subsistent !

Toute violation des formes normales se paye cash : incohérence des données, requêtes complexes, maintenance délicate et performances dégradées en sont les conséquences.
J'espère que vous avez appris les formes normales en cours, sinon c'est vraiment dommage car c'est fondamental

[aperikub]

je n'ai pas du etre clair, ce que je demandais c'est si ce n'est pas un problème de devoir aller chercher la clé auteur dans la table associative écrire plutot que de la trouver dans l'entité livre? (est-ce que c'est un fonctionnement normal?)
pour ce qui est des formes normales, j'y arrive, mais je les ai juste survolées pour l'instant (j'ai commencé les cours de b.d il y a 15 jours) pour l'instant je bloque sur le passage du modèle E/A au modèle relationnel (notamment les assertions qui sont écrites sous forme mathématique dans le cours et que j'ai beaucoup de mal à décoder)

[escartefigue]

Lors d'une insertion de livre, il faudra rechercher ses auteurs dans la table des auteurs et les créer si manquants.
La recherche peut se faire par exemple sur le nom+prénom, mais il faudra prévoir une sélection par l'utilisateur parmi les réponses possibles (ex : "Alexandre Dumas" père et fils )
Il faudra ensuite insérer autant d'occurrences dans la table écrire qu'il y a d'auteurs pour ce livre.

Lors de la consultation des éléments d'un livre, si on veut des infos sur ses auteurs, on passera effectivement par la table "écrire" pour retrouver le ou les identifiants des auteurs de ce livre ce qui permettra d'atteindre les bonnes lignes dans la table livre. C'est un fonctionnement tout à fait normal

J'espère que ça répond à la question ?

[aperikub]

parfaitement, merci beaucoup!