Un petit pas pour les données, un grand pas pour la BI

Ceux qui ont une longue expérience et une bonne mémoire s'en souviennent : le relationnel était censé permettre une prise en charge plus « naturelle » des relations entre données... et de faciliter en conséquence les relations entre l'utilisateur et les données. En pratique, il est vrai que le SQL représente un mode de communication plus maniable que d'autres interfaces de requête plus anciennes, les véritables raisons du succès de ce modèle sont ailleurs. Le modèle dit relationnel a essentiellement bénéficié d'un effet de standard, renforcé à l'époque de son décollage commercial par la croyance en la possibilité d'un modèle polyvalent de stockage et d'accès aux données, aussi efficace pour les requêtes analytiques complexes que pour le transactionnel de production.

Les années 1990, avec l'apparition du concept de data warehouse et l'explosion des applications décisionnelles (une explosion qu'aucune crise n'a arrêté depuis), ont amené la reconnaissance officielle d'une première limite. Alors qu'une application de production s'accommode parfaitement d'une structure de données basée sur des tables à deux dimensions éventuellement liées entre elles, quand il le faut, par la mécanique des clés étrangères, l'utilisateur-analyste navigue dans des univers de données multi-dimensionnels. Sur le terrain, ce constat a donné lieu à une première vague d'outils post-relationnels qu'on a regroupés derrière l'acronyme (lui-même peu significatif) d'OLAP, dont la caractéristique commune est de savoir gérer de façon native des structures de données matricielles dont le nombre de dimensions est illimité. Autrement dit des hypercubes. Il est donc devenu possible, pour l'informaticien, de mettre en oeuvre des techniques de stockage et d'accès conformes à la structure sémantique des requêtes multidimensionnelles.

Le stockage multidimensionnel natif permet de contourner le problème des performances brutes lors de l'exécution des requêtes complexes opérant selon des schémas d'analyse connus à l'avance. En revanche il ne résoud rien en matière d'autonomie des utilisateurs et de flexibilité des projets. On peut même dire que, dans beaucoup de cas, il ajoute une couche de complexité en imposant un effort de « surmodélisation » logique et physique de données, car il faut bien concevoir et implémenter les axes et les hiérarchies propres à chaque contexte d'analyse. Or la business intelligence analytique est notamment caractérisée par des besoins aussi changeants que difficiles à spécifier. C'est là qu'apparaît une seconde limite, que les outils OLAP de la fin du siècle ne sont pas conçus pour surmonter : la rigidité.

Qu'ils soient tabulaires ou multidimensionnels, et quelle que soit la puissance des stratégies d'optimisation qu'ils ont progressivement mises en oeuvre, les SGBD traditionnels ont tous au moins une caractéristique commune : la prééminence de la structure sur le contenu. En clair, cela signifie qu'ils ne peuvent prendre en charge aucune donnée, même élémentaire, que dans le cadre d'une structure déclarée à l'avance (table ou hypercube par exemple). Cette restriction vaut d'abord pour l'alimentation : on ne peut charger une donnée que dans un conteneur préalablement créé (et dont la réorganisation est toujours coûteuse, surtout quand de gros volumes sont en jeu). Elle vaut aussi, et surtout, pour l'utilisation des données, car il est impossible d'exprimer la moindre requête analytique sans connaître la logique complexe des tables et des clés étrangères, sauf à passer par des tableaux de bord ou des formulaires figés, derrière lesquels s'exécutent des requêtes SQL préalablement codées par des informaticiens. On est donc loin du compte en matière de flexibilité, et ce handicap se paie en efforts d'ingénierie aussi coûteux que récurrents.

La prépondérance de la structure, c'est-à-dire la nécessité de modéliser des conteneurs de données plus ou moins complexes avant de s'occuper du contenu, est tellement enracinée dans la culture informatique qu'elle apparaît presque comme « naturelle », alors qu'elle impose une démarche qui se situe, en réalité, aux antipodes de la pensée analytique. Spontanément, l'utilisateur s'intéresse au contenu, à la valeur. Le contenant (c'est-à-dire par exemple une table avec ses colonnes, sa clé primaire et ses clés étrangères) n'est éventuellement pertinent comme un objet intermédiaire permettant de naviguer parmi les valeurs. C'est de ce constat qu'est né le concept de SGBD « orienté valeur » ou, si on préfère, « orienté contenu ».

Comme presque toutes les inventions utiles, ce concept est finalement assez simple (l'implémentation, bien sûr, n'est pas plus simple que celle d'un SGBD classique, mais c'est le problème de l'éditeur et pas celui de l'utilisateur). Ses principes sont peu nombreux et clairement définis :

* les données sont physiquement stockées selon des structures physiques élémentaires totalement indépendantes des schémas logiques présentés à l'utilisateur ;
* ces données sont intégralement et automatiquement indexées, dans des conditions analogues à celles d'une base de données documentaire munie d'un moteur de recherche « plein texte » et sans que les index aient le moindre rapport avec les notions de table et de colonne ;
* chaque valeur (nombre, date ou texte) est stockée de manière unique, même si elle est utilisée à de multiples reprises (comme c'est souvent le cas dans les grands entrepôts de données) ;
* si une base de données est présentée à l'utilisateur sous la forme de tables composées de colonnes, voire de structures multidimensionnelles, ces objets ne sont que des vues externes, définies par des méta-données, sans rapport avec le stockage physique du contenu, susceptibles d'être créées ou supprimées par l'utilisateur lui-même sans réoganisation physique ;
* l'utilisateur (ou l'application) peut, au besoin, rechercher une valeur sans même savoir à l'avance dans quelle(s) structure(s) logique(s) elle apparaît.

Ces principes peuvent sembler peu orthodoxes au regard d'une certaine approche du génie logiciel qui veut absolument que toute exploitation d'une base de données passe par des phases de modélisation conceptuelle, logique et physique bien délimitées. En réalité, ils ne font que remettre les pendules à l'heure.

Les SGBD « rigides » (sans connotation péjorative) sont parfaitement conçus pour leur destination primaire, qui est de supporter des applications transactionnelles de production répétitives et de contrôler le respect de règles d'intégrité référentielle bien définies dans le cadre de requêtes simples. Ils demeurent tout à fait acceptables pour servir de support à la production de tableaux de bord ou de rapports de masse dont les paramètres changent mais dont la structure évolue peu.

Les systèmes orientés valeur sont en revanche beaucoup mieux adaptés aux applications analytiques dont le but est précisément la mise à disposition de moyens d'investigation dans les données et non celle d'un catalogue de restitutions figées. Ils sont à ce jour les seuls à offrir nativement un mode d'exploitation des données conforme au cheminement de la pensée de l'analyste, apportant à ce dernier un degré d'autonomie sans précédent tout en éliminant les contraintes de conception et d'optimisation communs à tous les SGBD « orientés structure ».