2 ou 3 tables pour la relation client rendez-vous

Bonjour,

J’aimerai avoir votre avis pour savoir si je dois créer 2 ou 3 tables dans ma bd pour la relation suivante :

Un client peut prendre 0 ou n rendez-vous
Un rendez-vous peut être associé à 0 ou 1 client

L’application permet :
. de créer, modifier, supprimer des clients.
. de créer, modifier, supprimer des rendez-vous sans les associer à un client

Il est ensuite possible d’associer un rendez-vous à un client s’il ne l’est pas déjà ou de couper le lien entre le rendez-vous et le client pour rendre le rendez-vous disponible.

Dans un premier temps j’ai créé une table client (client_id, nom, prénom, …) et une table rendez-vous (rdv_id, libellé du rendez vous, date du rendez-vous, heure de rendez-vous, …). La table rendez-vous possède une clef étrangère contenant l’id du client pour les rendez-vous associés à un client ou null pour les rendez-vous qui ne sont pas encore associés à un client.

Cette première solution fonctionne parfaitement mais mon directeur de mémoire m’indique que cette solution ne respecte pas l’intégrité référentiel.

Il me demande de remplacer la clef étrangère par une table client_rdv (client_id, rdv_id). Avec cette deuxième solution il suffit d’ajouter un enregistrement dans client_rdv lorsqu’on associe un client à un rendez-vous ou de supprimer un enregistrement dans cette table lorsque l’on libère un rendez-vous.

La remarque de mon directeur de mémoire est elle justifiée ? Est-il grave d’avoir un clef étrangère qui pointe sur rien ? La deuxième solution fonctionne, mais elle permet d’associer plusieurs clients à un rendez-vous. Or, je ne veux pas associer plusieurs clients à un rendez-vous, mais au maximum un seul.

Personnellement je suis plutôt favorable à la première solution, mais si je veux défendre cette solution il me faut m’appuyer sur des arguments précis.

Théoriquement, quelle est selon vous la meilleure solution ?
En pratique, quelle solution retient-on en général ?

Merci de m’éclairer car je ne sais pas trop ou trouver la réponse.

Le modèle correct est le suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

CREATE TABLE T_CLIENT_CLI (CLI_ID INTEGER NOT NULL PRIMARY KEY, CLI_NOM ... ) CREATE TABLE T_PLANNING_PLN (PLN_ID INTEGER NOT NULL PRIMARY KEY, PLN_DATE DATE NOT NULL, PLN_HEURE TIME NOT NULL, CONSTRAINT UK_DATEHEURE UNIQUE (PLN_DATE, PLN_HEURE) ) CREATE TABLE T_RENDEZ_VOUS_RDV (PLN_ID INTEGER NOT NULL FOREIGN KEY REFERENCES T_PLANNING_PLN (PLN_ID), CLI_ID INTEGER NOT NULL FOREIGN KEY REFERENCES T_CLIENT_CLI (CLI_ID), CONSTRAINT PK_RDV PRIMARY KEY (PLN_ID, CLI_ID) )

---

à partir de là tout est possible, mais :
1) alimente la table T_PLANNING_PLN depuis aujourd'hui jusqu'à la date de la retraite (maintenant 65 ans...)
2) prévoir des horaires par tranche de 10 ou 15 ou 20 ou 30 minutes suivant le cas et rien pour les jour fériés, les dimanches....

Bien évidemment des tables de paramétrage du planning serait les bienvenues :
- Elles permetraient par exemple de stipuler les jours fériés et plus généralement les jours de fermture (congès)
- elles permettrait de stipuler la durée "normale" d'un RV et les horaires de réception

Exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

CREATE TABLE T_PLANNING_JOUR_SEMAINE_PJS (PJS_ID INTEGER NOT NULL PRIMARY KEY, PJS_NOM_JOUR CHAR(10) NOT NULL, PJS_TRAVAILLE BOOLEAN NOT NULL DEFAULT TRUE, PJS_HEURE_OUVERTURE TIME NOT NULL DEFAULT '09:00', PJS_HEURE_FERMERTURE TIME NOT NULL DEFAULT '18:00' ) CREATE TABLE T_PLANNING_JOUR_FERIE_FIXE_PFF (PFF_MOIS INTEGER NOT NULL CHECK (VALUE BETWEEN 0 AND 12), PFF_JOUR INTEGER NOT NULL CHECK (VALUE BETWEEN 1 AND 31), PFF_LIBELLE VARCHAR(64), CONSTRAINT PK_PFM PRIMARY KEY (PFF_MOIS, PFF_JOUR) ) CREATE TABLE T_PLANNING_JOUR_FERIE_MOBILE_PFM (PFM_DATE DATE NOT NULL PRIMARY KEY, PFM_LIBELLE VARCHAR(64) )

---

etc...

Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/gestiontemps/

A +

Si je me rappelle mes cours MERISE :) :)
Lorsque que tu traites une association avec au moins une cardinalité maximale à 1 (ce qui est le cas chez toi), il faut créer 1 table par entité et faire migrer la clé primaire de l'entité de cardinalité (n) dans la table de l'entité de cardinalité (1), bien sur, les propriétés dans l'association migrent aussi de la meme maniere.

Donc je pense que ta solution est conforme a la normalisation MERISE.

bon courage

Merci pour les réponses.

J’ai modifié le mapping hibernate de mon appli struts pour passer à 3 tables. La bd nouvelle est créée. Mais maintenant dans la liste des rendez-vous, le nom de la personne associée n’apparaît pas toujours comme il faut. Si je ferme ie et que je l’ouvre a nouveau je les données sont fausses. Si je recommence ça marche. Les données en bases sont toujours bonne mais en mémoire les données sont parfois pas a jour.

Bizare.