IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Merise Discussion :

[MCD] besoin d'aide sur cardinalité client - voiture dans le cas d'une location


Sujet :

Merise

  1. #1
    Membre régulier
    Profil pro
    Inscrit en
    avril 2004
    Messages
    333
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2004
    Messages : 333
    Points : 123
    Points
    123
    Par défaut [MCD] besoin d'aide sur cardinalité client - voiture dans le cas d'une location
    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é.

    Nom : Capture d’écran 2022-04-28 à 11.51.52.png
Affichages : 80
Taille : 24,2 Ko

    - 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

  2. #2
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    8 393
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 8 393
    Points : 30 225
    Points
    30 225
    Billets dans le blog
    2
    Par défaut
    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

    Nom : Sans titre.png
Affichages : 59
Taille : 11,5 Ko


    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)
    );

  3. #3
    Membre régulier
    Profil pro
    Inscrit en
    avril 2004
    Messages
    333
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2004
    Messages : 333
    Points : 123
    Points
    123
    Par défaut
    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

  4. #4
    Membre chevronné
    Avatar de Paprick
    Homme Profil pro
    Professeur des Universités
    Inscrit en
    juin 2019
    Messages
    514
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Professeur des Universités
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2019
    Messages : 514
    Points : 2 045
    Points
    2 045
    Par défaut
    Bonsoir,
    Citation Envoyé par ctobini Voir le message
    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 !
    Patrick Bergougnoux - Professeur des Universités au Département Informatique de l'IUT de Toulouse III
    La simplicité est la sophistication suprême (Léonard de Vinci)
    LIVRE : Modélisation Conceptuelle de Données - Une Démarche Pragmatique
    Looping - Logiciel de modélisation gratuit et libre d'utilisation

  5. #5
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    8 393
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 8 393
    Points : 30 225
    Points
    30 225
    Billets dans le blog
    2
    Par défaut
    @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.

  6. #6
    Membre régulier
    Profil pro
    Inscrit en
    avril 2004
    Messages
    333
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2004
    Messages : 333
    Points : 123
    Points
    123
    Par défaut
    Merci à vous deux, c'est beaucoup plus clair 😊

  7. #7
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    8 393
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 8 393
    Points : 30 225
    Points
    30 225
    Billets dans le blog
    2
    Par défaut
    Merci de penser à passer le sujet à "résolu" si c'est bien le cas

  8. #8
    Membre régulier
    Profil pro
    Inscrit en
    avril 2004
    Messages
    333
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2004
    Messages : 333
    Points : 123
    Points
    123
    Par défaut
    C'est fait, désolé de l'oubli 😊

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Aide sur python et CGI dans un cas particulier
    Par Papaillou dans le forum Réseau/Web
    Réponses: 0
    Dernier message: 11/04/2009, 17h37
  2. Réponses: 2
    Dernier message: 24/06/2008, 09h46
  3. Filemaker ... besoin d'aide sur les Plugin
    Par joange dans le forum Autres SGBD
    Réponses: 3
    Dernier message: 22/04/2004, 10h16
  4. [intermedia] besoin d'aide sur script PL/SQL
    Par SteelBox dans le forum PL/SQL
    Réponses: 8
    Dernier message: 05/01/2004, 19h59
  5. [CR] besoin d'aide sur les formules
    Par GuillaumeDSA dans le forum Formules
    Réponses: 4
    Dernier message: 10/07/2003, 12h19

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo