PHP|Débutant :: Forums

Bonjour,

Merci pour votre retour et vos différents commentaires.
j'ai donc bien fait de venir interroger les experts

Avez-vous voulu faire un MCD ou un MRD?
euh MCD, je ne connais même pas l'autre.

Explications et schéma d'ensemble:

Admettons un projet X
id_Projet: 1
Titre: Projet X
Date_début: 01/10/2014
Durée: 36 mois
etc.

Ce projet X se segmente en Work-Packages (groupe de taches).
Peut-on dire par exemple qu'un projet se défini par un ensemble de WP? => OUI

Ils ont chacun (par exemple) :
id_WP: 1
leader: P1
titre: WP2
date_début: 01/10/2014
date_fin: 31/10/2015

Parallèlement, un certain nombres de personnes travaillent sur ce projet. Par soucis de reporting, il me faut toutefois avoir au delà du nom de la personne, le ou les WPs auxquels elle aura contribué et le nombre d'heures qu'elle y aura consacré par jour. les justifications des heurs et les déclarations de déplacements (objet du voyage, WP de rattachement, destination, coût) ne seront quant à elle que mensuel

Une personne travaillant sur notre projet X mais peut participer a 1 ou plusieurs WPs sur 1 ou plusieurs périodes du projet.
Chaque jour cette personne pourra donc travailler sur 1 ou plusieurs WPs ou sur aucun du reste.

Exemple!

Bob travaille sur le projet X et participe au WP2 et WP4.
Admettons pour plus de facilité qu'il aura participer à ce projet à hauteur de 15% son temps soit approx: 22.5 heures / mois
Pour encore plus de faciliter admettons qu'il partagé de temps à 50/50 sur les deux WPs soit 11.25h / mois

il faudra donc selon les infos ci dessus déclarer.
BOB sur les WP2 et WP4
exemple; WP4, entre le 01/10/2014 et 31/10/2015, il faudra avoir déclarer pour chaque mois équivalent de 11.25heures réparti sur les jours travaillés (pas les weekends et jour féries). a ces heures, il faudra du reste dans le script php que je puisse enlever les vacances, RTT etc.

Est ce plus clair?

c'est quoi cette manie de drum de préfixer les champs par le nom de la table ???????
je faisais çà y a quelque siècle, mais maintenant, quel intérêt ?

a++

Merci pour votre retour,

je ne suis pas bien sur de cerner les choses;
1)
La notion de projet est plus qu'essentielle, pas de projet alors pas de WP.
la table Projet est donc par définition la table première de l'ensemble.
Un projet à des WPs
Un projet à des partenaires
Un projet à un annexe technique, un accord réglementaire etc. (ca deviendra ici de la gestion documentaire simple via parcours de dossier)
etc.

2)
Où est passée la notion de période?
cette notion est importante car la période n'est pas corrélée à la durée des WPs.
Un projet à 1 ou plusieurs périodes (dans mon cas, maximum 5)

3) je ne comprends pas trop ici la notion de rôle.
cela correspond il à la fonction de la personne sur le projet?

4) si je prends votre schématisation, et au delà de mes remarques précédentes, j'ai peur de pas comprendre.

les tables de base:
un Work package à une date de début et de fin (table Work Package)
Tout le personnel participant à un projet est indiqué dans table personnel (il faut donc attaché ici l'id Projet je présume) car une personne peut évidemment bosser sur plusieurs projets

les tables liées
c'est là que je suis perdu
1 personne a certes un rôle (si fonction) => en quoi ce rôle à une date de début ou de fin?
faites vous référence au rôle du WP? je suis perdu...

exemple BOB travaillant sur Projet X à la fonction de chargé d'études travaillant sur le WP2 (date_début: 01/10/2014, durée: 12 mois,  date_fin: 31/10/2015)

Oula il me falloir digérer cela.
le fait d'avoir plusieurs interconnexions ne peut pas dire que cela est une usine à gaz.
je dois certainement mal m'exprimer afin que vous arriviez à cette conclusion.

je comprends bien que cette schématisation n'est pas la vue d'ensemble et qu'un sous segment là n'est pas le soucis hormis le fait que la notion de projet reste pour moi et mon objectif élémentaire et primordiale.
En effet, je suis pas forcément d'accord avec votre point de vue. Quand vous dites qu'une personne travaillant sur un ou plusieurs WP travaille par extension sur un projet, je ne suis que partiellement d'accord. Car il pourra arriver que des Wps aient plus ou moins les même titres.. et il arrive que des projets quasi similaire se chevauchent également sur les dates. Donc dans ma vision des choses, même si je peux me tromper, la notion de projet est bien la base. C'est parce que le projet X existe que Mr A pourra travailler sur tels ou tels partie (WPs). sans ce projet, ses recherches n'auront pas pu etre entamé faute d'argent etc..

mais ce qui est certain c'est que je ne comprends cette notion d'entité vs table.
En quoi une entité se diffère t'elle d'une table?
dans vos entités, on y voit bien des clés primaires

Votre commentaire indiquerait que vos entités auront dont plus de champs qui n'apparaissent pas.

Connaître la période de travail d'un employé sur un projet se fera avec une simple requête SQL.
il n'est pas ici question de la période de travail d'un employé, enfin oui et non.

Oui => par rapport à ses heures effectués sur tel ou tel WP
Non => pas uniquement, il y a bien une notion de période globale au niveau projet qui régule l'arrivée des financements

Admettons un projet X:
2 périodes de 12 mois pour faire simple
Période 1: Du  01/10/2014  au 31/10/2015
Périodes 2 Du 01/11/2015 au 31/11/2016

admettons également 2 WPs
WP1 du mois 0 au mois 15
WP2 du mois 13 au mois 36

Bob travaille donc sur le WP1 et à la fonction de chargé d'etudes, il travaille à 100% sur 6 mois de la première période.
Dupont ravaille sur le WP2 et le WP1 et à la fonction de controleur, il travaille  sur toute la durée du projet à 30% de son temps soit 45 heures par mois dont 30h sur le WP1 et 15h sur WP2.

le fait de savoir que dupont a travailler sur  WP1 qui s'étale du mois 0 au mois 15 ne donnera pas la période concernée par requête SQL.

>>@Pierrot : cela évite les homonymies au niveau exploitation et permet d'assurer l'unicité d'une propriété à travers le modèle, pour l'essentiel.
j'ai pas compris là

nomDeTable.NomDeChamp et tout est évité

a++

Bonjour JC,

Je ne vais pas rentrer dans votre débat d'expert entre Pierrot et toi
Je vous laisse débattre selon vos expériences respectives.

1) Merci d'avoir ajouter l'entité Projet.
2) Vous avez parfaitement raison ce sont les id des lignes qui permette l'identification.
3) cela reste un petit peu abstrait à mes yeux. Mais si je comprends bien le fait de faire une architecture MCD ne donne donc pas la schématisation de sa base de donnée mais seulement une schématisation des entités du système.

A mon niveau cela complique encore plus les choses j'ai peur.
Quel intérêt au final hormis pour de gros projets difficile à définir? le fait de schématiser la base de donnée en direct ne permet elle pas une lisibilité plus simple? je n'ai aucune envie de remettre en cause votre avis sur la chose mais j'ai jute l'impression que cela complique un peu plus la mise en place de l'architecture.

mais bon je vais tenter de prendre en compte votre vision et de me perfectionner
Si je prends votre nouvelle modélisation d'entité.

nous avons donc 1 projet représenté par l’entité Projet.
Celle ci au niveau base de donnée comprendra entre autre.
-l'id projet
-Le titre projet.
-l'acronyme projet
-la durée initiale
-la date de début
-la date de fin théorique
-la durée de prolongation si besoin
-la date de fin réelle (date initiale + prolongation)

Ce projet est constitué de WP représente également par l'entité Work Package
Celle ci au niveau base de donnée comprendra entre autre
- L'id du projet auquel ce WP est rattaché
- L'id du WP en question
- un titre
- sa date de début
- sa date de fin
- on pourrait admettre un potentielle prolongation à ce niveau également donc je rajoute
- prolongation
-date fin réelle

C'est à ce niveau que les choses se compliquent pour moi.

Un certain nombre de personnes vont travailler sur un ou plusieurs WP du projet mais pouvant également participer à plusieurs projets il faut créer une entité intermédiaire.

Nous avons donc une entité personnes.
Celle ci au niveau base de donnée comprendra entre autre
- l'id de la personne
- son nom
- son prenom
- son login de connexion
- son mot de passe crypté
- son  adresse mail

Viens alors l'entité intermédiaire à une personne et un WP.
C'est au sein de cette entité que l'on va pouvoir indiquer une fonction / un rôle pour cette personne sur un WP d'un projet.
Celle ci au niveau base de donnée comprendra entre autre (c'est une table de liaison n:m n'est ce pas?)
-l'id du WP
- l'id de la personne ( a priori ici p.id) mais je ne savais pas que l'on pouvait renommer les clés si c'est bien cela
- l'id du rôle

A ce point une question: A quoi cela sert il d'avoir une autre entité / table Roles./ il y aura certainement des roles récurrents mais pourquoi créer une table distinctes?
- la date début de son intervention
-L'idée du WP role
-la date de fin de son intervention

A ce stade on parle en jours en mois en année ou directement en heures?
je ne comprends pas la distinction entre l'entité WP Role et la WP travail.
La WP role définit déja le début et la fin d'une personne pourtant cela se redéfini dans WP travail.
comment puis je distinguer les deux?

Il faut rester réaliste, il arrive que certaines personnes ne déclarent pas les heures par jour , il faudra faire donc un calcul de répartition en fin de période..

Enfin, je ne cerne pas bien où se trouve la notion de période projet.
je ne parle pas de la période de travail de telle ou telle personne mais de la période projet (financement)

Dernière modification par Darkangel (29-09-2014 12:53:22)

Bonjour Jc,

Merci pour votre retour.
Je prends effectivement le temps de clarifier les choses avant de me lancer.

J'ai tout d'abord lu la présentation de votre lien.
Je comprends déjà plus les niveaux d'architecture, mais la dernière indication me conforte:
Toute entité devient une table dans laquelle les attributs deviennent les colonnes.

Cela confirme bien ce que vous dites, à savoir que le MCD reste la schématisation de sa base de données

Est ce bien à un changement de nom de projet auquel vous faites référence?
Si oui, même dans le cadre de projet à l'international, enfin dans mon domaine, la langue de référence est l'anglais et de fait le titre du projet restera en anglais pour tous les pays.

a ma connaissance et selon ma compréhension de votre schéma, il est bien question de prolongation au niveau des WP mais dans 90% des cas que je rencontre la notion d'extension est lié au projet dans son ensemble et donc à tous les Wps. Il arrive cependant que seul certain WP soit effectivement concerné dans les 10% de cas restants. mais dans le système mis en place il faudrait donc dans ce cas modifier tous les WP du dit projet et indiquer une extension de x.

En ce qui concerne votre remarque sur la normalisation des données, je vous fait confiance sur la chose car je ne maîtrise pas cela.
La date de fin réelle est effectivement ce dont j'ai besoin et ne s'applique qu'une fois.  Il ne m'est jamais arrivé d'avoir deux prolongations successives.
mais si j'envisageais le cas comme vous le soulignez ( table d'archive)  il suffirait en théorie d créer une table extension rattache a la table projet avec l'historique des extensions et les dates de fin réelles calculées en conséquence non? mais il s’avérerait que cette table devra etre modifiable du coup...

la date de fin d'un WP ou d'un projet n'a rien de théorique enfin dans mon domaine. cela est réglementé et fixe sauf si prolongation.
iil y a donc effectivement une date réelle de début et une date de fin fixe qui peut se modifier si extension accordée mais les deux dates en questions ont besoins d’être connu.
Dans mon domaine le travail doit être effectué dans la période indiquée car au delà les dépenses ne sont plus éligibles.

je ne cerne pas trop cette notion de normalisation comme souligner précédemment mais ok pourquoi pas.
si je comprends bien cela:

admettons 2 personnes.
Dupont (chargé d'études)
Pierrot (data manager)

le champ dupont sera enregistré dans la table personnel
chargé d’étude sera enregistré dans role.
l'association des deux dans le cadre d'un projet se fera dans la table intermédiaire WP: Role.
mais alors cela engendre un problème futur que je je souligne dès maintenant.
Cela obligera a terme de vérifier si le rôle existe ou non dans la base role avant de créer l'association.
Au vue de la multitude de fonction que cela peut couvrir bien que 90% soient récurrentes je l'admet cela alourdira il me semble la recherche.

aucun historique d'accès n'est réellement nécessaire mais bon pourquoi pas dans l'absolu. dans le post initial je ne faisais partie qu'a une partie du projet  dans sa globalité. Ok pour séparer la notion de connexion de la table personne en vue d'envisager un système d'accès plus pertinent.

ok je suis d'accord avec vous pour les calculs via sql.

je ne suis pas sur de bien comprendre.
si on définit dans Role que Mr X à bossé comme contrôleur du 2 au 10 pourquoi reprendre une autre fonction dans une autre table?
pourquoi selon votre schématisation ne pas mettre les 2 infos dans wp role directement?
sauf si on considère d’après ma deuxième lecture de la chose que la table travail serait le détail d'activités et la table rôle juste une date de début et de fin d'intervention et donc la période du WP en référence?

je suis parfaitement d'accord avec votre point de vue et c'est pourquoi j'ai souligné ce point dès maintenant.
c'est un point assez compliqué.

Deux approches à ce point et en vue de répondre à cette problématique que je rencontre déjà.
-
si Mr X complète ses heures régulièrement dans ce futur système alors ok pas de soucis. Même s'il complète cela chaque semaine cela ne posera pas de problème.
Encore faut il envisager au niveau sql /php que la personne pourra style indiquer 15h consacré sur WP1 sur 3 jours dans la semaine donc 5heures par jours à enregistrés dans la base automatiquement mais cela s’avérera encore le cas simple

- bien malgré moi et toute une équipe, le personnel ne suit bien évidemment pas toujours les règles...
très et trop difficile de pouvoir les inciter à le faire car déjà bien surchargé.

il arrive assez souvent que les personnes en question nous déclare un % de temps effectué sur le projet et la période concernée correspondant plus ou moins à la réalité. cela vaut dans les deux sens: temps complètement dépasser ou travail réalisé en moins de temps que prévu.

C'st un principe admis par les hautes autorités dans la plupart des pays.

Tout ça pour dire que dans certains cas il arrive que la personne n'a rien déclarer. Alors il nous faut composer d'après l'estimatif.
budget de 160k€ estimatif pour un data manager sur tant de temps.
On décompose ce montant en fonction de la durée de la période , de son % de temps déclarer et on constitue les feuilles d'heures justificatives comme cela.
salaire de l'année * heures déclarées = salaire éligible . encore faut il pouvoir le justifier par des résultats

il me faut pouvoir composer selon ces 2 réalités..

Pour vous donner une idée d'exemple de journalisation de travail effectué (travail pointé)

Extrait d'un post issu de PHP débutant dont voici l'extrait qui nous interesse: (MySQL)

Dernière modification par Jc (29-09-2014 15:50:56)

merci pour votre partage de scripts.
me parait bien mais quelque peu minimaliste car une notion n'a pas été abordé.
prenons un calendrier et un mois concerné. Il faut pouvoir générer un calendrier du mois avec les jours travaillés en omettant bien évidemment de déclarer quelqu’un les weekends ou pendant ses congés par exemple..

Bonjour JC,

Merci pour votre retour.
Tout d'abord ne serait il pas plus pertinent de voir cela via un autre moyen que le forum?
J'ai peur de polluer un peu avec une demande extérieur au codage pur pour le moment..

question de langues:
Je ne pense pas m’être correctement exprimé.
Je sais bien que le php ne fait pas tout. je faisais référence aux vues renvoyées par php.
exemple menu de la page / présentations etc.. nous n'allons pas stocker cela dans la base mais bien dans des variables php non?
dans de petits sites anciens que j'avais fait, la traduction se faisait bien par php.

exemple

En ce qui concerne ensuite ce que j'appellerai le back office, tout pourra être en anglais..
Toutes les données projets sont en anglais...

En ce qui concerne les extensions et pour répondre à votre question:

Il n'est pas nécessaire de se compliquer autant la vie.
Un temps de travail est éligible si celui ci est réalisé pendant la période du projet et pendant la période de son WP de surcroît.
Comptabiliser le temps non éligible ne m'est pas nécessaire.
Dans le pire des cas, même si une personne faisait une déclaration bidon d'heures cela s’avérait inutile car non proportionnel au coût de personnel déclaré en amont de négociation du contrat et basé sur les ressources RH. aussi et en fonction des remontées de nos contrôleurs financiers, je devrai adapter moi même leurs déclarations d'heures pour les rendre adéquat. Obligatoire si un audit venait à nous tomber dessus.

Aussi la base sera différencier si travail éligible ou non!
admettons une période de 1 an.
1 janvier 2014 au 31/12/2014. si la personne déclare 5% de son temps sur 1 an et 1 mois le système lui refusera le mois en dehors de la période.
En même temps le système ne lui proposera même pas dans ma vision des choses.

La seule personne habilitée à déclarer dans l'appli une extension de validité est moi. Nous pourrions cependant anticiper l'avenir et prévoir le cas que 2 ou 3 personnes max puissent le faire mais encore faudrait il que je leur délègue le droit.

=> Oui en fonction des dates du projets et des dates du ou des WPs concernés.

Petites explications

Un amendement de contrat est déposé en vue de demander une extension de projet et donc d’éligibilité de coup.
Si la réponse est défavorable alors les dates projets restent celles annoncées précédemment et l'appli doit refuser toute déclaration au delà de cette date.
Si la réponse est favorable:
cas extension projet (fréquent): Tous les WP sont concernés et les coûts sont donc éligibles tant qu'ils rentrent dans l'enveloppe budgétaire que nous avions recu.
cas extension WP (rare): seul un WP est prolongé et seuls couts liés à ce wP sont encore éligibles. l'appli refusera les dépenses pour les autres wps.

je vais y cogiter mais je n'envisageais initialement pas de vous embêter avec l'ensemble
Voila une première représentation sans reprendre le détail rôle et travail qui vienne se connecter à cela.
https://drive.google.com/file/d/0B0Rb6S … sp=sharing

pour info, j'aurais du modifier l'entitée partenaires par l'entité membre. car un membre peut soit etre coordinateur soit partenaires du projet mais reste un membre tout de même.

Dernière modification par Darkangel (30-09-2014 11:23:36)

Bonjour JC,

Dois je comprendre par là que que tous mes menus, autres titres etc. avec leurs traductions devront être stockes dans la base de donnée?
Si oui, auriez vous un lien à me proposez qui montre une façon
ou une autre de procéder de façon optimisé?

merci pour votre nouveau modèle que je vais décortiquer.
Dans ma schématisation ma façon de procéder avec les sous contractants de partenaires (ou membre après correction) est elle correcte?.

euh là je sèche. Implémenter la règle d'assertion?? kesako?
je connais un peu même très peu les contraintes d'intégrités et d’âpres mes lectures cela y semble lié mais jamais employé.

commentaire audit

je relève votre commentaire bien que ce ne soit pas les autorités françaises qui nous auditent.
mais vous avez parfaitement raison sur le principe et c'est pourquoi je dois dores et déjà prévoir un log de connexion et un suivi des modifs des heures.

de même dans ma dernière modélisation et selon vos précédentes recommandations,  j'avais mis en place une entitée code personnel externe à personnel est ce ok que vous sous entendiez les choses?
Enfin si je dois prévoir un historique de connexion et modification puis je laisser la table directement a personnel?

Dernière modification par Darkangel (30-09-2014 13:45:56)

Pour commencer avec les contraintes SQL, il y en a un total de  7 dont 5 sont des contraintes de table.

Pour les contraintes de table :
- Contrainte de clé primaire (PK)
- Contrainte d'obligation de valeur (NOT NULL)
- Contrainte de clé étrangère (FOREIGN KEY)
- Contrainte de validation (CHECK)
- Contrainte d'unicité (UNIQUE)

Les 2 dernières étant:
- Contrainte de Domaine (INT, VARCHAR, ...)
- Contrainte d'assertion

Note: MySQL par exemple ne les implémente pas toutes contrairement à d'autres moteurs comme postgreSQL ou SQLServer pour ne citer que ceux là.

Une contrainte d'assertion est une expression logique (prédicat) devant toujours être évaluée à vrai et peut concerner plusieurs tables. Elle permet la mise en place de règle de validation entre différentes colonnes de différentes tables. Une contrainte d'assertion est au sens de la norme SQL un objet de la base de données.
Un exemple : Faire en sorte que le montant des commandes non réglées ne dépasse pas 20% du CA réalisé par un client.

Pour les langues, le plus simple et le plus performant est d'utiliser la table de paramétrage PAYS (qui est à la base présente dans une gestion des adresses normalisée), de sortir toutes les colonnes de type VARCHAR de chaque table concernée et de les mettre dans une nouvelle table de localisation comme suit :

tables SQL

L'avantage en plus c'est que la table représentant l'entité de base devient en général après cette modification, une table statique, ce qui en augmente les performances.

Pour les amendements, faudrait lister les types possibles en faire une table de référence aussi, savoir si les droits de création peuvent changer en fonction du type, etc... faut tout développer.

Dernière modification par Jc (30-09-2014 14:17:30)