Discussion :

[dalinbm]

Bonjour,

Je sollicite vos aides, car j'ai du mal à faire un MCD pour modéliser correctement une problématique. En effet, on me demande de gérer les envois en mission des employés au sein de ma société.
vous trovez dans la suite un digramme de mon base de donnée:
mes grand remerciement.

[fsmrel]

Bonjour dalinbm,

Commencez par fournir les règles de gestion décrivant votre sujet. Voyez par exemple ici ou voyez l’exemple proposé par escartefigue. Ensuite, pour modéliser, utilisez l’excellent outil de modélisation Looping, gracieusement proposé par le professeur Patrick Bergougnoux (Paprick).

A plus tard !

[fsmrel]

Votre schéma est en fait un MLD, composé de tables. En effet Mission y est une table, car comportant une colonne Matricule faisant manifestement référence à la colonne Matricule de la table Employe.

Un MCD est composé d’entités-types (classes d’entités) et des associations entre les entités-types. Si l’entité-type Employe est identifiée par l’attribut (rubrique, propriété) Matricule, cet attribut n’est pas à répéter dans l’entité-type Mission, c’est à l’AGL de le faire lors de la production du MLD (et des tables SQL).

Pour bâtir votre MCD, dressez la liste des entités-types (correspondant aux tables de votre MLD) :

Employe

Mission

Hôtel

Réservation

Etc.

Ceci fait, définissez, explicitez les associations (vos liens du MLD) au moyen des règles de gestion :

RG001 – Un employé fait partie d’un service

RG002 – Un employé occupe un poste

Etc.

A noter que ces deux règles tendent à montrer que des entités-types Service et Poste sont à mettre en oeuvre, sinon, au stade SQL, les colonnes correspondantes pourraient prendre des valeurs différentes dans les lignes de la table Employe, au fil de la saisie de ces valeurs.

[escartefigue]

Attention aussi au choix des identifiants : ils doivent être stables. Or un numéro d'immatriculation peut changer, c'est donc un mauvais choix.
Possiblement, le matricule d'un employé peut peut être également changer : si un ancien employé démissionnaire est réembauché, ne prend il pas un nouveau matricule ? À vérifier.
Mais comme l'indique justement FsmRel, priorité aux règles de gestion, c'est un prérequis incontournable.

[dalinbm]

Bonsoir,
un grand grand grand merci pour vos réponses et vos réclamations, je les prend on considération..

[fsmrel]

Bonsoir,

Pour confirmer ce que rappelle escartefigue, un identifiant doit être invariant, donc non significatif. Par exemple, comme le numéro d’immatriculation d’un véhicule peut changer dans le temps, il devra faire l’objet d’un identifiant alternatif pour l’entité-type Vehicule, donc pouvant changer de valeur, tandis que l’identifiant principal de cette entité-type (disons VehiculeId) ne changera pas. Cette affaire est évidemment particulièrement sensible au niveau SQL, car l’impact sur les clés étrangères (intégrité référentielle) s’y avère redoutable, et comme dit l’autre, chouffe la zoubia !

Vous verrez, avec Looping, définir un identifiant alternatif est extrêmement simple.

N’hésitez pas à soumettre le résultat de l’aménagement de votre MCD.

Bon courage !

[dalinbm]

Bonjour , je viens de réaliser les règles de gestion ainsi que le MCD ,merci de m’aider;
****
RG01 : Pour une période donnée, un employé ne peut effectuer qu'une et une seule mission.
RG02 : une mission peut avoir plusieurs destination (plusieurs lieux).
RG03 : une mission peut être réalisé par un employé ou plus
RG04 : la mission est planifiée suite a une demande de mission (demandeur : site distant) ou suite à un besoin du réalisateur de la mission.
RG05 : chaque agent en mission est bénéficié par un frais de déplacement (suivant le nombre de jours) sauf au mois du ramadhan ou en séances uniques
RG06 : les missions s’exécutent dans la même entreprise : des sites centraux et des sites distant (bureau régional, bureau local, des antennes, des polycliniques ...)
RG07 : Tous les véhicules (de service) de la société sont susceptibles d’effectuer des missions locales quel que soit le trajet.
RG08 : Une voiture de mission (de service) est pilotée par un chauffeur (lui-même employé de la société)
G09: Pour une mission en voiture Personnel, l’agent qui possède cette voiture prendre en charge le pilotage de la voiture ainsi que l'exécution de mission.
RG10 : En plus de ses frais de mission, le pilote d’une voiture personnel bénéficie d'autre frais (frais fixe par kilométrage)
RG11 : Si la mission s’effectue en bus, l’employé reçoit des frais supplémentaires pour l’achat du ticket de bus (La liste des moyens de transport est exhaustive)
RG12 : si la mission nécessite plus d'un jour, il faut faire la réservation dans un hôtel à condition que la distance entre le lieu de départ et lieu d'arrivée dépasse une distance bien déterminée ainsi que la validation de conducteur de mission.
RG13 : la réservation c'est en charge du la structure réceptionniste.
****

[Paprick]

Bonsoir,

Attention ! au niveau MCD, les clés étrangères ne doivent pas être exprimées : elles seront automatiquement générées au niveau MLD.
Comme vous utilisez Looping, le test est vite fait : appuyez simplement sur le bouton MLD (en haut à gauche) ; vous pouvez également observer le MLD textuel.
Vous semblez privilégier le formalisme UML... je pense qu'un schéma E/A est plus opportun.
Par ailleurs, je pense que vous avez inversé les cardinalités...

Bonne continuation !

[fsmrel]

Bonsoir,

Dalinbm, comme toute matière, la modélisation doit être bien maîtrisée, donc d’abord apprise, et en l’occurrence il s’agit plus précisément de la construction du MCD.
Pour vous guider, il existe fondamentalement l’ouvrage remarquable de D. Nanci et B. Espinasse Ingénierie des systèmes d'information - Merise deuxième génération,
c’est l’ouvrage de référence. Le chapitre à étudier est le chapitre 7 (« Modélisation conceptuelle des données »).

N'hésitez pas à poser vos questions.

Courage !

[dalinbm]

bonjour,
bien dit pour l'apprentissage, mais je suis en train de formaliser avec cette matières ,en parallèle vous trouvez dans la suite une rectification de mon schéma E/A . le probleme c'est que il me faut un chauffeur pour le cas d'une voiture de service et en effet le chaffeur est un employe .....
Mes remerciement sincère pour vous tous.

[fsmrel]

Bonjour dalinbm,

Vous proposez la règle suivante :

RG01 : Pour une période donnée, un employé ne peut effectuer qu'une et une seule mission

Selon votre MCD, durant toute sa carrière, l’employé disons e1 ne peut effectuer qu’une seule mission, disons m1.

La règle RG01 sous-entend que e1 peut en effectuer plusieurs disons m1, m2, ... La contrainte est que la période p1 pendant laquelle e1 effectue la mission m1, doit être strictement différente de la période p2 quand e1 effectue la mission m2, etc.

Il s’agit là d’une contrainte qui n’est pas triviale à modéliser et nécessitant la mise en oeuvre d’un trigger au stade SQL : pour le moment ignorons la contrainte, et faisons comme si l’employé pouvait participer en même temps à plusieurs missions. Chaque résolution de difficulté en son temps.

Par ailleurs, si tous les employés ne sont pas astreints à effectuer des missions, la cardinalité minimale portée par la patte d’association connectant l’entité-type Employe et l’association Effectuer doit être 0 et non pas 1.

Selon la règle RG04, une mission est planifiée suite à une demande de mission (demandeur : site distant) ou suite à un besoin du réalisateur de la mission.

(a) La cardinalité portée par la patte d’association connectant l’entité-type Mission et l’association Planifier doit être 0,1 et non pas 0,n, sinon la mission m1 pourrait être planifiée par les sites s1, s2, etc.

(b) La mission m1 étant planifiée soit à la demande d’un site distant, soit à la demande du réalisateur de la mission, cette dernière demande doit être modélisée.

Mais qui est le réalisateur de la mission ?

(a) Un employé qui ne participera pas à la mission ?

(b) Un employé qui participera à la mission ?


A propos du type de mission :

L’entité-type Mission et l’association Planifier sont toutes deux porteuses d’un attribut Type_Mission : il y a là une redondance, et la redondance est redoutable dans une base de données (problème de l’égalité des valeurs à garantir à tout prix).

(a) Si le type de mission ne concerne que les sites (ce dont je doute), cet attribut doit être porté par l’association Planifier et être supprimé dans l’entité-type Mission.

(b) Si le type de mission concerne plus généralement les missions, cet attribut doit être porté par l’entité-type Mission et être supprimé dans l’association Planifier.

Par ailleurs, pour des raisons de cohérence, le type de mission doit faire l’objet d’une entité-type, appelons-la par exemple TypeMission.

Dans le cas (a), la modélisation serait la suivante (qui pose quelques problèmes malsains au stade SQL : génération du marqueur NULL)  :

Dans le cas (b) (qui a ma préférence, car plus saine), la modélisation serait la suivante :

De façon générale, tout ce qui est « type de » doit faire l’objet d’une entité-type contenant le libellé (désignation ou tout nom synonyme) : TypeReservation, TypeTransport, TypeSite, TypeFrais, TypeVoiture, etc.

Toujours pour des raisons de cohérence, la mise en oeuvre d’une entité-type Poste et d’une entité-type Service vaut aussi, référencées par l’entité-type Employe.

En passant, à quoi correspond l’attribut CodeBr porté par l’entité-type Employe ?

A propos des frais : la cardinalité portée par la patte d’association connectant l’entité-type Frais et l’association Beneficier doit être 1,1 et non pas 0,n.

Association Utiliser_Voiture : pour la mission m1, on peut utiliser au plus une voiture, disons la voiture v1. En conséquence, si les employés e1, e2, e3 sont affectés à la mission m1, si le trajet est effectué avec la voiture m1, ces employés devront tous faire le trajet avec la voiture v1. Pour avoir réalisé moi-même de nombreuses misions en compagnie de collègues, chacun choisissait son mode de transport...

Cette réflexion vaut par exemple pour les réservations d’hôtel : mes collègues et moi-même demandions à notre secrétaire d’effectuer une réservation pour l’hôtel de notre préférence (et quand certains avaient de la famille dans la ville, ils ne demandaient pas de réservation).

Bref, y a encore du pain sur la planche, mais tenez bon !

[dalinbm]

Bonsoir, merci infiniment pour votre collaboration et votre précieux réclamation
« RG01 : Pour une période donnée, un employé ne peut effectuer qu'une et une seule mission
La règle RG01 sous-entend que e1 peut en effectuer plusieurs disons m1, m2, ... La contrainte est que la période p1 pendant laquelle e1 effectue la mission m1, doit être strictement différente de la période p2 quand e1 effectue la mission m2, etc. »

C’est exactement vrai et c’est ce que je veux dire, mais en parallèle une mission peut être une formation, une intervention technique etc ...

« Mais qui est le réalisateur de la mission ?
(a) Un employé qui ne participera pas à la mission ? (b) Un employé qui participera à la mission ? »

Le réalisateur de la mission est l'employeur « chef de mission » mais on peut avoir une mission planifier par le directeur de la structure comme le chef service ….
Le type de mission concerne plus généralement les missions.
Type de mission : (Demande de mission, Besoin interne)
« En passant, à quoi correspond l’attribut CodeBr porté par l’entité-type Employe ? »

CodeBr est un identifiant attribue à chaque site (Bureau régional : « Br », bureau local :« Bl », Antenne, direction, centre formation ...)
« Association Utiliser_Voiture : pour la mission m1, on peut utiliser au plus une voiture, disons la voiture v1. En conséquence, si les employés e1, e2, e3 sont affectés à la mission m1, si le trajet est effectué avec la voiture m1, ces employés devront tous faire le trajet avec la voiture v1. Pour avoir réalisé moi-même de nombreuses misions en compagnie de collègues, chacun choisissait son mode de transport... »
Dans ce cas : e1, e2, e3, (avec chauffeur e4 le cas d'une voiture de service) prend la voiture v1
« Cette réflexion vaut par exemple pour les réservations d’hôtel : mes collègues et moi-même demandions à notre secrétaire d’effectuer une réservation pour l’hôtel de notre préférence (et quand certains avaient de la famille dans la ville, ils ne demandaient pas de réservation). » ... peut être effectuée dans des cas spéciale. (La réservation est en charge de demandeur de mission en collaboration avec les employeurs chargée du la mission)

[dalinbm]

par la suite l’attribut CodeBr porté par l’entité-type Employe peut joué le role de l'identifiant de site , vos aides s'il vous plait.
... mes grand remerciements...

[fsmrel]

Bonsoir,

D’accord pour les entités-types Service, Poste, Type_Mission, Type_Site, Type_Frais, et autres Type_xxxx.
 
 

en parallèle une mission peut être une formation, une intervention technique etc.

Les valeurs telles que "formation", "intervention technique" seront prises en charge par la table dérivée de l’entité-type Type_Mission.

L’identifiant d’une entité-type ne doit pas prendre une valeur significative, et doit donc être du type numérique (voyez la génération du code SQL effectuée par Looping). Ainsi, l’entité-type Employe est à identifier par un attribut non significatif (EmployeId ou id_Employe, à votre convenance). En conséquence, l’attribut Matricule devra faire l’objet d’un identifiant alternatif ("Unique" coché ci-dessous) :
 

 
 

Un employé pouvant effectuer plus d’une mission, la cardinalité maximale portée par la patte connectant l’entité-type Employe et l’association Effectuer doit être « n ».

Pour citer une partie d’une réponse qui vous est faite et la mettre en évidence, vous pouvez cliquer sur "Répondre avec citation". Vous utiliserez alors la balise QUOTE qui vous est proposée et ne conserverez que le texte intéressant. Exemple :
 

[QUOTE=fsmrel;12024479]blabla[/quote]

A noter que DVP propose ICI un ensemble de balises bien utiles.

Vous avez le droit de voter quand une réponse vous éclaire...

Il se fait tard, on reprendra demain...

[dalinbm]

Bonjour,
Mr fsmrel ,C'est incroyable de vous voir constamment repousser les limites.Merci d'être un joueur étoile et de nous avoir aidé à atteindre mes objectifs.
Le Nouveau modele E/A apres modification reste a verifier la dateFrais(pour l'entité Frais ,dateFrais: c'est la date de mission ?!!!) et la difference entre chauffeur (voiture de service) et employe en mission.

[fsmrel]

Bonsoir,

En ce qui concerne l’entité-type Employe, je reprends ce que j’ai écrit dans mon message précédent ; j’ai ajouté l’identifiant alternatif naturel Matricule, sinon les employés ne seront plus immatriculés ! l’attribut id_Employe (ou EmployeId) est volontairement dépourvu de signification, donc invariant, son rôle est de participer à la stabilité de la base de données.
 
 

pour l'entité Frais ,dateFrais: c'est la date de mission

 
Cela peut se traduire de deux façons :

(a) Dans le cadre de la mission m1, l’employé e1 a bénéficié des frais f1, f2, etc. (détail des frais dans le cadre de la mission).

(b) Dans le cadre de la mission m1, l’employé e1 a bénéficié des frais f1 (cumul des frais dans le cadre de la mission).

Dans les deux cas, la date des frais n’est pas à modéliser puisqu’il s’agit de la date de la mission m1.

De toute façon, puisque l’entité-type Frais devient dépendante de la paire (Employe, Mission), y a pas à tortiller, il faut transformer l’association Effectuer en entité-type...
Heureusement, Paprick a tout prévu avec Looping, il savait longtemps à l’avance que dalinbm passerait par là !

On part de là (j’ai renommé l’association Effectuer en EmployeMission) :

Cliquer sur l’association. Ceci fait, Looping présente en bas à droite une icône que j’ai encadrée en rouge :

En cliquant sur cette icône, on obtient la modélisation suivante :

Looping a transformé l’association EmployeMission en entité-type. Apparemment cette entité-type n’a aucun attribut, pas même d’identifiant. En réalité, il s’agit d’un entité-type faible, relative aux deux autres (fortes), ce que Looping met en évidence en remplaçant les cardinalités "1,1" en "1,1(R)" (où R symbolise l’identification relative). Quand on examine le code SQL produit, on constate que la table EmployeMission a bien pour clé primaire la paire (EmployeId, MissionId).

Pour en revenir aux frais, la modélisation devient la suivante :

La date de frais a évidemment été supprimée dans l’entité-type Frais, puisque la date de la mission joue le rôle.

J’ai supposé que l’attribut FraisMontant représente le cumul des frais, d’où la cardinalité 0,1 portée par la patte d’association entre EmployeMission et Frais. Dans ces conditions, on peut faire l’économie de l’entité-type Frais et dégager l’attribut FraisMontant dans l’entité-type EmployeMission (si pas de frais : FraisMontant prendra la valeur 0).

A propos de l’association Conduire :

Du fait de la cardinalité 1,1 portée par la patte connectant l’entité-type Voiture et l’association Conduire, la voiture v1 ne peut être conduite que par le chauffeur c1. Comment faire s’il tombe malade ou est en vacances et qu’on a besoin de lui pour la mission m1 ? les employés e1, e2 et e3 devront manifestement trouver un autre moyen pour se rendre à destination...

Dans le même sens, un hôtel n’est affecté qu’à une seule réservation et une réservation peut concerner plusieurs hôtels, c’est une règle un peu bizarre...

Il se fait tard, la suite au prochain numéro !

Vous ne votez (likez ) toujours pas ?

[fsmrel]

Bonjour dalinbm,

Dans mon message précédent, j’ai traité des frais dan l’hypothèse où ceux-ci sont cumulés.
 
Qu’en est-il si l’on souhaite connaître les frais selon leur nature (type de frais) ?

Le plus simple est alors d’établir une association entre les entités-types EmployeMission et TypeFrais. Cette association est porteuse de l’attribut FraisMontant :
 

A plus tard !

[dalinbm]

Bonjour
merci

 
Qu’en est-il si l’on souhaite connaître les frais selon leur nature (type de frais) ?
 

il existe 3 type de frais tel que : le frais mission (8 dinars : un plat ) mission en voiture de service , avec voiture personnel : frais total (frais mission + prime kilometrique + peage) et enfin transport publique (frais mission + ticket )
parla suite des nouveau modification tel que j'ai ajouter une entité_type chauffeur qui herite de l'entité_type employe ainsi q'une autre entité_type nommée voiture_personnel qui herite de l'entité_type voiture.pour resolu le probleme du la presence d'un attribut Id_Employe dans l'entité_type voiture (alors que cela ne sera vrai que dans une seul condition : l'utilisation d'une voiture personnel...)

[fsmrel]

Reprenons,
 

e1, e2, e3, (avec chauffeur e4 le cas d'une voiture de service) prend la voiture v1.

 
D’accord. Pour résumer, e1, e2, e3 constituent l’équipe de la mission m1, tandis que e4 est le chauffeur qui les conduit à destination, au moyen de la voiture v1.

Selon votre MCD, pour la mission m1, la voiture v1 est la seule voiture concernée, donc elle est affectée à la mission m1, du début à la fin de celle-ci.

Dans ces conditions, je propose la modélisation suivante :

Cela peut paraître surprenant, car il n’y a pas de lien entre les entités-types Chauffeur et Voiture (l’association Conduire de votre MCD ayant disparu)...
En fait, dans votre MCD, l’association Conduire dit simplement que tel chauffeur, disons a4, peut conduire telles voitures de service, v1, v2, v3, etc., mais en réalité il est susceptible de conduire n’importe laquelle d’entre elles, et rien ne dit qu’il a été affecté à la mission m1...

Il faut appeler un chat, un chat. J’ai donc défini une association Affecter, signifiant qu’a telle mission, disons m1, a été effectivement affecté tel chauffeur, en l’occurrence a4. Quelle voiture a donc conduit le chauffeur a4 à l’occasion de la mission m1 ? La connaissance de cette voiture est satisfaite grâce à l’association UtiliserVoiture, selon laquelle pour telle mission on a utilisé spécifiquement telle voiture. D’accord, c’est une méthode de déduction à la façon de l’inspecteur Columbo, mais elle fonctionne et elle suffit...

Cas de l’utilisation d’une voiture personnelle

L’employé e1 fait partie de l’équipe chargée de la mission m1. Supposons que ce soit lui qui conduise ses collègues : on le retrouvera non seulement dans l’entité-type EmployeMission, mais aussi dans l’entité-type spécialisée Chauffeur et sa voiture devra être présente dans la table dérivée de l’entité-type Voiture.

La suite au prochain numéro, en attendant, dodo...

En passant, quel est votre SGBD ? Vu le modèle de votre 1er message, ce serait SQL Server. Exact ?

Merci pour les concernant mon message précédent, mais vous n’avez pas ...

[dalinbm]

En passant, quel est votre SGBD ? Vu le modèle de votre 1er message, ce serait SQL Server. Exact ?

Oui, c'est bien dit , J'applique les modifications très prochainement. Mes grand remerciements