Discussion :

[Zidane7]

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.

[Zidane7]

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:

[escartefigue]

Voici

Pièce jointe 579035

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

[fsmrel]

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

[fsmrel]

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.

[escartefigue]

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

[Zidane7]

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.

[fsmrel]

Bonsoir Zidane7,

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 ?

[Zidane7]

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.

[fsmrel]

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.

[Zidane7]

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.

[fsmrel]

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.

[Zidane7]

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.

[fsmrel]

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....

[fsmrel]

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.

[fsmrel]

Je reviens sur ce que j’ai écrit dans le post #24 :

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é :

[Zidane7]

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.

[fsmrel]

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.

[Zidane7]

Bonsoir Monsieur fsmrel?
Merci infiniment pour votre contribution.

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

Je suis entièrement d’accord sur votre remarque et j'ai changé conformément à cela.

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.

Effectivement une caissière peut allez dans une autre agence et inversement.

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.

Un avenant concerne un et un seul contrat car les numéro d'avenant différent même s'ils portent le même nom.
Exemple deux(2) voitures TOYOTA HILUX portent le même nom et même marque mais les numéros de série ne sont pas les mêmes. Les avenants sont pareils.
Voici le code sql généré

CREATE TABLE CATEGORIE(
categorieId COUNTER,
codecategorie VARCHAR(4) NOT NULL,
libelleCategorie VARCHAR(50) NOT NULL,
nombreplacecategorie INT,
PRIMARY KEY(categorieId),
UNIQUE(codecategorie)
);

CREATE TABLE CLIENT(
clientId COUNTER,
codeclient VARCHAR(10) NOT NULL,
nomClient VARCHAR(50) NOT NULL,
prenomClient VARCHAR(50) NOT NULL,
adresseClient VARCHAR(50) NOT NULL,
telephoneClient VARCHAR(30) NOT NULL,
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) NOT NULL,
PRIMARY KEY(typeContratId),
UNIQUE(codetypecontrat)
);

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

CREATE TABLE Sous_Garantie(
sousGarantieId CHAR(5),
codesousgarantie VARCHAR(2) NOT NULL,
libelleSousGarantieId VARCHAR(50) NOT NULL,
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 NOT NULL,
puissanceMax BIGINT NOT NULL,
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) NOT NULL,
dateCreation DATE NOT NULL,
PRIMARY KEY(agenceId),
UNIQUE(codeagence)
);

CREATE TABLE SOUS_CATEGORIE(
categorieId INT,
souscategorieId INT,
codesouscategorie VARCHAR(4) NOT NULL,
libelleSousCategorie VARCHAR(50) NOT NULL,
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) NOT NULL,
nomcaissiere VARCHAR(40) NOT NULL,
PRIMARY KEY(agenceId, caissiereId),
UNIQUE(codecaissiere),
FOREIGN KEY(agenceId) REFERENCES AGENCE(agenceId)
);

CREATE TABLE VEHICULE(
vehiculeId COUNTER,
codevehicule COUNTER NOT NULL,
marque VARCHAR(50) NOT NULL,
type VARCHAR(50) NOT NULL,
energie VARCHAR(15) NOT NULL,
serie VARCHAR(40) NOT NULL,
vpuissance INT NOT NULL,
nombreDePlaceCarteGrise INT NOT NULL,
nombreDePlaceCabine BIGINT NOT NULL,
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) NOT NULL,
Prenomprodcteur VARCHAR(50) NOT NULL,
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) NOT NULL,
dateEffetAvenant DATE,
dateExpirationAvenant DATE,
contratId CHAR(10) NOT NULL,
PRIMARY KEY(avenantId),
UNIQUE(codeavenant),
FOREIGN KEY(contratId) REFERENCES CONTRAT(contratId)
);

CREATE TABLE ENCAISSE_A(
agenceId INT,
caissiereId INT,
avenantId INT,
encaisse_aId COUNTER,
codeencaisse_a VARCHAR(15) NOT NULL,
montantencaisse_a BIGINT,
dateencaisse_a DATE,
PRIMARY KEY(agenceId, caissiereId, avenantId, encaisse_aId),
UNIQUE(codeencaisse_a),
FOREIGN KEY(agenceId, caissiereId) REFERENCES CAISSIERE(agenceId, caissiereId),
FOREIGN KEY(avenantId) REFERENCES AVENANT(avenantId)
);

CREATE TABLE ENCAISSE_C(
agenceId INT,
caissiereId INT,
contratId CHAR(10),
encaisse_cId COUNTER,
codeencaisse_c VARCHAR(15) NOT NULL,
montantencaisse_c BIGINT,
dateencaisse_c DATE,
PRIMARY KEY(agenceId, caissiereId, contratId, encaisse_cId),
UNIQUE(codeencaisse_c),
FOREIGN KEY(agenceId, caissiereId) REFERENCES CAISSIERE(agenceId, caissiereId),
FOREIGN KEY(contratId) REFERENCES CONTRAT(contratId)
);

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

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

CREATE TABLE APPORTE_A(
avenantId INT,
apporteurId CHAR(8),
PRIMARY KEY(avenantId, apporteurId),
FOREIGN KEY(avenantId) REFERENCES AVENANT(avenantId),
FOREIGN KEY(apporteurId) REFERENCES APPORTEUR(apporteurId)
);

Le MCD qui accompagne est le suivant:
J'ai fait la capture de la partie Contrat, Avenant, Caissiere et Caisse.
Merci par avance.

[fsmrel]

Bonsoir Zidane7,

Concernant les encaissements, ça va mieux. Toutefois, dans la mesure où rien ne fait référence à ENCAISSE_C, vous pouvez conserver l’association ENCAISSE_C comme je l’ai fait, plutôt qu’en faire une entité-type, en tout cas fonctionnellement et sémantiquement ça reste une association.

A cette occasion, je reviens sur l’entité-type PFC : fonctionnellement et sémantiquement PFC est une association. Si j’en ai fait une entité-type, c’est parce que l’entité-type VEHICULE est à associer à PFC, mais Merise interdit qu’une association X soit liée à une association Y. C’est une contrainte injustifiée, et on administre donc un remède technique : pour pouvoir associer VEHICULE et PFC, la solution fut de transformer PFC en entité-type. Notez que je n’ai pas défini d’attribut identifiant pfcId ni d’attribut codePFC. L’identifiant de PFC est en réalité la paire {puissanceId, catId}, héritée des entités-types PUISSANCE et CATEGORIE. En l’absence d’identifiant déclaré pfcId, l’identifiant alternatif codePFC n’a pas de raison d’être.

Pour en revenir à ENCAISSE_C, si vous tenez vraiment à en faire une entité-type, soit, mais faites comme j’ai fait pour PFC, supprimez les attributs encaisse_cid et codeencaisse_c qui n’apportent rien et au contraire alourdissent inutilement le modèle.

Passons à SQL.

Pour simplifier, je n’utilise ci-dessous que les tables concernant les encaissements des contrats (j’ai donc débarrassé la table CONTRAT des références à CLIENT et VEHICULE).

J’ai utilisé SQL Server, donc son mode d’auto-incrémentation, à savoir IDENTITY.

Les tables :

CREATE TABLE AGENCE
(
agenceId      INT  IDENTITY,
codeAgence    VARCHAR(3)   NOT NULL,
nomAgence     VARCHAR(50)  NOT NULL,
dateCreation  DATE         NOT NULL,
CONSTRAINT AGENCE_PK PRIMARY KEY(agenceId),
CONSTRAINT AGENCE_UK UNIQUE(codeagence)
);

CREATE TABLE CAISSIERE
(
caissiereId       INT IDENTITY,
codeCaissiere     VARCHAR(6)    NOT NULL,
prenomCaissiere   VARCHAR(40)   NOT NULL,
nomCaissiere      VARCHAR(40)   NOT NULL,
agenceId          INT           NOT NULL,
CONSTRAINT CAISSIERE_PK PRIMARY KEY  (caissiereId),
CONSTRAINT CAISSIERE_UK UNIQUE(codeCaissiere),
CONSTRAINT CAISSIERE_AGENCE_FK FOREIGN KEY(agenceId) 
    REFERENCES AGENCE(agenceId)
);

CREATE TABLE CONTRAT
(
contratId                INT IDENTITY,
codeContrat              VARCHAR(10)   NOT NULL,
dateEffetContrat         DATE          NOT NULL,
dateExpirationContrat    DATE          NOT NULL,
agenceId                 INT           NOT NULL,
CONSTRAINT CONTRAT_PK PRIMARY KEY(contratId),
CONSTRAINT CONTRAT_UK UNIQUE(codeContrat),
CONSTRAINT CONTRAT_AGENCE_FK FOREIGN KEY(agenceId) 
    REFERENCES AGENCE(agenceId)
);

CREATE TABLE ENCAISSE_C
(
contratId           INT,
caissiereId         INT,
dateEncaisse        DATE          NOT NULL,
montantEncaisse     INT           NOT NULL,
PRIMARY KEY(contratId, caissiereId),
FOREIGN KEY(caissiereId) REFERENCES CAISSIERE(caissiereId),
FOREIGN KEY(contratId) REFERENCES CONTRAT(contratId)
);

Un début de jeu d’essai :

INSERT INTO AGENCE (codeAgence, nomAgence, dateCreation)
VALUES
    ('ag1', 'Agence 1', '1990-01-02')
  , ('ag2', 'Agence 2', '1990-01-02')
  , ('ag3', 'Agence 3', '1998-01-02')
;
INSERT INTO CONTRAT (codeContrat, dateEffetContrat, dateExpirationContrat, agenceId)
VALUES
    ('ctr01', '2018-01-01', '2022-12-31', (SELECT agenceId FROM AGENCE WHERE codeAgence = 'ag2'))
  , ('ctr02', '2018-01-01', '2022-12-31', (SELECT agenceId FROM AGENCE WHERE codeAgence = 'ag3'))
  , ('ctr03', '2018-01-01', '2022-12-31', (SELECT agenceId FROM AGENCE WHERE codeAgence = 'ag3'))
;
INSERT INTO CAISSIERE (codeCaissiere, prenomCaissiere, nomCaissiere, agenceId)
VALUES
    ('cai01', 'Julie', 'Dupont', (SELECT agenceId FROM AGENCE WHERE codeAgence = 'ag1'))
  , ('cai02', 'Rose', 'Bonbon', (SELECT agenceId FROM AGENCE WHERE codeAgence = 'ag1'))
  , ('cai03', 'Maud', 'Durand', (SELECT agenceId FROM AGENCE WHERE codeAgence = 'ag2'))
;
INSERT INTO ENCAISSE_C (contratId, caissiereId, dateEncaisse, montantEncaisse)
VALUES
    ((SELECT contratId FROM CONTRAT WHERE codeContrat = 'ctr01')
     , (SELECT caissiereId FROM CAISSIERE WHERE codeCaissiere = 'cai03')
     , '2018-01-01', 3000)
;
INSERT INTO ENCAISSE_C (contratId, caissiereId, dateEncaisse, montantEncaisse)
VALUES
    ((SELECT contratId FROM CONTRAT WHERE codeContrat = 'ctr02')
     , (SELECT caissiereId FROM CAISSIERE WHERE codeCaissiere = 'cai01')
     , '2018-01-01', 1000)
;

Pour connaître les contrats :

SELECT codeContrat, dateEffetContrat, dateExpirationContrat, codeAgence
FROM   CONTRAT as x JOIN AGENCE as y ON x.agenceId = y.agenceId ;

=>

codeContrat   dateEffetContrat   dateExpirationContrat   codeAgence
ctr01         2018-01-01         2022-12-31              ag2
ctr02         2018-01-01         2022-12-31              ag3
ctr03         2018-01-01         2022-12-31              ag3

Pour connaître les caissières :

SELECT codeCaissiere, prenomCaissiere, nomCaissiere, codeAgence 
FROM   CAISSIERE as x JOIN AGENCE as y ON x.agenceId = y.agenceId ;

=>

codeCaissiere   prenomCaissiere   nomCaissiere   codeAgence
cai01           Julie             Dupont         ag1
cai02           Rose              Bonbon         ag1
cai03           Maud              Durand         ag2

Pour connaître les encaissements :

SELECT codeContrat, codeCaissiere, dateEncaisse, montantEncaisse 
FROM   ENCAISSE_C as x 
  JOIN CONTRAT as y ON x.contratId = y.contratId
  JOIN CAISSIERE as z ON x.caissiereId = z.caissiereId ; 

=>

codeContrat   codeCaissiere   dateEncaisse   montantEncaisse
ctr01         cai03           2018-01-01     3000
ctr02         cai01           2018-01-01     1000 

Ce qui vaut pour ENCAISSE_C s’applique évidemment à ENCAISSE_A.