Discussion :

[MV1908]

Bonjour,

Je modélise actuellement une mini-application de réservation de salles de réunion dans une entreprise.
En gros, une salle peut être réservée à une date donnée par une personne donnée.

J'ai donc 3 entités de base : DATE (Jour, Heure), SALLE(id_salle), PERSONNE(id_personne), et une association ternaire : reservation (Jour#, Heure#, id_personne#, id_salle#, motif)

Jusque la, pas de problème.

Le truc est que l'application doit pouvoir suivre les modifications qui sont apportées aux réservations.

J'aimerais donc créer une table qui contienne toutes les modifications apportées aux réservations.

Ma question est donc de savoir quelle sera la structure de cette table 'modifications' :

• Il faut reprendre les 4 clés primaires de la table réservation et y adjoindre les attributs supplémentaires requis?

• Il faut ajouter un attribut 'id_resa' à la table réservation en auto_increment(possible si le champ n'est pas PK?), et ajouter une clé étrangère sur ma table 'modifications', pointant sur sur ce champ 'id_resa'?

Dans le 2eme cas, on obtiendrait alors la structure suivante :

reservation (Jour#, Heure#, id_personne#, id_salle#, motif, id_resa)
modification (id_modif, id_resa#) avec les attributs qui vont bien.

Votre avis??

Merci d'avance.

[fsmrel]

Je présente ici une approche mi-relationnelle mi-merisienne.
A priori, la structure de votre table Réservation n’a pas à être modifiée. En revanche, une modification porte sur une réservation et n’est donc qu’une propriété multivaluée de celle-ci. Elle fait donc normalement l’objet d’une entité (faible) Modification : son identifiant est celui de l’entité Réservation augmenté d’un attribut discriminant (id_modif). Le problème est qu’au sens Merise du terme, Réservation n’est pas une entité mais une relation et qu’à une relation on ne peut pas rattacher un objet, entité ou relation (ce qui a pour conséquence que si une relation est porteuse de propriétés, celles-ci ne peuvent pas être multivaluées, au risque d’enfreindre la première forme normale). Peu importe, rien ne vous empêche de transformer une relation en entité (disons associative) et de toutes façons, au niveau relationnel, il n’y a que des tables. Celles-ci pourraient être :

Réservation (id_salle, id_personne, Jour, Heure, motif)
Modification (id_salle, id_personne, Jour, Heure, id_modif, <attributs de la modification>)

où id_modif est un séquenceur relatif au quadruplet {id_salle, id_personne, Jour, Heure}

Maintenant, si vous souhaitez un incrément automatique pour les modifications, rendez l’attribut id_modif clé primaire à lui seul, comme dans le jeu de Create Table qui suit (personnellement, pour des raisons de performance, je préfère que le premier attribut entrant dans la composition de la clé primaire (id_salle) n’en soit pas éjecté, mais ceci est une autre histoire) :

Modification (id_modif, id_salle, id_personne, Jour, Heure, <attributs de la modification>)

Exemple de DDL (DB2)

CREATE TABLE RESERVATION (
ID_SALLE INT NOT NULL,
ID_PERSONNE INT NOT NULL,
JOUR DATETIME NOT NULL,
HEURE DATETIME NOT NULL,
MOTIF CHAR(64) NOT NULL,
CONSTRAINT PK_RESERVATION PRIMARY KEY (ID_SALLE, ID_PERSONNE, JOUR, HEURE)
CONSTRAINT FK_1 FOREIGN KEY...
) ;

CREATE TABLE MODIFICATION (
ID_MODIF ROWID NOT NULL,
ID_SALLE INT NOT NULL,
ID_PERSONNE INT NOT NULL,
JOUR DATETIME NOT NULL,
HEURE DATETIME NOT NULL,
... ,
CONSTRAINT PK_MODIFICATION PRIMARY KEY (ID_MODIF),
CONSTRAINT FK_M FOREIGN KEY (ID_SALLE, ID_PERSONNE, JOUR, HEURE)
REFERENCES RESERVATION ON DELETE CASCADE
) ;

Observation

J’ai réordonné les attributs dans la composition de la clé primaire de la table Réservation :
{id_salle, id_personne, Jour, Heure}
en effet, je suppose que l’élément qui intéresse d’abord l’utilisateur est la salle (évidemment je peux me tromper, mais le principe reste valable si c’est la personne ou la date). Je suis d’accord que selon la théorie relationnelle, on manipule des ensembles et que la notion d’ordre n’y a pas sa place. Cela dit, si au niveau de la modélisation le confort de l’utilisateur et le temps de réponse ne sont pas l’objet de l’étude, une fois en production, la chanson n’est plus la même.