Bases de données vs Entrepôts de données

Précédemment:

On a vu comment on pouvait utiliser des bases de données dans des processus d’analyse de données.

Nous avons abordé la différence entre base de données OLAP et OLTP ainsi que l’importance de distinguer base de données en production, base de données d’analyses. Nous avons abordés les processus ETL qui permettent d’alimenter les bases de données analytique de données aux formats variés.

Aujourd’hui nous allons voir comment utiliser une base de données relationnelle classique pour faire de l’analyse de données. On parle alors de bases de données ROLAP (pour relationnel OLAP)

Bases de données ROLAP

Dans la suite, nous supposons que les opérations d’analyses que nous souhaitons réalisés sont celles du Cube OLAP (rotation, projection, agrégation, désagrégation).

La table des faits contient l’ensemble des lignes bruts qui nous intéressent. Chacune de ses colonnes peut faire partie d’une dimension d’analyse et chaque dimension d’analyse peut être composé de plusieurs colonnes.

Modélisation naïve

Si la table des faits (voire cours3) est stockée telle quelle dans une table relationnelle, il est possible de faire toutes les opérations d’agrégation via de simple GROUP BY.

Réaliser des projections est très simple, il suffit de rajouter des conditions dans la WHERE clause mais agréger et desagrégé les dimensions peut rapidement devenir très compliquer.

Rappels sur les bases de données relationnelles

Dans une base de données classique sur une table T, réaliser une projection d’une vue du cube dans les dimensions d1 et d2 qui agrège selon une dimension d3 se fait simplement:

SELECT d1,d2, AGG(d3) 
FROM T 
WHERE --- ici on met les projections --- 
GROUP BY (d1, d2);

Ici, l’opération AGG doit être une opération d’agrégation supporter par la base de données. En SQLite3 il y a peu d’opération supporter (typiquement la moyenne, la somme, le nombre mais pas la médiane). Dans des logiciels plus complet, les opérations statistiques classiques sont supportées.

Par exemple dans PostgreSQL, les corrélations, covariance, et opération de régression.

Performance d’un Group By

Vous trouverez ici un notebook qui permet d’étudier la performance des GroupBy sur des tables SQLite.

Le schema en étoile

Il arrive (en fait c’est tous le temps le cas), qu’une dimension d’analyse soit l’accumulation de plusieurs colonnes de la table des faits. Par exemple, une position géographique peut être représenter un pays, une région, une ville, une adresse.

Réciproquement, certaines colonnes peuvent être dimensionnée et agréger pour augmenter ou diminuer la granularité de l’analyse.

Le schéma en étoile permet de structurer les données pour simplifier la mise en place des requêtes. Il s’agit de créer une table par dimension ou chaque colonne correspond à un niveau de granularité et de reconstituer la table des faits via une vue (matérialisée ou non) sur les dimensions.

Vous trouverez ici un notebook qui illustre la mise en étoile dans le cas de l’analyse des données sirene du TD précédant.

TD4

Reprenez le dataset openfoodfact du premier TD. Mettre en place une base de données SQLite qui réalise un schéma en étoile autours de vos dimensions d’analyses.

Compiled the: dim. 07 janv. 2024 23:18:56 CET