Discussion :

[fsmrel]

Bonsoir,

j ai quelque difficultés avec les cardinalités , je les lis à l envers on dirait

Il y a juste une inversion. Concernant l’association Association_9, on lit : "Un mode de règlement participe une seule fois à l’association" et un règlement participe plusieurs fois à l’association". Il est évident qu’il faut lire le contraire. Le mot clef dans cette affaire est "participe" : Une entité E participe ... fois à l'association R. Une fois que l’on a compris cela, il n’y a plus de problème.

je me suis dit, autant mieux mettre une propriété occupé de type booléen à chambre

Il s’agit d’une redondance, puisque, comme je l’ai déjà écrit, il suffit Il d’interroger la table Reserver pour savoir si la chambre "1" de l’hôtel "ho1" est libre à la date "dx". Or, l’expérience des bases de données prouve que là où est la redondance, l’incohérence se précipite et s'installe, malgré toutes les précautions manuelles que l’on peut prendre. Si vous tenez à conserver l’attribut redondant, il sera nécessaire au niveau SQL que vous programmiez un trigger contrôlant de façon automatique que la redondance est cohérente.


Je note en passant que vous n’avez pas identifié Chambre relativement à Hotel : avec PowerAMC, il vous suffit de cocher la case "Identifiant" de la fenêtre "Propriétés du lien d’association" (elle-même ouverte quand on double clique sur le lien connectant Chambre et Possède).


Concernant Reservation : vous préférez utiliser une entité-type plutôt qu’une association-type et c’est tout à fait votre droit. Mais alors, utilisez l’identification relative : une réservation est une propriété d’une chambre (elle même propriété d'un hôtel : on est dans une logique de poupées russes). La date de réservation est une propriété de la réservation et le lien avec Planning n'est plus utile, il peut disparaître.

Par ailleurs, j'ai fait figurer un invariant (ResaId) comme identifiant relatif de Reservation par rapport à chambre : au niveau logique, il faudra ajouter une clé alternative, susceptible de modification concernant la date : {HotelId, ChambreId, DateDebut}, ou mieux, si l'on veut être vraiment efficace, prévoir un trigger empêchant le recouvrement des périodes de réservation par des clients différents.





Courage, Paris ne s'est pas construit en un jour. Apprenez à maîtriser les concepts un par un et surtout pas tous à la fois...

[TheLeadingEdge]

Re,
Pas mal ta proposition...
Je vais juste pinailler un peu...
Tu as choisi de relier service à facture. Je l'aurai plutôt relié à reservation. Sinon, il faut qu'il existe une règle qui te fait créer la facture en même temps que la réservation. Dans le cas contraire tant que tu n'as pas de facture tu ne peux pas associer service à réservation. (Ton graphe n'est pas fermé)

[tesnimeronsard]

bonjour,

1-Concernant la facture , le fait d'avoir des cardinalités 1,1 entre facture et reservation ,je pensais à relier les services et reglement directement à l ' entité client?est ce possible?

2-si un client effectue un changement en ce qui concerne sa réservation , comment l ' indiquer au niveau conceptuel , est ce qu elle donne lieu à une nouvelle réservation ?ou le client désire diminuer le temps de sa reservation ...

3-par rapport aux formes normales , elles dependent bien du modele conceptuel mais elles se vérifient au niveau du modele relationnel?
par exemple la 1Fn elle fait appel à l atomicité que cela signifie t il?est ce qu une adresse (numero ,rue) n ' est pas decomposable?
pour assurer une cohérence , il faut bien que mon modèle respecte ses 3 formes normales , on y fait aussi référence aux contraintes d integrité et de dependance fonctionnelle.

Voici une version pratiquement finale , je pense ,enfin j espere.

[fsmrel]

Bonjour,


tesnimeronsard :

Vous n’avez pas tenu compte des observations que j’ai faites dans mon précédent message, concernant l’identification [relative] de Chambre relativement à Hotel et de Reservation relativement à Chambre, que j’avais justifiée par des motifs d’ordre sémantique. Au stade de la modélisation conceptuelle, vous pouvez effectivement ne pas utiliser cette identification relative et préférer une identification absolue, puisque l’on part du principe qu’à ce stade, les notions d’espace et de temps n’interviennent pas. Par contre, au niveau opérationnel, quand l’utilisateur posera une question du genre "Quel est le numéro de téléphone de l’hôtel auprès duquel a été effectuée telle réservation ?" alors vous aurez à programmer une double jointure mettant en jeu les tables Hotel, Chambre, Reservation tandis que par le jeu de l’identification relative, une jointure simple entre les tables Hotel et Reservation aurait suffi. Quelque part vous ferez faire du "pointer chasing" au SGBD, vous lui aurez supprimé un de ses turbos.

Selon votre MCD, l’entité-type Reservation est donc malheureusement identifiée de manière absolue. Dans ces conditions, quel rôle joue l’association-type Relat1 (mettant en relation Reservation et Planning) ? Est-elle nécessaire ?

si un client effectue un changement en ce qui concerne sa réservation , comment l'indiquer au niveau conceptuel , est ce qu’elle donne lieu à une nouvelle réservation ?ou le client désire diminuer le temps de sa réservation ...

Je vous avais suggéré de mettre en œuvre un attribut de type booléen "réservation confirmée" : il y avait là peut-être un premier élément de réponse. Maintenant, avant de pouvoir éventuellement agir sur le MCD, vous devrez interroger le maître d’ouvrage, pour savoir quelle est la véritable règle du jeu en l’occurrence, par exemple : "Toute modification ou annulation de réservation effectuée avant un délai de tant d’heures est possible..."

par rapport aux formes normales , elles dependent bien du modele conceptuel mais elles se vérifient au niveau du modele relationnel?

Quoi est censé dépendre du modèle conceptuel ? Concernant les formes normales, voyez mes réponses à Touronster : "Formes normales, et DF" (1)
"Formes normales, et DF" (2)

par exemple la 1Fn elle fait appel à l atomicité que cela signifie t il?est ce qu une adresse (numero ,rue) n ' est pas decomposable?

Cette atomicité concerne le système opérant (disons le SGBD). Si vous lui dites qu’un code postal est du type CHAR(5), il ne cherchera pas à interpréter le contenu : "abcd$!" est pour lui aussi valide que "75017" ou "2B290". Même chose pour l’adresse (numéro, rue). C’est à vous de définir le niveau de finesse qui vous convient. Certains atomisent en "encapsulant" numéro et rue dans le même attribut, d’autres préfèrent un granule plus fin et utilisent un attribut Rue et un attribut Numéro dans la rue. Comme disent Chevallier et Laspalès, "C’est vous qui voyez". Prenez encore le cas de la date : un SGBD vous propose en général le type Date, auquel cas "2008-02-20" est une valeur atomique, mais le SGBD vous propose en plus les opérateurs YEAR, MONTH, DAY vous permettant d’aller piocher au niveau subatomique. Exemple limite : si vous définissez l’attribut Nom du client comme étant du type CHAR(48), personne n’y trouvera à redire. Par contre, tout le monde, —sauf le SGBD et le modèle— vous prendrait pour un farfelu si vous définissiez 48 attributs : Nom1, Nom2, ..., Nom48 pour stocker le nom du client : humainement parlant, l’atomicité est un concept subjectif, à tout le moins relatif, mais il est nécessaire pour le système.

pour assurer une cohérence , il faut bien que mon modèle respecte ses 3 formes normales , on y fait aussi référence aux contraintes d integrité et de dependance fonctionnelle.

La vérification de la 2e forme normale et suivantes ne peut être que partielle au niveau conceptuel, par construction (absence des attributs identifiants dans les associations-types). Il faut donc passer au niveau tabulaire pour assurer le coup, parce que chaque table est alors dotée de l’ensemble de ses attributs. L’objet de la normalisation est d’évacuer les redondances susceptibles de mettre en péril l'intégrité des tables (entre autres choses), mais cela ne représente qu’une partie de l’intégrité des données, laquelle a à voir avec l’ensemble des règles de gestion des données. Quant aux dépendances fonctionnelles (DF), elles expriment certaines règles de gestion des données (contraintes d’unicité) et —exercice moins trivial qu'il n'y paraît !— la liste complète de ces DF est à dresser avant d’aborder le sujet de la normalisation.

[tesnimeronsard]

Bonjour,

en effet , je me suis trompé sur la version du mcd.J en ai fait 2 une sans la facture , le fait d' effectuer une réservation si elle est ou non confirmé entrainera automatiquement une facture?

1ere version :


2 eme version :


Je vous suis tres reconnaissant .je vais dormir , je n en peux plus

[fsmrel]

Bonsoir, oiseau de nuit,


Pour la partie Réservation, votre première version est satisfaisante en ce qui me concerne (je ne tiens pas compte de la 2e version, qui semble plutôt traiter de la facturation).

Facturation

Je ne connais pas le fonctionnement de la facturation dans le monde hôtelier. Maintenant, le fait de dire qu’une facture concerne une seule réservation, donc une seule chambre, me paraît restrictif. Je préférerais pouvoir dire qu’une facture concerne plus d’une chambre (par exemple, une pour madame et monsieur, deux pour les enfants et une autre pour l'oncle et la tante) : la facture comporterait alors autant de lignes que de chambres réservées.

Je m’oriente donc ici vers ce scénario.

Si vous voulez qu’une réservation fasse immédiatement l’objet d’une facturation (conformément à votre cardinalité minimale 1 portée par la patte connectant Reservation et EstFacturée), et en tenant compte de ma remarque, vous pouvez vous inspirer du MCD suivant, dans lequel l’association-type Effectuer entre Client et Reservation devient du reste inutile, puisqu’on trouve le client via la facture :




Et le MLD devient le suivant :




Mais, si vous préférez qu’une réservation puisse faire l’objet d’une facturation de façon différée, vous pouvez vous inspirer du MCD suivant, dans lequel l’association-type Effectuer entre Client et Reservation retrouve sa place, puisque du coup, on ne trouve pas forcément tout de suite le client via la facture :




D’où le MLD :


MLD dans lequel le client que l’on facture est bien celui qui réserve, ce qui n’a rien d’obligatoire selon le MCD...

Demandez l’avis de TheLeadingEdge.


N.B.
Concernant ce dernier MLD : du fait de la cardinalité 0,1 portée par la patte reliant Reservation et Référencer dans le MCD, l’attribut FactureId de la table Reservation devra pouvoir prendre la "valeur" nulle, ce qui est autorisé en SQL, mais strictement interdit du point de vue de la théorie relationnelle. On peut s’en sortir par une pirouette, en transformant l’association-type Référencer en entité-type LigneFacture, mais attention alors aux effets secondaires...

Encore courage !

[tesnimeronsard]

bonjour,

par rapport a la facture je me demande carrément si il est utile de créer cet entité , elle se retrouve via le client d' ou ma deuxieme version du mcd.

en ce qui concerne le modèle physique de données , il n ' est pas encore abouti mais en marche , cependant sous sql server 2005 "date" n ' est pas valide alors j ' utilise "datime".

voici les requetes de création de table :

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
Create Table Hotel
(CodeHotel      Integer Identity primary key,
 Hot_Adresse    Varchar(35) Not null,
 Hot_Codepostal char(5) not null,
 Hot_Ville      varchar (32) ,
 Hot_Numtel     char(10)
 
) ;

CREATE TABLE Client
(IdClient INT   Identity PRIMARY KEY,
Nom VARCHAR(25) NOT NULL,
Prenom varchar (25) Not null,
DateNaissance DATEtime ,
cli_Adresse varchar (32),
cli_CodePostal char(5),
Hot_Ville      varchar (32) ,
email varchar (50),
Login varchar(15) UNIQUE not null,
);


create table Categoriechambre
(Idcategoriechambre INT  Identity PRIMARY KEY,
LibelleCategorie varchar (15) not null
CHECK(LibelleCategorie IN ('simple', 'double', 'double confort', 'suite')));

create table Saison (
IdSaison INT  Identity PRIMARY KEY,
LibelleSaison varchar (32)not null,
datedebutSaison datetime not null,
datefinSaison datetime not null,
);

create table tarif_chambre
(
Idtarif INT  Identity PRIMARY KEY,
Idcategoriechambre INT   NOT NULL REFERENCES categoriechambre(Idcategorie),
IdSaison INT  not null references saison (idsaison),
Prixnuit decimal (10,2) not null
Constraint Chambre_AK1 Unique (Idcategorie,idsaison)
) ;

create table chambre (
IdcategorieChambre INT Identity not null,
CodeHotel int not null ,
Idcategoriechambre int not null references categoriechambre (Idcategorie),
Numerochambre smallint not null,
Etage smallint not null 
Constraint Chambre_PK Primary Key (codeHotel, IdChambre),
Constraint Chambre_AK1 Unique (codehotel, Etage, Numero),
Constraint codeHotel_FK Foreign Key (codehotel) References Hotel,  
Constraint idcategoriechambre_FK Foreign Key (idcategoriechambre) References 

Categoriechambre
) ;


create table Modereservation (
idModereservation int Identity primary key ,
designation varchar (15) not null ,
pourcentageModereservation  integer not null 
);


create table reservation (
idreservation int identity not null ,
Idclient int not null references client(idclient),
CodeHotel int not null references hotel (codehotel) ,
idchambre int not null references chambre(idchambre),
idModereservation int not null references Modereservation (idmodereservation),
Datereservation datetime not null ,
Datedebreservation datetime not null,
Datefinreservation datetime not null,
confirmation booleen not null
Constraint Chambre_PK Primary Key (idreservation, CodeHotel,IdChambre),
);

Pourrait on me dire si cela semble correct , je pense qu' il faudrait rajouter peut etre une contrainte au niveau de la table réservation .

Merci

[fsmrel]

Bonjour oiseau de nuit,

par rapport a la facture je me demande carrément si il est utile de créer cet entité, elle se retrouve via le client d' ou ma deuxieme version du mcd.

Voulez-vous dire que la facture deviendrait une propriété du client ? Je ne saisis pas tout...


Concernant les instructions CREATE TABLE

Table Hotel : Évitez les nulls tant que c’est possible (Hot_Ville, Hot_Numtel).

Table Client : Même chose. Par exemple, si vous ne connaissez pas l’adresse d’un client, utilisez une valeur pas défaut (par exemple : ClientNom Varchar(48) Not null default '??'). AMC vous donne la possibilité de le faire dès l’étape MCD.

Table CategorieChambre : vous avez codé :

CHECK (LibelleCategorie IN ('simple', 'double', 'double confort', 'suite'));

En principe, ce sont les lignes de cette table qui fournissent ces valeurs (qui valent alors pour axiomes). Sinon, autant faire l’économie de la table et coder la clause CHECK directement dans la table Chambre (en y remplaçant l’attribut attribut Idcategoriechambre par l’attribut LibelleCategorie). Quoi qu'il en soit, il vaut quand même mieux utiliser la table CategorieChambre débarrassée de la clause CHECK.

Table Chambre : La clause Identity est en théorie inutile pour l’attribut IdcategorieChambre. Néanmoins vous pouvez la conserver sans problème, si cela vous est plus pratique.

Table Reservation :

Clause Identity : cf. Table Chambre.
Clé primaire : Remettre de l’ordre :
(Idreservation, CodeHotel, IdChambre) doit devenir (CodeHotel, IdChambre, Idreservation)

je pense qu'il faudrait rajouter peut etre une contrainte au niveau de la table réservation

Vous pouvez toujours ajouter (lors de l’étape MCD) une 1re contrainte qui donnera lieu à ceci :

Code :

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

1
2
 DateDebut  Datetime  Not null
      Constraint Resa_Datedebut_1 Check (DateFin >= DateDebut),

Vous pouvez aussi définir des clés alternées (clause UNIQUE) : (CodeHotel, IdChambre, DateDebut), (CodeHotel, IdChambre, DateFin), mais cela n’empêchera guère qu’un 2e client partage la même chambre qu’un 1er si la réservation de celui-ci dure plus d’une nuit. Pour éviter cela, il faudra prévoir un trigger, du genre (avec 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
CREATE TRIGGER Trig_1 ON Reservation For Insert, Update
As
  Begin 
        Select  'x'
        From    Inserted i
              , Reservation r
        Where   i.HotelId = r.HotelId
          And   i.ChambreId = r.ChambreId
          And   i.ResaId <> r.ResaId
          And   Not (i.DateFin < r.DateDebut Or i.DateDebut > r.DateFin)
    IF @@rowcount > 0
       Begin
         RAISERROR ('Chevauchement des réservations !',16,1)
       End
  End
GO

Avec PowerAMC (si cela vous chante) : Table Reservation : Onglet Triggers \ Fenêtre "Propriétés du trigger" \Onglet Définition => Insérer le code ci-dessus.
Puis SGBD \ Générer les triggers et les procédures", fenêtre "Génération de triggers et procédures", cocher "Création de triggers", "Pour l’insertion", Pour la modification".

Pour en savoir plus sur les triggers, voir ce qu'à écrit SQLpro à leur sujet.

[TheLeadingEdge]

Re,

le client que l’on facture est bien celui qui réserve, ce qui n’a rien d’obligatoire selon le MCD...
Demandez l’avis de TheLeadingEdge.

Si effectivement on peut facturer un client qui n'est pas celui qui a réservé on a 2 responsabilités différentes pour l'entité client, et il faut donc 1 2nde association (entre ''client'' et ''facture''). Par contre si le client payeur est nécessairement celui qui a réservé, l'assoc. entre ''client'' et ''réservation'' est suffisante (au niveau conceptuel s'entend) On connait le client par transitivité.

par rapport a la facture je me demande carrément si il est utile de créer cet entité , elle se retrouve via le client d' ou ma deuxieme version du mcd.

Non.
Il n'existe pas de DF directe entre ''client'' et ''facture'' ou entre ''Client'' et ''Réservation'' mais des (potentielles) DM. Il est impossible de relier une ''facture'' à 1 ''réservation'' de cette manière.
Maintenant tu peux aussi décider que c'est une donnée calculée et choisir de ne pas la stocker. (Mais il faudra qd même que tu mémorise le n° de facture

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)
[...]
On peut s’en sortir [...] en transformant l’association-type Référencer en entité-type LigneFacture

Si on utilise la date et le n° de chambre comme composant de la PK de ''réservation'' on empeche bien de réserver 2 fois la même chambre le même jour, mais c'est effectivement totalement déconseillé d'utiliser une propriété susceptible d'être modifiée comme identifiant. On peut donc utiliser le n° de réservation comme PK. Et traduire par une AK la DF Chambre/Date (DF au sens Merise ;-) Pas stable donc ce n'est plus 1 CIF).
Si on gère la DM (plusieurs chambres ou plusieurs dates pour une réservation) une association ''LigneFacture'' devient automatique et on règle le pb de la FK nullable.

[tesnimeronsard]

Bonjour ,

cela n' est pas très évident à suivre .Oui je suis encore en phase d' apprentissage , j espere que cela viendra.

j ' avais pensé à créer une réservation pour une nuit , si le client réserve 3 nuits par exemple 3 réservations sont établies (je pense que cela fait un peu trop ) mais cela aurait peut être éviter de trouver 2 clients dans une même chambre.

je voyais plus le client comme occasionnel , ce que je veux dire ce n est pas comme un salarié d ' une entreprise , ou un élève d ' une classe .

Concernant la réservation encore , selon moi le client paie qu ' il confirme ou non.Donc la chambre est occupée si seulement la propriété "confirmation" prend la valeur 1.

Pour la facture je ne comprend pas pourquoi la cardinalité doit etre à "0,1" sur le second mcd de fmsrel , je la porterais à 1,1.

Je vous remercie , je crois que je vais me convertir en hotelier

[fsmrel]

j ' avais pensé à créer une réservation pour une nuit , si le client réserve 3 nuits par exemple 3 réservations sont établies (je pense que cela fait un peu trop ) mais cela aurait peut être éviter de trouver 2 clients dans une même chambre.

Une réservation par nuit, cela est possible, mais dans l’esprit ça n’est pas sain et révèle une certaine "paresse" à ne pas laisser s’installer...

je voyais plus le client comme occasionnel.

Ceci est le cas des curistes qui passent 15 jours dans une ville d’eaux ou des familles, parents et enfants, qui lors des vacances séjournent 15 jours ou un mois à l’hôtel. Et au niveau opérationnel, vous risquez de rendre obèse la table Reservation si vous créez une réservation par nuit.

Pour la facture je ne comprend pas pourquoi la cardinalité doit etre à "0,1" sur le second mcd de fmsrel , je la porterais à 1,1.

Cela dépend du souhait du maître d’ouvrage (l’hôtelier), à qui il revient de décider si la création d’une réservation déclenche simultanément et nécessairement la création d’une facture.

Je vous remercie , je crois que je vais me convertir en hotelier

J'espère que vous nous ferez des prix...