Conception des systèmes d'information

De Metabolisme territorial
Aller à : navigation, rechercher

Dans nos travaux, nous définissons les bases conceptuelles d'un système d'information qui aide à l'analyse du métabolisme des territoires. Pour ce faire, nous mobilisons différentes approches issues du monde informatique, que nous appliquons à notre thématique spécifique d'étude (voir chapitre X). Dans cette partie, nous présentons les fondements de ces approches. Il ne s'agit pas de recenser l'ensemble des approches disponibles, mais d'identifier celles qui vont nous permettre de concevoir notre système d'information.

Ainsi, après quelques généralités sur les systèmes d'information, nous examinerons les structures disponibles pour manipuler des données. Nous aborderons ensuite les notions d'ontologie, de modèle de données et de programmation orientée objet. Nous parlerons également des entrepôts de données et des projets inspirant DBpedia et Wikidata. Enfin, nous prendrons le temps d’approfondir la question de la visualisation des données.

Systèmes d'information

Un système d'information (SI) vise à "transformer des données brutes, hétérogènes, [...] en une information visible et compréhensible." (Flichy 2013, p.59). Il s'agit d'un ensemble d'algorithmes, exécutés sur une machine informatique en interaction avec des utilisateurs humains ou avec d'autres SI pour manipuler des données, c'est-à-dire en ajouter, les visualiser, les modifier, les synthétiser, les partager, ...

L’ingénierie des SI fait partie des sciences de conception (Assar 2015). Plutôt que décrire le monde tel qu'il est, ces sciences de l’artificiel visent à imaginer comment il pourrait être et à spécifier les artéfacts qui y amènent. La conception repose beaucoup sur l'empirisme et l'itération, parfois plus que sur la déduction (Flichy 2013). Les concepteurs doivent en effet procéder à des choix techniques, sur la base de leurs connaissances, de leurs ressources et de leurs intuitions, forcément limitées. L'évaluation des artéfacts conçus est ainsi indispensable pour les améliorer jusqu'à ce qu'ils répondent de manière satisfaisante aux objectifs qui leur sont assignés (Assar 2015).

Le développement d'un SI est un processus long qui mobilise de nombreuses personnes et compétences à l'intersection entre plusieurs disciplines (Flichy 2013). Le travail de programmation ne représente qu'une partie du processus : celle visant à l'implémentation concrète de tout un travail de conceptualisation et de formalisation des besoins des utilisateurs et du domaine d'étude.

Dans les méthodes de développement de système d'information, la plus connue (au moins en France) est probablement la méthode MERISE dont nous nous sommes largement inspirée dans nos travaux. Cette méthode repose sur la séparation des données et des traitements. Elle est toutefois décriée pour sa complexité si l'on souhaite l'appliquer de manière rigide (Thévenot 2001).

Même si un certain nombre d'auteurs proposent des méthodologies pour la développement des SI{Ref needed}, il ne semble pas y a pas de méthode unique pour la conception d'un système d'information. Cela va surtout dépendre de la complexité des fonctionnalités que l'on souhaite proposer.

La formalisation des besoins des utilisateurs prend généralement la forme d'une analyse fonctionnelle {Ref needed}. Il s'agit d'identifier précisément les fonctions nécessaires aux utilisateurs pour pouvoir traiter les données relatives à leur domaine. Nous verrons l'analyse fonctionnelle pour notre domaine d'étude dans le chapitre XX. Le formalisation du domaine d'étude peut quant à elle se faire à l'aide d'une ontologie et d'un modèle de données. Nous détaillons ces notions dans les parties suivantes.

Comme tout science, la conception d'un SI repose également sur la réutilisation de concepts et de méthodes déjà existants. Nous présentons ainsi également deux concepts, répandus dans le monde de l'informatique, qui nous a paru pertinent de mobiliser dans nos travaux : la Programmation Orientée Objet (POO) et les Entrepôts de Données (EDD).

Voir également :

Structures de données

Les structures de données sont des manières d'organiser les données pour pouvoir les agréger, créer des liens entre elles, les stocker, les manipuler et les partager avec d'autres utilisateurs humains ou machines (http://dimacs-algorithmic-mdm.wdfiles.com/local--files/start/Methodologies%20for%20Data%20Quality%20Assessment%20and%20Improvement.pdf). Elles sont fondamentales pour les systèmes d'informations car elles permettent l'utilisation d'algorithmes efficaces dans le traitement des données {Ref needed}. Les données structurées visent à être concises et explicites, à la différence des données non structurées, comme le texte, le son, les images, les vidéos qui peuvent faire l'objet d'une interprétation[1]. En fait, pour exister numériquement, toutes les données doivent être structurées, mais nous parlons bien ici des données explicites littérales (nombre ou texte court).

Toute opération de traitement des données va nécessiter de les manipuler à travers leur structures. De nombreux outils informatiques existent pour cela : logiciels spécialisés, librairies de programmation, système de gestion de bases de données, ... Nous dressons ici un panorama générales des structures existantes, pour pouvoir mieux décrire notre démarche dans les chapitres suivants.

Les structure récursives

Les structure récursives organisent les données sous forme de blocs de données (des nœuds ou sommets) reliés entre eux. Les liens (ou arrêtes) entre les nœuds peuvent avoir un sens (liens orientés) ou être également porteurs d'un bloc de donnée, par exemple pour spécifier la longueur du chemin. Les structures récursives les plus simple sont les listes chaînées (figure X.a) qui permettent d'ordonner les données, puis les arbres qui permettent de les hiérarchiser (figure X.b), puis les graphes qui permettent de multiples relations entre les différents nœuds (figure X.c).

Ces structures générales font l'objet de plusieurs déclinaisons : Les listes chaînées permettent de conceptualiser des files d'attentes ou des piles, les arbres sont nécessaires pour conceptualiser des arborescences (de fichiers, d'une nomenclature, des territoires, ...) et des algorithmes de recherche efficaces, et les graphes ont permis l'émergence de la foisonnante théorie des graphes en mathématiques.

La définition d'une structure récursive est assez simple en programmation et de nombreuses librairies contenant les fonctionnalités idoines existent pour cela. Par contre, les logiciels communs (notamment bureautiques), ne permettent pas de manipuler des structures récursives simplement, et il faut utiliser des logiciels spécialisés.

Formats de sérialisation

La sérialisation consiste à organiser des données sous la forme d'une longue chaîne de caractères (sérialisation textuelle) ou de bits (binaire). L’ordonnancement des informations et l'utilisation de certains caractères (ou suite de bit) qui ont un sens spécifique sont définis selon une convention. Cela permet d'extraire un sens complexe de cette longue chaîne et de lier de manière cohérentes différentes parties. (Sumaray & Makki, 2012)

Les formats de sérialisation textuelle sont lisibles par les humains, même si cela demande un peu d'effort et de connaitre la convention pour en interpréter le sens. Pour cela les données sont séparées et structurées soit à l'aide de délimiteurs (",", ";", " ", retour à la ligne, ...) pour former des lignes et des colonnes comme avec le format CSV, ou soit en utilisant des balises ("<balise>Donnée</balise>", ou "{Donnée}" ) comme pour les formats XML, JSON. Les trois formats cités sont les plus répandus en informatique et particulièrement présents pour l'échange de données sur le web (Sumaray & Makki, 2012).

Les formats binaires quant à eux forment une suite de bits, ce qui rend leur lecture trop complexe pour un humain, mais ne pose pas de difficulté pour une machine. Ils sont plus adaptés pour structurer des données complexes (images, son, document bureautique) et en optimiser la taille. La plupart des extensions connues (zip, doc, png, jpg, gif, mp3, avi, ...) repose sur une telle sérialisation.

Dans la pratique, tous les fichiers que nous manipulons reposent sur des formats de sérialisation. Ce sont les différents logiciels qui permettent d'en extraire le sens et de le rendre manipulable par un utilisateur humain à travers une interface (graphique, tactile, sonore ...). L'intérêt des formats textuels est que le plus simple des logiciels (le bloc-notes) suffit pour lire la chaine de caractères.

Les tableaux

Les tableaux sont un moyen efficace de structurer l'information, à la fois très familière pour les humains, mais aussi pour les machines informatique dont l'architecture est fondamentalement compatible avec cette approche. Nous pouvons distinguer plusieurs types de tableaux :

  • Les tableaux à une dimension de lecture (plus souvent appelées "enregistrements") sont composés d'une succession de lignes (très rarement de colonnes), chaque ligne formant un groupe de données dont le sens est identifié par l'intitulé de colonne.
  • Les tableaux à deux dimensions, où chaque case est mise en correspondance avec son intitulé de ligne et de colonne, formant ainsi un triplet de valeur.
  • En généralisant, nous pouvons conceptualiser des tableaux à 3,4, ... n dimensions, formant ainsi des tableaux multidimensionnels (des hypercubes), où chaque donnée est à l'intersection de n intitulés, formant ainsi un n-plet de données.

Les enregistrements et les tableaux 2D se manipulent aisément avec un logiciel tableur. Pour les tableaux de dimension supérieure, il faut faire appel à des logiciels plus avancés, comme par exemple les technologies OLAP (Online Analytical Processing). Dans tous les cas, il est toujours possible de présenter un tableau à n dimensions sous la forme d'enregistrements avec n+1 colonnes (un tableau 2D de taille l x c peut se présenter sous la forme de l x c lignes et 3 colonnes).

Tableaux liés : Modèle Entité/Association

Il est possible de structurer des données sous la forme d'un ensemble de tableaux d'enregistrements reliés entre eux. Pour concrétiser ce lien, il suffit que les données d'une colonne soit communes à plusieurs tableaux. On parle de clef de jointure, celle qui permet d'établir le lien (il s'agit souvent d'une référence unique : d'un produit, d'un client, ...). Cette structuration des données est fondamentale en informatique, elle est plus souvent dénommée "modèle entité/association" et est déployée à travers les bases de données relationnelles (BDDR). Grâce à cette approche, il est possible de gérer une forte complexité dans les relations entre les données, là où les modèles récursifs ou les tableaux sont conceptuellement limités.

De manière pragmatique, le modèle entité/association vise à structurer les données relatives à un domaine à travers un ensemble de tables, chacune visant à rassembler les données d'un type d'entité particulier (on parle parfois de classes) comme des clients, des produits, des villes. En fait, presque n'importe quel nom commun qui soit tangible peut constituer un type d'entité. Ces entités sont décrites par des propriétés qui peuvent être de type élémentaire (nombre, date, texte court) ou représenter une association avec un ou plusieurs autres entités du modèle. Le modèle entité/association est souvent formalisé à l'aide du diagramme de classe du langage UML ou du modèle logique de données de la méthode Merise (qui est très similaire).

La mise en œuvre d'un modèle entité/association à travers une BDDR est une approche standard dans l'industrie, mature, dominant le marché du stockage de l'information et disponible dans pratiquement tous les Systèmes de Gestion de Bases de Données (SGBD) (https://tel.archives-ouvertes.fr/tel-00465962/document ). Ces derniers vont permettre d'accéder, d'ajouter, modifier ou supprimer des données dans une BDDR par l’intermédiaire de requêtes écrites dans un langage spécifique, souvent du SQL - Structured Query Langage. Ces requêtes nécessitent de connaître le modèle de données, et peuvent être parfois complexes à écrire, surtout si les jointures à réaliser sont nombreuses. L’exécution de ces requêtes est toutefois très efficace dès lors que l’on travaille avec des ensembles (https://tel.archives-ouvertes.fr/tel-00465962/document ).

Structures de données basées sur le web

L'apparition d'Internet a été une révolution dans la façon nous partageons l'information. A l'origine, Internet n'a pas fondamentalement changé la façon de structurer les données et a simplement permis d'y accéder à distance, ce qui est déjà un progrès conséquent. Toutefois, nous voyons émerger deux structures dont l'essence même est d'être distribuée sur Internet : le web de données et les chaines de blocs. Bien que reprenant des structures existantes (respectivement le modèle entité-association et les listes chaînées), cette spécificité impose des contraintes supplémentaires pour rendre la structure fonctionnelle, mais ouvre dans le même temps des possibilités nouvelles.

https://interstices.info/le-web-de-donnees/

Web de données

Le web de données (ou linked data) permet de structurer des données sous la forme d'une base distribuée à l'échelle d'internet. Concrètement, chaque site souhaitant publier des données compatibles avec cette démarche globale doit respecter un certain nombre de conventions. Celles-ci permettent de rendre interopérables les données entre différentes bases, de façon à permettre aux utilisateurs de réaliser des requêtes (en SPARQL) comme s'il ne s'agissait que d'une seule base.

Pour être opérationnel, le formalisme du web de données est plus conséquent que celui du modèle entité/association, et donc plus complexe à mettre en œuvre. Notamment, le web de données implique l'utilisation d'identifiant unique (URI - Uniform Resource Identifier) permettant d'identifier de manière partagée et non ambiguë les différentes entités à décrire (Berners-Lee 2006). Il implique également de multiplier les liens entre les entités, entre différents sites.

Il nécessite notamment de partager les ontologies de domaine (voir chapitre suivant) et donc d'user d'un formalisme commun à travers le langage OWL + RDF* + SPARQL. Toutes ces normes sont proposées par W3C.

Annexes

  • Web de données et création de valeurs : le champ des possibles : https://www.cairn.info/revue-i2d-information-donnees-et-documents-2016-2-page-28.htm
  • https://hal.archives-ouvertes.fr/hal-00793284/
  • Wikipedia et Wikidata incluent des outils sémantiques (à traves l'extension SMW)
    • Résumé : Le web des données consiste à publier des données sur le web de telle sorte qu'elles puissent être interprétées et connectées entre elles. Il est donc vital d'établir les liens entre ces données à la fois pour le web des données et pour le web sémantique qu'il contribue à nourrir. Nous proposons un cadre général dans lequel s'inscrivent les différentes techniques utilisées pour établir ces liens et nous montrons comment elles s'y insèrent. Nous proposons ensuite une architecture permettant d'associer les différents systèmes de liage de données et de les faire collaborer avec les systèmes développés pour la mise en correspondance d'ontologies qui présente de nombreux points communs avec la découverte de liens.
  • https://www.w3.org/DesignIssues/LinkedData.html

Chaîne de blocs

Plus souvent connue sous son nom anglais (blockchain), la chaîne de bloc présente des caractéristiques qui en font une structure de données spécifique. On peut la considérer comme une bases de données distribuée (donc avec des données stockée simultanément à différents endroits du réseau) et non modifiable (il n'est possible que d'ajouter des nouveaux blocs).

La première chaîne de blocs a été conceptualisée par une personne (ou une équipe) connue sous le nom de Satoshi Nakamoto en 2008.

La chaîne de bloc est connue pour avoir permet l'essor des crypto-monnaie (la plus connue étant le BitCoin) : ces monnaies qui ne répondent pas de l'autorité d'un état ... Mais les applications possibles de la chaîne de bloc dépassent les seules questions financières (https://www.cairn.info/revue-realites-industrielles-2017-3-p-10.htm, Delahaye 2015) systèmes universels de courrier, instruments notariés et financiers décentralisés, systèmes de votes en ligne sécurisés, etc. . Plusieurs chercheurs considère la blockchain comme permettant d'établir de la confiance.

La blockchain est basée sur un protocole qui permet de garantir l'intégrité des données et d'empêcher leur falsification.

On peut considérer la blockchain "un très grand cahier [virtuel] que [...] tout le monde puisse lire, sur lequel chacun puisse écrire, mais qui soit impossible à modifier et indestructible" (Delahaye 2015, p.80).

Les images graphiques

Une image est à la fois une donnée en elle-même, mais elle peut aussi contenir des données et constituer ainsi une structure de données. Nous pensons surtout aux graphiques (histogramme, nuages de points, cartographies, ...) qui permettent d'exprimer visuellement des données. Nous mettons de cotés les photographies et les vidéos car cela nous amènerait à des questions de traitement des images. Soulignons toutefois qu'il est possible d'extraire des informations de ces différents supports, cela montre ainsi qu'il s'agit également de structures de données, bien que parfois complexe à exploiter.

Les graphiques sont quand à eux plus faciles à exploiter. Il permettent d'appuyer un grand nombre d'études quantitatives.

Si construire un graphique à partir de données est désormais une tâche assez aisée avec les outils informatiques (librairies de fonction "plot", SIG, ...), l'opération inverse est plus complexe, surtout pour des machines, et ne peut pas permettre de retrouver la précision des données initiales à cause de l'approximation graphique. A cela s'ajoute le caractère un peu absurde à vouloir déduire d'un graphique les données qui ont permis sa construction, même si en pratique cela s'avère parfois plus simple que de retrouver les données correspondantes dans un format adéquat.

Les images graphiques constituent donc plutôt une structure pour le bout de la chaine de traitement des données, lorsqu'il s'agit de transformer ces données en une information appréhendable par des humains. 

Avantage :

  • Fait appel à l'intuitivité dans la compréhension des liens grâce à du graphique
  • Facilement constructible à partir des données à représenter

Inconvénient :

  • Approxime les valeurs
  • Ne constitue pas une structure permettant une exploitation aisée des données par les machines (sauf l'image en tant que donnée elle-même)

Synthèse

Type de structure User friendly Machine friendly
Texte + --
Graphique (sauf graphe) +_+_ --
Arbre et graphe + ++
Tableaux simples à 1 ou 2 dimensions ++ ++
Tableaux simples à n (> 3) dimensions -(-) ++
Tableaux reliés -(-) ++
Format de sérialisation syntaxique -(-) ++
Format de sérialisation binaire --- ++
Modèle-Objet = ++
Web sémantique / OWL + +

Autres élements

Voir également : Category:Structure de données

Ontologie, modèle conceptuel de données et programmation orientée objet

Notion d'ontologie

Selon les disciplines, une ontologie peut désigner différentes approches, mais avec une notion commune de la recherche du sens et de l'essence des choses. Du point de vue informatique, celui qui nous intéresse principalement pour aborder la question des données, une ontologie est la spécification d'une conceptualisation : Il s'agit de formaliser une vue abstraite et simplifiée du monde que l'on veut étudier à travers un nombre restreint de termes pour désigner les concepts mobilisés, leurs caractéristiques, leurs propriétés, et les relations qu'ils peuvent avoir entre eux (Gruber 1993).

La définition d'un ontologie permet la mise en place d'un vocabulaire commun utilisable pour partager des informations entre différentes personnes (chercheurs, gestionnaires, ...) et avec des machines (Noy & Mcguinness, 2001). Une ontologie peut en effet être explicitées sous forme de code informatique à travers notamment le modèle conceptuel de données (voir notion suivante).

La pertinence d'une ontologie repose sur plusieurs points (Gruber 1993) : la clarté des concepts utilisés qui doivent être aussi objectifs que possible et notamment indépendants d'un contexte ; la cohérence de l'ontologie qui ne doit pas permettre d'inférer des raisonnements contradictoires ; l'extensibilité de l'ontologie et la possibilité d'ajouter de nouveaux concepts sans avoir à toucher aux fondements ; une déformation d'encodage minimale, c'est-à-dire limiter tant que possible la définition "forcée" d'un concept en modifiant son sens initial pour qu'il s'intègre dans l'ontologie ; un engagement ontologique minimal : chaque terme mobilisé ajoutant à la complexité de l'ontologie, il est nécessaire de peser l'usage de chacun pour s'assurer qu'il soit effectivement nécessaire pour décrire ce que l'on souhaite étudier. C'est un compromis en partie subjectif entre la quantité de vocabulaire utilisée que l'on souhaite minimiser et la complexité de la réalité qui peut être correctement décrite à l'aide de ce vocabulaire que l'on souhaite maximiser.

La définition d'une ontologie est le fruit d'un processus itératif dans lequel le vocabulaire est supposé, testé, validé, amélioré ... Dans leur guide, Noy & Mcguinness, (2001) dressent différents points à aborder dans ce processus. Il s'agit notamment de déterminer les concepts clefs et leur terminologie mobilisés dans le domaine d'application pour lequel on veut définir une ontologie. Il faut ensuite définir les liens entre ces concepts, leurs propriétés et les règles qui régissent ces liens et propriétés pour garantir l'intégrité des données (par exemple des règles hiérarchiques ou d'exclusion). La réutilisation d'ontologies existantes permet également de renforcer la pertinence et le caractère partagé du vocabulaire utilisé.

Une ontologie a vocation a être générique (Spyns et al. 2002). Aussi, des ontologies décrites en langage naturel peuvent être considérées comme acceptables. Toutefois, différents langages ont été développés spécialement pour la formalisation d’ontologies , comme OWL (Web Ontology Language) mobilisé à travers le web sémantique et qui permet de formaliser tout autant le vocabulaire et les propriétés, que des règles logiques entre ces différentes notions, tel que les inclusions, les contraires, les exclusions, les jonctions ... (Fléty & De 2009).

Dans la suite de nos travaux, nous nous appuierons sur ces différents afin de définir une ontologie du métabolisme territorial (voir : Ontologie du métabolisme territorial)

Modèles de données

Dans le processus d'implémentation d'un système d'information, l'ontologie permet de spécifier le vocabulaire, les liens et les règles qui permettent l'étude d'un domaine. Elle a un objectif de description générique et n'est pas nécessairement destinée à pouvoir être implémentée telle quelle dans un système d'information (Spyns et al. 2002). Des standards comme RDF ou ses dérivés visent à formaliser les ontologies pour les rendre opérationnelles. Toutefois, réaliser en même temps une description générique et un composant opérationnelle est un exercice complexe.

Les modèles de donnée ont quant à eux des objectifs plus opérationnel visant à décrire précisément l'information que l'on souhaite manipuler. Il existe habituellement trois niveaux de modèle de données, du plus abstrait au plus concret : Le Modèle Conceptuel de Données (MCD), le Modèle Logique (MLD) et le Modèle Physique (MPD).

Le premier (MCD), en raison de son niveau d'abstraction est finalement très proche de la définition d'une ontologie (Gruber 1993). La limite entre ontologie (surtout lorsqu'elles sont formalisées) et MCD n'est d'ailleurs pas forcément évidente, tous deux s'intéressant à décrire la sémantique d'un domaine (Spyns et al. 2002). La différence principale relève de l'intention : l'ontologie est plutôt orientée sur la recherche d'un consensus pour partager de l'information entre différents utilisateurs, tandis que le MCD est une première étape prescriptive pour construire la BDD d'un système d'information afin de respecter un cahier des charges (Pierra et al. 2005).

Toutefois, l'implémentation opérationnelle du modèle nécessite de prendre en compte certaines aspects supplémentaires : le typage des propriétés, la multiplicité des associations, les possibilités d'héritages, les attributs d'attributs, ...

Il y a plusieurs façons de représenter un modèle conceptuel de données, l'une des plus utilisée est le modèle entité-association


Programmation orientée-objet

Le fait qu'un Territoire hérite de MTObject signifie, dans une terminologie informatique, qu'un Territoire possède toutes les caractéristiques et propriété d'un MTObject. Les propriétés et attributs communs (comme le nombre d'attributs variable ou la possibilité d'être quantifié) n'ont ainsi pas besoin d'être implémenté pour chaque concept, mais juste une fois pour le concept général qui transmettra automatiquement ses propriétés aux autres concepts par héritage.

L'héritage, que nous utilisons dans son sens informatique, est le fait de dériver une classe dite mère pour en obtenir plusieurs dites filles. L'utilité de la démarche est de ne définir qu'une seule fois pour la classe mère les propriétés communes à toutes les classes filles. Le fait de définir un héritage va automatiquement faire bénéficier la fille de toutes les propriétés et méthodes de la mère. C'est un processus assez transparent : même s'il pose quelque difficultés pour être implémenté dans une base de données, les outils que nous utilisons permettent de s'en abstraire. C'est un gros gain en terme de programmation et permet d'éviter du code redondant.

Mapping objet-relationnel

L'utilisation d'un mapping objet-relationnel (object-relational mapping - ORM) permet d'abstraire la gestion d'une base de données au profit d’une approche orientée objet.

Dans le chapitre introductif sur les structures de données, nous avons vu qu'un système de gestion de base de données relationnels est une technologie éprouvée pouvoir stocker et extraire de grandes quantités de données (Dessaigne 2005). Toutefois, implémenter et utiliser une base de données demande une certaine expertise et la construction de requêtes peut également être complexe lorsque les liens entre les données sont nombreux.

Le paradigme de la programmation orientée objet (POO) est quant à lui plus simple et plus intuitif pour manipuler des données et leurs liens. Toutefois, le stockage des données n'est pas prédéfini dans le paradigme : libre au programmeur d'implémenter les techniques de stockage qui lui conviennent, qu'il s'agisse de sérialisation ou de faire des requêtes sur une base de données existante. Toutefois, cette liberté est plutôt une contrainte car il faut synchroniser en permanence les objets de données manipulés dans les algorithmes avec les données effectivement stockées.

Le principe du mapping objet-relationnel (ORM) permet d'utiliser une approche orientée objet pour travailler sur des données, et d'avoir de manière transparente une synchronisation de ces données avec une BDDR. Cette solution nous permet de bénéficier à la fois des techniques de stockage performants des BDDR et de l'intuitivité offerte par la POO pour le développement d'algorithme.

Entrepôts de données

Fondements

La gestion des données est un problème récurent pour les organisations. Le développement de l'informatique a toutefois permis de faciliter cette gestion et de manipuler de plus en plus rapidement les données. L'apparition des Systèmes de Gestion de Bases de Données (SGBD) dans les années 1970 y a largement contribué en permettant de rassembler en un lieu unique des données autrefois éparpillées dans différents fichiers (Inmon 2005). Les SGBD ont permis de faciliter la recherche et la mise à jour des données, ainsi que le développement d'applications. Toutefois, les capacités de calcul augmentant, la quantité de données manipulée fit de même, menant à la multiplication des bases de données au sein des entreprises. Cette multiplication, souvent menée de manière itérative sans vision d'organisation à long terme, manque parfois de crédibilité. Ainsi, Inmon (2005) met en avant les problématiques qui résultent cette multiplication "naturelle" des bases de données. Ainsi l'existence de données similaires, la définition du périmètre d'étude (temporel et qualitatif), l'intégration de données extérieures sans en spécifier la source, et l'implémentation des processus de traitement sont tout autant de facteurs qui peuvent changer et amener les analyses vers des conclusions différentes. Le prise de décision dans les entreprises qui repose sur ces conclusions est donc potentiellement instable.

Pour rendre plus cohérentes les analyses entre elles et fiabiliser le processus de prise de décisions, Inmon propose en 1991 la mise en place d'"entrepôts de données" (EDD, ou base de données décisionnelle ; en anglais, data warehouse). Le principe est assez simple : il s'agit d'une base de données centralisée qui rassemble une synthèse transversale et standardisée des données situées dans les différentes bases opérationnelles existantes de l'entreprise, sans toutefois les remplacer. A la différence d'une BDD classique, les données stockées dans un EDD n'ont pas vocation à être modifiées ou supprimées (éventuellement, elle peuvent être synthétisées à nouveau pour l'archivage). L'EDD constitue ainsi une référence unique dans l'entreprise sur lesquelles les analyses peuvent se baser pour répondre à des interrogations transversales. Cela simplifie grandement la recherche de données, réduit le risque d'incohérences et facilite la réitération des analyses dans d'autres contextes (temporels, géographiques, ...). En d'autres termes, cela permet une réduction des coûts liées à ces opérations.

L'implémentation d'un EDD repose sur la définition d'une ontologie puis d'un modèle conceptuel de données pour chacune des typologies d'information que l'on souhaite stocker (les "sujets"). Elle nécessite de définir également le niveau de détail que l'on souhaite conserver lors de l'agrégation de l'information (la "granularité"), ainsi que les standards à retenir (par exemple pour les identifiants, les dates, les localisations géographiques ...). Un EDD est souvent implémenté de manière itérative, en commençant à le rendre opérationnel pour un sujet en particulier, puis en l'étoffant au fur et à mesure avec d'autres sujets. A partir d'un certain niveau de développement, la taille et l'accès à l'EDD deviennent problématiques. S'en suit alors généralement la création de magasins de données qui vont extraire une partie des données de l'EDD selon un domaine métier particulier (finance, relation client, ...), afin de faciliter l'accès et l'usage de ces données dans le travail d'analyse.

Extracto-chargeur

L'alimentation en données d'un EDD est réalisée à travers des "extracto-chargeurs". Derrière ce mot bizarre se cachent des algorithmes visant à (1) extraire des données sources hétérogènes, généralement une base de donnée ou un tableur (2) réaliser des opérations sur ces données (conversion, nettoyage, synthèse selon une granularité donnée, ...), (3) charger les données transformées dans l'EDD. En anglais, on parle de techniques Extract / Transform / Load (ETL). Les ETL sont des éléments cruciaux pour le fonctionnement d'un EDD et leur conception peut représenter 80 % du temps de développement (Thomsen & Bach 2009).

Dans les cas les plus simples, les données sources prennent la forme d'une table, et l'opération à mener consiste à mettre en correspondance les différents champs (ou noms de colonnes) de cette table, avec le modèle de données de l'EDD, ce qu'on appelle parfois le data mapping. Dans les cas les plus simple, où les champs sont parfaitement équivalent, le travail de mise en correspondance peut être facilement réalisé avec une interface graphique (GUI - Graphic User Interface). Dans les cas les plus complexes, les opérations à réaliser sur les données avant de les charger dans un EDD sont si spécifiques qu'elles ont peu de chance d'être disponibles dans une GUI. Dans ce cas, le développement d'algorithmes de traitement de données semble plus simple pour implémenter ces opérations (Thomsen & Bach 2009).

Les ETL doivent également tenir compte de plusieurs contraintes. D'une part, il s'agit de s'assurer de ne pas charger deux fois les mêmes données dans l'EDD et de définir la périodicité de leur chargement. D'autre part, la granularité et le format des données doivent être préalablement définis et respectés dans l'implémentation des ETL.

Projets web : DBpedia et wikidata

....


Interface Homme-Machine

La mise en œuvre de la puissance de calcul des outils informatiques et la restitution des résultats s'opère à travers des interfaces.

au service de l'utilisateur

L'interface utilisateur est un composant essentiel d'un système d'information. Elle peut être graphique (GUI - Graphic User Interface) ou en ligne de commande. Elle doit permettre à l'utilisateur de mobiliser les différentes fonctionnalités du SI afin d'opérer les traitements de données (ajout, modification, consultation, analyse) pour lesquels il est conçu. L'intuitivité de l'interface est un aspect important pour faciliter le travail de l'utilisateur, ce qui amène très souvent à privilégier des interfaces graphiques. Du point de vue du développeur cependant, une interface par ligne de commande (c'est-à-dire la possibilité pour l'utilisateur d'écrire au clavier des numéro ou des noms de commande, ou bien des valeurs littérales) est bien plus simple à mettre en œuvre.

Toutefois, l'interface, bien que très pratique, est limité dans ses fonctionnalités qui doivent être pensées et implémentées a priori. Dans des domaines où les traitement peuvent être de natures très diverses, voire définis a posteriori, la liberté doit être donnée à l'utilisateur de développer ses propres fonctionnalités à travers du code informatique. Cela ouvre ainsi un horizon des possibles qui n'est limité que par "l’imagination créative de l’Homme et l’applicabilité concrète de ces lois" (Assar 2015, p.29), mais qui requiert du temps et des compétences spécifiques. Ainsi, les interfaces permettent de mettre en œuvre rapidement des traitements génériques, tandis que la possibilité d'écrire des programmes supplémentaires (sous forme de "macro", d'extension ou de module dans le cas du SINAMET) offre une grande liberté de traitement en contrepartie d'un temps de développement plus important. Une fois créé, ces programmes additionnels peuvent toutefois devenir des fonctionnalités génériques facilement accessibles par d'autres utilisateurs.

  • Les utilisateurs avancé peuvent gérer une interface textuelle, tandis que les novices privilégierons des solutions avec GUI (Thomsen & Bach 2009)

S'ils sont facilement paramétrables, ils peuvent être utilisés dans une grande variété de cas.




Références

• Assar, S., 2015, Méthodes de recherche empirique en ingénierie des SI. Principes et applications, Revue des Sciences et Technologies de l'Information - Série ISI : Ingénierie des Systèmes d'Information, 20, pp. 11-33. Lavoisier. DOI : 10.3166/isi.20.6.11-33
• Berners-Lee, T., 2006, Linked Data (mis à jour en 2010). [En ligne] URL : https://www.w3.org/DesignIssues/LinkedData.html. Consulté le 19 avril 2018.
• Delahaye, J., 2015, Les blockchains, clefs d'un nouveau monde, Pour la Science, 449, pp. 80-85. [En ligne] URL : https://www.pourlascience.fr/sd/informatique/les-blockchains-clefs-daposun-nouveau-monde-8354.php. Consulté le 19 avril 2018.
• Dessaigne, N., 2005, Le modèle DOAN (DOcument ANnotation Model) Modélisation de l'information complexe appliquée à la plateforme Arisem Kaliwatch Server.. [En ligne] URL : https://tel.archives-ouvertes.fr/tel-00465962. Consulté le 19 avril 2018.
• Fléty, Y., De Sède-Marceau, M., 2009, Vers une géo-ontologie pour les Systèmes Énergétiques Territoriaux (SET), XVIe rencontres de Rochebrune sur les systèmes complexes naturels et artificiels : ontologie et dynamique des systèmes complexes, pp. 1-12. [En ligne] URL : https://hal.archives-ouvertes.fr/hal-00767229. Consulté le 19 avril 2018.
• Flichy, P., 2013, Rendre visible l'information, Réseaux, pp. 55-89. [En ligne] URL : http://www.cairn.info/revue-reseaux-2013-2-page-55.htm. Consulté le 19 avril 2018.
• Gruber, T., 1993, A translation approach to portable ontology specifications, Knowledge acquisition, 5, pp. 199-220. Elsevier. DOI : 10.1006/knac.1993.1008
• Inmon, W., 2005, Building the Data Warehouse. Wiley, 576 p.. [En ligne] URL : http://homes.dcc.ufba.br/~mauricio052/Material_Artigo/Building_The_Data_Warehouse_(2005)_Fourth_Edition-Inmon-Wiley.pdf. Consulté le 19 avril 2018.
• Noy, N., Mcguinness, D., 2001, Ontology Development 101: A Guide to Creating Your First Ontology. [En ligne] URL : http://www-ksl.stanford.edu/people/dlm/papers/ontology-tutorial-noy-mcguinness.pdf. Consulté le 19 avril 2018.
• Pierra, G., Dehainsala, H., Ameur, Y., Bellatreche, L., 2005, Bases de données à base ontologique. Principe et mise en oeuvre, Ingénierie des Systèmes d'Information, 10, pp. 91-115
• Spyns, P., Meersman, R., Jarrar, M., 2002, Data Modelling Versus Ontology Engineering, SIGMOD Rec., 31, pp. 12-17. ACM. DOI : 10.1145/637411.637413
• Sumaray, A., Makki, S., 2012, A Comparison of Data Serialization Formats for Optimal Efficiency on a Mobile Platform, ICUIMC '12, pp. 48:1-48:6. ACM. DOI : 10.1145/2184751.2184810
• Thévenot, J., 2001, Évolution des perspectives de la conception des SI : analyse longitudinale des enjeux et des réponses méthodologiques, Systèmes d'Information et Management, 6, pp. 117-132. DOI : 10.9876/sim.v6i2.103
• Thomsen, C., Bach Pedersen, T., 2009, Pygrametl: A Powerful Programming Framework for Extract-transform-load Programmers, DOLAP '09, pp. 49-56. ACM. DOI : 10.1145/1651291.1651301

  1. Pour illustrer cela, prenons une photographie numérique du nombre 42 : les données codant l'image ne contiennent pas le nombre en lui-même, mais uniquement les pixels de l'image. C'est la lecture et l'interprétation de la photographie par une intelligence qui permettra de lire le nombre 42.
Faits relatifs à « Conception des systèmes d'information »
CiteRefCallRef needed +
KeyRefflichy2013 +, assar2015 +, thevenot2001 +, sumaray2012 +, bernerslee2006 +, delahaye2015 +, gruber1993 +, noy2001 +, spyns2002 +, flety2009 +, pierra2005 +, dessaigne2005 +, inmon2005 + et thomsen2009 +
PageLabelConception des systèmes d'information +