Discussion :

[khawla b]

Bonsoir ,

je suis en train de modéliser une application de gestion de candidature en ligne .en fait c une solution à pour but d'accompagner le service RH dans leurs tâches quotidiennes.

Nous avons 4 acteurs : Admin, Commercial, Candidat, RH
admin gère les comptes utilisateurs, il peut (voir , ajouter, modifier, supprimer) commercial , RH.

Commercial :

Liste des nouveaux candidats ayant postulé sur nos offres accessible en cliquant sur le nombre.
voir L’ensemble des CV présents dans la base, classés selon leur statut.
Aperçu le CV d'un candidat.
Recherche « full-text » dans le CV, la lettre de motivation ou les notes attachées aux candidats
voir la liste des candidats, affichée sous forme de tableau.
Gestion de la relation candidat : mailing, réponse auto ou manuel.
importer le CV d'un candidat par analyse sémantique, qui permet de compléter le formulaire automatiquement.
voir l'historique du suivi du candidat
Suivi, traçabilité et historisation de toutes les actions candidats
Exportater des données au format MS Office

Gestion des offres par catégories.
Recherche Multi-critères, plein texte, par entreprise....
Nombre de candidatures par offre
Création, modification et publication des offres
Liste des candidatures ayant postulées
Recherche géographique d'un candidat.
Transférer la fiche d’un candidat au opérationnels ou a un client

Tableau de suivi des candidats qui indique l’avancement des candidatures et les descriptions éventuelles de l’avancement

RH

gère les comptes , il peut (voir , ajouter, modifier, supprimer) commercial , RH.
Gestion partenaires et médias de diffusion
Envoi par email vers les sites partenaires
Création, modification des clients et des filiales
Prise de rendez vous directement dans Outlook

Donc pour tenter de mettre en place le diagramme de classe de façon plus simple et souple, j'ai pensé a faire de l'héritage (tous les utilisateurs hérite de la classe user ) mais alors comment représenter l'héritage avec MySQL Workbench ?

Ou alors, si quelqu'un a déja travaillé sur un projet similaire, comment a t-il présenter les classes et les relations entre eux ?

Merci.

[CinePhil]

Bonjour,

Principe de l'héritage de données dans une base de données...

Règle de gestion :
Un utilisateur peut être un administrateur et un administrateur est un utilisateur.

MCD méthode Merise :
Administrateur -(1,1)----être----0,1- Utilisateur

Diagramme de classe UML :
Administrateur -0..1----------1..1- Utilisateur

Entity/relationship diagram de MySQL Workbench :


Il faut utiliser le "1:1 identifying relationship" puis double-cliquer sur la relationship, aller dans l'onglet "Foreign key" de la relationship et dé-sélectionner la "Mandatory" de la "referencing table".

Remarque : la clé primaire de la table Administrateur sera la clé étrangère référençant la table Utilisateur.

[fsmrel]

Bonsoir,

Voir aussi cette partie de l’article sur MySQL Workbench.

[khawla b]

Bonsoir ,

Merci pour votre réponse , j'ai suivi ton conseil et voila mon nouveau diagramme de classe . je sais pas est ce que c juste de modéliser la classe rôle de la cette manière!
Est ce que les cardinalités entre les différents classe de diagramme sont-t-ils juste ??

[CinePhil]

Entrons donc un peu dans le détail de ce schéma...
Et puisqu'il s'agit d'un schéma de base de données relationnelle fait avec un outil destiné à modéliser une telle base pour MySQL, bien que les cardinalités utilisées soient de la fome d'un diagramme de classe UML, je préfère parler de tables et de colonnes.

1) Que représentent la colonne "name" dans les tables ADMIN, RH et COMMERCIAL ?
Comme elles sont de type INT, la question se pose encore plus !

2) Quelle que soit la réponse à la première question, comme cette colonne "name" apparaît dans les trois tables qui héritent de la classe USER, c'est donc, semble t-il, une colonne commune à tous les USER qui doit figurer dans la table USER. À moins que cette colonne soit finalement inutile ?

3) Un type TEXT (dans la table ROLE) est à réserver pour les textes longs et n'est surtout pas à utiliser comme clé primaire d'une table.
La table ROLE devrait plutôt être composée par exemple ainsi :
role_id INTEGER PRIMARY KEY,
role_code CHAR(5) NOT NULL (avec une clé unique sur cette colonne si elle est pertinente),
role_libelle VARCHAR(48) NOT NULL

4) Il faudrait externaliser certaines colonnes de la table CANDIDAT
4.1) Si vous cherchez, par exemple, tous les candidats de Saint-Étienne et que cette ville est parfois écrite Saint Etienne, St. Etienne, St Étienne ou sous une autre forme, vous allez perdre des candidats en route. Il est donc préférable d'avoir une table de référence de villes, au moins du principal pays de l'application. Vous pourrez trouver des référentiels de villes françaises ou du monde sur internet assez facilement.

4.2) La civilité est à choisir parmi un nombre restreint de valeurs (Monsieur, Madame, Mademoiselle, Maïtre, Professeur...). Il convient donc de créer une table de référence des civilités qui comprendra l'abréviation et le libellé complet de la civilité. Au passage, ça m'étonnerait que des civilités qui vous intéresseront fassent jusqu'à 45 caractères !

4.3) Idem pour la situation familiale, pour le niveau d'études... à vous de voir si d'autres propriétés sont externalisables selon le même principe qui consiste à créer une table de référence et d'associer celle-ci aux tables qui en ont besoin.

4.4) Concernant les langues, elle doivent, elles aussi, être externalisées, de manière à trouver facilement les candidats qui parlent Italien en cherchant la clé étrangère référençant cette langue dans la table associative entre les langues et les candidats.

MCD : candidat -1,n----parler----0,n- langue

Dans la table associative, vous pouvez ajouter une colonne booléenne pour indiquer si c'est la langue maternelle ou bien faire une association avec les niveaux en langue (notions, débutant, pratique professionnelle, pratique courante, langue maternelle).

5) Que représente "TitreCandidature" ? Un type MEDIUMTEXT me semble bien long pour un titre !

6) Même remarque sur la longueur pour le Diplome, le NiveauExperiencePro, CompetenceExtraPro, ResumeCV...

7) L'association entre CANDIDAT et EVALUATION ne me semble pas bonne.
Un candidat peut être enregistré sans avoir été encore évalué, non ?
De plus, c'est plutôt l'évaluation qui se réfère à un candidat que l'inverse.
Je vous laisse réfléchir aux bonnes cardinalités à mettre.

8) Que représente la table STATISTIQUE ?
Elle ne contient qu'une clé primaire !

9) Comme pour la table ROLE, le choix de la clé primaire de la table MEDIA n'est pas bon. Il vaut mieux avoir une clé primaire entière et auto-incrémentée.

Voilà quelques remarques à prendre en compte ; je ne vais pas tarder à partir. Je laisse fsmrel vous en faire probablement d'autres.

A+

[fsmrel]

Bonsoir khawla b,

CinePhil a répondu au moment où j’allais poster. Je n’ai pas eu le temps de lire son message, mais on devrait être en phase.

Les cardinalités des associations entre USER et les spécialisations ADMIN, RH, COMMERCIAL et CANDIDAT sont correctes.

Quel est le rôle de l’attribut name pour ADMIN, RH, COMMERCIAL ? ne fait-il pas double emploi avec l’attribut nom de la table USER ? Est-ce juste pour faire du remplissage ?

Quelle est la finalité des tables ROLE et ROLE_HAS_USER ? Merci de donner des exemples concrets.

Vu les cardinalités de l’association entre CANDIDAT et EVALUATION vous avez établi une bijection. Soit, mais la table CANDIDAT a pour clé la paire {USER_idUSER, EVALUATION_idEVALUATION}, d’où surjection, donc contradiction. Le mickey «» symbolise le fait que l’attribut EVALUATION_idEVALUATION participe à la clé primaire de la table USER, ainsi qu’à la clé étrangère référençant la clé primaire de la table EVALUATION. Si l’attribut EVALUATION_idEVALUATION ne participe qu’à la clé étrangère, le mickey doit être le losange rougeâtre «».

A propos de la bijection, je vous demande de méditer ce billet : « Merise : cardinalités 1,1 ---- 1,1 => intégrité référentielle = cautère sur jambe de bois ». Ce qui est écrit vaut pour Merise, mais également pour les autres approches. Dans la série, voyez aussi le point (C) de « Join, le tueur des dinosaures », où le contexte est celui de l’injection, mais les problèmes engendrés ne sont pas tristes non plus.

Indépendamment des problèmes engendrés par la bijection et l’injection, encore à propos de la table EVALUATION, chaque colonne non clé peut être marquée nulle. Si elles le sont toutes, cela revient à dire qu’un candidat a pu ne pas être encore évalué, ce qui reviendrait en l’occurrence à une injection :

[CANDIDAT]—0..1———1—[EVALUATION]

Où EVALUATION hérite de la clé primaire de CANDIDAT.

J’ai encore pas mal de remarques à faire (par exemple concernant SUIVI_CANDIDAT), mais je dois m’absenter, à bientôt donc.

Bon courage !

[khawla b]

Bonjour tout le monde ,


Merci bq pour votre réponse et je suis vraiment désolé d'avoir rependre à notre discussion après 6 jours, malheureusement j'ai été malade.

vu que vous avez presque les mm remarques sur mon diagramme , permettez moi de vous rependre dans un seul commentaire .

1) la colonne "name" dans la classe ADMIN, RH et COMMERCIAL c’était juste pour remplissage au début pour faire la liaison entre les classe et j'ai oublier de le supprimer .

2) je n'avais pas aucune idée sur " la table référence" et comment la modéliser ! ou bien le code sql pour l'implémenter alors j'ai chercher sur internet .

voilà mon nv diagramme j'ai essayé d'externaliser la table "langue , pays, civilité " mais j'ai sais pas est ce que c juste d'avoir une relation 1.. 0.1 juste pour avoir une table référence !!!!


3) concernant la table évaluation , vous avez raison la liaison doit être 1... 1..0 .


cordialement.

[fsmrel]

Bonsoir khawla b,


Si l’on avait affaire à un diagramme de classes UML, le lien que vous avez établi entre CANDIDAT et PAYS serait caractéristique d’une association. Au vu des cardinalités (multiplicités) que vous avez mises en oeuvre, un pays fait référence à au moins un et un seul candidat, tandis qu’un candidat fait facultativement référence à un pays et au plus un :

Dans le contexte de MySQL Workbench, (voyez ici et là) le lien d’association ne se traduit pas par un trait plein, mais seulement en pointillés : les traits pleins sont réservés pour exprimer ce qu’on appelle en UML une composition (voire une spécialisation/généralisation).

Pour signifier qu’un candidat représente au moins un et au plus un pays, et qu’un pays peut être représenté par plusieurs candidats, le diagramme doit être le suivant (dans lequel, en passant, l’attribut [code] doit donner lieu à une contrainte d’unicité (clé candidate)) :

Le losange rougeâtre, accompagnant l’attribut idPays de la table CANDIDAT, symbolise la clé étrangère voulant que chaque valeur prise par l’attribut idPays de la table CANDIDAT soit une valeur prise par cet attribut dans la table PAYS.

En complément de ce qui précède, j’ai représenté ci-dessous quelques corrections à effectuer :

En passant, tout les losanges blanchâtres doivent bleuir (pour alléger le diagramme, j’ai gommé pas mal des attributs concernés).

Si vous avez besoin de plus d’éclaircissements, on pourra essayer de vous les fournir.

vu que vous avez presque les mm remarques...
...
voilà mon nv diagramme...
...

Souvenez-vous que, selon la charte developpez.com, le style SMS n’a pas lieu d’être.

[khawla b]

Bonjour Cinephil ,


j'ai suivi vos conseils et j'ai changé les liens entre les différents classes de diagramme , mais j'ai quelque soucis, par exemple :

1) après avoir publier une offre dans les média de diffusions les candidats qui vont participé , ils vont être ajouter d'une manière automatique dans la base de données précisément dans la table candidat ( donc c un candidat non inscrit ) , comment lui ajouter un mdp !!
que ce que je dois faire sachant que je vais implémenter le spring Security pour faire la sécurité de l'app où je dois avoir une table user contenant les différents utilisateurs avec login et mot de passe.
2) nous avons 4 types de candidats : inscrit , Non inscrit , recruté , refusé , j'ai pensé d'ajouter un attribut status pour différencier les diff types des candidats .
est ce que c juste de faire ça ?


merci d'avance

[CinePhil]

ils vont être ajouter d'une manière automatique dans la base de données précisément dans la table candidat

Puisque la table CANDIDAT hérite de la table USER et a l'identifiant de cette dernière en clé étrangère, il faut que votre programme crée d'abord le USER puis récupère l'identifiant et crée ensuite le CANDIDAT avec ce même identifiant.

comment lui ajouter un mdp

La piste est juste au-dessus : en créant en premier le USER !

où je dois avoir une table user contenant les différents utilisateurs avec login et mot de passe

D'après votre schéma, vous l'avez déjà !

2) nous avons 4 types de candidats : inscrit , Non inscrit , recruté , refusé , j'ai pensé d'ajouter un attribut status pour différencier les diff types des candidats .
est ce que c juste de faire ça ?

Oui, bien sûr ! et une association entre cette table de référence des types de candidat et la table CANDIDAT.

[khawla b]

Dix mercis pour votre aides et vos conseils ))))

si vous n'avez pas de remarque je passe au codage !

[CinePhil]

si vous n'avez pas de remarque je passe au codage !

Je n'ai pas pris le temps de regarder votre schéma en détail.

[escartefigue]

Bonjour,

Certaines tables ont des attributs à externaliser
Par exemple
CANDIDAT
Téléphones fixe et mobiles sont à évacuer de cette entité-type, il faut créer une nouvelle ET (entité-type) "média" et une autre ET "type-media" avec la modélisation suivante
CANDIDAT 0,n --- posseder --- (1,1) MEDIA 1,1 --- typer --- 0,n TYPE_MEDIA
Notez les cardinalité (1,1) entre parenthèses, pour matérialiser l'identification du média relativement au candidat
EDIT : je vois que vous avez déjà créé une ET média pour un autre usage, il faut donc choisir un autre nom, mais le principe reste le même

Langues ne doit pas être un attribut (et encore moins une liste d'attributs comme le suggère votre usage d'un pluriel), mais là aussi une relation 0,n vers une ET langue

Un statut en varchar, c'est suspect, quelle est la vocation de cet attribut et quelles sont les valeurs possibles ?
Là aussi, la mise en œuvre d'une nouvelle ET pour gérer les statuts est la bonne solution

Idem pour mobilité, à codifier et externaliser

Etc

OFFRE
Là aussi externalisez dans de nouvelles entité-types les notions comme le niveau d'étude, le niveau d'expérience, la localisation...

STATISTIQUE
S'il s'agit d'enregistrer des compteurs à un instant "t" alors il manque un attribut d'horodatage (et donc de type date ou timestamp)
S'il s'agit de dénombrer à la demande alors il ne faut pas stocker les infos mais les calculer (ne jamais stocker de données calculées)
Ce qui m'inquiète c'est que vous ayez lié ces stats aux offres, du coup je pense que c'est une erreur de modélisation, il manque probablement là encore une ET

Etc...