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

[Energylite]

edit: Bonjour

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.

Donc cela veut dire que l'avenant du contrat est une nouvelle classe rattachée à la classe contrat où je vais devoir effectuer un EA en rapport avec ces deux entités. Est-ce qu'il convient de créer une classe "archives" pour archiver l'ancien contrat et faire apparaitre pour la classe employé son avenant en premier plan et non son ancien contrat ?






Pour l'habilitation, cela commence à devenir un peu plus ardu que prévu. J'ai demandé à des collègues comment fonctionnait leur système d'habilitation. Je vais essayer d'expliquer au mieux (je n'ai pas la fibre pédagogique)

Le département dans lequel je suis actuellement est divisé en plusieurs services où officient plusieurs techniciens.
Prenons le cas de Olivier et David, deux techniciens du même service d'électricité par exemple.
Ils appartiennent donc au profil de métier "électricien"/"électrique" mais Olivier n'a qu'une habilitation électrique basse tension tandis son collègue à une habilitation électrique basse et haute tension. Sur ces habilitations basse tension, Olivier est habilité "chargé de travaux" au contraire de David qui est habilité "intervenant". De plus, David est un "chargé de travaux" sur l'habilitation haute tension.
Pour des raisons de coûts, le manager du sous-services (qui n'a aucune des habilitations existante mais qui appartient au service "électricité") a fais suivre une montée de compétences à David et Olivier. David à eu une habilitation pour faire des interventions suspendus avec un harnais et Olivier a eu une habilitation pour la conduite d'un chariot élévateur.

Le fonctionnement en classe de métier ne me parait pas adéquat ou alors difficile à mettre en place (je ne maitrise pas les arcanes de la BDD donc je n'ai pas vraiment de recul et d'expérience) au vue des nouvelles informations de gestions des habilités que j'ai eu aujourd'hui. Car du fait qu'ils sont du même services, cela voudrai dire qu'ils partageraient les mêmes habilitations avec les même spécificités. Hors ce n'est pas le cas dans la situation ici présente. Aussi, la spécificité de l'habilitation est à prendre en compte maintenant .

De mon point de vue, cela me paraissait plus simple de renseigner les habilitations une à une pour un employé du fait des nombreuses catégories qu'il peut y avoir dans les habilitations. C'est vrai que si chaque employés avaient une habilitation bien définie (électricien: basse tension et haute tension, conducteur de chariot: conduire des chariot etc) en fonction de leur appartenance à un service ce serait plus simple et moins prise de tête.

Après réflexion, il me semble plus juste de créer une classe "métier" (qui correspondait à ma classe "équipe") où est rattachée deux autres classes. La première liée à la classe métier du service qui peut être optionnelle qui correspondrai à la classe primaire avec ses spécifications associées et une classe secondaire qui correspondrait à l'ajout d'habilitations et aussi de ces caractéristiques. L'ajout des habilitations se ferait malheureusement à la main, une à une.

Qu'en pensez-vous ?

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

Malheureusement Looping est interdit dans mon entreprise

[escartefigue]

Bonjour,

Est-ce qu'il convient de créer une classe "archives" pour archiver l'ancien contrat et faire apparaitre pour la classe employé son avenant en premier plan et non son ancien contrat ?

Ce qu'il convient de faire dépend des instructions du donneur d'ordre, toutes les solutions sont envisageables : création d'une classe "avenant" en plus de "contrat", recopie de "contrat" dans "contrat archive", voire rien du tout. À voir avec la maîtrise d'ouvrage pour savoir ce qui est nécessaire.

Le département dans lequel je suis actuellement est divisé en plusieurs services où officient plusieurs techniciens.
Prenons le cas de Olivier et David, deux techniciens du même service d'électricité par exemple.
Ils appartiennent donc au profil de métier "électricien"/"électrique" mais Olivier n'a qu'une habilitation électrique basse tension tandis son collègue à une habilitation électrique basse et haute tension. Sur ces habilitations basse tension, Olivier est habilité "chargé de travaux" au contraire de David qui est habilité "intervenant". De plus, David est un "chargé de travaux" sur l'habilitation haute tension.
Pour des raisons de coûts, le manager du sous-services (qui n'a aucune des habilitations existante mais qui appartient au service "électricité") a fais suivre une montée de compétences à David et Olivier. David à eu une habilitation pour faire des interventions suspendus avec un harnais et Olivier a eu une habilitation pour la conduite d'un chariot élévateur.

Attention : il ne faut pas confondre les gestes métier (réaliser des branchements basse tension, haute tension, entretenir tel équipement électrique etc.) et l'accès au système d'information.
La notion de profil métier dans le cadre des habilitations a pour vocation de gérer les accès à telle ou telle fonction du système d'informations
Si Olivier et David ont besoin des mêmes accès au système d'information, bien que faisant des opérations différentes, alors ils peuvent partager le même profil métier (par exemple, ils ont tous les deux besoin d'accéder en mise à jour au stock informatique de pièces détachées).

De mon point de vue, cela me paraissait plus simple de renseigner les habilitations une à une pour un employé du fait des nombreuses catégories qu'il peut y avoir dans les habilitations.

C'est très rarement le cas, tout d'abord pour les raisons que j'ai données plus haut (ne pas confondre le métier et l'accès au S.I.)
L'utilisation de profils métiers est évidemment d'autant plus intéressante que le nombre d'employés ayant besoin d'accéder de la même façon au système d'information est important. Mais même s'il y a peu d'employés par profil métier, c'est une solution intéressante, car quand un nouvel employé est embauché à tel poste, on sait qu'il faut lui appliquer tel profil sans avoir à se poser de questions.

Malheureusement Looping est interdit dans mon entreprise

Peut être que votre logiciel de modélisation utilisé permet aussi de basculer du modèle E/A au modèle UML ?

[Energylite]

Bonjour !
Je reviens vers vous après avoir pris en compte vos remarques de votre dernier message ! je tiens a vous remercier de vos réponses que vous rédigez sur votre temps libre ("je suppose").
Au final j'essaie de modéliser la BDD via votre méthode E/A, même si le MLD correspondant à la modélisation de ma BDD me fais beaucoup réfléchir pour comprendre l'attribution des clé étrangères sur certaines classe. Je vous joins ma modélisation au message.

Ce qu'il convient de faire dépend des instructions du donneur d'ordre, toutes les solutions sont envisageables : création d'une classe "avenant" en plus de "contrat", recopie de "contrat" dans "contrat archive", voire rien du tout. À voir avec la maîtrise d'ouvrage pour savoir ce qui est nécessaire.

Je dois présenter une première ébauche du projet donc je préfère couvrir un maximum d'angles et de fonctionnalité que possible pour le développement de cet outil. De plus, c'est aussi un apprentissage supplémentaire sur un domaine qui m'étais totalement étranger il y a encore une semaine.

Attention : il ne faut pas confondre les gestes métier (réaliser des branchements basse tension, haute tension, entretenir tel équipement électrique etc.) et l'accès au système d'information.
La notion de profil métier dans le cadre des habilitations a pour vocation de gérer les accès à telle ou telle fonction du système d'informations
Si Olivier et David ont besoin des mêmes accès au système d'information, bien que faisant des opérations différentes, alors ils peuvent partager le même profil métier (par exemple, ils ont tous les deux besoin d'accéder en mise à jour au stock informatique de pièces détachées).
C'est très rarement le cas, tout d'abord pour les raisons que j'ai données plus haut (ne pas confondre le métier et l'accès au S.I.)

Mais de toute manière, la base de donnée sera accessible que pour les managers. Je l'ai peut être mal expliqué mais omis mais la confection de la base de données vient d'un fichier Excel d’ordonnancement qui gère les l'arrêt technique de bateau de plaisance, les employés du service des arrêts techniques ainsi que leur emploie du temps d'où le fait que les habilitations définissent plus le niveau de compétence pratique requise pour effectuer des travaux que des compétences d'accès au SI.
Peut être que je suis dans le faux et que le fonctionnement des habilitations que j'ai décrit est en tout point identique à vos explications.

Je vais commencer la parties emplois du temps qui, d'après ce que j'ai compris, est l'élément le plus difficile a concevoir dans une BDD. J’espère que ce tutoriel https://sqlpro.developpez.com/cours/gestiontemps/ pourra m'aider dans sa réalisation, du moins dans sa modélisation !

Peut être que votre logiciel de modélisation utilisé permet aussi de basculer du modèle E/A au modèle UML ?

Au final, je peux utiliser l'outil qui est bien plus pratique que mon outil de modélisation d'UML.

EDIT: Petit couac au niveau de la clé primaire de la classe véhicule qui est bien évidement un int !

[escartefigue]

Du coup il ne s'agit pas de gérer des habilitations au S.I. mais les qualifications et compétences des employés.
Ce que j'ai modélisé plus haut a peut être son utilité pour les mangers, s'ils n'ont pas tous les mêmes habilitations, sinon oubliez cette partie.
Je vais devoir m'absenter 2 ou 3 jours, je réfléchirai sur la modélisation des compétences métier à mon retour

À bientôt donc

[Energylite]

Bonsoir !

Du coup il ne s'agit pas de gérer des habilitations au S.I. mais les qualifications et compétences des employés.

C'est bien cela, je vous présente mes excuses si l'explication de mon projet est brouillon.

Je vous souhaite un bon week-end et si des idées me traverse l'esprit au fur et à mesure que j'effectue mes recherches soyez sûr que j'alimenterai ce topic !

Je vous remercie déjà par avance pour votre aide.

[escartefigue]

Me voilà de retour de ces trop courtes vacances

Concernant la qualification des employés, il ne faut bien sûr, comme tout le reste, ne les modéliser que si elles sont utiles (par exemple pour affecter les tâches au personnel qualifié pour).
Si c'est le cas, faut il associer ces qualifications à des diplômes, certifications ou autres documents attestant la réalité de la qualification ?
À préciser.

[Energylite]

Bonjour !

C'est vrai que ces vacances étaient courtes mais toutes les bonnes choses ont une fin

Concernant la qualification des employés, il ne faut bien sûr, comme tout le reste, ne les modéliser que si elles sont utiles (par exemple pour affecter les tâches au personnel qualifié pour).
Si c'est le cas, faut il associer ces qualifications à des diplômes, certifications ou autres documents attestant la réalité de la qualification ?
À préciser.

La qualification est utile et nécessaire pour préciser l'affectation des arrêts techniques possible pour un employés. Certain sont liés à leur appartenance à l'équipe de travail et donc par extension aux diplômes et d'autres non. Par exemple un électricien peut avoir une certification haute/basse tension car c'est un électricien mais un mécanicien ne peut pas avoir ces certifications. Les deux corps de métier peuvent par exemple avoir l'habilitation pour le maniement d'un chariot élévateur.

Je pense que dans la configuration actuelle du service, il ne faut pas lier les certifications à de quelconques diplômes. La table aura juste un lien de relations avec les employés. Aussi, la spécification pourra être utile lors d'une recherche dans la BDD d'employé ayant une qualification particulière.