Discussion :

[ctobini]

Bonjour à tous,

J'aurais besoin de votre avis du point de vue de la logique des relations et cardinalités entre les entités client et voiture dans le cas de la gestion soit des données courantes (diagramme du haut dans l'image), soit en historisant (diagramme du bas dans l'image).

L'hypothèse est la plus simple : un client peut louer une à plusieurs voitures, une voiture ne peut-être louée qu'à un client à la fois. Un client n'existe que s'il a déjà loué.



- dans le cas d'une gestion non historisée (seule la location en cours serait gérée), la relation serait pour moi 1,n côté client qui peut louer plusieurs voitures et 1,1 côté voiture qui n'est rattachée qu'à un client à la fois :

CLIENT(idClient)
idClient clé primaire

VOITURE(idVoiture, date_location, idClient)
idVoiture : clé primaire
idClient : clé étrangère référence CLIENT(idClient)




- dans le cas d'une historisation, il me semble logique que ce soit 1,n 1,n car une voiture peut être rattachée à plusieurs relations A_LOUE :

CLIENT(idClient)
idClient clé primaire

VOITURE(idVoiture)
idVoiture : clé primaire

A_LOUE(idClient, idVoiture, date_location, date_retour)
idClient : clé primaire, clé étrangère référence CLIENT(idClient)
idVoiture : clé primaire, clé étrangère référence VOITURE(idVoiture)
date_location : clé primaire

Je mets la date de location en PK,FK afin que l'unicité soit garantie pour un client et une date de location. La date de fin de location sera mise à jour à échéance.

Sur le principe auriez-vous fait de cette manière l'historisation ?

Merci,

C. Tob

[escartefigue]

Bonjour,

il faut veiller à ce qu'une même voiture ne puisse pas être louée simultanément par plusieurs clients à la même date.
Pour ce besoin, il faut faire participer une entité-type fictive [DATE] dans une relation ternaire avec [CLIENT] et [VOITURE] en ajoutant une contrainte pour que la table associative issue de l'association (louer) ait pour clef unique le couple identifiant du véhicule+la date

Le modèle conceptuel est donc




L'entité-type [CA_calendrier] est entre parenthèses car elle ne deviendra pas une table, elle ne sert qu'à faire participer la date à la clef primaire de la table associative.
La flèche qui pointe vers CL_client matérialise la contrainte qui permet d'évacuer l'identifiant client de cette PK, le rendant de fait unique pour un véhicule et une date

Ce qui donne le DDL suivant (ici décliné pour SQL server) :

Code SQL :

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
20
21
22
CREATE TABLE CL_client(
   CL_ident INT IDENTITY,
   CL_nom VARCHAR(50) NOT NULL,
   CL_prenom VARCHAR(50) NOT NULL,
   PRIMARY KEY(CL_ident)
);
 
CREATE TABLE VO_voiture(
   VO_ident INT IDENTITY,
   VO_immatriculation CHAR(10) NOT NULL,
   PRIMARY KEY(VO_ident),
   UNIQUE(VO_immatriculation)
);
 
CREATE TABLE LO_louer(
   VO_ident INT,
   CA_date DATE,
   CL_ident INT NOT NULL,
   PRIMARY KEY(VO_ident, CA_date),
   FOREIGN KEY(VO_ident) REFERENCES VO_voiture(VO_ident),
   FOREIGN KEY(CL_ident) REFERENCES CL_client(CL_ident)
);

[ctobini]

Bonjour escartefigue et merci beaucoup pour l'explication, c'est très clair.

Dans ce type de relation j'imagine que la date doit avoir une granularité assez fine (heures et minutes) pour assurer l'unicité pour gérer le cas, certes peu probable, où un client louerait et rendrait une voiture puis la louerait à nouveau dans la même journée

Je crois avoir lu que ce que vous proposez est une association relative ?

C. Tob

[Paprick]

Bonsoir,

Je crois avoir lu que ce que vous proposez est une association relative ?

Non, il s'agit en fait d'une association ternaire (souvent appelée tri-patte) qui, dans ce cas, intègre une classe d'entité fictive (qui ne produira pas de table).
La notion d'indentifiant relatif intervient dans le cas d'une cardinalité 1,1 avec récupération de la clé étrangère pour la faire participer à la clé primaire de la table associée .

Bonne continuation !

[escartefigue]

@ctobini : il s'agit effectivement d'une association ternaire.

Concernant la granularité, indépendamment du cas peu probable en effet de la même personne louant le même véhicule plusieurs fois le même jour, on peut par contre plus facilement imaginer deux personnes louant le même véhicule l'un le matin et l'autre l'après midi par exemple.
En ce cas, il faudra remplacer la date de CA_calendrier par un horodatage et ajouter un attribut "LO_date_heure_fin" (date et heure de fin de location) également de type horodatage, mais positionné dans l'association "LO_louer". C'est ce qui permettra de vérifier qu'il n'y a pas de chevauchements de périodes de location pour un même véhicule.

Pour être complet, on ajoutera une contrainte "check" pour s'assurer que la date et heure de fin de location est supérieure à la date et heure de début de location.

[ctobini]

Merci à vous deux, c'est beaucoup plus clair 😊

[escartefigue]

Merci de penser à passer le sujet à "résolu" si c'est bien le cas

[ctobini]

C'est fait, désolé de l'oubli 😊