Discussion :

[JeuneJavaiste]

Bonjour,

Comme tout étudiant qui se respecte, je me prépare à passer mon partiel de BD dans une semaine et demie (aïe).
En regardant les annales je m'aperçois qu'à tout les coup mon prof demande de critiquer le schéma relationnel proposé & d'en donner les faiblesses sauf que...nous ne l'avons jamais fait alors voici ma question : comment juge-t-on de la qualité d'un schéma relationnel ?

[Chtulus]

Bonjour et bienvenue,

Si vous nous montriez le schéma en question et les critiques faites à son sujet ?

Commencez par vérifier la conception et les FN de votre BD !

[JeuneJavaiste]

En effet, c'est une bonne idée !

Voici le-dit schéma :

Soit une base de données touristique dédiée aux réservations d’hôtels dans les stations de sports d’hiver en
France. Les six relations qu’elle contient sont :
STATION (NumSta, NomSta, Altitude, Département)
Cette relation donne le numéro d’une station de sports d’hiver, son nom, son altitude (en haut de la station) et
le nom du département français dans lequel elle se trouve.
HOTEL ( NumHot, NomHot, NumSta, Catégorie)
Cette relation donne le numéro d’un hôtel, son nom, le numéro de la station de sports d’hiver dans laquelle il
se trouve, et sa catégorie (le nombre 1 pour un hôtel une étoile, le nombre 2 pour un hôtel deux étoiles, etc.).
CHAMBRE (NumHot, NumCh, NbLits, Prix)
Cette relation donne le numéro de l’hôtel dans lequel se trouve la chambre, le numéro de la chambre, le
nombre de lits qu’elle contient et le prix pour une nuit.
TARIF (NumHot, NumCh, DateDeb, DateFin, Prix)
Cette relation donne le prix pour une nuit dans une période définie par une date de début et une date de fin,
pour une chambre d’hôtel désignée par le numéro de la chambre et par le numéro de l’hôtel.
RESERVATION (NumCli, NumHot, NumCh, DateDeb, DateFin, NbPers, NbResa)
Cette relation donne le numéro d’un client, le numéro de l’hôtel dans lequel il a effectué une réservation, le
numéro de la chambre réservée, la date de début de la réservation, la date de fin de la réservation, le nombre
de personnes pour lesquelles il a effectué la réservation, et le nombre total de réservations effectuées par ce
client depuis l’existence de la base de données.
CLIENT (NumCli, NomCli, VilleCli, TelCli, AnNaissCli, NbResaCli)
Cette relation donne le numéro du client, son nom, sa ville de résidence, son numéro de téléphone, l’année de
naissance et le nombre total de réservations effectuées par ce client depuis l’existence de la base de données.

C'est ce schéma qu'il s'agit de critiquer.

PS : Je vais peut-être sembler idiot mais que veut dire le sigle 'FN' ?

Merci pour cette réponse !

[CinePhil]

FN = formes normales.

Voir cet article qui vous en dira plus sur le sujet et vous aidera à critiquer le schéma. Donnez-nous le début de votre critique et on commentera et complétera éventuellement avec des explications.

Il y a effectivement matière à critiquer. Je vois au moins 7 points à critiquer.

[B.AF]

Formes Normales

A priori si tu vérifies dans ton modèle le niveau 3, c'est potentiellement améliorable, mais c'est déjà bien fiable.

[JeuneJavaiste]

Merci pour ces réponses et toutes mes excuses pour cette réponse tardive.
Voici ce que je dirais du schéma tel qu'il est proposé :

- tout d'abord il manque les clés (mais le sujet demande de les rajouter soi-même)
- je ne comprends pas certains champs : pourquoi ne donner que l'année de naissance du client et non pas sa date de naissance complète (surtout que l'on demande ensuite de rédiger une requête permettant d'obtenir l'âge du client).
Pour le reste, il me semble que le schéma respecte la forme normale de niveau 1.
- il me semble qu'il ne respecte pas la forme normale de niveau 2 (les clés sont soulignées):
RESERVATION (NumCli, NumHot, NumCh, DateDeb, DateFin, NbPers, NbResa)
Dans ce cas, le NbResa (nombre de réservation du client depuis l'existence de la base de donnée) ne dépend que du client, et pas du numéro de chambre.

- Il me semble enfin qu'il y a une redondance dans le mesure où, par exemple le nombre de réservations est présent deux fois dans le schéma.

Merci encore du temps que vous avez pris pour me répondre !

[B.AF]

Bon même si il faudrait tou mettre en perspective de "dans quoi ta db s'incrit";

Déjà Département pourrait faire l'objet d'une normalisation, qui te permettrait en outre de gérer les villes et les indicatifs de téléphone (si tu devais appliquer des règles de validation de données, vérifier que qq1 qui est domicilié à paris n'a pas rentré un numéro commençant par 02)

La catégorie devrait aussi être normalisée, et éventuellement gérer une évolution dans le temps , mais ça c'est davantage pour la partie métier.
On peut toujours partir du principe qu'il s'agit de la derniére bonne connue.

Pour la chambre, un ID mécanique devrait exister de sorte à ne pas utiliser un élément métier dans la clef, ce qui pourrait te poser des pb d'audit (si jamais tu veux faire des modifications)

Tarif est un non sens pousique le tarif d'une chambre d'un hôtel est le tarif rataché à l'identifiant d'une chambre. De même c'est un non sens que de référencer le prix de la chambre et dans chambre et dans tarif. L'information est redondante et sans relation.

Réservation devrait disposer d'une clef unique et non dépendante des critére de la réservation. De même le nombre de réservation est assez "space"; c'est le nombre de réservation de quoi ? De la chambre, cela doit être dans chambre.
En outre, elle devrait se suffire de la relation vers le tarif pour identifier la chambre et de la relation vers le client pour identifier quel client à réserver cette chambre.

Entre autres...

[CinePhil]

STATION (NumSta, NomSta, Altitude, Département)
Cette relation donne le numéro d’une station de sports d’hiver, son nom, son altitude (en haut de la station) et
le nom du département français dans lequel elle se trouve.

1) Comme dit par un autre, il ne devrait pas y avoir le nom du département mais un identifiant du département, éventuellement son numéro (alphanumérique, penser à la Corse 2A et 2B... il y a des stations de ski en Corse ?).

HOTEL ( NumHot, NomHot, NumSta, Catégorie)
Cette relation donne le numéro d’un hôtel, son nom, le numéro de la station de sports d’hiver dans laquelle il
se trouve, et sa catégorie (le nombre 1 pour un hôtel une étoile, le nombre 2 pour un hôtel deux étoiles, etc.).

2) On peut éventuellemet dire qu'il devrait y avoir une table Categories pour donner la signification des codes figurant dans la colonne de cette table.

CHAMBRE (NumHot, NumCh, NbLits, Prix)
Cette relation donne le numéro de l’hôtel dans lequel se trouve la chambre, le numéro de la chambre, le nombre de lits qu’elle contient et le prix pour une nuit.

3) Chaque chambre devrait avoir un identifiant alors que NumCh semble ici représenter plutôt le numéro de la chambre dans l'hôtel, donc plusieurs n° 10, 15...

TARIF (NumHot, NumCh, DateDeb, DateFin, Prix)
Cette relation donne le prix pour une nuit dans une période définie par une date de début et une date de fin,
pour une chambre d’hôtel désignée par le numéro de la chambre et par le numéro de l’hôtel.

4) Puisque une chambre appartiendrait à un seul hôtel si la chambre avait, comme préconisé ci-dessus, un identifiant unique, il est inutile de répéter ici le NumHot.
5) L'existence de cette table Tarif rend redondant le Prix de la chambre figurant dans la table Chambre.

RESERVATION (NumCli, NumHot, NumCh, DateDeb, DateFin, NbPers, NbResa)
Cette relation donne le numéro d’un client, le numéro de l’hôtel dans lequel il a effectué une réservation, le
numéro de la chambre réservée, la date de début de la réservation, la date de fin de la réservation, le nombre
de personnes pour lesquelles il a effectué la réservation, et le nombre total de réservations effectuées par ce
client depuis l’existence de la base de données.

6) Une fois encore, l'identifiant de la chambre suffirait et la répétition du numéro de l'hôtel est inutile.
7) La construction de cette table suppose qu'une réservation ne concerne qu'une chambre et qu'un client qui réserve deux chambres fera deux réservations. C'est discutable mais pourquoi pas !
8) Par contre, le NbResa n'a rien à faire dans cette BDD. C'est une donnée calculable à partir des autres infos.

CLIENT (NumCli, NomCli, VilleCli, TelCli, AnNaissCli, NbResaCli)
Cette relation donne le numéro du client, son nom, sa ville de résidence, son numéro de téléphone, l’année de
naissance et le nombre total de réservations effectuées par ce client depuis l’existence de la base de données.

9) Comme pour les départements dans la première table, la VilleCli devrait être un identifiant venant d'une table des Villes, éventuellement elle-même associée à la table des départements.
10) Une fois encore, NbResaCli est une donnée calculable et n'a pas à figurer en BDD.
11) Comme souligné dans un autre message, on ne peut pas calculer un âge exact avec seulement l'année. Il vaudrait mieux avoir la date de naissance complète.

J'avais trouvé 7 points criticables à la première lecture rapide, en voilà maintenant 11. Certains peuvent être regroupés (l'IdChambre - point 3, 4 et 6) et ne sont peut-être pas des erreurs du strict point de vue des formes normales.

[B.AF]

8) Par contre, le NbResa n'a rien à faire dans cette BDD. C'est une donnée calculable à partir des autres infos.

Oui mais bon dans le temps, faire cela risque dans certains SGBD sur des volumes importants de te créer des problèmes de plans d'exécution, vu que tu vas devoir utiliser les index.

Après fonctionnellement, il faut peut être pouvoir créer un modéle de statistiques à enregistrer.


6) Une fois encore, l'identifiant de la chambre suffirait et la répétition du numéro de l'hôtel est inutile.

Ben non, ce qu'il faut c'est référencer le tarif puisque la relation logique d'une réservation est due à la disponibilité de la chambre qui au moment de la réservation aura un certain tarif.

Même remarque pour le nombre de résa du client.

[CinePhil]

Oui mais bon dans le temps, faire cela risque dans certains SGBD sur des volumes importants de te créer des problèmes de plans d'exécution, vu que tu vas devoir utiliser les index.

Quel est le volume de données ?
Le nombre de stations de ski françaises. Une centaine ?
Le nombre d'hôtels dans ces stations. Un millier ?
Le nombre de réservations par an. Disons une moyenne de 40 chambres par hôtel, une trentaine de semaines par an... 120 000 réservations par an ?
Les SGBD sont dimensionnés pour travailler avec des volumes de données bien plus importants. Maintenant, si le cahier des charges prévoit une purge des données chaque année avec conservation des statistiques, la colonne NbResa est justifiée.

6) Une fois encore, l'identifiant de la chambre suffirait et la répétition du numéro de l'hôtel est inutile.

Ben non, ce qu'il faut c'est référencer le tarif puisque la relation logique d'une réservation est due à la disponibilité de la chambre qui au moment de la réservation aura un certain tarif.

Euh... je ne vois pas le rapport entre les deux là !
M. Dupont réserve la chambre 12 de l'Hôtel des Cimes à Val Trucmuche 2000 du 10 au 15 février 2009. Cette chambre porte l'identifiant 248.
C'est pas le tarif qui va enregistrer cette info !

[B.AF]

Si tu regardes le modéle d'origine si :

Une chambre est associées à un hôtel
A un instant t la chambre a un tarif
La réservation du client lambda n'a donc besoin que de référencer le tarif, puisque le tarif représente le côut de la chambre dans l'hôtel.

pour retrouver la chambre il suffit donc de connaitre le tarif impliqué, qui connait la chambre donc l'hotel.

Concernant les données de type statistiques d'exploitation, il est bien plus souple de les calculer lors des évenements associés que de recourir à des scalaires. Ne serait-ce qu'en terme d'évolutivité.