Discussion :

[white_agent]

bonsoir tout le monde ! j’espère que vous allez bien !
voici mon MCD , aidez moi à le valider en trouvant des erreurs ( cardinalités ... ) et de me corriger svp !
les entités importantes:
-catégorie (chambre simple ...);
-règlement ( mode règlement : un montant est payé par chèque , CB...);
-mode de réservation (directe ou par internet avec un pourcentage );
-service (piscine, salle de conférence ,restaurant ...);
-planning : pour une chambre , elle peut être réserve sur des dates différents par la même ou des differentes personnes.

[fsmrel]

Bonsoir white_agent


Un MCD n’est pas que pictural, commencez par dresser le catalogue des règles de gestion des données. A titre d’exemple, voyez ce qu’ont réalisé nono02P et Redreams.

Donnez des exemples venant illustrer ces règles, comme ici.

Dresser un catalogue exhaustif de règles formalisées n’est certes pas chose aisée, mais à défaut la modélisation est hasardeuse et fragile. On n'escalade pas le Mont Blanc sans un bon équipement. Courage à vous.

[white_agent]

merci mr fsmrel pour vos conseilles !
monsieur le problème c'est que le professeur nous a distribué des thèmes , alors à chaque fois que je fais un MCD , il me dit :" et ce cas ... , ton MCD ne le vérifie pas ..." et je trouve ta réponse très logique : il faut faire les règles ... mais c difficile , qu'à chaque fois j' imagine un cas et je le traite , alors que ce que je fais !!!
j 'ai une autre question , si tu veux me répondre : comment modifier mon MCD pour qu'un client peut payer une réservation mes pas tous ( supposant qu'un client peut réserver plusieurs chambres à plusieurs personnes dans des dates différents ?
MERCI pour votre réponse MR fsmrel.

[fsmrel]

Bonsoir white_agent

planning : pour une chambre , elle peut être réservée sur des dates différents par la même ou des differentes personnes.

Votre phrase n’interdit pas de penser que ce qui suit est possible, je pose donc la question :

Supposons que white_agent a effectué une réservation pour la chambre C1 pendant la période P1.

Est-ce que fsmrel (qui est un autre client et qui n’a aucun lien avec white_agent) peut lui aussi réserver C1 pendant la période P2, mais telle que P1 et P2 se recouvrent ? Par exemple, P1 = du lundi 4 avril 2016 au samedi 9 avril 2016, et P2 = du mercredi 6 avril 2016 au mardi 12 avril 2016 ?

[white_agent]

bonsoir , oui tu as totalement raison !!
bon !! la solution à mon avis c'est à travers un TRIGGER "on insertion" on vérifie dans la table de "planning" :
notre nouvelle date de début doit être > les date_fin dans la table , et la nouvelle date_fin doit être < date_début dans la table .
et pour ma question , je vais :
1/ changer la cardinalité de l'association "concerne " du coté de l'entité "réservation" à : 1,1
2/changer la cardinalité de l'association "est_effectuer" du coté de l'entité "réservation" à : 0,1
alors comme sa : chaque personne paye pour sa propre chambre et aura sa propre facture ! ( et bien sur je vais mettre sa dans les règles de gestion )

est ce que c'est juste ?

merci monsieur !

[fsmrel]

Bonsoir white_agent,

la solution à mon avis c'est à travers un TRIGGER "on insertion"

Houlà ! Les triggers, ça se passe dans la soute, au stade SQL, au cas où le SGBD ne propose pas l’instruction CREATE ASSERTION, ou tout autre moyen d’interdire le recouvrement des dates (par exemple PostgreSQL permet de contrôler le recouvrement des dates grâce à la clause EXCLUDE USING). A ce propos, quel est votre SGBD ?

Par ailleurs, il est courant de représenter une période, un intervalle de dates, par des attributs date_debut, date_fin, mais votre SGBD propose peut-être un type à cet effet ? (DATERANGE dans le cas de PostgreSQL).


Au niveau conceptuel, la partie réservation ressemblerait à ceci :





Où l’entité-type RESERVATION est identifiée relativement à l’entité-type CLIENT, c'est-à-dire qu’au stade du MLD, la table RESERVATION issue de l’entité-type RESERVATION aura pour clé primaire la paire {id_client, id_planning} : le but est de propager l’attribut id_client le plus loin possible, on verra plus tard si cela vaut effectivement le coup, pour le moment on va dire a priori oui.

Selon ce MCD, une réservation peut concerner plus d’une chambre, via l’entité-type PLANNING. L’entité-type PLANNING est identifiée relativement à CHAMBRE. On permet ainsi de garantir la contrainte :

A une date donnée, une chambre fait l’objet d’une seule réservation.

On verra la facturation quand on sera en phase sur ce qui précède.

[white_agent]

bonsoir monsieur fsmrel !
merci pour vos réponses .
1/ mon SGBD est : Oracle ;
2/je pense qu'il n'y a pas ce type dans oracle pour éviter les chevauchements .
3/ vous avez dis monsieur :"la table RESERVATION issue de l’entité-type RESERVATION aura pour clé primaire la paire {id_client, id_planning} "
je vois que l’entité-type RESERVATION aura un clé primaire la paire {id_client, id_reservation} , et la table planning aura pour clé primaire le triplet {id_client, id_reservation, id_planning}.
------
des questions :
pour la relation {de } avec le contour noir (image de l'mcd): est ce que d’après votre représentation ( la propagation du clé client ) ,il faut supprimer cette relation ?
pour la relation {concerne } avec le contour rouge (image de l'mcd ) :un client peut réserver a d'autre clients , c'est toujours valable ?
merciii monsieur

nb:dans l'MCD j'ai changé les cardinalité avec celles que tu ma donné .

[fsmrel]

Bonsoir white_agent,

je vois que l’entité-type RESERVATION aura un clé primaire la paire {id_client, id_reservation}

Bien vu, œil de lynx ! Je suis désolé, j’ai fait un copier/coller intempestif, après que WORD m’a mangé la moitié de la phrase que j’avais rédigée, d’où un résultat bizarre... Ainsi, au lieu de lire :

La table RESERVATION issue de l’entité-type RESERVATION aura pour clé primaire la paire {id_client, id_planning}

Ce qui est absurde, il est évidemment préférable de lire :

La table RESERVATION issue de l’entité-type RESERVATION aura pour clé primaire la paire {id_client, id_reservation}, et la table PLANNING aura pour clé primaire la paire {id_chambre, id_planning}.

Ce qui est quand même plus conforme...

la table planning aura pour clé primaire le triplet {id_client, id_reservation, id_planning}.

Pour que, dans le MLD, la table PLANNING ait pour clé primaire le triplet {id_client, id_reservation, id_planning}, dans le MCD il faudrait identifier PLANNING relativement à RESERVATION plutôt qu’à CHAMBRE : c’est une possibilité, voyez le paragraphe Variante ci-dessous. Toutefois, en l’état du MCD que j’ai proposé, au stade MLD, les attributs id_client et id_reservation feront partie des attributs de la table PLANNING, mais sans participer à la clé, laquelle sera la paire {id_chambre, id_planning}. Continuons avec ce scénario, on verra l’alternative plus loin.


A propos de l’identification relative :

Pour que, dans le MLD (en fait MPD au sens PowerAMC), la table PLANNING ait pour clé primaire la paire {id_chambre, id_planning}, il faut utiliser, au stade du MCD, ce qu’on appelle l’identification relative.

Techniquement, avec PowerAMC, la mise en oeuvre de l’identification relative est simple. En cliquant sur la patte connectant RESERVATION et RESA_CLI, on provoque l’ouverture de la fenêtre « Propriétés du lien d’association », dans laquelle on coche la case « Identifiant » :





Au résultat, la cardinalité 1,1 en cause, est mise entre parenthèses, rappelant ainsi que l’identification de RESERVATION est relative à CLIENT.

Le principe est le même pour identifier PLANNING relativement à CHAMBRE.


MLD résultant :





_____________________________________________________

Cas de la contrainte selon laquelle, à une date donnée, une chambre fait l’objet d’une seule réservation.

On aurait pu ne pas définir l’attribut id_planning dans le MCD et le remplacer par periode_reservation dans le système d’identification, garantissant du même coup la contrainte :


MCD






MLD






Mais il est vivement recommandé de ne faire participer à l’identification d’une entité-type que des attributs invariants, alors qu’une période de réservation peut être modifiée.

Donc, jouons le jeu de l’invariance et conservons id_planning. Afin de garantir explicitement la contrainte, le MLD doit être complété par l’ajout d’une clé alternative (contrainte d’unicité), à savoir la paire {id_chambre, periode_reservation}.

Techniquement, vous pouvez procéder procède ainsi :

Ouvrez la fenêtre « Propriétés de la table PLANNING » et sélectionnez l’onglet Clés :





Apparaît identifiant_1, nom de la clé primaire {id_chambre, id_planning}. En cliquant sur la ligne qui se trouve sous identifiant_1, vous avez la possibilité de définir une clé alternative (cle_2 dans l’exemple) :





Vous faites un double click sur la ligne « cle_2 ». Vous avez droit à un avertissement :





A la question posée, vous répondez « Oui ». Vous avez alors droit à la fenêtre « Propriétés de la clé », dans laquelle vous repérez l’onglet « Colonnes » :





Après avoir cliqué sur cet onglet, la fenêtre prend l’allure suivante, avec apparition d’une icône à utiliser pour ajouter des attributs à la clé cle_2 :





Vous cliquez sur l’icône, et il vous est proposé la liste des attributs parmi lesquels vous choisirez ceux qui feront l’objet de la clé alternative.





Il s’agit évidemment des attributs id_chambre et periode_reservation :





Une fois ces attributs cochés, vous faites « OK » pour chaque fenêtre, et la table PLANNING doit ressembler à ceci, où la paire {id_chambre, id_planning} est clé primaire, tandis que la paire {id_chambre, periode_reservation} est clé alternative (alternate key} :





Variante

Vous aviez évoqué la possibilité d’avoir pour clé primaire de la table PLANNING le triplet {id_client, id_reservation, id_planning} : c’est un choix tout à fait légitime.

Le MCD est alors le suivant :





Et le MLD :





En notant que la paire {id_chambre, periode_reservation} reste clé alternative, afin de garantir la contrainte selon laquelle à une date donnée, une chambre ne peut faire l’objet que d’une seule réservation.


Vous avez plus d'un scénario possible, faites votre choix...


Dans votre dernier MCD, une réservation est effectuée par un client (association EFFECTUE) : d’accord. Mais à quoi correspond l’association CONCERNE ? Est-ce à dire qu’un client peut réserver non pas pour lui, mais pour quelqu’un d’autre ?


J'espère qu'il n'y a pas eu de copier/coller malencontreux de ma part...

On verra les factures plus tard. En attendant, bon courage !

[white_agent]

bonsoir Monsieur fsmrel !!
j’espère que vous allez bien !
merci pour vos réponses , et merci pour toujours !

je démarre par vous répondre à votre dernière question :"Dans votre dernier MCD, une réservation est effectuée par un client (association EFFECTUE) : d’accord. Mais à quoi correspond l’association CONCERNE ? Est-ce à dire qu’un client peut réserver non pas pour lui, mais pour quelqu’un d’autre ?
*oui ,le client peut réserver a plusieurs autres clients . si c'est valable ; est ce qu'on on fait la même chose pour la relation "concerne" c-à-d : on fait l’identification relative avec l'entité "reservation"{le 1,1 devient (1,1)}, ou seulement avec la relation "effectue" !? et pour quoi?
deux autres questions :
1/sachant que j'utilise oracle comme SGBD ; vous avez cité un attribut qui est "période" dans l'entité planning , il est de quel "type de donnée" car moi j'ai divisé la période en deux dates début et fin ?
dans le cas ou il n' y a pas cet attribut dans oracle , est ce que j'utilise les deux dates (début et fin ) avec id_chambre dans la clé alternative ?
2/dans mon premier mcd que j'ai proposé , la relation "DE" qui relit l'entité-type "client" et l'entité-type "planning" , et ce que je dois la supprimer car je pense qu'elle est inutile puisque dans le MPD de votre représentation ,l'entité-type "planning" contient déjà id_client ?
NB: mon but de faire la relation "DE" est de savoir l'ensemble des planning attribuer à un client .

[fsmrel]

Bonsoir white_agent,

oui ,le client peut réserver a plusieurs autres clients . si c'est valable ; est ce qu'on on fait la même chose pour la relation "concerne" c-à-d : on fait l’identification relative avec l'entité "reservation"{le 1,1 devient (1,1)}, ou seulement avec la relation "effectue" !? et pour quoi?

Je suppose que la phrase « le client peut réserver a plusieurs autres clients » est à interpréter ainsi : « le client peut réserver pour plusieurs autres clients ». Dans ce cas-là, je reviens à l’époque où j’étais encore en activité, et que mon entreprise réservait des chambres, par exemple à l’Hôtel du Pingouin, pour mes collègues et moi-même, quand nous travaillions sur le projet CREPE :

Mon entreprise était Dubicobit (nom fictif...), basée à Paris.
Nous étions un certain nombre d’ingénieurs ayant à passer un certain nombre de semaines (pas forcément consécutives) sur le projet, loin de notre base.

Dans la base de données, le contenu des tables aurait pu être le suivant :

CLIENT

id_client    nom_client
55           Dubicobit
101          François
102          Jean
103          Louis
104          André

RESERVATION

id_client_reservant   id_reservation    date_reservation    id_client_concerne
55                    1                 d1                  101
55                    2                 d1                  102
55                    3                 d1                  103
55                    4                 d2                  101
55                    5                 d2                  104
...                   ...               ...                 ...

Où, en passant, il apparaît que la paire {id_client_concerne, date_reservation} devrait faire l’objet d’une clé alternative.


Un MLD (MLD 1) :




D’où le MCD (MCD 1) :





Vous observerez que je n’ai pas utilisé l’identification relative pour l’association CONCERNE. Pour répondre à votre question à ce sujet, utilisons-la.


MCD (MCD 2) :





Il y a maintenant une double identification relative, signifiant que RESERVATION est en fait le déguisement d’une association réflexive :

MCD (MCD 3) :





MLD dérivé (MLD 3) :





Où il apparaît que Dubicobit ne pourra effectuer qu’une seule réservation pour François.


Mais revenons au MCD (MCD2) :





Ce MCD est correct. Toutefois, voyons le MLD qui en est dérivé (en montrant la partie planning).


MLD (MLD 2)





Ce MLD est correct. Toutefois, reprenons MLD 1, tout en y faisant figurer l’attribut id_client_concerne, et comparons :





MLD 1 est moins chargé que MLD 2 : l’attribut id_client_concerne est absent de la table PLANNING, attribut qui y est inessentiel, et représente plutôt une surcharge inutile : il vaut mieux l’évacuer, c'est-à-dire que, si l’entité-type RESERVATION est identifiée relativement à CLIENT via RESA_CLI (EFFECTUE), il est inutile d’identifier en plus RESERVATION relativement à CLIENT, via CONCERNE.

Sachant que j'utilise oracle comme SGBD ; vous avez cité un attribut qui est "période" dans l'entité planning , il est de quel "type de donnée" car moi j'ai divisé la période en deux dates début et fin ?
dans le cas ou il n' y a pas cet attribut dans oracle , est ce que j'utilise les deux dates (début et fin ) avec id_chambre dans la clé alternative ?

Vous devez effectivement remplacer l’attribut periode_reservation par les attributs date_affectation_debut et date_affectation_fin, et vous remplacerez la clé alternative {id_chambre, periode_reservation} par les clés alternatives {id_chambre, date_affectation_debut} et {id_chambre, date_affectation_fin}, mais cela ne sera qu’un cache-misère, car rien n’empêchera de voir les périodes se recouvrir : pour pallier, vous devrez mettre en oeuvre un trigger.

dans mon premier mcd que j'ai proposé , la relation "DE" qui relit l'entité-type "client" et l'entité-type "planning" , et ce que je dois la supprimer car je pense qu'elle est inutile puisque dans le MPD de votre représentation ,l'entité-type "planning" contient déjà id_client ?
NB: mon but de faire la relation "DE" est de savoir l'ensemble des planning attribuer à un client.

L’association DE est effectivement inutile, car redondante, et elle est même dangereuse car elle est la cause d’une boucle (cycle) : il y a un 1er chemin allant directement de RESERVATION à CLIENT via EFFECTUE, et aussi un 2e chemin allant indirectement de RESERVATION à CLIENT via POUR > PLANNING > DE, et cette fois-ci, le client impliqué doit être le même quel que soit le chemin, contrainte qu’il faut à tout prix garantir.

Il ressort que l’association DE doit être supprimée. Si vous voulez connaître l'ensemble des affectations faites pour un client « concerné », une vue SQL suffira :

CREATE VIEW DE_CONCERNE (nom_client, id_chambre, date_affectation_debut, date_affectation_fin) 
AS
    SELECT x.nom_client, z.id_chambre, z.date_affectation_debut, z.date_affectation_fin
    FROM   CLIENT AS x JOIN RESERVATION AS y ON x.id_client = y.id_client_concerne
                       JOIN PLANNING AS z ON y.id_client_reservant = z.id_client_reservant
                                          AND  y.id_reservation = z.id_reservation
;

Un script SQL pour tester :

CREATE TABLE CHAMBRE
(
        id_chambre            INT             NOT NULL
      , etage                 VARCHAR(5)      NOT NULL
    , CONSTRAINT CHAMBRE_PK PRIMARY KEY (id_chambre)      
) ;

CREATE TABLE CLIENT
(
        id_client             INT             NOT NULL
      , nom_client            VARCHAR(32)     NOT NULL
    , CONSTRAINT CLIENT_PK PRIMARY KEY (id_client)      
) ;

CREATE TABLE RESERVATION
(
        id_client_reservant   INT             NOT NULL
      , id_reservation        INT             NOT NULL
      , date_reservation      DATE            NOT NULL
      , id_client_concerne    INT             NOT NULL
    , CONSTRAINT RESERVATION_PK PRIMARY KEY (id_client_reservant, id_reservation) 
    , CONSTRAINT RESERVATION_AK UNIQUE (id_client_concerne, date_reservation) 
    , CONSTRAINT RESERVATION_FK1 FOREIGN KEY (id_client_reservant)
          REFERENCES CLIENT (id_client)    
    , CONSTRAINT RESERVATION_FK2 FOREIGN KEY (id_client_concerne)
          REFERENCES CLIENT (id_client)     
) ;

CREATE TABLE PLANNING
(
        id_client_reservant    INT             NOT NULL
      , id_reservation         INT             NOT NULL
      , id_planning            INT             NOT NULL
      , id_chambre             INT             NOT NULL
      , date_affectation_debut DATE            NOT NULL 
      , date_affectation_fin   DATE            NOT NULL 
    , CONSTRAINT PLANNING_PK PRIMARY KEY (id_client_reservant, id_reservation, id_planning) 
    , CONSTRAINT PLANNING_AK1 UNIQUE (id_chambre, date_affectation_debut) 
    , CONSTRAINT PLANNING_AK2 UNIQUE (id_chambre, date_affectation_fin) 
    , CONSTRAINT PLANNING_FK1 FOREIGN KEY (id_client_reservant, id_reservation)
         REFERENCES RESERVATION (id_client_reservant, id_reservation)    
    , CONSTRAINT PLANNING_FK2 FOREIGN KEY (id_chambre)
          REFERENCES CHAMBRE (id_chambre)    
    , CONSTRAINT PLANNING_CK1 CHECK (date_affectation_debut <= date_affectation_fin)
) ;

INSERT INTO CHAMBRE (id_chambre, etage) VALUES 
  (1, 'rdc'), (2, '3') ;

INSERT INTO CLIENT (id_client, nom_client) VALUES 
  (55, 'Dubicobit'), (101, 'François'), (102, 'Jean'), (103, 'Louis'), (104, 'André') ;

INSERT INTO RESERVATION (id_client_reservant, id_reservation, date_reservation, id_client_concerne) VALUES 
  (55, 1, '1992_04_10', 101), (55, 2, '1992_04_10', 102), (55, 3, '1992_04_10', 103), (55, 4, '1992_05_02', 101), (55, 5, '1992_05_02', 104) ;

INSERT INTO PLANNING (id_client_reservant, id_reservation, id_planning, id_chambre, date_affectation_debut, date_affectation_fin) VALUES
  (55, 1, 1, 1, '1992_04_14', '1992_04_15'), (55, 1, 2, 1, '1992_04_27', '1992_04_29') 
, (55, 4, 1, 1, '1992_05_02', '1992_05_02'), (55, 2, 1, 1, '1992_05_04', '1992_05_07') 
;

Sommes-nous en phase ?

[white_agent]

bonsoir monsieur fsmrel , j’espère que vous allez bien !
merci , pour vos réponses !
vous m'avez dis : "Vous devez effectivement remplacer l’attribut periode_reservation par les attributs date_affectation_debut et date_affectation_fin, et vous remplacerez la clé alternative {id_chambre, periode_reservation} par les clés alternatives {id_chambre, date_affectation_debut} et {id_chambre, date_affectation_fin}, mais cela ne sera qu’un cache-misère, car rien n’empêchera de voir les périodes se recouvrir : pour pallier, vous devrez mettre en oeuvre un trigger."
alors, est ce que les clés alternative pour que " à une date donnée , une chambre fait partie d'une seule réservation" est insuffisante ou inutile ? c-à-d : j'implémente le trigger et je ne déclare pas les clés alternatives ( {id_chambre, date_affectation_debut} et {id_chambre, date_affectation_fin} OU j'implémente trigger + les clés alternatives ? et pour quoi ( pour que je comprend ) .
aide : pour le trigger ?! pouvez vous m'expliquer comment le faire pour qu'il puisse traité le problème en question?
-------------
passant à la facturation !
vous avez mon premier mcd , une réservation a une seule facture ; est ce que monsieur vous voyez des problèmes dans cette représentation( est ce qu'elle vérifie toutes les possibilités ?
un problème :
l'entité facturation et l'entité tarif sont trop séparés , bon je ne c' est pas , mais il me semble que la requête pour calculer la facture sera trop compliquer , non ??

pardon monsieur , je pose trop de questions !


merci infiniment

[fsmrel]

Bonsoir white_agent,


Si vous mettez les triggers en œuvre, vous pouvez vous dispenser de définir les clés alternatives {id_chambre, date_affectation_debut} et {id_chambre, date_affectation_fin}.

Je n’utilise pas Oracle, aussi pour savoir comment programmer les triggers avec ce SGBD, il faudra que vous postiez dan le forum Oracle.

vous avez mon premier mcd , une réservation a une seule facture ; est ce que monsieur vous voyez des problèmes dans cette représentation (est ce qu'elle vérifie toutes les possibilités ?)

Selon votre 1er MCD , à une réservation correspondent 0,N factures. Maintenant, si en fait à une réservation correspond forcément au moins une et au plus une facture, alors l’entité-type FACTURE est absorbée par l’entité-type RESERVATION, elles ne font qu’une.


.

l'entité facturation et l'entité tarif sont trop séparés

Pour trouver les tarifs associés à une réservation, en SQL il suffit d’une jointure des tables RESERVATION, PLANNING, CHAMBRE, CATEGORIE, TARIF_SC, ça peut paraître impressionnant, mais ça n’est pas la mer à boire...

[white_agent]

Merci monsieur !
J'ai d'autres questions :
Maintenant je suis entraine de développez l'interface graphique , je veux connaitre les requêtes à programmer ; titre d exemple : dans le menu barre : je vais mettre : client , réservation , facture , chambre ..
Quand je clique sur client , une liste s'apparait , contenant : ajouter un client .. ; est ce que vous avez une vue globale sur une telle application?
Merciii