Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#1 Re : Forum Général PHP » Reflexion sur base de donnée avant programation » 30-09-2014 22:44:47
Bon bah me voila dans une sacré panade alors car je ne connais que mysql.
pas sur d'avoir bien cerné ce que vous voulez dire pour les langues mais je vais y cogiter à deux fois.
Pour les amendements je connais tous les cas possibles mais j'envisagerai don de supprimer l'entitee extension
et de créer une amendement de sorte a ce que je puisse faire un enum des cas possible et de rajouter un champ date si seulement cas extension periode..
ca serait correct?
de meme et au sein de mon modèle en construction:
https://drive.google.com/file/d/0B0Rb6S … sp=sharing
deux questions:
cela vous semble t'il deja correct?
Une personne travaillant forcement pour un membre et pour un projet, je devrais donc rattacher la table à Project has members non?
mais parallèlement cette personne va travailler sur 1 ou plusieurs WPs.
dois je donc prévoir une table qui lierai àla fois Project has members et wp?
#2 Re : Forum Général PHP » Reflexion sur base de donnée avant programation » 30-09-2014 22:44:47
une autre notion rentre en compte que j'ai omis de mentionner.
dans le cas d'un projet il peut effectivement y avoir un amendement de sorte à avoir une extension de durée mais il peut aussi y avoir des amendements autres (nouveau partenaire, retirer un partenaire )
aussi j'aimerai pouvoir garder un historique des amendements, de leur date et de leur motif.
#3 Re : Forum Général PHP » Reflexion sur base de donnée avant programation » 30-09-2014 22:44:47
Bonjour JC,
Définir quelques variables en multilangue au niveau PHP ça peut être pratique pour un petit site statique, mais pas pour une application web.
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?.
N'oubliez pas d'implémenter la règle d'assertion pour la création de wpt_end de WP_TRAVAIL.
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?
#4 Re : Forum Général PHP » Reflexion sur base de donnée avant programation » 30-09-2014 22:44:47
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
define('TXT_MENU_ACCEUIL', 'Accueil');
define('TXT_MENU_ACCEUIL', 'Startseite');
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.
Pour répondre à cette problématique, je vais supposer d'abord, que seuls un ou plusieurs profils particuliers au sein de votre modèle sont autorisés à déclarer officiellement une extension de validité de projet. Les droits d'une telle action sont donc normalement très spécifiques et une telle entité PROJET_WORK_EXT doit être modélisé pour cela. Reste à définir ses dépendances et ses règles de gestion/validation pour la modéliser correctement.
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.
On contrôle au niveau de l'application si la déclaration d'une nouvelle période de travail s'inscrit dans une durée éligible.
=> Oui en fonction des dates du projets et des dates du ou des WPs concernés.
- Soit on met en place un système identique aux extensions de projet pour les extensions de WP. Cette extension devra être effectuée par la personne autorisée préalablement à la saisie de toute nouvelle déclaration de travail.
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 confirme cette nécessité et de détailler le contexte de gestion et de consultation.
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.
#5 Re : Forum Général PHP » Reflexion sur base de donnée avant programation » 30-09-2014 22:44:47
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..
#6 Re : Forum Général PHP » Reflexion sur base de donnée avant programation » 30-09-2014 22:44:47
Re bonjour,
Ok pour ne pas internationaliser (gérer plusieurs langues) l'application. Donc tout sera en Anglais.
clarifions les choses à ce niveau.
il n'est pas nécessaire d'internationaliser les éléments de la base.
l'application en tant que telle pourra quant elle être en français et en anglais mais cela se fait très bien via php et le détection de la langue utilisée ou choisie
Merci de clarifier et de détailler cette gestion d'extension de durée de projet.
Deux choses à distinguer.
il y a le projet avec une date de début et une date de fin théorique ou réelle
et il y a les Wps avec également une date de début et une date de fin théorique.
dans le cas d'une extension et comme je le soulignais précédemment il peut y avoir deux cas.
majoritairement: le projet dans son ensemble est prolongé de disons 6 mois ou 1 an et que les coûts deviennent donc éligibles pour tout le projet et durant cette extension.
Dans l'autre cas, beaucoup moins fréquent, seulement le WPx est allongé mais pas tout le projet ce qui signifie que seul les dépenses liées aux activités de ce WP seront encore éligibles.
mais votre schématisation semble répondre à ces deux possibilités car si on indique la durée au travers des WP directement, mais il faudra donc aller récupérer la date la plus lointaine d'un des WP ou connaitre la date de fin réelle... pas très pratique en soi . mais je ne vois pas comment optimiser a part d'indiquer dans la table projet si extension lié au projet ou au wp et procéder via les deux techniques en parallèle..
mais pas très catholique pour un expert comme vous je présume...
Tout d'abord, veuillez m'excuser pour mon abus de langage quand j'ai dit "lecture seule" ce n'est jamais le cas en pratique mais il s'agit en fait d'un contexte, où les lectures sont majoritaires et optimisées prioritairement aux écritures (par exemple 80%/20%).
oullala pas besoin de vous excuser, c'est moi la personne qui doit se perfectionner...
mais ok 
Ce critère est essentiel est majeur car il constitue à la fois une règle de gestion et de validation métier. Donc oui si tel est le cas la date de fin fixe devient parfaitement légitime et prends tout son sens. Du coup il peut être en effet judicieux de mettre en place une entité WP_EXTENSION pour gérer ces extensions au sein du modèle, et d'autant plus, dans un contexte de gestion de workflow.
oui date de période = éligibilité des coûts. donc ok avec votre analyse.
reste a distinguer par rapport au premier point si on fonctionne par extension projet vs extension WP ou les deux ...
Pas de récurrence ici, cette entité constituera dans le modèle relationnel une table de référence (paramétrage) qui ne contient aucun doublon. Cela n'alourdira aucunement la recherche, si cela peut vous rassurer.
euh ?? table de paramétrage je peux comprendre sous réserve que cela corresponds bien à l'enregistrement de toutes les fonctions possibles de tous les projets...
C'est votre 2e lecture qui est la bonne, sauf qu'ici le modèle n'est pas spécifique à une date de début et de fin d'intervention GLOBALE, mais elle autorise la journalisation de l'information car il s'agit d'un historique. Vous pouvez vous en servir toutefois dans le mode qui vous conviendra le mieux.
Ensuite pour répondre au pourquoi de votre première lecture: Il est important que votre SGBDR connaisse à un instant T, qui travaille sur quoi et où, surtout dans un contexte où la gestion de workflows (processus transverses) peut intervenir au sein de votre SI. Toujours dans votre première lecture le terme "bosse" est faux au premier degré du mot. On sait qui fait quoi au sein d'un WP et donc par extension au sein d'un projet à un instant T, permettant de faire une carte du personnel de l'entreprise et de leur fonction au sein de son organigramme (directeur de projet, chef de projet, chef d'équipe, etc...) mais cette entité ne renseigne en rien sur les heures de travail de ces personnes à leurs postes respectifs.
j'ai donc bien fait de me relire avant de poster
mais de ce fait et dans votre modèle pourquoi indiquer cela dans les deux entités?
mais ok pour la journalisation et l'aspect d'historique. c'est juste que je ne cerne pas l'utilisé d'avoir ce que je perçois comme un doublon
oui bien vu, je suis parfaitement d'accord avec votre analyse.
Pour éviter ce genre de problèmes, le planning de gestion du personnel peut servir à cela: pour un jour donné, M.X travaille sur tel poste à faire telle tâche et pas une autre. Ainsi il est plus aisé de savoir qui fait quoi pendant combien de temps. Reste à gérer les transitions de tâche "j'ai terminé telle tâche et commencé la tâche suivante en fin de journée (env.2h)".. Après c'est à l'entreprise de s'adapter.
Question que faites-vous de ce temps travaillé en plus et qui est considéré comme non éligible? comment doit-il être traité?
C'est là toute la complexité de la chose. je travaille dans le domaine de la santé et leurs activités sur le projet sont très très variables.
c'est pourquoi j'insiste sur le besoin de devoir articuler les choses dans les deux sens tel qu'indiqué dans mon précédent post.
le personnel doit bien évidemment indiquer sur quelles taches il y a travailles mais travaillant sur plusieurs et parfois en parallèle, leur imposer un tel système serait parfaitement utopiste.
je ne pensais pas aller aussi loin dans l'application en tant que telle.
j'envisageais plus tôt au vue de mon niveau de me limiter aux seuls enregistrements des heures
avec le compte rendu donné par la machine une adéquation coût personnel / horaires était plus aisé
mais bon plus je cogite avec vous de la mise en place au global et si je ne peux adapter les choses au fur et a mesure, il va réellement falloir que je présente les choses plus largement (au dela des services annexes, il faudrait prévoir qu'un projet à des membres (coordinateur ou partenaires ou sous contractants d'un partenaire ou meme tierce partie d'un partenaire. Chacun travaillant sur une tache du projet. mais cela n'aurait qu'un aspect consultatif interne, pas question de gérer les feuille d'heures de tous les membres d'un projet.. aucun utilité. la seule notion serait par exemple de suivre l'avancement des WP si nous étions coordinateur.
Question que faites-vous de ce temps travaillé en plus et qui est considéré comme non éligible? comment doit-il être traité?
c'est une perte mais qui est couvert par les coûts indirects (coût d'un projet pour lesquels aucunes justifications n'est demandé) mais c'est justement une chose que l'on évite et c'est pourquoi des feuilles d'heures s'impose.
#7 Re : Forum Général PHP » Reflexion sur base de donnée avant programation » 30-09-2014 22:44:47
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
Le titre du projet : ok sauf s'il est envisagé de définir une application internationalisée.
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.
Ce sont des informations déjà présentes dans le modèle et qui pourront être extraites via requête. Ainsi les "remettre" dans la futur table projet, va consister à la dénormaliser (l'atomicité des données et donc la première et la deuxième forme normale ne seront plus respectées). Ce choix devra donc être pris le plus tard possible en fonction des besoins de production. La date de fin réelle sera la plus légitime car elle peut éviter de refaire plusieurs fois les calculs. Si toutefois on souhaite ne pas polluer le modèle par ce genre d'information dénormalisante, il pourra être judicieux de créer une table d'archive de projet qui elle stockera toutes ces informations car elles n'auront pas à être modifiées dans le temps, et qui permettra d'avoir toutes les informations clés d'un projet par une simple lecture de la table. On pourrait même créer un nouveau schéma dans la base de données à cette fin d'archivage d'information, schéma alors utilisé en lecture seule et placé sur des unités disques spécifiques et optimisés pour ce genre d'accès.
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...
Pour les WPs il en va de même.
La date de fin, comme je l'ai dit est ici censée être théorique (celle prévue initialement). Cela permet de conserver la normalisation, car elle permettra de connaître la prolongation en faisant une comparaison avec la durée totale de travail sur ce WP dans la future table wp_travail.
En ce qui concerne la date de fin réelle d'un WP, je dirais par expérience qu'elle n'a pas sa raison d'être ici. (Cela n'engage que moi). Si toutefois vous souhaitez la mettre, n'oubliez pas la considération précédente faite pour les projets.
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.
Pour préserver la normalisation. D'un côté nous avons l'entité qui défini les rôles pouvant exister au sein du modèle, et de l'autre l'historisation des rôles exercés par WP dans le temps en fonction de l'entité PERSONNEL.
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.
Oui mais cela reste encore à définir et ne faisait pas partie du post initial. Si un historique doit être géré au niveau des accès avec login/mot de passe alors son login/mot de passe doit être absent de l'entité PERSONNE. (une entité est toujours au singulier). Pour l'adresse email elle pourra rester dans l'entité PERSONNE, car elle peut être dans l'absolu, différente de celle de connexion si elle est utilisée dans le cadre de la récupération d'un mot de passe perdu notamment.
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.
Rien de tout cela. On stocke ici l'information sous forme de date et heure (YYYY-mm-dd hh:mm:ss) pour le début et la fin.
Il ne s'agit que de relever l'information, on n'effectue aucun calcul ici. On réserve cela à plus tard aux VUES SQL.
ok je suis d'accord avec vous pour les calculs via sql.
Dans WP_ROLE, on exprime par exemple que M.X est déclaré/défini sur le WP n°123 comme contrôleur du 2 au 10 septembre 2014
Dans WP_TRAVAIL, on exprime par exemple que M.X, à travaillé sur ce même WP en tant que contrôleur le 3 septembre de midi à 18h et le 5 septembre de 15h à 18h.
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?
Ceci est un problème et peut remettre en cause le modèle que je vous ai proposé.
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..
#8 Re : Forum Général PHP » Reflexion sur base de donnée avant programation » 30-09-2014 22:44:47
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)
#9 Re : Forum Général PHP » Reflexion sur base de donnée avant programation » 30-09-2014 22:44:47
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.
#10 Re : Forum Général PHP » Reflexion sur base de donnée avant programation » 30-09-2014 22:44:47
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)
#11 Re : Forum Général PHP » Reflexion sur base de donnée avant programation » 30-09-2014 22:44:47
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?
#12 Forum Général PHP » Reflexion sur base de donnée avant programation » 30-09-2014 22:44:47
- Darkangel
- Réponses : 30
Bonjour à toutes et à tous,
Je vais bientôt devoir me lancer dans la programmation d’un système de gestion pour mon travail.
Je cogite donc préalablement à la vision d’ensemble et à la base de données qu’il me faudra.
Mais je ne suis pas sûr de moi au sujet de la partie liée aux heures effectuées par le personnel.
J’explique ce que je souhaite pour cette partie.
1 projet à plusieurs périodes
1 projet a également plusieurs Work Package (WPs)
Le personnel doit être :
- rattaché au projet
- rattaché à un WP
- rattaché à une période
- il doit déclarer le nombre d’heures effectués chaque jour de chaque mois.
voila la modélisation en cours.
je ne pense pas bien procéder pour les mois et les heures et souhaiterais donc votre avis.
https://drive.google.com/file/d/0B0Rb6S … sp=sharing
Merci par avance
#13 Re : Forum Général PHP » question sur l'utilisation du for ($i = 0; $i < $result; $i++) » 10-01-2014 12:01:31
Bonjour,
A ce propos, je ne suis pas partisan d'autoriser un compte à accéder à un autre compte, car cela n'est pas très sécuritaire. En effet chaque compte doit pouvoir rester inaliénable au sein d'un système et chaque personne doit pouvoir rester seule responsable et garante de ce qui est fait à partir de son propre compte. Ses identifiants doivent donc rester connus d'elle seule et en est responsable. Les logs actions sont là justement pour pouvoir auditer qui fait quoi comment, où et quand pour permettre aussi une totale transparence du système et de pouvoir identifier éventuellement lorsqu'un compte a été hacké (adresse IP jamais utilisée sur un compte donné, connexion à une heure inhabituelle ou non autorisée, etc...).
Ensuite s'il s'agit qu'un supérieur puisse accéder au compte d'une autre personne pour une assistance quelconque, il existe des outils pour cela (partage d'écran sur Skype, teamviewer, etc...) il est important de ne pas tout mélanger à ce niveau.
C'est effectivement une position qui se défend et que je comprends
quelques explications toutefois car je crois m’être mal exprimé au départ:
je précise qu'ici il ne s'agissait pas d'autoriser un supérieur à accéder au compte d'une autre personne mais qu'un admin d'un établissement (généralement PME car les gros centres ont assez de monde en interne pour gérer) puisse solliciter l'aide de l’administrateur global non de l’établissement mais de l'interface dans son ensemble (il s'agirait en gros d'un helpdesk)
Après, je conviens que cela puisse poser des problèmes sécuritaires alors je vais abandonner cette idée et rajouterai un système d'aide détaillée.
Quel niveau d'administrateur établissement peut permettre d'intervernir sur toute partie d'un projet de cet établissement
Seul l'administrateur général pourra intervenir sur toute les parties de tous les projets.
Pour plus de précisions: les trois types d'administrateurs pourrons intervenir sur tout ou parti d'un projet de cet établissement
Accès total pour l'admin général
Accès aux budget des projets pour l'admin financier
Accès aux parties de gestions admin (contrats / nego etc) pour l'admin administratif
Concernant les règles de gestion des mises à jour, vous n'avez pas compris la question.
je suis désolé de ne pas avoir fournie la réponse escomptée
En espérant que je répondrais plus ici.
Ceci étant dit la réflexion ici m'aura permis d'identifier un nouvel administrateur que je qualifierais d'administrateur consultatif.
Un admin qui aurait à tout mais seulement en mode consultatif / ce même admin pourra bien évidemment être un gestionnaire d'un des projets et donc avoir un mode 2 sur ce projet spécifique;
Dans le cas d'une modification d'une donnée ou information relative à un projet et/ou de façon plus générale à toute information relative à une entité il est bien évidemment question de garder en stockage toutes les mises à jours effectuées.
il faudrait grossièrement parlant une table d'historique des modifications (ancien contenu / nouveau contenu / date de modif / personne ayant effectuée la modif)
seul l'admin général étant en mode 3 pourra supprimer un historique (ancien contenu devenu totalement obsolète ou autre motif).
dans le cas d'une entité:
- admettons un changement d'adresse (il faut garder l'ancienne quelque part ) et intégrer la nouvelle en tant qu'adresse officielle avec quelque part la date de modif
- admettons un changement de personnes représentantes (signataires, directeurs), il faut également garder les anciennes infos et prendre les nouvelles en tant qu'officiel tout en gardant une date de modification
-admettons un changement d'information bancaires (il faut aussi garder un historique des changements)
un admin général pourra ici intervenir sur tout en mode 3
un admin financier ne pourra intervenir que sur les infirmations bancaires en mode 2 et consulter le reste en mode 1
un admin admin ne pourra intervenir que sur les adresses / personnes représentantes en mode 2 et consulter le reste en mode 1
dans le cas d'un projet:
tant le cas d'un contenu rédactionnel il s'agit ici plus d'une gestion documentaire gérer au sein de la base sql via un historique des versions par datage + personne ayant mis à jour le contenu
néanmoins si une modif est effectuée directement dans le systèmes (exemple changement des WP entre la phase draft et montage) il faudrait ici garder un historique des WP anciens + prendre les nouveaux en tant qu'officiels avec date modif et explications.
un admin général pourra toujours tout faire en mode 3
un admin financier pourra ici et en mode 2 créer et modifier les budgets des projets
Concernant la granularité de gestion d'un projet
Dans un premier temps:
je rajoute déjà les autres étapes au projet:
- phase draft,
- phase montage,
- phase négociation ,
- phase en cours,
- phase amendement ,
- phase clôturée (projet étant arrivé à terme)
- phase rejeté (rejet des commission d'évaluation)
- phase abandon (de l’équipe)
premières réflexions:
https://drive.google.com/file/d/0B0Rb6S … sp=sharing
@
bientôt
#14 Re : Forum Général PHP » question sur l'utilisation du for ($i = 0; $i < $result; $i++) » 10-01-2014 12:01:31
Bonjour JC,
Merci à vous de m'accorder votre aide.
Je vais répondre point par point car je vois que vous êtes quelqu'un de pro dans la démarche.
- Etes-vous certain de vouloir refuser la possibilité à un administrateur de se connecter à son interface via une tablette? Est-ce pertinent?
Il ne me semblait pas avoir dit cela mais la question se pose.
Je ne vois pas inconvénient à ce que tous mes utilisateurs puissent accéder à l'interface via une tablette. seulement je pense que seul un mode de consultation serait adapté afin d’éviter toute mauvaise gestion. Ceci étant dit si un système d'historique est fait pourquoi ne pas tout autoriser apres tout selon les mêmes règles de gestion que citées.
Quels seraient les droits d'accès par défaut pour tout nouvel utilisateur sur votre plateforme avant attribution spécifique? (quel niveau et mode d'accès)
je précise à toutes fins utiles qu'avant d'entrer login / mot passe et avant qu'une vérification soit établie alors aucun accès ne sera autorisé.
les droits d'accès par défaut sera lecture seul sur les projets déjà débutés ou clôtures (non phase draft, non phase montage, non phase négociatio, non phase amendement)
Cette faculté qu'à un administrateur global de l'interface d'avoir un tel accès à un autre compte administrateur
un accord verbal ne sera pas suffisant, je voudrais pouvoir faire en sorte que tel administrateur après négociation orale puisse autoriser l'admin global via un bouton et une confirmation pendant un temps déterminer ou définitif à se connecter à sa propre interface en mode admin afin de pouvoir l'assister au besoin.
Quel niveau d'administrateur établissement peut permettre d'intervernir sur toute partie d'un projet de cet établissement? Il est en effet important qu'en cas d'absence, congé, maladie, etc... que le supérieur hiérarchique de cet administrateur absent puisse prendre le relai sur ses prérogatives au sein de la plateforme. Si cela n'est pas possible ainsi, quels sont les règles de gestion qui doivent s'appliquer dans ce cas de figure?
ce sont les gestionnaires qui interviennent au niveau projet mais les administrateur y ont également accès soit partiellement soit totalement en mode 3..
du fait qu'il y aura plusieurs gestionnaires et plusieurs administrateurs le problème d'absence ne se pose pas d'office
- Qu'en est-il des règles de gestion applicables aux mises à jour?
je ne suis pas sur de bien cerner votre demande.
lors d'une mise à jour incorporer au système, disons une nouvelle fonctionnalité, il faudrait que l'admin global puisse ou non l'appliquer à tout ou partie des établissements inscrits. seul l'admin global via son back-office gérera cela. les nouvelles fonctionnalités apparaîtrons ou non aux interfaces utilisateurs si activées.
Pour la suite, et avant de modéliser cette partie, il sera important de connaître la granularité des règles de gestion applicables à la gestion d'un projet au sein d'un établissement, afin de ne pas commettre d'erreur dans la modélisation des relations entre les droits d'accès et de gestion et chaque entité de gestion composant un projet.
au plaisir de pouvoir répondre si toutefois je saisissais ce à quoi corresponds la granularité des règles de gestion..
@ bientôt
#15 Re : Forum Général PHP » question sur l'utilisation du for ($i = 0; $i < $result; $i++) » 10-01-2014 12:01:31
Bonjour JC,
Voici ma réflexion sur l'interface, les utilisateurs et leurs droits d'accès à ce stade:
Tout d'abord la structure envisagée :
• 1 base de données
• 2 interfaces
=> 1 interface web en php et mysql (avec frontoffice et backofice)
=> 1 interface tablette et mobile (uniquement pour la consultation)
Concernant les utilisateurs et leurs niveaux d'accès:
Pour chaque niveau d’accès que je vais lister ci-après, je souhaiterai 3 modes :
- Un mode lecture simple (mode 1)
- Un mode lecture / écriture (mode 2)
- Un mode lecture /écriture /suppression (mode 3)
Il est bien évident que suivant le niveau d’accès, tel ou tel mode s’imposera.
Un utilisateur qui n’est pas admin pourra bien évidemment avoir plusieurs niveaux d’accès et modes différents sur les différents projets auquel il a accès.(exemple : lecture simple sur tous les projets (hors phase montage) et lecture écriture et peut être suppression sur certains dont ils auront la charge.
Attention, néanmoins un utilisateur peut être admin de plusieurs établissements ou admin d’un établissement et simple gestionnaire projet dans un autre..
Un administrateur global de l’interface
- Accès et gestion du back-office :
=> Ajout d’un nouvel établissement
=> Ajout de nouveaux utilisateurs pour n’importe quel établissement
=> Pourra se connecter au compte de n’importe quel établissement de la base si accord d’un administrateur général de l’établissement en question afin d’apporter une aide si besoin était.
=> Avertissement des maintenances et autres mises à jour
=> Gestion des droits d’accès
=> Autres à définir…
Pour chaque établissement
1) Un ou plusieurs administrateurs d’établissements
Dans ce profil administrateur j'aimerai envisager s’il faut pousser la réflexion les niveaux d'accès suivant
1.1) un niveau d’admin général ayant le pouvoir modifier toutes les infos d’un établissement et d’attribuer / modifier / supprimer les comptes d’utilisateurs des membres de son établissement et les données liés à leurs projets. (mode 3 sur tout)
1.2) un niveau d’ordre uniquement financier pour modifier les déclarations de trésorerie, les données bancaires, les données liées au budget propres aux projets (toutes phases confondues) etc. (mode 3 sur la partie financière uniquement et mode 1 pour le reste)
1.3) un niveau d’ordre administratif pour modifier uniquement les coordonnées légales d’un établissement (adresse, téléphone, etc.) et pouvoir attribuer tel ou tel niveau d’accès aux autres utilisateurs de son établissement (mode 3 sur la partie admin et mode 1 pour le reste)
Pour chaque projet
1) un ou plusieurs comptes de gestionnaires de projet
1.1) niveau d’accès : administratif pour créer / modifier / gérer les données propres à un projet et lié au :
=> montage (déclaration / contrat / montage et suivi budgétaire /amendement / annexe technique (WP / milestones / deliverables ) etc.
=> Au suivi (reporting / modifications des WP/ milestones / deliverables (avec historique modification)/ modification du budget (avec historique modification)
=> Gestion des feuilles de temps, du personnel à déclarer
1.2) niveau d’accès : scientifique pour créer / modifier / gérer les données propres à un projet et lié au contenu scientifique (avec historiques des mis à jours) => mais il s’agit ici plus d’une gestion de fichier + autres fonctionnalités
1.3) niveau d’accès juridique pour gérer les accords de consortium sur le projet et les amendements spécifiques (avec historique modif) => mais il s’agit ici plus d’une gestion de fichier
@+
#16 Re : Forum Général PHP » question sur l'utilisation du for ($i = 0; $i < $result; $i++) » 10-01-2014 12:01:31
Rebonjour,
Je comprends bien la logique de votre réflexion et il va donc me falloir réfléchir un peu plus à l'ensemble alors… je vais préparer cela pour demain !
il faudrait effectivement que je prévois un système de gestion d'historique plus poussé que ce que j'avais initialement prévu.
Mais cela revient donc à créer plusieurs tables pour des mêmes éléments non?
Exemple une entité ayant une adresse A qui déménage en adresse B.
L’adresse B devient donc officielle mais l'adresse A doit être gardée en historique...de même et dans ce même cas, comment procéder pour savoir que pour tel et tel projet c'est telle adresse à tel moment qui était attribuée?
#17 Re : Forum Général PHP » question sur l'utilisation du for ($i = 0; $i < $result; $i++) » 10-01-2014 12:01:31
Bonjour JC,
Je ne pensais pas qu’il fallait être aussi précis dès le début.
Ne peut-on pas créer de nouveaux niveaux d’accès dans le futur et créer des limites d’accès propre au niveau ?
Dans mon idée je pensais créer la structure générale, les catégories et applications propres à celle-ci et ensuite configurer dans une table de gestion d’accès quel groupe aurait accès à quoi en tant que lecture simple ou lecture/écriture. Mais peut être est ce que je fais fausse route.
- Quel est le découpage fonctionnel de ces catégories?
Je ne suis pas bien sûr de comprendre la question. Souhaitez-vous savoir les catégories à créer ?
Pour le reste des réponses, je vais cogiter un peu plus et revenir vers vous.
Cordialement
#18 Re : Forum Général PHP » question sur l'utilisation du for ($i = 0; $i < $result; $i++) » 10-01-2014 12:01:31
Bonjour JC,
Merci pour votre retour et tous mes voeux pour 2014.
Au sujet des règles de gestion:
en effet un utilisateur à un login et un mot de passe qui lui permettrons d'accéder à l'interface de gestion. (administrateur de certaines catégories ou simplement autorisé à consulter certaines parties)
Une fois connecté, le système ira vérifier le niveau d'accès de ce même utilisateur.
pour chaque projet doit être indiqué un contact:
=> scientifique
=> juridique
=> administratif
le wp leader représente ici à la fois une personne et un etab.
Concrètement, le wp leader représente ici l'établissement en charge de ce WP. mais il est vrai que derrière ce sera le responsable scientifique de ce même établissement qui sera en charge de cela. mais dans tous les cas j'ai besoin de savoir prioritairement l’établissement en charge.
chaque établissement à un ou plusieurs représentants légaux.
ce représentant peut effectivement être un des contacts soit admin/ scientifique ou juridique mais cela est rare..
ceci étant dit, dans le cas du tpe, une même personne peux avoir toutes les casquettes.
effectivement il serait bon d'avoir un historique des représentants légaux car admettons d'un directeur change en cours il est judicieux d'avoir le nom de l’ancien représentant mais aussi le nouveau
pour finir sur la partie historiques des utilisateurs sur les composantes projets:
j'aimerai effectivement mais je n'y avait pas pensé pouvoir garder un historique des personnes impliquées sur un projet même si une personne le quitte pour une raison ou une autre (changement d’établissement / arrêt de la recherche / abandon etc...)
Concernant les données financières.
votre remarque est pertinente car si un établissement changeait de données bancaires à un moment ou un a un autre cela modifierait leurs données y compris pour les projets plus anciens.
Ceci étant, un etab ne change pas de donnée bancaires trop fréquemment non plus donc faut il tout de même prévoir des données bancaires pour chaque projet?
Merci pour votre aide,
Cordialement,
#19 Re : Forum Général PHP » question sur l'utilisation du for ($i = 0; $i < $result; $i++) » 10-01-2014 12:01:31
Je vous remercie à mon tour pour votre aide.
Entre temps je ne chaume pas, je me forme un peu plus sur le php orienté objet, sur la modélisation MVC etc, ce progresse mais c'est pas simple non plus... Je regarde des vidéos de grafikart. Mais en connaissez vous d'autres par ailleurs afin que je puisse m'améliorer encore?
#20 Re : Forum Général PHP » question sur l'utilisation du for ($i = 0; $i < $result; $i++) » 10-01-2014 12:01:31
si cela peut aider, voila la représentation graphique:
https://drive.google.com/file/d/0B8uGkm … sp=sharing
si je me base sur mon modèle conceptuel et afin de vérifier les points 1 par 1:
je ne suis pas certain par ailleurs que mes datatype de champs sont partout adéquat
1) Un établissement à plusieurs utilisateurs et un utilisateur peut faire partie de plusieurs établissement donc sommes nous bien d'accord qu'une table associative s'impose? ce que j'ai fais me semble ici logique. Néanmoins, question: Pourrais-je au sein de cette table associative indiquer les niveaux d'accès ou est-ce préférable de procéder autrement?
2) Un établissement n'a pas plusieurs données financières donc par conclusion il s'agit d'une relation 1:1. est ce ok?
3) Un établissement peut avoir plusieurs représentants légaux donc relation 1:n. est ce ok?
4) Un établissement n'a qu'un type de statut donc relation 1:1 contrairement à ma modélisation qui indique une relation 1:n? mais je n'ai jamais demandé ça quand j'ai construit ma table...enfin je ne pense pas...
5) Un établissement peut avoir plusieurs projets et un projet peut avoir comme partenaire plusieurs établissement donc table associative je pense.
Cependant je ne sais pas si j'ai bien fais de mettre autant de donnée dans cette table d'autant que de base il y a bien qu'un seul contact admin, financier ou juridique mais si je veux pouvoir rajouter d'autres personnes associées disons cela pourra un jour me poser problème. Dois je donc prévoir de créer des tables 1:N liées avec ma table de jointure, 1 pour les contacts administratifs, 1 pour les contacts juridiques et enfin une pour les contacts scientifiques??
6) Contrairement à ce que me donne ma modélisation et après réflexion un projet peut avoir plusieurs comptes avec un solde différent donc il aurait fallu faire une relation 1:N je présume et non 1:1, comment puis je modifier cela dans ma base existante?
7) 1 projet à plusieurs Wp (Work Package) donc 1:n comme je l'ai fait à priori
8) chaque WP à plusieurs objectifs et plusieurs deliverables donc pour chacun des cas il faut bien faire une relation 1:N, non?
une fois ces points validés, je pense déja que j'aurais avancé un peu... je crois
#21 Re : Forum Général PHP » question sur l'utilisation du for ($i = 0; $i < $result; $i++) » 10-01-2014 12:01:31
Bonjour JC,
Je vous avais écrit un mail indiquant que j'avais procédé à un reverse engineering de ma base afin de diagnostiquer l'étendue des dégâts mais bon je vais donc tenter de détailler une vue globale de la base que j'ai par rapport à ce que souhaite (mais ça va faire plus long qu'en représentation graphique, )
Objet : Je souhaite développer une interface de gestion des projets que je gère afin de ma faciliter la vie à terme qui soit consultable et parfois modifiable par des utilisateurs et par ailleurs des utilisateurs d’autres organismes que le mien (projet collaboratif).
Pour se faire, j’ai créé une base de données dans laquelle j’ai plusieurs tables :
Je vais segmenter ma présentation en :
- tables principales
- Table de jointure
- Table annexes
Les tables principales
1) Une table que j’ai appelée « infos_gen_projets » dans laquelle je stocke les infos générales liées au projet à savoir la date de début, de fin, durée, numéro de contrat, acronyme etc.
`id_Projet` INT(11) NOT NULL AUTO_INCREMENT,
`IG_acronyme` VARCHAR(50) NOT NULL,
`IG_titre` VARCHAR(100) NOT NULL,
`IG_ligne` VARCHAR(150) NOT NULL,
`IG_appel` VARCHAR(32) NOT NULL,
`IG_nbcontrat` MEDIUMINT(9) UNSIGNED NOT NULL,
`IG_date-debut` DATE NOT NULL,
`IG_duree` TINYINT(2) UNSIGNED NOT NULL,
`IG_prolongation` TINYINT(2) UNSIGNED NULL DEFAULT NULL,
`IG_date-fin` DATE NOT NULL,
`IG_abstract` TEXT NOT NULL,
`id_keywords` TEXT NOT NULL,
`IG_logo` TEXT NULL DEFAULT NULL,
`IG_contribce_requested` DECIMAL(10,2) NOT NULL,
PRIMARY KEY (`id_Projet`))
ENGINE = InnoDB
AUTO_INCREMENT = 3
DEFAULT CHARACTER SET = utf8;
2) J’ai ensuite crée une autre table « etab » dans laquelle je stocke les données lis aux organismes enregistrés avec nom, acronyme, adresse, siteweb etc.
`id_Etab` INT(11) NOT NULL AUTO_INCREMENT,
`ETAB_acronyme` TINYTEXT NOT NULL,
`ETAB_nom` TINYTEXT NOT NULL,
`ETAB_pic` INT(11) NOT NULL,
`ETAB_nb` VARCHAR(15) NOT NULL,
`ETAB_adresse` TINYTEXT NOT NULL,
`ETAB_cp` CHAR(10) NOT NULL,
`ETAB_ville` TINYTEXT NOT NULL,
`ETAB_pays` TINYTEXT NOT NULL,
`ETAB_logo` TEXT NOT NULL,
`ETAB_siteweb` VARCHAR(255) NOT NULL,
PRIMARY KEY (`id_Etab`))
ENGINE = InnoDB
AUTO_INCREMENT = 25
DEFAULT CHARACTER SET = utf8;
3) Enfin la table utilisateurs dans laquelle je stocke le login, mdp, mail etc sur les utilisateurs enregistrés, je devrais également à terme créer une autre table de gestion de droits.
`id_Utilis` INT(11) NOT NULL AUTO_INCREMENT,
`Utilis_login` VARCHAR(150) NOT NULL,
`Utilis_mdp` CHAR(40) NOT NULL,
`Utilis_grain` CHAR(32) NOT NULL,
`Utilis_date_inscrip` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
`Utilis_debmail` VARCHAR(150) NOT NULL,
`Utilis_srvmail` VARCHAR(25) NOT NULL,
`Utilis_extmail` VARCHAR(25) NOT NULL,
PRIMARY KEY (`id_Utilis`))
ENGINE = InnoDB
AUTO_INCREMENT = 2
DEFAULT CHARACTER SET = utf8;
Tables de jointure
1) Table de jointure entre Etab et Utilisateurs pour savoir à quel établissement appartient tel utilisateur
`id_jonc` INT(11) NOT NULL AUTO_INCREMENT,
`id_Utilis` INT(11) NOT NULL,
`id_Etab` INT(11) NOT NULL,
PRIMARY KEY (`id_jonc`),
INDEX `id_Utilis` (`id_Utilis` ASC, `id_Etab` ASC),
INDEX `id_Etab` (`id_Etab` ASC),
CONSTRAINT `jonc_etab_utilisateur_ibfk_1`
FOREIGN KEY (`id_Utilis`)
REFERENCES `h2020`.`utilisateurs` (`id_Utilis`)
ON DELETE CASCADE
ON UPDATE CASCADE,
CONSTRAINT `jonc_etab_utilisateur_ibfk_2`
FOREIGN KEY (`id_Etab`)
REFERENCES `h2020`.`etab` (`id_Etab`)
ON DELETE CASCADE
ON UPDATE CASCADE)
ENGINE = InnoDB
AUTO_INCREMENT = 2
DEFAULT CHARACTER SET = utf8;
2) La table de jointure entre Etab et infos gen projets
Celle-ci est assez complète car elle stocke beaucoup d’infos.
Elle permet de savoir déjà quel etab est associé à tel projet, avec quel statut (partenaire ou coordonnateur), le numéro (numéro de partenaire du projet), la date d’entrée de sortie, le responsable admin, scientifique, juridique
`id_jonc` INT(11) NOT NULL AUTO_INCREMENT,
`id_Etab` INT(11) NOT NULL,
`id_Projet` INT(11) NOT NULL,
`JONC_EP_statut` ENUM('coord','partn') NOT NULL,
`JONC_EP_nb` TINYINT(2) UNSIGNED NOT NULL,
`JONC_EP_entry` TINYINT(2) UNSIGNED NOT NULL,
`JONC_EP_exit` TINYINT(2) UNSIGNED NOT NULL,
`JONC_EP_contrib_requested` DECIMAL(10,2) NOT NULL,
`JONC_EP_overheads_particuliers` TINYINT(2) NOT NULL,
`JONC_EP_titre_scientifique` VARCHAR(10) NOT NULL,
`JONC_EP_gender_scientifique` ENUM('M','F') NOT NULL,
`JONC_EP_prenom_scientifique` VARCHAR(30) CHARACTER SET 'latin1' COLLATE 'latin1_general_ci' NOT NULL,
`JONC_EP_nom_scientifique` VARCHAR(30) CHARACTER SET 'latin1' COLLATE 'latin1_general_ci' NOT NULL,
`JONC_EP_dbemail_scientifique` VARCHAR(150) CHARACTER SET 'ascii' NOT NULL,
`JONC_EP_srvemail_scientifique` VARCHAR(25) NOT NULL,
`JONC_EP_extemail_scientifique` VARCHAR(25) NOT NULL,
`JONC_EP_titre_admin` VARCHAR(10) NOT NULL,
`JONC_EP_gender_admin` ENUM('M','F') NOT NULL,
`JONC_EP_prenom_admin` VARCHAR(30) NOT NULL,
`JONC_EP_nom_admin` VARCHAR(30) NOT NULL,
`JONC_EP_dbemail_admin` VARCHAR(150) CHARACTER SET 'ascii' NOT NULL,
`JONC_EP_srvemail_admin` VARCHAR(50) NOT NULL,
`JONC_EP_extemail_admin` VARCHAR(50) NOT NULL,
`JONC_EP_titre_judiciaire` VARCHAR(10) NOT NULL,
`JONC_EP_gender_judiciaire` ENUM('M','F') NOT NULL,
`JONC_EP_prenom_judiciaire` VARCHAR(30) NOT NULL,
`JONC_EP_nom_judiciaire` VARCHAR(30) NOT NULL,
`JONC_EP_dbemail_judiciaire` VARCHAR(150) CHARACTER SET 'ascii' NOT NULL,
`JONC_EP_srvemail_judiciaire` VARCHAR(50) NOT NULL,
`JONC_EP_extemail_judiciaire` VARCHAR(50) NOT NULL,
PRIMARY KEY (`id_jonc`),
INDEX `id_Projet` (`id_Projet` ASC),
INDEX `id_Etab` (`id_Etab` ASC),
CONSTRAINT `jonc_etab_projets_ibfk_1`
FOREIGN KEY (`id_Etab`)
REFERENCES `h2020`.`etab` (`id_Etab`)
ON DELETE CASCADE
ON UPDATE CASCADE,
CONSTRAINT `jonc_etab_projets_ibfk_2`
FOREIGN KEY (`id_Projet`)
REFERENCES `h2020`.`infos_gen_projets` (`id_Projet`)
ON DELETE CASCADE
ON UPDATE CASCADE)
ENGINE = InnoDB
AUTO_INCREMENT = 26
DEFAULT CHARACTER SET = utf8;
Table annexes
1) Liées à la table Etab
- La table « finances » dans laquelle je stock le numéro de tva, swift, iban
`id_Finances` INT(11) NOT NULL AUTO_INCREMENT,
`id_Etab` INT(11) NOT NULL,
`FIN_tva` CHAR(13) CHARACTER SET 'ascii' COLLATE 'ascii_bin' NOT NULL,
`FIN_iban` CHAR(31) CHARACTER SET 'ascii' COLLATE 'ascii_bin' NOT NULL,
`FIN_swift` CHAR(11) CHARACTER SET 'ascii' COLLATE 'ascii_bin' NOT NULL,
PRIMARY KEY (`id_Finances`),
INDEX `id_Etab` (`id_Etab` ASC),
CONSTRAINT `etab_finances_ibfk_1`
FOREIGN KEY (`id_Etab`)
REFERENCES `h2020`.`etab` (`id_Etab`)
ON DELETE CASCADE
ON UPDATE CASCADE)
ENGINE = InnoDB
AUTO_INCREMENT = 26
DEFAULT CHARACTER SET = utf8;
- La table « overheads » dans laquelle je stocke le % des coûts indirects à appliquer suivant l’établissement et le programme.
`id_Etab` INT(11) NOT NULL,
`id_overheads` INT(11) NOT NULL AUTO_INCREMENT,
`OVH_programme` ENUM('FP7','H2020') NOT NULL,
`OVH_montant` DECIMAL(10,3) NOT NULL,
PRIMARY KEY (`id_overheads`),
INDEX `id_Etab` (`id_Etab` ASC),
CONSTRAINT `etab_overheads_ibfk_1`
FOREIGN KEY (`id_Etab`)
REFERENCES `h2020`.`etab` (`id_Etab`)
ON DELETE CASCADE
ON UPDATE CASCADE)
ENGINE = InnoDB
AUTO_INCREMENT = 26
DEFAULT CHARACTER SET = utf8;
- La table « representatives » dans laquelle je stocke les infos sur les représentants officiels de chaque établissement : nom, prénom, titre etc.
`id_Repr` INT(11) NOT NULL AUTO_INCREMENT,
`id_Etab` INT(11) NOT NULL,
`REPR_titre` TEXT NOT NULL,
`REPR_gender` ENUM('M','F') NOT NULL,
`REPR_prenom` TEXT NOT NULL,
`REPR_nom` TEXT NOT NULL,
`REPR_fonction` TEXT NOT NULL,
`REPR_phone1` VARCHAR(20) NOT NULL,
`REPR_phone2` VARCHAR(20) NOT NULL,
`REPR_fax` VARCHAR(20) NOT NULL,
`REPR_dbemail` VARCHAR(150) CHARACTER SET 'ascii' NOT NULL,
`REPR_srvemail` VARCHAR(50) NOT NULL,
`REPR_extemail` VARCHAR(50) NOT NULL,
`REPR_justif` TEXT NOT NULL,
PRIMARY KEY (`id_Repr`),
INDEX `id_Etab` (`id_Etab` ASC),
CONSTRAINT `etab_representatives_ibfk_1`
FOREIGN KEY (`id_Etab`)
REFERENCES `h2020`.`etab` (`id_Etab`)
ON DELETE CASCADE
ON UPDATE CASCADE)
ENGINE = InnoDB
AUTO_INCREMENT = 42
DEFAULT CHARACTER SET = utf8;
- La table « Legal » dans laquelle je stocke les infos liées aux statuts de l’établissement
`id_Etab` INT(11) NOT NULL,
`LEG_natural` ENUM('oui','non') NOT NULL,
`LEG_legpers` ENUM('oui','non') NOT NULL,
`LEG_nonprof` ENUM('oui','non') NOT NULL,
`LEG_researchorg` ENUM('oui','non') NOT NULL,
`LEG_pubbod` ENUM('oui','non') NOT NULL,
`LEG_intorg` ENUM('oui','non') NOT NULL,
`LEG_intorgeo` ENUM('oui','non') NOT NULL,
`LEG_educ` ENUM('oui','non') NOT NULL,
`LEG_enterp` ENUM('oui','non') NOT NULL,
`LEG_sme` ENUM('oui','non') NOT NULL,
UNIQUE INDEX `id_Etab` (`id_Etab` ASC),
CONSTRAINT `etab_legal_ibfk_1`
FOREIGN KEY (`id_Etab`)
REFERENCES `h2020`.`etab` (`id_Etab`)
ON DELETE CASCADE
ON UPDATE CASCADE)
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8;
2) Liées à la table Projet
- La table « Projets WP » dans laquelle je stocke les infos liées aux work-packages des projets
`id_Projet` INT(11) NOT NULL,
`id_wp` INT(11) NOT NULL AUTO_INCREMENT,
`WP_nb` TINYINT(2) NOT NULL,
`WP_type` TINYTEXT NOT NULL,
`WP_titre` TEXT NOT NULL,
`WP_start` TINYINT(2) NOT NULL,
`WP_end` TINYINT(2) NOT NULL,
`WP_leader` TINYINT(2) NOT NULL,
PRIMARY KEY (`id_wp`),
INDEX `id_Projet` (`id_Projet` ASC),
CONSTRAINT `projet_wp_ibfk_1`
FOREIGN KEY (`id_Projet`)
REFERENCES `h2020`.`infos_gen_projets` (`id_Projet`)
ON DELETE CASCADE
ON UPDATE CASCADE)
ENGINE = InnoDB
AUTO_INCREMENT = 15
DEFAULT CHARACTER SET = utf8;
- La table « WP objectifs »rattaché à WP dans laquelle je stocke les objectifs des Work package (1 ou plusieurs par WP)
`id_object` INT(11) NOT NULL AUTO_INCREMENT,
`id_wp` INT(11) NOT NULL,
`WP_objectif` TEXT NOT NULL,
PRIMARY KEY (`id_object`),
INDEX `wp_id` (`id_wp` ASC),
CONSTRAINT `projet_wp_objectifs_ibfk_1`
FOREIGN KEY (`id_wp`)
REFERENCES `h2020`.`projet_wp` (`id_wp`)
ON DELETE CASCADE
ON UPDATE CASCADE)
ENGINE = InnoDB
AUTO_INCREMENT = 46
DEFAULT CHARACTER SET = utf8;
- La table « Deliverables » rattaché à WP dans laquelle je stocke les infos liés aux déliverables de chacun des work packages du projet
`id_wp` INT(11) NOT NULL,
`id_deliv` INT(11) NOT NULL AUTO_INCREMENT,
`DELIV_nb` VARCHAR(5) NOT NULL,
`DELIV_titre` TEXT NOT NULL,
`DELIV_leader` TINYINT(2) NOT NULL,
`DELIV_pm` TINYINT(3) NOT NULL,
`DELIV_nature` TINYTEXT NOT NULL,
`DELIV_dissem` TINYTEXT NOT NULL,
`DELIV_date` TINYINT(2) NOT NULL,
PRIMARY KEY (`id_deliv`),
INDEX `id_wp` (`id_wp` ASC),
CONSTRAINT `projet_wp_deliverables_ibfk_2`
FOREIGN KEY (`id_wp`)
REFERENCES `h2020`.`projet_wp` (`id_wp`)
ON DELETE CASCADE
ON UPDATE CASCADE)
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8;
Et enfin la table « compte » rattaché à projet dans laquelle je stocke le numéro de compte, le solde, etc… du projet
`id_cpt` INT(11) NOT NULL AUTO_INCREMENT,
`id_Projet` INT(11) NOT NULL,
`CPT_nb` VARCHAR(15) NOT NULL,
`CPT_solde` INT(11) NOT NULL,
`CPT_solde_date` DATE NOT NULL,
PRIMARY KEY (`id_cpt`),
INDEX `id_Projet` (`id_Projet` ASC),
CONSTRAINT `projet_comptes_ibfk_1`
FOREIGN KEY (`id_Projet`)
REFERENCES `h2020`.`infos_gen_projets` (`id_Projet`)
ON DELETE CASCADE
ON UPDATE CASCADE)
ENGINE = InnoDB
AUTO_INCREMENT = 4
DEFAULT CHARACTER SET = utf8;
Voilà ma structure de base actuelle qui d’après vos précédentes remarques ne doit pas être adéquate.
dans l'attente de votre retour pour en discuter
#22 Re : Forum Général PHP » question sur l'utilisation du for ($i = 0; $i < $result; $i++) » 10-01-2014 12:01:31
Bonjour,
Encore en phase de construction bien qu'ayant déjà codè certaines fonctions, je suis tout a fait près a réprendre tout si cela s'impose, ce qui semble être le cas.
Au moins j'apprendrai a a mieux faire pour les prochaines fois!
Je vais donc réfléchir a l'ensemble et vous soumettre une vue globale. Merci en tout as d'être à l'écoute de débutant comme moi!
A vous de me dire par contre si vous souhaitez que je continue a tout poster ici ou sur une adresse mail.
Je prépare ça pour le début de semaine, le week-end étant plus destiné a s'occuper des enfants
#23 Re : Forum Général PHP » question sur l'utilisation du for ($i = 0; $i < $result; $i++) » 10-01-2014 12:01:31
Bon et bien je pense avoir de mauvaises fondations d'après votre post.
En espérant pouvoir régulariser cela car je voudrais pouvoir faire les choses correctement.
Je vais donc tenter de répondre point par point afin d'essayer de clarifier ce qu'il en est:
Point 1:
Un projet ne peut effectivement n'avoir qu'un seul et même acronyme. Au pire celui-ci sera modifié mais s'est tout.
Néanmoins un acronyme peut effectivement être similaire entre deux projets / dans ce cas,c'est le numéro de contrat qui lui sera unique.
Point 2:
Un wp est propre à un projet
De même, celui-ci a son propre wp_nb.
Il faut il comprendre que chaque projets a une liste de wp qui ont eux mêmes des livrables et des objectifs.
Les wp sont pour tous les projets de type wp1, wp2 etc mais les titres et autres infos sont propre aux projets.
Point 3
Chaque wp a un ou plusieurs objectif mais dans ma table j'ai bien fait une ligne par objectif car je pensais cela comme le meilleur moyen mais a tort il faut croire.
#24 Re : Forum Général PHP » question sur l'utilisation du for ($i = 0; $i < $result; $i++) » 10-01-2014 12:01:31
Non le wp1 du projet a ne peut être le même que le wp1 du projet b car deux projets distincts en tout point!
Il y a dans mon exemple de projet ici 7wp avec plusieurs objectifs pour certains et d'autres qu'un!
Quand je texte votre script je ne récupère que les objectifs du wp1..
#25 Re : Forum Général PHP » pseudo-frame et url » 07-12-2013 15:30:08
Bonjour.
J'ai pris connaissance de votre commentaire sur la page que vous m'avez indiqué. En plus d'être un expert de votre domaine, vous êtes bon pédagogue.
Je suis en phase de construction et au début donc je peux encore implémenter le rewrité.
Néanmoins, bien qu'ayant cerné un peu plus les choses, cela soulève une question.
Les liens rewrités n'existant que virtuellement faut il créer des règles pour toutes les combinaisons possible de mes pseudo-frame??
En effet ayant des liens types: index.php?corps=page1&menu=menu1
Il faut que je créé autant de rewrite que de cas ?
Merci par avance.