Gestion d'une bibliothèque

**LhIaScZkTer** · 28/05/2009, 15h44

Salut à tous,

J'ai réalisé un mcd pour la gestion d'une bibliothèque, mais je ne suis vraiment pas sûr du résultat

Voici les contraintes que j'ai :

-Le membre de la bibliothèque paye une cotisation pour l'année en cours qui lui permet d'emprunter des livres, magazines et cd de musique. Toutefois, certains documents ne peuvent pas être emprunté.
-Gestion des prêts et retours, avec un système de relance en cas de retard.
-Possibilité de réserver un livre s'il n'est pas disponible pour le prêt
-Gestion des abonnements

Fais-je bonne route ?
Il y a des choses qui ne me plaisent pas dans mon MCD...

Merci à tous pour votre aide

**LhIaScZkTer** · 29/05/2009, 12h16

Salut à tous,

je mets le pdf détaillant le sujet au cas où je me serais mal exprimé

Merci pour votre aide.

**Metafire18** · 29/05/2009, 13h07

Je ne vois pas l'utilité de la table "Date-emprunt"

Quelle partie de ton MCD s'occupe de gérer les abonnements?

**LhIaScZkTer** · 29/05/2009, 17h42

Salut Metafire18 merci pour ton aide

Tu as raison pour date_emprunt à la base je l'avais mise dans EMPRUNTER. Mais quelque chose me gêne dans cette relation car :

Un usager peut emprunter un ou plusieurs livre
Un livre peut être emprunté une ou plusieurs fois mais pas à la même date et à condition qu'il aie été rendu

Quelque chose me dérange là-dedans, je ne saurais dire quoi, mais ça se situe entre la relation RESERVATION et EMPRUNTER...

Pour la gestion des abonnements, j'ai fait plus que simple, c'est la relation COTISER qui s'occupe de ça. Le membre ne peut emprunter des livres qu'à condition d'avoir payé la cotisation annuel. C'est pas une bonne idée ?

**JPhi33** · 29/05/2009, 23h35

Bonjour,

Envoyé par LhIaScZkTer

Tu as raison pour date_emprunt à la base je l'avais mise dans EMPRUNTER.

Non, c'est toi qui a raison LhIaScZkTer.

Si l'entité DATE_EMPRUNT disparaît, un usager ne peut emprunter un même document qu'une seule fois ; sauf si on choisit de détruire l'occurrence de EMPRUNTER lorsque l'usager retourne le document mais, dans ce cas, on perd l'historique des emprunts.

Envoyé par LhIaScZkTer

Mais quelque chose me gêne dans cette relation car :

Un usager peut emprunter un ou plusieurs livre
Un livre peut être emprunté une ou plusieurs fois mais pas à la même date et à condition qu'il aie été rendu

Le seul cas de figure qui ne peut pas être géré avec l'association EMPRUNTER telle que tu l'as modélisée, c'est celui dans lequel un usager emprunte un document le matin, le retourne à midi et veut l'emprunter de nouveau le soir.

On admettra qu'il s'agit d'un cas marginal.

Quelques remarques complémentaires :

Tu n'a pas modélisé le fait qu'il existe 2 types de cotisation : 1) livres et périodiques ; 2) livres, périodiques et CD.
Un seul usager à la fois peut réserver un même document. Sans être une erreur, c'est une faiblesse du système.
La propriété est emprunté (dans RESERVATION) ne sert à rien.
Pour les documents consultables que sur place, les associations EMPRUNTER et RESERVATION ne sont pas pertinentes. Le MCD peut être amélioré en utilisant la généralisation/spécialisation.

**Metafire18** · 30/05/2009, 09h33

Envoyé par JPhi33

Si l'entité DATE_EMPRUNT disparaît, un usager ne peut emprunter un même document qu'une seule fois ; sauf si on choisit de détruire l'occurrence de EMPRUNTER lorsque l'usager retourne le document mais, dans ce cas, on perd l'historique des emprunts.

Dans ce cas, si l'on garde la table Date_emprunt, on pourrait faire migrer date_retour et date_rendu de la relation emprunter dans la table Date_emprunt non? Comme ça on a effectivement un historique mais celui ci sera un peu plus complet

**JPhi33** · 31/05/2009, 08h52

Envoyé par Metafire18

on pourrait faire migrer date_retour et date_rendu de la relation emprunter dans la table Date_emprunt non? Comme ça on a effectivement un historique mais celui ci sera un peu plus complet

Oui et non.

Oui pour date_retour car celle-ci est calculée à partir de la date d'emprunt : "L'emprunt est valable pour un mois" (énoncé). Mais cette modélisation restreint l'évolutivité du système : impossible d'avoir des dates de retour différentes pour des types d'usagers différents ou pour des types de documents différents. Par exemple, si on souhaite limiter la durée d'emprunt des périodiques à 2 semaines au lieu d'un mois, ce sera impossible.
La meilleure modélisation pour date_retour est de rester dans l'association EMPRUNTER. (donc, au final, c'est non)

Non pour date_rendu car celle-ci peut être différente d'un emprunt à l'autre. Un même usager empruntant deux documents le même jour ne va pas obligatoirement les rendre à la même date.

**LhIaScZkTer** · 01/06/2009, 17h08

Salut JPhi33, Metafire18 et merci encore pour votre aide

JPhi33, tu donnes une nouvelle dimension à l'énoncé qui m'a été donné que je n'avais compris.

D'un point de vue totalement sémantique, et c'est ce qui m'a beaucoup perturbé, je croyais qu'il n'y avait qu'un abonnement, mais avec des règles sur les emprunts...

il paye une cotisation pour l’année en cours

pourquoi ne pas avoir dit, il existe deux types de cotisations etc... décidément

Donc, si je comprends bien, maintenant, il y a deux type d'abonnement qui :

permet d'emprunter des livres et des périodiques mais pas de CD, donc au totalement 8 documents par mois, avec le quota qui va bien par document
permet d'emprunter des livres, des périodiques et des CD, donc au total 11 documents par mois, avec le quota qui va bien par document

Je vais corriger le MCD à cette effet.

Pour en revenir à la RESERVATION.
Je crois que je devrais utiliser le même type d'approche que pour EMPRUNTER. Car un livre peut être emprunté 0 à N fois par plusieurs usager à des dates différentes. J'avais mis ce booléen est_emprunte pour dire qu'une réservation a été concrétisé par l'emprunt, donc que le livre peut de nouveau être réservé. Sinon je vois pas trop comment faire ...

Pour le détournement de éditeur et auteur, pour stocker les maisons de disques et les groupes ou chanteurs, je me suis pas fatigué et ai décidé que ça irait bien comme ça.

Merci encore pour votre aide

**LhIaScZkTer** · 02/06/2009, 10h11

J'ai modifié mon MCD et voilà ce que ça donne.

Qu'en pensez-vous ?
Ce qui me gêne toujours, c'est que plusieurs usagers peuvent réserver un livre le même jour, donc la règle c'est quoi ? Le premier arrivé est le premier servi

Puisque j'y suis, la gestion de la recherche et de réservation, comment la comprenez-vous ? Moi, je pense à :
L'utilisateur va vers le/la bibliothécaire lui demande d'effectuer une recherche et ou une réservation.

Donc, c'est un logiciel non orienté usager de la bibliothèque, mais bibliothécaire.

**JPhi33** · 02/06/2009, 19h16

Bonjour,

Envoyé par LhIaScZkTer

Qu'en pensez-vous ?

Telle qu'elle est modélisée, l'association COTISER signifie que pour un type de cotisation (et il n'y en a que 2), on a un seul couple (usager, année).
Autrement dit, chaque année, seuls 2 usagers pourront cotiser, un pour chaque type d'abonnement ! --> à revoir

Envoyé par LhIaScZkTer

Ce qui me gêne toujours, c'est que plusieurs usagers peuvent réserver un livre le même jour, donc la règle c'est quoi ? Le premier arrivé est le premier servi

L'association RESERVER permet d'enregistrer plusieurs réservations à la même date pour le même document. La règle "le premier à réserver ce jour là, sera le premier à pouvoir emprunter" est envisageable. Encore faut-il pouvoir déterminer qui est le premier à réserver. A cette fin, on peut rajouter un numéro d'ordre dans l'association RESERVER. Il ne servira que dans ce cas-là. Dans tous les autres cas, il sera inutile.

Envoyé par LhIaScZkTer

Puisque j'y suis, la gestion de la recherche et de réservation, comment la comprenez-vous ? Moi, je pense à :
L'utilisateur va vers le/la bibliothécaire lui demande d'effectuer une recherche et ou une réservation.
Donc, c'est un logiciel non orienté usager de la bibliothèque, mais bibliothécaire.

L'énoncé demande simplement qu'il y ait une "gestion de recherche d'ouvrage et de réservation". Il ne précise pas qui en est l'utilisateur. Mais de toute façon, ce n'est pas une préoccupation qui relève du modèle statique (MCD) du système.

**LhIaScZkTer** · 03/06/2009, 11h55

Encore une fois JPhi33 merci pour ton aide

C'est vrai qu'après génération du MLD on voit mieux les incohérences surtout au niveau de la gestion des abonnements. Je pensais qu'il allait me générer une entité COTISER avec comme identifiant id_user et date et avec attribut id_abonnement ... bref...

J'ai mis la cardinalité de type_abonnement à 0,N. Le problème est que maintenant je peux avoir 2 abonnement différent par année et par personne, je mettrais une restriction au niveau de l'application...

Pour le numéro d'ordre que tu préconises, c'est effectivement une bonne idée. Je pense utiliser un attribut de type Time pour connaitre l'heure où le document est réservé cela ira impeccablement bien. Toutefois un problème persiste, l'interrogation de la base pour savoir si une réservation a été honorée sera catastrophique, car trop compliquée.

Je dois vraiment être moisi du cerveau

Pour la gestion de la recherche, je sais qu'elle ne fait pas partie du MCD, c'était juste pour avoir une explication extérieur, vu que je comprends tout de travers...

Merci encore pour ton aide

**JPhi33** · 03/06/2009, 23h32

Bonjour,

Envoyé par LhIaScZkTer

J'ai mis la cardinalité de type_abonnement à 0,N. Le problème est que maintenant je peux avoir 2 abonnement différent par année et par personne, je mettrais une restriction au niveau de l'application...

Ce que tu voulais modéliser est la chose suivante :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 [ USAGER ]
     |
    0,n
     |
     |
( COTISER )--1,1----( CIF )----0,n->[ TYPE_ABONNEMENT ]
     |
     |
    0,n
     |
 [ ANNEE ]

exprimant que, pour un couple (usager, année), il y a un et un seul type d'abonnement.

Envoyé par LhIaScZkTer

Toutefois un problème persiste, l'interrogation de la base pour savoir si une réservation a été honorée sera catastrophique, car trop compliquée.

Tu as été un peu trop loin pour la réservation. Il fallait bien changer la cardinalité de la patte RESERVER----DOCUMENT de 0,1 en 0,n mais associer une nouvelle entité DATE_RESERVATION à l'association RESERVER me semble excessif. Le besoin d'historiser les réservations n'apparaît pas.

Voici comment je gérerais les réservations :

l'usager U réserve le document D --> création d'une occurrence (U,D) dans RESERVER
U emprunte D --> suppression de l'occurrence (U,D) dans RESERVER (elle peut ne pas exister car on peut emprunter sans avoir réservé !)

Par contre, l'idée de la date et de l'heure dans l'association RESERVER est à retenir. En effet, en cas de réservations multiples, c'est-à-dire l'existence d'occurrences (U1,D), (U2,D), etc., l'usager ayant la préséance est celui ayant réservé le plus tôt.

**LhIaScZkTer** · 04/06/2009, 11h02

Salut JPhi33 merci pour ton aide

Cela m'aura permis de creuser un peu plus les CIF
Dépendance fonctionnnelle et CIF

Mon cours dit :

Une CIF sur plusieurs entités participant à une même relation exprime que l'une des entités est totalement déterminée par l'existence d'une ou de plusieurs autres entités.

La CIF traduit un lien fort et permanent de dépendance d'une entité par rapport à une ou plusieurs autres entités. Dans le cas où le lien n'est pas permanent dans le temps, il s'agira d'une dépendance fonctionnelle(DF) entre objets.

Un lien très intéressant aussi CIF

Donc, on est d'accord sur le fait que quand je génèrerai le MLD, la relation COTISER deviendra une entité à part entière et prendra la forme suivante :
COTISER(id_user,date,id_type_abonnement)

Je me cite :

Je pensais qu'il allait me générer une entité COTISER avec comme identifiant id_user et date et avec attribut id_abonnement ... bref...

Tout cela pour dire, que c'est pas ma faute si j'arrive pas à faire une CIF avec mon logiciel Open ModelSphere, je ne maîtrise pas encore la bête

Pour la relation RESERVER, encore une fois, tu as raison, ça me fait mal d'admettre que je suis un gland

As-tu déjà pensé à être prof ou écrire un livre "La modélisation pour les nuls" par exemple ?
C'est pas donné à tout le monde de donner des explications aussi claires et bien construites que les tiennes.

Je te remercie encore une fois pour ta/tes réponses.

**JPhi33** · 06/06/2009, 14h17

Bonjour,

Envoyé par LhIaScZkTer

Donc, on est d'accord sur le fait que quand je génèrerai le MLD, la relation COTISER deviendra une entité à part entière et prendra la forme suivante :
COTISER(id_user,date,id_type_abonnement)

Oui et id_type_abonnement serait une clé étrangère.

Sauf que Open ModelSphere ni aucun autre logiciel de modélisation ne te permettra de créer une CIF ni aucune association (une CIF est une association) entre TYPE_ABONNEMENT et COTISER, car COTISER est déjà une association.

Pour parvenir à modéliser cette partie, il faut utiliser une astuce : transformer COTISER en entité et la relier à USAGER et ANNEE par des liens identifiants mais je ne sais pas si Open ModelSphere sait le gérer correctement.

Par exemple, le lien identifiant suivant signifie que COTISER est identifiée par l'identifiant de USAGER (id_usager):

[ COTISER ]--(1,1)----( )----0,n->[ USAGER ]

(la notation (1,1) pour les liens identifiants est celle de PowerAMC)

En répétant l'opération côté ANNEE, on obtient une entité COTISER identifiée par id_usager et date (identifiant de ANNEE), c'est-à-dire l'identifiant de COTISER en tant qu'association... et le tour est joué !