La gestion de temps de l’entreprise - diuf.unifr.chdiuf.unifr.ch/is/userfiles/file/studentprojects/S-2006_Matthias... · La gestion de temps de l’entreprise – conception d’une

Université de Fribourg

Département d’informatique (DIUF)

La gestion de temps de l’entreprise –

conception d’une base de données relationnelle basée web

Travail de séminaire

de

Matthias Vögeli

Rte. de la CitéBellevue 11

1700 Fribourg

encadrement par

Dr. rer. pol. Stefan Hüsemann

Juin 2006

La gestion de temps de l’entreprise – conception d’une base de données relationnelle basée web

Matthias Vögeli Juin 2006 Travail de séminaire

Abstract

Le but de ce travail est d’établir en collaboration avec l’entreprise de conseil en

gestion management de Zurich – ZIEL Consulting AG un outil pour la gestion

des heures de travail et des frais professionnels. Outre le résultat conceptionelle,

un prototype basé web va être implémenté et évalué à partir des données

collectionnées. Le système se base sur un serveur MySQL et le langage de

programmation PHP.

La solution vise à proposer un outil pour le rapport des heures de travail et des

frais de gestion qui se produisent pour le personnel de l’entreprise. La base de

données doit être accessible hors du bureau et hors de main d’oeuvre si

l’employé travaille sur un projet extérieur.

En s’appuyant sur le cycle de vie de l’application d’une base de données les

phases majeures du travail de séminaire sont: l’analyse des données et des

exigences, la modélisation conceptionnelle et logique, la réalisation et

l’implémentation du prototype et finalement l’évaluation du prototype.

Motsclés

§ Système de gestion de base de données (SGBD)

§ Modèle entitéassociation (ERM)

§ Schéma de base de données relationnelle

§ MySQL

§ PHP

§ PhpMyAdmin


Matthias Vögeli Juin 2006 1

Table des matières

1 PRELIMINAIRE ............................................................................................. 2

1.1 ENONCE DU PROBLEME ..................................................................................... 2 1.2 OBJECTIFS .................................................................................................... 2 1.3 DEMARCHE ET QUESTIONS ................................................................................ 3

2 L’ANALYSE DES EXIGENCES.......................................................................... 6

2.1 ETAT ACTUEL ................................................................................................. 6 2.2 DETERMINATION DES EXIGENCES ..................................................................... 10 2.3 DESCRIPTION DU SYSTEME A CONSTRUIRE ET DES DONNEES ................................... 11

3 MODELISATION .......................................................................................... 14

3.1 MODELE ENTITEASSOCIATION ........................................................................ 14 3.1.1 Entités................................................................................................. 14 3.1.2 Les types d’associations......................................................................... 15 3.1.3 Modèle................................................................................................. 16

3.2 SCHEMA DE BASE DE DONNEES RELATIONNELLE.................................................... 16 3.2.1 Les règles ............................................................................................ 17 3.2.2 Les tables ............................................................................................ 18 3.2.3 Les contraintes d’intégrité structurelles.................................................... 19

4 REALISATION ET IMPLEMENTATION DU PROTOTYPE ................................. 21

4.1 TECHNOLOGIES UTILISEES POUR L’IMPLEMENTATION ............................................ 21 4.2 CONSTRUCTION DE LA BASE DE DONNEES ........................................................... 22 4.3 CREATION DE L’INTERFACE UTILISATEUR SIMPLIFIEE ............................................ 23

5 EVALUATION DU PROTOTYPE ..................................................................... 29

6 CONCLUSION ET PERSPECTIVES................................................................. 30

7 BIBLIOGRAPHIE ......................................................................................... 31

8 ANNEXE ...................................................................................................... 32

8.1 RESULTAT DE L’ENQUETE DANS L’ENTREPRISE ZIEL CONSULTING AG (EXTRAITS) ...... 32 8.2 CAPTURES D’ECRAN DE PHPMYADMIN ............................................................... 33



1 Préliminaire

1.1 Enoncé du problème

La gestion des heures de travail et des défraiements est en général géré avec

beaucoup de différences dans les petites et moyennes entreprises. Quelques

solutions utilisées par des PME sont loin de satisfaire objectivement les besoins

des employeurs et aussi des employés. En plus une généralisation du problème

des outils de décompte des heures et par conséquence une solution partout

applicable n’est pas possible étant donné qu’ils existent des différences

considérables entre les secteurs d’activités des entreprises. Ce qui est en général

demandé par les PME est un système centralisé avec l’intégration des processus

de l’entreprise et une haute accessibilité par les utilisateurs. La simplification de

la collection et de l’échange des données dans et entre les différents

départements de l’entreprise est à viser.

Par rapport à une entreprise startup, les dépenses administratives sont

d’ordinaire et malheureusement négligées pendant les premières années de

croissance. À partir d’une certaine taille de l’entreprise, les moyens du contrôle

deviennent insuffisants tandis que la gestion de l’enregistrement du temps et des

frais de travaux deviennent de plus en plus embrouillé.

1.2 Objectifs

Le but de ce travail est d’établir en collaboration avec l’entreprise de conseil en

gestion management de Zurich – ZIEL Consulting AG un outil pour la gestion

des heures de travail et des frais professionnels. ZIEL Consulting est fondée en

2002 avec l’objectif de conseiller le management au niveau stratégique en

questions de croissance d’entreprise. ZIEL Consulting a connue une forte

croissance des nombres des employés ainsi que du volume des commandes.

Outre le résultat conceptionnel, un prototype basé web va être implémenté et

évalué à partir des données collectionnées.

Les acteurs du marché des outils de gestion de temps ont compris les avantages

compétitifs que l’Internet pouvait leur apporter. Le système de gestion de base



de données constitue la technologie clé de l’économie Internet en mettant à

disposition leur propre langage et leur puissante fonction d’analyse de données.

Dans le but d’améliorer la situation actuelle, il est incontournable d’établir un tel

système comme outil pour la gestion du temps des entreprises. Les composants

du système doivent être des logiciels et des applications open source. Un logiciel

est dit open source lorsqu’il accompli les principaux critères nécessaires comme

la libre redistribution, un code source disponible ainsi que la possibilité de

travaux dérivés.

Si on a pu faire le bilan positif de l’évaluation du prototype, l’idée est de créer

une interface utilisateur sophistiquée, d’implémenter la version finale et de

maintenir le système de façon opérationnel dans l’entreprise ZIEL Consulting.

Cette démarche ne va pas être l’objet de ce travail.

1.3 Démarche et questions

En s’appuyant sur le cycle de vie de l’application d’une base de données (cf. Fig.

1.3.1.) on peut identifier quatre phases majeures: l’analyse des données et des

exigences, la modélisation conceptionnelle et logique, la réalisation et

l’implémentation du prototype et finalement l’évaluation du prototype.

Fig. 1.3.1.: Le cycle de vie de l’application d’une base de données [Connolly, Begg, Strachan 1996, p.125]



L’analyse des données vise à identifier l’état actuel avec une approche

systémique pour pouvoir déterminer les marges de fonctionnement du système

actuel, la délimitation des soussystèmes et de définir les interfaces en

s’appuyant sur [Jenny 1997]. Par la suite, les exigences envers le nouveau

système de gestion des heures de travail et le système de gestion de base de

données doivent être déterminés en collaboration avec ZIEL Consulting. Les

données pertinentes, leurs liaisons et leurs structures doivent permettre

d’élaborer une documentation complète. En plus, les fonctionnalités et les limites

du système doivent être fixées. Les questions suivantes se posent dans cette

phase: Quel est l’état actuel du système? Quelles données doiton pouvoir gérer?

Quelles sont les exigences envers un outil de gestion de temps pour ZIEL

Consulting?

La modélisation conceptionnelle et logique vise à concevoir un modèle entité

association. A l’aide de ce modèle, les données, leurs liaisons et les informations

qui sont mis à disposition pendant la phase de l’analyse sont représentés

graphiquement pour que l’on puisse convertir le modèle entitéassociation en un

schéma de base de données relationnelle. Les questions suivantes se posent

dans cette deuxième phase: Comment les données doiventelles être modelées

dans le modèle entitéassociation? Quelle est la spécification de la structure des

données et de leurs contraintes d’intégrité?

La prochaine phase sert à la réalisation et l’implémentation d’un prototype.

Prototyping est la création d’un modèle simplifié utilisable d’une application de la

base de données [Connolly, Begg, Strachan 1996, p. 132]. Avant la construction

de la base de données, les technologies utilisées, surtout PHP et MySQL, sont

brièvement présentées. La création d’une interface utilisateur simplifiée selon

quelques critères de [Shneiderman 1992] avec la connexion de la base de

données et la possibilité de simples interrogations achève cette phase de

construction. Les questions pertinentes dans cette phase sont: Quelles sont les

technologies informatique utilisée dans la construction du système? Comment on

connecte une page web dynamique avec une base de donnée?



La dernière phase vise à évaluer le prototype et proposer des améliorations. Les

questions posées dans cette partie sont: Estce que la solution proposée satisfait

les exigences et les besoins de l’utilisateur qu’on a identifié pendant la première

phase? Quelles sont les forces et les faiblesses d’un tel système? Quelles sont les

améliorations qui doivent être effectuées avant de construire la version finale du

système?

Les questions de la dernière phase doivent servir à identifier des faiblesses et

proposer des améliorations pour que l’on puisse les incorporer dans

l’implémentation d’un nouveau système de gestion des heures de travail dans

ZIEL Consulting pendant un projet qui va suivre à ce travail de séminaire.



2 L’analyse des exigences

2.1 Etat actuel

Le travail de ZIEL Consulting est organisé par projet. Cet à dire qu’on a plusieurs

clients générant des honoraires avec différents projets qui sont identifiable par

un code. De plus, on a des dépenses administratives et des dépenses du

développement des clients qui ne génèrent pas des honoraires. L’objectif de la

direction de ZIEL Consulting est de minimiser le ratio coûts / volume des

honoraires 3 et de maximiser le ratio volume des honoraires / jours décomptés 4 .

Le premier ratio vise à augmenter l’efficacité, tandis que le deuxième ratio à une

répercussion à la valeur ajoutée de l’entreprise. Le problème c’est qu’on n’a

quasiment pas de moyen de mesurer ces ratios avec le système actuel des

heures de travail et des défraiements.

La délimitation d’un système observé des autres systèmes devient nécessaire

pour garder la vue d’ensemble [selon Jenny 1997, p.3]. Un système au sens

organisationnel est identifiable et différenciable de ce qui l’entoure. En plus, il a

un comportement et agit en fonction d’un but [Huesemann 2005; p.25]. Par la

suite, les systèmes qui sont concernés dans l’entreprise vont être identifié de

manière systémique pour que l’on puisse décrire le flux de travail dans les

processus de ZIEL Consulting.

Dans un premier pas, la constitution de la marge de fonctionnement du système

et les éléments de l’environnement doivent être établie (cf. Fig. 2.1.1.). On

définit ce qui peutêtre grouper dans ou hors du cercle de problème. Nous

définissions la gestion du temps dans l’entreprise comme cercle de problème et

par conséquence comme système que nous allons observer. Les cercles qui sont

représentés hors du système principal 5 ont une relation directe par un ou

plusieurs soussystèmes de la gestion du temps. L’environnement fournit des

entrées au système qui lui permet d’opérer. La gestion du temps génère à son

tour des sorties vers l’environnement [Huesemann 2005; p.25].

3 En anglais: “CostIncomeRatio” 4 En anglais: “Value added” 5 Selon [Jenny 1997]: „Umsysteme“



Employés Clients

Comptabilité

Autres départements

Bulletin de paye Banque

La gestion du temps marge du système

Fig. 2.1.1.: Marge du système adapté de l’exemple dans [Jenny 1997; p. 7]

La prochaine étape, qui est visualisée dans la Fig. 2.1.2. vise à délimiter les

soussystèmes de la gestion du temps. Les soussystèmes interagissent entre

eux et chaque soussystème a luimême les caractéristiques d’un système. Les

composants de la gestion du temps sont l’enregistrement du temps comme la

preuve des défraiements qui est fait par les employés. L’allocation des ressources

ainsi que la gestion de projets est organisé par le chargé du projet et la gérance.

Ces deux derniers soussystèmes ne vont pas être considérés dans le travail de

séminaire.

La gestion du temps

Enregistrement du temps

Preuve des défraiements

Gestion de projets

Allocation des ressources

Fig. 2.1.2.: Soussystèmes adapté de l’exemple dans [Jenny 1997; p. 9]

La dernière nécessitée dans l’approche systémique est la définition des interfaces

(cf. Fig. 2.1.3.). Cette définition montre les dépendances entre les sous

systèmes séparés et les éléments de l’environnement. On différencie les

interfaces externes et les interfaces internes.



Employés

Clients

Comptabilité

Autres départements

Bulletin de paye

Banque

Enregistrement du temps

Preuve des défraiements

Gestion de projets

La gestion du temps

Ne sont pas considéré en solution

Impact sur le SGBD

Interfaces internes

Interfaces externes

Allocation des ressources

Fig. 2.1.3.: Interfaces adapté de l’exemple dans [Jenny 1997; p. 10]

A partir de la définition des interfaces, le système de la gestion du temps et ces

soussystèmes sont représentés de manière intégrale. Le déroulement du

processus et le flux de travail 6 de la gestion de temps dans l’entreprise peuvent

être représentés graphiquement.

Il existe aussi d’autres méthodes pour l’analyse et la description d’un système.

On aurait aussi pu appliquer le modèle de cas d’utilisation 7 qui est un produit de

travail dans RUP 8 . Un cas d’utilisation sert à représenter les exigences

fonctionnelles envers le système.

6 Anglais: „Workflow“ 7 Anglais: „use case model“ 8 Rational Unified Process



Le flux de travail (cf. Fig. 2.1.4.) peut être d’abord décrit sous le point de vue de

l’employé. Chaque employé à son propre Timesheet sur un mois. Ce Timesheet

est un fichier en Excel où les données sont remplies jour par jour.

Fig. 2.1.4.: Workflow ZIEL Consulting

L’exemple dans la Fig. 2.1.5. montre le remplissage d’un fichier de temps 9 . On a

d’abord le remplissage de la date. Le code se compose d’une abréviation du

projet et de son numéro. La colonne billable décide si la comptabilité peut

facturer le travail effectué et les frais de gestion au client.

Date Project Hours Bil lable (Y/N) Task Expenses (Y/N) Currency Amount Justification

12.04.2006 ADM 00X 8 N comptabilité N 13.04.2006 UNI 002 4 Y analyse concurrenciel Y CHF 75. train ZürichFribourg

Fig. 2.1.5.:Fichier Excel pour la gestion du temps (exemple)

9 Timesheet



En fin de mois, l’employé envoie son Timesheet au responsable du département

de comptabilité et du bulletin de paye. En même temps les preuves des

défraiements pour les montants des frais dans le fichier de temps doivent être

transmises. Le département de comptabilité réunit toutes les données des

employés. Elles sont soumises à une évaluation pour pouvoir payer les salaires et

facturer les comptes débiteurs. Par la suite, les documents sont classé à

l’archive.

L’avantage de cette solution en Excel est que la réalisation est relativement

simple avec un petit nombre des employés. En plus on est capable d’effectuer

des analyses par les employés par mois et année.

Il y a un grand nombre de désavantages qui sont que le système de gestion du

temps avec la solution des Timesheets est gérée en décentralisation et que des

interrogations sophistiquées ne sont pas effectuable. Avec une plus grand

nombre d’employés ça devient de plus en plus difficile de collecter, d’évaluer et

de stocker les donnés d’une manière propre. De plus, une contrôle des ratios

n’est pas applicable d’une manière satisfaisante. Le niveau d’automatisation, la

grande source d’erreurs et l’accessibilité limitée sont aussi des facteurs

désavantageux.

2.2 Détermination des exigences

Partant de l’analyse de l’état actuel avec ses forces et ses faiblesses, les

exigences envers le nouveau système doivent être définies. En outre on doit

savoir, quelles données sont à gérer. Pour obtenir ces informations cruciales, des

sondages avec les utilisateurs potentiels doivent être effectués dans l’entreprise

autant que la considération des documents accessibles et l’observation de

l’entreprise dans l’opération. Selon [Meier 2004, p.15] il est crucial d’utiliser le

langage des utilisateurs pour formuler les faits nécessaires au développement

ultérieur d’une base de données. Les exigences envers l’interface utilisateur et le

système à interrogation sélectif peuvent être décrite indépendamment.

Sur la base de l’étude du processus de gestion existant et de l’entretien avec les

collaborateurs et la direction, les exigences peuvent être constituées comme



suit: L’utilisateur doit avoir un accès sécurisé à l’interface utilisateur par son

navigateur Web de n’importe où dans le monde. Il doit avoir la possibilité de

remplir ses informations relatives à la gestion du temps dans des formulaires

prédéfinies. Les données pertinentes sont précisées en Fig. 2.3.2. Au niveau de

données il n’y aurait pas une grande différence visàvis de l’état actuel.

En ce qui concerne le système à interrogation sélective, on doit avoir un bond en

avant au niveau de la collection des données de tous les employés ainsi que

l’exploitation des informations nécessaires pour les autres départements

concernés. Des interrogations standardisées qui servent à un meilleur contrôle

doivent être prédéfinies. Des analyses par projet, par employé, par tout

personnel et par les frais de gestion, mais aussi des évaluations journalières,

mensuelles et annuelles doivent être possibles. Surtout, le département de

comptabilité aura besoin de ces interrogations. Cela implique, qu’elles doivent

s’effectuer sur une interface utilisateur qui ne requièrent pas des connaissances

de langages d’interrogation et de manipulation de données.

Ce qui est en question sont les limites des fonctionnalités du système. Le résultat

final n’aura pas un collecticiel, ni un outil de gestion de projet. Le nouveau

système de gestion de base de données ne va non plus automatiser

complètement le processus du bulletin de paye ni la facturation des clients.

2.3 Description du système à construire et des données

Une application est dite distribuée lorsqu’elle utilise plus d’une machine pour

assurer les services rendus. L’architecture du système à construire suit les règles

de répartition des fonctions

élémentaires de l’application sur ces

machines. Dans la Fig. 2.3.1. une

architecture client/serveur 2 couches

est représentée. D est la fonction du

stockage des données, T est la

fonction traitements des données

alors que IU est la fonction d’interface

utilisateur. Transposé sur le système à Fig. 2.3.1.: Fonction distribuable d’une application informatique



construire, cela signifie que le contrôle et la présentation s’effectuent locale au

poste de travail et qu’on a un serveur Web pour le stockage des données. Cela

veut dire, qu’il existe une interface utilisateur avancée où l’administrateur peut

effectuer des traitements des données 10 . En raison d’une interface utilisateur

sophistiquée, l’architecture client/serveur 2 couches est préférable pour une

version finale qui ne va pas être l’objectif du travail.

Le prototype implémenté va être construit selon une architecture client/serveur 3

couches (ou 3Tiers) visualisé dans la Fig. 2.3.2. Le serveur d’application est

alors séparé du serveur de données (SGBD). Avec cette solution il n’est pas

absolument nécessaire de construire une interface utilisateur haut niveau, parce

qu’on peut effectuer des traitements des données sur le poste de travail pour la

validation de l’IU.

Fig. 2.3.2.: Fonction distribuable d’une application informatique selon [Huesemann 2005; p.33]

Avant le lancement dans la modélisation des données, leur structure et leur

pertinence sont à identifier. Au Fig. 2.3.3. les différentes sortes de données sont

énoncées, leur format est assigné et un exemple est donné. Les formats des

données sont d’une part choisi selon l’utilisation par l’entreprise ZIEL Consulting,

comme les données concernant les projets, la compensation, l’activité ou les

frais. D’autre part des standards globalement acceptés sont appliqués comme la

date, les heures, la monnaie ou le montant.

10 En Anglais: „thick client, fat client, rich client”



Description Format Exemple date YYYYMMDD 20060412

20041102 project code (accordant to ZIEL Consulting) ADM 00X (internal task)

CDE 00X (internal task) UNI 003 (client) MAT 001 (client)

hours integer 8 4

billable boolean value (True or False) Y N

task character string Market analysis for China Due dilligence for M&A strategy Fact sheet for client

expenses boolean value (True or False) Y N

currency ISO4215 (currency code) CHF EUR USD GBP

amount decimal number 14.50 85.00

rationale character string Train from Zurich to Fribourg Business lunch

Fig. 2.3.3.: Description des données

Ce sont les données qui vont être remplies par les employés dans des

formulaires prédéfinis en interface utilisateur et qui vont apparaître dans la base

de donnés.



3 Modélisation

Après l’analyse des exigences et des données, l’idée principale de la modélisation

est la représentation graphique des données et de leurs relations. Dans le

modèle entitéassociation, les clés d’identifications pour les entités sont établi et

les types d’association entres les différentes relations sont assignés. Ca se passe

indépendamment du propre logiciel de la base de données. Dès que le modèle

entitéassociation est établi, le schéma de base de données relationnelle est mis

en place. A partir de ce schéma, la vraie programmation de la base de données

va s’effectuer.

3.1 Modèle entitéassociation

3.1.1 Entités

«Une entité est un objet spécifique qui peut être identifié distinctement parmi

d’autres objets dans le monde réel ou dans notre pensée. Elle peut désigner une

personne, un objet, un concept abstrait ou un événement. Les entités de même

type forment un ensemble d’entités caractérisées par un certain nombre

d’attributs» [Meier 2004, p. 16]. Pour chaque ensemble d’entités, on définit une

clé d’identification, c’estàdire un attribut ou une combinaison d’attributs qui

permet de distinguer de manière univalente les entités dans l’ensemble

considéré. 11

En appliquant la définition d’une entité au problème, on peut identifier les

ensembles d’entités présentées en Fig. 3.1.1.

Fig. 3.1.1. : Ensemble d’entités

Les différentes entités doivent avoir une relation en forme d’association. En

général, les liaisons définissent toujours des associations dans les deux directions

dans le modèle entitéassociation. Lors du système de gestion du temps, nous

aurons les associations représentées dans le Fig. 3.1.2.

11 De définitions semblables vous trouverez dans [Meier 2004, p. 16]



Fig. 3.1.2. : Associations

3.1.2 Les types d’associations

«Une association d’un ensemble d’entités (EE_1) à un deuxième ensemble EE_2

définit un lien orienté dans cette direction. Chaque association d’un ensemble

d’entités EE_1 à un autre ensemble EE_2 est caractérisée par un type. Le type

d’association de EE_1 à EE_2 indique le nombre d’entités provenant de

l’ensemble associé EE_2 qui sont reliées à une entité dans EE_1. On distingue

essentiellement quatre types d’associations» [Meier 2004, p. 18].

Association simple (Type 1)

À chaque entité dans l’ensemble d’entités EE_1 correspond une et une seule

entité dans l’ensemble EE_2.

Association conditionnelle (Type c)

À chaque entité dans l’ensemble EE_1 correspond au plus une entité dans

l’ensemble EE_2.

Association multiple (Type m)

À chaque entité dans l’ensemble d’entités EE_1 correspondent plusieurs entités

dans l’ensemble EE_2.

Association multiple conditionnelle (Type mc)

À chaque entité dans l’ensemble d’entités EE_1 correspondent aucune, une ou

plusieurs entités dans l’ensemble EE_2. Le type d’association multiple

conditionnelle se distingue du type d’association multiple par le fait qu’une entité

dans EE_1 peut ne pas être reliée à une entité dans EE_2.



Les types d’association déterminent le degré d’une liaison.

§ Liaisons de type simplesimple: (1,1) (1,c) (c,c)

§ Liaisons de type simplecomplexe (1,m) (1,mc) (c,m) (c,mc)

§ Liaisons de type complexecomplexe (m,m) (m,mc) (mc,mc)

3.1.3 Modèle

La représentation graphique du modèle entitéassociation (cf. Fig. 3.1.3.) est

indispensable pour la conversion en schéma de base de données relationnelle et

pour l’implémentation ultérieure.

Fig. 3.1.3. : Modèle entitéassociation

3.2 Schéma de base de données relationnelle

Après avoir disposé du modèle entitéassociation, la traduction en un schéma de

base de données relationnelle est à aborder. Il s’agit essentiellement de

représenter les ensembles d’entités et de liens par des tables. Ce schéma

contient la spécification de la structure des données et de leurs contraintes



d’intégrité. En outre, les tables, les attributs et les clés primaires sont définis.

Selon [Meier 2004] on peut appliquer cinq règles pour faciliter la traduction.

3.2.1 Les règles

Règle 1 (ensembles d’entités)

Chaque ensemble d’entités doit être traduit en une table distincte, avec une clé

primaire unique qui peut être soit la clé correspondante à l’ensemble d’entités,

soit une clé candidate. Les autres attributs de l’ensemble d’entités passent sur

les attributs correspondants de la table. [Meier 2004]

Règle 2 (ensembles de liens)

Chaque ensemble de liens peut être traduit en une table distincte. Elle doit

contenir les clés d’identification des ensembles d’entités participantes comme

clés étrangères. La clé primaire de la table ainsi obtenue peut être soit une clé

d’identification formée par la concaténation des clés étrangères, soit une autre

clé candidate, en créant par exemple une clé artificielle. Les autres attributs de

l’ensemble de liens complètent les attributs de la table. [Meier 2004]

Règle 3 (Liaisons de type complexecomplexe)

Chaque ensemble de liens complexecomplexe doit être transformé en une table

distincte. Les clés étrangères de la table sont formées au moins des clés

d’identification des ensembles d’entités qui participent à la liaison. La clé

primaire de la table est soit la clé d’identification formée par la concaténation des

clés étrangères, soit une autre clé candidate. D’autres attributs de l’ensemble de

liens deviennent les attributs de la table. [Meier 2004]

Règle 4 (liaisons de type simplecomplexe)

Un ensemble de liens simplecomplexe peut s’exprimer dans les deux tables des

ensembles d’entités participantes sans avoir besoin de créer une table distincte.

Pour cela, dans la table qui participe à l’association simple, on définit une clé

étrangère qui la relie à la table référencée en y ajoutant éventuellement d’autres

attributs de l’ensemble de liens considérés. Ainsi, en évitant de transformer une

liaison en une table distincte, la règle 4 permet de l’exprimer dans une table

existante, en ajoutant à l’une des deux tables une clé étrangère qui fait référence



à l’autre table dans l’association. Pour mettre en évidence une liaison, il convient

d’ajouter un nom de rôle au nom de la clé d’identification correspondante. Un

nom de rôle rend explicite la signification des valeurs d’une clé spécifique dans

une table étrangère. [Meier 2004]

Règle 5 (liaison de type simplesimple)

Un ensemble de liens simplesimple peut s’exprimer dans les deux tables des

ensembles d’entités participantes sans avoir besoin de créer une table distincte.

Une des clés d’identification de la table référencée est choisie comme clé

étrangère dans la seconde table.

3.2.2 Les tables

employe eNB nom prenom poNB_designation

tache tNB description heures pNB_faitpartie

execution eNB tNB date

projet pNB startdate enddate

code cNB abreviation numero description

correspondant pNB cNB

appartenance pNB eNB



position poNB description

monnaie mNB devise cours

user_admin uNB username password eNB_utilisation

frais fNB description montant eNB_charge mNB_multiplie

Conforme aux règles du passage du modèle entitéassociation au schéma de

base de données relationnelle chaque entité est traduite en une table distincte.

Les ensembles des liens peuvent être traduits en une table distincte. Elle contient

les clés d’identification des ensembles d’entités participantes comme clés

étrangères. Dans la table employé, la désignation de la position est représentée

comme clé étrangère dans la table. La table tâche a une clé d’identification et

une clé étrangère pNB_faitpartie qui relie la table projet. La clé d’identification de

la table exécution est formée par la combinaison des clés étrangères qui relient

aux tables employé et tâche. L’attribut date indique le jour exacte de l’exécution

d’une certaine tâche par l’employé. Les tables correspondant et appartenance

sont formées de même manière avec une combinaison des clés étrangères. La

table user_admin est seulement utilisée pour l’identification et l’enregistrement

des données sensibles comme des mots de passe des employés. Elle a une clé

étrangère qui référence à l’autre table employé dans l’association avec un nom

de rôle (eNB_utilisation) qui rend explicite la signification des valeurs d’une clé

spécifique dans une table étrangère. La table frais a une liaison par clé étrangère

avec des noms du rôle vers les tables dans l’association employé et monnaie.

3.2.3 Les contraintes d’intégrité structurelles

«Le concept d’intégrité signifie l’absence d’incohérence dans une base de

données. Le terme cohérence est aussi utilisé pour se référer à ce concept. Si les



données étaient introduites sans erreur dans une base et qu’elles délivrent les

informations désirées de manière correcte, on dit que la base de données en

question est intègre ou cohérente.» [Meier 2004] On certifie par exemple que la

table employé est cohérente, on admet par là que les noms et prénoms sont

corrects et existent en réalité.

Les contraintes d’intégrité structurelles établissent des règles qui doivent

s’appliquer à un schéma de base de données pour assurer sa cohérence. Ils sont

classées en trois catégories selon [Connolly, Begg, Strachan 1996, p. 538545]

et [Meier 2004, p.51].

La contrainte d’unicité requiert la déclaration d’une clé dans chaque table.

Lorsqu’il existe plusieurs clés candidates dans une même table, la contrainte

d’unicité oblige à en declarer une comme clé primaire (un attribut ou une

combinaison d’attributs).

La contrainte de domain dit qu’un attribut dans une table ne peut prendre que

des valeurs appartenant à un domaine de valeurs prédéfinies. Ce système ne

peut pas garantir le respect totale de cette contrainte. Il incombe aux utilisateurs

de determiner l’étendue exacte des règles pour valider le continue des tables. La

definition d’une contrainte de domaine basée sur les types énumérés est une

technique importante qui consiste à créer une liste de toutes les valeurs

possibles d’un attribut. Cette technique va être une partie important dans

l’implémentation du système de gestion de temps en l’application web en offrant

les choix possibles par des menus dropdown.

Le concepte d’intégrité référentiel introduit une classe importante de règles de

validation des données. Une base de données relationnelle respecte la contrainte

d’intégrité référentielle si, pour toute valeur d’une clé étrangère, il existe une

valeur identique de la clé primaire correspondante.



4 Réalisation et implémentation du Prototype

4.1 Technologies utilisées pour l’implémentation

Ces dernières années, le web a changé substantiellement. Au début c’était un

média pour la diffusion des contenues statiques. Aujourd’hui, la plupart des

contenues web devient généré de manière dynamique par des applications web.

A cause des avantages nets des bases de données, la plupart des applications

sont manœuvrées par une base de données. Le browser web sert à l’interface

utilisateur, la base de données au stockage et comme base d’application qui

représente l’interface entre IU et BD.

Un évènement typique d’une base de données web inclut les pas décrit dans [Fig.

4.1.1.] :

Fig. 4.1.1. : Structure de base d’une base de données web [Wellington, Thomson 2005, p.252]

1. Le browser web d’un utilisateur convie par HTTP une certaine page web.

Par exemple la page fichier.php pour enregistrer le temps du travail. Le

script d’exécution s’appelle input_fichier.php.

2. Le serveur web conçoit la demande pour input_fichier.php, retire le fichier

et transmet celui à la PHPEngine pour l’exploitation.

3. La PHPEngine commence à épuiser le script. Dans le script il y a une

commande qui établie une connexion à la base de données et qui effectue

une requête ou une modification (càd enregistre le temps). PHP

décapsule une connexion avec le serveur MySQL et envoie l’interrogation

correspondante.

4. Le serveur MySQL reçoit l’interrogation de la base de données et rend les

aboutissants à la PHPEngine après avoir traité la requête ou les

modifications des données.

5. La PHPEngine complète l’exécution du script. Pour cela on utilise souvent

des commandes de formatage pour la distribution des résultats qui doit

satisfaire quelques exigences optiques. Le code HTML resultant est livré au

serveur web.



6. Le serveur web retourne le code en HTML au browser. L’utilisateur peut

maintenant considérer les données saisis par les formulaires dans le site

fichier.php.

Ce processus se déroule toujours à quelques détails près de manière similaire –

indépendamment de l’affectation de la ScriptingEngine et du serveur de la base

de données. Pour construire ce prototype, un serveur web est utilisé qui supporte

PHP et MySQL.

PhpMyAdmin, une des applications de premier plan [selon Delisle 2005, p. 24]

est utilisé pour mieux gérer la base de données MySQL. Le traitement de la base

de données est effectué par une interface utilisateur chiadée (cf. Fig. 4.1.1.).

Comme fonctionnalités élémentaires on peut désigner la constitution et

l’extinction des bases de données ainsi que la création, le changement de nom,

la copie et la purge des tables. De plus l’administration de la structure des tables

inclus les indices et des opérations spécifiques comme la réparation,

l’optimisation et le changement du type de la table. Toute la liste des

fonctionnements est imagée dans [Delisle 2005, p. 2930].

4.2 Construction de la base de données

Comme prochaine mesure, la base de données timetrack est constituée à l’aide

de l’outil phpMyAdmin (dans l’annexe vous trouverez des capture d’écran du

cadre d’utilisation graphique). Les différentes tables sont mises en place à partir

du schéma de base de données. Les clés primaires et les types des champs sont

définis. Pour pouvoir établir un schéma relationnelle, phpMyAdmin possède une

fonctionnalité qui permet de gérer les relations entres les tables. Par

conséquence, les clés primaires et les clés étrangères sont attachées comme

présenté dans la Fig. 4.2.1. Pour pouvoir se servir de la fonctionnalité des clés

étrangères et de l’intégrité référentielle, les tables dans la base de données

doivent être constituées selon le type de table InnoDB à la place du type

standard MyISAM. InnoDB est assuré sur les transactions, est plus vite et donne

une extension de la fonction élargie.



employe

PK eNB

nom prenom poNB_designation

user_admin

PK uNB

username password eNB_utilisation

tache

PK tNB

description heures pNB_faitpartie

projet

PK pNB

startdate enddate

code

PK cNB

abreviation numero description

position

PK poNB

description

frais

PK fNB

description montant eNB_charge mNB_multiplie monnaie

PK mNB

devise cours

correspondant

pNB cNB

appartenance

pNB eNB

execution

eNB tNB date

Fig. 4.2.1. : Schéma des relations de la base de données timetrack

4.3 Création de l’interface utilisateur simplifiée

L’interface utilisateur du prototype est composée de plusieurs pages web qui sont

finalement reliées à la base de données par des formulaires (cf. Fig. 4.3.1.). Il

existe une distinction entre un domaine utilisateur et un domaine administrative.

Par le site heures & frais on a accès au fichier de temps et aux frais de gestion

ou on peut remplir ses heures travaillés et les frais utilisés. Le domaine

reportage propose à l’utilisateur quelques requêtes prédéfinies autant que des

interrogations personnalisées qui sont particuliers pour lui ou pour le



département dont il fait partie. Le domaine modifications (AMDIN) sert à ajouter

par des champs prédéfinis des nouveaux employés, des nouveaux projets avec

leurs dates de lancement et de l’échéance comme des nouveaux cours de

change. En plus, le domaine modifications offre la possibilité d’effacer des

données de la base de données.

Fig. 4.3.1. : Structure de l’interface utilisateur simplifiée

A l’encontre d’une solution complète, un prototype vise à proposer et à tester

seulement quelques de ces fonctionnalités. Pour cette raison, toutes les pages

sont connectées à la base de données et vont effectuer des requêtes mais

seulement sur un niveau limité. Les fonctionnalités qui doivent être encore

implémentées dans une version finale sont démontrées dans la partie 5

Evaluation du prototype.



Pour pouvoir montrer le fonctionnement du système, les pages principales

connectées à la base de données, leurs codes et les scripts PHP correspondants

sont présentés plus précisément dans ce qui suit.

De ce qui est présenté dans le sitemap (cf. Fig. 4.3.2.) seul les pages fichier.php

et input_fichier.php sont soumis à une analyse de manière plus précise. La raison

c’est que ce sont les scripts qui représentent l’idée principale du système de

gestion de temps basée web.

index.php

Sitemap http://unifr.matcom.ch

heures & frais

reportage

modifications

fichier.php

frais.php

req_pred.php

employes.php

code.php

cours.php

report_code.php

report_designation.php

report_tousfrais.php

report_monnaie.php

report_toustaches.php

page web

script en PHP

execution par lien execution par formulaire (POST)

req_pers.php

report_datesprojet.php

input_fichier.php

input_frais.php

reppers_employe.php

reppers_frais.php

reppers_fraissearch.php

reppers_mois.php

reppers_projet.php

reppers_term.php

input_employe.php

delete_employe.php

projets.php input_projet.php

input_code.php

delete_code.php

input_cours.php

delete_cours.php

Fig. 4.3.2. : Sitemap du prototype

Pour pouvoir introduire les heures du travail effectuées, on doit accéder à la page

fichier.php. Cette page est constituée de plusieurs champs de texte et de

sélection. La partie d’entête est incluse par une fonction de PHP:



D’abord le formulaire doit être introduit par la partie HTML:

Ensuite on a les différents champs qui sont soit HTML ou PHP:

Selectbox pour afficher les employés

Champ de texte pour introduire la date

Champ de texte pour introduire une description

Champ de texte pour introduire les heures

Selectbox pour afficher les projets



Boutons pour la mainlevée et la transmission

Puis, la partie au fond est incluse par une function de PHP:

Quand l’utilisateur appuye sur le bouton Transmettre!, le script en PHP

input_fichier.php est exécuté de manière comme il est décrit dans la partie 4.1

Technologies utilisées pour l’implémentation.

Script input_fichier.php

Les valeurs inscrites dans les champs auparavant sont transmises par la

méthode POST et sont utilisées pour ajouter les nouvelles valeurs dans les tables

tache et execution de la base de données timetrack.



Les autres scripts sont construits et exécutés de la même manière avec des

différences de l’information transmise par les champs prédéfinis et de

l’affectation des tables de la base de données. Tous les scripts sont mémorisés

sur le cédérom cijoint.



5 Evaluation du prototype

Après avoir réussit l’implémentation du prototype TimeTrack, la prochaine phase

sert à évaluer celuici pour identifier des forces et des faiblesses et de donner

l’opportunité de les incorporer dans une version ultérieure. L’évaluation doit se

porter sur les exigences et les besoins définis par les utilisateurs.

La solution du système de gestion de temps et des frais satisfait les besoins des

utilisateurs qui ont était définis comme suit: Tout utilisateur a un accès sécurisé

à l’interface utilisateur par un navigateur Web de n’importe où dans le monde. Il

a la possibilité de remplir les informations relatives à la gestion de temps et des

frais dans des formulaires prédéfinies. De plus on a un bond en avant en ce qui

concerne le système des requêtes et de la collection des données de tous les

employés. Des analyses profondes peuvent être effectuées par l’interface

utilisateur du système. Déjà le prototype rend possible à l’utilisateur sans

connaissances des langages d’interrogation et de manipulation de données

d’effectuer des requêtes et des insertions de nouvelles données.

Néanmoins il existe encore plusieurs composants qui ont le potentiel

d’amélioration et qui doivent être développés à partir du prototype.

Premièrement, le design de l’interface utilisateur doit être amélioré et encore

plus de fonctionnalités doivent être implémentées. Ces deux aspects rendent à

une meilleure utilisation par les employés. Deuxièmement, l’identification des

utilisateurs et la mise à disposition des sections privées pour les employés sont

des fonctions indispensables dans une version finale qui en plus augmenteront la

sécurité du système. Avec cette identification les employés autorisés peuvent

avoir accès à une section administrative où ils ont la possibilité d’ajouter des

nouveaux projets, employés et cours de change. Troisièmement, les reports des

heures de travail comme les frais de gestion doivent être préparé dans un format

qui soutient l’imprimé. Une autre possibilité serait la création de fichier en PDF

qui pourrait être fait par un script en PHP. Finalement, au niveau de la

programmation en PHP, des indications d’erreurs doivent être personnalisées et

l’insertion des champs des formulaires devrait être vérifié avant de les

transmettre vers la base de données.



6 Conclusion et perspectives

L’expansion du Web dans tous les secteurs des entreprises a donné naissance au

développement de nouveaux outils: les systèmes de gestion de temps basée

web.

Le développement d’un nouveau système pour l’enregistrement du temps et des

frais de gestion en collaboration avec l’entreprise conseil en gestion management

ZIEL Consulting AG était un travail captivant et instructif. Particulièrement

l’analyse de l’état actuel comme la définition des exigences ont montré l’aspect

pratique dans le travail de séminaire. La programmation de la base de données

et des scriptes en PHP était très satisfaisante parce que principalement le

langage PHP était adopté seulement par des livres et sans appui externe.

La cognition principale est que malgré toutes les fonctions dans le prototype et

les connaissances acquises par ce travail, la complexité de la matière rend

nécessaire encore plusieurs rajustements et degrés de développement avant de

l’implémentation d’une version qui serait applicable par une entreprise. Pour

cette raison il est vraisemblable qu’on va implémenter un système de gestion de

temps déjà existant sur le marché des logiciels gestion de projet et de temps

dans l’entreprise ZIEL Consulting.

De toute façon, les résultats et connaissances gagnés par le développement de

ce travail de séminaire vont être utile dans le cas d’une implémentation d’un

autre système par ZIEL Consulting AG ou du moins par la compréhension d’avoir

acquis des nouveaux moyens personnels.



7 Bibliographie

[Meier 2004] Andreas Meier: Relationale Datenbanken, Leitfaden für die

Praxis, 5. Auflage, SpringerVerlag Berlin Heidelberg 2004.

[Connolly, Begg, Strachan 1996] Thomas Connolly, Carolyn Begg, Anne

Strachan: Database Systems – A practical approach to design,

implementation and management, 2 nd edition, AddisonWesley

Publishing Company Inc., England 1996.

[Elmasri, Navathe 2000] Ramez Elmasri, Shamkant B. Navathe: Fundamentals of

Database Systems, 3 rd edition, Pearson Education

International, 2000.

[Wellington, Thomson 2005] Luke Wellington, Laura Thomson: PHP 5 & MySQL

5, 3 rd edition, Pearson Education Inc., 2004 (German language

edition published by Markt + Technik Verlag, München 2005)

[Delisle 2005] Marc Delisle: phpMyAdmin – open source library, Addison

Wesley Verlag, 2005.

[Jenny 1997] Bruno Jenny: Projektmanagement in der

Wirtschaftsinformatik, 2. Auflage, vdf Hochschulverlag, Zürich

1997.

[Date 1995] C. J. Date: An introduction to database systems, 6 th edition,

AddisonWesley Publishing Company Inc., US 1995

[Date, Darwen 1998] Chris J. Date, Hugh Darwen: SQL – Der Standard, 1.

Auflage, Addison Wesley Longman GmbH, Bonn 1998

[Shneiderman 1997] Ben Shneiderman: Designing the user interface: strategies

for effective humancomputer interaction, 3 rd edition, Addison

Wesley Publishing Company Inc.,

[Huesemann 2005] Stefan Hüsemann:Systèmes d’information de l’entreprise,

dans: Cours Systèmes d’information I, Université de Fribourg



8 Annexe

8.1 Résultat de l’enquête dans l’entreprise ZIEL Consulting AG (extraits)

Visualisation du problème de la gestion de temps

Opportunités et dépenses



Résultats après clarification

8.2 Captures d’écran de phpMyAdmin

base de données timetrack avec ses

tables

champ pour créer une nouvelle table

Vue générale sur les tables de la base de données



champ pour choisir le type de la table

miette de pain (breadcrumbs)

Formularie pour définir les champs de la table

Introduction des propriétés dans la nouvelle table

champ pour exécuter des requêtes SQL

informations sur les clés primaires

et les clés étrangères informations générales

sur l‘état de la table

Vue de la structure et des informations complémentaires d’une table définit



l‘utilisateur peut insérer des nouvelles valeurs dans les champs prédéfinits (pas

de valeur pour la clé primaire parceque ce

champ est autoincrément)

Propriétés des valeurs dans la

table

Insertion de nouvelles valeurs dans la table

affichage de la requête effectuée en SQL

affichage de la table avec les valeurs dedans

Vue des valeurs d’une table qui est le résultat d’une requête

Documents

La gestion de temps de l’entreprise - diuf.unifr.chdiuf.unifr.ch/is/userfiles/file/studentprojects/S-2006_Matthias... · La gestion de temps de l’entreprise – conception d’une