QlikView : principe de la base vectorielle

En matière de bases de données, on distingue les bases classiques, dites « transactionnelles », des bases « décisionnelles », telles que QlikView. Alors qu'une base transactionnelle effectue avant tout (mais pas seulement, bien sûr) des écritures et des lectures ponctuelles, une base décisionnelle est destinée à manipuler de grands volumes de données. On demande en effet à une base décisionnelle des totaux, des moyennes, des répartitions, des évolutions, etc. sur de grands ensembles de données.
Les structures de données du transactionnel ne sont pas adaptées au décisionnel. C'est la raison pour laquelle une base décisionnelle peut n'avoir qu'une lointaine ressemblance avec la base transactionnelle dont elle est issue. Il faut remodéliser.

La force d'un outil comme QlikView est d'être capable à la fois de fournir des chiffres consolidés (les ventes d'une année entière au niveau du pays, par exemple) ET de les justifier ligne à ligne. Une base classique met une éternité à produire ce genre de chose.

Bien que la structure interne de QlikView soit un secret de fabrique, le principe général de la base vectorielle est connu. On extrait les données des tables (nombres, chaînes, etc.) ; on les dédoublonne et on les numérote. Les tables ne contiennent alors plus les données directement mais leur numéro.
L'avantage d'un tel système est d'éviter de stocker deux fois la même valeur. Les répétitions sont fréquentes dans les données, de sorte que le gain est en général de 90 %.

Dans l'exemple ci-dessous, la valeur « Médecin généraliste » est stockée trois fois dans la base classique contre une fois seulement dans la base vectorielle :

Si, de plus, on a la bonne idée de trier les données (comme c'est le cas ci-dessus), comparer le numéro revient à comparer la valeur. On tient là une deuxième optimisation appréciable puisque l'ordinateur manipule les nombres beaucoup plus vite que les textes.
Bien que la structure interne de QlikView ne soit pas connue, il est probable que QlikView trie ainsi les données et ne manipule ensuite que les nombres.

Chaque champ possédant probablement un nombre de valeurs distinctes inférieur à celui de la base, il est tentant de numéroter les valeurs distinctes par champ et de garder ce numéro comme valeur de champ, étant entendu que l'on conserve alors la table de correspondance permettant de retrouver le numéro « général » à partir du numéro « du champ ».
Avantage : des nombres plus petits dans la table, nécessitant moins de bits. Ces quelques bits gagnés ne paient pas de mine mais multipliés par le nombre de lignes et de colonnes, cela fait beaucoup !

Dans la figure ci-dessous, nous voyons que le premier champ contient des numéros de 5 à 21, ce qui nécessite cinq bits de stockage (avec cinq bits on compte jusqu'à 31). Tandis qu'avec un numéro « de champ » (à droite), le même champ ne contient plus que des numéros de 1 à 6, soit trois bits de stockage (avec trois bits on compte jusqu'à 7).

La structure interne de QlikView étant encore une fois tenue secrète, nous ne savons pas si la méthode utilisée est celle ci-dessus ou une autre plus performante (sûrement). Néanmoins, nous savons que le nombre de valeurs distinctes par champ est important.

Une première conséquence à tirer de la structure de la base vectorielle est de veiller à réduire le nombre de valeurs distinctes dans sa base. Cela signifie par exemple retirer les heures des dates, si on n'en a pas besoin, voire également le jour, toujours si on n'en a pas besoin.

Une autre conséquence de la base vectorielle (nous n'irons pas plus loin dans cet article) concerne ce qu'on appelle les tables de référence, ces tables associant un code à un libellé. Dans les bases de données classiques, on a l'habitude d'en faire des sous-tables. Dans une base vectorielle, c'est à éviter !

Non seulement un tel schéma nécessite le stockage du code ET du libellé, le code n'étant pas forcément utile, mais ce schéma induit un travail supplémentaire de liaison entre tables.
La bonne façon de procéder (cela choque un peu au début !) est de stocker le libellé directement dans la table principale. Ceci est gagnant à tous points de vue : aucune donnée inutile n'est conservée (le code a disparu) et le schéma est plus simple :

Les données étant dédoublonnées selon le principe même de la base vectorielle, il n'y a aucune répétition.

Astuce : la fonction map ou applymap() de QlikView permet de substituer efficacement un libellé à un code. Attention, ne pas faire la substitution en SQL car cela gonflerait inutilement le trafic réseau.

De façon générale, remonter quelques champs d'une sous-table dans la table principale ne nuit pas, et simplifie le schéma. Stocker quelques attributs répétitifs ne nuit pas.

Une base vectorielle, telle que QlikView, change un certain nombre d'habitudes par rapport aux bases de données classiques (transactionnelles). Avec une base vectorielle, on cherche à réduire le nombre de lignes mais plus encore le nombre de valeurs distinctes.

P.-S. Le fichier qvd ne donne qu'une image indirecte de la structure du qvw, car la table est déconnectée des autres et ne peut plus partager ses données. Donc, malgré ce qui est dit ci-dessous, je penche plutôt pour une mise en commun globale des données dans le qvw, et non par table.

Je tiens à remercier TomDuBouchonProfil de TomDuBouchon pour la mise en forme de cet article et ClaudeLELOUP pour sa relecture.