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

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

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

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

    Informations forums :
    Inscription : juin 2019
    Messages : 291
    Points : 1 135
    Points
    1 135
    Par défaut
    Bonsoir,
    Citation Envoyé par Zidane7 Voir le message
    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é...
    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

  2. #102
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    7 388
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 7 388
    Points : 27 868
    Points
    27 868
    Billets dans le blog
    16
    Par défaut
    Bonsoir,

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

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

  3. #103
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    7 388
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 7 388
    Points : 27 868
    Points
    27 868
    Billets dans le blog
    16
    Par défaut
    Citation Envoyé par Zidane7 Voir le message
    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 ?
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

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

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

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

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

  5. #105
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    7 388
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 7 388
    Points : 27 868
    Points
    27 868
    Billets dans le blog
    16
    Par défaut
    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 ?
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

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

  6. #106
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    7 388
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 7 388
    Points : 27 868
    Points
    27 868
    Billets dans le blog
    16
    Par défaut
    Bonsoir Patrick,


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

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

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

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

    Informations forums :
    Inscription : juin 2019
    Messages : 291
    Points : 1 135
    Points
    1 135
    Par défaut
    Citation Envoyé par fsmrel Voir le message
    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.
    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

  8. #108
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    7 388
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 7 388
    Points : 27 868
    Points
    27 868
    Billets dans le blog
    16
    Par défaut
    Citation Envoyé par Paprick Voir le message
    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)...
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

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

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

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

    Informations forums :
    Inscription : juin 2019
    Messages : 291
    Points : 1 135
    Points
    1 135
    Par défaut
    Citation Envoyé par fsmrel Voir le message
    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.
    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

  10. #110
    Membre à l'essai
    Homme Profil pro
    Développeur Java
    Inscrit en
    décembre 2019
    Messages
    52
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Guinée

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : décembre 2019
    Messages : 52
    Points : 13
    Points
    13
    Par défaut Conception d'un MCD pour une assurance automobile
    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)
    );
    Images attachées Images attachées  

  11. #111
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    7 388
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 7 388
    Points : 27 868
    Points
    27 868
    Billets dans le blog
    16
    Par défaut
    Bonsoir,

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


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

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

  12. #112
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    7 388
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 7 388
    Points : 27 868
    Points
    27 868
    Billets dans le blog
    16
    Par défaut
    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.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

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

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

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

    Informations forums :
    Inscription : juin 2019
    Messages : 291
    Points : 1 135
    Points
    1 135
    Par défaut
    Bonsoir François,
    Citation Envoyé par fsmrel Voir le message
    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.
    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

  14. #114
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    7 388
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 7 388
    Points : 27 868
    Points
    27 868
    Billets dans le blog
    16
    Par défaut
    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 :
    Nom : Zidane7_assurance_auto_producteur_caissiere.png
Affichages : 21
Taille : 19,4 Ko


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

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

  15. #115
    Expert éminent sénior
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    6 499
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 6 499
    Points : 20 156
    Points
    20 156
    Billets dans le blog
    2
    Par défaut
    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...

  16. #116
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    7 388
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 7 388
    Points : 27 868
    Points
    27 868
    Billets dans le blog
    16
    Par défaut
    Bonsoir Capitaine,


    Citation Envoyé par escartefigue Voir le message
    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.


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

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

  17. #117
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    7 388
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 7 388
    Points : 27 868
    Points
    27 868
    Billets dans le blog
    16
    Par défaut
    Bonsoir Patrick,


    Citation Envoyé par Paprick Voir le message
    Citation Envoyé par fsmrel Voir le message
    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 ?
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

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

  18. #118
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    7 388
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 7 388
    Points : 27 868
    Points
    27 868
    Billets dans le blog
    16
    Par défaut
    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).
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

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

  19. #119
    Expert éminent sénior
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    6 499
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 6 499
    Points : 20 156
    Points
    20 156
    Billets dans le blog
    2
    Par défaut
    Bonsoir François

    Citation Envoyé par fsmrel Voir le message
    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.

    Citation Envoyé par fsmrel Voir le message
    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

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

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

    Informations forums :
    Inscription : juin 2019
    Messages : 291
    Points : 1 135
    Points
    1 135
    Par défaut
    Citation Envoyé par fsmrel Voir le message
    Ach ! Et si je m’inscris dans le groupe Nanci ?
    Et tu deviendrais le prince de l'identification relative sans identifiant relatif !
    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

Discussions similaires

  1. Réponses: 2
    Dernier message: 28/03/2008, 20h23
  2. Mcd pour une suivi de materiel simple SVP
    Par moumio dans le forum Forms
    Réponses: 1
    Dernier message: 25/11/2007, 15h47
  3. [MCD] Conception d'un MCD pour des étudiants d'une fac
    Par beegees dans le forum Schéma
    Réponses: 7
    Dernier message: 16/10/2006, 03h05
  4. Réponses: 3
    Dernier message: 12/01/2006, 19h47
  5. [Conception] - Organisation des pages pour une requete.
    Par ShinJava dans le forum PHP & Base de données
    Réponses: 14
    Dernier message: 24/10/2005, 16h33

Partager

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