Big Data, Science des données, aide à la décision en entreprise, business intelligence, data warehouse, reporting, OLAP, web analytics, data visualization, data mining, internet des objets, informatique cognitive, intelligence artificielle...

Abonnez-vous gratuitement à Decideo !


Decideo

 


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


Rédigé par par Alexandre LACK le 18 Juin 2009

Les systèmes de gestion de bases de données se succèdent et, à première vue seulement, ne se ressemblent pas depuis trois bonnes décennies. Après le passage des grands ancêtres hiérarchiques ou navigationnels, le paysage a été envahi par un modèle qui domine encore aujourd'hui sans partage et qu'on a qualifié, un peu à la légère, de relationnel.



Alexandre LACK, Manager Produit, illuminate Solutions SL
Alexandre LACK, Manager Produit, illuminate Solutions SL
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 ».





Commentaires

1.Posté par Jali le 19/06/2009 13:39
hein ?
quid de la décentralisation des données sur des serveurs demandant chacun moins de ressources et ayant pourtant des capacités évolutives ? En ces temps de crise, et d'open-source est-il cohérent de penser à changer de structures pour multiplier les requêtes et le temps de processing pour outre-passer la clé primaire, plutot que de revoir l'utilité même des bases de données sur-dimensionées en les épurant et stockant sur des systèmes plus verts( et peut-être moins performant) les données moins souvent accédées. L'écologie n'est pas un point à omettre. Les BDD dynamiques d'aujourd'hui ont un système loin d'être arrivé à ses limites, la création et suppression on-demand de tables et bases entières et un point puissant des bases d'aujourd'hui.
qu'en pensez-vous ?

2.Posté par MUCKENHIRN le 23/06/2009 13:09
Ces solutions d'analyse en mémoire forment un complément, très puissant et souple aux autres outils existants en fonction des profils des analystes. Depuis 2 ans elles sont encensées. Toutefois, elles posent quelques questions :
- L'analyste se retrouve devant le modèle de données de production. On est encore souvent obligé de lui faire des structures intermédiaires.
- Ce type d'outil a tendance à recloisonner les applis décisionnelles alors qu'on vient tous de passer du temps et des investissements à les décloisonner
- Nécessité de gérer le risque de non cohérence des chiffres, voire d'anarchie d'agrégats proches et fournissant des chiffres contradictoires.
- Le travail de conception non fait en amont est à faire par l'analyste qui doit avoir un profil particulier. Ne pas mettre entre toutes les mains.

3.Posté par Francois le 25/06/2009 10:31
Entre la base de données de production et le datawarehouse, les données sont remaniées, nettoyées et filtrées grâce à un ETL ; l'analyste ne voit pas le modèle de production, il voit le modèle du DataWareHouse qui est plus propre, contient des données maîtrisées (selon les spécifications qu'il a lui-même faites à la MOA) et très orienté métier. Il n'est donc pas perdu. Il dispose des mêmes informations que celles dont il dispose déjà dans son DataMart actuel, mais sans que les hyper-cubes n'aient été prédéfinis.

Le cloisonnement dont vous parlez me semble être une façon de voir les choses. En effet, il me semble que ces solutions rapprochent le décisionnel de la production et ne s'en éloigne pas. Les analystes retrouvent immédiatement les nouvelles structures et les évolutions apportées à la production et deviennent alors des utilisateurs qui s'apparentent aux utilisateurs classiques.

Je ne comprends pas ce que vous voulez dire dans votre troisième point. En effet, les données sont moins manipulées, moins filtrées et plus représentative de l'état de la production. Si des incohérences existent en production, elles seront remontées plus directement jusqu'à l'analyste, libre à lui d'appliquer des corrections ou non, mais ces corrections ne lui sont pas imposées. D'autre part, si l'analyste estime qu'il faut appliquer certaines corrections systématiquement en amont, il reste tout à fait possible de les mettre en oeuvre, comme avec une architecture standard, dans l'ETL qui effectue le chargement du DataWareHouse.

Il ne s'agit pas de transformer un analyste en concepteur, mais de lui mettre à disposition les informations "métier" présentes dans la base de production et uniquement ces informations, en aucun cas les informations techniques. Ces nouvelles bases de données, par leur système de stockage par valeur unique, ne sont pas impactées si les données sont dénormalisées au moment du chargement, au contraire. Dans une base de données relationnelle, cela signifie une jointure entre plusieurs tables que l'on matérialise dans une nouvelle table. Cette nouvelle table sera donc dénormalisée avec de la redondance et un espace de stockage proportionnel à la jointure (pouvant aller jusqu'au produit cartésien). En revanche, dans une base avec un stockage par valeur, le stockage ne changera pas, mais l'analyste n'aura pas à effectuer l'équivalent d'une jointure (suivre une relation). Il pourra toujours effectuer ses analyses avec les hierarchies, comme il les faisait auparavant, mais plus simplement.

Il faut bien voir que ce type de base de données permet surtout de s'affranchir de la prédéfinition et du précalcul nocturne des cubes pour les enregistrer dans un DataMart. En effet, dans une architecture classique comme dans illuminate, un cube est une base de données avec un schéma en étoile. Comme les requetes ne sont pas limitées à un résultat mono-table, elles renvoient un résultat multi-table, soit un sous-ensemble de la base de données. Si la requête renvoie un schéma adapté, cela signifie que les cubes ne sont que les résultats d'une requête. L'analyste dispose donc de l'intégralité des hierarchies, des axes et des faits, libre à lui de choisir quelle hiérarchie il souhaite utiliser et quels faits il souhaite agréger.


4.Posté par pascal le 26/06/2009 14:30
- J’ai mis ce post pour réagir par rapport au discours dithyrambique sur les outils vectoriels d’analyse en mémoire ou BD orientée valeur. Par exemple, l’argument souvent mis en avant par les éditeurs de ce type de solution est que l’analyste peut directement se connecter sur une copie de la BD de production sans passer par un coûteux modèle d’entrepôt. On a parfois l’impression de revenir 20 ans en arrière avec les discours d’éditeurs du décisionnel de l’époque.
Ces outils d’analyse en mémoire sont très puissants et souples, offrent une bonne alternative aux solutions multidim existantes. Néanmoins, on ne peut baser une solution décisionnelle globale uniquement sur ce type d’outil. Ils sont complémentaires et très efficaces pour certains types d’analyse.
- Votre remarque sur la prise en compte immédiate des évols de prod est tout à fait judicieuse. Je faisais référence au cloisonnement au sein des applis décisionnelles et pas à celui entre décisionnel et le SI de prod. Une des clés du décisionnel est de croiser de façon transverse les informations faisant sauter, dans le travail d’intégration de l’entrepôt de données, les cloisonnements amont éventuels entre les applis. Le risque, via une utilisation sans précaution de ces outils, est d’avoir des analystes qui créent des tas d’indicateurs dans leur coin sans partage des règles de gestion avec les autres.
- Je ne parlais pas des incohérences issues du SI de prod. Je parlais de celles issues de la multiplication des calculs des indicateurs dans un contexte de SI décisionnel global d’entreprise. Par exemple quelqu’un calcule le nombre de déclarants en prenant en amont toutes les occurrences jusqu’au dernier jour ouvré du mois et un autre effectue le calcul d’un indicateur équivalent en prenant toutes les occurrences jusqu’au dernier jour calendaire du mois, WE compris. Les solutions d’analyse en mémoire ont tendance, si aucune précaution n’est prise, à faciliter ce phénomène. Cela rejoint le point sur le décloisonnement.

5.Posté par Jali le 02/07/2009 04:04
Je rejoins complétement Pascal, notamment sur le point concernant le cloisonnement. Mais peut-être est-ce encore en train de changer.

6.Posté par Patrick le 08/07/2009 11:39
Parler des SGBDR comme des "structures rigides" non "orientées valeurs" est une affirmation péremptoire, prétentieuse et totalement incorrecte qui discrédite l'article de Monsieur Lack. Dommage car il y a un discours moins dogmatique à tjs et encore confirmer sur la cohabitation intelligente des technologies SGBDR/ROLAP et MOLAP.

Nouveau commentaire :
Facebook Twitter

Vous pouvez commenter ou apporter un complément d’information à tous les articles de ce site. Les commentaires sont libres et ouverts à tous. Néanmoins, nous nous réservons le droit de supprimer, sans explication ni préavis, tout commentaire qui ne serait pas conforme à nos règles internes de fonctionnement, c'est-à-dire tout commentaire diffamatoire ou sans rapport avec le sujet de l’article. Par ailleurs, les commentaires anonymes sont systématiquement supprimés s’ils sont trop négatifs ou trop positifs. Ayez des opinions, partagez les avec les autres, mais assumez les ! Merci d’avance. Merci de noter également que les commentaires ne sont pas automatiquement envoyés aux rédacteurs de chaque article. Si vous souhaitez poser une question au rédacteur d'un article, contactez-le directement, n'utilisez pas les commentaires.