CHAPITRE 5 : BASE DE DONNEES
Dans le chapitre précédent nous avons fait une
analyse minutieuse du cahier des charges. Cette analyse nous a permis d'obtenir
le Modèle Conceptuel de Données de la méthode
Merise. Maintenant nous allons nous référer
à ce modèle pour obtenir notre base de données.
5.1 MODELE LOGIQUE DE DONNEES
Pour obtenir notre MLD, nous appliquons les règles de
normalisation énoncées dans le CHAPITRE 3. Ces
règles nous permettent de traduire notre MCD en MLD que nous pouvons
voir sur le schéma suivant :
Figure 24 : Modèle Logique de Données du
GED.
Nous pouvons remarquer que les entités sont devenues
des tables. Les associations de type 1 : n ont disparu au profit d'une
clé étrangère dans la table qui se trouve du
côté où la cardinalité maximale de l'association
était n. De plus, les associations de types n : m sont devenues des
tables de jonctions auxquelles nous avons ajouté quelques attributs
utiles pour le backend.
Page 33 sur 57
5.2 MODELE PHYSIQUE DE DONNEES (SCHEMA DE LA BASE DE
DONNEES)
Après réalisation du MLD, nous
définissons le type de chaque propriété afin d'aboutir
à une base de données fiable qui nous permettra de sauvegarder
nos données en toute intégrité. Ainsi, nous obtenons le
modèle Physique de données ci-dessous :
Figure 26 : Structure de la base de données.
A ce stade nous avons la structure de notre base de
données qui résulte de l'implémentation du code SQL sur la
console de maria dB du logiciel WampServer.
Page 34 sur 57
Page 35 sur 57
CHAPITRE 6 ARCHITECTURE DU PROJET
Pour l'implémentation de notre backend, nous avons
utilisé l'architecture MVC expliquée au CHAPITRE
2. Nous suivrons une logique MVC plutôt personnalisée en
limitant au maximum de s'encombrer avec des fichiers inutiles au regard de la
taille de notre projet. Voyons de près l'arborescence de notre
application web sur le serveur :
1
2
3
4
5
6
7
8
9
10
Figure 26 : Arborescence de notre application
11
En « 1 », nous avons la racine de notre serveur.
Chaque fichier ou dossier qu'elle contient joue un rôle bien
spécifique qui contribue au bon fonctionnement de notre système.
Déclinons le rôle de chacun.
6.1 FICHIER « INDEX.PHP »
Figure 27 : Fichier index.php
Page 36 sur 57
C'est le fichier d'entrée de notre application,
c'est-à-dire, lorsqu'un qu'un ordinateur client émet un
requête http pour avoir accès à notre application, c'est ce
fichier que le serveur renvoie comme réponse. Ce fichier spécifie
le contenu de notre page d'accueil, c'est-à-dire le
texte, les images, les icônes
ainsi que tout élément visible dans la fenêtre du
navigateur lorsqu'un visiteur accède au site via l'URL. Le fait que ce
soit un fichier PHP lui confère la possibilité d'écrire de
la logique pour inclure dynamiquement : les pages au niveau de la vue
(ligne 8) et les fichiers de configuration indispensables
(lignes 3, 6 et 10). De plus, c'est dans ce fichier que l'on
démarre la session qui permet de conserver les informations des
utilisateurs de page en page lorsqu'ils sont authentifiés (ligne
2).
6.2 FICHIER « .HTACCESS »
Serveur
Apache
Figure 28 : Fichier de configuration .HTACCESS
.HTACCESS permet d'ajouter une couche de
sécurité supplémentaire à la configuration de notre
application web.
Dans le script de la figure, nous sécurisons notre
application web contre : l'accès aux dossiers sensibles
situés à la racine du serveur depuis le navigateur ou origine
inconnue. Ce script est important en ce sens qu'il empêche
quiconque d'avoir accès à l'arborescence de notre serveur.
Page 37 sur 57
6.3 FICHIER « SETTING.PHP »
Figure 29 : Code source du fichier de configuration de
l'application
Le fichier setting.php est le fichier de
configuration de notre application. Il permet de :
définir l'encodage des caractères (à la
ligne 3) ;
d'instancier l'objet PDO (à la ligne 4) afin
d'établir la connexion à la base de données en renseignant
: le SGBD « mysql », l'url de l'hôte
du serveur de base de données (bdd) « localhost
», le nom de la bdd « numerixgab
», l'encodage de caractère « utf8mb4
», le nom d'utilisateur « root » et le mot de
passe qui est ici une chaine de caractère vide vu que
nous sommes en mode développement en local. Ces
paramètres changeront naturellement lors du déploiement de notre
application ;
d'inclure le fichier permettant de faire de l'autoloading
c'est-à-dire le chargement dynamique des classes php.
6.4 FICHIER « PACKAGE-LOCK.JSON »
Le fichier package-lock.json permet de
stocker la structure de l'arborescence de dépendances à chaque
installation. Il est généré automatiquement lors de la
modification du fichier package.json ou dans l'architecture du
dossier node_module.
6.5 FICHIER « NUMERIXGAB.SQL »
Ce fichier contient le code source de notre base de
données à vide. Il ne joue pas de rôle particulier dans
l'arborescence mais permet néanmoins de sauvegarder la structure de
notre base de données.
6.6 MODELE « MODEL/ »
Figure 31 : Contenu du Modèle
Le modèle constitue l'ensemble de fichier qui
communique avec la base de données. Il est constitué
exclusivement de classes. Ces classes sont étroitement liées aux
tables de notre base de données.
Figure 32 : Illustration de la similitude entre la classe
Types.class.php et la table types
Ainsi, à chaque table de notre base de données
est associée deux classes du modèle ayant des rôles
distincts :
Une classe, portant le même nom que la table, contenant
des propriétés identiques aux attributs de la table (voir la
figure précédente). Chaque propriété comporte le
même type que l'attribut de la table à laquelle il correspond. Ces
attributs sont
Page 38 sur 57
Page 39 sur 57
déclarés en « private » pour
respecter les règles d'encapsulation. De fait, nous avons défini
des méthodes « getters » et « setters » pour obtenir
ou modifier les propriétés des objets découlant de cette
classe. De plus, nous y avons défini un constructeur qui hydratera
(définir des valeurs initiales aux attributs de la classe) notre classe
automatiquement lors de son instanciation.
une classe ayant pour radicale le nom de la table et pour
préfixe le mot Manager. Exemple : «
TypesManager.class.php ».
Cette classe permet d'effectuer des requêtes SQL vers la
base de données. Elle communique avec la base de données pour
permettre à notre code source d'écrire, de lire, de modifier ou
de supprimer une ou plusieurs données dans la table correspondant au
radical.
Figure 32 : Illustration de la liaison entre la classe
TypesManager.class.php et la base de données
6.7 VUES « VIEW/ »
C'est l'ensemble des fichiers qui contribuent à
l'affichage des interfaces de l'application sur l'écran de
l'utilisateur.
Figure 33 : Dossier contenant les vues
Le fichier « index_view.php »
: fichier des vues permettant de charger le Controller
responsable du chargement dynamique des vues.
Figure 34 : Illustration source d'inclusion des vues
Le dossier « footer / » : il
contient le fichier « footer.php ». Ce fichier contient le code html
permettant d'afficher le pied de la page.
Figure 35 : Illustration du dossier du pied de page et de son
code source
Le dossier « nav /» : il
contient les fichiers contenant le code HTML de navigation de l'application
web.
Figure 36 : Illustration du dossier contenant les fichiers du
code source de navigation
Nous pouvons visualiser deux fichiers qui sont :
o « nav.php » : navigation
lorsque l'utilisateur n'est pas authentifié.
o « nav_inside.php » :
navigation lorsque l'utilisateur est authentifié.
Le dossier « main /» :
contient les dossiers et fichiers responsable de l'affichage du corps de
l'application.
Page 40 sur 57
Page 41 sur 57
Figure 37 : Contenu du dossier main contenant toutes les vues
du corps de l'application
Détaillons ces éléments :
o « document/ » : dossier
contenant le fichier « document.php » où est écrit le
code html de l'interface « ajout de documents » ;
Figure 38 : Vue de l'interface document
o « dossier/ » : contient le
fichier « dossier.php » dans lequel est écrit le code html de
l'interface « ajout de dossiers » ;
Figure 39 : Vue de l'interface dossier
o « employer/ » : contient
le fichier « employer.php » dans lequel est écrit le code html
de l'interface « ajout d'employers» ;
Figure 40 : Vue de l'interface gestion des
employés
o « message/ » : contient le
fichier « message.php » dans lequel est écrit le code html de
l'interface « mini forum» ;
Figure 41 : Vue de l'interface du forum
o « rubrique/ » : contient
les fichiers responsables de l'affichage des interfaces d'exploration de la
banque documentaire. Nous avons successivement : ? «
documentList.php » : affiche la liste des documents contenus dans un
dossier ;
Page 42 sur 57
? « dossierList.php » : affiche la liste
des dossiers contenus dans une rubrique ;
? « rubrique.php » : affiche la liste des
rubriques d'une structure spécifique ;
? « script_pdf.php » : script php
permettant de charger dynamiquement la dépendance javascript permettant
d'afficher les documents PDF.
Figure 42 : Contenu du fichier script_pdf.php
o Le fichier « form_connect.php
» : formulaire de connexion à la session utilisateur
;
o Le fichier « main.php »
: corps du site lorsque l'utilisateur ne s'est pas encore connecté ;
o Le fichier « main_check.php
» : l'interface du choix du portail après
l'authentification ;
o Le fichier « main_inside.php
» : l'interface du choix du service (ajouter dossier,
ajouter document, ajouter rubrique) après authentification.
6.8 CONTROLEURS « CONTROLLER /»
Ce dossier contient les fichiers qui sont appelés
contrôleurs. Ces fichiers assurent la logique métier de notre
application :
Figure 43 : Contenu du dossier controller
gère l'affichage dynamique des vues sur l'interface de
l'utilisateur en fonction du choix de navigation ;
gère le traitement des requêtes asynchrones
(AJAX) provenant du javascript ; transmet les données provenant du
Modèle à la Vue.
Dans le souci de préservation des
données à caractères personnels, nous ne
détaillerons pas ce dossier afin de garantir la sécurité
du système.
6.9 VERSIONNAGE AVEC GIT
A la racine de notre application, nous pouvons voir un dossier
caché nommé « .git ».
Page 43 sur 57
Figure 44 : Racine de notre application web
Ce dossier contient les sauvegardes des différentes
versions de notre projet.
Nous avons utilisé le versionnage GIT afin
d'éviter des actions irréversibles lors du développement
de notre solution.
Figure 45 : Console du gestionnaire de versionnage
GIT
Observons sur le terminal représenté à la
figure de la page suivante les différentes versions de notre projet.
Page 44 sur 57
Figure 46 : Résultat de la commande "git status"
permettant d'avoir un listing des différentes versions de
l'application
Page 45 sur 57
| 
