Discussion :

[Julien Rozier]

Bonjour,

Je cherche à développer un système simple de gestion de réservations de vidéo projecteurs pour mon institut.

J'ai eu quelques vieilles expériences avec SQL et les modélisations MCD/MLD mais elle ne sont pas suffisantes.

Le scénario:

Un prof passe sur une interface
-rentre ses infos (nom...)
-Choisi la date ou il souhaite disposer d'un video proj parmi une liste de dates
-Choisi le modèle de video proj (10 modèles en tout et 2 vidéos proj par modèle)
-Choisi un créneau parmi 10 (8h-9h, 9h-10h...)

L'idée est que s'il choisit le vidéo proj "toto", il peut voir directement s'il est dispo ou pas pour ce créneau et date là... Et si oui le reserver biensur

j'ai fais plusieurs MCD tous un peu différents mais je n'arrive pas à me convaincre.
En fait je n'arrive pas à voir quelles associations je dois mettre en place entre les entités...
Je n'ai pas géré les cardinalités non plus pour l'instant

[Julien Rozier]

Bonjour,

depuis hier j'ai rajouté un nouveau champ dans la table videoProj pour gérer le fait qu'il y'en ait 2 de disponibles / modèle.

Quelqu'un peut valider ou non mon modèle? Merci à vous

Bon dimanche

[hed62]

Je vois une entité-type Réservation et une association-type Réeserve... D'instinct je dirai qu'il y a un plroblème est que les deux ne font qu'un.

L'association-type entre le videoproj et les date se retrouve par calcul (toutes les dates - dates réservées) et ne doit donc pas figurer.

[Julien Rozier]

En effet la table RESERVATION ne sert à rien vu que je peux rajouter le champ dateReservation dans l'association "reserve". je n'y avais pas pensé
Merci

Pour le reste c'est correct ?

[hed62]

A première vue.. Je n'ai pas trop le temps de regarder en détails, mieux vaut attendre le passage de JPhi, fsmrel, TheLeadingEdge ou tout autre expert.

[JPhi33]

Julien,

Je pars de l'hypothèse que l'entité Réservation n'existe plus. Du coup, l'association Effectue non plus.

L'association Réserve (dimension 5 ! ! !) est plus que suspecte. Déjà qu'on se méfie lorsqu'une association atteint la dimension 3, là, il y a de quoi y regarder de près. Sans l'entité Réservation, elle passe à dimension 4.

L'idée directrice de la modélisation des données est la description de l'organisation de données permettant de fournir les informations au professeur et d'enregistrer les informations qu'il fournit. Il ne faut pas se laisser guider par les actions effectuées lors de la réservation. Ceci conduit invariablement à commettre des erreurs de modélisation.

Les entités identifiées sont correctes, me semble-t-il : Professeur, Vidéo-Proj (VProj), Créneau, Date. Pour les associations, par contre, j'ai l'impression que c'est un peu plus flou.

L'objectif principal est de savoir si un VProj est réservé ou non. Il y a une manière très simple de le modéliser : si on a une association entre VProj et Créneau+Date, on peut dire que, pour un VProj et un Créneau+Date donnés, lorsque l'occurrence de l'association existe, c'est que le VProj est réservé, sinon c'est qu'il est disponible.

Créneau+Date peut se modéliser en considérant qu'un Créaneau n'a pas d'existence seul, c'est simplement un numéro d'ordre dans une journée (identification relative). Pour l'identifier complètement (identification absolue) il doit être complété d'une Date. Créneau est donc une entité identifiée relativement à une Date : c'est ce qu'on appelle une entité faible.
L'Entité Créneau pourrait ressemble à ça :

Code :

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

1
2
3
4
5
1   8h-9h
2   9h-10h
3   10h-11h
...

Pour pouvoir identifier un créneau concrètement, il faut qu'il ressemble à ça :

Code :

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

1
2
3
4
5
6
7
8
9
15/04/2008   1   8h-9h
15/04/2008   2   9h-10h
15/04/2008   3   10h-11h
...
16/04/2008   1   8h-9h
16/04/2008   2   9h-10h
16/04/2008   3   10h-11h
...

On le modélise :
: Créneau :--1,1----( relatif à )----0,n->[ Date ]

En formalisme EA, Créneau est en traits pointillés. Ceci sous-entend que l'identifiant absolu de Créneau est idDate+NumCréneau.

Il n'y a plus qu'à associer Créneau et VProj :
[ VProj ]--0,n----( Réservation )----0,n--: Créneau :
Comme prévu, la date de réservation (date à laquelle le professeur a effectué l'action de réserver) peut se situer dans l'association Réservation.

La réservation d'un VProj donné à un créneau donné, ne peut avoir été faite que par un seul Prof. Donc :
( Réservation )--1,1----( est effectuée )----0,n->[ Prof ]

Modèle 1



"( est effectuée )" est une association (plus exactement une CIF) entre une entité et une autre association. Impossible à modéliser avec les outils existants. Il faut donc procéder de manière artificielle en créant une pseudo entité Réservation :

[ Réservation ]--1,1----( a-un )----0,n->[ VProj ]
[ Réservation ]--1,1----( a-un )----0,n->: Créneau :
[ Réservation ]--1,1----( est effectuée )----0,n->[ Prof ]

Modèle 2



On peut se rapprocher du modèle 1 en identifiant Réservation relativement à VProj et Créneau. idRéservation sera alors remplacé par idVProj+(idDate+NumCréneau). Le MLD dérivé de ce 3e modèle sera alors identique à celui du modèle 1.

Dans les 1er et 3e modèles, il est plus simple que dans le modèle 2 de déterminer si un Vidéo-proj est réservé ou non : une fois qu'on a le VProj, la Date et le Créneau, il suffit de vérifier par requête si la ligne correspondante existe ou non dans la table issue de l'association (ou pseudo entité) Réservation, et le tour est joué ! Si on a un modèle de VProj et non pas le numVProj, alors il faut faire la même requête mais pour chaque VProj correspondant à ce modèle.


Voila ! Simple, non ?


JPhi33

[Julien Rozier]

Merci beaucoup pour ta réponse !

J'ai pas tout compris

Julien,

Je pars de l'hypothèse que l'entité Réservation n'existe plus. Du coup, l'association Effectue non plus.

L'association Réserve (dimension 5 ! ! !) est plus que suspecte. Déjà qu'on se méfie lorsqu'une association atteint la dimension 3, là, il y a de quoi y regarder de près. Sans l'entité Réservation, elle passe à dimension 4.

Pourquoi ?

L'idée directrice de la modélisation des données est la description de l'organisation de données permettant de fournir les informations au professeur et d'enregistrer les informations qu'il fournit. Il ne faut pas se laisser guider par les actions effectuées lors de la réservation. Ceci conduit invariablement à commettre des erreurs de modélisation.

OK

Les entités identifiées sont correctes, me semble-t-il : Professeur, Vidéo-Proj (VProj), Créneau, Date. Pour les associations, par contre, j'ai l'impression que c'est un peu plus flou.

L'objectif principal est de savoir si un VProj est réservé ou non. Il y a une manière très simple de le modéliser : si on a une association entre VProj et Créneau+Date, on peut dire que, pour un VProj et un Créneau+Date donnés, lorsque l'occurrence de l'association existe, c'est que le VProj est réservé, sinon c'est qu'il est disponible.

Créneau+Date peut se modéliser en considérant qu'un Créaneau n'a pas d'existence seul, c'est simplement un numéro d'ordre dans une journée (identification relative). Pour l'identifier complètement (identification absolue) il doit être complété d'une Date. Créneau est donc une entité identifiée relativement à une Date : c'est ce qu'on appelle une entité faible.
L'Entité Créneau pourrait ressemble à ça :

Code :

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

1
2
3
4
5
1   8h-9h
2   9h-10h
3   10h-11h
...

Pour pouvoir identifier un créneau concrètement, il faut qu'il ressemble à ça :

Code :

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

1
2
3
4
5
6
7
8
9
15/04/2008   1   8h-9h
15/04/2008   2   9h-10h
15/04/2008   3   10h-11h
...
16/04/2008   1   8h-9h
16/04/2008   2   9h-10h
16/04/2008   3   10h-11h
...

On le modélise :
: Créneau :--1,1----( relatif à )----0,n->[ Date ]

En formalisme EA, Créneau est en traits pointillés. Ceci sous-entend que l'identifiant absolu de Créneau est idDate+NumCréneau.

Il n'y a plus qu'à associer Créneau et VProj :
[ VProj ]--0,n----( Réservation )----0,n--: Créneau :
Comme prévu, la date de réservation (date à laquelle le professeur a effectué l'action de réserver) peut se situer dans l'association Réservation.

La réservation d'un VProj donné à un créneau donné, ne peut avoir été faite que par un seul Prof. Donc :
( Réservation )--1,1----( est effectuée )----0,n->[ Prof ]

Modèle 1



"( est effectuée )" est une association (plus exactement une CIF) entre une entité et une autre association. Impossible à modéliser avec les outils existants. Il faut donc procéder de manière artificielle en créant une pseudo entité Réservation :

[ Réservation ]--1,1----( a-un )----0,n->[ VProj ]
[ Réservation ]--1,1----( a-un )----0,n->: Créneau :
[ Réservation ]--1,1----( est effectuée )----0,n->[ Prof ]

Modèle 2



On peut se rapprocher du modèle 1 en identifiant Réservation relativement à VProj et Créneau. idRéservation sera alors remplacé par idVProj+(idDate+NumCréneau). Le MLD dérivé de ce 3e modèle sera alors identique à celui du modèle 1.

Dans les 1er et 3e modèles, il est plus simple que dans le modèle 2 de déterminer si un Vidéo-proj est réservé ou non : une fois qu'on a le VProj, la Date et le Créneau, il suffit de vérifier par requête si la ligne correspondante existe ou non dans la table issue de l'association (ou pseudo entité) Réservation, et le tour est joué ! Si on a un modèle de VProj et non pas le numVProj, alors il faut faire la même requête mais pour chaque VProj correspondant à ce modèle.


Voila ! Simple, non ?


JPhi33

Merci beaucoup pour ces explications très claires. J'ai appris plein de choses.
J'ai compris la façon d'associer un vidéoProj à une date+créneau mais y'a un truc flou dans ma tête..
Quelle requête pour afficher si pour un vidéoProj donné à une date donnée est dispo ou pas à un créneau donné ?

Je reprends les schémas devant une feuille et un stylo ce soir. Peut être que je m'autorépondrais

[JPhi33]

Quelle requête pour afficher si pour un vidéoProj donné à une date donnée est dispo ou pas à un créneau donné ?

Après dérivation du MCD 1 en MLD, tu obtiens la table (clés soulignées, clé étrangère suffixée par #) :
RESERVATION(Date, idCréneau, idVProj, date_reservation, idProf#).

Si un VProj est réservé à une date et un créneau donnés, il fait l'objet d'une ligne dans cette table.

Exemple (dans lequel je me limite aux 2 premiers créneaux du 21/04/2008 et aux VProj 1 et 2) :

Code :

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

1
2
3
4
5
6
Date       idCreneau idVProj date_reservation idProf
---------- --------- ------- ---------------- ------
21/04/2008 1         vp1     07/04/2008       pr03
21/04/2008 2         vp1     09/04/2008       pr17
21/04/2008 2         vp2     16/04/2008       pr09

Le prof pr06 voudrait réserver le vp1 pour le créneau 1 du 21/04. La requête pourrait être celle-ci :

Code :

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

1
2
3
4
5
6
Select date_reservation, idProf
  From RESERVATION
 Where Date = '21/04/2008'
   And idCreneau = '1'
   And idVProj = 'vp1'

Résultat : réservé par pr03 le 07/04/2008.

Pas de chance ! Il se rabat alors sur le vp2, même date, même créneau. La même requête avec ces nouveaux paramètres donne : aucune ligne. Le vp2 est donc dispo à cette date+créneau. Il réserve --> requête d'insertion dans la table dont le contenu devient :

Code :

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

1
2
3
4
5
6
7
Date       idCreneau idVProj date_reservation idProf
---------- --------- ------- ---------------- ------
21/04/2008 1         vp1     07/04/2008       pr03
21/04/2008 2         vp1     09/04/2008       pr17
21/04/2008 2         vp2     16/04/2008       pr09
21/04/2008 1         vp2     16/04/2008       pr06

Simple, non ?


JPhi33

[Julien Rozier]

Merci beaucoup !

Mon système marche enfin