Discussion :

[gautier1er]

Bonjour à tous .Je suis actuelement en stage et mon devoir c'est de créer une application de gestion de courrier d'un ministere .
les courriers departs et arrivés
Mon MCD est ci-dessous .J'aimerai avoir votre avis sur ça.
merci


cordialement

[escartefigue]

Bonjour,

Il manque vos règles de gestion, sans lesquelles on ne peut pas valider un MCD, les règles sont à rédiger sous la forme :
R001 : un agent appartient à un et un seul service
R002 : un service peut avoir un à plusieurs agents
etc...

Quelques remarques en vrac :
- Si on en croit votre MCD, un courrier au départ peut être expédié par plusieurs personnes très surprenant...
- Courrier au départ et en arrivée sont semblables, il faut donc modéliser une seule entité-type, et soit utiliser l'héritage si certains attributs sont spécifiques, soit ajouter un attribut permettant de les distinguer
- Qu'est ce que c'est que cette relation "écrire" à date entre "courrier départ" et "courrier arrivée" un courrier peut écrire un courrier ?
- Etes vous certain que un courrier en arrivée peut être traité par plusieurs agents ? si c'est bien le cas, il y a certainement plusieurs types de traitements à identifier (enregistrer le courrier, le diffuser au bon service, y répondre, le numériser etc...)
- A quoi sert le sous-type "Particulier", a priori inutile, par contre, il y a des personnes qui travaillent dans le ministère et qui sont concernées par les courriers mais qui ne sont pas des agents (les ministres, directeurs de cabinet, les adjoints, les secrétaires etc... or vous ne les avez pas modélisées
- Qu'est ce que c'est que la relation "Recevoir" a priori redondante avec "Traiter" car je ne pense pas que vous souhaitiez prendre en compte les courriers reçus par des particuliers , mais seulement ceux reçus par le ministère et donc traités par un agent du ministère
- Le choix des verbes pour les associations n'est pas toujours très judicieux, par exemple "RENFERMER1 et 2" que vous pouvez remplacer par "TYPER" (il n'y aura plus qu'une seule relation puisque une seule entité-type courrier)
- Evitez les varchar 200 à toutes les sauces, un nom sur 200 ça ne sert à rien, de plus des varchar de petite taille sont à remplacer par du char fixe (pour des raisons de performances, je ne rentre pas dans les détails techniques, ils sont nombreux). Typiquement, l'attribut Lib_Typ_Court doit être de type Char(10) plutôt que VarChar(10).
- Respectez les formes normales, tout attribut doit être en dépendance fonctionnelle de l'identifiant. Or dans l'entité-type agent, vous avez positionné l'attribut "Fonction agent", la fonction ne dépend pas seulement de l'identifiant agent puisqu'elle peut varier dans le temps (mutation, promotion etc...). La bonne modélisation est donc [AGENT] 1,n --- (exercer) --- 0,n[FONCTION].
- La relation "regrouper" (que vous pourriez renommer "travailler" ou "rattacher" ou "dépendre"...) ne concerne pas seulement les agents, mais aussi d'autres acteurs, ceux que vous avez oublié de modéliser...
- Vos entités-types sont très pauvres en attributs, à compléter

Bon courage

[CinePhil]

Je plussoie à peu près tout ce qu'à écrit escartefigue, avec un bémol sur ce qu'il exprime quant aux CHAR au lieu de VARCHAR.
Je considère qu'une colonne de type CHAR est, par définition, de taille fixe. Dans un CHAR(10) on enregistre 10 caractères, pas moins. Le type CHAR convient aux codes (code postal français à 5 caractères), aux références à taille fixe (référence d'un produit dans un catalogue), aux "numéros" non modifiables (numéro de département français sur 3 caractères)...
Même si un ministère reçoit, j'imagine, une grande masse de courriers et que la taille de la BDD deviendra vite importante, je ne suis pas sûr que la performance pâtisse énormément d'un VARCHAR(10) au lieu d'un CHAR(10).

J'ajouterai les remarques suivantes :

1) Concernant les personnes
Ne faut-il pas considérer les courriers reçus de personnes morales (autres ministères ou organismes publics, entreprises, associations...) ou envoyés à des personnes morales sans destinataire précis ?
Dans ce cas, le premier héritage à faire est entre personne physique et personne morale.
Toute personne a un nom d'usage ; une personne physique a un prénom ; une personne morale a une raison sociale.
Par conséquent, si vous en restez aux personnes physiques, séparez au moins le prénom du nom.

2) Concernant les services et les directions
Ils ont souvent des noms à rallonge (ce qui peut justifier la grande taille de la colonne) mais sont souvent dénommés plus simplement (pour ceux qui sont du sérail ! ) par des sigles. Je pense que vous devriez prévoir une propriété sigleService et sigleDirection.

3) Concernant les courriers
Ils ont généralement une référence donnée par l'expéditeur, que ce soit l'expéditeur externe au ministère ou l'interne.
La date de réception est une propriété spécifique aux courriers reçus et ne dépend pas de la personne qui reçoit le courrier. Par contre, vérifiez s'il peut y avoir d'autres dates (de traitement par le service destinataire, de réponse, d'archivage...).
Que voulez-vous mettre dans les types de courrier ? S'agit-il de la différenciation entre courrier simple ou recommandé, reçu par voie postale ou Chronopost ou porteur, ou de la différentiation concernant le contenu du courrier (lettre simple, documentation, texte à caractère législatif...) ?
En gros, vérifiez s'il n'y a pas plusieurs typages à modéliser. Est-il prévu d'enregistrer, éventuellement sur demande du destinataire ou de l'expéditeur, les courriers électroniques, ce qui constitue un autre type de courrier ?

Bon courage pour la suite.

[escartefigue]

Je plussoie à peu près tout ce qu'à écrit escartefigue, avec un bémol sur ce qu'il exprime quant aux CHAR au lieu de VARCHAR.
Je considère qu'une colonne de type CHAR est, par définition, de taille fixe. Dans un CHAR(10) on enregistre 10 caractères, pas moins. Le type CHAR convient aux codes (code postal français à 5 caractères), aux références à taille fixe (référence d'un produit dans un catalogue), aux "numéros" non modifiables (numéro de département français sur 3 caractères)...
Même si un ministère reçoit, j'imagine, une grande masse de courriers et que la taille de la BDD deviendra vite importante, je ne suis pas sûr que la performance pâtisse énormément d'un VARCHAR(10) au lieu d'un CHAR(10).

Sur le point particulier du varchar
- le varchar contient un attribut longueur sur 1 à 3 octets (dépend du SGBD et de la longueur effective de la donnée) en plus de l'attribut données. Par conséquence un varchar(1) sera toujours plus long que char(1)
- le varchar est très intéressant pour optimiser le stockage disque des données dont la longueur effective varie beaucoup selon les lignes mais peu pour un même identifiant. Par exemple la longueur de la raison sociale varie beaucoup d'une entreprise à l'autre, mais ne change pas dans le temps pour une même entreprise (ou alors marginalement)
- Par contre, le varchar présente plusieurs inconvénients : il ralentit les recherches avec ou sans index (d'environ 20%), il pénalise les instructions de tri et groupage et, en cas d'augmentation de la longueur lors d'un update, il peut provoquer des déplacements de lignes de data et/ou d'index, ce qui pénalise les perfs et fragmente les données

Pour le reste tout à fait d'accord

[gautier1er]

Je suis entièrement dacord avec vous !

J’ai séparé les courriers départs et les courriers arrivés a cause du numérotation des courriers pour 2 raisons qui sont :

1ère raison :Les courriers arrivés et les courriers départs ne sont pas numérotés dans le même ordre.Exemple :si le dernier courrier arrivé est le n°77 alors si il ya un courrier départ qui suit alors celui-ci ne prendra pas le n°78 mais on tiendra compte du dernier n° du courrier départ.

2ème raison :pour enregistrer un courrier dans la base de données , je ne veux pas que l’utilisateur saisir le numéro du courrier ,je veux que l’application gère cela donc le numéro du courrier sera auto incrémenter .sinon l’utilisateur devra toujours aller regarder dans le cahier de registre pour voir le dernier numéro du courrier donc ça ralenti encore la gestion .du coup cette application ne facilite pas la tache aux utilisateurs .

Concernant l’entité TYPE COURRIER est permet de savoir si le courrier départ une réponse a un courrier arrivé ou vis versa .
Concernant l’entité DATE pour éviter de répéter dateEcriture comme propriété dans l’entité courrier depart et dans l’entité courrier arrivé d’où la redondance , j’ai du faire unique pour les 2 entités en créant l’entité DATE.

Voici les règles de gestion que je devrai envoyer au même moment que le MCD
1) Un type courrier peut renfermer un ou plusieurs courrier (s ) arrivé (s) .
2) Un type courrier peut renfermer un ou plusieurs courrier(s ) départ (s) .
3) Une direction renferme un ou plusieurs service (s).
4) Un service peut regrouper un ou plusieurs agent (s) .
5) La date de réception d’un courrier arrivé dépend du destinataire et du courrier arrivé.
6) La date d’expédition d’un courrier dépend de l’expéditeur et du courrier départ.
7) La date de signature (date de traitement) d’un courrier dépend de l’agent et du courrier arrivé .
8) A date donnée est écrit zéro ou plusieurs courrier (s) départ(s ).
9) A date donnée est écrit zéro ou plusieurs courrier (s) arrivé(s ).
10) Une personne (expéditeur ou destinataire ) peut être soit un agent si elle est du ministère .
11) Une personne (expéditeur ou destinataire ) est un particulier si elle n’est pas du ministère.

Concernant l’entité personne et ses derivés , j’aimerai si possible que vous me donniez plus d’information et aussi tous les acteurs du ministère , se sera gentil de votre part .

J’ai besoin de vos conseils .
Merci a vous.

[escartefigue]

Je suis entièrement dacord avec vous !

C'est une bonne base de discussion

J’ai séparé les courriers départs et les courriers arrivés a cause du numérotation des courriers pour 2 raisons qui sont :

1ère raison :Les courriers arrivés et les courriers départs ne sont pas numérotés dans le même ordre.Exemple :si le dernier courrier arrivé est le n°77 alors si il ya un courrier départ qui suit alors celui-ci ne prendra pas le n°78 mais on tiendra compte du dernier n° du courrier départ.

2ème raison :pour enregistrer un courrier dans la base de données , je ne veux pas que l’utilisateur saisir le numéro du courrier ,je veux que l’application gère cela donc le numéro du courrier sera auto incrémenter .sinon l’utilisateur devra toujours aller regarder dans le cahier de registre pour voir le dernier numéro du courrier donc ça ralenti encore la gestion .du coup cette application ne facilite pas la tache aux utilisateurs .

Il faut bien distinguer deux choses : l'identifiant fonctionnel du courrier, c'est à dire celui qui a un sens pour vous et pour les acteurs en charge du courrier, et l'identifiant technique, qui n'a pas besoin de sens fonctionnel, il vaut d'ailleurs bien mieux qu'il n'en ait pas, et dont la fonction est de garantir l'identification unique et stable dans la base de données.
Donc la contrainte que vous évoquez ne vous oblige nullement à créer deux entités type différentes, créez au contraire une seule entité-type (ET) courrier, dont l'identifiant technique sera une colonne attribuée par le SGBD (auto incrément ou auto décrément au choix) et qui possèdera un autre attribut, le numéro de courrier qui sera votre identifiant fonctionnel. Ce numéro de courrier pourra être unique ou non, selon votre choix.

Concernant l’entité TYPE COURRIER est permet de savoir si le courrier départ une réponse a un courrier arrivé ou vis versa .

C'est une raison supplémentaire de ne pas faire deux entité-type courrier arrivée et départ, puisque le type permet de le savoir

Concernant l’entité DATE pour éviter de répéter dateEcriture comme propriété dans l’entité courrier depart et dans l’entité courrier arrivé d’où la redondance , j’ai du faire unique pour les 2 entités en créant l’entité DATE.

Une ET date pourquoi pas, mais une relation telle que vous l'avez modélisée entre les deux ET courrier, surtout pas !
Car ici vous avez modélisé un courrier en arrivée écrit un courrier au départ à une certaine date, ça ne va pas
De plus, une relation ternaire ne comporte jamais de cardinalité 1,1 sur une de ses pattes

Voici les règles de gestion que je devrai envoyer au même moment que le MCD
1) Un type courrier peut renfermer un ou plusieurs courrier (s ) arrivé (s) .
2) Un type courrier peut renfermer un ou plusieurs courrier(s ) départ (s) .
3) Une direction renferme un ou plusieurs service (s).
4) Un service peut regrouper un ou plusieurs agent (s) .
5) La date de réception d’un courrier arrivé dépend du destinataire et du courrier arrivé.
6) La date d’expédition d’un courrier dépend de l’expéditeur et du courrier départ.
7) La date de signature (date de traitement) d’un courrier dépend de l’agent et du courrier arrivé .
8) A date donnée est écrit zéro ou plusieurs courrier (s) départ(s ).
9) A date donnée est écrit zéro ou plusieurs courrier (s) arrivé(s ).
10) Une personne (expéditeur ou destinataire ) peut être soit un agent si elle est du ministère .
11) Une personne (expéditeur ou destinataire ) est un particulier si elle n’est pas du ministère.

Vous devez à minima avoir une règle pour chaque "patte " de chaque relation, cette liste est donc un début mais à compléter.
Ce que vous devez mentionner dans les règles ce sont
- ce qui permet d'écrire les cardinalités sur les "pattes" des relations, comme vous l'avez fait dans vos règle 1 à 4
- ce que l'on appelle les contraintes d'intégrité fonctionnelles CIF, c'est à dire les restrictions supplémentaires qui s'appliquent entre plusieurs relations, du genre :
"seul l'agent qui a réceptionné le courrier est habilité à y répondre" (j'ose espérer que cette contrainte d'intégrité est fausse, mais c'est pour l'exemple )
autre CIF un peu plus réaliste, dans un autre contexte applicatif :
Le client qui règle la facture doit être le client qui a passé la commande

Les règles 5, 6 et 7 sont suspectes, à reformuler ou expliquer
La règle 10 est tronquée : une personne peut être soit un agent soit quoi ? .... suspens

Concernant l’entité personne et ses derivés , j’aimerai si possible que vous me donniez plus d’information et aussi tous les acteurs du ministère , se sera gentil de votre part .

Là par contre, on ne peut rien pour vous : la première tache avant même de rédiger les règles de gestion, c'est de recueillir les informations métier auprès de vos donneurs d'ordre, c'est à dire votre maitrise d'ouvrage.
C'est à eux de citer par exemple la liste des personnes qui interviennent dans le métier : agent, secrétaire, chargé de mission, directeur de cabinet etc...
C'est à eux de vous fournir les règles métier (les règles de gestion que vous avez commencé à écrire)
C'est également à eux de vous donner la liste des typologies (types de courriers par exemple)
Le MCD que vous allez rédiger, et que vous leur ferez valider, en dépend

[CinePhil]

En plus de ce qu'a écrit escartefigue, je vais commencer par revenir sur ce point puisque vous demandez des éclaircissements :

10) Une personne (expéditeur ou destinataire ) peut être soit un agent si elle est du ministère .
11) Une personne (expéditeur ou destinataire ) est un particulier si elle n’est pas du ministère.

Vous avez correctement fait un héritage de personne vers particulier et agent.

Concernant l’entité personne et ses derivés , j’aimerai si possible que vous me donniez plus d’information et aussi tous les acteurs du ministère , se sera gentil de votre part .

J'évoquais plus haut les personnes morales (entreprises, autres organismes publics, associations, fondations...).

Je vais commencer par donner mes règles de gestion, tel que je préconise de les écrire.

R1 : Une personne physique est une personne et une personne peut être une personne physique.
R2 : Une personne morale est une personne et une personne peut être une personne morale.
R3 : Un agent est une personne physique et une personne physique peut être un agent.
R4 : Un particulier est une personne physique et une personne physique peut être un particulier.

Je m'arrête là concernant les règles de gestion car, sans information complémentaire sur votre besoin, il ne me semble pas utile de faire des héritages supplémentaires de agent vers, par exemple, ministre, directeur de département, chef de service, secrétaire... ni de personne_morale vers entreprise, organisme public, association...

Passons au MCD des règles de gestion ci-dessus, en commençant par faire chaque morceau séparément :

R1 : personne_physique -(1,1)----être----0,1- personne
R2 : personne_morale -(1,1)----être----0,1- personne
R3 : agent -(1,1)----être----0,1- personne_physique
R4 : particulier -(1,1)----être----0,1- personne_physique

Assemblons le tout :
agent -(1,1)----être----0,1- personne_physique -(1,1)----être----0,1- personne -0,1----être----(1,1)- personne_morale
particulier -(1,1)----être----0,1---------|

Voilà ce qui peut être fait si vous avez besoin de distinguer les personnes morales des personnes physiques.

On peut ajouter la contrainte suivante :
C1 : Une personne physique est soit un agent, soit un particulier.

Ceci engendrera une exclusion/totalité (XT) dans le symbole de l'héritage sur le MCD (pas facile à représenter en format texte dans ce message) et signifiera que le nombre de personnes physiques sera égal au total agents + particuliers (totalité) et qu'aucun agent ne sera aussi un particulier ni qu'aucun particulier ne sera un agent (exclusion).

Concernant les courriers, on peut aussi faire un héritage...

Règles de gestion :
R5 : Un courrier départ est un courrier et un courrier peut être un courrier départ.
R6 : Un courrier arrivée est un courrier et un courrier peut être un courrier arrivée.

Là aussi, on ajoute une contrainte d'exclusion/totalité :
C2 : Un courrier est soit un courrier départ, soit un courrier arrivée.

MCD :
courrier_depart -(1,1)----être----0,1- courrier
courrier_arrivee -(1,1)----être----0,1------|

Continuons notre réflexion...

R7 : un courrier départ peut répondre à un courrier arrivée et un courrier arrivée peut avoir en réponse un courrier départ.

MCD :
courrier_depart -0,1----répondre----0,1- courrier_arrivée

Nota :
Comme je l'explique dans un autre article de mon blog, ce dernier morceau de MCD engendrera la création d'une table associative dans la base de données.

Réfléchissons maintenant sur les dates des courriers...
Normalement, tout courrier, qu'il soit reçu ou envoyé, comporte une date d'écriture.
Tout courrier reçu peut (doit ?) être marqué de sa date d'arrivée au ministère.
Je ne sais pas si ça existe dans votre pays mais en France, on peut envoyer des courriers recommandés avec accusé de réception, ce qui permet à l'expéditeur de savoir officiellement à quelle date le destinataire a reçu le courrier, mais la date de réception du courrier par le destinataire d'un courrier envoyé (courrier départ) n'est pas systématiquement connue.

On peut donc écrire les règles de gestion suivantes :
R8 : Un courrier comporte une date (d'écriture) et une date (d'écriture) peut être inscrite sur plusieurs courriers.
R9 : Un courrier arrivée comporte une date (de réception) et une date (de réception) peut être inscrite sur plusieurs courriers arrivée.
R10 : Un courrier départ peut comporter une date (de réception) et une date (de réception) peut être inscrite sur plusieurs courriers départ.

Peut-être que la date d'écriture inscrite sur le courrier départ n'est pas la date d'envoi, pour des raisons de circuit de signature qui retarderait l'envoi. Il est donc peut-être nécessaire d'ajouter la date d'envoi.
R11 : Un courrier départ enregistre une date (d'envoi) et une date (d'envoi) peut être enregistrée sur plusieurs courriers départ.

Nota :
J'introduis ici l'entité type (un peu particulière) Date qui, une fois transformée en table de la base de données contiendra toutes les dates possibles. Ainsi, à une date donnée, il est possible qu'aucun courrier ne soit reçu (cas des jours où le courrier n'est pas distribué au ministère), ce qui justifie la possibilité de ma règle ("peut être inscrite") et pas l'obligation (il serait alors écrit : "est inscrite").

MCD :
R8 : courrier -1,1----comporter----0,n- date (d'écriture)
R9 : courrier_arrivee -1,1----comporter----0,n- date (de réception)
R10 : courrier_depart -0,1----comporter----0,n- date (de réception)
R11 : courrier_depart -1,1----enregistrer----0,n- date (d'envoi)

Nota :
Dans la table issue de l'entité type courrier, il y aura une colonne nommée par exemple "id_date_ecriture" qui sera une clé étrangère référençant la table des dates. Idem pour la mise en oeuvre des autres règles, sauf la R10 qui engendrera une table associative (là encore, voir mon article de blog).

On voit donc que, contrairement à votre MCD, il n'y a pas d'association porteuse d'une propriété date. Les dates sont des propriétés des courriers. L'entité type date n'est d'ailleurs utile que si vous avez besoin de faire, par exemple, des statistiques sur le nombre de courrier reçus ou envoyés par jour, par semaine, par mois... et que vous avez donc besoin de toutes les dates possibles. Dans le cas contraire, contentez-vous de mettre les propriétés date_ecriture, date_envoi, date_reception aux bons endroits.

Passons, pour finir, aux liens entre les personnes et les courriers...
Une personne, qu'elle soit un particulier ou un agent (je fais comme vous abstraction des personnes morales dans cette réflexion), peut écrire ou être destinataire un courrier.
Vous pouvez par contre, en interne au ministère, considérer la personne qui réceptionne le courrier et l'enregistre (un agent du service courrier) puis le transmet ensuite au destinataire (un autre agent, quelle que soit sa fonction).

On a donc les règles de gestion suivantes :

R12 : Un courrier est écrit par une personne et une personne peut écrire plusieurs courriers.
R13 : Un courrier est destiné à une personne et une personne peut être destinataire de plusieurs courriers.
R14 : Un courrier est réceptionné par un agent et un agent peut réceptionné plusieurs courriers.

MCD :
courrier -1,1----écrire----0,n- personne
|------------1,1----destiner----0,n-----|
|------------1,1----réceptionner----0,n- agent

Voilà de quoi vous aider à réfléchir...
Bonne continuation !

[gautier1er]

Bonjour et merci pour les règles de gestion que vous aviez donné , j’ajoute ces règles a ça :

R15 :Un ministère est une personne morale et une personne morale peut être un ministère .
R16:Un partenaire est une personne morale et une personne morale peut être un partenaire .

R17 : Un agent est une personne physique et une personne physique peut être un agent.
R18: Un agent peut exercer une ou plusieurs fonctions et une fonction est exercé par aucun ou plusieurs agents.
R19:Un agent travaille dans un service et dans un service plusieurs agents peuvent travailler.
R20 :Un service est rattaché à une direction et une direction peut rattacher plusieurs service.

Je fais héritage de l’entité type agent :
Comme tout courrier passe toujours par le service courrier et c’est le service courrier qui transmet le courrier a celui qui doit traiter le courrier donc je fais ceci :

R21:un agent peut être un agent du service courrier et un agent du service courrier est un agent.
R22:un agent peut être un traiteur (celui qui traite le courrier ex : le Directeur de Cabinet ) et un traiteur est un agent.
.En plus j’aimerai créer une entité (traiteur) qui prend en compte ( le ministre , le directeur de Cabinet ,chef de cabinet,DAF, DRH ,directeur de communication etc )
Je ne sais pas si c’est une bonne idée .
merci

[CinePhil]

R15 :Un ministère est une personne morale et une personne morale peut être un ministère .
R16:Un partenaire est une personne morale et une personne morale peut être un partenaire .

Donc au début vous n'aviez pas besoin des personnes morales et maintenant vous avez besoin de les spécialiser...
Pouvez-vous nous justifier en quoi c'est nécessaire au sein du domaine que vous modélisez (la gestion du courrier au sein de votre ministère) ?

R17 : Un agent est une personne physique et une personne physique peut être un agent.
R18: Un agent peut exercer une ou plusieurs fonctions et une fonction est exercé par aucun ou plusieurs agents.
R19:Un agent travaille dans un service et dans un service plusieurs agents peuvent travailler.
R20 :Un service est rattaché à une direction et une direction peut rattacher plusieurs service.

Sans être repassé sur le MCD que vous nous avez présenté, cela me semble correspondre... rien de nouveau ici, il me semble.

Je fais héritage de l’entité type agent :
Comme tout courrier passe toujours par le service courrier et c’est le service courrier qui transmet le courrier a celui qui doit traiter le courrier donc je fais ceci :

R21:un agent peut être un agent du service courrier et un agent du service courrier est un agent.
R22:un agent peut être un traiteur (celui qui traite le courrier ex : le Directeur de Cabinet ) et un traiteur est un agent.
.En plus j’aimerai créer une entité (traiteur) qui prend en compte ( le ministre , le directeur de Cabinet ,chef de cabinet,DAF, DRH ,directeur de communication etc )

En quoi serait-ce nécessaire ?

Ce qui justifie un héritage de données, c'est :
- des propriétés particulières pour une sous-entité type (cas de la personne morale qui a un numéro d'immatriculation et d'une personne physique qui a un prénom) ;
- des associations particulières pour une sous-entité type (dans ce que je développe actuellement, c'est le cas de la ville française que j'associe à son département, ce qui n'est pas le cas des villes non françaises dont je n'ai besoin de connaître que le pays).

Dans votre MCD, si je ne m'abuse, vous pourrez savoir si un agent est du service courrier par son association avec service.
Si vous avez seulement besoin de vérifier que la personne qui est enregistrée comme ayant réceptionné le courrier est bien du service courrier, vous pourrez le faire par une contrainte. Il n'est peut-être pas indispensable de faire un héritage de agent vers agent du service courrier pour ça.
Concernant les "traiteurs", posez-vous la question aussi s'il est utile de spécialiser ça par rapport à agent.

En bref, ne faites des héritages de données que lorsqu'ils sont pleinement justifiés.

[gautier1er]

Donc au début vous n'aviez pas besoin des personnes morales et maintenant vous avez besoin de les spécialiser...
Pouvez-vous nous justifier en quoi c'est nécessaire au sein du domaine que vous modélisez (la gestion du courrier au sein de votre ministère) ?

pour connaitre les courriers en provenance d’un ministère ou de partenaire privés.

Dans votre MCD, si je ne m'abuse, vous pourrez savoir si un agent est du service courrier par son association avec service.
Si vous avez seulement besoin de vérifier que la personne qui est enregistrée comme ayant réceptionné le courrier est bien du service courrier, vous pourrez le faire par une contrainte. Il n'est peut-être pas indispensable de faire un héritage de agent vers agent du service courrier pour ça.
Concernant les "traiteurs", posez-vous la question aussi s'il est utile de spécialiser ça par rapport à agent.

En bref, ne faites des héritages de données que lorsqu'ils sont pleinement justifiés.

ok donc je peux rester sur l'entité type (agent) et donner des proprietés qui permettront de distinguer un agent du service courrier et traiteur ou bien de crée une entité type ( type agent ) pour faire cela

[CinePhil]

pour connaitre les courriers en provenance d’un ministère ou de partenaire privés.

Vous pouvez savoir ça par l'identité de la personne morale expéditrice du courrier. Soit un courrier est adressé à "Ministère de quelque chose", soit à une autre personne morale genre "Entreprise Bidule".
La spécialisation de la personne morale sur ce seul aspect me semble bien superflu.

[gautier1er]

ok merci

Merci infiniment à CinePhil et à escartefigue grace à vous j'ai pur réalisé mon MCD ,

voici le MCD ci-joint
c'est OK ou je dois améliorer ?

[CinePhil]

Pourquoi avez-vous mis l'adresse et le sexe (et que sont les propriétés relatives à des pièces ?) seulement chez l'agent ?

Si M. Jean Dupont habitant Yamoussoucro écrit au ministère, vous avez son sexe et son adresse, non ?

Au passage, il est préférable d'externaliser les villes pour éviter l'enregistrement multiple du nom d'une ville, parfois avec des orthographes différentes.
Ça diminue le volume de données enregistrées.
Ça évite les erreurs d'orthographe.
Ça évite les résultats incomplets dans les requêtes si, par exemple, on cherche toutes les personnes connues habitant Saint-Étienne et que dans la base de données cette ville est écrite de plusieurs manières (St Etienne, Saint Etienne, St Étienne, Saint-Etienne...). Idem pour les statistiques (Combien avons-nous reçus de courriers de Saint-Étienne en 2016 ?)

[alassanediakite]

Salut
Pour avoir déjà fait un cas pareil.
1=>
Il aurai été pertinent que gautier1er décrive le processus de traitement d'un courrier arrivé: réception, transmission, traitement. Car il est très important de suivre le courrier dans le circuit du service.
Ainsi on doit pouvoir tracer les transmissions (éventuellement avec objet) à agent ou service, les traitements effectués.
2=>
Pour la recherche, il faut aussi penser à l'archivage physiques ou logiques (images scannée) des courriers. Pour l'archivage physique on parlera d'armoires et de classeurs.
3=>
Il a lieu de préciser le SGBD qui sera utilisé, cela pour prévoir les difficultés de mise en œuvre des choix du mcd (surtout l'héritage).
Pour le reste je m'arrête là car ma facture n'est pas encore réglée
@+

[gautier1er]

j'utiliserai MySQL comme SGBD , j'espere que ça ne cause pas problème avec l'héritage ?

[alassanediakite]

Salut
Un coup d’œil ici.
@+

[gautier1er]

Je n'est pas encore faire le MCT mais voici en bref la description de l'existence

Cas du courrier arrivé : Dès l’arrivée d’un courrier au service courrier, un agent reçoit le courrier accompagné de la décharge , l’agent prend le temps de vérifier si le courrier est adressé a quelqu’un du ministère ( exemple : le ministre , le directeur de cabinet ) si c’est le cas alors il attribut un numéro au courrier et il met aussi ce numéro sur la décharge puis remet la décharge a celui qui a envoyé le courrier afin de pouvoir suivre le courrier , l’agent enregistre le courrier dans le registre des courriers arrivés (le numéro ,la date d’arrivée ,le numéro d’origine , le date d’écriture ,l’expéditeur ,l’objet du courrier) ensuite ,l’agent du service courrier transmet le courrier+ la fiche de suivi du courrier à l’agent qui est chargé d’ imputer le courrier au bon service ( c’est le ministre qui est chargé de ça mais à son absence c’est le Directeur de Cabinet qui s’en charge ) ,après l’imputation au bon service , le courrier revient au service courrier et un agent note la date de retour du courrier (au service courrier) sur la fiche de suivi ,puis transmet le courrier au service destinataire (transmet les copies aux services qui doivent suivre le courrier ) , a l’arrivée du courrier au service destinataire, un agent du service destinataire reçoit le courrier puis note la date de réception par le service destinataire dans le cahier de décharge puis l’agent du service courrier retourne avec le cahier.
le service destinataire doit traiter le courrier dans un délai (date de traitement) .
Il arrive souvent que l’expéditeur du courrier appel ou se rend a service courrier pour voir la suite du traitement du courrier (si le courrier a été traité ou il est à quelle niveau etc ) ,l’agent du service courrier regard dans le cahier de registre (courriers arrivés) pour voir à quelle service le courrier a été imputer

Pourquoi avez-vous mis l'adresse et le sexe (et que sont les propriétés relatives à des pièces ?) seulement chez l'agent ?

Si M. Jean Dupont habitant Yamoussoucro écrit au ministère, vous avez son sexe et son adresse, non ?

Au passage, il est préférable d'externaliser les villes pour éviter l'enregistrement multiple du nom d'une ville, parfois avec des orthographes différentes.
Ça diminue le volume de données enregistrées.
Ça évite les erreurs d'orthographe.
Ça évite les résultats incomplets dans les requêtes si, par exemple, on cherche toutes les personnes connues habitant Saint-Étienne et que dans la base de données cette ville est écrite de plusieurs manières (St Etienne, Saint Etienne, St Étienne, Saint-Etienne...). Idem pour les statistiques (Combien avons-nous reçus de courriers de Saint-Étienne en 2016 ?)

c'est vrai vous avez raison, je externalisé la ville maintenant

Salut
Pour avoir déjà fait un cas pareil.
1=>
Il aurai été pertinent que gautier1er décrive le processus de traitement d'un courrier arrivé: réception, transmission, traitement. Car il est très important de suivre le courrier dans le circuit du service.
Ainsi on doit pouvoir tracer les transmissions (éventuellement avec objet) à agent ou service, les traitements effectués.
2=>
Pour la recherche, il faut aussi penser à l'archivage physiques ou logiques (images scannée) des courriers. Pour l'archivage physique on parlera d'armoires et de classeurs.
3=>
Il a lieu de préciser le SGBD qui sera utilisé, cela pour prévoir les difficultés de mise en œuvre des choix du mcd (surtout l'héritage).
Pour le reste je m'arrête là car ma facture n'est pas encore réglée
@+

Je n'est pas encore faire le MCT mais voici en bref la description de l'existence

Cas du courrier arrivé : Dès l’arrivée d’un courrier au service courrier, un agent reçoit le courrier accompagné de la décharge , l’agent prend le temps de vérifier si le courrier est adressé a quelqu’un du ministère ( exemple : le ministre , le directeur de cabinet ) si c’est le cas alors il attribut un numéro au courrier et il met aussi ce numéro sur la décharge puis remet la décharge a celui qui a envoyé le courrier afin de pouvoir suivre le courrier , l’agent enregistre le courrier dans le registre des courriers arrivés (le numéro ,la date d’arrivée ,le numéro d’origine , le date d’écriture ,l’expéditeur ,l’objet du courrier) ensuite ,l’agent du service courrier transmet le courrier+ la fiche de suivi du courrier à l’agent qui est chargé d’ imputer le courrier au bon service ( c’est le ministre qui est chargé de ça mais à son absence c’est le Directeur de Cabinet qui s’en charge ) ,après l’imputation au bon service , le courrier revient au service courrier et un agent note la date de retour du courrier (au service courrier) sur la fiche de suivi ,puis transmet le courrier au service destinataire (transmet les copies aux services qui doivent suivre le courrier ) , a l’arrivée du courrier au service destinataire, un agent du service destinataire reçoit le courrier puis note la date de réception par le service destinataire dans le cahier de décharge puis l’agent du service courrier retourne avec le cahier.
le service destinataire doit traiter le courrier dans un délai (date de traitement) .
Il arrive souvent que l’expéditeur du courrier appel ou se rend a service courrier pour voir la suite du traitement du courrier (si le courrier a été traité ou il est à quelle niveau etc ) ,l’agent du service courrier regard dans le cahier de registre (courriers arrivés) pour voir à quelle service le courrier a été imputer

[alassanediakite]

Salut
gautier1er, il faut prendre le temps qu'il faut pour bien rédiger le mct (si possible en schéma). Cela permet une meilleur collaboration.
Je voudrais te laisser avec CinePhil et escartefigue (je ne serais que de trop!).
@+

[gautier1er]

Salut
gautier1er, il faut prendre le temps qu'il faut pour bien rédiger le mct (si possible en schéma). Cela permet une meilleur collaboration.
Je voudrais te laisser avec CinePhil et escartefigue (je ne serais que de trop!).
@+

ok merci ,c'est gentil

[gautier1er]

bonjour ,
Pour vérification du MCD ci-joint et commenter .



cordialement