Entrepot

1. Modélisation d’un
Entrepôt de données
Préparé par: Dr. Olfa DRIDI
FSB – Département Informatique GLSI2

2. 2
Stockage

3. 3
Stockage
Ø ROLAP : Relational OLAP
Ø MOLAP : Multi-Dimentional OLAP
Ø HOLAP : Hybrid OLAP
Ø DOLAP : Desktop OL AP

4. 4
Plan
1. Introduction aux systèmes OLAP
2. Systèmes ROLAP
• Introduction à la technologie ROLAP
• Techniques d’indexation ROLAP
• Sélection et matérialisation de vues
• Fragmentation de tables
• Forces et faiblesses de la technologie ROLAP
• Quelques produits de technologie ROLAP
3. Systèmes MOLAP
• Introduction à la technologie MOLAP
• Techniques de stockage
• Densité et compression
• Agrégation et calcul des agrégats
• Forces et faiblesses de la technologie MOLAP
• Quelques produits de technologie MOLAP
4. Systèmes HOLAP
• Introduction à la technologie HOLAP
• Quelques produits de technologie HOLAP

5. 5
Les règles de Codd pour les produits OLAP
En 1993 Codd définit les bases du modèle OLAP : 12 règles de Codd définissent
l’évaluation des produits OLAP :
1. Vue multidimensionnelle : Une base OLAP offre une vue multidimensionnelle des
données
2. Transparence: éléments techniques mis en œuvre invisibles pour l’utilisateur
3. Accessibilité: la complexité et l’hétérogénéité des données sont masquées par les outils
OLAP
4. Stabilité: performances stables indépendamment du contexte d’analyse
5. Architecture Client/Serveur : le coté serveur a en charge l’homogénéisation des
données, les clients se connectent simplement au serveur
6. Traitement générique des dimensions : une seule structure logique pour toutes les
dimensions. Tout calcul effectué sur une dimension peut l’être sur les autres
7. Gestion dynamique des matrices creuses : gestion dynamique de la mémoire physique
nécessaire pour stocker les données non nulles
8. Support multi-utilisateurs : gestion des accès concurrents aux données
9. Croisement des dimensions
10. Manipulation intuitive des données
11. Flexibilité des restitutions
12. Nombre illimité de niveaux d’agrégations et de dimensions

6. 6
ROLAP (Relational OLAP)
Ø OLAP relationnel
Ø Données obtenues à partir de tables relationnelles et de jointures entre
celles-ci
Ø En fonction de la granularité́, la requête générée est plus ou moins
complexe
Ø A chaque consultation, la requête est recalculée
Les résultats ne sont pas stockés
Ø Langage : SQL
Ø Avantages
Faible coût (car tire partie des ressources existantes)
Ø Inconvénients
Temps de réponse long car sollicitation de la base à chaque relance
d’un rapport

7. 7
MOLAP (Multi-Dimentional OLAP)
Ø OLAP multi-dimentionnel
Ø DonnéesstockéesdansunebasededonnéesmultidimentionnelleappeléeCUBE
Exemple : Essbase...
Ø Plus de relationnel!
Ø Tous les croisements possibles sont précalculés
Restitution des données instantanée
Ø Langage : MDX
Ø Avantages
Temps de réponse très court (toutes les données et résultats sont stockés)
Ø Inconvénients
Coût élevé des licences pour les bases multi-dimentionnelles
Coût élevé de développement des cubes
Difficile à mettre en place pour les gros volumes de données, à cause de
tous les résultats précompilés

8. 8
HOLAP (Hybrid OLAP)
Ø Association du ROLAP et du MOLAP
Ø Concept de Drill-Through
Accès aux données agrégées avec MOLAP (Cube)
Accès aux détails avec le ROLAP (tables relationnelles) Étapes :
Données agrégées stockées dans une table multi-dimentionnelle o
Restitution de ces données à partir d’un outil de reporting
Ø Affichage des données agrégées extraites à partir des tables multi-
dimentionnelles Affichage des détails des opérations issus des bases
relationnelles
Ø Avantages
Temps de réponse assez court
Moins coûteux que MOLAP car moins de développement
Ø Inconvénients
Ne pourra pas être utilisé si les rapports sont trop complexes et font trop de
croisements de données

9. 9
DOLAP (Desktop OLAP)
Ø Ce n’est pas une technologie de stockage, mais un mode de
fonctionnement.
Ø Base de données OLAP limitée en taille.
Ø Permet à l’utilisateur d’enregistrer une partie de la base de données
multi-dimentionnelle en local.

10. 10
Conception d’un Data
Warehouse

11. 11
Phases de construction d’un DW
Ø Il y’a trois parties interdépendante qui relève la construction d’un
Datawarehouse:
Ø L’étude préalable qui va définir les objectifs, la démarche à suivre, le
retour sur investissement,...
Ø L’étude du modèle de données qui représente le DW conceptuellement
et logiquement
Ø L’étude de l’alimentation du Datawarehouse

12. 12
Étude préalable:
Étude des besoins
Ø Définir les objectifs du DW
Ø Déterminer le contenu du DW et son organisation, d’après:
Les résultats attendus par les utilisateurs,
Les requêtes qu’ils formuleront,
Les projets qui ont été définie
Ø Recenser les données nécessaires à un bon fonctionnement du DW:
Recenser les données disponibles dans les bases de production
Identifier les données supplémentaires requises
Ø Choisir les dimensions
Typiquement: le temps, le client, le produit, le magasin...
Ø Choisir les mesures de fait
De préférences de quantités numériques additives
Ø Choisir la granularité des faits
Niveau de détails des dimensions

13. 13
Étude préalable:
Coûts de déploiement:
Ø Nécessite des machines puissantes, souvent une machine parallèle
Ø Capacité de stockage très importante (historisation des données)
Evaluer la capacité de stockage
Ø Equipes de maintenance et d’administration
Les coûts des logiciels
Les logiciels d’administration du DW
Les outils ETL (Extract-Transform- Loading)
Les outils d’interrogation et de visualisation Les outils de Datamining

14. 14
Modélisation
Ø Niveau conceptuel:
Un DW est basé sur une modélisation multidimensionnelle qui
représente les données dans un cube
Un cube permet de voir les données suivant plusieurs dimensions:
Tables de dimensions
La table des faits contient les mesures et les clés des dimensions
Ø Niveau Logique:
Plusieurs schémas types sont proposés pour représenter un DW:
Schéma en étoile;
Schéma en flocon;

15. 15
Alimentation
Ø L’alimentation est la procédure qui permet de transférer des données du
système opérationnel vers le DW
Ø La conception de cette opération est une tâche complexe
60 à 90 % de la charge totale d’un projet DW
Ø Elle doit être faite en collaboration avec l’administrateur des bases de
productions
Ø Il est nécessaire de déterminer:
Quelles données seront chargées
Les transformations et les vérifications nécessaires
La périodicité et le moment de transferts des données

16. 16
Conception d’un Data Warehouse
Ø Étape 1
Choisir le processus à modéliser
Ø Étape 2
Choisir le grain des faits
Décider de ce que représenté une ligne de la table de faits
Niveau de détail: transactions individuelles, récapitulatifs journaliers,
mensuels...
Ø Étape 3
Identifier les dimensions qui s’appliquent aux lignes de la table
des faits
Typiquement le temps, le client, le foyer, le produit, magasin, agence,
compte...
Ø Étape 4
Identifier les mesures de fait qui renseignent la table de faits
De préférence des quantités numériques additives

17. 17
Conclusion
u Voici une liste de points importants à prendre en compte
pour que le projet du SID soit un succès :
u Se concentrer sur les exigences et les objectifs
u Obtenir le soutien des responsables du côté utilisateur
u Choisir un mode de développement itératif plutôt que global
u Prévoir au mieux les coûts de chaque étape (en temps, en homme/jour, en
dépenses)
u Préférer la commodité d’utilisation et la performance des requêtes plutôt que
la facilité de développement
u Rechercher au maximum des solutions simples
u Respecter une architecture commune et cohérente
u Ne pas se limiter à une granularité trop importante
u Préparer et prendre en compte l’évolution future du système opérationnel et
de l’environnement en général
u S’assurer de l’acceptation du système par les utilisateurs

18. 18
Exemple de modèle dimensionnel en étoile
Ø L'ETL (Extraction Transformation Loading) est le processus de copie des
données depuis les tables des systèmes transactionnels vers les tables
du modèle en étoile du data warehouse.

19. 19
Exercice

20. 20
Exemple d’outils
Ø ETL
Outil d’ETL de Talend
Ø Reporting
Outil de reporting Birt
Ø Exploration
Outil d’exploration de données JPivot
Ø Analyse
Outil d’analyse statistique Weka