Poly BDM

Bases de données multidimensionnelles
et mise en œuvre dans Oracle
1 Introduction et Description générale

Les bases de données relationnelles sont très performantes pour les systèmes opérationnels
(ou transactionnels) qui constituent ce qu’on appelle les systèmes OLTP (On-Line Trans-
actional Processing). Ces bases de données sont destinées à des systèmes effectuant de nom-
breuses requêtes pas très complexes et très répétitives touchant une quantité faible de données
(en nombre de tables), par exemple pour gérer un stock. De très nombreux opérateurs ont
alors accès à ces requêtes de mise à jour (par exemple l’ensemble des employés du magasin
dont on gère le stock). Ces systèmes de production ne permettent pas d’effectuer efficacement
des analyses de données. On distingue alors ces premiers sytèmes OLTP des stystèmes OLAP
(On-Line Analytical Processing) proposés par Codd (1993) qui sont eux destinés à peu
de personnes (dirigeants, analystes) effectuant de manière moins fréquente des requêtes com-
plexes d’analyse mettant en jeu de très gros volumes de données stockés dans des entrepôts de
données. Ces analyses sont dites multidimensionnelles puisqu’elles permettent l’analyse
d’un fait (par exemple les ventes) en fonction de dimensions (par exemple la ville, le produit
et le mois de vente).
Si les systèmes relationnels sont efficaces pour l’OLTP (robustes, performants et sécurisés),
ils se sont révélés insuffisants pour les systèmes OLAP. Se sont alors développés des systèmes
de gestion de bases de données multidimensionnelles. Cependant, ces systèmes ne permettaient
pas de gérer de très gros volumes de données de manière aussi efficace que les SGBD classiques
relationnels, on se dirige donc maintenant de plus en plus vers des systèmes relationnels-OLAP.
Pour résumer :
OLTP OLAP
(transactions) (analyse)
Taille des données concernées faible (quelques n-uplets) importante (millions de n-uplets)
Fréquence des requêtes souvent peu souvent
Utilisateurs agents opérationnels (nombreux) analystes/décideurs (peu nombreux)
Granularité détail résumé
Requêtes simples et répétitives complexes et non prévisibles
Accès lecture/écriture lecture
Optique production et mise à jour optique décisionnelle
Le lien entre OLTP et OLAP se fait dans le processus général de vie des données. Les
requêtes OLAP se font sur les données stockées (dans l’entrepôt de données) alimentées par
des données sources produites par des requêtes OLTP, comme le montre la figure 1.
Les outils E.T.L. correspondent à:
• Extract : accès aux données sources. Le langage de requêtes est différent selon le type de
données (données structurées BD relationnelles, non structurées, semi-structurées XML).
• Transform : transformation pour homogénéiser (formatage, nettoyage des données, par
exemple pour exprimer toutes les distances dans la même unité)
1
Figure 1: Processus complet. OLTP-OLAP
• Load : chargement dans l’entropôt

La mise à jour de l’entropôt (refresh) est coûteuse et se fait de manière régulière, par exemple
toutes les nuits. Elle peut être incrémentale ou nécessiter le recalcul de tout l’entrepôt.
On appelle magasin de données un sous-ensemble de données sur un sujet particulier.
Par exemple, si l’entrepôt de données décrit l’ensemble des données d’une entreprise, on pourra
proposer un magasin pour le service facturation, un pour le service du personnel, etc.
Ces magasins servent à analyser les données à travers différents techniques, comme par
exemple le reporting (édition de rapports d’analyses statistiques), la fouille de données (data
mining), la visualisation, ou encore les requêtes what if qui décrivent ce qui se passerait si telle
ou telle action était entreprise (par exemple si on augmentait les salaires de 2%).
Quand Codd a proposé le modèle OLAP (1993), il a décrit 12 règles qu’un tel système soit
permettre :
1. modèle (multi)dimensionnel
2. transparence du serveur pour l’utilisateur
3. accessibilité des données
4. performances d’accès stables
5. architecture client-serveur
6. dimensionnalité générique
7. gestion des données éparses
8. multi-utilisateurs
9. opérations sur les dimensions
2
10. manipulation intuitive des données
11. souplesse d’affichage et d’édition
12. dimensions et niveaux multiples
Cependant, ces règles sont faussées par le fait que Codd travaillait pour un éditeur de
système OLAP et qu’elle décrivent donc ce système commercial !
On peut donc se référer au modèle FASMI : Fast Analysis of Shared Multidimensional
Information. Les réponses doivent donc être rapides, le système doit fournir des outils d’analyse
numériques et statistiques, l’architecture doit être multi-utilisateurs et offrir une vue multidi-
mensionnelle des données, quels que soient leur volume et leur mode de stockage.
Jusqu’à présent, il n’existe aucun consensus, pas de modèle ou de langage standard.
Bibliographie :
http://www.olapreport.com
http://www.billinmon.com
Codd, Providing OLAP (On-Line Analytical Processing) to User-Analysts: An IT Mandate,
Arbor Software White Paper, 1993.
R. Kimball, The Datawarehouse Toolkit, John Wiley & Sons, 1996.
2 Entrepôts de données
Pour Inmon, un entrepôt de données (Data Warehouse - DW) est : subject-oriented, integrated,
time-variant, and non volatile collection of data in support of management decision making pro-
cess. Les données sont donc historisées, maintenues et matérialisées (stockées physiquement).
Cette collection de données constitue un ensemble homogène (à partir de données hétérogènes,
très nombreuses et distribuées), exploitable (pour un processus de décision). Pour R. Kimball,
un entrepôt de données est a copy of transaction data specifically structured for query and
analysis.
Il existe deux schémas principaux possibles pour la modélisation de l’entrepôt : le schéma
en étoile et le schéma en flocon.
Quel que soit le modèle considéré, on distinguera la table des faits qui contient l’information
à analyser (par exemple les ventes) des tables de dimensions qui contiennent les informations
sur les dimensions d’analyse (par exemple le lieu, le temps, la description du produit).
2.1 Schéma étoile (Star Schema)

Ce type de schéma est décrit sur la figure 2. La table des faits contient les clés étrangères vers
les tables de dimension. L’ensemble de ces clés étrangères forment la clé primaire, la table
des faits étant en BCNF. Les tables de dimension quant à elles ne sont pas normalisées. Un
exemple est donné sur la figure 3.
2.2 Schéma en flocon (Snowflake Schema)

Dans ce modèle, les tables de dimensions sont normalisées pour constituer une structure
hiérarchique (c.f. figure 4). Ceci a pour avantage de faciliter la maintenance des tables de
dimension et de réduire la redondance, cependant il faudra calculer des jointures coûteuses.
Un exemple est donné sur la figure 5.
3
Figure 2: Schéma en étoile
Figure 3: Schéma en étoile : exemple
4
Figure 4: Schéma en flocon
5
Figure 5: Schéma en flocon : exemple
6
Figure 6: Cube de données
Figure 7: Hiérarchies simple et multiple
3 Cubes de données
Le modèle multidimensionnel sur lequel s’appuie OLAP permet la définition d’hypercubes de
données (appelés cubes par abus de langage) afin de faire valoir la représentation dimensionnelle
des données. À partir des schémas étoile et flocon, on construit les cubes de données, comme
indiqué figure 6. Pour des raisons évidentes de visualisation, cet hypercube n’a que trois
dimensions, il faut l’imaginer en k dimensions.
Une base de données multidimensionnelle est un ensemble d’hypercubes définis le long
de dimensions. Ces dimensions peuvent être munies de hiérarchies. On distingue alors les
hiérachies simples des hiérarchies multiples, comme indiqué sur la figure 7. Le niveau ALL
correspond à l’agrégation totale, comme illustré sur la figure 8.
La mesure désigne le contenu des cellules de l’hypercube. La mesure peut être additive,
semi-additive ou non additive :
• Mesure non additive : on ne peut pas sommer les valeurs des cellules en conservant un
sens. Par exemple, si le cube contient des moyennes de ventes par mois, produit et ville,
il n’y a pas de sens à sommer les valeurs des cellules des villes pour les regrouper en
départements.
7
Figure 8: Hiérarchies : niveau ALL
Figure 9: Treillis des cuboı̈des pour les 4 dimensions A, B, C, D
• Mesure semi-additive : on peut sommer sur certaines dimensions en gardant un sens mais
pas sur toutes. Par exemple, si on considère un cube décrivant l’état des stocks par ville,
produit et mois, il est possible de faire la somme sur les dimensions ville et produit pour
connaı̂tre l’état global des stocks pour toutes les villes ou pour tous les produits, mais il
n’y a aucun sens à sommer sur la dimension temporelle des mois.
• Mesure additive : on peut sommer sur toutes les dimensions tout en conservant un sens.
Par exemple, si l’on considère les sommes des ventes par produits, villes et mois, on peut
faire la somme des valeurs des cellules tout en conservant un sens aux données.
La construction des hypercubes nécessite :

• le choix des dimensions d’analyse,
• le choix de la fonction d’agrégation,
• et la définition de la requête.
On parle du treillis des cuboı̈des pour décrire l’ensemble des cubes qu’il est possible de
construire à partir d’un modèle ayant plusieurs dimensions. La figure 9 décrit l’ensemble des
hypercubes qu’il est possible de construire à partir de quatre dimensions A, B, C et D.
La fonction d’agrégation pour la construction des cubes est l’une des fonctions classiques
comme AVG, SUM, MIN, MAX, ... Le niveau d’agrégation doit être soigneusement déterminé.
En effet, il indique le niveau de détail auquel les utilisateurs pourront accéder sans qu’il soit
nécessaire de réaccéder aux données sources. Mais un niveau trop détaillé entraı̂ne un cube
volumineux.
La requête de construction est de la forme suivante :
8
select dim1, ..., dimk, AGREGATION
from table_faits, table_dim1, ..., table_dimk
where [jointure]
Group By dim1, ... , dimk
[Having ...] ;
Par exemple, la construction du cube de la figure 6 serait la suivante :
select Mois, Ville, Produit, SUM(Quantite)

from vente, TMois, TLieu, TProduit
where Vente.IDProduit = TProduit.IDProduit
AND Vente.IDLieu = TLieu.IDLieu
AND Vente.IDDate = TMois.IDDate
Group By Mois, Ville, Produit ;
4 Opérations sur les cubes de données

Les hypercubes sont munis de différentes opérations réparties selon qu’elles ont trait à :
• la visualisation des données (aucune modification sur le contenu),
• la navigation le long des hiérarchies de dimensions,
• la sélection des données
On rappelle qu’il n’existe pas de modèle consensuel et donc pas d’ensemble d’opérations
défini pour tous les systèmes. Cependant, il existe un certain nombre d’opérations couramment
admises comme étant essentielles décrites ci-dessous.
4.1 Visualisation des données

On considère ici les deux opérations principales : la rotation et l’inversion.
La rotation (rotate/pivot) permet d’examiner le cube selon un autre angle (voir figure 10)).
Un cube de dimension n a n(n − 1) vues. Par exemple un cube de dimension 3 a 6 faces.
PIVOT/ROTATE
12 42
(rotation)
12 42 42 42
35 18 37 42
35
16 3
Figure 10: rotation
L’inversion (switch) consiste à inverser l’ordre de certaines valeurs (figure 11). Certaines
informations se retrouvent alors placées l’une à côté de l’autre, ce qui facilite la découverte
d’un phénomène.
9
SWITCH
12 42 12 42
12 42 42 (inversion) 12 42 42
35 18 37 18 35 37
35 35
16 3 16 3
Figure 11: Inversion
4.2 Navigation le long des hiérarchies

La généralisation (roll-up décrite figure 12 revient à généraliser les valeurs d’un attribut à des
concepts de niveau supérieur (passage au granule supérieur). On peut par exemple calculer la
moyenne sur plusieurs valeurs de dimensions. Le roll-up(*) ou roll-up global calcule l’agrégation
sur toutes les valeurs, on n’a plus qu’une cellule contenant, par exemple, la moyenne générale1.
La spécification (drill-down), à l’inverse du roll-up, est une opération de spécialisation
(passage au granule inférieur).
ROLL-UP
12 42 21 17,7 20 42
(generalisation) 42
12 42 42 21 17,7 20 42
35 18 37
35
16 3
Figure 12: Roll Up
4.3 Sélection
Il existe deux types de sélection : sur les cellules et sur les dimensions.
4.3.1 Sélection sur les cellules (Slice)

La restriction (figure 13) consiste à extraire de l’information résumée pour une certaine dimen-
sion.
On ne retient alors que les valeurs correspondant à un certain critère, par exemple toutes
les valeurs inférieures à 15.
4.3.2 Sélection sur les dimensions (Dice)

Il s’agit d’une restriction sur les dimensions et non plus par rapport à un critère sur la mesure
(voir figure 14).
1 La fonction d’agrégation peut tout aussi bien être la somme, la médiane ... ou une fonction plus complexe
10
SLICE
12 42 12
(restriction)
12 42 42 12
35 18 37
35
16 3 3
Figure 13: Sélection sur les cellules
DICE
12 42 12
(projection)
12 42 42 12
18
35 18 37 35 18
35
35 35
16 3 16
Figure 14: Sélection sur les dimensions
5 Stockage physique
Le principal problème posé pour le stockage des cubes de données est leur nature peu dense,
éparse (sparsity), de très nombreuses cellules étant vides. Il existe trois stratégies de stockage
physique : le stockage sous la forme relationnelle (ROLAP), sous la forme multidimensionnelle
(MOLAP) ou une solution hybride (HOLAP) combinant ces deux première approches.
5.1 ROLAP
On nomme ROLAP l’approche Relationnel OLAP. Les données sont stockées sous la forme
de tables relationnelles. Elles sont modélisées sous la forme de schémas en étoile ou flocon.
Les requêtes multidimensionnelles doivent alors être traduites en requêtes relationnelles (SQL).
Ce modèle est excellent vis à vis de la capacité de stockage, mais les requêtes sont difficiles à
définir et à mettre en œuvre et sont coûteuses.
5.2 MOLAP
On nomme MOLAP l’approche Multidimensionnelle OLAP. La technologie de stockage
est multidimensionnelle. Les données sont stockées sous la forme de tableaux multidimension-
nels, des index multidimensionnels sont définis. Cette tecnologie de stockage nécessite donc
des techniques de compression face à la faible densité des données (sparsity). La taille des
données pouvant être ainsi stockées est faible par rapport à la solution ROLAP. Cependant,
les requêtes sont écrites de manière intuitive et efficace. Toutefois, il faut redéfinir un langage
de manipulation des données alors qu’il n’existe aucun consensus ni technologie reconnue et
vraiment établie.
5.3 HOLAP
On nomme HOLAP l’approche Hybride OLAP. Cette technologie combine les deux solutions
précédentes. Les données détaillées sont stockées dans une base de données relationnelle, et les
données agrégées dans une base multidimensionnelle.
11
5.4 Systèmes commerciaux
Produit Editeur Type
Essbase Arbor Software MOLAP
DB2 OLAP Server IBM ROLAP/MOLAP
Metacube Informix ROLAP
SQL Server (2000) Microsoft ROLAP
Express Server Oracle MOLAP
9i OLAP Oracle ROLAP/MOLAP
5.5 Précalcul des agrégats

Il est possible, selon les systèmes, de calculer les agrégats à différents niveaux de granularié dans
les hypercubes. Ne rien précalculer constitue bien évidemment un gain de place mais réduit
considérablement les performances. A l’inverse, tout stocker rend le système performant mais
nécessite un espace de stockage très important. Un stockage partiel peut alors être envisagé,
mais il pose le problème du choix judicieux des précalculs à effectuer.
6 Mise en œuvre dans Oracle

Historiquement, Oracle s’est lancé dans les systèmes OLAP à travers le logiciel ORACLE
Express suite au rachat d’Hyperion. Ce système, très orienté MOLAP et externe au noyau
oracle 8i, a nécessité la définition d’un langage de définition, d’un langage de manipulation
et d’un système de stockage multidimensionnel. Des outils d’analyse et de programmation
étaient fournis. Même si la manipulation des données était facile et efficace, Oracle Express ne
permettait le stockage de données volumineuses.
Avec la version Oracle 9i, Oracle a décidé d’intégrer les fonctionnalités OLAP au sein
du noyau du SGBD. Des fonctionnalités liées aux entrepôts de données (vues matérialisées
de gros volumes de données modélisés sous la forme d’un schéma en étoile ou flocon) sont
présentes. Il est possible de créer des dimensions, des cubes. Ces cubes sont interrogés entre
autres via un langage de manipulation OLAP propriétaire (OLAP DML). Les bases de données
multidimensionnelles sont des Analytic Workspaces qui contiennent un ou plusieurs cubes, des
méta-données (dimensions, hiérarchies), ... Les cubes y sont persistants ou calculés seulement
pour la durée d’une session. Les informations sont stockées dans le OLAP CATALOG. L’accès
aux données multidimensionnelles est possible via SQL à travers des vues, via le langage OLAP
DML, ou via la Java OLAP API.
Les clauses GROUP BY CUBE, GROUP BY GROUPING SETS et GROUP BY ROLLUP
permettent de construire des cubes en ayant le détail des agrégats. La fonction SUM est utilisée
pour agréger les données.
SELECT ...
GROUP BY ... {CUBE | ROLLUP| GROUPING SETS} (dimension_column) ;
ROLLUP calcule des sous-totaux ainsi que le total général, toutes données confondues.
Il est possible d’effectuer des ROLLUP partiels.
GROUP BY expr1, ROLLUP(expr2, expr3);
CUBE calcule tous les sous-totaux des combinaisons possibles des colonnes. Si n attributs
sont spécifiés dans la clause CUBE, il y aura 2n combinaisons de sous-totaux calculés. CUBE
calcule plus de sous-totaux que ROLLUP.
De même que précédemment, il est possible d’effectuer un GROUP BY CUBE partiel.
12
GROUP BY expr1, CUBE(expr2, expr3)
La fonction RATIO TO REPORT calcule le ratio d’une valeur par rapport à une somme
d’un ensemble de valeurs. Une valeur NULL est traitée comme un zéro pour le calcul de la
somme.
RATIO_TO_REPORT ( expr ) OVER ( [query_partition_clause] )
Exemple :
SELECT ch.channel_desc, TO_CHAR(SUM(amount_sold),’9,999,999’) AS SALES,

TO_CHAR(SUM(SUM(amount_sold)) OVER (), ’9,999,999’) AS TOTAL_SALES,
TO_CHAR(RATIO_TO_REPORT(SUM(amount_sold)) OVER (), ’9.999’)
AS RATIO_TO_REPORT
FROM sales s, channels ch
WHERE s.channel_id=ch.channel_id AND s.time_id=to_DATE(’11-OCT-2000’)
GROUP BY ch.channel_desc;
CHANNEL_DESC SALES TOTAL_SALE RATIO_

-------------------- ---------- ---------- ------
Direct Sales 14,447 23,183 .623
Internet 345 23,183 .015
Partners 8,391 23,183 .362
Les fonctions RANK et DENSE RANK permet de retourner le rang d’une valeur parmi
une liste de valeurs. On peut alors par exemple retourner les n meilleurs (requêtes Top-N) ou
les n moins bons (requêtes Bottom-N). La différence entre RANK et DENSE RANK est que
DENSE RANK ne laisse pas de trous dans les rangs quand il y a des ex-aequo.
RANK ( ) OVER ( [query_partition_clause] order_by_clause )

DENSE_RANK ( ) OVER ( [query_partition_clause] order_by_clause )
Exemple :
SELECT channel_desc, TO_CHAR(SUM(amount_sold), ’9,999,999,999’) SALES$,

RANK() OVER (ORDER BY SUM(amount_sold)) AS rang,
FROM sales, products, customers, times, channels, countries
WHERE ... [jointure] ...
GROUP BY channel_desc;
CHANNEL_DESC SALES$ RANG

-------------------- -------------- ------------
Direct Sales 2,443,392 3
Partners 1,365,963 2
Internet 467,478 1
Il est possible de créer des vues matérialisées :
CREATE MATERIALIZED VIEW [schema.]materialized_view options

[USING INDEX index_options]
[REFRESH [refresh_options]] [FOR UPDATE] [{ENABLE|DISABLE} QUERY REWRITE]
13
Les options de rafraı̂chissement permettent de définir si le rafraı̂ssement se fait ou non
automatiquement, et s’il se fait automatiquement à quels moments il doit s’effectuer. Par
exemple :
CREATE MATERIALIZED VIEW Vue_OLAP

REFRESH START WITH SYSDATE NEXT SYSDATE+1
ENABLE QUERY REWRITE
AS
SELECT ... , COUNT(*)
FROM ...
WHERE ...
GROUP BY ... ;
On force le rafraı̂chissement de la manière suivante :
begin
dbms_mview.refresh(’olapv_emp’);
end;
/
La création de dimensions est possible :
CREATE DIMENSION [schema.]dimension level_clause(s)

[hierarchy_clause(s) attribute_clause(s)];
Il doit y avoir au moins une clause hiérarchie ou attribut. La clause LEVEL a la forme
suivante :
LEVEL level IS (table.column,...)
La clause hiérarchie a la forme suivante :
HIERARCHY hier (child_level CHILD OF parent_level,... [join_clause])
La clause attribut a la forme suivante :
ATTRIBUTE level DETERMINES (dependent_column,...)
La clause join a la forme suivante :
JOIN KEY (child_key_column,...) REFERENCES parent_level
Par exemple :
CREATE DIMENSION customers_dim

LEVEL customer IS (customers.cust_id)
LEVEL city IS (customers.cust_city)
LEVEL state IS (customers.cust_state_province)
LEVEL country IS (countries.country_id)
LEVEL subregion IS (countries.country_subregion)
LEVEL region IS (countries.country_region)
HIERARCHY geog_rollup (
customer CHILD OF
city CHILD OF
state CHILD OF
14
country CHILD OF
subregion CHILD OF
region
JOIN KEY (customers.country_id) REFERENCES country )
ATTRIBUTE customer DETERMINES
(cust_first_name, cust_last_name, cust_gender, cust_marital_status,
cust_year_of_birth, cust_income_level, cust_credit_limit)
ATTRIBUTE country DETERMINES (countries.country_name) ;
On peut vérifier la validité de la dimension créée :
EXEC DBMS_OLAP.validate_dimension(’customers_dim’,USER,FALSE,FALSE);
SELECT table_name,
dimension_name,
relationship,
bad_rowid
FROM mview$_exceptions;
15

Poly BDM

Transféré par

Droits d'auteur :

Formats disponibles

Poly BDM

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Poly BDM

Transféré par

Droits d'auteur :

Formats disponibles

Bases de données multidimensionnelles

et mise en œuvre dans Oracle

1 Introduction et Description générale

• Load : chargement dans l’entropôt

2.1 Schéma étoile (Star Schema)

2.2 Schéma en flocon (Snowflake Schema)

Figure 3: Schéma en étoile : exemple

Figure 7: Hiérarchies simple et multiple

Figure 9: Treillis des cuboı̈des pour les 4 dimensions A, B, C, D

La construction des hypercubes nécessite :

Par exemple, la construction du cube de la figure 6 serait la suivante :

select Mois, Ville, Produit, SUM(Quantite)

4 Opérations sur les cubes de données

4.1 Visualisation des données

Figure 10: rotation

Figure 11: Inversion

4.2 Navigation le long des hiérarchies

Figure 12: Roll Up

4.3.1 Sélection sur les cellules (Slice)

4.3.2 Sélection sur les dimensions (Dice)

Figure 13: Sélection sur les cellules

Figure 14: Sélection sur les dimensions

5.5 Précalcul des agrégats

6 Mise en œuvre dans Oracle

GROUP BY expr1, ROLLUP(expr2, expr3);

RATIO_TO_REPORT ( expr ) OVER ( [query_partition_clause] )

SELECT ch.channel_desc, TO_CHAR(SUM(amount_sold),’9,999,999’) AS SALES,

CHANNEL_DESC SALES TOTAL_SALE RATIO_

RANK ( ) OVER ( [query_partition_clause] order_by_clause )

SELECT channel_desc, TO_CHAR(SUM(amount_sold), ’9,999,999,999’) SALES$,

CHANNEL_DESC SALES$ RANG

Il est possible de créer des vues matérialisées :

CREATE MATERIALIZED VIEW [schema.]materialized_view options

CREATE MATERIALIZED VIEW Vue_OLAP

On force le rafraı̂chissement de la manière suivante :

La création de dimensions est possible :

CREATE DIMENSION [schema.]dimension level_clause(s)

CREATE DIMENSION customers_dim

On peut vérifier la validité de la dimension créée :

Vous aimerez peut-être aussi