Bonjour,
Certaines de mes remarques recoupent celles qui ont été faites précédemment. A vous de trier.
Remarques générales
« Une chambre est occupée par un client selon un planning établi. »
Où sont les dates de début et de fin correspondantes ?
« il est établi un planning journalier qui permet de savoir si les chambres sont occupées, libres ou réservées et le nombre des occupant par chambre »
Votre MCD ne prévoit ni la gestion de la situation des chambres (occupée, etc.), ni le nombre d’occupants (à moins que chaque occupant ne fasse systématiquement l’objet d’une instance de CLIENT ; c’est un peu comme une rate et sa portée : on connaît le nombre de ratons composant cette dernière, mais on n’identifie pas les ratons, à moins que tel ou tel ait à être identifié pour des raisons diverses et variées...)
« Une chambre coûte un tarif »
Vous avez établi une relation 1,N-1,N avec Tarif, ce qui signifie qu’une chambre peut avoir plusieurs tarifs : contradiction. En toute logique, si une chambre a un et un seul tarif, soit celui-ci figure en tant que propriété de la chambre, soit il figure dans une entité-type permettant de connaître le tarif en fonction de la catégorie de la chambre.
En plus, selon votre MCD, le prix d’une chambre varie en fonction des repas...
« Pour les fonctionnaires du BAIV »
Comment sait-on qu’un client est du BAIV ?
« Une facture est établie à un client »
Il manque un attribut Numéro de facture pour l’entité-type FACTURE. En effet, ce type d’information est connu de l’utilisateur (voire géré par lui). L’identifiant FAC_ID ne doit être connu que du système et servira au niveau SQL pour traiter efficacement de l’intégrité référentielle et des opérations relationnelles telles que la jointure.
Les fonctionnaires du BAIV sont-ils concernés ? Est-il normal qu’un client ne soit pas facturé ? Pour quelle raison un client peut-il faire l’objet de plusieurs factures ? Est-ce au motif de l’archivage des copies ?
« Une facture possède au moins une ligne de facture »
Pour quelle raison ? Où est le libellé accompagnant chaque ligne ? (en tant que client, j’exige que chaque montant soit expliqué).
Entités-types à supprimer
« Un client peut avoir une adresse de domicile »
Puisqu’un client a au plus une adresse de domicile, vous pouvez remonter la donnée correspondante dans l’entité-type CLIENT. Si un client n’a pas de domicile, l’attribut correspondant prendra une valeur par défaut ("Sans objet", "Inconnu", etc.)
Cardinalités à revoir
La cardinalité 0,1, voilà l’ennemie, car au niveau SQL elle est traduite par une marque nulle, chose qui met en échec l’algèbre relationnelle et fait patiner les optimiseurs des SGBDR. 0,1 doit être remplacé par 1,1. Sont concernées les associations-types entre CLIENT et TITRE, ainsi que FACTURE et MODE_PAIEMENT. En conséquence :
TITRE : prévoir un titre « à blanc ».
MODE_PAIEMENT : a priori, on connaît le mode paiement. Mais si vraiment tel n’est pas le cas (supposons que cela concerne les fonctionnaires du BAIV ou que le client ne quitte pas les lieux ce jour), alors prévoir le mode de paiement "Sans objet", "A régler", ...
« Un client possède au moins un numéro de téléphone »
La cardinalité 0,N doit être transformée en cardinalité 1,N.
« Un client possède au moins une adresse électronique »
La cardinalité 0,N doit être transformée en cardinalité 1,N.
Identification relative
Certaines entités-types correspondent à des propriétés (multivaluées) d’autres entités-types :
TELEPHONE, ADRES_ELECTRONIQUE, FACTURE, LIGNE_FACTURE.
Il est recommandé de les identifier relativement plutôt que de façon absolue. Pour signifier que l’on identifie de façon relative, utiliser un mickey du genre 1,1 (R) (cf. FAQ Merise).
N.B. Pourquoi utilisez-vous l’expression angloricaine « Guest House » ? Votre projet concerne-t-il un pays anglophone ?
Partager