1. #21
    Expert confirmé
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 608
    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 : 2 608
    Points : 5 794
    Points
    5 794

    Par défaut

    Bonjour et merci pour les explications complémentaires

    A ma question sur l'équivalence éventuelle entre Agence et Producteur vous répondez par l'affirmative, mais les deux entités-types sont toujours présentes dans le modèle
    Si ce sont les mêmes notions, alors il ne faut en conserver qu'une seule
    Si vous conservez producteur plutôt qu'agence, alors il faut corriger la cardinalité mini à 0 vers les avenants (comme vous l'avez fait pour agence)

    Les entités-type TtypeGarantie et Tgaranties semblent identiques elles aussi ? à simplfier si c'est le cas, ou expliquer sinon

    Une remarque globale sur les différentes entités-type qui identifient des personnes (courtier, apporteur, producteur, assuré...), vous n'avez jamais modélisé d'entité type spécifique pour les adresses, ni pour les moyens de contacts. Ce faisant, vous limitez les possibilités de répétition.
    Classiquement, on modélise les contacts (téléphone, courriel, etc...) et adresses ainsi

    Personne 0,n----Posseder---1,1---Adresse 1,1---typer---0,n TypeAdresse

    Personne 0,n---Posseder---1,1---Contact 1,1---Typer---0,n TypeContact

    Sous forme Graphique :
    Nom : MCD_Contact.png
Affichages : 155
Taille : 11,4 Ko
    Dans cet exemple, les propriétés de la relation Posséder, permettent de gérer à date les notions de contacts préférés (par exemple le n° de téléphone à utiliser en priorité pour appeler un assuré)

  2. #22
    Membre régulier
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    décembre 2013
    Messages
    127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Guinée

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Associations - ONG

    Informations forums :
    Inscription : décembre 2013
    Messages : 127
    Points : 75
    Points
    75

    Par défaut Proposition d'un model conceptuel de donnée MCD

    Bonjour!
    J'ai un soucis par rapport à mon modèle.
    La relation entre la Table ou Entité TVEHICULE et TGARANTIE qui est ''EST SOUSCRIT'' est elle bonne?
    NB: Cette relation sera une table qui permettra de savoir quelle garantie le véhicule est souscrite et à quel montant vaut la garantie appelé ici PRIME et sa date de souscription.
    J'ai besoin de votre point de vue.
    Voici la pièce jointe.
    Merci par avance.
    Fichiers attachés Fichiers attachés

  3. #23
    Membre régulier
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    décembre 2013
    Messages
    127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Guinée

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Associations - ONG

    Informations forums :
    Inscription : décembre 2013
    Messages : 127
    Points : 75
    Points
    75

    Par défaut Proposition d'un model conceptuel de donnée MCD

    Rebonjour Monsieur escartefigue!
    A ma question sur l'équivalence éventuelle entre Agence et Producteur vous répondez par l'affirmative, mais les deux entités-types sont toujours présentes dans le modèle
    L'Agence c'est le lieu que le contrat est fait et le Producteur est celui qui a fait le contrat. Avez-vous compris mon problème?
    Les entités-type TtypeGarantie et Tgaranties semblent identiques elles aussi ? à simplifier si c'est le cas, ou expliquer sinon
    Les types de garantie sont les suivants: RC simple, Extension de garantie et TousRisques donc pour la table TTYPEGARANTIE. La table TGARANTIE, elle contient toutes les garanties.
    Une remarque globale sur les différentes entités-type qui identifient des personnes (courtier, apporteur, producteur, assuré...), vous n'avez jamais modélisé d'entité type spécifique pour les adresses, ni pour les moyens de contacts. Ce faisant, vous limitez les possibilités de répétition.
    Classiquement, on modélise les contacts (téléphone, courriel, etc...) et adresses ainsi

    Personne 0,n----Posseder---1,1---Adresse 1,1---typer---0,n TypeAdresse

    Personne 0,n---Posseder---1,1---Contact 1,1---Typer---0,n TypeContact
    J'aimerais savoir s'il faut modeliser chaque Entité (courtier, apporteur, producteur, assuré...) comme telle ou mettre le tout dans une même adresse ou Entité qui est Contact et Typecontact? Si oui comment?
    Merci infiniment par avance pour votre remarque et suggestion.

  4. #24
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

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

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 774
    Points
    18 774
    Billets dans le blog
    15

    Par défaut Souscriptions

    Bonsoir Zizoua,


    Citation Envoyé par Zizoua
    La relation entre la Table ou Entité TVEHICULE et TGARANTIE qui est ''EST SOUSCRIT'' est elle bonne?
    NB: Cette relation sera une table qui permettra de savoir quelle garantie le véhicule est souscrite et à quel montant vaut la garantie appelé ici PRIME et sa date de souscription.

    Les entités-types TVEHICULE et TGARANTIE sont l’objet d’une association EST_SOUSCRIT (dotée des attributs DATE_SOUSCRIPTION et PRIME), et chacune des pattes de cette association est porteuse d’une cardinalité maximale N.

    Exemple :




    (1) Pour produire un MLD, sous forme de diagramme relationnel, dans la barre de menus, vous sélectionnez :

    Product > Copy product

    Et à la demande de DB-MAIN, vous donnez un nom au nouveau schéma. Vous affichez ce schéma, lequel est la copie du premier, et dans la barre de menus, vous sélectionnez :

    Transform > Relational Model

    Au résultat :




    (2) Pour voir ce que cela donne au niveau SQL, dans la barre de menus, vous sélectionnez :

    File > Generate > nom du SGBD

    Avec « Standard SQL » :

    
    -- Tables Section
    -- --------------
    
    create table TGARANTIE (
         num_garantie numeric(7) not null,
         garantie char(32) not null,
         constraint ID_TGARANTIE primary key (num_garantie));
    
    create table TVEHICULE (
         num_vehicule numeric(8) not null,
         police varchar(16) not null,
         marque varchar(32) not null,
         constraint ID_TVEHICULE primary key (num_vehicule));
    
    create table EST_SOUSCRIT (
         num_garantie numeric(7) not null,
         num_vehicule numeric(8) not null,
         date_souscription date not null,
         prime numeric(8) not null,
         constraint ID_EST_SOUSCRIT primary key (num_vehicule, num_garantie));
    
    -- Constraints Section
    -- -------------------
    
    alter table EST_SOUSCRIT add constraint FKEST_TVE
         foreign key (num_vehicule)
         references TVEHICULE;
    
    alter table EST_SOUSCRIT add constraint FKEST_TGA
         foreign key (num_garantie)
         references TGARANTIE;
    
    
    Manifestement, la table EST_SOUSCRIT (évitez les espaces entre les mots « Est » et « SOUSCRIT ») permet de savoir pour une paire {num_vehicule, num_garantie}, c'est-à-dire pour chaque garantie souscrite pour un véhicule donné, quelle est la date de souscription et le montant de la prime.
    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 »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  5. #25
    Membre régulier
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    décembre 2013
    Messages
    127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Guinée

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Associations - ONG

    Informations forums :
    Inscription : décembre 2013
    Messages : 127
    Points : 75
    Points
    75

    Par défaut Proposition d'un model conceptuel de donnée MCD

    escartefigue
    Pour l'entité type "garanties" vous n'avez pas répondu à ma question, je vois des attributs comme RC et DV qui me font penser à "Responsabilité Civile" et "Dommage Véhicule"
    Si c'est bien cela dont il s'agit, il ne faut pas modéliser ainsi.
    Il ne faut pas répéter les attributs, mais créer un attribut unique "code garantie" et un libellé correspondant, vous répéterez autant de fois que nécessaire les lignes pour les valoriser avec les différents codes et libellés possibles.
    Je reformule ma question.
    J’ai des garanties suivantes :
    1 RESPONSABILITE EN CIRCULATION
    2 RECOURS TIERS INC. HORS CIRCULATION
    3 DOMMAGES AU VEHICULE
    4 INCENDIE - EXPLOSION
    5 VOL DU VEHICULE
    6 BRIS DE GLACE
    7 DEFENSE - RECOURS
    8 ASSURANCE FAMILLE & PASSAGERS
    9 PROTECTION CONDUCTEUR
    10 AVANCE SUR RECOURS
    J’aimerais savoir si on veut par exemple souscrire un véhicule à 2, 3, ou 4 garanties avec des montants différents, il faut saisir un à un ou mettre le numéro de chaque garantie avec son montant et valider, ensuite saisir une autre garantie avec son numéro et valider ? Ou s’il y a une autre procédure pour saisir les numéros des garanties qu’on a besoin pour valider une fois pour toute ?
    Je demande s’il y a une autre façon de modéliser pour obtenir ma toute dernière question.
    NB : Ces valeurs sont obtenues dans l’association ‘’ EST SOUSCRIT’’ qui sera transformée en table.
    J'ai ajouté la pièce jointe pour vous permettre de voir mon modèle et de bien comprendre mon problème.
    Merci infiniment par avance.
    Fichiers attachés Fichiers attachés

  6. #26
    Expert confirmé
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 608
    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 : 2 608
    Points : 5 794
    Points
    5 794

    Par défaut

    Citation Envoyé par Zizoua Voir le message
    L'Agence c'est le lieu que le contrat est fait et le Producteur est celui qui a fait le contrat. Avez-vous compris mon problème?
    En ce cas il y a bien 2 entités-types différentes
    Je reformule pour etre sur d'avoir bien compris : le producteur est un employé d'une agence ?
    Si c'est bien ça, la relation produire de producteur serait la même que souscrire de courtier ? on pourrait donc avoir une seule relation, avec une exclusion courtier/producteur

    Citation Envoyé par Zizoua Voir le message
    J'aimerais savoir s'il faut modeliser chaque Entité (courtier, apporteur, producteur, assuré...) comme telle ou mettre le tout dans une même adresse ou Entité qui est Contact et Typecontact? Si oui comment?
    Conceptuellement il s'agit bien de choses différentes, le MCD fera apparaitre autant d'entités-types que d'adresses (adresses courtiers, adresses producteur, adresse assuré...)
    Au niveau physique MPD, il sera possible de faire d'autres choix

  7. #27
    Expert confirmé
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 608
    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 : 2 608
    Points : 5 794
    Points
    5 794

    Par défaut

    Citation Envoyé par Zizoua Voir le message
    J’aimerais savoir si on veut par exemple souscrire un véhicule à 2, 3, ou 4 garanties avec des montants différents, il faut saisir un à un ou mettre le numéro de chaque garantie avec son montant et valider, ensuite saisir une autre garantie avec son numéro et valider ? Ou s’il y a une autre procédure pour saisir les numéros des garanties qu’on a besoin pour valider une fois pour toute ?
    Ces questions concernent les traitements, votre MCD n'est pas concerné à ce stade, les règles de saisie et validation doivent être vues après.

    Pour en revenir aux garanties et types de garanties, si c'est le type de garanties qui conditionne la tarification, et qu'un assuré ne peut pas souscrire une garantie particulière, mais seulement un type de garantie (type qui inclut une ou plusieurs garanties), il faut donc bien maintenir les 2 entités-type sans faire apparaitre les valeurs de garantie dans l'entité-type "tgarantie" : "RC", "DV", "IE" etc... sont des valeurs liées à des instances de l'entité-type, vous les avez supprimées dans votre pièce jointe du post n°25, c'est parfait .

  8. #28
    Membre régulier
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    décembre 2013
    Messages
    127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Guinée

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Associations - ONG

    Informations forums :
    Inscription : décembre 2013
    Messages : 127
    Points : 75
    Points
    75

    Par défaut Proposition d'un model conceptuel de donnée MCD

    Bonjour!
    En ce cas il y a bien 2 entités-types différentes.
    Je reformule pour etre sur d'avoir bien compris : le producteur est un employé d'une agence ?
    Si c'est bien ça, la relation produire de producteur serait la même que souscrire de courtier ? on pourrait donc avoir une seule relation, avec une exclusion courtier/producteur.
    Les cardinalités entre les Tables TCONTRAT et TCOURTIER sont 0,1 et 1,N (un contrat peut ne pas être produit par un courtier et un courtier est celui qui produit au moins un contrat ou plusieurs contrats).
    Et celles des Tables TCONTRAT et TPRODUCTEUR sont 1,1 et 1,N (un contrat est produit par un et un seul Producteur et un producteur est celui qui a produit au mois un contrat ou plusiers contrats).
    Donc donner les mêmes relations entre les Tables TCOURTIER et TPRODUCTEUR serait comment?
    Pouvez-vous me donner un schéma explicatif?
    Conceptuellement il s'agit bien de choses différentes, le MCD fera apparaitre autant d'entités-types que d'adresses (adresses courtiers, adresses producteur, adresse assuré...)
    Au niveau physique MPD, il sera possible de faire d'autres choix.
    Merci de m'avoir donner une explication claire.
    Pour en revenir aux garanties et types de garanties, si c'est le type de garanties qui conditionne la tarification, et qu'un assuré ne peut pas souscrire une garantie particulière, mais seulement un type de garantie (type qui inclut une ou plusieurs garanties), il faut donc bien maintenir les 2 entités-type sans faire apparaitre les valeurs de garantie dans l'entité-type "tgarantie" : "RC", "DV", "IE" etc... sont des valeurs liées à des instances de l'entité-type, vous les avez supprimées dans votre pièce jointe du post n°25, c'est parfait .
    Un Assuré peut souscrire à une garantie particulière telle que la RC simple ou revenir pour faire une extension de garantie ou bien souscrire à Tous Risques.
    Voici la pièce jointe du MCD.
    Fichiers attachés Fichiers attachés

  9. #29
    Expert confirmé
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 608
    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 : 2 608
    Points : 5 794
    Points
    5 794

    Par défaut

    Citation Envoyé par Zizoua Voir le message
    Donc donner les mêmes relations entre les Tables TCOURTIER et TPRODUCTEUR serait comment?
    Pouvez-vous me donner un schéma explicatif?
    J'ai écrit une bétise il faut ajouter une exclusion entre les 2 relations (une exclusion avec une seule relation n'a pas de sens )
    Ce qui donne un schéma comme suit

    Nom : MCD0.png
Affichages : 116
Taille : 22,3 Ko

  10. #30
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

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

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 774
    Points
    18 774
    Billets dans le blog
    15

    Par défaut Exclusion

    Bonsoir,


    Comme j’ai pas mal de fers au feu, je n’ai pas tout lu de vos échanges passionnés mais courtois (la courtoisie ça fait du bien !), j’aimerais toutefois revenir sur tel ou tel point.


    Selon le MCD de Zizoua :


    Un contrat est produit par au moins et au plus un producteur ;

    Un contrat peut être apporté par au plus un apporteur ;

    Un contrat peut être amené par au plus un courtier.


    Zizoua, quelle définition précise donnez-vous au mot « apporteur » ? En particulier, s’agit-il de toute personne qui n’est pas courtier ?

    Quelle différence sémantique y a-t-il entre les verbes « apporter » et « amener » ?

    Si un contrat provient soit d’un courtier soit d’un apporteur, alors il y a une contrainte d’exclusion à prévoir.

    Quant à la représentation de cette contrainte, faisons référence à la « norme » Merise (définie lors de la journée Afcet du 15 novembre 1990) :




    Par référence à la norme, la contrainte selon laquelle un contrat donné ne peut pas être à la fois « apporté » et « amené », est à représenter ainsi (CONTRAT constitue le pivot de la contrainte) :





    Quelle définition précise donnez-vous au verbe « faire » dans la phrase « le Producteur est celui qui a fait le contrat » ? Le producteur est certes une personne physique d’une agence, mais (simple curiosité de ma part), à quel niveau de responsabilité se situe-t-il ? (chef ? exécutant ? Les deux mon général ?)


    escartefigue, votre diagramme où est représentée l’exclusion est ambigu, et tend à faire croire que cette contrainte donnera lieu à une ternaire, c'est-à-dire au stade relationnel à une variable relationnelle de degré 3 {id_prod, id_courtier, id_contrat} redondante, puisque décomposable en deux binaires {id_contrat, id_prod}, {id_contrat, id_courtier}
    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 »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  11. #31
    Membre régulier
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    décembre 2013
    Messages
    127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Guinée

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Associations - ONG

    Informations forums :
    Inscription : décembre 2013
    Messages : 127
    Points : 75
    Points
    75

    Par défaut Proposition d'un model conceptuel de donnée MCD

    escartefigue

    J'ai écrit une bétise il faut ajouter une exclusion entre les 2 relations (une exclusion avec une seule relation n'a pas de sens )
    Ce qui donne un schéma comme suit
    Si j'ai bien compris d'après votre schéma, un Courtier est forcément un Producteur et un producteur n'est pas forcément un Courtier et ils produisent tous des contrats?
    Pouvez-vous me donner les cardinalités de ces pattes?
    Et si on liait Courtier et Producteur?
    Merci par avance.

  12. #32
    Membre régulier
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    décembre 2013
    Messages
    127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Guinée

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Associations - ONG

    Informations forums :
    Inscription : décembre 2013
    Messages : 127
    Points : 75
    Points
    75

    Par défaut Proposition d'un model conceptuel de donnée MCD

    Monsieur fsmrel!
    Un contrat est produit par au moins et au plus un producteur ;
    Un contrat peut être apporté par au plus un apporteur ;
    Un contrat peut être amené par au plus un courtier.
    Zizoua, quelle définition précise donnez-vous au mot « apporteur » ? En particulier, s’agit-il de toute personne qui n’est pas courtier ?
    Effectivement. Un apporteur est une personne qui n'a pas d'agrément sinon que sa carte professionnelle et un courtier a un agrément et un cabinet de courtage.
    Quelle différence sémantique y a-t-il entre les verbes « apporter » et « amener » ?
    Les mots me manquent mais apporteur et courtier sont deux personnes différentes et ils amènent tous des contrats.
    Si un contrat provient soit d’un courtier soit d’un apporteur, alors il y a une contrainte d’exclusion à prévoir.
    Oui un contrat provient soit d'un courtier soit d'un apporteur.
    Quelle définition précise donnez-vous au verbe « faire » dans la phrase « le Producteur est celui qui a fait le contrat » ? Le producteur est certes une personne physique d’une agence, mais (simple curiosité de ma part), à quel niveau de responsabilité se situe-t-il ? (chef ? exécutant ? Les deux mon général ?)
    Ici un producteur est un exécutant dans une agence, qui produit les contrats(il peut ne pas être chef, mais s'il produit ou fait un contrat alors il est producteur).
    escartefigue, votre diagramme où est représentée l’exclusion est ambigu, et tend à faire croire que cette contrainte donnera lieu à une ternaire, c'est-à-dire au stade relationnel à une variable relationnelle de degré 3 {id_prod, id_courtier, id_contrat} redondante, puisque décomposable en deux binaires {id_contrat, id_prod}, {id_contrat, id_courtier}
    Merci d'avoir lever l'équivoque.
    Je vous remercie une fois de plus de vos différents efforts.
    Avez-vous d'autres remarques?
    Merci par avance.

  13. #33
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

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

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 774
    Points
    18 774
    Billets dans le blog
    15

    Par défaut Généralisation

    Bonsoir à nouveau,


    Citation Envoyé par Zizoua
    Ici un producteur est un exécutant dans une agence, qui produit les contrats (il peut ne pas être chef, mais s'il produit ou fait un contrat alors il est producteur).
    N’étant pas du métier, j’ai du mal à interpréter l’expression « produire des contrats »... Pourriez-vous donner quelques brèves explications ?


    Zizoua, dans votre MCD, si l’attribut POLICE de l’entité-type TVEHICULE fait référence à l’attribut POLICE de l’entité-type TCONTRAT, alors l’information est définie explicitement deux fois, mais par ailleurs, elle l’est aussi implicitement (du fait de l’association EST_SOUSCRIT connectant les deux entités-types) : l’attribut POLICE doit être éliminé de l’entité-type TVEHICULE, sinon il existera en double au stade SQL dans la table TVEHICULE.


    Zizoua, on est bien d’accord que les attributs POLICE, NUMVEHICULE, NUMPROD, NUMASSURE, etc. sont artificiels, c'est-à-dire qu’ils ne sont porteurs d’aucune signification, donc sont d’une stabilité absolue, parfaitement invariants, n’est-ce pas ? A ce sujet, voyez le billet De l’invariance des clés primaires, plus particulièrement la règle d’or de Tabourier. Si ces attributs ont un sens, alors ils deviendront des identifiants alternatifs (ils conservent leur propriété d’unicité), et il faudra définir des identifiants « primaires » artificiels, à la manière d’escartefigue : id_contrat, id_vehicule, etc. On en reparlera dans le contexte de DB-MAIN.



    Citation Envoyé par escartefigue

    Citation Envoyé par Zizoua
    J'aimerais savoir s'il faut modéliser chaque Entité (courtier, apporteur, producteur, assuré...) comme telle ou mettre le tout dans une même adresse ou Entité qui est Contact et Typecontact? Si oui comment?
    Conceptuellement il s'agit bien de choses différentes, le MCD fera apparaître autant d'entités-types que d'adresses (adresses courtiers, adresses producteur, adresse assuré...)

    Les courtiers, les apporteurs, les producteurs, les assurés, sont des personnes qui partagent des propriétés communes (nom, adresse, adresse, etc.), je propose donc de procéder à la généralisation des entités-types :






    PERSONNE est un surtype, ASSURE, COURTIER, APPORTEUR, PRODUCTEUR sont des sous-types. Pour construire un sous-type, voyez la technique utilisée ici.

    Dans le triangle symbolisant l’héritage, figure la lettre « P » : elle symbolise l’exclusion et la totalité, c'est-à-dire le partitionnement :

    Totalité : ASSURE, COURTIER, APPORTEUR, PRODUCTEUR sont les seuls types de personnes, il n’en existe pas d’autres. A défaut, merci de préciser ce qu’il en est.

    Exclusion : un assuré ne peut pas être à la fois courtier ou apporteur ou producteur. Un courtier ne peut pas non plus être apporteur ou producteur. Un apporteur ne peut pas non plus être producteur. Merci de préciser ce qu’il en est exactement : par exemple, un apporteur, un producteur, un courtier peuvent-ils être aussi des assurés ?


    Pour les adresses (en supposant qu’une adresse peut jouer plus d’un rôle) :





    Zizoua, vous ne votez pas souvent... Je pense qu’escartefigue et moi-même vous apportons quelques éclairages : pour marquer votre satisfaction, n’hésitez pas à cliquer sur le pouce vert en bas de nos messages qui ont pu vous apporter quelque chose, et au passage à confirmer ici des médailles acquises sur différents terrains, souvent accidentés...
    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 »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  14. #34
    Expert confirmé
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 608
    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 : 2 608
    Points : 5 794
    Points
    5 794

    Par défaut

    Citation Envoyé par Zizoua Voir le message
    escartefigue
    Si j'ai bien compris d'après votre schéma, un Courtier est forcément un Producteur et un producteur n'est pas forcément un Courtier et ils produisent tous des contrats?
    Merci par avance.
    Non, ce que j'ai compris, peut être à tort, c'est qu'un contrat est soit produit par un courtier, soit par un producteur, jamais les 2 à la fois, d'où l'exclusion entre les 2 relations
    J'avais également supposé qu'un producteur était un employé d'une agence, est-ce bien le cas ?

    En réponse à FsmRel : je ne m'explique pas la disparition des liens qui sur mon dessin reliaient le X de l'exclusion avec les 2 relations , c'est bien comme ça que le dessin devrait apparaitre

    En effet, la généralisation des différents intervenants dans "personne" est une possibilité intéressante, reste à voir quels sont les attributs communs et ceux qui ne le sont pas entre les assurés, producteurs, courtiers et autres personnes

  15. #35
    Membre régulier
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    décembre 2013
    Messages
    127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Guinée

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Associations - ONG

    Informations forums :
    Inscription : décembre 2013
    Messages : 127
    Points : 75
    Points
    75

    Par défaut Proposition d'un model conceptuel de donnée MCD

    Bonjour!
    fsmrel
    Bonsoir à nouveau,
    Envoyé par Zizoua
    Ici un producteur est un exécutant dans une agence, qui produit les contrats (il peut ne pas être chef, mais s'il produit ou fait un contrat alors il est producteur).
    N’étant pas du métier, j’ai du mal à interpréter l’expression « produire des contrats »... Pourriez-vous donner quelques brèves explications ?
    Producteur ou produire un contrat est celui qui est dans une agence et qui est assis derrière l'ordinateur qui saisi puis imprime le contrat du client(l'assuré). Mon objectif est de savoir qui a fait tel ou tel contrat dans telle ou telle agence pour situer la responsabilité. Qu'il soit chef ou exécutant, s'il doit saisir et imprimer des contrats alors il doit avoir son nom dans le logiciel pour savoir celui qui a fait ce contrat.
    Zizoua, dans votre MCD, si l’attribut POLICE de l’entité-type TVEHICULE fait référence à l’attribut POLICE de l’entité-type TCONTRAT, alors l’information est définie explicitement deux fois, mais par ailleurs, elle l’est aussi implicitement (du fait de l’association EST_SOUSCRIT connectant les deux entités-types) : l’attribut POLICE doit être éliminé de l’entité-type TVEHICULE, sinon il existera en double au stade SQL dans la table TVEHICULE.
    Merci et j'ai corrigé.
    Zizoua, on est bien d’accord que les attributs POLICE, NUMVEHICULE, NUMPROD, NUMASSURE, etc. sont artificiels, c'est-à-dire qu’ils ne sont porteurs d’aucune signification, donc sont d’une stabilité absolue, parfaitement invariants, n’est-ce pas ? A ce sujet, voyez le billet De l’invariance des clés primaires, plus particulièrement la règle d’or de Tabourier. Si ces attributs ont un sens, alors ils deviendront des identifiants alternatifs (ils conservent leur propriété d’unicité), et il faudra définir des identifiants « primaires » artificiels, à la manière d’escartefigue : id_contrat, id_vehicule, etc. On en reparlera dans le contexte de DB-MAIN.
    Merci pour ces remarques.
    Envoyé par Zizoua
    J'aimerais savoir s'il faut modéliser chaque Entité (courtier, apporteur, producteur, assuré...) comme telle ou mettre le tout dans une même adresse ou Entité qui est Contact et Typecontact? Si oui comment?
    Conceptuellement il s'agit bien de choses différentes, le MCD fera apparaître autant d'entités-types que d'adresses (adresses courtiers, adresses producteur, adresse assuré...)
    Les courtiers, les apporteurs, les producteurs, les assurés, sont des personnes qui partagent des propriétés communes (nom, adresse, adresse, etc.), je propose donc de procéder à la généralisation des entités-types :
    PERSONNE est un surtype, ASSURE, COURTIER, APPORTEUR, PRODUCTEUR sont des sous-types. Pour construire un sous-type, voyez la technique utilisée ici.
    Dans le triangle symbolisant l’héritage, figure la lettre « P » : elle symbolise l’exclusion et la totalité, c'est-à-dire le partitionnement :
    Totalité : ASSURE, COURTIER, APPORTEUR, PRODUCTEUR sont les seuls types de personnes, il n’en existe pas d’autres. A défaut, merci de préciser ce qu’il en est.
    Exclusion : un assuré ne peut pas être à la fois courtier ou apporteur ou producteur. Un courtier ne peut pas non plus être apporteur ou producteur. Un apporteur ne peut pas non plus être producteur. Merci de préciser ce qu’il en est exactement : par exemple, un apporteur, un producteur, un courtier peuvent-ils être aussi des assurés ?
    Merci.
    D'après votre schéma, on fait une Entité PERSONNE(id_personne,adres_personne,...) et une Entité TYPEPERSONNE(id_typepersonne,typepersonne,...) ici on mettra les Assuré, les Courtiers, les Producteurs et les Apporteurs?
    Mais un Producteur peut être un Assuré tout comme un Courtier, un Apporteur peuvent être des Assurés. Comment géré ce cas?

  16. #36
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

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

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 774
    Points
    18 774
    Billets dans le blog
    15

    Par défaut

    Bonsoir,


    Citation Envoyé par Zizoua
    Producteur ou produire un contrat est celui qui est dans une agence et qui est assis derrière l'ordinateur qui saisi puis imprime le contrat du client(l'assuré). Mon objectif est de savoir qui a fait tel ou tel contrat dans telle ou telle agence pour situer la responsabilité. Qu'il soit chef ou exécutant, s'il doit saisir et imprimer des contrats alors il doit avoir son nom dans le logiciel pour savoir celui qui a fait ce contrat.
    Merci pout l’éclairage.



    Citation Envoyé par Zizoua
    Un Producteur peut être un Assuré tout comme un Courtier, un Apporteur peuvent être des Assurés. Comment gérer ce cas ?
    On va faire un peu de montage, façon lego ou puzzle...

    On commence par modéliser les assurés en tant que tels : un assuré peut être une personne quelconque, souscrivant au moins un contrat :





    Les propriétés spécifiques des assurés (date de naissance, etc.) figurent dans l’entité-type ASSURE. ASSURE est une entité-type faible, c'est-à-dire qu’elle n’a de sens que par rapport à l’entité-type PERSONNE, dont elle hérite de l’identifiant num_personne, identifiant que l’on n’a donc pas à rappeler dans ASSURE.

    Techniquement parlant, identifier ASSURER relativement à PERSONNE s’avère un peu compliqué, aussi je vous renvoie à l’annexe ci-dessous « Modélisation d’une association [A]--0,1--(R)--1,1--[B] avec identification relative » pour que vous ne perdiez pas trop de temps.


    MLD produit par DB-MAIN à partir du MCD ci-dessus :





    La table TCONTRAT est dotée d’un attribut num_personne, faisant l’objet d’une clé étrangère {num_personne} référençant la table ASSURE, qui est aussi dotée d’un attribut num_personne, faisant à son tour l’objet d’une clé étrangère {num_personne} référençant la table PERSONNE.


    Passons aux professionnels : producteurs, apporteurs, courtiers. On va donc procéder à leur spécialisation, c'est-à-dire à la spécialisation de certaines personnes, en producteurs et non producteurs. On définit donc deux sous-types : PRODUCTEUR et NON_PRODUCTEUR. Dans le triangle de connexion du trio PERSONNE, PRODUCTEUR, NON_PRODUCTEUR, on signifie que les sous-types sont exclusifs, disjoints (lettre « D »), mais il n’y a pas de contrainte de totalité (donc de partitionnement), pour tenir compte du fait que les assurés ne sont pas tous des professionnels de l’assurance (cas par exemple de mademoiselle Castafiore, artiste lyrique) :





    A titre d’exemple, le sous-type PRODUCTEUR est porteur d’un attribut matricule, parce qu’il s’agit de quelqu’un de l’entreprise (en supposant que l’on ait besoin de cette information).

    Dans la mesure où les non producteurs ne font pas partie de l’entreprise (ou, s’ils en font partie, en supposant qu’on ne s’intéresse pas à cette information), le matricule est absent du sous-type NON_PRODUCTEUR.

    Dan un deuxième temps, on spécialise les non producteurs (chacun avec ses propriétés propres, par exemple agrément, carte professionnelle) :





    En rassemblant le pièces du puzzle :





    En notant, conformément à votre MCD, qu’un contrat est souscrit par au moins un et au plus un assuré, que ce contrat est souscrit auprès d’au moins un et au plus un courtier, que ce contrat est apporté par au moins un et au plus un apporteur, et qu’il est produit par au moins un et au plus un producteur.


    Annexe : Modélisation d’une association [A]--0,1--(R)--1,1--[B] avec identification relative.

    Partons du diagramme :





    Le but de la manoeuvre est d’identifier ASSURE, non pas de façon absolue, mais relative à PERSONNE :





    L’entité-type ASSURE n’a pas d’identifiant propre, elle hérite de celui de l’entité-type PERSONNE, ce qui symbolisé dans le schéma sous la forme « id:EST_ASSUREE.PERSONNE ».

    Techniquement, ça devrait être quelque chose de facile à modéliser, comme ça l’est par exemple dans le cas de PowerAMC (où l’identification relative est symbolisée par la mise entre parenthèses de l’identifiant 1,1) :





    Mais DB-MAIN les choses ne sont pas aussi simples, l’AGL exige que côté PERSONNE, la cardinalité maximale soit N, donc par la force des choses que l’entité-type ASSURE soit dotée d’un identifiant.

    On va donc procéder ainsi : remplacement provisoire de 0,1 par 0,N (patte connectant PERSONNE et EST_ASSUREE), et ajout dans ASSURE d’un attribut X, bidon et provisoire, que l’on rend identifiant :





    Dans l’entité-type ASSURE, on fait un clic gauche sur « id: X », de manière à ouvrir la fenêtre « Property box » qui va bien :





    Un clic dans « components » => apparition d’un symbole :





    Un clic sur => ouverture de la fenêtre « Multiple choice dialog » :





    On sélectionne « r:EST_ASSUREE.PERSONNE », puis on clique sur « Add First ». Au résultat :





    On fait « OK ». Au résultat, l’entité-type ASSURE a pour identifiant la paire {r:EST_ASSUREE.PERSONNE, X} c'est-à-dire que cette entité-type est bien identifiée relativement à l’entité-type PERSONNE.





    Suite à quoi, le diagramme devient le suivant :





    On peut maintenant remplacer 0,N par 0,1 et supprimer l’attribut X, DB-MAIN n’y voit pas d’inconvénient :





    Comme dit l’autre, « Ben dis-donc ! Tout ça pour ça ! »


    MLD correspondant :





    Code SQL (MySQL) produit par DB-MAIN :

    
    create table PERSONNE (
         num_personne int not null,
         nom_personne varchar(32) not null,
         tel_personne char(10) not null,
         constraint ID_PERSONNE primary key (num_personne));
    
    create table ASSURE (
         num_personne int not null,
         date_naissance date not null,
         constraint FK_EST_ASSUREE_ID primary key (num_personne));
    
    alter table ASSURE add constraint FK_EST_ASSUREE_FK
         foreign key (num_personne)
         references PERSONNE (num_personne);
    
    

    Et voilà le travail.


    Pour cette partie, se rapproche-t-on du MCD qui convient ?
    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 »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  17. #37
    Membre régulier
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    décembre 2013
    Messages
    127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Guinée

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Associations - ONG

    Informations forums :
    Inscription : décembre 2013
    Messages : 127
    Points : 75
    Points
    75

    Par défaut Proposition d'un model conceptuel de donnée MCD

    Bonsoir!
    Je reviens vers vous pour vous donner les explications suivantes:
    1) Un SOUSCRIPTEUR peut ne pas être un ASSURE ;
    2) Un ASSURE ne peut pas être à la fois PRODUCTEUR et ASSURE (ici un ASSURE, s’il est
    3) PRODUCTEUR ne peut pas produire (faire) son propre contrat d’assurance, il faut une autre personne pour faire son contrat et lui signe en tant que SOUSCRIPTEUR et ASSURE);
    4) Un PRODUCTEUR peut être SOUSCRIPTEUR et ASSURE mais il ne peut pas être PRODUCTEUR,
    SOUSCRIPTEUR et ASSURE à la fois car son contrat doit être fait par une autre personne différente de lui-même ;
    5) Un COURTIER peut être ASSURE mais n’a plus droit en ce moment à une commission donc il perd la fonction de COURTIER (il est en ce moment un simple ASSURE) ;
    6) Un COURTIER ne peut pas être un PRODUCTEUR (il est un simple intermédiaire entre l’ASSURE et l’ASSUREUR) ;
    7) Un COURTIER peut ne pas être un SOUSCRIPTEUR (par exemple envoyé son client dans une agence pour souscrire le contrat) ;
    8) Un APPORTEUR peut être un SOUSCRIPTEUR ;
    9) Un APPORTEUR peut être un ASSURE en ce moment il est un simple ASSURE, il n’a plus droit à une commission ou prime sur ce contrat ;
    10) Un ASSURE est une personne qui bénéficie l’assurance ou qui a sa voiture assurée (qui a son nom sur la carte grise de la voiture assurée);
    11) Un PRODUCTEUR est une personne qui produit ou fait le contrat (qui produit et signe le contrat d'assurance au nom de la société d'assurance) ;
    12) Un COURTIER est une personne qui est intermédiaire entre l’ASSURE et l’ASSUREUR (la société d’assurance ou une personne qui a les agréments de courtage qui peut aussi avoir un cabinet de courtage) ;
    13) Un CONTRAT est un document dans lequel existe les différents règlements entre l’ASSURE et l’ASSUREUR remis à l’ASSURE pour lui valoir ce que de droit (c'est dans ce contrat qu'il existent les garanties que l'assuré accepte ou pas);
    14) Un APPORTEUR est celui qui n’a pas de document juridique lui permettant d’ouvrir un cabinet de courtage donc un simple professionnel (il apporte aussi les affaires et il est aussi intermédiaire entre l'assuré et l'assureur mais différent d'un courtier) ;
    15) Un SOUSCRIPTEUR est une personne qui signe le contrat d’assurance et qui paye le montant de (l’assurance) la prime à la caisse (il peut être une personne envoyée par l'assuré ou l'assuré lui-même ou autre).
    J'aimerais d'après mes analyses qu'on modélise conformément à mes renseignements ci-dessus si encore vous trouvez l'ajout d'une table personne est nécessaire alors je tiendrai compte.
    Au niveau des adresses, on en parlera plus tard quand ce cas fini.
    J'ai fait certaines modifications par rapport à ID, vous pouvez aussi vérifier à travers la pièce jointe.
    Excusez moi de mes fautes.
    Merci infiniment par avance.
    Fichiers attachés Fichiers attachés

  18. #38
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

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

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 774
    Points
    18 774
    Billets dans le blog
    15

    Par défaut Evolution du puzzle...

    Bonsoir Zizoua,


    Entité-type ASSURE : vous avez défini un identifiant id_massure. Mais un identifiant ne doit pas être significatif, il ne doit donc pas être défini par l’utilisateur, ni contrôlé par celui-ci : en conséquence, il faut ajouter un identifiant alternatif, le numéro d’assuré défini par l’assureur et dont celui-ci fait ce qu’il veut.

    Evitez de préfixer le nom des entités-types par la lette « T », ça a une connotation dont on doit se passer au niveau supérieur (modèle conceptuel).

    Entité-type CONTRAT : mêmes remarques. Ne confondons pas le numéro de contrat et l’identifiant du contrat.

    Ces remarques valent pout toutes les entités-types. En passant, concernant la lettre « T », vous m’objecterez peut-être qu’elle permet de repérer visuellement une table au stade SQL : mais alors pourquoi ne pas avoir ajouté cette lettre en tête des noms des associations donnant lieu à des tables, telles que EST_SOUSCRIT, etc. ?



    Citation Envoyé par Zizoua
    (5) Un COURTIER peut être ASSURE mais n’a plus droit en ce moment à une commission donc il perd la fonction de COURTIER (il est en ce moment un simple ASSURE) ;
    Du point de vue de l’application, si une personne exerce bien la fonction de courtier, c’est qu’elle n’est pas assurée chez vous. Comme elle ne peut pas être non plus apporteur (cf. votre message #32) ou producteur, on peut conclure qu’elle n’est pas souscripteur.


    Citation Envoyé par Zizoua
    (9) Un APPORTEUR peut être un ASSURE en ce moment il est un simple ASSURE, il n’a plus droit à une commission ou prime sur ce contrat ;
    Autrement dit, si un apporteur est un assuré, je suppose qu’il perd la fonction d’apporteur s’il l’a déjà, auquel cas on peut dire plus généralement que quelqu’un ne peut pas être connu comme étant à la fois à la fois apporteur et assuré : êtes-vous d’accord avec cette règle ?


    si oui, un MCD pourrait être celui-ci :






    Sinon, précisez bien les règles, afin qu’on trouve une alternative.

    Vous observerez que du point de vue du MCD, un producteur peut aussi être connu en tant qu’assuré : pour respecter la règle : « un producteur ne peut pas produire (faire) son propre contrat d’assurance », on mettra en œuvre la contrainte qui va bien au niveau SQL (cf. la contrainte CONTRAT_CHK01 ci-dessous).



    Citation Envoyé par Zizoua
    Un ASSURE ne peut pas être à la fois PRODUCTEUR et ASSURE (ici un ASSURE, s’il est
    Comment se termine cette phrase ?



    Citation Envoyé par Zizoua
    PRODUCTEUR ne peut pas produire (faire) son propre contrat d’assurance
    Si on utilise la spécialisation des personnes, pour garantir cette règle, avec MS SQL Server, il suffit d’ajouter une contrainte pour la table CONTRAT (contrainte CONTRAT_CHK01 ci-dessous), sinon on ne sait pas faire :

    
    CREATE TABLE CONTRAT 
    (
         id_police             INT  IDENTITY   NOT NULL,
         num_police            CHAR(12)        NOT NULL,
         date_effet            DATE            NOT NULL,
         id_assure             INT             NOT NULL,
         id_producteur         INT             NOT NULL,
         CONSTRAINT CONTRAT_PK PRIMARY KEY (id_police),
         CONSTRAINT CONTRAT_AK UNIQUE (num_police),
         CONSTRAINT CONTRAT_CHK01 CHECK (id_assure <> id_producteur)
    );
    
    INSERT INTO CONTRAT (num_police, date_effet, id_assure, id_producteur) VALUES ('A047-2016-03', '2016-03-01', 12, 12) ; 
    
    
    =>

    Msg 547, Level 16, State 0, Line 16
    The INSERT statement conflicted with the CHECK constraint "CONTRAT_CHK01".



    Citation Envoyé par Zizoua
    si encore vous trouvez l'ajout d'une table personne est nécessaire alors je tiendrai compte.
    Sans l’entité-type PERSONNE, sa spécialisation et les contraintes de partitionnement, par exemple on ne sait pas empêcher qu’un courtier en exercice soit en même temps assuré chez vous, qu’il soit producteur, qu’un producteur soit en même temps apporteur, etc.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    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. #39
    Membre régulier
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    décembre 2013
    Messages
    127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Guinée

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Associations - ONG

    Informations forums :
    Inscription : décembre 2013
    Messages : 127
    Points : 75
    Points
    75

    Par défaut Proposition d'un model conceptuel de donnée MCD

    Bonjour!
    fsmrel
    Entité-type ASSURE : vous avez défini un identifiant id_massure. Mais un identifiant ne doit pas être significatif, il ne doit donc pas être défini par l’utilisateur, ni contrôlé par celui-ci : en conséquence, il faut ajouter un identifiant alternatif, le numéro d’assuré défini par l’assureur et dont celui-ci fait ce qu’il veut.
    Merci pour la remarque par rapport au nom id_massure dont j'ai changé en id_assure, mais ma question est de savoir sur un identifiant alternatif, comment voulez-vous que je défini cet identifiant?
    Evitez de préfixer le nom des entités-types par la lette « T », ça a une connotation dont on doit se passer au niveau supérieur (modèle conceptuel).
    J'ai mis cela pour différencier les noms des tables et certains attributs ou noms des tables.
    Ces remarques valent pour toutes les entités-types. En passant, concernant la lettre « T », vous m’objecterez peut-être qu’elle permet de repérer visuellement une table au stade SQL : mais alors pourquoi ne pas avoir ajouté cette lettre en tête des noms des associations donnant lieu à des tables, telles que EST_SOUSCRIT, etc. ?
    Comment voulez-vous ajouter cette lettre en tête des associations?
    (
    5) Un COURTIER peut être ASSURE mais n’a plus droit en ce moment à une commission donc il perd la fonction de COURTIER (il est en ce moment un simple ASSURE) ;
    Du point de vue de l’application, si une personne exerce bien la fonction de courtier, c’est qu’elle n’est pas assurée chez vous. Comme elle ne peut pas être non plus apporteur (cf. votre message #32) ou producteur, on peut conclure qu’elle n’est pas souscripteur.
    Non, une personne qui est courtier peut être assuré chez nous mais il n'a plus droit à une commission sur son contrat d'assurance, il est un simple courtier. En d'autre terme, un courtier est un apporteur d'affaire mais il n'est pas un apporteur dans le sens d'utilisation dans les assurances, ici c'est quelqu'un qui a un agrément pas un apporteur simple qui n'a pas d'agrément mais une carte professionnelle. Ils peuvent être tous des souscripteurs (un courtier, apporteur, ou producteur peuvent être des souscripteur).
    (9) Un APPORTEUR peut être un ASSURE en ce moment il est un simple ASSURE, il n’a plus droit à une commission ou prime sur ce contrat ;
    Autrement dit, si un apporteur est un assuré, je suppose qu’il perd la fonction d’apporteur s’il l’a déjà, auquel cas on peut dire plus généralement que quelqu’un ne peut pas être connu comme étant à la fois à la fois apporteur et assuré : êtes-vous d’accord avec cette règle ?
    si oui, un MCD pourrait être celui-ci :
    Oui, un apporteur ne peut pas être à la fois apporteur et assuré. D'après votre schéma, je voudrais savoir les association, cardinalités et identifiant entre les tables suivantes: (Assure, Non_apporteur), (producteur, non_apporteur), (non_apporteur, souscripteur), (apporteur, souscripteur), (souscripteur, personne), (courtier, personne)?
    Un ASSURE ne peut pas être à la fois PRODUCTEUR et ASSURE (ici un ASSURE, s’il est
    Comment se termine cette phrase ?
    Voici ce que je voudrais dire: 2) Un ASSURE ne peut pas être à la fois PRODUCTEUR et ASSURE (ici un ASSURE, s’il est
    PRODUCTEUR, il ne peut pas produire (faire) son propre contrat d’assurance, il faut une autre personne pour faire son contrat et lui signe en tant que SOUSCRIPTEUR et ASSURE);
    Avec la pièce jointe, vous donnerez votre avis.
    Merci infiniment pour votre contribution.
    Une fois de plus merci à l'avance.
    Fichiers attachés Fichiers attachés

  20. #40
    Membre régulier
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    décembre 2013
    Messages
    127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Guinée

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Associations - ONG

    Informations forums :
    Inscription : décembre 2013
    Messages : 127
    Points : 75
    Points
    75

    Par défaut Proposition d'un model conceptuel de donnée MCD

    Bonjour!
    Je vous donne plus d'explication dans ma phrase suivante:
    Oui, un apporteur ne peut pas être à la fois apporteur et assuré.
    Si un apporteur vient pour assuré sa voiture, il n'aura plus de commission sur son contrat d'assurance. Il devient en ce moment un simple assuré raison pour laquelle que je dis "oui un apporteur ne peut pas être à la fois apporteur et assuré sinon en d'autres termes il peut l'être.
    D'après votre schéma, je voudrais savoir les association, cardinalités et identifiant entre les tables suivantes: (Assure, Non_apporteur), (producteur, non_apporteur), (non_apporteur, souscripteur), (apporteur, souscripteur), (souscripteur, personne), (courtier, personne)?
    Une fois de plus merci pour votre aide.

Discussions similaires

  1. realisation modele conceptuel
    Par gui-llaume dans le forum Schéma
    Réponses: 3
    Dernier message: 18/10/2007, 15h18
  2. Réponses: 1
    Dernier message: 01/10/2007, 16h14
  3. Définition modèle organisationnel vs modele conceptuel
    Par L'aigle de Carthage dans le forum Schéma
    Réponses: 6
    Dernier message: 26/06/2007, 01h18
  4. modele conceptuel avec sql server 2005
    Par sundjata dans le forum MS SQL-Server
    Réponses: 3
    Dernier message: 29/10/2006, 09h10

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