Projet Tuteuré:
Base de données archéologique et logique floue.
Commanditaire: laboratoire de géo-archéologie
Équipe :
BONENFANT Michel DERRIAULT Christopher
MARTIN Johnny
I . Introduction
Description du sujet:
Le laboratoire de géo-archéologie nous a confié la tâche de développer une application de gestion de base de données archéologique qui permettra de gérer les données extraites d'une nécropole.
Nous avons jusqu'au vendredi 27 octobre 2006 pour réaliser la phase d'analyse et de conception du projet. Durant cette première phase, nous analyserons donc le sujet et établirons le planning ainsi que la répartition des tâches.
Ensuite, nous disposerons de 8 semaines pour la phase de production et de qualification, ce qui nous emmènera au vendredi 22 décembre 2006.
Enfin, la phase de déploiement et de finalisation du projet s'étendra jusqu'au vendredi 19 janvier 2007.
II . Étude préalable
1 . Objectifs du projet
Ce projet est en deux temps.
Le premier temps consiste à développer une base de données archéologique et une IHM pour l’administration de la base de données. Le cahier des charges concernant l’interface homme-machine (IHM) et le MCD sera fourni.
Le deuxième temps consiste à réutiliser un programme de logique floue pour classer des informations de la base de données par rapport à des règles définies dans le moteur de logique floue. Les règles sont renseignées par un fichier XML et des données provenant de la base de données sont passées en paramètre au moteur de logique floue pour réaliser une classification.
Exemple d’interface homme machine représentant la table unité de fouille dans la base de donnée:
2 . Étude détaillée
Etude du Modèle Conceptuel des Données
Avant d'analyser le Modèle Conceptuel des Données de cette base de données
archéolgique, il paraît nécessaire de présenter la table centrale de ce MCD. En effet, il s'avère que toute la structure de la base de données s'oriente autour de la table « unité de fouille ».
La table unité de fouille décrit une certaine zone des fouilles, elle est identifiée par un ID, un numéro. Ces caractéristiques sont les suivantes :
une longueur minimum, une largeur minimum, une profondeur,
un état de conservation(conservation), une description,
ses coordonnée(X. & Y) sont représentées par une image.
Partie Inhumation:
La partie Inhumation du MCD permet de trier, par unité de fouille, les inhumations répertoriées, ainsi que nous le montre la relation ci-dessous.
Cette relation exprime le fait qu'une occurrence de l'entité inhumation se situe dans une et une seule unité de fouille, alors qu'une unité de fouille peut se révéler contenir plusieurs corps inhumés.
Ici, cette relation nous informe que chaque corps inhumé peut posséder chaque occurrence de la table
Partie Topologie:
La table topologie regroupe toutes les topologies observées sur le site qui sont identifiées par un ID. Chaque topologie possède un type.
D'après l'ensemble de relations présenté ici, une topologie ne peut pas concerner à la fois une unité de fouille, une inhumation, une incinération, une offrande animale, ou un mobilier.
Néanmoins une topologie concernant par exemple une unité de fouille peut concerner plusieurs unités de fouille.
Cette relation réflective nous informe qu'une ou plusieurs topologies peuvent être en relation avec une ou plusieurs autres topologies. Cela permet de situer une topologie par rapport à d’autres.
Partie Mobilier:
La partie Mobilier de ce MCD permet de classer les différents objets trouvés dans une unité de fouille, comme l'annonce la relation ci-dessous:
A partir de cette relation partent d'autres relations permettant de définir de quel type est une occurrence de la table « mobilier ». Puis, d'autres relations adjacentes à quelques types permettent de définir un type.
A première vue, cet ensemble de relations peut paraître compliqué à comprendre, mais il est en fait assez simple.
En effet, nous voyons que chaque relation concerne d'une part la table « mobilier » et d'autre part une table représentant un type de mobilier. De plus, l'ajout de la contrainte d'exclusivité entre toutes ces relations modélisée par la croix à l'intérieur du disque jaune nous permet de comprendre qu'une occurrence de l'entité mobilier ne peut être que d'un type. Elle est du type bois, verre, céramique, métallique, autre, ou encore qu'elle n'appartient à aucun type.
Maintenant, intéressons-nous à la définition de chaque type cité dans le paragraphe précédent.
L'ensemble de relations présenté ci-dessus nous informe sur le fait qu'une occurrence de l'entité « pièce céramique » appartient à un seul « groupe céramique », ainsi qu'à un seul « type céramique ». De plus, à chaque occurrence de l'entité « type céramique », on ne peut associer au plus qu'une occurrence de chaque entité « pâte » et « surface ».
En observant ces deux relations, nous apprenons qu'un « fragment métallique » appartient à un « type métallique », mais aussi qu'un « type métallique » entre dans une « typologie métallique ».
Partie Incinération:
La table incinération va correspondre à des zones carbonisées retrouvées dans une et une seule unité de fouille.
Ces zones sont classées par ID et pourront être décrites par un ipc (indice pondéral
crânien), leur taux d’identification, le contenant périssable, le poids total humain relatif (très faible, faible, moyen, important, très important), poids total humain précis, poids total animal.
Cela dit, si la zone possède un contenant périssable et que cela s’avère être un mobilier, ce dernier ne pourra pas être de type céramique.
Dans cette zone incinérée, on pourra retrouver :
Aucun ou plusieurs sujets humains identifiables grâce à leur numéro ID, leur age et leur sexe.
Aucun ou plusieurs sujets animaux identifiables grâce à leurs IDs et leurs espèces.
Aucun ou un unique type de mobilier identifiable grâce à son numéro ID, sa fragmentation, son degré d’incinération, son orientation et son image.
De plus, les sujets humains et animaux pourront avoir des os qui seront dénombrés, que l’on nommera et que l’on classera par ID.
Partie Offrande:
Une offrande animale va aussi être retrouvée dans une et une seule unité de fouille.
Ces offrandes vont être classées par ID et décrites par leur sexe (M pour masculin, F pour féminin, I pour inconnu et C pour castré ), leur type d’espèce ainsi que leur age.
De plus, ces offrandes seront forcément décrites par le type d’os qui les compose.
Elles pourront être également décrite la/les partie anatomique découverte et le groupe d’offrande auquel elles correspondent.
Ces trois parties seront, quant à elles, classées par ID et décrite par des noms.
Partie Datation :
La table datation regroupe toutes les périodes utilisées sur la zone de fouille. Chaque période est identifiée par un ID, et possède un nom de période ainsi qu’une date de début et une date de fin.
Cet ensemble de relations nous indique que chaque occurrence des entités présentes ici, hormis datation, peut être associée à maximum une occurrence de la table datation.
Un type de bois permet de représenter tous les types de bois présents sur le site de fouilles. Chaque type de bois appartient à une période et est représenté par un nom, une essence et une utilisation qui représente une description brève de ce à quoi servait ce bois.
Un type de verre permet de représenter chaque sorte de verre présent sur le site. Chaque type de verre appartient à une période, et est représenté par un nom et une couleur.
Le type céramique permet de classifier les objets en céramique selon leur nom et leur forme ainsi que selon leurs fonctions en Gaule et/où à Rome et leur morphologie. Chaque type de céramique appartient à une période.
Un type métallique permet de représenter chaque métaux présents sur le site. À un métal donné correspond une période. On identifie ce type par un nom ainsi que la matière qui le compose.
Chacun des types précédemment décrits possède donc une période qui doit exister dans la table datation.
La connaissance de ces périodes permettra de dater les unités de fouille sur lesquelles ces types ont été retrouvés.
Il faut également savoir que chaque unité de fouille s'inscrit obligatoirement dans une période qui devra préalablement être créée dans la table datation.
La logique floue
Pour réaliser notre projet, il nous est demandé d'implémenter un moteur de logique floue afin de classer des informations dans la base de donnée par rapport à des règles définies par ce dernier.
Nous allons donc essayer de vous faire comprendre de manière simplifiée ce qu'est la logique floue.
La logique floue est très proche du processus de la pensée humaine "quotidienne". Elle met en oeuvre un jeu de règles comme, implicitement, nous en utilisons chaque jour.
Voici un petit exemple pour mieux comprendre le principe de cette logique.
Pour tout conducteur normal, le processus de conduite comporte quelques règles élémentaire
Si le feu est rouge Si ma vitesse est
élevée Et si le feu est proche Alors je freine fort.
Si le feu est rouge Si ma vitesse est faible Et si le feu est loin Alors je maintiens ma vitesse.
Si le feu est orange Si ma vitesse est
moyenne Et si le feu est loin alors je freine doucement.
Si le feu est vert Si ma vitesse est faible Et si le feu est proche alors j'accélère.
La logique floue formalise donc le monde de la même manière que le fait notre cerveau.
Par exemple, on ne dira jamais "Si le feu est rouge, si ma vitesse dépasse 85,6 Km/H et si le feu est à moins de 62,3 mètres, alors j'appuie sur la pédale de frein avec une force de 33,2 Newtons".
Cette logique admet donc des variables approximative tel que faible, élevé, loin, proche en entée et fait de même pour les variables en sorties (freinage léger ou fort).
Ainsi, elle va déterminer un ensemble de règle dans le but de mettre en relation les entrées et les sorties.
3 . Étude technique
Durant ce projet, nous allons utiliser différentes technologies pour mettre au point la base de données, l'IHM pour l'administration de cette base de données, ainsi que pour l'implémentation du moteur de logique floue.
Premièrement, la base de données a été créée à partir d'un script PostgreSQL qui nous a été fourni, ainsi que le Modèle Conceptuel des Données à l'origine de ce script.
Ensuite, puisque le moteur de logique floue fourni a été développé en C#, nous devons maintenant développer l'application de gestion de la base de données avec ce même langage.
De plus, les règles de logique floue seront décrites dans un fichier XML.
Planification
L’interface est découpé en 9 onglets et doit être fini au plus vite afin de pouvoir attaquer la partie la plus importante du projet sur la logique floue. Pour cela nous avons découpé l’interface en 3 parties
réalisables indépendamment les une des autres. Chacun de nous se chargera de l’une de ses parties qui devront être terminées pour le 09/11/06.
Après cette phase, 2 jours seront attribués pour la mise en commun des différentes parties et pour s’assurer que ceux-ci sont compatibles entre elle. L’interface avec la base de donnée devra avoir atteint son stade final lors de cette phase.
La phase suivante est l’application des principes de logique floue à l’archéologie.
Cette phase ne peut être planifiée pour le moment, en effet sa composition nous est encore inconnue. De ce fait, il est important de terminer rapidement la phase interface afin de gagner un maximum de temps pour réaliser cette partie.
