Indexation de données pour l’archéologie đánh chỉ mục dữ liệu cho khảo cổ học luận văn ths truyền dữ liệu và mạng máy tính chương trình đào tạo thí điểm

UNIVERSITE NATIONALE DU VIETNAM, HANOI INSTITUT FRANCOPHONE INTERNATIONAL HOÀNG YẾN INDEXATION DE DONNÉES POUR L´ARCHÉOLOGIE ĐÁNH CHỈ MỤC DỮ LIỆU CHO KHẢO CỔ HỌC MÉMOIRE DE FIN D’ÉTUDES DU MASTER INFORMATIQUE HANOI – 2016 UNIVERSITE NATIONALE DU VIETNAM, HANOI INSTITUT FRANCOPHONE INTERNATIONAL HOÀNG YẾN INDEXATION DE DONNÉES POUR L´ARCHÉOLOGIE ĐÁNH CHỈ MỤC DỮ LIỆU CHO KHẢO CỔ HỌC Spécialité: Réseaux et Systèmes Communicants (RSC) Code: Programme pilot HANOI - 2016 ATTESTATION SUR L’HONNEUR J’atteste sur l’honneur que ce mémoire a été réalisé par moi-même et que les données et les résultats qui y sont présentés sont exacts et n’ont jamais été publiés ailleurs La source des informations citées dans ce mémoire a été bien précisée LỜI CAM ĐOAN Tôi cam đoan cơng trình nghiên cứu riêng tơi Các số liệu, kết nêu luận văn trung thực chưa công bố cơng trình khác Các thơng tin trích dẫn Luận văn rõ nguồn gốc Fait Hanoi, le 25 octobre 2016 Hà Nội, Ngày 25 tháng 10 năm 2016 HOÀNG Yến Sommaire Remerciements ii Résumé iii Abstract iv Liste des abréviations v Chapitre Introduction Générale 1.1 Introduction 1.2 Contexte et Cadre d’étude 1.3 Problématique 1.4 Objectifs de stage Chapitre Données d’archéologie 2.1 Système informatique en archéologie 2.2 Terminologies en archéologie 2.3 Le type de données 2.4 Données géométriques 2.5 Base de données d’un système informatique de l'archéologie 2.6 Conclusion Chapitre Indexation de données 3.1 Stockage des données 3.2 Indexation de données 11 3.3 Organisation des index 13 3.3.1 Index bitmap (Index brut) 13 3.3.2 Index primaire (trié ou linéaire) 14 3.3.3 Index Hachage 15 3.3.4 Index B-Trees (Index hiérarchisés) 15 3.3.4.1 3.4 Index B+Trees 17 Index de document 18 3.4.1 Index inversé 19 3.4.2 Prétraitement Document 20 3.5 Indexation spatial et R-Trees 21 3.6 Conclusion 23 Chapitre 25 Proposition de modèle 25 4.1 Outils de projet 25 4.2 Architecture de fonctions 26 4.3 Relation de données dans la base de données 27 Chapitre 29 Implémentation, Analyse 29 5.1 Technologies 29 5.2 Sécurité des données 29 5.3 Représentation de données 29 5.4 Recherche par les champs 32 5.5 Recherche plein-textes 32 5.6 Index inversé de la recherche plein-texte (FTS) 33 5.7 Indexation implicite 36 5.8 Indexation de fichier 37 5.9 Accès et indexation du type données géométriques 40 5.10 Organisation des Hyperliens 41 5.11 Indexation des données de fichier PDF 44 Chapitre 48 Expérimentation d’indexation 48 6.1 Implémentation l’index dans le SQLite 48 6.2 Indexation sur une petite table 48 6.3 Indexation sur une grande table 50 6.4 B-Trees dans SQLite 53 Conclusion et perspectives 58 Conclusion 58 Perspectives et limitations 59 Référence 60 Remerciements Je tiens remercier toutes les personnes qui ont participé la réussite de mon stage, l’équipe pédagogique de L'Institut Francophone International (IFI), l’Université Nationale du Vietnam Hanoi, monsieur Nguyễn Hồng Quang et monsieur Hồ Tường Vinh Je voudrais remercier le professeur Nguyễn Quý Đạo qui m'a beaucoup aidé dans ma recherche de stage Je voudrais remercier monsieur Marc Daniel, professeur, LSIS UMR 7296 qui m'a beaucoup aidé obtenir le visa franỗais, m'a permis de postuler et ma donnộ loccasion de faire le stage en France Je tiens remercier monsieur Romain Raffin, mtre de Conférences Informatique, LSIS UMR 7296 qui, en tant que tuteur, m’a encadrée et s'est toujours montré l'écoute et très disponible tout au long de la réalisation de ce projet Grâce aussi sa confiance, j'ai pu accomplir mes missions Enfin, je souhaiterais remercier toutes les personnes : ma famille, mes amis de l’IUT IFI qui m'ont toujours soutenu et encouragé au cours de la réalisation de ce mémoire ii Résumé Les données dans l’archéologie sont généralement trop volumineuses en mémoire Le problème est d’accéder aux données, de trouver rapidement des données liées une application client / serveur d'archéologie L'architecture client-serveur est une solution bien connue pour l'accès de plusieurs utilisateurs un seul serveur Il nous permet de travailler en ligne Aujourd'hui, nous pouvons afficher des documents, des artefacts, des statues ou marcher dans un ancien bâtiment avec la combinaison du modèle client/serveur et des données dans un système informatique d’archéologie Dans ce document, nous étudions l'indexation des données d'archéologie Le but de l’indexation est l’organisation des données pour l’accès rapide aux objets en réduisant l’espace de recherche Des données d'archéologie sont des images, des documents, des maillages en trois-dimensions 3D et sont sauvegardées sur la base de données ou dans un dossier sur un serveur Nous avons fait une étude théorique et pratique sur la méthode d’indexation de données où nous allons nous concentrer sur l’index hiérarchique, l’index B-trees et l’indexation de recherche plein-texte (FTS) Les données ont été recherchées par le soutien du réseau En plus, nous étudions également l'organisation et l’indexation de données hors ligne par PDF dans le côté du client Mots-clés : stockage des données, indexation des données pour l'archéologie, maillage 3D, modèle client-serveur, B-trees index, R-trees index, recherche plein-texte, 3D en archéologie, données géométriques, SQLite, NodeJS iii Abstract The data in archeology generally occupies a large space in memory The problem is how to access data quickly to find data in a model client / server The client-server architecture is a well-known solution for the access of multiple users to a single server It allows us to work online Today, we can see documents, artifacts, statues or walking in an old building with the combination of the client / server model and data in an informatics system of archaeology In this paper, we study about indexing for archaeological data The goal of indexing is accessing quickly to objects by reducing space of searching Archaeological data are images, documents, three-dimensional objects 3D, and keywords that are stored on a folder or database of sever We did a theoretical and practical study on the data indexing method where we will concentrate on the hierarchical index, the B-trees index, and the full-text search indexing (FTS) Data are searched by the support of network In addition, we also studied the organization and indexing offline par PDF in the client side Keywords : data storage, indexing data for archeology, 3D mesh, client-server model, full text search, index B-trees, R-trees index, 3D archeology, geometrical data, SQLite, NodeJS iv Liste des abréviations 2D Two Dimensional 3D Three Dimensional API Application Programming Interface B-trees balanced tree CSV Comma Separated Values format (Data file) DB Data base Doc Document FTS Full text search Id Identification HTML HyperText Markup Language Node.js Node JavaScript JADE Java Agent Development Environment JSON Javascript Object Notation ODT OpenOffice OS Operator System PDF Portable Document Format SQLite Sqlite Database File R-trees rectangle tree SQL Structured Query Language WKT Well-Known Text v Chapitre Introduction Générale 1.1 Introduction Nous allons montrer une partie du projet Eloquenzior réalisé dans mon stage dans ce document Le stage a contribuée au projet d’archéologie Eloquenzior sur les interfaces, la fonction d’affichage, management, la recherche et l’organisation des données d’archéologie sur les nouvelles techniques de developpement Web, Express, Jade, Node.Js, Sqlite…Dans ce mémoire, nous allons montrer les méthodes d’indexation de données, la recherche par l’index inversé pour la fonction de la recherche plein-texte et l’affichage et l'organisation des données textuelle, des documents, des images, des objets 3D, également l’indexation de données hors ligne par PDF dans le côté du client Tout au long de ce mémoire, nous organisons ce rapport en six sections Dans le chapitre 1, nous allons représenter l’introduction générale, le contexte, le problématique, l’objectif de stage Après, dans le chapitre 2, nous allons introduire les concepts de l’archéologie et des données archéologiques Dans le chapitre 3, nous allons montrer le stockage des données, les concepts et la méthode d’indexation de données Suite, nous allons présenter la proposition du modèle dans le chapitre Dans le chapitre 5, l’implémentation de l’application, les outils utilisés serons démontrés Dans le chapitre 6, nous allons faire l’expérimentation d’indexation, l’analyse et l’évaluation des méthodes également Enfin, nous allons conclure le rapport et montrer des perspectives 1.2 Contexte et Cadre d’étude Le stage est effectué dans le cadre du projet Eloquenzior (projet AMIDEX d'Aix-Marseille Université) de LSIS UMR 7296 (Laboratoire des Sciences de l’Information et des Système Marseille, France) Eloquenzior est un projet du patrimoine numérique Le projet est dans un projet plus large d’analyse du décor sculpté du site de Delphes en Grèce Le projet est axé sur l'étude de deux anciens monuments pour leur importance historique : la Tholos Delphes (Grèce), le Temple Attis Zama Regia (Tunisie) Le partenaire du projet est le Centre Camille Jullian (Histoire et archéologie de la Méditerranée et de l'Afrique du Nord, de la protohistoire la fin de l'Antiquité, UMR 7299 - AMU / CNRS / k = nombre de l'ordre de ligne, dans notre projet, on calcule k = n-37+2 (37 est nombre du page de démarrage, est nombre de ligne pour le mot « Sommaire ») n: nombre de page affiché sur le sommaire Le résultat de découpage d’index comme la figure suivante : n Figure 5.11f – Structure du découpage du page sommaire par la fonction de hachage 47 Chapitre Expérimentation d’indexation 6.1 Implémentation l’index dans le SQLite Dans cette partie, on va analyser des index dans SQLite La commande EXPLAIN QUERY PLAN est utilisée pour obtenir une description de la stratégie d’une requête SQL En plus, elle rapporte sur la manière dont la requête utilise des indices de base de données Regardons une expérimentation sur l’index où nous allons créer un index sur les tables « artefact» et «users» Pour l’affichage le temps de requête de l’exemple, on utilise la commande « timer on » L’unité du temps est la seconde: sqlite> timer on Afficher des index dans SQLite Pour l’affichage des index d’une table « tableName» on utilise : sqlite> indices tableName L’affichage des index de la base de données : vous pouvez lister toutes les index dans la base de données comme suit: sqlite> SELECT * FROM sqlite_master WHERE type = 'index'; Suppression des index Un index peut être supprimé par la commande DROP La syntaxe est suivante: DROP INDEX index_name; 6.2 Indexation sur une petite table Dans ce scénario, nous montrons un exemple d’indexation sur une petite table « users » de la base de données EloquenziorUser.sqlite Elle est considérée une petit table parce que les nombres de colonnes et enregistrements sont petits La table « users » a colonnes et 14 enregistrements Scénario avec la requête SELECT, UPDATE, INSERT, DELETE Dans ce scénario, nous exécutons la requête SELECT, UPDATE, INSERT, DELETE avec la table « users » indexée sur la colonne « username » et la table « users » n’est pas indexée sur la colonne « username » 48 Création un index index_usersname sur la colonne « username » par la commande sqlite> CREATE INDEX index_usersname ON users (username); Et puis, on fait une suppression de l’index index_usersname : Le temps dans le cadre blanc est le temps d’exécution de la requête sur la table entière Le cadre rouge montre le temps pour la table indexée Les résultats sont représentés dans les figures suivantes Le résultat de la figure 5.2.2a montre le temps d’une requête SELECT L’exécution de l’index index_usersname est plus lente que l’exécution de scanner sur la table entière (0.027>0.019) Figure 6.2a –Analyse de l’index de la table « users » de la requête SELECT Scénario avec la requête UPDATE Avec la commande UPDATE, le temps d’exécution de scanner sur la table entière : 0.179 et sur la table indexée par la colonne « username » : 0.289 Figure 6.2b –Analyse de l’index de la table « users » de la requête UPDATE Scénario avec la requête INSERT Avec la commande INSERT, le temps d’exécution de scanner sur la table entière: 0.150 et sur la table indexée par la colonne « username » : 0.201 49 Figure 6.2c –Analyse de l’index de la table « users » de la requête INSERT Scénario avec la requête DELETE Avec la commande DELETE, le temps d’exécution de scanner sur la table entière: 0.135 et sur la table indexée par la colonne « username » : 0.186 Figure 6.2d –Analyse de l’index de la table « users » de la requête DELETE Par observation, l’exécution des commandes SELECT, UPDATE, INSERT, DELETE de la table « users » indexée sur la colonne « username » est plus lente que l’exécution des commandes sur la table entière Lorsque des données et des colonnes sont peu nombreuses, l’indexation est inefficace Parce que nous devons dépenser plus de mémoire pour stocker des index, et dépenser de temps de pointeur vers des positions des enregistrements 6.3 Indexation sur une grande table Dans ce scénario, nous testons l’indexation sur la table « Artefact » de la base de données Eloquenzior.sqlite La table « Artefact » possède 15 colonnes et 514 enregistrements Nous montrons les scénarios pour l’analyse comme suit : La requête SELECT EQUAL sans l’index L’exécution une requête SELECT WHERE EQUAL de la table « artefact » : 50 On ne crée pas l’index de colonne « description » qui est la colonne de la condition de recherche, après on exécute la requête SELECT avec la clause WHERE comme suit : sqlite> EXPLAIN QUERY PLAN Select * from artefact where description = 'FRAGMENT DE PLAQUE'; 0|0|0|SCAN TABLE artefact Le système affiche « SCAN TABLE artefact » sur l’écran Il montre que SQLite scanne totalement sur la table « artefact » Puis, on crée un index sur la colonne « description » sqlite> CREATE INDEX index_description ON artefact (description); sqlite> EXPLAIN QUERY PLAN Select * from artefact where description = 'FRAGMENT DE PLAQUE'; 0|0|0|SEARCH TABLE artefact USING INDEX index_description (description=?) Le système scanne sur la table d’index quand on crée un index sur la colonne qui est après la clause WHERE et l’opérateur égal « = » Avec l’opérateur LIKE, le système scanne la table entière Le temps d’implémentation de l’opérateur égal « = » est plus rapide que l’opérateur LIKE Pour la comparaison du temps d’exécution, on crée un index sur la table, et puis on exécute la commande SELECT comme nous montrons dans la figure 6.3a : Figure 6.3a – Analyse du temps d’exécution de l’index de la table « artefact » Par la comparaison entre l’exécution de la table indexée et non-indexée On peut voir le temps réel de la requête avec l’index (0.022) est plus petit que la requête sans-index (0.033) On peut trouver l’indexation sur la colonne de recherche est efficace sur des données volumineuses Avec la requête de la clause « SELECT…WHERE…= » précédemment Nous avons expérimenté pour le temps d’exécution de la recherche linéaire où les enregistrements de recherche sont situés la fin de la table On fait des expérimentations du cas ó la table 51 « Artefact » est indexée sur la colonne « description » et le cas où la table n’est pas indexée Les quantités d’enregistrements sont 100, 200, 300, 400, 500 La coordonnée x est les quantités d’enregistrements, la coordonnée y est le temps d’exécution Figure 6.3b – Analyse du temps d’exécution l’index Par observation des graphiques dans la figure 6.3b, on trouve que l’index n’est pas efficace lorsque le nombre d’enregistrement est petit Le temps d’exécution d’index peut être supérieur au temps de scanner la table entière Quand des données sont volumineuses, l’index est efficace La requête SELECT avec l’index multiple: On utilise l’index index_description_numAutre sur deux colonnes « description » et « numAutre » et exécute la commande SELECT deux colonnes « description » et « numAutre » CREATE INDEX index_description_numAutre ON artefact(description, numAutre) sqlite> EXPLAIN QUERY PLAN SELECT description, numAutre FROM artefact WHERE numAutre ='K64'; 0|0|0|SCAN TABLE artefact USING COVERING INDEX index_description_numAutre Run Time: real 0.002 user 0.000000 sys 0.000000 SQLite affiche « covering index » sur l’écran Cela montre que le système scanne sur la table d’index multiple La structure de la table d’index est les deux colonnes « description » et « numAutre » 52 6.4 B-Trees dans SQLite La requête « SELECT ORDER BY, GROUP BY, DISTINCT » avec Btrees Dans une requête SELECT qui contient des clauses ORDER BY, GROUP BY ou DISTINCT, SQLite utilise une structure temporaire B-Trees pour le tri de sortie Si on crée un index sur des colonnes qui sont après des clauses ORDER BY, GROUP BY, DISTINCT, il pourrait utiliser cet index L'utilisation d'un index B-Trees est presque toujours beaucoup plus efficace que le tri primaire (linéaire) Dans ce scenario, on fait un requête de tri en groupant On regarde un exemple dans le projet suivant : on exécute une requête pour l’affichage de toutes des fréquences d’anatomie dans une jointure des tables groupant par les noms des anatomies « Anatomy.name» SQLite utilise un index B-Trees pour le tri de sortie (regardons le message « USE TEMP B-TREE FOR GROUP BY » sur l’écran) sqlite> EXPLAIN QUERY PLAN SELECT as id, Anatomy.name as name, count( Anatomy.name) as frequence FROM Anatomy, Illustration, illustrateArtefact, Artefact, IllustrationData WHERE illustrateArtefact.f_idArtefact = Artefact.idArtefact AND illustrateArtefact.f_idIllust = Illustration.idIllustration AND IllustrationData.idIllustrationData = Illustration.f_idIllustrationData AND Artefact.anatomy LIKE '%'|| Anatomy.name ||'%' GROUP BY Anatomy.name; 0|0|2|SCAN TABLE illustrateArtefact 0|1|1|SEARCH TABLE Illustration USING INTEGER PRIMARY KEY (rowid=?) 0|2|3|SEARCH TABLE Artefact USING INTEGER PRIMARY KEY (rowid=?) 0|3|4|SEARCH TABLE IllustrationData USING COVERING INDEX sqlite_autoindex_IllustrationData_1 (idIllustrationData=? AND rowid=?) 0|4|0|SCAN TABLE Anatomy 0|0|0|USE TEMP B-TREE FOR GROUP BY Run Time: real 0.018 user 0.000000 sys 0.000000 Figure 6.4a – Analyse de l’exécution de l’index B-trees Par observation du résultat de la commande EXPLAIN QUERY PLAN, on constate que SQLite fait une jointure entre les tables illustrateArtefact, Illustration, Artefact et la table d’index « sqlite_autoindex_IllustrationData_1 » Puis, le système choisit le champ ‘Anatomy.name’ pour grouper les résultats, SQLite crée une table temporaire et y sauve les résultats avec la fréquence = count(Anatomy.name) comme la figure 6.4b Les lignes jaunes représentent des groupements de chaque champ ‘Anatomy.name’ Des enregistrements sont triés dans une arbre B comme la table temporaire et finalement, les enregistrements de groupements sont choisis pour le résultat final 53 Figure 6.4b - B-trees dans la clause GROUP BY Création d'index sur la clé étrangère dans la jointure des tables Dans ce cas, on crée des index sur les colonnes qui sont des clés étrangères dans une requête de jointure L’implémentation est plus rapide On crée trois 54 index sur les clés étrangères “f_idArtefact”, “f_idIllust”, “f_idIllustration” des tables “illustrateArtefact”, “illustrationArtefact”, “illustration” comme suivant: sqlite> CREATE INDEX index_f_idArtefact ON illustrateArtefact(f_idArtefact); sqlite> CREATE INDEX index_f_idIllust ON illustrationArtefact(f_idIllust); sqlite>CREATE INDEX index_f_idIllustrationData ON illustration(f_idIllustrationData); sqlite> EXPLAIN QUERY PLAN SELECT as id, Anatomy.name as name, count( Anatomy.name) as frequence FROM Anatomy, Illustration, illustrateArtefact, Artefact, IllustrationData WHERE illustrateArtefact.f_idArtefact = Artefact.idArtefact AND illustrateArtefact.f_idIllust = Illustration.idIllustration AND IllustrationData.idIllustrationData = Illustration.f_idIllustrationData AND Artefact.anatomy LIKE '%'|| Anatomy.name ||'%' GROUP BY Anatomy.name; 0|0|3|SCAN TABLE Artefact 0|1|2|SEARCH TABLE illustrateArtefact USING INDEX index_f_idArtefact (f_idArtefact=?) 0|2|1|SEARCH TABLE Illustration USING INTEGER PRIMARY KEY (rowid=?) 0|3|4|SEARCH TABLE IllustrationData USING COVERING INDEX sqlite_autoindex_Illust rationData_1 (idIllustrationData=? AND rowid=?) 0|4|0|SCAN TABLE Anatomy 0|0|0|USE TEMP B-TREE FOR GROUP BY Run Time: real 0.009 user 0.000000 sys 0.000000 Figure 6.4c –analyse de l’exécution de l’index sur la clé étrangère On voit que le temps de l’implémentation (0.009) dans la figure 6.4c est plus petit que dans la figure 6.4a (0.018) où on ne fait pas l’indexation sur les clés étrangères L’indexation est non seulement efficace sur des colonnes de recherche et de tri, mais aussi efficace sur des clés étrangères Comparaison l’index primaire avec l’index B-Trees Dans ce cas, on crée un index primaire simple index_anatomy_name sur la colonne de tri ‘Anatomy.name’ Après, on fait une requête SELECT COUNT pour calculer la fréquence d’anatomie SQLite recherchera par l’index index_anatomy_name, le résultat comme suit : 55 sqlite> CREATE INDEX index_anatomy_name ON anatomy(name); sqlite> EXPLAIN QUERY PLAN SELECT as id, Anatomy.name as name, count( Anatomy.name) as frequence FROM Anatomy, Illustration, illustrateArtefact, Artefact, IllustrationData WHERE illustrateArtefact.f_idArtefact = Artefact.idArtefact AND illustrateArtefact.f_idIllust = Illustration.idIllustration AND IllustrationData.idIllustrationData = Illustration.f_idIllustrationData AND Artefact.anatomy LIKE '%'|| Anatomy.name ||'%' GROUP BY Anatomy.name; 0|0|0|SCAN TABLE Anatomy USING COVERING INDEX index_anatomy_name 0|1|3|SCAN TABLE Artefact 0|2|2|SEARCH TABLE illustrateArtefact USING INDEX index_f_idArtefact (f_idArtefact=?) 0|3|1|SEARCH TABLE Illustration USING INTEGER PRIMARY KEY (rowid=?) 0|4|4|SEARCH TABLE IllustrationData USING COVERING INDEX sqlite_autoindex_IllustrationData_1 (idIllustrationData=? AND rowid=?) Run Time: real 0.015 user 0.000000 sys 0.000000 Figure 6.4d – Analyse de l’exécution de l’index primaire On peut trouver que le système utilise l’index primaire créé par l’utilisateur pour faire la requête et SQLite ne crée pas l’index B-Trees sur la colonne triée comme la figure 6.4a Le temps d’exécution dans ce cas est 0.015 (comparons avec le temps d’exécution 0.009 de l’index B-Trees, dans la figure 6.4c) On peut constater que lorsque le système utilise l’index B-Trees, le système s’exécute rapidement que pour l’index primaire Nous avons expérimenté avec la requête SELECT COUNT(Anatomy.name) comme avant sur le temps d’exécution des quantités d’enregistrements de table “Artefact” : 100, 200, 300, 400, 500 enregistrements On supprime tous les index sur les clés étrangères dans le cas précédant pour obtenir des résultats plus précis Le résultat est affiché comme la figure 6.4e suivante La coordonnée x est les quantités d’enregistrements, la coordonnée y est le temps d’exécution La ligne jaune représente le graphe de temps d’exécution quand le système utilise les B-trees pour grouper et la ligne bleue pour l’index primaire 56 Figure 6.4e - Analyse du temps d’exécution de l’index B-trees et l’index primaire Par observation du graphique, on trouve que lorsqu’on compte le nombre d’enregistrements par la commande SELECT GROUP BY, l’index B-trees est plus efficace que l’index primaire lorsque le nombre d’enregistrement est grand 57 Conclusion et perspectives Conclusion L’organisation et la gestion de données sont importantes dans le processus de réalisation d’un système de base de donnộes Lindexation est une faỗon dorganisation des donnộes pouvant augmenter la performance des systèmes de gestion Nous avons fait une étude théorique et pratique sur l’indexation dans le projet d’archéologie Eloquenzior Dans le chapitre 3, nous avons montré les méthodes d’indexation pour appliquer la partie pratique Dans les chapitres et 5, nous avons présenté la proposition et l’implémentation du projet d’archéologie Eloquenzior Une partie de projet d’archéologie Eloquenzior a été implémentée dans mon stage basée le model client-serveur où nous avons développé les interfaces, la fonction d’affichage, le management des données, la recherche et l’organisation les données sur les nouvelles techniques de développement Web : Express, Jade, Node.js, SQLite Pour chaque type de données, on a étudié des techniques et des bibliothèques pour l’affichage, le traitement, le stockage et l'exportation des données Premièrement, nous avons présenté le résultat d’affichage et de recherche Deuxièmement, nous avons montré l’indexation et l’organisation des données Nous avons réalisé l’index inversé dans SQLite pour la fonction de la recherche plein-texte Pour accéder des fichiers, nous avons organisé des données de type fichier dans des dossiers et utilisé l’indexation logique sur les fichiers pour y accéder Un objet géométrique est numérisé un ensemble des points sous format ‘WKT’ et stocké dans la base de données avant l’indexation Avec l’objet 3D, nous avons proposé une méthode d’index qui associe chaque mot-clé des zones de l'espace visuel Cette association permet de relier mots-clés et informations visuelles Un des avantages de cette méthode est que les zones visuelles sont interprétables Les zones peuvent être facilement manipulées et stockées Des hyperliens dans le projet permettent de naviguer entre des pages Web, nous avons les organisé dans une liste triée, un arbre récursif, un nuage Nous avons introduit une nouvelle structure non-triée « nuage» qui permet d’organiser des images dans une seule page pour faciliter la recherche des images L’indexation peut être créée dans un fichier PDF qui contient des données de tout le système en créant une page de sommaire Finalement, dans le chapitre 6, pour améliorer la vitesse d'accốs aux donnộes, par les faỗons de gộrer l’index dans SQLite, nous avons montré une partie pratique et l’évaluation la requête de l’indexation sur des données volumineuses et sur des petites tables L’indexation peut être inefficace sur une petite table Alors, on peut prendre une décision de 58 sélectionner une colonne et une table pour l’indexation où il faut assurer que les avantages de l'indexation sont toujours plus grands que le coût du stockage On a appliqué l’indexation B-trees dans la clause GROUP BY, puis on a représenté une méthode comparative entre l’index B-trees et l’index primaire dans une expérimentation qui démontre que l’index B-trees est plus avantageux que l’index primaire, non-hiérarchisé sur des données volumineuses En plus, nous avons réalisé que l’indexation sur des clés étrangères peut améliorer le temps d’implémentation la requête de jointure également Perspectives et limitations Nous souhaitons par la suite travailler sur les images du web pour construire un moteur de recherche d'images des informations visuelles efficaces pour lequel l'utilisateur fournit plusieurs mot-clé pour des images d’illustration d’artefact Enfin, la limitation de notre système est la vitesse d’exporter des images au PDF pas rapide : avec 400 images, il prend beaucoup le temps pour exporter Avec la donnée de type document : le système doit l’afficher comme une image Cela signifie que le système transforme automatiquement le fichier en image avant Puis, l’utilisateur doit faire un operateur de sauvegarder cette image un dossier dans l’ordinateur avant exporter au PDF Dans l’avenir, nous souhaitons une fonction exportation de PDF plus rapidement avec des images volumineuse Nous souhaitons le système peut exporter des données de type document au PDF directement, l’utilisateur n’a pas besoin d'sauvegarder la photo de document sur l’ordinateur En plus, le système peut convertir un objet 3D en image 2D automatiquement avant l’exportation au PDF 59 Référence [1] Aanne Chaillou (2003), Nature statut et traitements informatisés des données en archéologie, pp.15, 35, 18 [2] Alessandro Furieri (2011), “Spatial SQL: WKT and WKB”, pp.1 [3] Julien Forget (2011-2012), “Système de fichiers”, Cité Scientifique 59655 Villeneuve d’Ascq, pp.3-25 [4] Bertrand Le cun et Emmanuel Hyon (2011), “Gestion de Fichiers”, Université Paris Ouest Nanterre, pp.17-20 [5] Antoine Cornuéjols (2007), “ Stockage des données et indexation”, pp.1 [6] Alessandro Artal (2003-2004), “Database 2, Lecture II”, University of Bolzano, pp.3 [7] Amin Aoulad Abdelouarit (2012), “Optimisation des performances de l’entrepôt de données via les index”, Université Abdelmalek Essaad de Tétouan, Maroc, pp.38 [8] Andreas Kaltenbrunner, Lefteris Kellis & Dani Mart (2010), “B-tree”, pp.5 [9] Maude Manouvrier (2012), “Un exemple de structure de données hiérarchique : l'arbre B+”, Université Paris-Dauphine, pp.3 [10] El Amin Aoulad Abdelouarit, Mohamed Merouani (2013), “Les index pour les entrepôts de données : comparaison entre index arbre-B et Bitmap”, pp.3 [11] Dan Vodislav (2016), “Organisation physique des données Master M1 Informatique (2016-2017)”, Université de Cergy-Pontoise, pp.20, 23, 30, 32, 39 [12] El Ghailani Maher (2003), “Bitmap indexing and related indexing techniques”, pp.11 [13] Stefan Brass, Datenbanken (2005), “B-Tree Indexes”, pp.4 [14] Ajit Kumar Mahapatra1et Sitanath Biswas (2011), “Inverted indexes: Types and techniques”, IJCSI International Journal of Computer Science Issues, Vol 8, Issue 4, pp.385387 [15] Aurélien Max (2010), “Indexation pour la Recherche d’Information”, pp.4 [16] Adam Hadraba (2015), Inverted index implementation, pp.5-10 [17] Jimmy Lin and Chris Dyer (2010), “Data-Intensive Text Processing with Map Reduce”, Morgan & Claypool Publishers, pp.68, 72-76 [18] David Kauchak (2009), “TF-IDF”, pp.7-8 [19] Zineddine KOUAHLA (2013), Indexation dans les espaces métriques, pp.35-36 [20] Kirill Smirnov, George Chernishev (2014), R-tree re-evaluation effort: a report*, pp.3-4 [21] Sean Lang (2014), Web Development with Jade, pp.18 [22] Jean-Yves Antoine(2016), “Bases de donnộes avancộes, Universitộ Franỗois Rabelais de Tours, pp.5 [23] Jesse Farmer (2008), “Interview Questions: Database Indexes”, pp.1 [24] Bertrand LIAUDET (2007-2008), “Base de données”, pp.16-17 60 [25] Luca Bondi (2016), “Inverted Indexing”, pp.3-6 [26] Philippe Rigaux (2001), “Cours de bases de données”, pp.149-150 [27] C.Crochepeyre (2000 - 2001), “Système de gestion de fichiers”, pp.62-68 [28] Robert Godin (2006), “Stockage des données, indexation, optimisation des requêtes”, pp.68 [29] Bertrand Dupouy(1991), “Gestion des fichiers”, Telecom-ParisTech BCI Informatique, pp.328 [30] Neelabh Pant (May 2015), “Performace comparion of spatial indexing structure for differenct query types”, pp.4-5 [31] Bayer R., McCreight C (1972), “Organization and Maintenance of Large Ordered Index”, Acta Informatica, pp.173-189 [32] MANNING, Christopher D, Prabhakar RAGHAVAN, Hinrich SCHUTZE (2008) “Introduction to information retrieval”, 1st pub, Cambridge: Cambridge University Press, xxi, 482 s ISBN 9780521865715 [33] D Comer (1979), “The Ubiquitous B-Tree ACM Computing Surveys”, pp.11 [34] Donghui Zhang (2004), “B Trees”, CRC Press, LLC, pp.15 [35] Marcus Fontoura, Maxim Gurevich, Vanja Josifovski (2011), “Efficiently Encoding Term Co-occurrences in Inverted Indexes”, ACM 978-1-4503-0717-8/11/10, pp.3 [36] Adnen A (2009-2010), “Système de gestion de fichiers’’, Institut Supérieur d’Informatique et des Technologies de Communication, pp.2 [37] Kim Nguyen, Veronique Benzaken (2014), “Indexation Implantation des opérateurs Calcul de coût”, Polytech Paris-Sud, pp.13 [38] P Rigaux (2011), “Indexation Structures arborescentes et hachage’’, Univ Paris-Dauphine, pp.9 [39] Eliseo Clementini, (2009), A Conceptual Framework for Modelling Spatial Relations, Université Lyon, N° d’ordre ISAL-0028, pp.9 61 ... des relations de données Chapitre Indexation de données 3.1 Stockage des données Pour comprendre l? ?indexation, on fait l’étude sur des unités des stockages physiques, des unités des stockages... l 'indexation des données d'archéologie Le but de l? ?indexation est l’organisation des données pour l’accès rapide aux objets en réduisant l’espace de recherche Des données d'archéologie sont des... FRANCOPHONE INTERNATIONAL HOÀNG YẾN INDEXATION DE DONNÉES POUR L´ARCHÉOLOGIE ĐÁNH CHỈ MỤC DỮ LIỆU CHO KHẢO CỔ HỌC Spécialité: Réseaux et Systèmes Communicants (RSC) Code: Programme pilot HANOI - 2016