Discussion :

[ollivier]

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.

[SQLpro]

Le modèle correct est le suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 +

[Yanika_bzh]

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

[ollivier]

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.