Discussion :

[tesnimeronsard]

Bonjour ,

J ' ai une étude de cas a faire a rendre très prochainement , j 'ai du mal vraiment à saisir , je ne demande pas de me le faire bien sur , mais de m ' aiguiller tant au niveau des entités et des cardinalités.
Voici le sujet :

Une chaîne d’hôtels souhaite mettre en place un système informatisé de gestion des réservations de ses chambres. Ce système permettra par ailleurs d’assurer la gestion de la comptabilité de chaque hôtel.
Les clients pourront effectuer des réservations par Internet ou directement auprès de la réception d’un hôtel. Par internet, 30% du montant est réglé directement en ligne pour valider la réservation. L’origine de chaque réservation (internet ou par l’hôtel) est consignée pour des raisons statistiques. Dans tous les cas, un code d’identification est fourni au client, ce qui lui permet de gérer son compte par internet (réservation, changement).
Les hôtels sont identifiés par un code établissement. Les chambres se réservent par nuit complète, et sont réparties en plusieurs catégories de prix (Simple/Double/Double confort/Suite). Le prix par nuit varie en fonction des saisons. Dans chaque hôtel chaque chambre est identifiée par son numéro et son étage, et appartient à une catégorie de prix.
Chaque réservation s’effectue sous le nom d’une seule personne : nom, prénom, adresse, email, adresse postale. Lorsque le client quitte l’hôtel, une facture lui est émise avec l’ensemble des consommations de la chambre : mini-bar, blanchisserie, téléphone, services divers.
Le règlement peut s’effectuer de plusieurs façons : CB, liquide, chèque, autre. Une même facture peut être réglée avec plusieurs moyens de paiement (ex : réservation payée par internet, mais ajout d’autres consommations).

J' ai réalisé une premiere ébauche mais à 5h cela s' avère etre difficile.J ai crée les entités , cependant je pense devoir y ajouter une entité ou une association pour savoir si une chambre est reservée ou libre ou occupés.

Cela fait 5 jours que j ' y suis sans vraiment avancer.
je vous remercie de votre aide

[TheLeadingEdge]

Bonjour,
2 3 petites remarques.
D'abord sur les cardinalités.
Assoc. ''possède'' la cardinalité de ''Chambre'' devrait être 1,1.
Assoc. ''contient'' la cardinalité de ''Service'' devrait être 1,1.
Celles-ci concernent plus l'aspect sémantique.
Ds l'assoc. ''correspond'' la cardinalité de ''Reglement'' devrait être 1,n.
L'assoc. ''contient'' devrait être entre ''réservation'' et ''service'', plutôt qu'entre ''facture'' et ''service''.
Je verrai 1 assoc. entre ''Facture'' et ''Réservation'', plutôt qu'entre ''Facture'' et ''Client''. Tu as ''Client'' par transitivité et tu ne perd pas l'info de la ''réservation''. Tu peux retrouver ttes info. nécessaires pour établir ta facture : client, service, type de réservation (pour déduire l'accompte déjà versé si réservation internet)...
Si une réservation ne concerne qu'une seule chambre (fais valider la règle de gestion), tu as 1 card. 1,1 sur une des pattes de la ternaire ''réserve''. Tu peux la réduire.

je pense devoir y ajouter une entité ou une association pour savoir si une chambre est reservée ou libre ou occupés.

1 entité ''calendrier'' peut-être ?
Perso. j'ajouterai aussi des entités ''mode de règlement'', ''type de réservation'', ''type de service'' et ''adresse''. A toi de voir

J' ai réalisé une premiere ébauche mais à 5h cela s' avère etre difficile

Tu es bien parti. Bon courage pour la suite.

[fsmrel]

Bonjour,

J’ai écrit ce qui suit quand TleLeadingEdge ne vous avait pas encore répondu. Aussi, veuillez considérer mes réflexions comme un complément.

1) Vous avez établi une association entre des hôtels et des chambres et cette association peut être interprétée de la façon suivante :

Un hôtel possède plusieurs chambres et une chambre est possédée par plusieurs hôtels. Ceci ne reflète pas précisément la réalité : une chambre appartient à un seul hôtel.

2) Du fait des cardinalités N, votre association-type Réserve peut se lire ainsi :

Un client peut retenir plusieurs chambres et chaque chambre peut faire l’objet de plusieurs réservations (ou encore : un client peut effectuer plusieurs réservations et chacune concerner plusieurs chambres).

La même réservation peut être faite par plusieurs clients et concerner plusieurs chambres (ou encore : la même réservation peut être faite pour plusieurs chambres et concerner plusieurs clients).

Etc.

Or il préférable que l’on puisse lire : Une réservation concerne une seule chambre et un seul client (Réfléchissez ensuite au problème suivant : un client peut-il réserver la même chambre (dans le même hôtel) à des dates différentes ? Si oui, comment résoudre cela ?

=>

A chaque fois que vous définissez une association-type, effectuez-en la lecture, en faisant intervenir chaque entité-type qui participe et en tenant compte plus particulièrement des cardinalités maximales.

[tesnimeronsard]

Bonjour,

je vous remercie de vous réponses :

Identifiant de l' entité chambre :
La clé primaire de l' entité chambre ne peut pas être le numéro de la chambre car 2 hôtels différents peuvent posséder des chambres avec des mêmes numéros.J' ai essayé d indiquer un autre numéro en tant que clé primaire mais je me retrouve avec des doublons .

Bon je reposte vers 5h quand j ' aurai lu plus vos remarques attentivement.

merci encore

[TheLeadingEdge]

Bonjour,

La clé primaire de l' entité chambre ne peut pas être le numéro de la chambre car 2 hôtels différents peuvent posséder des chambres avec des mêmes numéros.J' ai essayé d indiquer un autre numéro en tant que clé primaire mais je me retrouve avec des doublons .

De la même manière que le n° de chambre est composé de l'étage et d'un n° séquentiel, ds la relation, ''chambre'' est 1 ''weak entity''. Sa PK est composée de celle de ''Hotel'' et d'un n° de chambre

[fsmrel]

Au niveau SQL :

Pour ne pas être embêté avec des histoires d’étages, vous utilisez le n° séquentiel proposé par TheLeadingEdge (numero, rebaptisé ici ChambreId) et, pour tenir compte du fonctionnel, vous définissez une clé alternative Chambre_AK1, dans laquelle, outre la clé de l’hôtel, figurent le n° d’étage et le n° de la chambre dans l’étage.

Une ébauche de création des tables (façon SQL Server 2005) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Create Table Hotel
(HotelId       Integer Identity Not null,
 NotelNom      Varchar(48) Not null,
 ...
 Constraint Hotel_PK Primary Key (HotelId)
) ;

Create Table CaregoriePrix  
(CategPrixId   Integer Identity Not null,
 ...
 Constraint CaregoriePrix_PK Primary Key (CategPrixId)
) ;

Create Table Chambre  
(HotelId       Integer Identity Not null,
 ChambreId     Integer     Not null,
 Etage         Char(3)     Not null,
 Numero        Integer     Not null,
 CategPrixId   Integer     Not null,
 ...  
 Constraint Chambre_PK Primary Key (HotelId, ChambreId),
 Constraint Chambre_AK1 Unique (HotelId, Etage, Numero),
 Constraint Chambre_Hotel_FK Foreign Key (HotelId) References Hotel,  
 Constraint Chambre_Categ_FK Foreign Key (CategPrixId) References CaregoriePrix  
) ;

[tesnimeronsard]

Bonjour ,

j' ai légèrement avancé
1-En ce qui concerne le modèle physique de données , je suis dessus moment . Cependant je pensais que lorsque j 'ai une clé primaire qui devient étrangère dans l' autre entité , elle devient par défaut clé primaire quand j ai une relation de type 1:N?
Ces contraintes suivent elles une règle bien défini?Cet attribut ou champ IdHotel est auto incrémenté?
Oui je sais je galère

2-Au niveau de du modèle conceptuel , à quel moment doit on utiliser des relations ternaires ?Comment les lis t on?Par exemple la relation ternaire entre les entités client , chambre et calendrier.

3-A TheLeadingEdge
Quand tu dis :
"Perso. j'ajouterai aussi des entités ''mode de règlement'', ''type de réservation'', ''type de service'' et ''adresse'' ,

je comprends bien que l adresse ou "localisation" sera relié au client mais aussi a l hotel , je me suis aussi demandé par rapport à ça si ces hotels peuvent situés à l' étranger , des clients peuvent il réserver aussi de l étranger ?
par rapport aux entres entités que tu as suggérer , j y réflechis et ce sont de bonnes idées , mais j ' ai vraiment du mal .

4 A fsmrel
un client peut-il réserver la même chambre (dans le même hôtel) à des dates différentes

j y pensais aussi , par rapport a la date non??


5-il y a une chose aussi qui est a prendre en compte , en cas d ' une annulation de commande , d ' un remboursement.Une entité annulation??

Je vous remercie de votre aide.

[hed62]

A propos des ternaires : tu peux en mettre une entre Saison, tarif et catégorie. En effet, une catégorie coute un tarif selon une saison


Pourquoi mettre un attribut "Libre" dans une relation "est occupée" ?

On ne peut régler une facture en plusieurs fois ?

Tes cardinalités semblent inversées : elles ne le sont pas.

[fsmrel]

Bonjour,

je pensais que lorsque j 'ai une clé primaire qui devient étrangère dans l' autre entité , elle devient par défaut clé primaire quand j ai une relation de type 1:N?
Ces contraintes suivent elles une règle bien défini?Cet attribut ou champ IdHotel est auto incrémenté?

Je vais répondre à votre question, mais en attendant, je vous prie de noter qu’à la suite d’un copier/coller intempestif, l’instruction CREATE TABLE Chambre que j’ai fournie est à rectifier :

Code :

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

1
2
3
4
Create Table Chambre  
(HotelId   Integer Identity  Not null, 
 ...
)

est à changer en :

Code :

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

1
2
3
4
Create Table Chambre  
(HotelId   Integer Not null,
 ...
)

En effet, la clause Identity appliquée à l’attribut HotelId a déjà été utilisée pour la table Hotel. Cette coquille a pu vous gêner, auquel cas je vous prie de m’excuser.

[fsmrel]

je pensais que lorsque j 'ai une clé primaire qui devient étrangère dans l' autre entité , elle devient par défaut clé primaire quand j ai une relation de type 1:N? Ces contraintes suivent elles une règle bien défini?Cet attribut ou champ IdHotel est auto incrémenté?

Pour commencer, évitez de mélanger l’emploi des concepts : l’entité (ou plus exactement entité-type) est un concept utilisé en modélisation conceptuelle (disons Merise). Clé primaire et clé étrangère sont des concepts qui ressortissent à SQL. Mais, lors de l’étape de passage du MCD au MLD, l’identifiant de chaque entité-type donne lieu à une clé primaire SQL.

Concernant les cardinalités 1:N, prenons le cas des entités-types Hotel et Chambre. La règle communément adoptée de dérivation (notamment par les outils de conception) est celle-ci :

1) L'identifiant HotelId de l’entité-type Hotel donne lieu à la clé primaire {HotelId} de la table Hotel.

2) Si l’entité-type Chambre est identifiée de manière absolue par ChambreId (c'est-à-dire si deux occurrences de l’entité-type ne peuvent pas prendre la même valeur pour la propriété ChambreId), cet identifiant donne lieu à une clé primaire singleton {ChambreId} (deux lignes de la table ne peuvent pas prendre la même valeur pour l’attribut ChambreId). Pour sa part, {HotelId} constitue une clé étrangère de la table Chambre, permettant de faire référence à la clé primaire {ChambreId} de la table Hotel.

3) En revanche, si l’entité-type Chambre est identifiée de manière relative, c'est-à-dire si Chambre est à considérer comme n’étant qu’une propriété d’Hotel (propriété multivaluée, puisqu’un hôtel comporte plus d’une chambre), alors ChambreId permet d’identifier chaque chambre, relativement à un hôtel. Au niveau tabulaire, la clé primaire de chambre est constituée du couple {HotelId, ChambreId}. Comme ci-dessus, {HotelId} constitue une clé étrangère de la table Chambre, permettant de faire référence à la clé primaire {ChambreId} de la table Hotel.

Exemple de MCD avec PowerAMC (notez l’emploi des parenthèses pour la cardinalité 1,1)



Concernant les exemples de CREATE TABLE que je vous ai précédemment proposés, j’ai pris le parti de procéder à l’identification relative.
Maintenant, il n’y a pas d’absolu quant aux règles de passage du niveau conceptuel au niveau logique (SQL). Un MCD (Modèle Conceptuel de Données) répond à des exigences relevant du formalisme Entité/Association (Merise en ce qui nous concerne), tandis que le MLD est soumis à d’autres règles. Par exemple, si l’on s’astreint à respecter la théorie relationnelle, on doit définir obligatoirement une clé candidate pour une table (dans cette théorie, le concept de clé primaire n’est plus mentionné qu’à titre historique). SQL pour sa part n’exige même pas que l’on définisse de clé quelle qu’elle soit (mais ceci est une autre histoire).

Incidemment, ne pas oublier que la table Chambre possède une clé alternative {Hotelid, Etage, Numero}, qui d'un point de vue SQL pourrait très bien remplacer {HotelId, ChambreId} en tant que clé primaire (bien que cela ne soit pas notre intention).

Concernant l’auto-incrémentation, il s’agit d’un procédé qui ne relève pas de la modélisation, on pourra en reparler plus tard. Concentrez-vous sur les aspects conceptuels de votre sujet.

[hed62]

(notez l’emploi des parenthèses pour la cardinalité 1,1)

Je rebondis sur cette précision : quelle différence entre 1,1 et (1,1) ?

[fsmrel]

Je rebondis sur cette précision : quelle différence entre 11 et (1,1) ?

L’emploi des parenthèses permet à PowerAMC de signifier que Chambre est identifiée relativement à Hotel. Avec Win’Design, on représente cela sous la forme : 1,1 (R), comme cela est montré dans la FAQ Merise.

[hed62]

Merci c'est donc spécifique à l'outil, et non une notation "normalisée"

[fsmrel]

A l’attention de tesnimeronsard.


Au sujet de l’association-type Occuper (ou EstOccupée) :
Vous avez défini des pattes à cardinalité maximale 1, ce qui se lit ainsi : "[Au cours de son existence] une chambre a été (ou est, ou sera) occupée une seule fois, en tout et pour tout (et en outre, par un seul client)." Ce qui revient à dire que cette chambre est l’exclusivité d’un certain client, lequel n’y aura mis qu’une seule fois les pieds dans sa vie. Qui plus est, ce client ne pourra jamais occuper une autre chambre d'hôtel (de la chaîne en question)...

Si la lecture doit être la suivante : "Une chambre donnée peut être occupée plusieurs fois", la cardinalité 1,1 côté Chambre doit être remplacée par 0,N.
De même, si un client peut occuper plusieurs chambres (sous-entendu au fil du temps), la cardinalité 1,1 côté Client doit être remplacée par 0,N.



Maintenant, si toutes les cardinalités maximales sont N, un autre problème se pose. En effet, implicitement, l’identifiant de l’association-type Occuper est représenté par le n-uplet {HotelId, ChambreId, ClientId, Jour}, ce qui revient à dire que la même chambre peut être occupée le même jour par plusieurs clients (et les booléens Reserve et Libre —au fait, pourquoi deux booléens ?— ne l’empêcheront pas et a priori ne sont ici d’aucune utilité).

On peut aussi penser que l’association-type Occuper fait double emploi avec l’association-type Réserver. Si l’on y réfléchit, une réservation peut être perçue comme une association entre une chambre et un client, pour une période donnée (pour le moment ignorons le cas du client qui réserve simultanément plus d’une chambre).



Éliminons donc du MCD l’association-type Occuper pour ne conserver que l’association-type Réserver. Problème à nouveau : vu du MCD, rien n’empêche que la même chambre puisse être réservée en même temps par plusieurs clients.

Pour résoudre ce problème,

- Soit vous abandonnez PowerAMC pour utiliser Win’Design qui permet de mettre en œuvre le concept de CIF (voir FAQ Merise) et ainsi de prendre en compte la contrainte Chambre X Jour → Client (pour une chambre donnée, et pour un jour donné il ne peut y avoir qu’un client).

- Soit vous déguisez l’association-type Réserver en entité-type Réservation (celle que vous avez définie disparaissant).

- Soit vous modifiez manuellement le MLD dérivé par l’AGL.

- Soit vous utilisez la représentation dite Entité/Relation de PowerAMC au lieu de la représentation Merise (le passage d'un mode à l'autre est effectué en un clic de souris...) Lançons-nous dans cette représentation, afin de voir autre chose. Notez soigneusement que les associations-types disparaissent, remplacées par des entités-types associatives.

Les cardinalités sont remplacées par d’autres symboles équivalents, dont l'interprétation est la suivante :

- Un hôtel comporte plusieurs chambres.

- Une chambre est une propriété multivaluée d’un hôtel (identification relative).

- Une chambre peut faire l’objet de plusieurs réservations.

- Une réservation est une propriété multivaluée d’une chambre (identification relative).

- Un client peut effectuer plusieurs réservations.

- Une réservation concerne un client.



Notez que la date de réservation ne participe pas à l’identification de l’entité-type Reservation (cette date est en effet modifiable, or on sait qu’il est préférable de préserver la stabilité des identifiants, à cause des opérations ultérieures).

Le MLD est le suivant :



Maintenant, je vous laisse réfléchir à tout cela...

[TheLeadingEdge]

re,
Si une réservation peut concerner plusieurs chambres, on est en présence d'un agrégat. la DF {date, chambre, client}--> réservation est bien une ternaire. Mais il existe aussi une DF {date, chambre}--> client dont il faut tenir compte. Sur le 1er schéma cette DF est matérialisée par une ''CIF''. qu'il conviendra de convertir en 1 AK. (cf Unicité d'une clef composée)
Pour autant on peut inverser les DF, et on obtient le 2nd schéma. Dans ce cas 1 PK (date, chambre) sera automatiquement crée pour la table ''réservation'' depuis les rel. identifiantes

NB: Je reviens sur le fait que ceci n'est valable que si 1 client peut réserver plusieurs chambres en 1 seule réservation. Si une réservation ne concerne qu'une seule chambre la patte correspondante de la ternaire a 1 card. 1,1. (CIF), ce qui signifie que ce n'est pas une 3-aire.

NB 2 : Ce cas a déjà été posé ici sur le forum. Tu trouveras peut-être des réponses à tes questions

[tesnimeronsard]

bonjour ,

C ' est vraiment pas facile d' appliquer toutes ces règles.

1-Pourquoi ne pourrais t on pas identifier la chambre par son Numéro de chambre et le CodeHotel?par exemple un IdChambre aussi peut identifier une chambre et on pourrait appliquer une contrainte d ' unicité aux identifiant NumeroChambre,CodeHotel.

2-en ce qui concerne la dépendance fonctionnelle ou contrainte d' integrité fonctionnelle :
Dépendance fonctionnelle des propriétés de la relation :
- je ne comprends pas pourquoi un client ne peut pas réserver la même chambre si je n ' ajoute pas une entité date.
-Pour une occurence d ' une relation les valeurs des propriétés de la relation doivent etres uniques???Quel est l ' identifiant de la relation?

exemple :

Dans le deuxiéme modèle proposé par TheLeadingEdge , cela me semble correct?

une réservation (entité) a pour identifiant IDnuméro mais elle dépendra des identifiants de chaque entité en relation avec elle .Mais pour autant , un client x pourra toujours effectué une réservation sur cette meme chambre un même jour.C ' est pour cela que je voulais ajouter un "statut" de la chambre qui indiquerait que celle ci est occupée ou réservée par un booléen(j' ai pris exemple sur le mcd proposé sur le site)



je sais bien que l ' on apprend pas à modéliser un Si en une semaine mais le je je me sens vraiment perdu .Je sais que j ' ai du mal et veuillez m ' en excusez .

Merci

[fsmrel]

Bonsoir,

Vous posez la question :

Pourquoi ne pourrais t on pas identifier la chambre par son Numéro de chambre et le CodeHotel? par exemple un IdChambre aussi peut identifier une chambre et on pourrait appliquer une contrainte d'unicité aux identifiant NumeroChambre, CodeHotel.

On vous a montré précédemment comment modéliser l’identification de la chambre, relativement à l’hôtel.
Je reprends (contexte PowerAMC) :


Ensuite, vous pouvez agir au niveau du MLD pour signifier que le couple {HotelId, Etage} est clé alternative (ak = alternate key). Pour ma part, j’ai pris la liberté de retenir le triplet {HotelId, Etage, Numero} :



Vous remarquerez que l'attribut HotelId de la table CHambre participe à la clé primaire, à la clé alternative et à une clé étrangère.

Et comme il n’est pas mauvais de savoir ce que donne au niveau SQL son travail de modélisation, on peut demander à l'AGL de produire les instructions permettant de créer les tables :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Create Table Hotel
(HotelId       Integer     Not null,
 HotelNom      Varchar(48) Not null,
 HotelAdresse1 Varchar(48) Not null, 
 CodePostal    Char(05)    Not Null,
 Ville         Varchar(48) Not null,
 Constraint Hotel_PK Primary Key (HotelId)
) ;
Create Table Chambre  
(HotelId       Integer     Not null,
 ChambreId     Integer     Not null,
 Etage         Char(3)     Not null,
 Numero        Integer     Not null,
 CategPrixId   Integer     Not null,  
 Constraint Chambre_PK Primary Key (HotelId, ChambreId),
 Constraint Chambre_AK1 Unique (HotelId, Etage, Numero),
 Constraint Chambre_Hotel_FK Foreign Key (HotelId) References Hotel) ;

Puis de préparer un embryon de jeu d’essai, pour les tests...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Insert Into Hotel Values (1, 'Hôtel du Nord', 'Quai de Jemmapes', '75010', 'Paris') ;
Insert Into Hotel Values (2, 'Hôtel du Midi', 'Quai des Brumes',  '50930', 'Couville') ;

Select * From Hotel  ;
 
Insert Into Chambre Values (1, 1, '0', 100, 5) ;       
Insert Into Chambre Values (1, 2, '0', 101, 5) ;        
Insert Into Chambre Values (1, 3, '1', 102, 4) ;        

Insert Into Chambre Values (2, 1, '1', 101, 3) ;        
Insert Into Chambre Values (2, 2, '1', 102, 3) ;    

Select * From Chambre ; 

Etc.

A un moment donné, il faudra effectivement s'assurer que tout cela fonctionne, que les règles de gestion des données sont blindées, avant qu'il ne soit trop tard...

[fsmrel]

Pour une occurence d ' une relation les valeurs des propriétés de la relation doivent etres uniques???Quel est l'identifiant de la relation?

Reprenons votre représentation graphique :



Dans tous les ouvrages traitant de Merise, il est écrit qu’une relation n’a pas d’identifiant propre. Celui-ci n'est donc pas représenté, il est virtuel et concernant la relation Reserver ci-dessus, peut être conçu comme étant constitué des identifiants de Client et de Chambre.

Au niveau logique, le résultat est le suivant (à la suite de mon précédent message, Chambre a pour identifiant le couple {HotelId, ChambreId}) :

Client {ClientId, CLientNom...}
Hotel {HotelId, HotelNom...}
Chambre {HotelId, ChambreId, ...}
Reserver {ClientId, HotelId, ChambreId, Date, NbreJours}

Considérez maintenant la représentation tabulaire suivante, dans laquelle on a souligné les clés primaires :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Client {ClientId, CLientNom, ...}
          cl1     Client Un


Hotel {HotelId, HotelNom, ...}
         ho1    Hotel Un  
         ho2    Hotel Deux

Chambre {HotelId, ChambreId, Etage, Numero, ...}
           ho1       1        '0'    100           
           ho1       2        '0'    101         

Reserver {ClientId, HotelId, ChambreId, Date, NbreJours}
           cl1       ho1        1        d1     n1
           cl1       ho1        2        d2     n2

Étant donné que pour une valeur de clé primaire, on ne peut pas avoir deux fois la même ligne dans la table, ceci vaut en particulier pour la table Reserver :
Ici, un client peut réserver deux chambres distinctes dans le même hôtel, pour des dates différentes ou non (d2 peut être remplacé par d1 et n2 par n1). Par contre, il ne peut pas réserver plus d’une fois la même chambre (disons la 1, celle qu’il aime tant), puisque cela conduirait à avoir deux fois la valeur <cl1, ho1, 1> pour la clé primaire de Reserver, en violation avec la règle.
Si on veut que le client puisse réserver plus d’une fois la même chambre dans le même hôtel, à des dates différentes, il faut modifier la composition de la clé primaire, en faisant par exemple intervenir la date (ou, de préférence, une donnée non sujette à modification, tel qu’un numéroteur de réservation relatif au triplet {ClientId, HotelId, ChambreId} ou plus simplement au couple, {HotelId, ChambreId} voire au singeton {HotelId} ou au singleton {ClientId}). Dans le cadre de l’exercice, on peut de se contenter de la date, ce qui se représente ainsi :

Reserver {ClientId, HotelId, ChambreId, Date, NbreJours}

Et cette fois-ci, il devient possible de réserver la même chambre à des dates différentes pour un client donné :

Code :

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

1
2
3
Reserver {ClientId, HotelId, ChambreId, Date, NbreJours}
            cl1       ho1        1       d1    n1
            cl1       ho1        2       d2    n2

Malheureusement, on se rend compte qu’il est possible d’injecter des lignes non légales dans la table Reserver :

Code :

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

1
2
3
4
Reserver {ClientId, HotelId, ChambreId, Date, NbreJours}
            cl1       ho1        1       d1    n1
            cl1       ho1        2       d2    n2
            cl2       ho1        1       d1    n2

Autrement dit, deux client(e)s pourront se retrouver en même temps dans la même chambre... Il est prudent d’évacuer l’attribut ClientId de la clé primaire, qui se résume donc à {HotelId, ChambreId, Date}, auquel cas la ligne <cl2, ho1, 1, d1, n2> ne pourra pas exister :

Code :

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

1
2
3
4
Reserver {ClientId, HotelId, ChambreId, Date, NbreJours}
           cl1       ho1        1        d1    n1
           cl1       ho1        2        d2    n2
           cl2       ho1        1        d1    n2     /* Impossible */

Maintenant, il faut pouvoir produire cette représentation à partir d’un MCD. Or, la table Reserver est inférée d’une association-type Reserver, mais étant donné que celle-ci n’a pas d’identifiant propre et qu’on peut considérer celui-ci comme l’ensemble des identifiants des entités-types participant à l’association, l’attribut Date doit être issu d’une entité-type factice que l’on peut nommer par exemple Calendrier, qu’il faudra évidemment ne pas générer au niveau tabulaire, puisqu’elle n’y joue strictement aucun rôle.

Problème encore : si les entités-types participant à l’association Reserver sont Chambre, Calendrier et Client, par définition l’identifiant de Client participe à l’identifiant (virtuel) de Reserver. Pour faire en sorte qu’il n’en soit pas ainsi et bannir Client de l’identification, il faut en passer par la mise en œuvre de la CIF décrite par TheLeadingEdge dans son message du 12 février.
http://www.developpez.net/forums/sho...6&postcount=15

Vous pouvez aussi reprendre la représentation E/R figurant en bas de mon message du même jour.
http://www.developpez.net/forums/sho...5&postcount=14

[fsmrel]

je voulais ajouter un "statut" de la chambre qui indiquerait que celle ci est occupée ou réservée par un booléen

Ce statut concerne une chambre à une date : l’association-type Reserver permet de savoir si une chambre fait l’objet d’une réservation à une date donnée. Il suffira donc d’interroger la table Reserver pour savoir si la chambre "1" de l’hôtel "ho1" est libre à la date "dx". Par exemple (pseudo-requête à adapter en fonction du SGBD) :

Code :

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

1
2
3
4
SELECT   "Pas libre"  
FROM     Reserver
WHERE    HotelId = "ho1" AND ChambreId = 1
AND      "dx" >= Date AND "dx" < Date + NbreJours  ;

A la rigueur, vous pourriez ajouter à Reserver un attribut de type booléen, permettant de savoir si la réservation a été confirmée.

je sais bien que l ' on apprend pas à modéliser un S.I. en une semaine mais le je je me sens vraiment perdu

Il est bon dans ce genre de situation d’avoir sous la main un ouvrage qui tienne la route, très complet, dans lequel les concepts sont soigneusement exposés et où l’on apprend à les manipuler correctement. N’hésitez pas à acquérir l’ouvrage ci-dessous, ça sera un bon investissement.
Merise par D. Nanci et B. Espinasse

[tesnimeronsard]

bonjour,
je te remercie pour ton aide , en effet je pense que je vais me procurer ce livre en éspérant qu' il m' aidera à assimiler les notions importantes .

je me suis dit , autant mieux mettre une propriété occupé de type booléen à chambre .
j ai pas envie de vous casser la tete avec ca , voila je fournis mon mcd , j ai quelque difficultés avec les cardinalités , je les lis à l envers on dirait.