Discussion :

[khyor]

Bonjour à tous.
Je travaille actuellement à la réalisation d'une application destinée à gérer les ressources de mon entreprise.
J'ai vu le post de "ahmedmrj" intitulé "departement informatique" qui se rapproche en partie de mon application mais j'ai quelques autres notions a gérer que je souhaite vous présenter.

Pour situer un peu le contexte, nos employés travaillent sur des Affaires et se voient attribuer différentes ressources.
Ces ressources sont décomposées en plusieurs domaines :

• Informatique
• Téléphonique
• Topographique
• Automobile

De plus, je souhaite rajouter à ces ressources, la saisie du temps lié aux Affaires.

Ainsi, chacun de ces domaines sera accessible sous la forme de Modules avec différents type d'accès (utilisateur, gestionnaire, admin)


Je vais vous exposer ici la partie "saisie temps" qui sera le premier module que je compte développer.

Règles de fonctionnement :

• 1 utilisateur a accès à 0 ou plusieurs module
• 1 utilisateur collabore a 0 ou plusieurs affaires pour un rôle donnée
• A 1 affaire collabore au moins 1 ou plusieurs utilisateurs.
• 1 utilisateur saisie un temps à 1 date donnée pour 1 affaire à 1 phase précise
• 1 affaire est localisé dans 1 et 1 seul lieu
• 1 lieu localise 0 ou plusieurs affaires
• 1 lieu localise 0 ou plusieurs clients
• 1 client est localisé dans 1 et 1 seul lieu
• 1 client est représenté par 1 ou plusieurs contacts
• 1 contact représente 1 et 1 seul client

A partir de ces règles j'ai essayé de créer un petit schéma que j'ai joint.

J'attends vos commentaires et conseils afin de l'améliorer.

Merci par avance

[CinePhil]

La fonction de l'utilisateur devrait être externalisée dans une autre entité/table.
Idem pour l'état d'une affaire, type d'accès d'un module et rôle d'un utilisateur dans une affaire.

Pourquoi les deux associations "Localiser" sont-elles de nature différente ?
Idem pour "Collaborer".

Contact et Utilisateur sont tous deux des personnes ayant quasiment les mêmes attributs. Il pourrait être envisagé de faire un héritage d'une entité Personne vers deux entités "Utilisateur" et "Contact".

Dans vos règles de gestion, vous parlez de projet et dans le schéma il s'agit d'affaire.

pour 1 projet à 1 phase précise

Si ce que je viens de supposer est vrai, alors il manque probablement une association entre Affaire et Phase.

Il est possible dans votre schéma qu'un utilisateur saisisse un temps pour une affaire à laquelle il ne collabore pas. A vous de voir si c'est normal.

[khyor]

Merci de m'accorder un peu de votre temps

La fonction de l'utilisateur devrait être externalisée dans une autre entité/table.
Idem pour l'état d'une affaire, type d'accès d'un module et rôle d'un utilisateur dans une affaire.

- ok pour la fonction de l'utilisateur, je vais l'externaliser.
- pour l'état d'une affaire, il y a en fait doublon, car celui-ci est en fait géré par l'entité "Phases". Donc il n'a plus lieu d'être.
- pour le rôle d'un utilisateur dans une affaire, je vais l'externaliser aussi.
- pour le type d'accès d'un module, il s'agira d'un booléen OUI/NON 1/0 donc je pense qu'il n'est pas nécessaire de l'externaliser. C'est pour défini si l'utilisateur peut accéder ou non au module. le nom du champs n'était pas explicite.

Pourquoi les deux associations "Localiser" sont-elles de nature différente ?
Idem pour "Collaborer".

Je me suis un peu emmélé avec les paramètrages je pense. je voulais appliquez ces règles :
- un affaire est localisé dans au moins et au plus dans 1 lieu
- un client est localisé dans au moins et au plus dans 1 lieu
- un lieu localise au moins 0 ou au plus plusieurs affaires
- un lieu localise au moins 0 ou au plus plusieurs clients

Contact et Utilisateur sont tous deux des personnes ayant quasiment les mêmes attributs. Il pourrait être envisagé de faire un héritage d'une entité Personne vers deux entités "Utilisateur" et "Contact".

ah vi, merci !

Dans vos règles de gestion, vous parlez de projet et dans le schéma il s'agit d'affaire.

Oui, désolé, je vais utiliser le terme d'affaire désormais.

Si ce que je viens de supposer est vrai, alors il manque probablement une association entre Affaire et Phase.

Là par contre je ne vois pas à quoi vous faites allusion ?

Il est possible dans votre schéma qu'un utilisateur saisisse un temps pour une affaire à laquelle il ne collabore pas. A vous de voir si c'est normal.

Non, en effet, cela ne doit pas être possible.

1 utilisateur ne doit pouvoir saisir 1 temps que pour les affaire auxquelles il collabore.

Pour résumé le fonctionnement de la saisie temps:
chaque jour, 1 utilisateur saisie le temps passé sur une affaire à une phase donnée.
il peut donc toute la semaine, saisir son temps passé sur une même affaire à une même phase.
De même, il peut saisir plusieurs temps passés, sur des affaires différentes le même jours.
L'unicité de l'enregistrement doit donc être (JOURCalendar,AFFAIRE,PHASE,UTILISATEUR) si je ne me trompe pas ?

[CinePhil]

- pour le type d'accès d'un module, il s'agira d'un booléen OUI/NON 1/0 donc je pense qu'il n'est pas nécessaire de l'externaliser.

Effectivement c'est inutile. Il vaut mieux utiliser le type BOOLEAN dans ce cas.

Je me suis un peu emmélé avec les paramètrages je pense. je voulais appliquez ces règles :
- un affaire est localisé dans au moins et au plus dans 1 lieu
- un client est localisé dans au moins et au plus dans 1 lieu
- un lieu localise au moins 0 ou au plus plusieurs affaires
- un lieu localise au moins 0 ou au plus plusieurs clients

J'avais bien compris et le sens des relations n'est pas en cause mais d'après le dessin, il y a je pense une "identifying relationship" et une "non-identifying relationship". Vous n'avez pas dû utiliser le même bouton pour toutes les relations, ce qui peut être justifié dans certains cas mais pas ici.

Si ce que je viens de supposer est vrai, alors il manque probablement une association entre Affaire et Phase.

Là par contre je ne vois pas à quoi vous faites allusion ?

Ben...

une affaire à une phase donnée

Il s'agit bien des phases d'une affaire non ? Donc une phase concerne une affaire ? Ou bien ces phases sont-elles génériques pour tout type d'affaire (conception, réalisation...) ? Bref ce n'est pas limpide sur le schéma mais peut-être que oui dans le cahier des charges.

Non, en effet, cela ne doit pas être possible.

1 utilisateur ne doit pouvoir saisir 1 temps que pour les affaire auxquelles il collabore.

Il faut donc faire quelque chose ici. Pas le temps de développer maintenant.

Pour résumé le fonctionnement de la saisie temps:
chaque jour, 1 utilisateur saisie le temps passé sur une affaire à une phase donnée.
il peut donc toute la semaine, saisir son temps passé sur une même affaire à une même phase.
De même, il peut saisir plusieurs temps passés, sur des affaires différentes le même jours.
L'unicité de l'enregistrement doit donc être (JOURCalendar,AFFAIRE,PHASE,UTILISATEUR) si je ne me trompe pas ?

C'est comme ça que je l'avais compris donc si ma dernière supposition concernant les phases est juste, votre unicité est juste également.

[khyor]

J'avais bien compris et le sens des relations n'est pas en cause mais d'après le dessin, il y a je pense une "identifying relationship" et une "non-identifying relationship". Vous n'avez pas dû utiliser le même bouton pour toutes les relations, ce qui peut être justifié dans certains cas mais pas ici.

ça me revient, j'ai bien utilisé le même bouton.
Toutefois j'ai retiré la clé étrangère [lieux_id] des clé primaire des entités AFFAIRE et CLIENT, leurs relations sont donc passé 'non-identifiying'.

Si je redéfini ces clés étrangères en clé primaire pour ces deux entités, je vais donc avoir en clé primaire pour l'entité AFFAIRE :

• id
• lieu_id
• client_id
• client_lieux_id

a voir donc, qu'en pensez vous ?

Il s'agit bien des phases d'une affaire non ? Donc une phase concerne une affaire ? Ou bien ces phases sont-elles génériques pour tout type d'affaire (conception, réalisation...) ? Bref ce n'est pas limpide sur le schéma mais peut-être que oui dans le cahier des charges.

Oui en effet, ces phases sont génériques pour tout type d'affaire.

[CinePhil]

ça me revient, j'ai bien utilisé le même bouton.
Toutefois j'ai retiré la clé étrangère [lieux_id] des clé primaire des entités AFFAIRE et CLIENT, leurs relations sont donc passé 'non-identifiying'.

Si je redéfini ces clés étrangères en clé primaire pour ces deux entités, je vais donc avoir en clé primaire pour l'entité AFFAIRE :

• id
• lieu_id
• client_id
• client_lieux_id

a voir donc, qu'en pensez vous ?

C'est effectivement une non-identifying relationship qu'il faut utiliser dans ce cas sinon l'identifiant du lieu se propage et c'est inutile dans ce cas.

[khyor]

Et hop, pour le soucis des utilisateurs qui peuvent saisir des temps sur des affaires auxquels ils n'ont pas accès :
En fait, après discussion avec le bureau d'études, il apparait intéressant, voir primordiale que n'importe quel utilisateur, puisse saisir un temps sur une affaire auxquelles il n'est pas affecté d'ordinaire. Cela intervient dans un rôle de délégation lorsque une personne doit provisoirement effectuer des tâches ciblé pour un autre.
du coup, la solution que j'envisage est de rajouter un rôle "délégation" pour bien identifier ces saisie. Ça me semble un bonne solution, quitte éventuellement à faire valider les temps délégués par un gestionnaire mais bon ça reste à voir.

[khyor]

Je suis de nouveau au travail sur mon projet.
J'ai effectué quelques modifications :
- création d'une entité PERSONNE dont héritera les entités EMPLOYE et CONTACT
- l'entité FONCTION fusionne également avec ROLE étant données qu'une partie seront communes.Ces dernières seront donc identifié par le booléen 'role'.
- ajout de l'entité AGENCE qui sera lié à EMPLOYE


Pour résumé :
- Une PERSONNE peut être un EMPLOYE ou un CONTACT (en aucun cas les 2)
- Un CONTACT est le lien de communication CLIENT
- L'EMPLOYE est défini par une FONCTION et est affecté à une AGENCE
- un EMPLOYE est lié à une AFFAIRE selon un ROLE donné
- un EMPLOYE saisie un 'temps' à une 'date' donnée pour une PHASE précise d'une AFFAIRE (chaque jour, un employé pourra saisir ses temps passé sur les différentes phases de affaires qui lui sont affectés)
- les CLIENTS, les AFFAIRES ainsi que les AGENCES sont géo localisé sur un LIEU

N'hésitez pas à me faire part de vos commentaires et conseils pour faire évoluer ou structurer au mieux mon schéma.