Application du processus de fouille de données d'usage du web sur les fichiers logs du site cubba

CHAPITRE 4

Prétraitement de fichiers log

du site CUBBA

1. Étude de cas

1.1. Analyse du site Web académique

Dans cette étude de cas sur des données réelles, nous analysons les fichiers log du site Web de notre Centre universitaire de Bordj Bou Arréridj³. La figure exhibe un aperçu de la page de garde du site en question.

FIG 4.1. Aperçu de la page de garde du site Web de Centre Universitaire de Bordj Bou Arrerridj.

1.2. Préparation des données

En collaboration avec les responsables du centre de calcul, nous avons pu obtenir un jeu de données qui enregistre l'accès au site pendant la période du 14 février 2010 jusqu'au 17 mars 2010. Les différents fichiers log du format ECLF sont concaténés en un seul fichier qui a constitué notre source de données. Le tableau suivant indique la taille des différents fichiers log récupérés sur la période étudiée.

3 Le site analysé est accessible à l'adresse suivante : http://www.univ-bba.dz

Période Taille
14 mars .17mars	1698 ko
07mars 14mars	4276 ko
28fev 07mars	2537 ko
21fev 28fev	1873 ko
14 fev 21 fev	3955 ko
Total	14339 ko

TAB 4.1. La taille des fichiers log analysés.

2. Implémentation

2.1. Chargement du fichier Log et transformation en une table d'une BDD

Le fichier LOG est un fichier texte, appelé aussi journal des connexions. Généralement il est de la forme suivante :

Le fichier Log se transforme en une table composée de plusieurs colonnes. Chaque colonne correspond à un champ spécifique du fichier Log :

FIG 4.3. Base de données après import.

2.2. Présentation de l'application de prétraitement

Notre application est une petite démonstration aux différentes étapes de prétraitement, c'est pour ça on n'a pas besoin de réalisé une interface ergonomique, mais on a mené à réaliser une interface plus au moins au professionnel.

a. Nettoyage des données

Une fois les fichiers log importés dans les espaces de stockage, les données concernant les pages possédants des requêtes non valides, des images ou de fenêtre publicitaire ...etc ; n'apportent rien à l'analyse. Elles seront donc filtrées et éliminées.

Pour cela on est amené à supprimer de notre base de données les requêtes qui ont les formes suivantes :

+ Les requêtes correspondant aux statuts non valides par la requête

("delete from LOGUNIV where statut<=200 ou statut>399 »)

+ Les requêtes correspondant aux méthodes différentes de get' par la requête

("delete from LOGUNIV where methode < >`get' »)

+ Les requêtes correspondant aux fenêtres publicitaires par la requête

("delete from LOGUNIV where url like %popus%')

L'étape qui concerne les pages provenant des robots web nécessite l'établissement d'une liste des adresses IP⁴ (4187 adresses collectées) et une liste d'UserAgent⁵ (966 User- Agents collectés). Les requêtes provenant d'une des adresses IP ou d'un des User-Agents présents dans les deux listes sont supprimées.

b. Transformation des données

La transformation des données est une tache fastidieuse car elle représente véritablement le visiteur. Notre analyse est entièrement ne tient pas compte du fait que plusieurs requêtes peuvent provenir d'un même utilisateur. Ceci réduit les problèmes liés aux caches Web (Proxy), aux adresses IP dynamiques et au partage d'ordinateurs.

+ L'identification des sessions d'utilisateurs

Après le nettoyage des données et l'application de l'algorithme d'identification des sessions d'utilisateurs « FIG 4.5 » on a obtenue 744 sessions. La figure ci dessous présente un aperçu de sessions obtenues.

4

5

FIG 4.5. L'identification des sessions. + L'identification des visites

Après la création des sessions et l'application de l'algorithme d'identification des visites ci-dessous, nous obtenons 1826 visites d'après la base totale.

> Algorithme d'identification des visites d'utilisateur

En premier temps on doit collecter des informations sur l'identification des visites d'utilisateurs. Soit les variables suivantes :

v' Ri= Requête i

v' V [Ri] = Visite à laquelle appartient la requête i v' S [Ri] = Session à laquelle appartient la requête i v' T [Ri] = Temps de déclenchement de la requête i. v' Durée [Ri] =Durée de la requête i.

v' Durée = Somme des durées de requêtes de chaque visite. v' NV = Nombre de requêtes dans chaque visite.

1. Ordonner les requêtes suivant la variable S [Ri].

2. Détermination de la durée de chaque requête.

3. Construction des visites.

4. Détermination de I a durée de I a dernière requête de chaque visite.

FIG 4.6 Algorithme d'identification des visites d'utilisateur.

FIG 4.7. L'identification des visites.

c. Base de données final

Notre base de données qui constitue de 1826 requêtes est prête pour l'application de différentes méthodes de fouille des données. La figure suivante montre la base de données finale après l'étape de prétraitement.

FIG 4.8. Résultat final de prétraitement.