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

  1. #21
    Futur Membre du Club
    Conception d'un MCD pour une assurance automobile
    Bonjour Monsieur,
    Merci pour votre intervention et je suis vraiment d'avis sur votre point de vue.
    Je viens d'apporter quelques modifications dans le MCD dont voici ci-dessous.
    Avez vous des remarques sur ce modèle?
    Merci par avance.

  2. #22
    Futur Membre du Club
    Conception d'un MCD pour une assurance automobile
    Bonjour Monsieur,
    Merci pour votre contribution.
    Ce qui donne (PK soulignées) :

    [MA_MARQUE (MA_ident, MA_nom...) 0,n --- proposer --- 1,1(R) [MO_MODELE (MO_ident, MO_nom, MO_places...)] 0,n --- appartenir --- 1,1(R) [VH_VEHICULE(VH_ident, VH_immatriculation, VH_date_immat...)]

    et

    [MO_MODELE (MO_ident, MO_nom, MO_places...)] 1,1 --- utiliser --- 0,N [EN_energie(EN_ident, EN_code, EN_libelle...)]
    Pouvez-vous schématisé le modèle en question?
    Merci par avance.
    Voici le MCD modifié ci-dessous:

  3. #23
    Expert éminent sénior
    Voici



    Ce qui donne le script 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
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    CREATE TABLE MA_marque(
       MA_ident COUNTER,
       MA_nom VARCHAR(50) NOT NULL UNIQUE,
       PRIMARY KEY(MA_ident)
    );
    
    CREATE TABLE EN_energie(
       EN_ident COUNTER,
       EN_code CHAR(4) NOT NULL UNIQUE,
       EN_libelle VARCHAR(80) NOT NULL,
       PRIMARY KEY(EN_ident)
    );
    
    CREATE TABLE MO_modele(
       MA_ident INT,
       MO_ident COUNTER,
       MO_nom VARCHAR(80) NOT NULL,
       MO_millesime CHAR(4) NOT NULL,
       MO_places DECIMAL(3,0) NOT NULL,
       EN_ident INT NOT NULL,
       PRIMARY KEY(MA_ident, MO_ident),
       FOREIGN KEY(MA_ident) REFERENCES MA_marque(MA_ident),
       FOREIGN KEY(EN_ident) REFERENCES EN_energie(EN_ident)
    );
    
    CREATE TABLE VH_vehicule(
       MA_ident INT,
       MO_ident INT,
       VH_ident COUNTER,
       VH_immat CHAR(15) NOT NULL,
       VH_date_immat DATE NOT NULL,
       PRIMARY KEY(MA_ident, MO_ident, VH_ident),
       FOREIGN KEY(MA_ident, MO_ident) REFERENCES MO_modele(MA_ident, MO_ident)
    );
    Si vous avez besoin des éléments relatifs à la motorisation (puissance réelle, nombre de cylindres, régime maxi etc...) alors le modèle doit être rattaché à une entité-type motorisation et c'est la motorisation qui sera en lien avec l'énergie. Modélisation sans doute requise pour un constructeur mais probablement pas dans votre cas

  4. #24
    Expert éminent sénior
    Bonsoir Zidane7,

    La modélisation par généralisation/spécialisation ne vous séduit manifestement pas.

    Vous préférez donc en passer par la mise en oeuvre de l’association PFC_S entre PFC et SOUS_CATEGORIE.

    Les conséquences de votre choix au stade SQL :

    (1) Le bonhomme NULL se fera un malin plaisir de ficher la patouille dans les clés étrangères.

    (2) Rien n’empêche que, via l’association PFC_C, la PFC pfc1 fasse référence à la catégorie c1, et d’autre part, via les associations PFC_S et C_SC, que cette PFC fasse référence à la catégorie c2.

    Déjà pour empêcher que ne se produise la situation décrite avec le cas (2), en Merise on modélise une contrainte d’inclusion. Pour l’étude et la mise en oeuvre de ce type de contrainte, reportez-vous à la page 124 (identifiant relatif) de l’ouvrage de référence de D. Nanci et B Espinasse Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001).

    Description de la contrainte d’inclusion : si, via l’association PFC_S, une PFC fait référence à une sous-catégorie, alors la catégorie référencée par cette sous-catégorie doit être celle qui est directement référencée par la PFC (via l’association PFC_C). Dans le diagramme qui suit, La contrainte d’inclusion est symbolisée par la lettre « I » incrustée dans un cercle, l’entité-type CATEGORIE (branchée sur la contrainte par une ligne en pointillés) est le pivot de la contrainte, l’association PFC_S en est la portée et l’association PFC_C en est la cible.



    Mais pour être complet et que ça puisse fonctionner, il faut aussi que l’association C_SC participe à la portée de la contrainte :



    Si conceptuellement tout ceci est satisfaisant, il n’en demeure pas moins qu’il y a un hic dès qu’on redescend sur terre : la déclaration de la contrainte au stade SQL est en effet complètement à votre charge (assertion dans le cas de la norme SQL, programmation d’un trigger dans le cas des SGBD, cf. page 190 de l’ouvrage de référence que j’ai cité)...

    Pour éviter les tracas provoqués par la présence du bonhomme NULL dans les clés étrangères et pouvoir en plus implanter la contrainte d’inclusion sans avoir à la déclarer, on procède ainsi : on remplace l’association PFC_S par une entité-type (nommons-la PFC_SC), identifiée relativement à PFC (dont elle hérite de l’identifiant, à savoir la paire {puissanceId, catId}).

    Il faut aussi qu’au stade SQL, PFC_SC soit dotée d’un attribut correspondant à la catégorie de la sous-catégorie référencée par PFC_SC (on verra pourquoi). Tout cela se traduit par le MCD suivant :


    Code SQL :

    CREATE TABLE PUISSANCE
    (
       puissanceId INT,
       puissanceMin INT NOT NULL,
       puissanceMax INT NOT NULL,
       CONSTRAINT PUISSANCE_PK PRIMARY KEY(puissanceId)
    );
    
    CREATE TABLE CATEGORIE
    (
       catId INT,
       catCode VARCHAR(24) NOT NULL,
       catLibelle VARCHAR(48) NOT NULL,
       CONSTRAINT CATEGORIE_PK PRIMARY KEY(catId),
       CONSTRAINT CATEGORIE_AK UNIQUE(catCode)
    );
    
    CREATE TABLE SOUS_CATEGORIE
    (
       catId INT,
       sousCatId INT,
       sousCatCode VARCHAR(4) NOT NULL,
       sousCatLibelle VARCHAR(48) NOT NULL,
       CONSTRAINT SOUS_CATEGORIE_PK PRIMARY KEY(catId, sousCatId),
       CONSTRAINT SOUS_CATEGORIE_AK UNIQUE(sousCatCode),
       CONSTRAINT SOUS_CATEGORIE_CATEGORIE_FK FOREIGN KEY(catId) 
           REFERENCES CATEGORIE(catId)
    );
    
    CREATE TABLE PFC
    (
       puissanceId INT,
       catId INT,
       responsabiliteCivile INT NOT NULL,
       defenseRecours INT NOT NULL,
       CONSTRAINT PFC_PK PRIMARY KEY(puissanceId, catId),
       CONSTRAINT PFC_PUISSANCE_FK FOREIGN KEY(puissanceId) 
           REFERENCES PUISSANCE(puissanceId),
       CONSTRAINT PFC_CATEGORIE_FK FOREIGN KEY(catId) 
           REFERENCES CATEGORIE(catId)
    );
    
    CREATE TABLE PFC_SC
    (
       puissanceId INT,
       catId INT,
       catId_1 INT NOT NULL,
       sousCatId INT NOT NULL,
       CONSTRAINT PFC_SC_PK PRIMARY KEY(puissanceId, catId),
       CONSTRAINT PFC_SC_PFC_FK FOREIGN KEY(puissanceId, catId) 
           REFERENCES PFC(puissanceId, catId),
       CONSTRAINT PFC_SC_SOUS_CATEGORIE_FK FOREIGN KEY(catId_1, sousCatId) 
           REFERENCES SOUS_CATEGORIE(catId, sousCatId)
    );
    
    CREATE TABLE VEHICULE
    (
       vehiculeId INT,
       vehiculeSerie VARCHAR(48) NOT NULL,
       vehiculePuissance INT NOT NULL,
       puissanceId INT NOT NULL,
       catId INT NOT NULL,
       CONSTRAINT VEHICULE_PK PRIMARY KEY(vehiculeId),
       CONSTRAINT VEHICULE_PFC_FK FOREIGN KEY(puissanceId, catId) 
           REFERENCES PFC(puissanceId, catId)
    );
    


    Vous observerez que la table PFC_SC contient deux fois la catégorie :

    une 1re fois avec le nom catId, et participant à la clé étrangère faisant référence a la clé primaire de la table PFC ;

    Une 2e fois avec le nom catId_1, et participant à la clé étrangère faisant référence a la clé primaire de la table SOUS_CATEGORIE.

    Pour satisfaire à la contrainte d’inclusion établie dans le MCD, les deux attributs catId et catId_1 doivent prendre des valeurs égales : à cet effet il suffit de les fondre en un seul attribut, nommons le catId. On remplace la déclaration ci-dessus de la table PFC_SC par la suivante :

    CREATE TABLE PFC_SC
    (
       puissanceId INT,
       catId INT,
       sousCatId INT NOT NULL,
       CONSTRAINT PFC_SC_PK PRIMARY KEY(puissanceId, catId),
       CONSTRAINT PFC_SC_PFC_FK FOREIGN KEY(puissanceId, catId) 
           REFERENCES PFC(puissanceId, catId),
       CONSTRAINT PFC_SC_SOUS_CATEGORIE_FK FOREIGN KEY(catId, sousCatId) 
           REFERENCES SOUS_CATEGORIE(catId, sousCatId)
    ); 
    Dans ces conditions, il n’y a donc rien à programmer pour implanter la contrainte d’inclusion, la fusion des deux attributs catId et catId_1 suffit à notre bonheur.

    Pour répondre à l’observation précédente « on verra pourquoi », une condition nécessaire pour s’assurer de la contrainte d’inclusion est de faire en sorte que l’attribut catId participe à la clé primaire de la table SOUS_CATEGORIE, ce qui en autorise ensuite la propagation jusqu’à la table PFC_SC (attribut catId_1).
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  5. #25
    Expert éminent sénior
    Utere sed non abutere
    A l’attention d’Escartefigue,

    Capitaine, tu as identifié l’entité-type VEHICULE relativement à l’entité-type MODELE : tu considères donc que VEHICULE n’est qu’un entité-type faible, c’est-à-dire une propriété multivaluée de MODELE, ce qui est pour le moins contestable. En effet, en toute logique, si on supprime un modèle, alors on devra aussi supprimer tous les véhicules qui s’y rattachent... Par ailleurs, au stade SQL, la clé primaire de VEHICULE n’est plus {VH_ident} mais {MA_ident, MO_ident, VH_ident} et toutes les tables ayant une clé étrangère référençant la table VEHICULE seront affublées des attributs MA_ident et MO_ident, ce qui me paraît très louche conceptuellement parlant.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  6. #26
    Expert éminent sénior
    Effectivement, j'ai été vite en besogne.
    La suppression du modèle est bien peu probable, mais une identification absolue est toutefois plus adaptée pour le véhicule

  7. #27
    Futur Membre du Club
    Conception d'un MCD pour une assurance automobile
    Bonsoir Messieurs,
    Merci pour votre contribution.
    Je dois aussi procéder de la même manière au niveau de la sous_garantie et la catégorie?
    Voici le schéma ci-dessous:
    Avez vous d'autres suggestions?
    Merci par avance.

  8. #28
    Expert éminent sénior
    Bonsoir Zidane7,

    Citation Envoyé par fsmrel Voir le message
    Dans ces conditions, il n’y a donc rien à programmer pour implanter la contrainte d’inclusion


    Le prérequis étant bien sûr, comme je l’avais précisé, d’identifier l’entité-type PFC_SC relativement à l’entité-type PFC et l’entité-type SOUS-CATEGORIE à l’entité-type CATEGORIE. Vous avez oublié de le faire dans votre MCD.

    Concernant les garanties et sous-garanties, selon votre MCD, il n’y a aucune association (directe ou dérivée) entre les entités-types GARANTIE (ou SOUS-GARANTIE) et l’entité-type VEHICULE. Autrement dit, il est impossible de savoir quelles garanties et sous-garanties valent pour un véhicule donné.

    Question 1 :

    Est-il normal qu’on ne sache pas quelles garanties (sous-garanties) valent pour un véhicule donné ?


    Si c'est normal, les entités-types GARANTIE et SOUS-GARANTIE ne sont d’aucune utilité et peuvent disparaître...
    Si non, on verra comment modéliser.

    Question 2 :

    Selon votre MCD, il n’y a pas moyen de savoir à quel contrat précis se rattache un véhicule donné. Est-ce normal ?
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  9. #29
    Futur Membre du Club
    Conception d'un MCD pour une assurance automobile
    Bonjour Monsieur,
    Merci pour vos remarques.
    Voici les modifications que j'ai effectuées sur le MCD.
    Avez vous d'autres remarques?
    Merci par avance.

  10. #30
    Expert éminent sénior
    Bonsoir Zidane7,

    Dans votre dernier MCD, vous avez oublié d’identifier SOUS_CATEGORIE relativement à CATEGORIE et PFC_SC relativement à PFC : revoyez le 3e diagramme que j’ai proposé dans le post #24.

    Toujours selon votre dernier MCD, les garanties sont associées aux contrats ; mais les sous-garanties ne sont associées à rien, elles ont donc inexploitables.

    Vous avez supprimé l’association POSSEDER entre CLIENT et VEHICULE, et vous faites participer VEHICULE à l’association ASSURER entre CONTRAT et CLIENT : d’accord. ASSURER est devenue une association ternaire, dont une patte est porteuse d’une cardinalité 1,1 : il est d’usage de remplacer ce genre de ternaire par deux binaires, mais on ne va pas chipoter. Cela dit l’entité-type CONTRAT est porteuse de la propriété artificielle, identifiante (et dépourvue de toute signification) contratId, mais il lui manque l’identifiant naturel qu’est le numéro du contrat lui-même. Je vous renvoie au post #13 dans lequel j’ai expliqué comment procéder pour modéliser les identifiants naturels (et je vous renvoie au post #15 pour les identifiants artificiels). Ma remarque vaut évidemment pour les entités-types CATEGORIE, SOUS-CATEGORIE, etc., etc., etc.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  11. #31
    Futur Membre du Club
    Conception d'un MCD pour une assurance automobile
    Bonsoir Monsieur,
    Dans votre dernier MCD, vous avez oublié d’identifier SOUS_CATEGORIE relativement à CATEGORIE et PFC_SC relativement à PFC : revoyez le 3e diagramme que j’ai proposé dans le post #24.
    Voici le schéma que vous m'avez donné:
    Selon ce schéma, j'ai effectué des modifications comme suit:
    .
    Pouvez-vous me montrer à travers looping les erreurs sur mon MCD?
    Une fois de plus merci.

  12. #32
    Expert éminent sénior
    Bonjour Zidane7,

    Il y a régression, car vous utilisiez l’identification relative (ou donniez l’illusion de l’utiliser), par exemple dans le post #12, où la patte connectant l’entité-type PFC et l’association PFC_P est porteuse d’une cardinalité 1,1(R) et où la patte connectant l’entité-type PFC et l’association PFC_C est elle aussi porteuse d’une cardinalité 1,1(R). Dans votre dernier post (à savoir le post #31), la lettre « (R) » a disparu, donc l’identification relative elle aussi. En conséquence la génération du code SQL de création des tables est forcément impossible.

    Je rappelle qu’avec Looping, l’identification relative s’obtient en cochant la case « identifiant relatif » dans la fenêtre « Cardinalité ». Exemple :



    Rappel des associations qui doivent être parties prenantes dans l’identification relative :

    PFC_P
    PFC_C
    PFC_SC_P
    SC_C
    EST (entre GARANTIE et SOUS_GARANTIE) en notant que le nom de cette association est à changer car une sous-catégorie n’est pas une catégorie mais en est seulement un élément, un composant : une sous-catégorie appartient à une catégorie.


    Une fois que vous aurez réussi à générer le code SQL, merci de le poster comme je l’ai fait dans le post #24 (utilisez la balise PRE). Si vous n’arrivez pas à générer le code SQL, joignez votre fichier .loo qu’on puisse regarder où ça coince.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  13. #33
    Futur Membre du Club
    Conception d'un MCD pour une assurance automobile
    Bonjour Monsieur,
    Voici le code sql dont vous m'avez demandé:
    CREATE TABLE CATEGORIE(
    categorieId CHAR(8),
    libelleCategorie VARCHAR(50),
    nombreplacecategorie INT,
    PRIMARY KEY(categorieId)
    );

    CREATE TABLE CLIENT(
    clientId CHAR(8),
    nomClient VARCHAR(50),
    prenomClient VARCHAR(50),
    adresseClient VARCHAR(50),
    telephoneClient VARCHAR(30),
    PRIMARY KEY(clientId)
    );

    CREATE TABLE APPORTEUR(
    apporteurId CHAR(8),
    nomApporteur VARCHAR(50),
    prenomApporteur VARCHAR(50),
    PRIMARY KEY(apporteurId)
    );

    CREATE TABLE TYPECONTRAT(
    typeContratId CHAR(8),
    libelleTypeContrat VARCHAR(50),
    PRIMARY KEY(typeContratId)
    );

    CREATE TABLE GARANTIE(
    garantieId CHAR(3),
    Libelle_Garantie VARCHAR(50),
    PRIMARY KEY(garantieId)
    );

    CREATE TABLE Sous_Garantie(
    sousGarantieId CHAR(5),
    libelleSousGarantieId VARCHAR(50),
    categorieId CHAR(8) NOT NULL,
    garantieId CHAR(3) NOT NULL,
    PRIMARY KEY(sousGarantieId),
    FOREIGN KEY(categorieId) REFERENCES CATEGORIE(categorieId),
    FOREIGN KEY(garantieId) REFERENCES GARANTIE(garantieId)
    );

    CREATE TABLE PUISSANCE(
    puissanceId CHAR(8),
    puissanceMin INT,
    puissanceMax BIGINT,
    PRIMARY KEY(puissanceId)
    );

    CREATE TABLE PFC(
    categorieId CHAR(8),
    puissanceId CHAR(8),
    responsabilitecivile VARCHAR(50),
    PRIMARY KEY(categorieId, puissanceId),
    FOREIGN KEY(categorieId) REFERENCES CATEGORIE(categorieId),
    FOREIGN KEY(puissanceId) REFERENCES PUISSANCE(puissanceId)
    );

    CREATE TABLE PRODUCTEUR(
    producteurId VARCHAR(50),
    Nomproducteur VARCHAR(50),
    Prenomprodcteur VARCHAR(50),
    PRIMARY KEY(producteurId)
    );

    CREATE TABLE AGENCE(
    agenceId COUNTER,
    nomAgence VARCHAR(50),
    dateCreation DATE,
    PRIMARY KEY(agenceId)
    );

    CREATE TABLE SOUS_CATEGORIE(
    categorieId CHAR(8),
    souscategorieId INT,
    libelleSousCategorie VARCHAR(50),
    PRIMARY KEY(categorieId, souscategorieId),
    FOREIGN KEY(categorieId) REFERENCES CATEGORIE(categorieId)
    );

    CREATE TABLE PFC_SC(
    categorieId CHAR(8),
    puissanceId CHAR(8),
    categorieId_1 CHAR(8) NOT NULL,
    souscategorieId INT NOT NULL,
    PRIMARY KEY(categorieId, puissanceId),
    FOREIGN KEY(categorieId, puissanceId) REFERENCES PFC(categorieId, puissanceId),
    FOREIGN KEY(categorieId_1, souscategorieId) REFERENCES SOUS_CATEGORIE(categorieId, souscategorieId)
    );

    CREATE TABLE VEHICULE(
    vehiculeId CHAR(8),
    immatriculation VARCHAR(20),
    marque VARCHAR(50),
    type VARCHAR(50),
    energie VARCHAR(15),
    serie VARCHAR(40),
    vpuissance INT,
    nombreDePlaceCarteGrise INT,
    nombreDePlaceCabine BIGINT,
    categorieId CHAR(8) NOT NULL,
    puissanceId CHAR(8) NOT NULL,
    PRIMARY KEY(vehiculeId),
    FOREIGN KEY(categorieId, puissanceId) REFERENCES PFC(categorieId, puissanceId)
    );

    CREATE TABLE CONTRAT(
    contratId CHAR(10),
    dateEffetContrat DATE,
    dateExpirationContrat DATE,
    agenceId INT NOT NULL,
    producteurId VARCHAR(50) NOT NULL,
    vehiculeId CHAR(8) NOT NULL,
    clientId CHAR(8) NOT NULL,
    PRIMARY KEY(contratId),
    FOREIGN KEY(agenceId) REFERENCES AGENCE(agenceId),
    FOREIGN KEY(producteurId) REFERENCES PRODUCTEUR(producteurId),
    FOREIGN KEY(vehiculeId) REFERENCES VEHICULE(vehiculeId),
    FOREIGN KEY(clientId) REFERENCES CLIENT(clientId)
    );

    CREATE TABLE AVENANT(
    avenantId CHAR(8),
    libelleAvenant VARCHAR(50),
    dateEffetAvenant DATE,
    dateExpirationAvenant DATE,
    contratId CHAR(10) NOT NULL,
    PRIMARY KEY(avenantId),
    FOREIGN KEY(contratId) REFERENCES CONTRAT(contratId)
    );

    CREATE TABLE APPORTER(
    contratId CHAR(10),
    apporteurId CHAR(8),
    dateapporteur DATE,
    PRIMARY KEY(contratId, apporteurId),
    FOREIGN KEY(contratId) REFERENCES CONTRAT(contratId),
    FOREIGN KEY(apporteurId) REFERENCES APPORTEUR(apporteurId)
    );

    CREATE TABLE APPARTENIR(
    contratId CHAR(10),
    typeContratId CHAR(8),
    PRIMARY KEY(contratId, typeContratId),
    FOREIGN KEY(contratId) REFERENCES CONTRAT(contratId),
    FOREIGN KEY(typeContratId) REFERENCES TYPECONTRAT(typeContratId)
    );

    CREATE TABLE PROTEGER(
    categorieId CHAR(8),
    garantieId CHAR(3),
    PRIMARY KEY(categorieId, garantieId),
    FOREIGN KEY(categorieId) REFERENCES CATEGORIE(categorieId),
    FOREIGN KEY(garantieId) REFERENCES GARANTIE(garantieId)
    );

    CREATE TABLE ASSOCIER(
    contratId CHAR(10),
    garantieId CHAR(3),
    PRIMARY KEY(contratId, garantieId),
    FOREIGN KEY(contratId) REFERENCES CONTRAT(contratId),
    FOREIGN KEY(garantieId) REFERENCES GARANTIE(garantieId)
    );
    Voici le MCD.
    Une fois de plus merci.

  14. #34
    Expert éminent sénior
    Bonjour Zidane7,

    On avance dans le bon sens. J’ai quand même un certain nombre de remarques à faire. Commençons par le commencement.

    SGBD

    Quel est votre SGBD ?


    Prise en compte de NOT NULL

    Prenons par exemple le cas de la table CLIENT. Votre déclaration est la suivante :

    CREATE TABLE CLIENT(
    clientId CHAR(8),
    nomClient VARCHAR(50),
    prenomClient VARCHAR(50),
    adresseClient VARCHAR(50),
    telephoneClient VARCHAR(30),
    PRIMARY KEY(clientId)
    ); 


    Les attributs qui ne participent pas à la clé primaire de la table doivent être explicitement déclarés NOT NULL. Pour la clé primaire, c'est inutile, NOT NULL est implicite :

    Avec la prise en compte de NOT NULL :

    CREATE TABLE CLIENT(
    clientId CHAR(8),
    nomClient VARCHAR(50) NOT NULL,
    prenomClient VARCHAR(50) NOT NULL,
    adresseClient VARCHAR(50) NOT NULL,
    telephoneClient VARCHAR(30) NOT NULL,
    PRIMARY KEY(clientId)
    ); 


    Cette prise en compte de NOT NULL vaut pour toutes les tables.

    D’autres remarques vont suivre.

    PS. N’oubliez pas de liker les posts qui ont pu vous aider....
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  15. #35
    Expert éminent sénior
    Bonjour Zidane7,

    Clés primaires avec attributs artificiels

    J’ai écrit dans le post #6 qu’il faut distinguer les attributs naturels des attributs artificiels.

    Pour reprendre le cas de la table CLIENT, nomClient, prenomClient, adresseClient, telephoneClient sont les attributs naturels, prenant les valeurs que leur affecte l’utilisateur. Cette table doit en plus être dotée d’un attribut artificiel qui sera réservé pour la clé primaire (inférée de l’identifiant de l’entité-type CLIENT du MCD). Appelons clientId cet attribut artificiel : c’est le SGBD qui, sous le capot, lui affecte ses valeurs, lesquelles nous restent cachées, nous n’y avons pas accès, on se fiche donc de ces valeurs. Concernant l’attribut artificiel clientId, nos propres requêtes SQL ne sont que du genre :

    WHERE CLIENT.clientId = CONTRAT.clientId


    Où l’on mentionne clientId mais pas ses valeurs puisqu’on doit les considérer comme inaccessibles (sinon on ne pourra que s’en mordre les doigts).

    Avec Looping, pour déclarer un attribut artificiel (par exemple clientId) ayant pour vocation d’être identifiant (clé primaire au stade SQL) :



    Selon le SGBD, Compteur donnera lieu à IDENTITY (DB2, SQL Server, Sybase), COUNTER (MS ACCESS), AUTO_INCREMENT (MySQL), SERIAL (PostgreSQL), etc.


    Clés alternatives

    Une clé alternative garantit l’unicité au même titre qu’une clé primaire, mais elle sert fondamentalement comme point d’entrée dans la base de données. Par exemple, si clientId est clé primaire de la table CLIENT, alors comme je l’ai écrit dans le post #13, il sera opportun de définir un identifiant alternatif codeClient à utiliser pour accéder aux informations d’un client donné. Un identifiant alternatif correspond à un attribut naturel tel que CodeClient, sa valorisation est donc du ressort de l’utilisateur.

    Exemple, accéder à certaines informations du client Zidane7 :

    SELECT telephoneClient, contratNumero, dateEffetContrat
    FROM   CLIENT JOIN CONTRAT ON CLIENT.clientId = CONTRAT.clientId
    WHERE  codeClient = 'zidane7' 
    ;

    Exemple de MCD relatif aux clients et aux contrats :



    Tables correspondantes :

    CREATE TABLE CLIENT
    (
       clientId         INT            IDENTITY,
       codeClient       VARCHAR(16)    NOT NULL,
       nomClient        VARCHAR(48)    NOT NULL,
       prenomClient     VARCHAR(48)    NOT NULL,
       adresseClient    VARCHAR(95)    NOT NULL,
       telephoneClient  VARCHAR(20)    NOT NULL,
       CONSTRAINT CLIENT_PK PRIMARY KEY (clientId),
       CONSTRAINT CLIENT_AK UNIQUE (codeClient)
    );
    
    CREATE TABLE CONTRAT
    (
       contratId               INT           IDENTITY,
       contratNumero           VARCHAR(16)   NOT NULL,
       dateEffetContrat        DATE          NOT NULL,
       dateExpirationContrat   DATE          NOT NULL,
       clientId                INT           NOT NULL,
       CONSTRAINT CONTRAT_PK PRIMARY KEY (contratId),
       CONSTRAINT CONTRAT_AK UNIQUE (contratNumero),
       CONSTRAINT CONTRAT_CLIENT_FK FOREIGN KEY (clientId) 
           REFERENCES CLIENT(clientId)
    ); 


    Concernant les clés primaires et alternatives, la technique valant pour CLIENT et CONTRAT vaut également pour CATEGORIE, SOUS-CATEGORIE, GARANTIE, SOUS-GARANTIE, etc.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  16. #36
    Expert éminent sénior
    Je reviens sur ce que j’ai écrit dans le post #24 :

    Citation Envoyé par fsmrel Voir le message
    Vous observerez que la table PFC_SC contient deux fois la catégorie :

    une 1re fois avec le nom catId, et participant à la clé étrangère faisant référence a la clé primaire de la table PFC ;

    Une 2e fois avec le nom catId_1, et participant à la clé étrangère faisant référence a la clé primaire de la table SOUS_CATEGORIE.

    Pour satisfaire à la contrainte d’inclusion établie dans le MCD, les deux attributs catId et catId_1 doivent prendre des valeurs égales : à cet effet il suffit de les fondre en un seul attribut, nommons le catId. On remplace la déclaration ci-dessus de la table PFC_SC par la suivante :

    CREATE TABLE PFC_SC
    (
       puissanceId INT,
       catId INT,
       sousCatId INT NOT NULL,
       CONSTRAINT PFC_SC_PK PRIMARY KEY(puissanceId, catId),
       CONSTRAINT PFC_SC_PFC_FK FOREIGN KEY(puissanceId, catId) 
           REFERENCES PFC(puissanceId, catId),
       CONSTRAINT PFC_SC_SOUS_CATEGORIE_FK FOREIGN KEY(catId, sousCatId) 
           REFERENCES SOUS_CATEGORIE(catId, sousCatId)
    );


    Dans ces conditions, il n’y a donc rien à programmer pour implanter la contrainte d’inclusion, la fusion des deux attributs catId et catId_1 suffit à notre bonheur.


    Plutôt que de bricoler manuellement le code SQL généré par Looping, on peut demander à celui-ci de participer, en lui fournissant une règle dans laquelle on injecte le code SQL qui va bien et sera recopié par Looping en fin du script SQL qu’il aura généré :

    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  17. #37
    Futur Membre du Club
    Conception d'un MCD pour une assurance automobile
    Bonsoir Monsieur fsmrel,
    Bonjour Zidane7,
    Merci infiniment pour vos interventions.
    Je viens de faire les modifications conformément à ce que vous m'avez dit.
    Regardez le code sql qui accompagne le MCD.
    CREATE TABLE CATEGORIE(
    categorieId COUNTER,
    codecategorie VARCHAR(4) NOT NULL,
    libelleCategorie VARCHAR(50),
    nombreplacecategorie INT,
    PRIMARY KEY(categorieId),
    UNIQUE(codecategorie)
    );

    CREATE TABLE CLIENT(
    clientId COUNTER,
    codeclient VARCHAR(10) NOT NULL,
    nomClient VARCHAR(50),
    prenomClient VARCHAR(50),
    adresseClient VARCHAR(50),
    telephoneClient VARCHAR(30),
    PRIMARY KEY(clientId),
    UNIQUE(codeclient)
    );

    CREATE TABLE APPORTEUR(
    apporteurId CHAR(8),
    codeapporteur VARCHAR(5) NOT NULL,
    nomApporteur VARCHAR(50),
    prenomApporteur VARCHAR(50),
    PRIMARY KEY(apporteurId),
    UNIQUE(codeapporteur)
    );

    CREATE TABLE TYPECONTRAT(
    typeContratId COUNTER,
    codetypecontrat VARCHAR(2) NOT NULL,
    libelleTypeContrat VARCHAR(50),
    PRIMARY KEY(typeContratId),
    UNIQUE(codetypecontrat)
    );

    CREATE TABLE GARANTIE(
    garantieId CHAR(3),
    codegarantie VARCHAR(2) NOT NULL,
    Libelle_Garantie VARCHAR(50),
    PRIMARY KEY(garantieId),
    UNIQUE(codegarantie)
    );

    CREATE TABLE Sous_Garantie(
    sousGarantieId CHAR(5),
    codesousgarantie VARCHAR(2) NOT NULL,
    libelleSousGarantieId VARCHAR(50),
    categorieId INT NOT NULL,
    garantieId CHAR(3) NOT NULL,
    PRIMARY KEY(sousGarantieId),
    UNIQUE(codesousgarantie),
    FOREIGN KEY(categorieId) REFERENCES CATEGORIE(categorieId),
    FOREIGN KEY(garantieId) REFERENCES GARANTIE(garantieId)
    );

    CREATE TABLE PUISSANCE(
    puissanceId COUNTER,
    codepuissance VARCHAR(3) NOT NULL,
    puissanceMin INT,
    puissanceMax BIGINT,
    PRIMARY KEY(puissanceId),
    UNIQUE(codepuissance)
    );

    CREATE TABLE PFC(
    categorieId INT,
    puissanceId INT,
    responsabilitecivile VARCHAR(50),
    PRIMARY KEY(categorieId, puissanceId),
    FOREIGN KEY(categorieId) REFERENCES CATEGORIE(categorieId),
    FOREIGN KEY(puissanceId) REFERENCES PUISSANCE(puissanceId)
    );

    CREATE TABLE AGENCE(
    agenceId COUNTER,
    codeagence VARCHAR(3) NOT NULL,
    nomAgence VARCHAR(50),
    dateCreation DATE,
    PRIMARY KEY(agenceId),
    UNIQUE(codeagence)
    );

    CREATE TABLE SOUS_CATEGORIE(
    categorieId INT,
    souscategorieId INT,
    codesouscategorie VARCHAR(4) NOT NULL,
    libelleSousCategorie VARCHAR(50),
    PRIMARY KEY(categorieId, souscategorieId),
    UNIQUE(codesouscategorie),
    FOREIGN KEY(categorieId) REFERENCES CATEGORIE(categorieId)
    );

    CREATE TABLE PFC_SC(
    categorieId INT,
    puissanceId INT,
    categorieId_1 INT NOT NULL,
    souscategorieId INT NOT NULL,
    PRIMARY KEY(categorieId, puissanceId),
    FOREIGN KEY(categorieId, puissanceId) REFERENCES PFC(categorieId, puissanceId),
    FOREIGN KEY(categorieId_1, souscategorieId) REFERENCES SOUS_CATEGORIE(categorieId, souscategorieId)
    );

    CREATE TABLE CAISSIERE(
    agenceId INT,
    caissiereId COUNTER,
    codecaissiere VARCHAR(4) NOT NULL,
    prenomcaissiere VARCHAR(40),
    nomcaissiere VARCHAR(40),
    PRIMARY KEY(agenceId, caissiereId),
    UNIQUE(codecaissiere),
    FOREIGN KEY(agenceId) REFERENCES AGENCE(agenceId)
    );

    CREATE TABLE VEHICULE(
    vehiculeId COUNTER,
    codevehicule COUNTER NOT NULL,
    marque VARCHAR(50),
    type VARCHAR(50),
    energie VARCHAR(15),
    serie VARCHAR(40),
    vpuissance INT,
    nombreDePlaceCarteGrise INT,
    nombreDePlaceCabine BIGINT,
    categorieId INT NOT NULL,
    puissanceId INT NOT NULL,
    PRIMARY KEY(vehiculeId),
    UNIQUE(codevehicule),
    FOREIGN KEY(categorieId, puissanceId) REFERENCES PFC(categorieId, puissanceId)
    );

    CREATE TABLE PRODUCTEUR(
    agenceId INT,
    producteurId COUNTER,
    codeproducteur VARCHAR(5) NOT NULL,
    Nomproducteur VARCHAR(50),
    Prenomprodcteur VARCHAR(50),
    PRIMARY KEY(agenceId, producteurId),
    UNIQUE(codeproducteur),
    FOREIGN KEY(agenceId) REFERENCES AGENCE(agenceId)
    );

    CREATE TABLE CONTRAT(
    contratId CHAR(10),
    codecontrat VARCHAR(10) NOT NULL,
    dateEffetContrat DATE,
    dateExpirationContrat DATE,
    agenceId INT NOT NULL,
    agenceId_1 INT NOT NULL,
    producteurId INT NOT NULL,
    vehiculeId INT NOT NULL,
    clientId INT NOT NULL,
    PRIMARY KEY(contratId),
    UNIQUE(codecontrat),
    FOREIGN KEY(agenceId) REFERENCES AGENCE(agenceId),
    FOREIGN KEY(agenceId_1, producteurId) REFERENCES PRODUCTEUR(agenceId, producteurId),
    FOREIGN KEY(vehiculeId) REFERENCES VEHICULE(vehiculeId),
    FOREIGN KEY(clientId) REFERENCES CLIENT(clientId)
    );

    CREATE TABLE AVENANT(
    avenantId COUNTER,
    codeavenant VARCHAR(10) NOT NULL,
    libelleAvenant VARCHAR(50),
    dateEffetAvenant DATE,
    dateExpirationAvenant DATE,
    contratId CHAR(10) NOT NULL,
    PRIMARY KEY(avenantId),
    UNIQUE(codeavenant),
    FOREIGN KEY(contratId) REFERENCES CONTRAT(contratId)
    );

    CREATE TABLE ENCAISSER(
    agenceId INT,
    caissiereId INT,
    avenantId INT,
    contratId CHAR(10),
    encaisserId COUNTER,
    codeencaissement VARCHAR(10) NOT NULL,
    dateencaissement DATE,
    montantencaisser BIGINT,
    PRIMARY KEY(agenceId, caissiereId, avenantId, contratId, encaisserId),
    UNIQUE(codeencaissement),
    FOREIGN KEY(agenceId, caissiereId) REFERENCES CAISSIERE(agenceId, caissiereId),
    FOREIGN KEY(avenantId) REFERENCES AVENANT(avenantId),
    FOREIGN KEY(contratId) REFERENCES CONTRAT(contratId)
    );

    CREATE TABLE APPORTER(
    contratId CHAR(10),
    avenantId INT,
    apporteurId CHAR(8),
    dateapporteur DATE,
    PRIMARY KEY(contratId, avenantId, apporteurId),
    FOREIGN KEY(contratId) REFERENCES CONTRAT(contratId),
    FOREIGN KEY(avenantId) REFERENCES AVENANT(avenantId),
    FOREIGN KEY(apporteurId) REFERENCES APPORTEUR(apporteurId)
    );

    CREATE TABLE APPARTENIR(
    contratId CHAR(10),
    typeContratId INT,
    PRIMARY KEY(contratId, typeContratId),
    FOREIGN KEY(contratId) REFERENCES CONTRAT(contratId),
    FOREIGN KEY(typeContratId) REFERENCES TYPECONTRAT(typeContratId)
    );

    CREATE TABLE PROTEGER(
    categorieId INT,
    garantieId CHAR(3),
    PRIMARY KEY(categorieId, garantieId),
    FOREIGN KEY(categorieId) REFERENCES CATEGORIE(categorieId),
    FOREIGN KEY(garantieId) REFERENCES GARANTIE(garantieId)
    );

    CREATE TABLE ASSOCIER(
    contratId CHAR(10),
    garantieId CHAR(3),
    PRIMARY KEY(contratId, garantieId),
    FOREIGN KEY(contratId) REFERENCES CONTRAT(contratId),
    FOREIGN KEY(garantieId) REFERENCES GARANTIE(garantieId)
    );
    Ensuite mon schéma MCD et ses relations sont ils corrects?
    Merci par avance.

  18. #38
    Expert éminent sénior
    Bonsoir Zidane7,

    J’ai pas mal d’observations à faire, mais déjà :

    Votre MCD comporte la nouvelle entité-type CAISSIERE ainsi que l’association ternaire ENCAISSER.

    Cette association correspond au prédicat suivant :

    Un encaissement effectué par la caissière caissiereId concerne le contrat contratId et l’avenant avenantId.


    1re remarque : selon cette association, il ne peut y avoir encaissement que s’il y a avenant. Comment faites-vous pour les contrats sans avenant ?

    2e remarque : rien n’empêche que l’avenant soit celui de n’importe que contrat autre que celui qui est légitimement concerné...

    3e remarque (technique) : dans ENCAISSER, il existe une dépendance fonctionnelle avenantId → contratId :
    au niveau relationnel, le triplet {caissiereId, avenantId, contratId} est une surclé et doit être réduit à la paire {caissiereId, avenantId} pour être clé (c’est-à-dire clé candidate dans le langage relationnel, lequel impose la règle d’irréductibilité des clés, en plus de la règle d’unicité).

    Moralité : si un encaissement concerne soit un contrat soit un avenant, alors il doit y avoir deux associations distinctes, la 1re concernant seulement les contrats et la 2e concernant seulement les avenants (si un encaissement ne concerne que les avenants, dans le diagramme ci-dessous on supprime l’association ENCAISSE_C).



    A noter que l’identification relative ne concerne que les entités-types faibles (propriétés multivaluées telles que, par exemple, les sous-catégories qui ne sont que des propriétés multivaluées des catégories, et en dépendent donc « à la vie, à la mort »).
    Une caissière dépend-elle à la vie à la mort de son agence ? Doit-elle disparaître si l’agence pour laquelle elle travaille actuellement disparaît ? Cette caissière ne peut-elle jamais changer d’agence ? Bref, identifier CAISSIERE relativement à AGENCE n’est pas bien pertinent.

    PS. Un avenant peut-il ne pas dépendre à la vie à la mort d’un contrat ? Autrement dit, un avenant donné peut-il concerner un contrat C1 puis un contrat C2 ?

    Vous me direz si vous partagez mon point de vue ou pas.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

###raw>template_hook.ano_emploi###