Discussion :

[nadia85]

Bonjour tout le monde,
j'ai construit le modèle MCD suivant à partir duquel j'ai construit un MPD


Le MPD est généré sans erreur. Cependant quand je génère le script sql pour la construction de la base, ette erreur se produit:




Pourriez vous m'aider à corriger le problème?

Merci d'avance

[escartefigue]

C'est une erreur non bloquante.
Power AMC génère un index pour chaque FK, mais, pour la table concernée, comme la PK est composée de 2 FK (table associative oblige), l'index sur la FK "numcl" est redondant avec l'index PK composé de numcl+numch.
il suffit de supprimer cet index redondant

Par ailleurs, avec ce modèle, si une même personne fait plusieurs réservations avec le même identifiant de client, elle devra systématiquement changer de chambre à chaque fois.
Contournement possible : créer autant de fois la personne avec un identifiant différent qu'il y a de réservations... Pas terrible.
Meilleure solution : ajouter une entité-type "calendrier" dans le MCD avec un seul attribut "date" qui sera l'identifiant, et faire participer cette entité-type à l'association (reservation)
Ce faisant, la date participera à la PK de la table issue de cette association.
Mais, comme il ne faut pas que plusieurs personnes puissent réserver la même chambre à la même date (ce qui serait du coup possible après cette modif), il faut ensuite évacuer l'identifiant de la personne "numcl" de la PK de la table associative "reservation".
Il faut donc que "numcl" devienne un simple attribut de cette table.
Modification à faire dans le MLD (dans mes souvenirs, contrairement à Looping, power AMC ne permet pas de le faire dans le MCD)

[nadia85]

Bonsoir à tous,

J'ai réglé le problème de génération de la base. Je vous remercie beaucoup pour les remarques. Comme vous l'avez dit, si une même personne fait plusieurs réservations avec le même identifiant de client, elle devra systématiquement changer de chambre à chaque fois.
Pour celà j'ai pensé à refaire le modèle:

Voici le nouveau MCD:



Dans le modèle physique de données, on voie bien que les clés primaires des tables client, chambre et facture ont migré vers la table réservation. Du coup, un même client peut effectuer plusieurs réservations dans la même chambre mais pendant des périodes différentes (à condition qu'elle ne soit pas occupée par d'autres clients).




Merci

[escartefigue]

Bonsoir,

Cette nouvelle version corrige le problème des réservations multiples d'un même client, mais elle en présente un nouveau : une même chambre peut être réservée plusieurs fois à la même date !

Pour éviter cette écueil, je propose le modèle ci-dessous



J'ai identifié la réservation relativement au client : sans client pas de réservation, c'est donc une entité-type faible. D'où la présence du (R) près des cardinalités (c'est la symbolique utilisée par Looping, Power-AMC de son côté met les cardinalités entre parenthèses dans ce cas)
J'ai fait de même pour les chambres identifiées relativement à l'hotel.
J'ai créé une entité-type fictive (d'où son nom entre parenthèses) [CA_calendrier] qui est là uniquement pour participer à l'association (CO_concerner) et ainsi ajouter la date "CA_date" comme composante de la PK de la table issue de cette association.
Entité type "fictive" car elle ne deviendra pas une table (grâce à une case à cocher de Looping) ce serait inutile.
J'ai aussi ajouté une contrainte, symbolisée par une flèche en direction de [RS_réservation] qui marque l'unicité d'une réservation pour un coupe chambre+date
C'est cette association ternaire affublée de cette contrainte qui permet d'éviter les réservations multiples d'une chambre à la même date

J'ai préféré une cardinalité 0,1 plutôt que 1,1 de [RS_reservation] vers (referencer) car en général, l’hôtel ne facture pas dès la réservation, celle-ci pouvant être annulée.

[nadia85]

Bonjour,

Je vous remercie énormément pour vos remarques. Elles m'ont clarifié le problème.
Juste une petite question: je n'ai pas compris la signification du symbole (R). Est-il nécessaire de le mentionner avec une relation type faible lorsqu'on utilise PowerAMC?

Merci d'avance

[escartefigue]

Le symbole (R) de looping sert à mettre en évidence l'identification relative.

L'identification relative est utilisée pour les entité-type dites "faibles".

La chambre d'hôtel en est un cas typique : la chambre n°27 n'a de sens que si on connait également le n° d'hôtel.
Le n° de chambre 27 seul ne suffit pas, il n'est pas unique, il peut y avoir plusieurs chambres n° 27 réparties dans différents hôtels.
L'identifiant complet de la chambre est donc n° d'hôtel + n° de chambre.

Avec Power AMC, ce n'est pas un (R) qui est affiché sur le MCD mais les cardinalités qui sont entre parenthèses, par exemple (1,1)

Il y a une case à cocher "identifiant" dans PowerAMC pour déclarer une identification relative.

[Paprick]

En complément de l'exellente explication de escartefigue (grand spécialiste Looping ), sachez que vous pouvez choisir, dans les propriétés, le format de l'identification relative : 1,1(R), (1,1) ou 1,1

Bonne continuation !

[escartefigue]

J'ai encore bien des choses à découvrir, par exemple, je n'avais pas repéré cette possibilité de choix du type d'affichage de l'identification relative
Merci Paprick

[nadia85]

Bonjour,

Je vous remercie énormément pour vos conseils et vos remarques qui m'ont clarifié beaucoup de choses.


Bonne journée