Discussion :

[Energylite]

Bonjour à tous,

Je sollicite votre aide pour un éventuel retour sur la conception, ou plutôt la visualisation,d'une BDD via UML. Je dois vous avouer que je ne suis pas un expert des bases de données puisque j'ai légèrement étudié cette discipline dans mon parcours d'étude.

Voici le contexte de la BDD et le projet global qui gravite autour.
Cette BDD gère l'arrêt technique de bateau de plaisance, les employés du service des arrêts techniques ainsi que leur planning.

Voici comment je visualisais le tout:
Les employés disposent de différentes informations leur concernant comme le type de contrat auquel ils sont soumis, le type d'habilitation qu'ils possèdent, leur appartenance à une équipe de travail et le rattachement à un supérieur qui est leur manager. Ce manager est aussi rattaché à son supérieur. la classe employés est utilisé par la suite pour l'organisation du planning via l'affichage des plages d'absences, de formations, de vacances et de missions de travail.
Ces mêmes employés travaillent sur des arrêts techniques régis par un code de tache. Par exemple repeindre le bateau correspond au code tache P01.

Ces arrêts techniques prennent en compte les bateaux, leur type ainsi que leur nom de code. L'emplacement où est effectué l’arrêt technique dans le port correspond au gisement alors que le site correspond à l'endroit géographique du port.
Bien évidement, on dispose d'un budget pour faire les travaux d'où la présence de la classe budget rattaché à la classe des arrêts techniques.

Il se peut que notre employé ai besoin d'un véhicule et que des personnes l'accompagne pour sa mission de travail.
Par ailleurs, le statut de l'avancement des travaux sur le bateau est régis par la classe statut.

Dans son ensemble, les liaisons entre classe sont, pour ma part, un héritage dans la mesure où les classes sources influent sur les classes clientes sauf pour la classe véhicule qui n'est pas obligatoire, de même pour les passager d'un véhicule qui sont facultatifs.

Je me suis aidé des différentes documentations que vous avez mis à disposition sur votre site et bien évidement, d'autre site. J'espère avoir bien compris cette étape de modélisation de la BDD et espère la mettre en œuvre prochainement après consultation de vos retours !

Cordialement,
ENERGYLITE

[escartefigue]

Bonjour,

Ce schéma semble être un MLD plutôt qu'un diagramme de classe.
J'ai du mal à le déchiffrer, le zoom est inopérant. Il faudrait le découper en sous ensembles pour que ce soit plus facile à lire.

[Energylite]

Bonjour,

C'est étrange que vous ne puissiez pas zoomer sur l'image (même lors d'une ouverture dans un nouvel onglet).
De toute manière, je vous ai découpé l'image en sous ensemble !

[escartefigue]

Ce modèle suscite de nombreuses interrogations et remarques

Pour la partie employé, manager et contrat, le modèle proposé implique que les managers n'ont pas de contrat de travail. Je serais surpris que ça corresponde à la réalité !
Pour pouvoir valider le modèle de données, il faut présenter les règles de gestion sous la forme suivante :

R001a : une personne peut encadrer d'autres personnes
R001b : une personne est encadrée par au plus une autre personne

R002a : un personne qui contracte un contrat de travail est un employé
R002b : un contrat est contracté par un et un seul employé

il faudra probablement prévoir la notion d'avenant au contrat de travail et donc les règles de gestion correspondantes

Concernant la partie habilitation, la façon la plus courante de les gérer est d'associer ces habilitations à des profils métier et d'associer les personnes à ces profils.
Par exemple, le droit à créer, modifier et consulter un contrat client correspond au profil "gestionnaire de contrat client". Toutes les personnes embauchées dans le service de gestion des contrats clients seront rattachées à ce profil. Ce qui permettra de leur attribuer automatiquement les habilitations correspondantes. C'est beaucoup plus simple que de faire les habilitations pour chaque personne.

Les règles de gestion sur ce point seraient donc :
R010a : chaque personne, employée ou non, est rattachée à un et un seul profil métier
R010b : un profil métier peut être rattaché à plusieurs personnes

R011a : pour chaque profil métier sont attribués une ou plusieurs habilitations
R011b : une habilitation peut être attribuée à plusieurs profils métiers


Ce qui donne le modèle entité-association suivant :



Et le diagramme UML associé :



Il faut bien entendu adopter la même démarche pour les autres parties du diagramme : rédiger les règles de gestion en leur attribuant un identifiant, puis modéliser en conséquence

EDIT il y a une coquille sur les cardinalités de [CONTRAT] vers (contracter). C'est 1,1 qu'il faut mettre bien sûr pour être conforme à la règle R002a
EDIT il y a une autre coquille (décidément !) : dans mon esprit debval et finval sont les dates de début et de fin de validité, ce faisant, finval est de type "date" et non pas "varchar" (valeur par défaut que j'ai oublié de modifier)

[Energylite]

Bonjour !
Désolé de la réponse tardive, le week-end fût mouvementé de mon côté. Enfin passons ces détails si vous le voulez bien

Concernant la partie manager, je m'étais inspiré de cette modélisation vue sur un tutoriel de modélisation rédigé par Monsieur Laurent AUDIBERT où ce monsieur présente une auto-association sur une classe-association. Je me suis dis que cette représentation devait être valable sur une classe.
(voici le lien :https://laurent-audibert.developpez....classes#L3-5-2).


Pour développer un peu plus le côté manager, la BDD et le site qui va se servir de cette BDD est adressé à ces managers. De plus, concernant l'avenant au contrat de travail, cela veut dire qu'il faut prévoir une autre classe traitant de cette modification ? Puisque sur la classe travail, j'avais prévu une opération "modification" si il devait y avoir des changements de contrats pour les employés.

Je suis entièrement d'accord avec vous pour la partie des habilitations, c'est vrai que c'est beaucoup plus simple d'après votre explication mais en rédigent ma réponse à votre message, j'ai pensé à cela, que se passe t-il si une personne a plusieurs habilitations dans le cadre d'une formation ou d'une mise à niveau des compétences ? Cette personne bénéficiera de plusieurs profils métier donc ne sera plus en mesure de respecter votre première règle de gestion "R010a : chaque personne, employée ou non, est rattachée à un et un seul profil métier".

Cela se voit que je ne suis absolument pas familier avec les BDD, je n'ai même pas eu la connaissance de l'étape d'entité-association à faire avant de modéliser d'UML ...

Je me remets de suite au travail et vous remercie d'avoir pris le temps de rédiger une réponse à mon post sur ce forum !

[escartefigue]

Re

De plus, concernant l'avenant au contrat de travail, cela veut dire qu'il faut prévoir une autre classe traitant de cette modification ? Puisque sur la classe travail, j'avais prévu une opération "modification" si il devait y avoir des changements de contrats pour les employés.

Si l'avenant est une simple modification du contrat et qu'on n'a pas besoin de conserver le contrat initial, alors une nouvelle entité-type [AVENANT] n'est pas nécessaire.

que se passe t-il si une personne a plusieurs habilitations dans le cadre d'une formation ou d'une mise à niveau des compétences ? Cette personne bénéficiera de plusieurs profils métier donc ne sera plus en mesure de respecter votre première règle de gestion "R010a : chaque personne, employée ou non, est rattachée à un et un seul profil métier".

Ce n'est pas un souci, dans le cadre de sa formation, l'employé utilisera un code utilisateur spécifique lié à cette formation, ce login sera rattaché au profil métier visé par cette formation, profil métier qui sera associé à une ou plusieurs habilitations.
Autre possibilité : la formation étant le plus souvent réalisée sur un environnement de formation spécifique, il n'y a pas de problème pour attribuer à cet utilisateur un profil métier différent dans cet environnement de son profil métier de production.

Exemples de rattachements :
code utilisateur U0001 rattaché au profil métier 'PM001' (gestionnaire de contrat client)
code utilisateur U0002 rattaché au profil matier 'PM002' (comptable)

PM001 est habilité aux fonctions suivantes :
FCL002 : modifier un compte client
FCL003 : consulter un compte client
FCO001 : créer une commande client
FCO002 : modifier une commande client
FCO003 : consulter une commande client

PM002 est habilité aux fonctions suivantes :
FCL001 : créer un compte client
FCL004 : clôturer un compte client
FCO003 : consulter une commande client

je n'ai même pas eu la connaissance de l'étape d'entité-association à faire avant de modéliser d'UML ...

Il n'est pas nécessaire de faire un diagramme EA avant le diagramme UML, ce sont juste deux formalismes différents.
Je préfère le formalisme EA que je trouve plus clair, comme j'utilise Looping avec lequel passer de l'un à l'autre se fait en un clic, c'est plus facile pour moi de procéder ainsi