Modélisation des données : tout savoir pour tirer le maximum de vos données

Steve Hoberman est l'auteur de plusieurs ouvrages sur les techniques de modélisation de données, dont le plus récent : Data Modeling for MongoDB: Building Well-Designed and Supportable MongoDB Databases.

Steve Hoberman est également consultant et formateur en modélisation des données. A ce titre, il a formé plus de 10 000 personnes dans le monde.

Dans cet échange avec TechTarget/LeMagIT, il décrit les principales difficultés rencontrées par les entreprises qui souhaitent créer des modèles de données. Il fournit également plusieurs conseils techniques qui vous aideront à développer des modèles de données plus efficaces et plus précis pour les applications opérationnelles et décisionnelles, notamment celles exécutées sur des bases de données NoSQL comme MongoDB.

LeMagIT / TechTarget : Comment une entreprise décide-t-elle de la meilleure forme à adopter pour ses modèles de données ? Vous expliquez que cela dépend du public visé : pouvez-vous préciser quels modèles fonctionnent mieux pour quels publics ?

Steve Hoberman : Le modélisateur doit en effet faire preuve d'une certaine souplesse quant à la forme visuelle du modèle. Il est parfois difficile de ne pas recourir à une notation de modélisation traditionnelle.

Lorsque vous travaillez avec des rôles de développement d'applications dont l'intitulé de la fonction contient les termes « données », « développeur » ou « base de données », il est tout à fait possible d'utiliser la notation traditionnelle avec formes géométriques et traits, comme la notation d'ingénierie de l'information (cf. la notation en « patte de corbeau ») ou l'UML (Unified Modeling Language). Pour ces rôles, j'applique systématiquement cette notation aux trois niveaux de modèle : conceptuel, logique et physique.

Pour les rôles dont l'intitulé contient le mot « métier » (ou « business ») il importe avant tout de vérifier si le public est à l'aise avec la notation traditionnelle de modélisation des données.

Parfois, ce public composé d'utilisateurs professionnels, d'analystes métier, etc. connaît déjà cette forme traditionnelle ou a envie de l'apprendre. Mais il peut aussi être judicieux de l'éviter et de la remplacer par une notation qu'ils comprennent.

Par exemple, utilisez des feuilles de calcul si vous travaillez avec des experts financiers, ou encore des images : ainsi, la photo d'un entrepôt représentera le concept d'entrepôt.

LeMagIT / TechTarget : Quelles sont les principales difficultés rencontrées par les entreprises qui créent un modèle de données ? Comment les éviter et les résoudre ?

Steve Hoberman : La plus grande difficulté consiste à rendre correctement les besoins dans le modèle de données.

En début de projet, ces besoins sont souvent vagues (voire inexistants), et le modèle doit les représenter intégralement et fidèlement. Il est donc très difficile de transformer ce flou, ou cette ambiguïté, en quelque chose de précis. Il faut poser de nombreuses questions et documenter les résultats dans le modèle.

Cela demande du temps et une bonne connaissance des questions à poser, deux paramètres qui manquent souvent à l'équipe du projet pour répondre à ces questions.

La modélisation des données consiste à collecter des informations sur l'entreprise et son activité, or c'est un processus chronophage et complexe.

LeMagIT / TechTarget : alors que de nouvelles utilisations de la modélisation se popularisent, par exemple dans le domaine de l'atténuation des risques et de la rétro-ingénierie, en quoi le rôle du modélisateur a-t-il évolué pour s'adapter ?

Steve Hoberman : En ce qui concerne la rétro-ingénierie, au lieu de partir de zéro et d'élaborer les modèles de données d'après de nouvelles spécifications système, nous organisons les attributs et les règles selon le mode de fonctionnement actuel des systèmes.

La démarche et les livrables sont donc les mêmes, qu'il s'agisse d'un nouveau développement ou d'une rétro-ingénierie ; c'est le point de départ qui diffère.

Avec l'atténuation des risques et la rétro-ingénierie, notre rôle s'apparente souvent à celui d'un « archéologue de données » : nous menons de véritables enquêtes de détectives pour déterminer la signification d'un champ système existant et ses relations avec d'autres champs.

LeMagIT / TechTarget : Pouvez-vous recommander une méthode permettant de garantir la précision en cas de conflit dans les définitions et spécifications ?

Steve Hoberman : Il existe plusieurs techniques efficaces. Je décrirai brièvement les deux que je préfère.

Je connais une modélisatrice qui écrit ses propres définitions avec une telle précision qu'elle sait pertinemment que toutes sont incorrectes. Puis elle les soumet à l'entreprise pour correction. D'après elle, il est plus facile pour un utilisateur métier de corriger une définition existante que d'en créer une de toutes pièces.

D'autres modélisateurs préfèrent que les équipes de développement définissent les termes avant de les nommer. Pour nommer un concept, il faut savoir ce que c'est. Il est donc logique de le définir, puis de le nommer.

Ces deux approches permettent d'élaborer des définitions précises très efficacement.

LeMagIT / TechTarget : Quelles sont les principales différences, en termes de modélisation, entre une base de données relationnelle et une base NoSQL ?

Steve Hoberman : Avec un SGBDR (système de gestion de base de données relationnelle), la structure de la base de données ressemble souvent au modèle logique de données. Les différences entre un SGBDR et son modèle logique sont dues principalement aux modifications impliquant les performances ou les outils.

Avec une base de données NoSQL, en revanche, la conception de la base peut s'écarter radicalement du modèle logique en termes de structure.

LeMagIT / TechTarget : En quoi la nature des bases de données NoSQL, sans schéma ou avec un schéma allégé, affecte-t-elle le processus de modélisation des données ?

Steve Hoberman : Les bases de données NoSQL permettent de créer des champs à mesure que des données sont ajoutées (c'est ce qu'on appelle une base de données « sans schéma » ou « à schéma allégé »).

Il est ainsi plus facile de créer un prototype et de construire la base de données de manière itérative avant de terminer (voire parfois de commencer) le modèle de données.

Dans certains cas, la conception de la base de données est entièrement réalisée avant que les modèles logiques et conceptuels ne soient créés à des fins de documentation et de support. Par conséquent, un environnement sans schéma peut permettre l'adoption d'une approche ascendante (partant du modèle physique).

LeMagIT / TechTarget : En prenant le temps de créer un modèle de données, de quels avantages peut bénéficier une entreprise ou quelles complications peut-elle éviter ?

Steve Hoberman : Créer un modèle de données permet avant tout de rendre les données compréhensibles, autrement dit lisibles et exploitables par les utilisateurs.

Grâce à un tel document, qui décrit les données avec une grande précision, les entreprises bénéficient d'avantages tangibles : elles réduisent les coûts de développement et de support, et se dotent de systèmes de qualité performants et conformes aux spécifications.