Discussion :

[TomDuBouchon]

Bonjour,

yvesduc vous présente ce nouvel article sur le principe de la base vectorielle sur QlikView.

La puissance de QlikView tient dans sa base vectorielle, technique consistant à séparer les tables et les données. Toutefois, ceci a des conséquences sur la modélisation.

En le remerciant et en vous souhaitant une bonne lecture.

[yimson]

Merci Yves, pour cette brillante intervention.

J'ai travaillé pour une SSII avec Qlikview pendant environ huit (08) mois. Je peux t'avouer que le fait que QLIKVIEW soit tres propriétaire était la réelle difficulté au départ. Au cours du temps, j'ai pu appréhendé certains concepts.
Ce document vient vraiment à point nommé pour ce qui voulaient se lancer dans l'univers QLIKVIEW.

[nvannier]

Le fait de "dénormaliser" les tables (en supprimant ainsi les tables de référence) pour en faire une seule permet aussi d'utiliser une fonctionnalité très utile de QlikView : la "fréquence".

C'est intéressant dans les listes de sélection : on peut afficher la fréquence d'une valeur, et même trier par ordre décroissant de fréquence, ce qui permet rapidement de voir quelles sont les valeurs prépondérantes dans les données, en un seul coup d'oeil. Par exemple le nombre de "Médecin généraliste" serait 3 dans l'exemple ci-dessus. Alors que si les tables de référence n'étaient pas dénormalisées, on aurait toujours une fréquence de 1 pour toutes les valeurs.

Autre point intéressant pour les tables de référence : j'ai l'habitude d'utiliser des listes de sélection avec le code ET la valeur (séparés par un trait d'union), comme ça l'utilisateur peut choisir des 2 façons : soit il connait le code, soit il connait la valeur, dans les 2 cas ça fonctionne.

[aspire]

Je viens de lire l'article sur Qlickview, produit que je ne connaissais pas mais dont j'ai entendu parlé.
Et je suis assez déçu des "explications" peu convaincantes pour ne pas dire approximatives ou fausses.
Dans la 1ere partie on comprend le principe de la "base vectorielle", mais je trouve la comparaison avec la table SQL très mal choisie et non probant : évidement cette table est mal conçue il faut ajouter 2 relations, une pour les villes et une pour les activités. Cela évite d'office les redondances en espace. De plus l'auteur masque totalement le DDL sous-jacent a la structure le SQL (dérivé de l’algèbre linéaire théorie la + utilisé depuis les années 70 aujourd'hui encore).
D'où mon interrogation sur les requetes QlickView ? (en comparaison du langage de requetage sql qui fait toute la force des sgbdrs.)
La 2eme conséquence me semble tout aussi peu claire : on n'a pas " l'habitude de faire des sous-tables dans les bases classiques" comme dit l'auteur mais on les conçoit avec des DF (dependance fonctionnelle) !
J' ai l'impression, enfin plutôt la certitude que toute la théorie liée aux sgbrd est totalement ignorée de l'auteur. C'est très dommage lorsqu'on se dit capable de comparer les 2 systèmes.

PS: 2^3 = 8 valeurs codées différentes et non 7.

[yimson]

Bonjour Aspire,

Je viens de lire l'article sur Qlickview, produit que je ne connaissais pas mais dont j'ai entendu parlé.
Et je suis assez déçu des "explications" peu convaincantes pour ne pas dire approximatives ou fausses.
Dans la 1ere partie on comprend le principe de la "base vectorielle", mais je trouve la comparaison avec la table SQL très mal choisie et non probant : évidement cette table est mal conçue il faut ajouter 2 relations, une pour les villes et une pour les activités. Cela évite d'office les redondances en espace. De plus l'auteur masque totalement le DDL sous-jacent a la structure le SQL (dérivé de l’algèbre linéaire théorie la + utilisé depuis les années 70 aujourd'hui encore).
D'où mon interrogation sur les requetes QlickView ? (en comparaison du langage de requetage sql qui fait toute la force des sgbdrs.)
La 2eme conséquence me semble tout aussi peu claire : on n'a pas " l'habitude de faire des sous-tables dans les bases classiques" comme dit l'auteur mais on les conçoit avec des DF (dependance fonctionnelle) !
J' ai l'impression, enfin plutôt la certitude que toute la théorie liée aux sgbrd est totalement ignorée de l'auteur. C'est très dommage lorsqu'on se dit capable de comparer les 2 systèmes.

Je te comprends parfaitement. Tu es un aguerri du monde SQL avec des tables respectant les formes normales de base (1FN, 2FN, 3FN, ...), du moins je pense

Il faut noter que dans le monde des bases de données, il en existe deux grands courants: les bases de données décisionnelles et les bases de données transactionnelles.

Chacune d'elles a un objectif précis à atteindre, respectivement, l'une est dimensionnée pour optimiser les accès aux données, et l'autre est dimensionnée pour optimiser les insertions et les mises à jour. Tu remarques bien que les deux modes ne fonctionnent pas de la même façon mais ce sont des bases de données.

Autrement dit, dans les bases de données décisionnelles, on sera amené à effectuer beaucoup de SELECT, d'où il faut optimiser la base pour accélérer les opérations de recherche, et dans les bases de données transactionnelles, on va faire beaucoup de INSERT et UPDATE, le but n'étant pas de rechercher l'information, mais d'en créer et de mettre à jour au besoin.

Parfois pour atteindre cet objectif visé par les bases de données décisionnelles, on est souvent amené à violer les règles fondamentales de modélisation de données. D'où ces notions que tu as pu lire dans l'article.

Il faut noter que les bases de données vectorielles implémentées dans Qlikview se retrouvent dans le groupe des bases de données décisionnelles. Qlikview est un outil conçu pour faciliter l'aide à la décision, donc il est optimisé pour faciliter l'accès à l'information et la présenter sous forme de graphique, diagrammes, histogrammes, camemberts et autres représentations graphiques existantes. C'est un outil de Business Intelligence.

J'espère avoir apporté quelques éclaircissements.