Section 3 : ETUDE TECHNIQUE
2.3.1 Introduction
L'étude technique nous permet de concrétiser ou
de mettre en place physiquement la structure de notre application.
2.3.2 Besoins des utilisateurs
Les besoins des utilisateurs sont les états en sorties
qui permettent l'impression des enregistrements selon une représentation
définie préalablement.
Les états que nous disposons pour notre application
sont les suivant :
· Liste des clients enregistres
· Liste des occupations des chambres effectuées
· Situation d'une occupation
2.3.3 Choix du SGBD à utiliser
Un SGBD représente un ensemble de logiciel qui permet
de décrire, manipulé, traiter les ensembles des données
formant la base. Il doit également assurer la sécurité et
la confidentialité des données dans un environnement où de
nombreux utilisateurs ayant des besoins varié peuvent interagir
simultanément sur ces données.
Toutefois il existe actuellement plusieurs types de SGBD. Nous
portons le choix sur Hyper File SQL Client/serveur qui est système de
gestion de base de données fourni avec WinDev utilisant les fichiers au
format WinDev à l'extension de fichier « .ana »
2.3.4 Passage du MOD au MLD
Le passage du MOD au MLD brut doit respecter les règles
suivantes :
· Les objets deviennent des entités dans le sens
mathématique du terme ; donc les lignes aux colonnes sous forme de
table ;
· Les propriétés des objets deviennent des
attributs des tables ;
· Les identifiants des entités deviennent des
clés primaires ;
Les relations dans le sens conceptuel ou sémantique
subissent plusieurs traitements selon le cas notamment :
· La relation du type père et fils
disparaît, mais la sémantique sera maintenue.
· Comme la table fils dépend de la table
père, elle va recevoir la clé de son père et cette
dernière (clé) sera migrée dans la table fils comme
clé étrangère.
· Pour la relation du type autre que père et
fils ; cette relation devient la table et ses attributs seront la
concaténation des clés de deux autres tables. Si la relation
portait une propriété, celle-ci demeurera dans la table comme
attribut
2.3.5 Présentation du modèle logique de
données
2.3.6 Normalisation du MLD
L'opération de la normalisation consiste à
supprimer les redondances qui peuvent encore se trouver dans le MLD brut. Cela
veut dire qu'au niveau de l'étape conceptuelle, nous n'avons pas tenu
compte des règles de vérification des objets pour que leurs
propriétés ne soient pas répétitivité.
Cette opération de la normalisation nous octroie trois
formes normales à respecter afin de pouvoir valider notre MLD
Première forme normal
Une table est, en première forme, normale, si tous ses
attributs sont élémentaires, c'est-à-dire non
décomposables, non répétitifs, et qu'elle porte une
clé primaire ou concaténée.
Deuxième forme normale
Une table est, en deuxième forme, normale, si
étant déjà en première forme normale, et ses
attributs dépendent pleinement de la clé primaire de cette
table.
Troisième forme normale
Une table est, en troisième forme, normale, si
étant déjà en deuxième forme normale, les attributs
qu'elle porte ont une dépendance fonctionnelle directe avec la
clé sans passer transitivement à un autre attribut non
clé. Il faut s'assurer aussi qu'il n y a pas de tables qui soient
cachées parmi les autres.
2.3.7 Présentation du MLD valide
2.3.8 Schémas logiques associés au MLD
validé
Agent : {#Matrag : texte [6],
nomag : texte [15], postnag : texte [15], Sexag :
texte [1], Fonctag : texte [20], adreag : texte [30],
contactag : texte [12]}
Client :{#numcli : texte [6],
nomcli : texte [15], pstn&Prencli : texte [30], sexcli :
texte [1], lieunais : texte [20], Datenais : date [8], Etatciv :
texte [20], adrescli : texte [30],#codnation : texte
[20],Profes : texte [20], nutelecli : texte [12], natupiec :
texte [15], lieu&datem : texte [15], numpiec : texte [18],
accomp : texte [10], lieudvien : texte [20], datearri : date
[8], datedep : date [8], butvoy : texte [10],#matrag : texte
[6], codcham : texte [6]}
Chambre :{#numcha : texte [20],
desigcha : texte [30], prix :monaie [10], #codcateg : texte
[20]}
Occuopation :{datarr :date [8],
heurarr : h[4], heurdep :h [4], datdep : date[8],
motifdepla :texte [20], #matrag : texte [6], #numcli : texte[6],
#numcha :texte[20]}
Categorie :{#codcateg :texte[6],libcateg :
texte[30]}
01 Consulte le plan d'hôtel
OK KO
02 Enregistrement dans bulletin d'inscription
OK KO
03 Établissement de facture
OK KO
04 Établissement rapport journalière
OK KO
05 Vérification rapport journalière
OK KO
06 Signature de rapport journalière
Toujours
07 Classement Rapport Journalière
Toujours
Archivée
RJ validé
ET
Réception RJ
ET
RJ vérifié
RJ non signe
ET
RJ établir
Réception RJ
ET
FA établir
Fin journée
FA non établir
ET
Bulletin établir
Réception
Bulletin nonétablir
ET
Plan validé
Plan non validé
Accueil
2.3.9 Élaboration du modèle organisationnel
de traitement
|
Déroulement
|
Procédure fonctionnelle
|
NATURE
|
POSTE
|
|
8H à16h00
8H00à16h
15h00 à 22h
8hoo à 15h
15h00 à 19h
8h30 à 15h
|
|
TM
TA
TA
TA
TR
TM
TR
|
Réception
Réception
Caisse
Réception
D d'explo
DAF
AG
|
| 
