Patrick Bergougnoux - Professeur des Universités au Département Informatique de l'IUT de Toulouse III
La simplicité est la sophistication suprême (Léonard de Vinci)
LIVRE : Modélisation Conceptuelle de Données - Une Démarche Pragmatique
Looping - Logiciel de modélisation gratuit et libre d'utilisation
Bonsoir,
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.
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, 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 »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, 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 »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Patrick Bergougnoux - Professeur des Universités au Département Informatique de l'IUT de Toulouse III
La simplicité est la sophistication suprême (Léonard de Vinci)
LIVRE : Modélisation Conceptuelle de Données - Une Démarche Pragmatique
Looping - Logiciel de modélisation gratuit et libre d'utilisation
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 ?
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, 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 »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Bonsoir Patrick,
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).
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, 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 »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
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.
Patrick Bergougnoux - Professeur des Universités au Département Informatique de l'IUT de Toulouse III
La simplicité est la sophistication suprême (Léonard de Vinci)
LIVRE : Modélisation Conceptuelle de Données - Une Démarche Pragmatique
Looping - Logiciel de modélisation gratuit et libre d'utilisation
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, 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 »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
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.
Patrick Bergougnoux - Professeur des Universités au Département Informatique de l'IUT de Toulouse III
La simplicité est la sophistication suprême (Léonard de Vinci)
LIVRE : Modélisation Conceptuelle de Données - Une Démarche Pragmatique
Looping - Logiciel de modélisation gratuit et libre d'utilisation
Bonsoir Messieurs,
Paprick
A ce niveau, je viens de mettre la clé de la cedeao comme suivant: cedeaohistoId et cela marche. Merci pour votre intervention.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 ?
fsmrel
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?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 ?
Il ya deux(2) types de contrats à savoir: MONO et FLOTTE.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 ?
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)
);
Bonsoir,
Zidane7, pardonnez cette incidente sur l'identification relative, mais on s'occupe de vous.
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. »
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, 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 »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
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.
En passant, la responsabilité civile étant une donnée numérique, le type VARCHAR(50) est inapproprié pour l’attribut correspondant.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) );
Je vais regarder la suite de vos questions/réponses.
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, 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 »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Bonsoir François,
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.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.
Patrick Bergougnoux - Professeur des Universités au Département Informatique de l'IUT de Toulouse III
La simplicité est la sophistication suprême (Léonard de Vinci)
LIVRE : Modélisation Conceptuelle de Données - Une Démarche Pragmatique
Looping - Logiciel de modélisation gratuit et libre d'utilisation
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)(1).
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
(1) 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).
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, 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 »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
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...
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.
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.
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).
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, 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 »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, 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 »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
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).
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, 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 »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Bonsoir François
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.
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
Patrick Bergougnoux - Professeur des Universités au Département Informatique de l'IUT de Toulouse III
La simplicité est la sophistication suprême (Léonard de Vinci)
LIVRE : Modélisation Conceptuelle de Données - Une Démarche Pragmatique
Looping - Logiciel de modélisation gratuit et libre d'utilisation
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager