De la gestion de données aux systèmes d'information

Temps estimé de lecture : 20 min

Objectifs

Objectifs pédagogiques visés :
- Quel est l’historique des enjeux et du développement des techniques autour des bases de données et des systèmes d’information ?

Objectifs pédagogiques visés :
- Comprendre les problématiques liées à l’accès concurrent aux données
- Comprendre la notion de système d’information

Les débuts du développement de l’informatique

Les premiers défis

Suite à la Seconde Guerre mondiale, le développement de l’informatique a très vite posé le problème de la conservation et de l’accès aux données.

À cette époque-là, un des principaux défis était la conservation et l’intégrité des données. Encore aujourd’hui et à titre individuel, vous souvenez-vous de la dernière fois que vous avez perdu les contacts de votre téléphone portable ? Imaginez s’il s’agit du fichier client d’une entreprise ! Il fallait donc éviter qu’une panne de courant intervenant pendant un traitement laisse les données stockées dans un état inconnu, ou qu’un incendie détruise définitivement les données accumulées (exigeant des solutions complexes au niveau de la sauvegarde).

Le deuxième défi résidait dans les temps d’accès, compte tenu de la taille des mémoires : quelques centaines d’octets pour des données stockées qui occupaient déjà quelques méga-octets (un catalogue de produits, 1 liste d’employés, 1 série de virements à effectuer, etc.).

La gestion des accès concurrents

Avec le développement des systèmes d’exploitation à temps partagé, dans lesquels les utilisateurs accédaient « presque » simultanément aux ressources, s’est posé le problème de la gestion de l’accès concurrent aux données par différents utilisateurs ou différentes applications, spécialement quand ceux-ci modifiaient les données.

Aujourd’hui, les propriétés exigées en cas d’accès concurrents sont bien connues et désignées par l’acronyme ACID (Atomicité, Cohérence, Isolation, Durabilité). Elles caractérisent la notion de transaction. Le cadre transactionnel a sans nul doute été un des éléments fondateurs des systèmes de gestion de bases de données (SGBD) actuels [Boudjlida 1999].

Dans les années soixante, l’apparition d’ordinateurs « mainframe » intégrant directement dans leurs systèmes d’exploitation des mécanismes transactionnels a répondu aux besoins de performances d’une informatique de gestion essentiellement caractérisée par un très fort « débit transactionnel » (nombre de transactions par seconde). Poussés par des acteurs riches et influents (par exemple les banques) et leurs applications exigeantes en terme de débit transactionnel (applications OLTP pour On Line Transaction Processing), évalués par des organismes indépendants (le Transaction Processing Council a précisément comme mission de concevoir de tels benchmarks http://www.tpc.org), les grands constructeurs informatiques ont affiné les technologies associées, donnant naissance aux moniteurs transactionnels, un secteur aujourd’hui encore extrêmement actif.

L’indépendance des données

Cependant, le cadre transactionnel ne traite pas tous les aspects liés au partage des données. Rapidement, le principe d’indépendance des données (data independance) vient compléter l’approche transactionnelle afin de dissocier les questions de performances d’accès de celles de modélisation des données et de personnalisation. La modélisation permet aux utilisateurs de manipuler des concepts évolués (des ventes, des produits …) sans savoir comment les octets sont stockés sur le disque, tandis que la personnalisation leur permet de n’avoir accès qu’aux données qui leur sont utiles. Ce principe a trouvé son aboutissement avec les SGBD relationnels (SGBDR), qui constituent encore aujourd’hui la principale famille de systèmes de gestion de bases de données. Ses fondements théoriques ont été définis dans les années 70, puis implantés à partir des années 1980, et servent de référence à la quasi-totalité des SGBD actuels [Elmasri 2004].

Soutenu par un langage standardisé, SQL (qui depuis son apparition en 1986, a considérablement évolué pour prendre en compte les besoins de l’industrie), le modèle relationnel s’est imposé dans le domaine de la gestion de données persistantes fortement structurées (typiquement représentables sous la forme de tableaux). Moins performants que les seuls moniteurs transactionnels, mais permettant de “comprendre” les données, ces systèmes constituent un des outils de base de toute application manipulant des données persistantes. La quasi-totalité des SGBD présents dans les entreprises, systèmes commerciaux (parmi lesquels SQL server, Oracle, ou Sybase ) ou systèmes libres (MySQL, PostgreSQL, etc.), repose sur le modèle relationnel et SQL. Peu à peu, ces systèmes, tout en respectant le standard SQL, ont mis en place des environnements plus ou moins riches pour monitorer les données, tuner les performances du système, gérer son évolution, etc.

Les années 90

Apparition de nouveaux modèles

Depuis les années 90, de nouveaux types d’applications sont apparus, leurs exigences sont différentes : exigences transactionnelles moins fortes par exemple, mais exigences de distribution ou de disponibilité bien plus fortes. Du côté des données à représenter, stocker et manipuler, de nouveaux modèles sont également apparus : XML (eXtended Markup Language) s’est imposé à la fois comme un standard de représentation des documents structurés (pas seulement des tableaux) et d’Internet ; RDF (Resource Description Framework) est un modèle permettant de représenter les annotations. Récemment, le souhait de stocker des données issues de capteurs a fait émerger le besoin d’intégrer des probabilités dans les bases de données. Des contraintes matérielles ou architecturales spécifiques posent également de nouveaux enjeux (BD embarquée sur une carte à puce, base de données dans le Cloud) sur le plan de la performance et de la sécurité.

La multiplication des applications

Du côté des entreprises, les SGBD, outils techniques de gestion des données, sont totalement banalisés, mais la gestion des données de l’entreprise reste, elle, tout à fait actuelle. Les applications se sont multipliées, selon les besoins des utilisateurs, le plus souvent sans réel contrôle de leur cohérence avec le parc applicatif existant. Dans une ère industrielle où vitesse et restructurations (filialisations, regroupements, rachats, etc.) allaient ensemble, la gestion d’un parc d’applications hétérogènes utilisant des bases de données désynchronisées était devenue un véritable enjeu pour les entreprises. Alors que le contexte économique de concurrence leur demandait d’adapter en permanence leur stratégie, les informations nécessaires pour définir cette stratégie étaient enfouies dans des bases de données éparpillées, manipulées par des logiciels mal maitrisés, peu flexibles, péniblement mis à jour au fil du temps, et dont les interdépendances avec d’autres logiciels n’étaient pas connues.

Dans cette jungle logicielle, les seuls résumés d’information, les « tableaux de bord », étaient obtenus en allant récupérer les données au cœur des bases de données, en espérant que ces données soient les bonnes (la multiplication des bases introduisant des désynchronisations difficiles à corriger). Les entrepôts de données (datawarehouse en anglais) constituent une approche basée sur les données pour l’aide à la décision dans l’entreprise. Traitées, corrigées, consolidées, les données de ces entrepôts viennent alimenter les tableaux de bord des décideurs, à tous les niveaux de l’entreprise : les problèmes de gestion de données pour l’analyse (OLAP pour On Line Analysis Processing) ont progressivement dominé ceux de l’OLTP, mais si le contexte change, les données restent un élément clé de la survie de l’entreprise.

La gestion de l’information

De fait, à la problématique de la gestion de données, même réelle, s’est substituée celle de la gestion de l’information d’entreprise, que l’on pourrait simplifier à la gestion des données de l’entreprise vues sous l’aspect métier. Finalement, il n’y a que depuis quelques dizaines d’années que toutes ces données sont informatisées.

Le terme de système d’information (SI) désigne « le système constitué des ressources humaines, des ressources matérielles et des procédures permettant d’acquérir, de stocker, de traiter et de diffuser les éléments d’information pertinents au fonctionnement d’une entreprise ou d’une organisation » (Office québécois de la langue française, 2004).

Tandis que, pendant les années 90, les politiques de qualité, orientées vers la satisfaction du client, viennent structurer les métiers de l’entreprise sous la forme de processus (enchaînement d’activités à exécuter pour répondre à un objectif et donner satisfaction à son client, interne ou externe à l’entreprise), la production et le transit de l’information au sein de l’entreprise deviennent un élément primordial de l’organisation du SI.

Après de nombreuses années dédiées exclusivement aux données et au développement d’applications, l’architecture [Hainaut 2015] s’impose petit à petit comme élément structurant du SI, déterminant en grande partie sa capacité à évoluer ou non au fil des évolutions et des restructurations. Le recensement des applications composant le système d’information (cartographie) et la maitrise de leurs interactions sont devenus un des premiers objectifs des Directions de Systèmes d’Information (DSI), qui ont peu à peu remplacé les services informatiques dédiés au développement et à la maintenance des années 70-80. En sous-traitant l’essentiel de leur développement, et en utilisant massivement des progiciels, tels que les progiciels de gestion intégrés (PGI, ou ERP en anglais pour Enterprise Resource Planning), ces DSI se concentrent sur la maitrise du parc applicatif et la gestion de la sous-traitance, sur la qualité et le coût de ses propres prestations vis-à-vis des services-métier de l’entreprise (marketing, conception, construction, etc.) devenus leurs clients et, plus récemment encore, sur l’accroissement de la « flexibilité » du système d’information, c’est-à-dire, sur sa capacité à évoluer rapidement pour répondre efficacement aux futurs besoins de l’entreprise.

C’est en prenant en considération ces exigences que doivent être analysés les progrès de l’informatique, tant sur le plan des technologies que des méthodes.

Références

Boudjlida, Bases de données et systèmes d’information, pages 1 à 10, chapitre 3, 1999 Emprunter

Elmasri, Conception et architecture des bases de données, pages 85 à 101, chapitre 4, 2004 Emprunter

Hainaut, Bases de données : concepts, utilisation et développement, pages 13 à 51, chapitre 2, 2015 Emprunter