Discussion :

[fsmrel]

Bonjour,

A propos des contraintes merisiennes

Je vous renvoie à l’ouvrage que j’ai déjà évoqué, Ingénierie des systèmes d'information - Merise deuxième génération.
Il traite notamment des contraintes sur spécialisation (cf. II-D-3-j. Contraintes sur spécialisation).

Dans le cas des chauffeurs, vous avez choisi la contrainte de partitionnement :

Au résultat :

Mais le partitionnement suppose qu’il y ait au moins deux entités-sous-types alors qu’ici il n’y en a qu’une seule. Pour mémoire, "XT" signifie exclusion et totalité des sous-types.

Dans ce contexte, Looping vous propose un choix de contraintes, et pour ma part, j’avais retenu :

Au résultat :

A propos du principe d’essentialité, de parcimonie :

Dans votre MCD, l’entité-type Chauffeur est porteuse de l’attribut Permis_Conduire. A mon sens, il est implicite qu’un chauffeur ait son permis de conduire. Cet attribut est-il essentiel ici ? Le supprimer serait-il préjudiciable ? Autrement dit, pensez-vous prévoir des requêtes faisant intervenir les permis de conduire ?

[escartefigue]

Bonsoir,

Quelques observations après relecture rapide du dernier MCD :

• je ne suis pas convaincu de l'utilité du sous-type [VoiturePersonnel] : il ne possède aucun attribut et ne fait l'objet d'aucune association. À confirmer.
• une réservation ne devrait pas porter sur un hôtel, mais sur une chambre d'hôtel. Il faut donc modéliser un type d'entité [chambre], identifié relativement à son [hotel]
  soit [CHAMBRE] 1,1(R) --- (appartenir) --- 1,n [HOTEL]
  La réservation pouvant porter sur plusieurs chambres.
• La réservation est ici décorrélée de l'employé, on ne sait donc pas qui réserve...
• en l'état, il n'y a aucune garantie de cohérence entre le type de transport et le véhicule effectivement utilisé pour la mission.
  On peut donc avoir un type "tramway" mais se déplacer en voiture.
• selon votre MCD, on ne connait que la dernière affectation d'un employé à un service. Si la conservation de l'historique est requise, il faut que l'association (Emp_Serv) devienne ternaire, en lien avec une nouvelle entité-type [DATE]
  Et comme je suppose qu'un employé n'est affecté qu'à un seul service à un instant "t", il faudra mettre en place une contrainte pour s'en assurer (c'est d'ailleurs très simple avec Looping )

Bien évidemment, j'abonde dans le sens des remarques des autres éminents contributeurs

[fsmrel]

Quelques observations après relecture rapide du dernier MCD

Ne t’inquiètes pas, Capitaine, on progresse pas à pas, didactisme en bandoulière. Chaque chose en son temps.

[dalinbm]

Bonsoir,

Dans votre MCD, l’entité-type Chauffeur est porteuse de l’attribut Permis_Conduire. A mon sens, il est implicite qu’un chauffeur ait son permis de conduire. Cet attribut est-il essentiel ici ? Le supprimer serait-il préjudiciable ? Autrement dit, pensez-vous prévoir des requêtes faisant intervenir les permis de conduire ?

il me faut une identification unique , je pense au code de permis de conduire comme solution ...

[dalinbm]

Bonsoir,
merci infinement pour vos conseilles et vos remarques ....

[*]je ne suis pas convaincu de l'utilité du sous-type [VoiturePersonnel] : il ne possède aucun attribut et ne fait l'objet d'aucune association. À confirmer.

bien dit..fsmrel ma proposer une autre solution.

[*]une réservation ne devrait pas porter sur un hôtel, mais sur une chambre d'hôtel. Il faut donc modéliser un type d'entité [chambre], identifié [B]

la reservation est en charge de demandeur du la mission(site distant) ... peut etre je dois le faire apres ....

[*]selon votre MCD, on ne connait que la dernière affectation d'un employé à un service. Si la conservation de l'historique est requise, il faut que l'association (Emp_Serv) devienne ternaire, en lien avec une nouvelle entité-type [DATE]
Et comme je suppose qu'un employé n'est affecté qu'à un seul service à un instant "t", il faudra mettre en place une contrainte pour s'en assurer (c'est d'ailleurs très simple avec Looping )

... c'est un affaire pour les RH , je pense qu'elle ne pose aucun problem pour le moment,mais merci pour votre remarque

la conservation de l'historique est requise

... pardons ..l'historique de koi ???

grand merci aussi pour fsmrel

[fsmrel]

Merci pour les fleurs !

il me faut une identification unique , je pense au code de permis de conduire comme solution...

 
Dans le schéma ci-dessous, l’entité-type Chauffeur n’a apparemment pas d’identifiant : en réalité elle en a un ! En effet elle hérite de celui de l’entité-type Employe (regardez le code SQL produit par Looping).

Si par exemple on veut connaître le nom du chauffeur de la mission m1, on l’obtiendra par jointure des tables Mission, Chauffeur, Employe.

Et voilà.

[dalinbm]

bonsoir fsmrel,
si je le met sans attribut ,lors de passage vers MLD il me donne :
Impossible de générer le script SQL :
voir les erreurs dans le MLD textuel

[Paprick]

Bonsoir,

bonsoir fsmrel,
si je le met sans attribut ,lors de passage vers MLD il me donne :
Impossible de générer le script SQL :
voir les erreurs dans le MLD textuel

Je pense que l'erreur vient d'ailleurs : merci de renvoyer la dernière version de votre MCD.

[fsmrel]

dalinbm,

Avec le MCD que j’ai présenté, tout se passe bien. Affichez déjà le vôtre.

Courage !

[dalinbm]

Bonsoir, et merci

[fsmrel]

Selon votre MCD, l’entité-type Employe est devenue sous-type de Chauffeur alors que c’est le contraire. inversez le sens de la flèche.

[Paprick]

Selon votre MCD, l’entité-type Employe est devenue sous-type de Chauffeur alors que c’est le contraire. inversez le sens de la flèche.

C'est tout à fait ça

[fsmrel]

Bonjour à tous,

Je ne voulais aborder l’histoire des réservations et autres sujets, qu’une fois entérinée la modélisation des affectations des chauffeurs, mais les circonstances font que je dois ouvrir une parenthèse.
 
 

une réservation ne devrait pas porter sur un hôtel, mais sur une chambre d'hôtel. Il faut donc modéliser un type d'entité [chambre], identifié relativement à son [hotel]
soit [CHAMBRE] 1,1(R) --- (appartenir) --- 1,n [HOTEL]
La réservation pouvant porter sur plusieurs chambres.
La réservation est ici décorrélée de l'employé, on ne sait donc pas qui réserve...

 
Du temps où je faisais partie de ma SSII, quand je partais en mission avec mes collègues, nous constituions une bande de N joyeux drilles. Notre secrétaire, Nicole, dite Nini, s’adressait à un hôtel et réservait N chambres. A charge de l’hôte d’affecter les chambres, mais Nini (pas plus que le comptable) n’était pas concernée par ce genre de cuisine. Tout ce dont elle avait besoin, c’était les coordonnées de l’hôtel et le montant de la facture. Inutile donc de modéliser une entité-type Chambre.

Exemple de scénario

A priori, Nini prend contact avec un seul hôtel. Mais il arrive pour des problèmes de disponibilité des chambres qu’il faille répartir les employés de la mission dans plus d’un hôtel. Le MCD en tient donc compte. L’association Reservation permet de connaître la date de réservation (mais si la date de réservation correspond toujours à la date de début de la mission, elle peut disparaître). L’association permet aussi de connaître le nombre de chambres (nombre dont le total doit être égal au nombre d’employés affectés à la mission). Et bien entendu, la réservation a un certain montant :

Dalinbm, quelle est votre scénario ?

[dalinbm]

Bonjour,
Pour notre établissement, comme je l'ai déjà dit, le demandeur de mission (locale ou distant) prend en charge du la réservation des chambres tel que il y a un nombre bien déterminée des hôtels (max 2) conventionnée avec le nôtre, et qui sont à tout moment disponible pour la réservation , quel que soit la situation, bon parfois il arrive que l'un de ces hôtels est plein donc il y a passage vers un autre. C’est une structure présent dans tous les bureaux régionales qui s’en charge de cet affaire, juste avant de planifier la mission, il faut cordonnée avec ce dernier (comme dans votre cas Nini)

[fsmrel]

D'accord,

La modélisation que j’ai présentée vous convient-elle ? suffit-elle ?

[dalinbm]

bonjour,
je m'excuse, un autre error lors de l'insertion des données dans la table mission:

INSERT INTO [dbo].[Mission]([Id_Mission],[date_Debut],[Date_Fin] ,[Objectif],[IdEmploye],[Id_Type_Mission]) VALUES (801,'2024-09-10 8:00:00' ,'2024-09-16 8:00:00','test5',700,610)
GO
error :
The INSERT statement conflicted with the FOREIGN KEY constraint "FK__Mission__IdEmplo__4222D4EF". The conflict occurred in database "Mission", table "dbo.Chauffeur", column 'IdEmploye'.



sauf dans le cas d'un chauffeur :

[dalinbm]

D'accord,

La modélisation que j’ai présentée vous convient-elle ? suffit-elle ?

oui bien sure ...

[fsmrel]

Si je prends ma casquette « inspecteur Colombo », je constate que l’erreur a lieu lors de l’insert dans la table Mission. Cette table a une clé étrangère de valeur "710" qui cible la table Chauffeur, laquelle doit donc contenir une ligne ayant pour valeur de clé primaire "710". A son tour, la table Employe doit elle aussi contenir une ligne ayant pour valeur de clé primaire "710" puisque référencée par la clé étrangère de la table Chauffeur.

[dalinbm]

Rebonjour,Merci inspecteur Colombo, le problème c'est que , d'après votre investigation, il faut mettre tous les employés qui peuvent se déplacer avec leur voiture personnelle ainsi que les chauffeurs (leur fonction dans la ste : chauffeur) dans la table chauffeur...un peut bizarre...

[fsmrel]

Merci inspecteur Colombo, le problème c'est que , d'après votre investigation, il faut mettre tous les employés qui peuvent se déplacer avec leur voiture personnelle ainsi que les chauffeurs (leur fonction dans la ste : chauffeur) dans la table chauffeur...un peut bizarre...

Ça paraît bizarre, mais prenons le cas suivant :

L’employé e1 participe à la mission m1.

Il sert aussi de chauffeur pour l’équipe (e1, e2, e3).

Pour cela il utilise sa propre voiture v1, laquelle doit alors être enregistrée dans la table Voiture.

Pour autant on n’est pas obligé d’enregistrer dans la table Chauffeur tous les agents ayant une voiture et dans la table Voiture toutes les voitures des agents qui en ont une, soyons parcimonieux ! En fin de mission on peut du reste supprimer e1 dans la table Chauffeur et v1 dans la table Voiture...

Comment Colombo saura que c’et la voiture v1 et pas une autre qui est celle de e1 ?

Par jointure des tables Mission, EmployeMission et Employe, on apprend que e1 est affecté à m1.
La table Mission nous apprend que le chauffeur est aussi e1. Par jointure des tables Mission et Voiture on apprend que c’est v1 qui est utilisée pour m1. Ainsi e1 conduisant v1, il s’agit donc de sa propre voiture et du coup, il sera bénéficiaire des frais inhérents.

Do you follow me ?