Création du référentiel unique de données

Je vais présenter ici le développement et l’implantation du référentiel unique de données.

La dispersion des données utilisateur dans le système d’information était le premier point dur à résoudre dans l’optique de la mise en place les nouveaux concepts. Source de données unique et socle technique d’offre des nouveaux services, ce référentiel se devait de recenser les données du système de façon exhaustive et cohérente.

2.2.1. Identification des données existantes

Les données existantes étaient réparties, pour les utilisateurs, dans l’annuaire LDAP, et pour les stations de travail, dans la base GLPI. Il a fallu analyser les données sources de chaque application et en extraire les données utiles.

L’application GLPI, par exemple, disposait de sa propre base de données dont l’information utile concernant les stations de travail n’était contenue que dans une vingtaine de tables sur les 160 que comptait le progiciel.

La méthode que j’ai appliquée pour extraire les données de cette application de gestion de parc a été d’effectuer une retro conception (« reverse engineering ») de la base de données, d’analyser le contenu de chaque table ainsi que leurs dépendances afin d’obtenir le schéma relationnel initial. Une fois le schéma logique et conceptuel établi, j’ai pu vérifier les dépendances fonctionnelles de la base et identifier toutes les tables contenant les données utilisateurs.

La seconde partie des données, orientées utilisateur, se trouvait dans l’annuaire LDAP en production. Il s’agissait plus exactement d’inventorier les données d’identification des utilisateurs (nom, prénom, login, etc.) parmi l’ensemble des données structurelles de l’annuaire LDAP.

Ces deux actions m’ont permis d’obtenir une liste exhaustive des champs et des données détenus par le système, que j’ai recensée dans un tableau de données. J’ai ensuite, pour les types de données, supprimé les doublons et complété ce tableau avec les nouveaux types nécessaires aux nouveaux développements.

Ce processus de nettoyage et de recensement a permis de créer le dictionnaire de données qui a servi de base à l’étape de modélisation du schéma de la nouvelle base de données unifiée.

2.2.2. Modélisation du schéma de la base de données

Pour effectuer la modélisation du schéma de la nouvelle base, plusieurs réunions regroupant l’ensemble des personnels du service informatique ont été organisées afin de réaliser une modélisation optimale. Ces réunions se sont déroulées d’abord sur le modèle de réunion de type « brainstorming » (remue-méninges) afin d’essayer de compléter le dictionnaire de données, puis sur des réunions de modélisation de base de données.

Après plusieurs discussions, le service informatique a pu développer un schéma adapté à l’environnement du laboratoire d’astrophysique.

La nouvelle base de données, regroupant l’ensemble des données du système, a été développée après plusieurs raffinages successifs, en s’appuyant sur les étapes itératives de la méthode Merise (Méthode d’Etude et de Réalisation Informatique pour les Systèmes d’Entreprise). L’utilisation de cette dernière nous a permis d’établir le schéma entités-associations, de créer le modèle conceptuel des données (MCD), d’en déduire les modèles logique et physique des données (respectivement MLD et MPD). Voici le modèle conceptuel de données du prototype, modèle représentatif du schéma de la base (hormis les contraintes d’intégrité) :

Figure 8 : Modèle conceptuel des données du prototype

Sur ce modèle conceptuel des données, il ressort visuellement qu’il existait deux familles distinctes de données utilisateur :

Les données concernant le compte de l’utilisateur et ses caractéristiques (partie gauche) : nom, prénom, login, répertoire personnel, etc. principalement extraites des annuaires LDAP.

Les données concernant les matériels de l’utilisateur (partie droite) : type de matériel, caractéristiques techniques du matériel, etc. principalement extraites du serveur GLPI.

Une fois ce modèle défini, nous avons généré nos modèles logiques et physiques de données.

Dans cette phase de prototypage, le choix du système de gestion de bases de Données (SGBD) s’est naturellement porté, pour des raisons de continuité et d’expertise, vers le progiciel MySQL1.

Pour finir, j’ai installé ce progiciel sur les serveurs dédiés au prototype et créé la base et les tables correspondantes au MPD établi.

1

2.2.3. Alimentation de la nouvelle base de données

A partir des actions décrites dans les paragraphes précédents, il restait à alimenter la base du prototype avec un processus d’importation des données réparties dans le système existant. Pour ce faire, j’ai procédé successivement aux étapes de création d’une base temporaire, de récupération et de traitement des données existantes et d’intégration dans le référentiel unifié.

Utilisation d’une base de données temporaire

Lors de cette première étape, pour simplifier ce processus de traitement, j’ai privilégié l’utilisation d’une base temporaire. Cette dernière avait comme structure un ensemble de tables qui reflétaient, de façon exhaustive, l’organisation de l’existant. Plus concrètement, nous avions une table pour chaque source issue du LDAP, DHCP, DNS et une table par type de données pour GLPI (utilisateur, machines,…). A partir de scripts, développés en langage Perl, j’ai procédé à l’extraction des données des services en production et les ai intégré dans les tables temporaires correspondantes.

Qualification des données et intégration dans la base définitive

A ce stade, la base de données regroupait la collecte exhaustive des données utilisateur du système sans cohérence ni qualification, ce qui permettait de travailler sur les données sans incidence sur le système en production.

Le regroupement des données brutes a mis en évidence les problèmes identifiés par l’équipe informatique, i .e. des doublons d’information, des données incohérentes entre les services, des informations périmées ou manquantes, etc.

Afin de qualifier ces données, j’ai développé de nouveaux scripts (Perl) permettant de les intégrer après traitement vers la base du prototype. Ce processus automatisé de qualification et de mise en cohérence a été précédé d’une validation manuelle, notamment pour le traitement des informations obsolètes.

Le résultat obtenu était une base de données unique et cohérente, contenant l’ensemble des informations présentes de façon dispersée dans le système d’information en production.

A ce stade, nous disposions d’une source unique d’informations à jour et pouvions désormais développer les scripts d’alimentation de nos services et les IHM associées.