Version imprimable
Bonjour!
Je viens très respectueusement ce matin pour demander votre avis par rapport à mon MCD d'une société d'assurance voyage.
Voici le MCD par pièce jointe:
Pièce jointe 215744
Je vous remercie par avance de vos aides sans cesse.
Merci infiniment.
Bonsoir!
Je reviens pour vous donner plus d'explication.
Je veux faire le MCD d'une petite entreprise d'assurance voyage.
L'entreprise possède les informations suivantes sur l'imprimé autocarbonné qui une partie sera remis au client et une partie reste dans la boîte.
Voici les information figurant sur l'imprimé:
1- N° Police...........;
2- Souscripteur.........;
3- Beneficiaire..........;
4- Adresse...............;
5- Date de naissance.........;
6- N° Passeport...........;
7- Durée/Sejour garantie...........;
8- Pays de destination...........;
9- Prime ttc.................
Et ensuite la date du jour de production du contrat, écrite comme suit:
10- ..../../....
Les clients voyagent dans beaucoup de pays, chaque pays a un tarif qui peut ne pas être identique à d'autres pays.
Aussi, si un client à un âge avancé, il paye un tarif complémentaire que les autres, quelque soit le pays de destination.
Dans cette situation, nous voulons que les polices soient données par an et renouvelable pour l'année prochaine et peut être remis à d'autre clients car le retour d'un client pour autre ou même pays ne demande pas d'avenant. Ensuite les agences ont un code chacun de trois chiffres qui leur permet d'être identifié.
NB: le cas de l'avenant ici, c'est quand il y a annulation de voyage et remboursement et de report ou bien quand la date de voyage est reportée ultérieurement.
Merci pour la compréhension.
Une fois de plus merci par avance.
Bonjour Zizaoua
Vous devriez communiquer vos règles de gestion, sous la forme (exemple)
- R001 un assuré est une personne ayant souscrit au moins un contrat
- R002 un contrat concerne un et un seul pays de destination
- R003 un client est un ?
etc..
C'est notamment cette remarque qui justifie la rédaction des règles de façon exhaustive, carCitation:
Envoyé par Zizoua
- le client n'apparait pas dans votre MCD, Est-ce un synonyme de l'assuré ?
- au vu de vos cardinalités, si un assuré va dans beaucoup de pays, il doit souscrire autant de contrats que de pays destinataires, Est-ce bien ce que vous voulez ?
Est-ce ce qui a motivé la relation CTR_avenant entre "pays" et avenant"Citation:
Envoyé par Zizoua
Cette partie concerne essentiellement les traitements, puisque vous avez déjà la date dans le contrat (qui est je suppose un synonyme de police, à préciser aussi), le MCD est OK de ce point de vueCitation:
Envoyé par Zizoua
Fort bien, mais vous n'avez pas modélisé l'agence, c'est probablement un acteur important dans votre modèle, à identifier en ce casCitation:
Envoyé par Zizoua
Et quelques remarques d'ordre général
- l'usage est d'utiliser des verbes, le plus souvent à l'infinitif, pour identifier les associations. Par exemple Contrat 1,n ---- souscrire ---- 1,n garantie
- "caissière" est assez restrictif comme choix de nom, seules les femmes sont autorisées à ce poste ? ;)
- vous devriez sortir l'adresse de l'entité-type assuré, ca présente de nombreux avantages (éviter les colonnes nulles, permettre de gérer plusieurs adresses, de les typer etc...)
- idem si vous gérez des n° de téléphone, des adresses courriel et autres moyens de contact, faites en des entité-type particulières, que vous mettrez en relation avec les entités-types concernées (les agents, les assurés, etc...)
- comme mentionné plus haut, évitez les synonymes, si toutefois ils sont fréquemment utilisés dans le métier, alors définissez les, s'il y a des différences entre les termes utilisés, précisez les, chaque équivoque étant une source d'erreur potentielle.
Bonsoir!
Merci beaucoup Monsieur escartefigue!
La règle de gestion est la suivante:
-R1: un assuré est une personne ayant souscrit au moins un contrat
-R2: Un contrat appartient à une et une seule personne
-R3: Un contrat concerne un et un seul pays
-R4: Un pays peut être concerné par zéro(0) contrat ou plusieurs
-R5: Un contrat est fait dans une et une seule agence
-R6: Une Agence fait au moins un contrat ou plusieurs
-R7: Une Agence peut faire zéro(0) avenant ou plusieurs
-R8: Un avenant est fait dans une et une seule agence
-R9: Un avenant ne dépend que d'un et un seul pays
-R9: Un pays peut avoir zéro avenant ou plusieurs
-R10: Un pays a un et un seul tarif
-R11: Un tarif appartient au minimum a un et au maximum a plusieurs pays
-R12: Un tarif peut avoir zéro historique ou plusieurs
-R13: Un contrat peut ne pas être payé ou payé plusieurs fois
-R14: Une caisse peut avoir au moins un payement ou plusieurs
-R15: Un payement concerne un et un seul type de payement
-R16: Un avenant concerne un et un seul type d'avenant
-R17: Un type d'avenant peut avoir zéro avenant ou plusieurs
-R18: Un historique concerne un et un seul tarif
Pièce jointe 216153
Merci pour vos remarques.
Voici les modifications ci-dessus.
Une fois de plus merci.
NB: entre avenant et pays, je devrais mettre est concerner
Bonjour,
Quelques questions et remarques supplémentaires
R13: Un contrat peut ne pas être payé ou payé plusieurs fois : je suppose que plusieurs fois correspond à un paiement échelonné, par exemple mensuel, Est-ce que le type de paiement correspond à cette notion ?
La relation "est payé" (un verbe, par exemple "regler", serait préférable) ne devrait elle pas inclure un attribut matérialisant l'instrument de paiement (par cheque, carte, traite, virement etc...)
On ne voit aucune relation entre "caisse" est "agence", est-normal ?
Est-ce que n'importe quelle caisse peut encaisser le paiement de n'importe quel contrat, ou au contraire, une caisse ne peut encaisser que le paiement d'un contrat souscrit dans l'agence dont la caisse dépend (souos réserve qu'une caisse dépende d'une agence, d'où ma question précédente)
R8: Un avenant est fait dans une et une seule agence, ok, mais Est-ce que les différents avenants d'un même contrat, peuvent être faits dans différentes caisses
Pouvez vous expiquer ce que sont les attributs "age maximum" et "montant supplementaire" de l'entité type "assuré"
Pensez à sortir l'adresse de l'entité-type assuré
Pensez aussi à utiliser des verbes pour nommer les associations, par exemple
AGENCE 1,n --- ETABLIR --- 1,1 CONTRAT
CONTRAT 0,n --- INCLURE --- 1,1 AVENANT
Un avenant n'a pas d'existence sans le contrat auquel il se rapporte, aussi, je vous propose d'identifier l'avenant relativement au contrat.
Comme vous utilisez DB-MAIN, je vous invite à consulter le billet de Fsmrel sur ce sujet : http://www.developpez.net/forums/blo...tion-relative/
Bonjour!
Je reviens pour vous montrer les modifications que j'ai faites sur mon MCD.
Pièce jointe 216289
Monsieur ESCARFIGUE
Plusieurs fois signifie par exemple : semaine, mois ou année, le type de paiement correspond par : espèce, chèque, virement bancaire…Citation:
R13: Un contrat peut ne pas être payé ou payé plusieurs fois : je suppose que plusieurs fois correspond à un paiement échelonné, par exemple mensuel, Est-ce que le type de paiement correspond à cette notion ?
Le verbe ‘’régler’’ serait préférable et ensuite pour éviter qu’on se trompe au moment de la saisie, j’ai préféré mettre une entité ’’ type_reglement’’ ou ‘’type_paiement’’.Citation:
La relation "est payé" (un verbe, par exemple "regler", serait préférable) ne devrait elle pas inclure un attribut matérialisant l'instrument de paiement (par cheque, carte, traite, virement etc...)
Non, voici ce que je viens d’apporter comme modification.Citation:
On ne voit aucune relation entre "caisse" est "agence", est-normal ?
Relation entre agence et caisse : Une agence peut avoir une caisse au minimum ou plusieurs au maximum(2) (par exemple à l’agence principale, celui ou celle qui encaisse les montants pour l’assurance automobile n’est pas celui ou celle qui encaisse les montants pour l’assurance voyage).
Non, une caisse n’encaisse que le contrat fait dans l’agence à laquelle elle se trouve d’où mes modifications précédentes.Citation:
Est-ce que n'importe quelle caisse peut encaisser le paiement de n'importe quel contrat, ou au contraire, une caisse ne peut encaisser que le paiement d'un contrat souscrit dans l'agence dont la caisse dépend (souos réserve qu'une caisse dépende d'une agence, d'où ma question précédente)
Non, oui (non pas toutes les agences, oui dans l’agence principale seulement)Citation:
R8: Un avenant est fait dans une et une seule agence, ok, mais Est-ce que les différents avenants d'un même contrat, peuvent être faits dans différentes caisses?
Selon ce qui est dans le contrat, si un assuré à un âge de 62 ans ou plus, il est frappé par une augmentation de sa prime d’assurance à un montant ‘’X’’ supplémentaire raison pour laquelle j’ai ajouté les cases age_maximum et montant_supplementaire.Citation:
Pouvez vous expliquer ce que sont les attributs "age maximum" et "montant supplémentaire" de l'entité type "assuré"
Pensez à sortir l'adresse de l'entité-type assuré.
Merci, mais je voudrais qu’on finisse avec cette partie après j’ai pensé à l’historique de cette entité que je vais vous demandé plus tard. Ensuite c’est l’adresse qui se trouve sur le passeport qu’on met sur le contrat.
Merci pour votre remarque.Citation:
Pensez aussi à utiliser des verbes pour nommer les associations, par exemple
AGENCE 1,n --- ETABLIR --- 1,1 CONTRAT
CONTRAT 0,n --- INCLURE --- 1,1 AVENANT
Pouvez vous me donner plus d’explication sur le sujet car je n’ai vraiment pas compris?Citation:
Un avenant n'a pas d'existence sans le contrat auquel il se rapporte, aussi, je vous propose d'identifier l'avenant relativement au contrat.
Comme vous utilisez DB-MAIN, je vous invite à consulter le billet de Fsmrel sur ce sujet :
Avez-vous d’autres remarques et suggestions ?
Merci une fois de plus de vos soutiens.
Merci infiniment.
C'est déjà plus clair :)
Ces nouvelles règles sont très importantes, elles feront l'objet de Contraintes d'Intégrité Fonctionnelle (CIF), que l'on pourra voir dans un 2ème tempsCitation:
Envoyé par Zizoua
Il faut donc définir ce qu'est une agence principale et quelles sont ses relations avec les autres acteurs de votre schémaCitation:
Envoyé par Zizoua
Du coup, ce ne sont pas des attributs mais des données calculéesCitation:
Envoyé par Zizoua
Puisque vous avez la date de naissance de l'assuré, il ne faut pas de colonne supplémentaire pour mentionner son âge, ce serait une redondance
(sauf à utiliser éventuellement une colonne calculée par le SGBD, à voir au niveau du MPD le cas échéant)
Quant au montant supplémentaire, ce sera une conséquence au niveau traitement, de l'age en fonction du type de contrat. Hors MCD donc
L'identification relative est une technique d'identification utilisée quand l'entité concernée, dite entité faible, ne peut pas avoir d'existence seule, sans l'entité dite forte à laquelle elle est rattachée.Citation:
Envoyé par Zizoua
C'est le cas de l'avenant qui ne peut exister sans contrat.
Si vous utilisez l'identification relative vous aurez par exemple pour le contrat identifié 0015 deux avenants, dont les identifiants seront 0015-001 et 0015-002.
L'identifiant de l'avenant inclut donc celui du contrat
si vous n'utilisez pas l'identification relative, les avenants dans le même exemple seront simplement numérotés 001 et 002
L'intérêt de l'identification relative est multiple :
- elle permet d'optimiser les accès futurs à la base de données car les informations seront physiquement stockées à des emplacements proches sur l'espace disque, grâce à une racine identifiante identique
- elle facilite la mise en œuvre de l'intégrité référentielle, puisque la suppression de l'entité forte, ici le contrat, permettra de supprimer automatiquement les occurrences d'entité faibles, les avenants.
Merci.Citation:
Relation entre agence et caisse : Une agence peut avoir une caisse au minimum ou plusieurs au maximum(2) (par exemple à l’agence principale, celui ou celle qui encaisse les montants pour l’assurance automobile n’est pas celui ou celle qui encaisse les montants pour l’assurance voyage).
Non, une caisse n’encaisse que le contrat fait dans l’agence à laquelle elle se trouve d’où mes modifications précédentes.
Ces nouvelles règles sont très importantes, elles feront l'objet de Contraintes d'Intégrité Fonctionnelle (CIF), que l'on pourra voir dans un 2ème temps.
Ici j'ai mis une entité type_agence pour identifier une agence principale et secondaire.Citation:
Non, oui (non pas toutes les agences, oui dans l’agence principale seulement)
Il faut donc définir ce qu'est une agence principale et quelles sont ses relations avec les autres acteurs de votre schéma.
Voir mon MCD corriger.
Selon ce qui est dans le contrat, si un assuré à un âge de 62 ans ou plus, il est frappé par une augmentation de sa prime d’assurance à un montant ‘’X’’ supplémentaire raison pour laquelle j’ai ajouté les cases age_maximum et montant_supplementaire.
Merci, mais on veut que la personne soit informée sur le montant total qu'elle doit payer à l'avance c'est à dire avant même de faire son contrat, selon vous comment peut on faire cela?Citation:
Du coup, ce ne sont pas des attributs mais des données calculées
Puisque vous avez la date de naissance de l'assuré, il ne faut pas de colonne supplémentaire pour mentionner son âge, ce serait une redondance (sauf à utiliser éventuellement une colonne calculée par le SGBD, à voir au niveau du MPD le cas échéant).
Le contrat est identique c'est à dire la prise en charge sanitaire, le rapatriement, de décès...Citation:
Quant au montant supplémentaire, ce sera une conséquence au niveau traitement, de l'age en fonction du type de contrat. Hors MCD donc
Mais le montant par rapport aux pays et l'âge avancé varie.
Citation:
Pouvez vous me donner plus d’explication sur le sujet car je n’ai vraiment pas compris?
Merci pour votre explication.Citation:
L'identification relative est une technique d'identification utilisée quand l'entité concernée, dite entité faible, ne peut pas avoir d'existence seule, sans l'entité dite forte à laquelle elle est rattachée.
C'est le cas de l'avenant qui ne peut exister sans contrat.
Si vous utilisez l'identification relative vous aurez par exemple pour le contrat identifié 0015 deux avenants, dont les identifiants seront 0015-001 et 0015-002.
L'identifiant de l'avenant inclut donc celui du contrat
si vous n'utilisez pas l'identification relative, les avenants dans le même exemple seront simplement numérotés 001 et 002
L'intérêt de l'identification relative est multiple :
- elle permet d'optimiser les accès futurs à la base de données car les informations seront physiquement stockées à des emplacements proches sur l'espace disque, grâce à une racine identifiante identique
- elle facilite la mise en œuvre de l'intégrité référentielle, puisque la suppression de l'entité forte, ici le contrat, permettra de supprimer automatiquement les occurrences d'entité faibles, les avenants
Regardez mon MCD ci-dessous:
Pièce jointe 216334
Avez-vous d'autres remarques et suggestions?
Merci infiniment pour votre soutient.
Bonjour,
En relisant votre MCD, j'ai encore quelques remarques :
- vos règles R9 (il y en avait 2 avec le même code) sont inutiles. En effet, un avenant ne concerne qu'un et un seul contrat, et un contrat ne concerne qu'un et un seul pays. Du coup, par transitivité, un avenant ne concerne qu'un et un seul pays, la relation "concerner" entre "pays" et "avenant" peut donc être supprimée ce qui simplifiera votre schéma ;)
- il me semble que vous devriez modifier la cardinalité minimale (1,n devenant 0,n) de "Agence" vers "établir", car on peut imaginer qu'une nouvelle agence n'ait pas encore établi de contrat
- même remarque entre "caisse" et "régler"
- une petite faute d'orthographe à corriger dans la relation "conserver" (entre tarif et historique).
Concernant votre question
Merci, mais on veut que la personne soit informée sur le montant total qu'elle doit payer à l'avance c'est à dire avant même de faire son contrat, selon vous comment peut on faire cela?
Vu que le tarif est lié à la fois au pays et à l'âge, vous devrez prévoir un traitement qui pourra récupérer le tarif du pays concerné par le contrat, et, en fonction de la date prévue de début de validité du contrat et de la date de naissance de l'assuré, calculer le tarif qui sera applicable au moment de l'entrée en vigueur du contrat (sous réserve qu'il n'y ait pas d'évolution tarifaire d'ici là bien sur)
Donc rien à ajouter dans le MCD, supprimez les 2 attributs inutiles "age_maxi" et "montant_supplémentaire", le traitement aura tous les éléments requis avec ce que vous avez déjà prévu dans le MCD :P
Bonjour!
Merci Monsieur ESCARTFIGUE pour vos précédentes réponses, je viens de faire les modifications et demande une proposition.
Pour ce qui concerne l'historique, voici mes propositions suivantes:
Nous voulons qu’à la fin de chaque année, on rase la base de données (c'est-à-dire remettre les anciennes polices aux nouveaux assurés) pour cela, je voudrais créer les historiques pour les entités suivantes : Contrat, Assuré et Avenant. De la manière suivante :
Pièce jointe 216416
Cela est elle bonne et quels sont les attributs à historier ?
Il y a-t-il des conséquences à cette situation ou des avantages ?
Quels sont vos avis et suggestions sur mon MCD ?
NB : J’ai mis les historiques pour savoir les temps à venir, quelles sont les productions par agence par an et les assurés de ce temps et ensuite les numéros de police de ces assurés et éventuellement s’il y a avenant, savoir quelle police il était attribué et pourquoi ?
J'ai aussi oublié de supprimer l'âge_maximum et le Montant_supplémentaire, vous pouvez laisser, je tiens compte et fait dans mon schéma
Merci infiniment pour votre soutien sans cesse.
Bonjour!
Merci Monsieur ESCARTFIGUE pour vos précédentes réponses, je viens de faire les modifications et demande une proposition.
Pour ce qui concerne l'historique, voici mes propositions suivantes:
Nous voulons qu’à la fin de chaque année, on rase la base de données (c'est-à-dire remettre les anciennes polices aux nouveaux assurés) pour cela, je voudrais créer les historiques pour les entités suivantes : Contrat, Assuré et Avenant. De la manière suivante :
Pièce jointe 216416
Cela est elle bonne et quels sont les attributs à historier ?
Il y a-t-il des conséquences à cette situation ou des avantages ?
Quels sont vos avis et suggestions sur mon MCD ?
NB : J’ai mis les historiques pour savoir les temps à venir, quelles sont les productions par agence par an et les assurés de ce temps et ensuite les numéros de police de ces assurés et éventuellement s’il y a avenant, savoir quelle police il était attribué et pourquoi ?
J'ai oublié laissé l'age_maximum et le montant_supplementaire mais j'en tiens compte car j'ai apporté les modifications nécessaires.
Merci infiniment pour votre soutien sans cesse.
HÉLAS CE SONT LES FAIBLES DÉBITS DE CONNEXION QUI FONT QU'IL Y A UNE MULTIPLICATION DE MESSAGE SANS SE RENDRE COMPTE.
CELA DÉCOURAGE LES INTERVENANTS, EXCUSEZ MOI.
Désolé mais j'ai du mal à comprendre le besoin pour plusieurs raisonsCitation:
Envoyé par Zizoua
- "raser" la base de données est un terme qui me surprend :D car très inhabituel dans la gestion des bases de données
- "police" est il synonyme de contrat (je le suppose mais il faut le confirmer, n'hésitez pas à enrichir vos règles de gestion pour mentionner les synonymes, par exemple
...-R2: Un contrat, aussi appelé "police", appartient à une et une seule personne
- pourquoi voulez vous remettre d'anciens contrats à de nouveaux assurés :weird:
- et enfin, vous parlez d'historiser mais les entit-type que vous avez modélisées sont très différentes de celles à historiser, du coup vous perdrez la quasi totalité des infos à historiser, j'avoue ne pas comprendre le but de tout ça
Ce sont aux experts métiers de répondre sur ce point. Il y a souvent des contraintes légales et certainement des contraintes internes à l'entrepriseCitation:
Envoyé par Zizoua
ll est donc essentiel que vos correspondants métier vous rédigent les règles d'archivage à prendre en compte : durée, contenu, mode de restitution de l'archive, délai maxi de mise à dispo, confidentialité, etc...
Sans ces instructions, vous ne pourrez pas répondre au "comment" archiver
Bonjour!
Merci encore Monsieur Escartefigue.
Avant tout, je viens d'apporter les modifications que vous m'avez demandé de faire.
Voici le MCD ci-dessous:
Pièce jointe 216468
Quelles sont vos remarques et suggestions?
Je voudrais vous dire de supprimer les Assurés, la police et l'Avenant pour revenir à l'état initial ces entités ainsi dès qu'il y a un nouveau Assuré, on lui remettrait une nouvelle police qui est aussi une police déjà donnée à un ancien Assuré.Citation:
Désolé mais j'ai du mal à comprendre le besoin pour plusieurs raisons
- "raser" la base de données est un terme qui me surprend car très inhabituel dans la gestion des bases de données
- "police" est il synonyme de contrat (je le suppose mais il faut le confirmer, n'hésitez pas à enrichir vos règles de gestion pour mentionner les synonymes, par exemple
...-R2: Un contrat, aussi appelé "police", appartient à une et une seule personne
- pourquoi voulez vous remettre d'anciens contrats à de nouveaux assurés
- et enfin, vous parlez d'historiser mais les entit-type que vous avez modélisées sont très différentes de celles à historiser, du coup vous perdrez la quasi totalité des infos à historiser, j'avoue ne pas comprendre le but de tout ça
En assurance voyage, un Assuré peut voyager pour longtemps ou aller revenir pour rester pendant des années sans voyager ou quand il revient, on lui remet un nouveau contrat pour le même pays ou autre raison pour laquelle on a voulu à la fin de chaque année réinitialisé le contrat, l'assuré et l'avenant pour repartir à zéro.
Que pensez vous?
Police est bien synonyme de contrat, c'est le jargon des assurances, ici la police est le numéro que l'on attribut aux assurés.
Merci infiniment pour votre soutien.
Une fois de plus merci par avance.
Dans votre cas, il ne faut donc pas supprimer physiquement les contrats puisque vous voulez pouvoir les recopier pour en créer de nouveaux
Il s'agira donc plutôt d'une annulation logique permettant de distinguer les contrats archivés de ceux en cours de validité.
Cela étant, je suis très réservé sur l'idée de créer un contrat (ou autre occurrence d'entité-type) par recopie d'un autre, surtout si ce n'est pas le même assuré
Les risques sont que les valeurs pré-remplies soient inadaptées, mais comme elles ont été vérifiées lors de la création du contrat d'origine que l'on a recopié, les contrôles sont OK mais les données sont incohérentes. Il me semble par expérience plus raisonnable de proposer un formulaire vierge pour forcer l'agent d'assurance à recueillir l'ensemble des éléments.
A la rigueur, prévoyez une possibilité de recopie, mais uniquement pour 2 contrats de type proche et qui concernent un même assuré par exemple
J'ai l'impression, mais peut être ai-je mal compris, que vous avez plutôt besoin de modèles de contrats type :
Quand un assuré souscrit un nouveau contrat, vous créez ce nouveau contrat à partir d'un modèle type
Quoi qu'il en soit, ces considérations sont de niveau traitement, donc prématurées à ce stade.
Bonsoir!
Merci Monsieur Escartefigue.
Les éléments qui peuvent varier au niveau Assuré sont les suivants :Citation:
vous devriez sortir l'adresse de l'entité-type assuré, ca présente de nombreux avantages (éviter les colonnes nulles, permettre de gérer plusieurs adresses, de les typer etc...)
idem si vous gérez des n° de téléphone, des adresses courriel et autres moyens de contact, faites en des entité-type particulières, que vous mettrez en relation avec les entités-types concernées (les agents, les assurés, etc...)
comme mentionné plus haut, évitez les synonymes, si toutefois ils sont fréquemment utilisés dans le métier, alors définissez les, s'il y a des différences entre les termes utilisés, précisez les, chaque équivoque étant une source d'erreur potentielle
L’Adresse et le numéro passeport car la personne peut changer l’adresse et de passeport si le passeport finit ou arrive à expiration. Avez-vous voulu que je crée une entité adresse ?
Avez-vous un schéma de proposition ?
Ensuite par rapport aux numéros, j’ai d’abord crée un numéro ‘’ id_’’ automatique ensuite j’ai crée un autre numéro ‘’num_’’ qui sert de vrai clé qui peut être changé par l’utilisateur.
Aussi sur les numéros de police, on doit donner un numéro à chaque agence qui leur permet d’être identifié suivit maintenant du numéro du client.
Exemple : si l’agence a le numéro : 311, les clients doivent avoir les numéros suivants :
3110001 pour le client n° 1 ;
3110002 pour le client n° 2 ;
3110003 pour le client n° 3 ;
3110004 pour le client n° 4 ;
Ainsi de suite.
Est elle une bonne façon de travailler ou avez-vous autre proposition ?
Merci infiniment pour vos soutiens.
Une fois de plus merci.
NB: pour précision, le numéro de police ou numéro de contrat doit être 7 chiffres, trois(3) pour les agences et les quatre(4) pour les assurés.
Bonjour,
Pour ce qui concerne l'externalisation des adresses, mais aussi des pièces justificatives, voici une proposition
Pièce jointe 216590
Vous noterez que j'ai mis 1,n de "justificatif", vers "fournir" pour le cas où deux membres d'une même famille, présentent le livret de famille comme justificatif d'identité
Je ne sais pas si ce cas se présente dans votre corps de métier, à vous d'adapter.
Le type de pièce justificatif c'est permis de conduire, carte d'identité, passeport etc...
Avec ce type de modèle, vous pouvez stocker plusieurs pièces d'identité ou justificatives (ex : certains pays exigent un document de l'autre parent si un enfant voyage avec un seul parent)
Pour le type adresse, ce peut être adresse de résidence, de correspondance, de villégiature ( à date) etc...
Vous pouvez faire de même pour les contacts (téléphone, courriel, fax etc...)
Concernant la numérotation
Comme il n'y a pas de lien direct entre assuré et agence, il ne faut pas utiliser l'identification relative pour associer le n° d'agence au numéro d'assuré
Le plus simple est d'avoir deux numérotations distinctes comme vous l'avez fait (les numéros fonctionnels) et de les associer par traitement en les concaténant sur les documents ou écrans
Glossaire et règles de gestion
Vous devriez définir les termes client, assuré, souscripteur et bénéficiaire.
L'entité-type assuré est identifiée par un id_souscripteur, du coup il semble que client, assuré et souscripteur soient une seule et même notion, il est préférable de n'en retenir qu'un vocable ou bien de préciser les rôles de chacun.
Si un contrat peut avoir plusieurs bénéficiaires, alors il faut créer une nouvelle entité-type "bénéficiaire" en lien avec l'assuré
Bonjour!
Ma question d'hier concernait les numéros de police ou contrat.
Voici la structuration voulu:
Aussi sur les numéros de police, on doit donner un numéro à chaque agence qui leur permet d’être identifié suivit maintenant du numéro du client.
Exemple : si l’agence a le numéro : 311, les clients doivent avoir les numéros suivants :
3110001 pour le client n° 1 ;
3110002 pour le client n° 2 ;
3110003 pour le client n° 3 ;
3110004 pour le client n° 4 ;
Ainsi de suite.
Pour ce qui concerne les numéros ''id_'' automatique, ils sont gérés par le la base de données tant dis que les numéros ''num_'' par les agents de saisie.
Ensuite ces numéros de police ou contrat sont de longueur(7) dont trois(3) comme identifiant de l'agence et quatre(4) comme identifiant des clients.
Est elle une bonne façon de travailler ou avez-vous autre proposition ?
Merci pour vos soutiens sans cesse.
Une fois de plus merci.
NB: C'est au moment que j'écrivais que vous avez répondu à l'une de mes questions, donc je vais relire attentivement.
Merci encore.
En plus regardez ma dernière question.
J'avais bien compris la question sur la numérotation et j'ai tenté d'y répondre, mais j'ai du être imprécis.
Puisque vous avez besoin à la fois du n° fonctionnel d'agence (3 digits) et du n° fonctionnel client (4 digits) pour enregistrer le n° de contrat
Vous devez enregistrer le contrat après avoir validé la création de l'agence et du client.
Votre contrat sera identifié techniquement par un chrono (Id) calculé par la base de données
Votre contrat sera identifié fonctionnellement par concaténation du n° agence et du n° client
Sauf que, cette numérotation vous interdit d'avoir plusieurs contrats pour un même client dans une même agence !
Or ce n'est manifestement pas ce que vous voulez, puisque vous avez pour règle de gestion :
R1: un assuré est une personne ayant souscrit au moins un contrat
Vous pouvez éventuellement utiliser n° d'agence + n° de client, à condition d'y ajouter un chrono contrat, pour rendre l'identifiant fonctionnel unique
Bonsoir!
Je vous remercie pour votre soutient.
Voici une proposition au niveau des adresses de mon MCD que je vous présente:
Pièce jointe 216663
A ce niveau, j'ai jugé que chaque assuré possède au minimum un(1) type d'adresse et au maximum plusieurs(n) et dans l'association posséder j'ai mis les attributs date_debut, numéro passeport, adresse et date_fin car ce numéro de passeport et l'adresse peuvent varier.
Comment trouvez vous cette proposition?
Merci encore pour votre aide.
NB: j'ai lu et compris votre proposition ci-dessus, merci aussi.
Bonjour Zizaoua,
Désolé mais votre version ne conviendra pas :
L'assuré ne possède pas des type-adresse mais des adresses
Et le n° de passeport n'est aucunement lié aux adresses, il ne doit donc pas être un attribut de la relation entre assuré et type-adresse
Reprenez le schéma que j'avais proposé dans mon post n°16
La partie pièces justificatives de mon schéma n'est pas forcément requise dans votre cas : si vous avez un et un seul document, conserver le n° de passeport dans l'entité-type Contrat est à la rigueur acceptable, même si d'un point de vue Merise ça reste une entorse aux règles de modélisation.
