Discussion :

[Paprick]

Bonsoir,

A present je coonstate qu'il y a une erreur au niveau dans le CODE SQL de mon MCD mais je ne vois pas d'où vient l'erreur.
Code sql: Erreur dans le MLD : impossible de générer le script SQL

Demandez l'affichage du MLD textuel (case à cocher en haut à droite) : cela vous indiquera la nature de l'erreur.
Mais, a priori, l'identifiant de CEDEAOHISTO me parait incomplet : il ne possède que l'identifiant relatif de CEDEAO, ce qui ne lui garantit pas l'unicité...

[fsmrel]

Bonsoir,

A present je constate qu'il y a une erreur au niveau dans le CODE SQL de mon MCD mais je ne vois pas d'où vient l'erreur.

Dans l’entité-type CEDEAOHISTO vous avez omis de rendre identifiant (relatif) l’attribut cedaoHistoDebut. Revoyez mon observation dans le post #98 : dans le MCD proposé, cet attribut y est effectivement identifiant (relatif) pour cette entité-type. Votre oubli n’a pas échappé à l’oeil d’aigle de Paprick.

Par contre, par référence au post #96, l'attribut TarifId doit disparaître de l'entité-type TARIF.

[fsmrel]

une caissière peut ne pas être aussi un producteur.

J’avoue ne pas bien comprendre cette phrase qui sous-entendrait qu’a priori les caissières sont des producteurs, mais que certaines d’entre elles ne le seraient pas (d’où contrainte d’exclusion à modéliser). Qu’en est-il exactement ?

[Paprick]

Bonsoir François,

Dans l’entité-type CEDEAOHISTO vous avez omis de rendre identifiant (relatif) l’attribut cedaoHistoDebut.

Il me semble que cedaoHistoDebut étant une rubrique de CEDEAOHISTO, il fait partie de l'identifiant composé mais n'est pas relatif, non ?

[fsmrel]

Je repose ma question (voir post #96) :

Combien y a-t-il de types de contrats ? Les deux que vous avez mentionnés (mono, flotte) ? D’autres ?

[fsmrel]

Bonsoir Patrick,

Il me semble que cedaoHistoDebut étant une rubrique de CEDEAOHISTO, il fait partie de l'identifiant composé mais n'est pas relatif, non ?

Etant donné que CEDEAOHISTO est identifiée relativement à CEDEAO, il faut bien qu’une rubrique et une seule de CEDEAOHISTO participe à l’identification de celle-ci. En l’occurrence le choix porte sur la rubrique cedaoHistoDebut. Je suis en phase avec D. Nanci et B. Espinasse, non ? (cf. Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001)page 130, identifiant relatif).

[Paprick]

Etant donné que CEDEAOHISTO est identifiée relativement à CEDEAO, il faut bien qu’une rubrique et une seule de CEDEAOHISTO participe à l’identification de celle-ci. En l’occurrence le choix porte sur la rubrique cedaoHistoDebut. Je suis en phase avec D. Nanci et B. Espinasse, non ?

En fait, c'est juste un point de détail dans la façon de présenter les choses : le 1er composant de l'identifiant venant de CEDEAO est bien relatif à CEDEAO, ce qui n'est pas le cas du 2ème composant représenté par la rubrique cedaoHistoDebut qui appartient directement à CEDEAOHISTO.
Mais c'est vraiment du détail car, en effet, on peut dire que CEDEAOHISTO est identifiée relativement à CEDEAO.

[fsmrel]

En fait, c'est juste un point de détail dans la façon de présenter les choses : le 1er composant de l'identifiant venant de CEDEAO est bien relatif à CEDEAO, ce qui n'est pas le cas du 2ème composant représenté par la rubrique cedaoHistoDebut qui appartient directement à CEDEAOHISTO.

Tu n'es donc pas en accord avec Nanci (cf. le cas du numéro de ligne de commande dans son exemple)...

[Paprick]

Tu n'es donc pas en accord avec Nanci (cf. le cas du numéro de ligne de commande dans son exemple)...

En relisant cette partie de l'ouvrage de Nanci, j'avoue que sa définition de l'identification relative me gêne aux entournures...
Tu sais comme moi que, dans bien des cas, une classe d'entités peut n'avoir aucune rubrique locale faisant partie de l'identifiant : c'est en particulier le cas quand on décompose une association pour lui associer ensuite une autre classe d'entités (d'ailleurs, Nanci aborde cette situation à la fin de sa partie sur les identifiants relatifs).
Et c'est vrai que je suis très gêné quand je lis : "Dans certains cas d'identification relative multiple, la présence d'un identifiant relatif n'est pas obligatoire." Une identification relative sans identifiant relatif... avoue que ce n'est pas très clair comme situation .
Pour moi, un identifiant relatif signifie que cet identifiant (ou composant de l'identifiant) est relatif à la classe d'entité associée (cf. page 187 de mon modeste ouvrage) : dans l'exemple des lignes de commande, l'identifiant relatif est "n° commande" qui, concaténé avec le "n° ligne" local de "LIGNE COMMANDE" en constitue l'identifiant.
Je n'avais effectivement pas remarqué ce point de divergence avec Nanci, mais je trouve que le cas des identifications relatives multiples rend son interprétation problématique.
Pour moi, le fait de récupérer ce qui deviendra une clé étrangère comme partie de l'identifiant d'une classe d'entités, n'est pas lié à l'éventuelle autre composante de l'identifiant de la classe en question, mais à la classe elle-même.

[Zidane7]

Bonsoir Messieurs,
Paprick

Demandez l'affichage du MLD textuel (case à cocher en haut à droite) : cela vous indiquera la nature de l'erreur.
Mais, a priori, l'identifiant de CEDEAOHISTO me parait incomplet : il ne possède que l'identifiant relatif de CEDEAO, ce qui ne lui garantit pas l'unicité...

Il me semble que cedaoHistoDebut étant une rubrique de CEDEAOHISTO, il fait partie de l'identifiant composé mais n'est pas relatif, non ?

A ce niveau, je viens de mettre la clé de la cedeao comme suivant: cedeaohistoId et cela marche. Merci pour votre intervention.
fsmrel

J’avoue ne pas bien comprendre cette phrase qui sous-entendrait qu’a priori les caissières sont des producteurs, mais que certaines d’entre elles ne le seraient pas (d’où contrainte d’exclusion à modéliser). Qu’en est-il exactement ?

Dans certaines agences, un producteur peut produire et encaisser en même temps c'est pour cela que je disais qu'un producteur peut être à la fois producteur et caissière simultanément et dans d'autres agences un producteur peut être différent d'une caissière. Aussi une caissière ou producteur peut être muté(e) d'une agence à une autre. Avez-vous des remarques sur ce point de vue?

Je repose ma question (voir post #96) :
Combien y a-t-il de types de contrats ? Les deux que vous avez mentionnés (mono, flotte) ? D’autres ?

Il ya deux(2) types de contrats à savoir: MONO et FLOTTE.
Aussi il existe plusieurs types de branches à savoir: AUTOMOBILE, TRANSPORT TERRESTRE, MARITIME, AERIEN ect...
Que pensez-vous?
Voici le code sql et MCD ci-dessous:
Quelles sont vos remarques et suggestions?
Merci d'avance.

CREATE TABLE CATEGORIE(
categorieId INT IDENTITY,
codecategorie CHAR(3) NOT NULL,
categorie VARCHAR(50) NOT NULL,
PRIMARY KEY(categorieId),
UNIQUE(codecategorie)
);

CREATE TABLE CLIENT(
clientId INT IDENTITY,
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 INT IDENTITY,
codeapporteur VARCHAR(5) NOT NULL,
nomApporteur VARCHAR(50) NOT NULL,
prenomApporteur VARCHAR(50) NOT NULL,
PRIMARY KEY(apporteurId),
UNIQUE(codeapporteur)
);

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

CREATE TABLE GARANTIE(
garantieId INT IDENTITY,
codegarantie CHAR(1) NOT NULL,
Libelle_Garantie VARCHAR(50) NOT NULL,
PRIMARY KEY(garantieId),
UNIQUE(codegarantie)
);

CREATE TABLE PUISSANCE(
puissanceId INT IDENTITY,
codepuissance VARCHAR(3) NOT NULL,
borneInf INT NOT NULL,
borneSup INT NOT NULL,
unite INT NOT NULL,
PRIMARY KEY(puissanceId),
UNIQUE(codepuissance)
);

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

CREATE TABLE AVENANT_LIBELLE(
avenantlibelleId INT IDENTITY,
avenantlibellecode CHAR(3) NOT NULL,
avenantlibellevaleur VARCHAR(50),
PRIMARY KEY(avenantlibelleId),
UNIQUE(avenantlibellecode)
);

CREATE TABLE MODEPAIEMENT(
modepaiemenId INT IDENTITY,
modepaiementcode VARCHAR(15) NOT NULL,
modepaiement_libelle VARCHAR(50),
PRIMARY KEY(modepaiemenId),
UNIQUE(modepaiementcode)
);

CREATE TABLE CEDEAO(
cedeaoId INT,
codecedeao INT NOT NULL,
cedeaodepuis DATE,
cedeaovehicule INT NOT NULL,
PRIMARY KEY(cedeaoId),
UNIQUE(codecedeao),
UNIQUE(cedeaovehicule)
);

CREATE TABLE CEDEAOHISTO(
cedeaoId INT,
cedeaohistoId INT IDENTITY,
cedeaohistodebut DATE NOT NULL,
cedeaohistofin DATE NOT NULL,
cedeaohistomontant INT NOT NULL,
PRIMARY KEY(cedeaoId, cedeaohistoId),
FOREIGN KEY(cedeaoId) REFERENCES CEDEAO(cedeaoId)
);

CREATE TABLE TAUX_DEFENSE_RECOURS(
tauxDrId INT IDENTITY,
tauxDrdebut DATE NOT NULL,
tauxDrfin DATE NOT NULL,
tauxvaleure DECIMAL(2,2) NOT NULL,
PRIMARY KEY(tauxDrId)
);

CREATE TABLE MARQUE(
marqueId INT IDENTITY,
libellemarque VARCHAR(50),
PRIMARY KEY(marqueId)
);

CREATE TABLE TAUXFGA(
tauxfgaId INT IDENTITY,
tauxfgadebut DATE,
tauxfgafin DATE,
tauxfgavaleur DECIMAL(2,2),
PRIMARY KEY(tauxfgaId)
);

CREATE TABLE TAUXTAXE(
tauxtaxeId INT IDENTITY,
tauxtaxedebut DATE,
tauxtaxefin DATE,
tauxtaxevaleur DECIMAL(2,2),
PRIMARY KEY(tauxtaxeId)
);

CREATE TABLE TAUXPROTDRIVER(
tauxprotdriverId INT IDENTITY,
tauxprotdriverdebut DATE,
tauxprotdriverfin DATE,
tauxprotdrivervaleur DECIMAL(2,2),
PRIMARY KEY(tauxprotdriverId)
);

CREATE TABLE ANPRORATA(
prorataId INT IDENTITY,
proratadatemini CHAR(3),
proratadatemaxi CHAR(3),
PRIMARY KEY(prorataId)
);

CREATE TABLE COUTPOLICE(
coupoliceId VARCHAR(2),
coutpolice INT NOT NULL,
libellecoupolice VARCHAR(50),
PRIMARY KEY(coupoliceId)
);

CREATE TABLE PRODUCTEUR(
agenceId INT,
producteurId INT IDENTITY,
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 CAISSIERE(
agenceId_1 INT,
caissiereId INT IDENTITY,
codecaissiere VARCHAR(4) NOT NULL,
prenomcaissiere VARCHAR(40) NOT NULL,
nomcaissiere VARCHAR(40) NOT NULL,
agenceId INT,
producteurId INT,
PRIMARY KEY(agenceId_1, caissiereId),
UNIQUE(codecaissiere),
FOREIGN KEY(agenceId_1) REFERENCES AGENCE(agenceId),
FOREIGN KEY(agenceId, producteurId) REFERENCES PRODUCTEUR(agenceId, producteurId)
);

CREATE TABLE CATCOMPLEMENT(
categorieId INT,
catcomplementId INT,
catcomplementcode CHAR(3) NOT NULL,
catcomplementlibelle VARCHAR(100) NOT NULL,
cedeaoId INT NOT NULL,
PRIMARY KEY(categorieId, catcomplementId),
FOREIGN KEY(categorieId) REFERENCES CATEGORIE(categorieId),
FOREIGN KEY(cedeaoId) REFERENCES CEDEAO(cedeaoId)
);

CREATE TABLE VEHICULE(
vehiculeId INT IDENTITY,
codevehicule CHAR(5) NOT NULL,
immatriculation VARCHAR(10) NOT NULL,
type VARCHAR(50) NOT NULL,
energie VARCHAR(15) NOT NULL,
serie VARCHAR(40) NOT NULL,
vehiculepuissance INT NOT NULL,
nombreDePlaceCarteGrise INT NOT NULL,
nombreDePlaceCabine BIGINT NOT NULL,
nombrePlacehorscabine INT,
marqueId INT NOT NULL,
puissanceId INT NOT NULL,
categorieId INT NOT NULL,
catcomplementId INT NOT NULL,
clientId INT NOT NULL,
PRIMARY KEY(vehiculeId),
UNIQUE(codevehicule),
FOREIGN KEY(marqueId) REFERENCES MARQUE(marqueId),
FOREIGN KEY(puissanceId) REFERENCES PUISSANCE(puissanceId),
FOREIGN KEY(categorieId, catcomplementId) REFERENCES CATCOMPLEMENT(categorieId, catcomplementId),
FOREIGN KEY(clientId) REFERENCES CLIENT(clientId)
);

CREATE TABLE CONTRAT(
contratId INT IDENTITY,
codecontrat VARCHAR(10) NOT NULL,
dateEffetContrat DATE NOT NULL,
dateExpirationContrat DATE NOT NULL,
reduction DECIMAL(2,2),
coupoliceId VARCHAR(2) NOT NULL,
clientId INT NOT NULL,
apporteurId INT,
agenceId INT NOT NULL,
producteurId INT NOT NULL,
typeContratId INT NOT NULL,
PRIMARY KEY(contratId),
UNIQUE(codecontrat),
FOREIGN KEY(coupoliceId) REFERENCES COUTPOLICE(coupoliceId),
FOREIGN KEY(clientId) REFERENCES CLIENT(clientId),
FOREIGN KEY(apporteurId) REFERENCES APPORTEUR(apporteurId),
FOREIGN KEY(agenceId, producteurId) REFERENCES PRODUCTEUR(agenceId, producteurId),
FOREIGN KEY(typeContratId) REFERENCES TYPECONTRAT(typeContratId)
);

CREATE TABLE AVENANT(
contratId INT,
avenantId INT IDENTITY,
codeavenant VARCHAR(10) NOT NULL,
libelleAvenant VARCHAR(50) NOT NULL,
dateemissionavenant DATE,
dateEffetAvenant DATE NOT NULL,
dateExpirationAvenant DATE NOT NULL,
bonus DECIMAL(2,2),
malus DECIMAL(2,2),
avenantlibelleId INT NOT NULL,
apporteurId INT,
PRIMARY KEY(contratId, avenantId),
UNIQUE(codeavenant),
FOREIGN KEY(contratId) REFERENCES CONTRAT(contratId),
FOREIGN KEY(avenantlibelleId) REFERENCES AVENANT_LIBELLE(avenantlibelleId),
FOREIGN KEY(apporteurId) REFERENCES APPORTEUR(apporteurId)
);

CREATE TABLE TARIF(
categorieId INT,
catcomplementId INT,
puissanceId INT,
tarifId INT,
datetarifdepuis DATE NOT NULL,
responsabilitecivile VARCHAR(50) NOT NULL,
PRIMARY KEY(categorieId, catcomplementId, puissanceId, tarifId),
FOREIGN KEY(categorieId, catcomplementId) REFERENCES CATCOMPLEMENT(categorieId, catcomplementId),
FOREIGN KEY(puissanceId) REFERENCES PUISSANCE(puissanceId)
);

CREATE TABLE TARIFHISTO(
categorieId INT,
catcomplementId INT,
puissanceId INT,
tarifId INT,
tarifhistoId INT,
tarifhistodurantdebut DATE NOT NULL,
tarifhistodurantfin DATE NOT NULL,
responsabilitecivilehisto INT NOT NULL,
PRIMARY KEY(categorieId, catcomplementId, puissanceId, tarifId, tarifhistoId),
FOREIGN KEY(categorieId, catcomplementId, puissanceId, tarifId) REFERENCES TARIF(categorieId, catcomplementId, puissanceId, tarifId)
);

CREATE TABLE ENCAISSEMENT_C(
contratId INT,
agenceId INT,
caissiereId INT,
encaisseCtrId INT IDENTITY,
encaisseCtrMontant INT,
encaisseCtrDate DATE,
modepaiemenId INT NOT NULL,
PRIMARY KEY(contratId, agenceId, caissiereId, encaisseCtrId),
FOREIGN KEY(contratId) REFERENCES CONTRAT(contratId),
FOREIGN KEY(agenceId, caissiereId) REFERENCES CAISSIERE(agenceId_1, caissiereId),
FOREIGN KEY(modepaiemenId) REFERENCES MODEPAIEMENT(modepaiemenId)
);

CREATE TABLE VEHIC_GARANT(
vehiculeId INT,
garantieId INT,
PRIMARY KEY(vehiculeId, garantieId),
FOREIGN KEY(vehiculeId) REFERENCES VEHICULE(vehiculeId),
FOREIGN KEY(garantieId) REFERENCES GARANTIE(garantieId)
);

[fsmrel]

Bonsoir,

Zidane7, pardonnez cette incidente sur l'identification relative, mais on s'occupe de vous.

Une identification relative sans identifiant relatif... avoue que ce n'est pas très clair comme situation .

Tu as raison !

Pour sa part, le groupe 135 de l’Afcet propose une définition de l’identifiant relatif qui est très brève et générale :

« Identifiant comprenant au moins une relation »

Cette définition est en désaccord avec celle de Nanci et elle conforme à ce que tu en dis : Avantage donc au binôme Afcet, Paprick.


A propos de la page 187 de ton ouvrage. Tu écris :

« Considérant que cette composante de l’identifiant est relative à la clase d’entités associée, on parle alors d’identifiant relatif. »

Je ne sais pas comment interpréter de façon précise le terme « composante » car en préalable de cette phrase tu traites de concepts du niveau relationnel : clés primaires et étrangères, concepts mixés avec ceux du niveau E/R, en l’occurrence celui d’identifiant, d’où perplexité de ma part.

A l’avenir, en attendant de ta part une définition de l’identifiant relatif basée exclusivement sur des concepts E/R, plutôt qu’écrire :

« Dans l’entité-type CEDEAOHISTO vous avez omis de rendre identifiant (relatif) l’attribut cedaoHistoDebut. Revoyez mon observation dans le post #98 : dans le MCD proposé, cet attribut y est effectivement identifiant (relatif) pour cette entité-type. »

J’essaierai de rester dans les clous au moins Afcet, mais sans utiliser l’adjectif « relatif » :

« Dans l’entité-type CEDEAOHISTO vous avez omis de faire participer l’attribut cedaoHistoDebut à l’identifiant de cette entité-type. Revoyez mon observation dans le post #98 : dans le MCD proposé, l’attribut cedaoHistoDebut participe effectivement à l’identifiant de CEDEAOHISTO. »

[fsmrel]

Bonsoir Zidane7,

Votre dernier MCD ne fait pas apparaître l’entité-type TARIF, mais l’instruction CREATE TABLE reprise ci-dessous montre que cette entité-type a conservé l’attribut tarifId, lequel doit être supprimé, comme je l’ai déjà signalé dans le post #96. En effet, jusqu’à ce jour, la règle est que pour une catégorie, un complément de catégorie et une puissance donnés, on n’a qu’un seul tarif, or la clé primaire (délinquante) de la table TARIF dit le contraire.

CREATE TABLE TARIF(
categorieId INT,
catcomplementId INT,
puissanceId INT,
tarifId INT,
datetarifdepuis DATE NOT NULL,
responsabilitecivile VARCHAR(50) NOT NULL,
PRIMARY KEY(categorieId, catcomplementId, puissanceId, tarifId),  
FOREIGN KEY(categorieId, catcomplementId) 
    REFERENCES CATCOMPLEMENT(categorieId, catcomplementId),
FOREIGN KEY(puissanceId) REFERENCES PUISSANCE(puissanceId)
); 

En passant, la responsabilité civile étant une donnée numérique, le type VARCHAR(50) est inapproprié pour l’attribut correspondant.


Je vais regarder la suite de vos questions/réponses.

[Paprick]

Bonsoir François,

Pour sa part, le groupe 135 de l’Afcet propose une définition de l’identifiant relatif qui est très brève et générale :

« Identifiant comprenant au moins une relation »

Cette définition est en désaccord avec celle de Nanci et elle conforme à ce que tu en dis : Avantage donc au binôme Afcet, Paprick.

A propos de la page 187 de ton ouvrage. Tu écris :

« Considérant que cette composante de l’identifiant est relative à la classe d’entités associée, on parle alors d’identifiant relatif. »

Je ne sais pas comment interpréter de façon précise le terme « composante » car en préalable de cette phrase tu traites de concepts du niveau relationnel : clés primaires et étrangères, concepts mixés avec ceux du niveau E/R, en l’occurrence celui d’identifiant, d’où perplexité de ma part.

Tu as raison, mais j'ai pensé qu'il était nécessaire de visualiser le résultat pour comprendre le concept : parler d'identifiant relatif sans imaginer la clé étrangère qui va avec est assez difficile à appréhender quand on ne maîtrise pas à fond la modélisation conceptuelle. Mais, je vais réfléchir à une définition qui pourrait se passer des aspects techniques et rester au niveau conceptuel tout en demeurant pédagogique.

[fsmrel]

Bonsoir Zidane7

A propos des producteurs et des caissières


En dépit de son nom, votre association "PEUT ÊTRE" entre PRODUCTEUR et CAISSIERE traduit en réalité une relation entre deux agents a priori distincts, le 1er pouvant par exemple être nommé Mado, appartenant à l’agence A1 et le second étant nommé Raoul, de l’agence A2.

Pour s’en sortir, il va falloir cette fois-ci, en passer par la généralisation/spécialisation des entités-types (héritage)⁽¹⁾.

On va donc mettre en oeuvre une entité-type AGENT, permettant de traiter de tous les types d’agents, des directeurs aux employés. En particulier on spécialise cette entité-type pour les agents qui nous intéressent, à savoir ceux qui produisent et/ou ceux qui encaissent. Par exemple, Raoul est producteur, Patricia est caissière, tandis que Mado est à la fois producteur et caissière.
Dans le MCD ci-dessous, PRODUCTEUR et CAISSIERE sont des spécialisations de l’entité-type AGENT. Un agent, qu’il soit producteur ou caissière n’appartient qu’à une agence (il peut bien sûr en changer). Le nom et le prénom d’un agent n’apparaît qu’une fois, et c’est dans l’entité-type AGENT. Les attributs codeCaissiere et codeProducteur n’ont plus d’emploi et c’est l’attribut agentCode qui prend leur relais. PRODUCTEUR et CAISSIERE n’ont pas d’identifiant en propre, ils héritent d’office de celui de AGENT.

La partie qui nous intéresse du MCD :

Un jeu d’essai :

Les agences

CREATE TABLE AGENCE
(
   agenceId INT IDENTITY,
   agenceCode CHAR(8) NOT NULL,
   agenceNom VARCHAR(50) NOT NULL,
   CONSTRAINT AGENCE_PK PRIMARY KEY(agenceId),
   CONSTRAINT AGENCE_AK UNIQUE(agenceCode)
);

INSERT INTO AGENCE(agenceCode, agenceNom)
VALUES
    ('agce01', 'agence du nord')
  , ('agce02', 'agence du sud')
  , ('agce03', 'agence du sud-est')
;
SELECT * FROM AGENCE ;

=>

agenceId    agenceCode    agenceNom

1           agce01        agence du nord
2           agce02        agence du sud
3           agce03        agence du sud-est

Les agents

CREATE TABLE AGENT
(
   agentId INT IDENTITY,
   agentCode CHAR(8) NOT NULL,
   agentNom VARCHAR(50) NOT NULL,
   agenceId INT NOT NULL,
   CONSTRAINT AGENT_PK PRIMARY KEY(agentId),
   CONSTRAINT AGENT_AK UNIQUE(agentCode),
   CONSTRAINT AGENT_AGENCE_FK FOREIGN KEY(agenceId) 
       REFERENCES AGENCE(agenceId)
); 

INSERT INTO AGENT (agentCode, agentNom, agenceId)
VALUES
   ('agent01', 'Fernand', (SELECT agenceId FROM AGENCE WHERE agenceCode = 'agce01'))
 , ('agent02', 'Raoul', (SELECT agenceId FROM AGENCE WHERE agenceCode = 'agce02'))
 , ('agent03', 'Paul', (SELECT agenceId FROM AGENCE WHERE agenceCode = 'agce02'))
 , ('agent04', 'Mado', (SELECT agenceId FROM AGENCE WHERE agenceCode = 'agce03'))
 , ('agent05', 'Patricia', (SELECT agenceId FROM AGENCE WHERE agenceCode = 'agce01'))
;

SELECT agentCode, agentNom, agenceCode , agenceNom  
FROM   AGENT as x JOIN AGENCE as y ON x.agenceId = y.agenceId 
;

=>

agentCode   agentNom        agenceCode  agenceNom

agent01     Fernand         agce01      agence du nord
agent02     Raoul           agce02      agence du sud
agent03     Paul            agce02      agence du sud
agent04     Mado            agce03      agence du sud-est
agent05     Patricia        agce01      agence du nord 

Les agents qui sont des producteurs

CREATE TABLE PRODUCTEUR
(
   agentId INT,
   CONSTRAINT PRODUCTEUR_PK PRIMARY KEY(agentId),
   CONSTRAINT PRODUCTEUR_AGENT_FK FOREIGN KEY(agentId) 
       REFERENCES AGENT(agentId)
) ;

/* Raoul et Mado sont producteurs */

    ((SELECT agentId  FROM AGENT WHERE agentCode = 'agent02'))
  , ((SELECT agentId  FROM AGENT WHERE agentCode = 'agent04'))
;

SELECT agentCode, agentNom, agenceCode, agenceNom 
FROM   PRODUCTEUR as x 
  JOIN AGENT as y ON x.agentId = y.agentId
  JOIN AGENCE as z ON y.agenceId = z.agenceId 
;   

=>

agentCode   agentNom           agenceCode   agenceNom
agent02     Raoul              agce02       agence du sud
agent04     Mado               agce03       agence du sud-est

Les agents qui sont des caissières

CREATE TABLE CAISSIERE
(
   agentId INT,
   CONSTRAINT CAISSIERE_PK PRIMARY KEY(agentId),
   CONSTRAINT CAISSIERE_AGENT_FK FOREIGN KEY(agentId) 
       REFERENCES AGENT(agentId)
);

/* Mado (qui est déjà producteur) et Patricia sont caissières */

INSERT INTO CAISSIERE(agentId)
VALUES
  ((SELECT agentId  FROM AGENT WHERE agentCode = 'agent04'))
, ((SELECT agentId  FROM AGENT WHERE agentCode = 'agent05'))
;

SELECT '' as caissiere, agentCode, agentNom, agenceCode, agenceNom 
FROM   CAISSIERE as x 
  JOIN AGENT as y  ON x.agentId = y.agentId
  JOIN AGENCE as z on y.agenceId = z.agenceId 
; 

=>

agentCode   agentNom           agenceCode   agenceNom
agent04     Mado               agce03       agence du sud-est
agent05     Patricia           agce01       agence du nord

Les contrats (et leurs producteurs)

CREATE TABLE CONTRAT
(
   contratId INT IDENTITY,
   contratCode VARCHAR(10) NOT NULL,
   ContratDateEffet DATE NOT NULL,
   contratDateExpiration DATE NOT NULL,
   agentId INT NOT NULL,
   CONSTRAINT CONTRAT_PK PRIMARY KEY(contratId),
   CONSTRAINT CONTRAT_AK UNIQUE(contratCode),
   CONSTRAINT CONTRAT_PRODUCTEUR_FK FOREIGN KEY(agentId) 
       REFERENCES PRODUCTEUR(agentId)
);

INSERT INTO CONTRAT (contratCode, ContratDateEffet, contratDateExpiration
                   , agentId)
VALUES
    (  'ctr01', '2019-01-01', '2023-12-31'
     , (SELECT x.agentId 
        FROM   PRODUCTEUR as x 
          JOIN AGENT as y ON x.agentId = y.agentId 
        WHERE agentCode = 'agent02'))
  , (  'ctr02', '2020-02-01', '2023-01-31'
     , (SELECT x.agentId 
        FROM   PRODUCTEUR as x 
         JOIN  AGENT as y  ON x.agentId = y.agentId 
         WHERE agentCode = 'agent02'))

  , (  'ctr03', '2020-03-01', '2023-02-28'
    , (SELECT x.agentId 
       FROM   PRODUCTEUR as x 
         JOIN AGENT as y ON x.agentId = y.agentId 
       WHERE agentCode = 'agent04'))
;

SELECT contratCode, ContratDateEffet
     , agentCode, agentNom  
FROM   CONTRAT as x 
  JOIN AGENT as y ON x.agentId = y.agentId 
;

=>

contratCode   ContratDateEffet   agentCode   agentNom    agenceCode   agenceNom

ctr01         2019-01-01         agent02     Raoul       agce02       agence du sud
ctr02         2020-02-01         agent02     Raoul       agce02       agence du sud
ctr03         2020-03-01         agent04     Mado        agce03       agence du sud-est

Les encaissements relatifs aux contrats

CREATE TABLE ENCAISSE_C
(
   agentId INT,
   contratId INT,
   encaisCtrId INT IDENTITY,
   encaisCtrMontant INT NOT NULL,
   encaisCtrDate DATE NOT NULL,
   CONSTRAINT ENCAISSE_C_PK PRIMARY KEY(agentId, contratId, encaisCtrId),
   CONSTRAINT ENCAISSE_C_CAISSIERE_FK 
       FOREIGN KEY(agentId) REFERENCES CAISSIERE(agentId),
   CONSTRAINT ENCAISSE_C_CONTRAT_FK FOREIGN KEY(contratId) 
       REFERENCES CONTRAT(contratId)
);

INSERT INTO ENCAISSE_C (agentId, contratId
                      , encaisCtrMontant, encaisCtrDate)
VALUES
    (
       (SELECT x.agentId 
        FROM   CAISSIERE as x 
          JOIN AGENT as y on x.agentId = y.agentId
        WHERE agentCode = 'agent04')
     , (SELECT contratId FROM CONTRAT as x WHERE contratCode = 'ctr01')
     , 10000, '2019-01-04'
    )
,
    (
       (SELECT x.agentId 
        FROM   CAISSIERE as x 
          JOIN AGENT as y on x.agentId = y.agentId
        WHERE agentCode = 'agent04')
     , (SELECT contratId FROM CONTRAT as x WHERE contratCode = 'ctr02')
     , 20000, '2020-02-02'
    )
,
    (
       (SELECT x.agentId 
        FROM   CAISSIERE as x 
          JOIN AGENT as y on x.agentId = y.agentId
        WHERE agentCode = 'agent04')
     , (SELECT contratId FROM CONTRAT as x WHERE contratCode = 'ctr01   ')
     , 20000, '2019-01-08'
    )
,
    (
       (SELECT x.agentId 
        FROM   CAISSIERE as x 
          JOIN AGENT as y on x.agentId = y.agentId
        WHERE agentCode = 'agent05')
     , (SELECT contratId FROM CONTRAT as x WHERE contratCode = 'ctr02')
     , 20000, '2020-02-07'
    )
;
SELECT '' as ENCAISSE_C, agentCode, agentNom, contratCode, encaisCtrMontant, encaisCtrDate 
FROM   ENCAISSE_C as x 
  JOIN AGENT as y ON x.agentId = y.agentId
  JOIN CONTRAT as z ON x.contratId = z.contratId
;

=>

agentCode   agentNom     contratCode   encaisCtrMontant   encaisCtrDate

agent04     Mado         ctr01         10000              2019-01-04
agent04     Mado         ctr01         20000              2019-01-08
agent04     Mado         ctr02         20000              2020-02-02
agent05     Patricia     ctr02         20000              2020-02-07

______________________
⁽¹⁾ Voyez l’ouvrage de D. Nanci et B. Espinasse, Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001) page 106 et suivantes, Types et sous-types d’entités : spécialisation/généralisation).
 

[escartefigue]

Bonjour,

Désolé, je n'ai pas eu le courage de lire les 5 pages qui précèdent avec attention, du coup je vais peut être faire un bis de remarques déjà formulées.

L'association (VENIR) entre [CAISSIERE] et [AGENCE] me surprend par son nom et ses cardinalités :
Pourquoi "venir" quelle est la raison d'être de cette association ?
Identifier la caissière relativement à l'agence sera fatal aux caissières en cas de fermeture d'agence

et pourquoi "caissière" les hommes sont ils interdits de séjour aux caisses ?

De même, identifier l'encaissement relativement à la caissière signifie que si la caissière démissionne ou casse sa pipe l'encaissement disparaît...

[fsmrel]

Bonsoir Capitaine,

Identifier la caissière relativement à l'agence sera fatal aux caissières en cas de fermeture d'agence

Non. Du fait de l’action de compensation par défaut RESTRICT (NO ACTION pour être au goût du jour) portée par la contrainte référentielle entre CAISSIERE et AGENCE, tout DELETE affectant une agence sera rejeté par le système. Autrement dit, si Mado fait partie de l’agence A1, il faudra commencer par recaser cet agent (et ses collègues concernés) dans une autre agence avant de tenter de supprimer A1.

Quoi qu’il en soit, dans ma dernière proposition de MCD (post #114), l’entité-type CAISSIERE devient sous-type de l’entité-type AGENT. Là encore, du fait de l’action de compensation par défaut RESTRICT portée par la contrainte référentielle entre AGENT et AGENCE, tout DELETE affectant une agence sera rejeté par le système. Rebelote, si Mado fait partie de l’agence A1, il faudra commencer par recaser cet agent (et ses collègues concernés) dans une autre agence avant de tenter de supprimer A1.

De même, identifier l'encaissement relativement à la caissière signifie que si la caissière démissionne ou casse sa pipe l'encaissement disparaît...

Non. Une fois de plus, du fait de l’action de compensation par défaut RESTRICT portée par la contrainte référentielle entre ENCAISSE_C et CAISSIERE, tout DELETE affectant une caissière sera rejeté par le système. A Zidane7 de voir si les encaissements faits par Mado sont à affecter à Patricia (cuisine douteuse) ou bien si Mado reste dans la base de données (ce qui implique la mise en oeuvre d’attributs DateEmbauche, DateDemission pour savoir si Mado est encore dans les murs), avec au besoin la gestion de l’historique du séjour des agents dans l’entreprise au cas où ceux-ci pourraient être réembauchés).

Quant à l’identification relative de ENCAISSE_C, c’est la conséquence la transformation de l’association ENCAISSE_C en entité-type, à cause de la participation de l’entité-type MODEPAIEMENT (cf. la ternaire dans le MCD du post #97).

[fsmrel]

Bonsoir Patrick,

Cette définition est en désaccord avec celle de Nanci et elle conforme à ce que tu en dis : Avantage donc au binôme Afcet, Paprick.

Ach ! Et si je m’inscris dans le groupe Nanci ?

[fsmrel]

Bonsoir Zidane7,

Concernant les avenants

Il ne reste que l’association "A" entre AVENANT et CONTRAT, l’ association entre AVENANT et VEHICULE ayant disparu (ainsi que l’association entre et AVENANT et CLIENT dont je n’avais pas encore traité) : parfait.


Encore une boucle

On peut aller de véhicule à CLIENT via le chemin direct VEHICULE > APPARTENIR > CLIENT ou via le chemin des écoliers VEHICULE > EST_SOUSCRIT > CONTRAT > ASSURE > CLIENT.

Si le client auquel appartient le véhicule n’est pas nécessairement celui qui est assuré pour ce véhicule, ces deux chemins sont légitimes. Par contre, si le client auquel appartient le véhicule est nécessairement celui qui est assuré pour ce véhicule, alors le chemin direct doit disparaître dans le MCD car on sait l’obtenir à partir de l’autre chemin (jointure SQL).

[escartefigue]

Bonsoir François

Bonsoir Capitaine,
Non. Du fait de l’action de compensation par défaut RESTRICT (NO ACTION pour être au goût du jour) portée par la contrainte référentielle entre CAISSIERE et AGENCE, tout DELETE affectant une agence sera rejeté par le système. Autrement dit, si Mado fait partie de l’agence A1, il faudra commencer par recaser cet agent (et ses collègues concernés) dans une autre agence avant de tenter de supprimer A1.

Certes, mais il n'en reste pas moins qu'une caissière ou un caissier ou tout autre personne travaillant dans une agence, ne saurait être considérée comme une entité-type faible de l'agence
Dans le cas d'une commande au contraire, supprimer la commande permet de supprimer toutes ses lignes grâce au DELETE CASCADE et c'est très bien ainsi.

Quoi qu’il en soit, dans ma dernière proposition de MCD (post #114), l’entité-type CAISSIERE devient sous-type de l’entité-type AGENT. Là encore, du fait de l’action de compensation par défaut RESTRICT portée par la contrainte référentielle entre AGENT et AGENCE, tout DELETE affectant une agence sera rejeté par le système. Rebelote, si Mado fait partie de l’agence A1, il faudra commencer par recaser cet agent (et ses collègues concernés) dans une autre agence avant de tenter de supprimer A1.

Et c'est bien mieux ainsi, mais derechef, l'agent n'est pas une entité-type faible de l'agence, l'un et l'autre ont leur existence propre, d'ailleurs, tu n'as à juste titre pas utilisé l'identification relative

[Paprick]

Ach ! Et si je m’inscris dans le groupe Nanci ?

Et tu deviendrais le prince de l'identification relative sans identifiant relatif !