pourquoi un benchmark comparatif sql versu multivalué est inutile pour savoir qu e le MV est superieur

Les bases de données relationnelles représentaient les données dans de
simples tables à deux dimensions ; un moyen efficace de représenter une
quantité importante de données d'une manière facilement compréhensible
par les programmeurs. Avec SQL, les bases de données relationnelles
instaurèrent un langage d'accès aux données standard. Leur structure
logique et physique, indépendante des applications, était compatible
avec de nombreuses applications d'entreprise.
Toutefois, la théorie relationnelle reposait en partie sur l'idée que
les données et les programmes qui les utilisaient, pouvaient et devaient
être indépendants les uns des autres. Cette idée était et reste
contradictoire avec le concept même de la technologie multivalué. La
technologie multivalué encourage le développeur à percevoir les données
comme des ensembles de données et non comme des tables. Par ailleurs,
les ensembles de données et les méthodes qui les utilisent ne sont pas
indépendants les uns des autres.

Prenons le cas d'une voiture en tant qu'ensemble de données. Lorsque
vous utilisez cette voiture, vous l'utilisez intégralement, comme une
même entité ; comme un ensemble.Maintenant, de nombreuses activités
(méthodes en terminologie ) sont associées à la voiture. Par exemple,
vous la manoeuvrez, vous changez de vitesse, vous mettez les
clignotants, vous allumez les feux, etc. Si la voiture est un ensemble,
ces activités représentent les méthodes de l'ensemble et lui sont
essentielles. Il est absurde de dissocier ces activités de la voiture.
Lorsque vous rentrez votre voiture dans un garage, vous la garez comme
une même entité, avec toutes ses fonctions. En aucun cas, vous ne garez
votre voiture dans le garage et stockez ses fonctions de direction, de
transmission, de signalement et d'allumage des feux ailleurs. Les
données et les processus associés ne peuvent et ne doivent pas être
dissociés ; c'est le cas dans les bases de données multivalué.
En réalité, ces deux points de vue présentent des avantages et des
inconvénients.
Certains processus sont réellement indépendants des données. C'est
notamment le cas des requêtes qui accèdent à d'importants jeux de
données. Une requête se contente de sélectionner les données en fonction
d'un ensemble de critères et ne se préoccupe pas de leur contenu ou de
la manière dont elles sont organisées, dès lors qu'elles peuvent
être extraites rapidement. Les requêtes sont indépendantes des données,
mais les méthodes d'un ensemble ne le sont pas.

Limites des bases de données relationnelles
Les bases de données relationnelles offrent moins de possibilités
qu'elles ne le laissent penser. Le stockage et la représentation de
structures de données, aussi ordinaires soient-elles, peuvent être assez
difficiles. Prenons l'exemple d'un itinéraire de bus, qui correspond en
fait à une simple liste ordonnée des arrêts du bus. Les bases de
données relationnelles ne conservent les tables que sous la forme de
listes non ordonnées et ne peuvent extraire une liste ordonnée que si un
index spécialement généré a été ajouté. Une base de données multivalué,
quant à elle, gère parfaitement les listes ordonnées et ne requiert
aucun index, ce dernier n'étant créé artificiellement qu'en raison des
limites des structures des données relationnelles.
Prenons maintenant l'exemple d'une nomenclature, soit un produit et ses
composants dans un système de fabrication. Les composants peuvent
eux-mêmes posséder d'autres composants qui à leur tour peuvent également
posséder des composants et ainsi de suite. Une table de base de données
relationnelle répertoriant l'intégralité des composants ne représente
pas la relation entre les composants et leurs sous-composants,
etc. Ces relations représentent des données importantes. La recherche
d'un produit et de tous ses composants dans une base de données doit
être sans équivoque. La structure d'une base de données relationnelle
complique inutilement le travail du développeur, qui consiste à répondre
à cette simple requête.

Les exemples de ce type abondent : une carte, ses routes, ses
rivières et ses points de repère ou encore un site Web et toutes ses
pages, ses liens et ses graphiques. En fait, plus l'ensemble
d'informations est complexe, plus il existe de niveaux hiérarchiques et
de relations croisées et moins il est possible de représenter ces
informations dans les structures de table simples d'une base de données
relationnelle. Les bases de données multivalué ne connaissent pas de
telles limites étant donné qu'elles ont été conçues pour résoudre les
problèmes de ce genre.
Malgré la maturité des produits de base de données relationnelle et la
croissance spectaculaire de la puissance des ordinateurs au cours de la
dernière décennie, nous entendons toujours parler de projets qui
échouent car les performances de la base de données relationnelle
utilisée sont tout simplement insuffisantes. Cela provient
généralement de la manière dont les bases de données relationnelles
stockent les données. Pour pouvoir assembler les données dont ils ont
besoin, les développeurs doivent souvent créer plusieurs jointures
(requêtes JOIN) d'une table à une autre, puis à une autre et ainsi de
suite. Pour extraire les données, la base de données exécute
des routines d'optimisation afin de déterminer le meilleur moyen de
collecter les données, puis de les extraire. Ce processus prend souvent
un certain temps et peut avoir un impact négatif sur les performances.
Les optimiseurs de base de données relationnelle ont eu beau s'améliorer
avec le temps, leurs performances restent bien inférieures à celle des
bases de données multivalué.

Bases de données relationnelles et défaut d'impédance
Le problème des bases de données relationnelles réside dans le fait
qu'elles utilisent une table à deux dimensions comme structure de
données de base. Selon la théorie relationnelle, les données sont
censées être organisées en tables normalisées ; les données doivent être
organisées de telle sorte qu'il n'existe qu'un seul moyen d'y accéder.
Le développeur peut ainsi éliminer tout risque de redondance et garantir
la cohérence des modifications apportées aux données. Cette technique de
conception a été proposée afin que les tables relationnelles contiennent
des jeux de données indépendants associés uniquement par l'intermédiaire
d'une clé. Elle provient directement de la théorie des ensembles, mais
cette théorie ne permet malheureusement pas de représenter toutes les
relations et les structures des données.
Le stockage des données sous une forme normalisée nécessite souvent que
le programmeur désassemble un ensemble pour le stocker dans la base de
données, puis l'assemble à nouveau à l'aide de requêtes SQL (plusieurs
requêtes JOIN) afin de l'utiliser. Si vous garez une voiture dans un
garage, cela revient à démonter les portes, les sièges, les roues, etc.
Cela prend du temps et ne présente aucun intérêt.
Ce problème est apparu lorsque les langages OO ont commencé à s'imposer.
Il est généralement décrit comme l' erreur d'impédance objet-relationnel
qui représente la différence entre les approches utilisées par les
langages OO et les bases de données relationnelles pour accéder aux
données et les problèmes résultants que le programmeur doit résoudre. En
réalité, la plupart des bases de données relationnelles ne sont pas
entièrement normalisées lors de leur implémentation,
mais cela n'empêche pas les problèmes d'erreur d'impédance, ce qui
complique la tâche du développeur. Des estimations montrent en effet que
les développeurs de programmes OO utilisant des bases de données
relationnelles passent entre 25 et 40 % de leur temps à écrire un code
mappant les objets aux tables relationnelles.

SQL fut alors amélioré pour permettre les appels à l'équivalent
relationnel des "méthodes multivalué".
Cette approche ignore complètement la théorie relationnelle des données,
mais elle permet de définir des ensembles complexes (cartes, graphiques
vectoriels, photographies et même des tables complètes) dans une
structure relationnelle et de les conserver comme entités. Ces
fonctionnalités furent donc implémentées et devinrent même des marques.
Chez Informix, les processus imbriqués étaient des DataBlades, tandis
que chez Oracle, il s'agissait de Cartridges. Il était donc possible de
stocker des ensembles sans avoir recours à des bases de données
multivalué, mais le principal problème restait à résoudre. En effet les
bases de données Relationnel connaissent toujours le problème d'erreur
d'impédance.

base données multivalué versus bases de données
relationnelles
En pratique, les bases de données multivalué présentent des avantages
considérables par rapport aux bases de données relationnelles :
L'exécution est beaucoup plus rapide pour les applications
transactionnelles.
Elles gèrent de manière bien plus efficace les ensemble complexes.
Elles permettent aux développeurs d'obtenir une meilleure productivité.
Elles sont faciles à administrer.
Dans certains cas, les bases de données multivalué ont remplacé les
bases de données relationnelles pour des raisons de performances. Cette
tendance se retrouve même dans certaines applications d'entreprise à
grande échelle qui ne nécessitent pas le stockage d'ensemble complexes
(opération qui semblerait pourtant relever du domaine des bases de
données relationnelles).
Le principal avantage des bases de données multivalué en matière de
performances est le suivant : contrairement aux bases de données
relationnelles, les bases de données multivalué n'ont généralement pas
besoin d'assembler les données pour pouvoir les utiliser.
Elles ont tendance à stocker les données sous leur forme la plus
couramment utilisée, ce qui permet généralement d'améliorer les
performances. Les bases de données multivalué peuvent implémenter des
stratégies de mise en mémoire cache ; ainsi, les données
sont plus susceptibles de se trouver en mémoire lorsqu'elles sont
demandées. Ces bases ne requièrent qu'une optimisation limitée pour
l'extraction des données.
A mesure que de nouveaux systèmes sont développés, le besoin de
manipuler des données complexes, telles que des documents, des
graphiques sophistiqués, des pages Web et des fichiers multimédia,
continue d'augmenter et ces types de demande sont mieux traités par les
bases de données multivalué.

Conclusion

il se peut que les bases de données relationnelles continuent de dominer
le marché des bases de données et que les bases de données multivalué ne
quittent pas la niche qu'elles se sont créées, mais il est également
possible que la part de marché de ces dernières augmente à mesure
qu'elles parviennent davantage à gérer les ensembles complexes utilisés
de nos jours.
.....
Copyright 2003, 2004 Baroudi Bloor International, Inc.
Ce document a été rédigé par Robin Bloor de la société Baroudi Bloor,
une société spécialisée en recherche, analyse et conseil stratégique
dans le domaine de l'informatique.
Robin Bloor est Directeur de la Recherche chez Baroudi Bloor
International Inc et Président de Bloor
Research., l'un des leaders mondiaux en conseil et analyse informatique
offrant des services de recherche et d'analyse aux utilisateurs et
fournisseurs informatiques, partout dans le monde. Vous pouvez le
contacter à l'adresse suivante : robin@baroudi.com.