Cours - Datawarehouse

Présentation de l’Enseignant
Laboratoire des Systèmes Informatiques

Université des sciences et de la Technologie Houari Boumediene
USTHB - Alger
• Pr. Kamel Boukhalfa

❑ Enseignant à l’USTHB
❑ Docteur de l’université de Poitiers-France et de l’USTHB
❑ Professeur depuis 2017
• Emails
❑ Email de l’USTHB : kboukhalfa@usthb.dz
❑ Emails souvent utilisés

❑ boukhalk@gmail.com
❑ Kamelboukhalfa@yahoo.fr
• Site Web personnel

❑ http://boukhalfa.jimdo.com
❑ CV
Pr. Kamel Boukhalfa ❑ Production scientifique
Boukhalk@gmail.com ❑ Téléchargement de cours
LES ENTREPOTS DE DONNEES - Data Warehouse 2

Domaines de Recherches PLAN GLOBAL
❑ Entrepôts de données
❑ Optimisation de la couche physique, Fragmentation Horizontale, Indexation, Tuning ❑ Entrepôts de données
❑ Méta-heuristiques
❑ AG, RS, HC, RT, Optimisation multi-objectifs
❑ Optimisation des Entrepôts
❑ Data mining
❑ Motifs fréquents, classification, règles d’association, data mining spatial
❑ Cloud Computing
❑ Fouille de données
❑ DBAAS, Systèmes de stockage hybride,
❑ Big Data ❑ Techniques de Fouille de données

❑ Analyse des réseaux sociaux, influence, tri des filles d’actualité
❑ Big Data
LES ENTREPOTS DE DONNEES - Data Warehouse 3 LES ENTREPOTS DE DONNEES - Data Warehouse 2
PLAN
Laboratoire des Systèmes Informatiques
Université des sciences et de la Technologie Houari Boumediene
USTHB - Alger
• Entrepôt de données
• Architecture des ED
• Modélisation multidimensionnelle OLAP
• Optimisation des Entrepôts de données

Pr. Kamel Boukhalfa
Boukhalk@gmail.com
LES ENTREPOTS DE DONNEES - Data Warehouse 2
Le contexte Les données utilisables par les décideurs
❑ Besoin: prise de décisions stratégiques et tactiques ❑ Données opérationnelles (de production)
❑ Pourquoi: besoin de réactivité
– Bases de données (Oracle, SQL Server)
❑ Qui: les décideurs (non informaticiens)
– Fichiers, …
❑ Comment: répondre aux demandes d’analyse des données, dégager des informations qualitatives nouvelles
– Paye, gestion des RH, gestion des commandes…
Pourquoi et ❑ Caractéristiques de ces données:

Qui sont mes
comment le chiffre
meilleurs clients? – Distribuées: systèmes éparpillés
d’affaire a baissé?
– Hétérogènes: systèmes et structures de données différents
– Détaillées: organisation des données selon les processus fonctionnels, données

A combien s’élèvent surabondantes pour l’analyse
Quels Algériens mes ventes
consomment journalières? – Peu/pas adaptées à l’analyse : les requêtes lourdes peuvent bloquer le système
beaucoup de temps transactionnel
de connexion?
– Volatiles: pas d’historisation systématique
Le Décisionnel Problématique
❑ Les entreprises passent à l'ère de l'information • Comment répondre aux demandes des décideurs?
❑ Défi : Transformer une partie de leur système d'information qui avait une
– En donnant un accès rapide et simple à l’information
vocation de production à un SI décisionnel dont la vocation de pilotage devient
stratégique
majeure.
– En donnant du sens aux données
❑ Un système d'information décisionnel (S.I.D.) est un ensemble de données
organisé de façon spécifique, approprié à la prise de décision.
❑ Finalité d'un système décisionnel : Mettre en place un système d’information dédié aux
❑ Pilotage de l'entreprise applications décisionnelles:
Un Entrepôt de Données (Data Warehouse)
Système d'Info. de Production
Orientation : Gestion
Système d'Info.
Le processus de prise de décision
Flux de Décisionnel Champs d’application des
données
externes Orientation : systèmes décisionnels
BD Pilotage
Fournisseurs BD
Clients
BD
Compta
Entrepôt de
BD Données
DRH
BD
Magasins Temps de prise d’une décision
BD
Marketing
BD
Flux de
données Produits
externes 11 LES ENTREPOTS DE DONNEES - Data Warehouse 12
Introduction Introduction
❑ Pourquoi le data warehouse ? Raisons d’être d’un entrepôt de données
▪ Améliorer les performances décisionnelles de l’entreprise
• Rassembler les données de l’entreprise dans un même lieu
❑ Comment? sans surcharger les BD (systèmes opérationnels)
▪ En répondant aux demandes d’analyse des décideurs
• Permettre un accès universel à diverses sources de données
❑ Exemples et assurer la qualité des données
▪ Clientèle: Qui sont mes clients? Pourquoi sont-ils mes clients?, Comment les
conserver ou les faire revenir (préférence d’achat, habitudes, …)? Ces clients sont-
• Extraire, filtrer, et intégrer les informations pertinentes, à
l’avance, pour des requêtes ultérieures
ils vraiment intéressants pour moi?
▪ Marketing, actions commerciales: où placer ce produit dans les rayons?
• Dégager des connaissances et faire un apprentissage sur
Comment cibler plus précisément le mailing concernant ce produit?
l’entreprise, le marché et l’environnement
▪Exemple dans le domaine de sécurité ?
C’est quoi un entrepôt de données? Les 4 caractéristiques des data warehouse
❑ Industrie (Inmon 1992)
1. Données orientées sujet:
• Collection de données orientées sujets
– Regroupe les informations des différents métiers
• Consolidées dans une base de données unique
• Non volatiles et historisées variant dans le temps – Ne tiens pas compte de l’organisation fonctionnelle
• organisées pour le support d'un processus d'aide à la des données

Applications
décision
Production Gestion de stock Facturation
❑ Recherche (Stanford 1995)
Sujets
Client
• Dispositif de stockage d’informations intégrées de Produit

sources distribuées, autonomes, hétérogènes
Les 4 caractéristiques des data warehouse Intégration de données
2. Données intégrées:
– Normalisation des données
– Définition d’un référentiel unique
h,f
1,0 h,f
homme, femme
GBP
EUR
CHF
USD
Les 4 caractéristiques des data warehouse Les 4 caractéristiques des data warehouse
3. Données non volatiles 4. Données datées

– Les données persistent dans le temps
– Traçabilité des informations et des décisions prises – Mise en place d’un référentiel temps
– Copie des données de production
Image de la base en Mai 2017 Image de la base en Juillet 2018
Répertoire Répertoire
Bases de production Entrepôts de données Base de Nom Ville Nom Ville
production
Ajout Karim Alger Karim Tipaza
Salim Blida Salim Blida
Suppression
Calendrier Répertoire
Accès Entrepôt
Code Année Mois Code Année
Nom Mois
Ville
Modification Chargement de
1 2017 Mai 1 Karim Alger
données
2 2018 Juillet 1 Salim Blida
LES ENTREPOTS DE DONNEES - Data Warehouse 19 LES ENTREPOTS DE DONNEES - Data Warehouse 2 Karim Tipaza 20
Datamart Intérêt des datamart
• Sous-ensemble d’un entrepôt de données • Nouvel environnement structuré et formaté en
• Destiné à répondre aux besoins d’un secteur ou d’une fonction des besoins d’un métier ou d’un usage
fonction particulière de l’entreprise particulier
• Point de vue spécifique selon des critères métiers
• Moins de données que DW
Datamarts du – Plus facile à comprendre, à manipuler
service Marketing
– Amélioration des temps de réponse
• Utilisateurs plus ciblés

Datamart du service
DW de l’entreprise Ressources
Humaines
Architecture d’un entrepôt de données Architecture d’un entrepôt de données: physique
Inconvénients
❑ pas de réelle intégration des données
❑ différentes vues non-réconciliées
❑ les requêtes peuvent facilement bloquer
les transactions en cours
Architecture générale Les flux de données
• Flux entrant
Zone de
Zone de préparation Zone de stockage présentation
– Extraction: multi-source, hétérogène
C
E H – Transformation: filtrer, trier, homogénéiser, nettoyer
X
A
T Transformations: Requêtes
R Data – Chargement: insertion des données dans l’entrepôt
R Nettoyage Rapports
A G warehouse
Standardisation Visualisation
C E
… Data Mining
T M
…
• Flux sortant
I E
O N
N T
Datamart – Mise à disposition des données pour les utilisateurs finaux
Sources de
données
Les différentes zones de l’architecture Processus ETL (Extracting – Transforming – Loading )
• Zone de préparation (Staging area)
 Le principe de l'entreposage des données est de rassembler de
– Zone temporaire de stockage des données extraites
– Réalisation des transformations avant l’insertion dans le DW:

multiples données sources qui souvent sont hétérogènes en les
• Nettoyage rendant homogènes afin de les analyser.
• Normalisation…
– Données souvent détruites après chargement dans le DW

 Ce travail d'homogéinisation nécessite des règles précises servant
• Zone de stockage (DW, DM)
– On y transfère les données nettoyées de dictionnaire (ou de référentiel) et qui seront mémorisées sous
– Stockage permanent des données forme de métadonnées (information sur les données).
• Zone de présentation
– Donne accès aux données contenues dans le DW

 Ces règles permettent d'assurer des tâches d'administration et de
– Peut contenir des outils d’analyse programmés:
• Rapports gestion des donnés entreposées.

• Requêtes…
ETL ETL
L'alimentation d'un ED est un processus qui s'effectue en plusieurs
Un système ETL est tout système qui permet :
étapes :
❑ d'offrir un environnement de développement, des outils de gestion des opérations
❑Sélection des données sources
et de maintenance.
❑ de découvrir, analyser et extraire les données à partir de sources hétérogènes; ❑Extraction des données
❑ de nettoyer et standardiser les données selon les règles d'affaires établies par
l'entreprise; ❑Transformation
❑ de charger les données dans un entrepôt de données dans et/ou les propager
❑Chargement
vers les data-marts.
Sélection des données sources Sélection des données sources (suite)
• Quelles sont les données de production qu'il faut sélectionner pour La sélection des données utiles à partir des BD de production n'est
pas simple à faire .
alimenter l'ED ?
Les données sont :
• Toutes les données sources ne sont forcément pas utiles.
• hétérogènes (différents SGBD et différentes méthodes d'accès);
• Doit-on prendre l'adresse complète ou séparer le code postal ?
• diffuses (différents environnements matériels et différents réseaux
• Les données sélectionnées seront réorganisées pour servir à la interconnectés ou non);
fabrication des informations. • complexes (différents modèles logiques et physiques principalement orientés
vers les traitements transactionnels).
• La dénormalisation des données crée des liens entre les données et
• La définition de la granularité dépend du niveau de raffinement de
permet des accès différents l'information qu'on veut obtenir.
Sélection des données sources (suite) Extraction des données
Il existe plusieurs niveaux de données :
❑ L'extraction peut se faire à travers un outil d'alimentation qui
❑ Les données sont parfois assemblées avant d'être injectées dans l'ED doit travailler de façon native avec les SGBD qui gèrent les données
permettant une vision intégrée et transversale de l'entreprise.
sources.
❑ Cette forme de données constitue le niveau le plus fin au niveau de l'ED
: ceux sont les données de détail. Elles peuvent être agrégées et
constituent ainsi un autre niveau de détail. ❑ Ou alors créer des programmes extracteurs. L'inconvénient de
❑ Elles seront par la suite structurées dans des espaces d'analyse (soit des cette approche est le risque de faire des extractions erronées,
cubes de données, soit des data marts). incomplètes et qui peuvent biaiser l'ED.
❑ Elles seront finalement à un niveau de présentation, où elles peuvent
avoir plusieurs formes (tableaux, graphiques, tableaux de bord, règles de
connaissances...). ❑ Il faut gérer les anomalies en les traitant et en gardant une trace
Extraction des données Transformation
❑ L'extraction doit se faire conformément aux règles précises du
référentiel.
C'est une suite d'opérations qui a pour but de rendre les
❑ Elle ne doit pas non plus perturber les activités de production.
données cibles homogènes et puissent être traitées de façon
cohérente.
❑ Il faut faire attention aux données cycliques. Celles qu'on doit calculer
à chaque période, pour pouvoir les prendre en considération. Exemple
Donnés sources données cibles Donnés sources données cibles

❑ L'extraction peut se faire en interne selon l'horloge interne ou par un Appli 1 : male, femelle m, f Appli 1 : $1 500 179121 DZD
planificateur ou par la détection d'une donnée cible (de l'ED) ; ou en Appli 2 : 1, 0 m, f Appli 2 : 160 € 21435 DZD
externe par des planificateurs externes. Appli 3 : Masculin, féminin m, f Appli 3 : 2 000£ 311950 DZD
❑ Les données extraites doivent être marquées par “ horodatage ” afin

qu'elles puissent être pistées.
Transformation Transformation
❑ Les données doivent alors filtrées afin d'éliminer les données aberrantes:
❑L'ensemble des données sources, après nettoyage ou
données sans valeurs, avec des valeurs manquantes.
transformation d'après des règles précises ou par application de
❑ Souvent dans les bases de production, certaines données sont
sémantiquement fausses. programmes, seront restructurées et converties dans un format
❑ Pour avoir une alimentation de qualité, il faut avoir une bonne cible.
connaissance des données à entreposer et des règles qui les régissent.
❑Il faut synchroniser les données pour que les valeurs agrégées
Savoir corriger les données pour les doter d'un vrai sens sémantique.
obtenues soient cohérentes, avant de passer à la phase de
chargement.
Data Cleaning Chargement
❑ Valeurs manquantes (nulles) ❑ C'est l'opération qui consiste à charger les données
– Ignorer le tuple
nettoyées et préparées dans le DW.
– Remplacer par une valeur fixe ou par la moyenne
❑ Valeurs erronées ou inconsistantes ❑ C'est une opération qui risque d'être assez longue. Il faut
– Générées en présence de bruits
mettre en place des stratégies pour assurer de bonnes
– Détecter par une analyse de voisinage
• Écart par rapport à la moyenne
conditions à sa réalisation et définir la politique de
• Factorisation en groupes
rafraîchissement.
– Remplacer par une valeur fixe ou par la moyenne
❑ C'est une phase plutôt mécanique et la moins complexe.
❑ Inspection manuelle de certaines données possible
Chargement Catégories des systèmes d'ETL
❑ Le dictionnaire (ou référentiel) de données est constitué de
Il existe trois catégories d'outils ETL :
l'ensemble des métadonnées.
1. Engine-based : les transformations sont exécutées sur un serveur ETL,
❑ Il renferme des informations sur toutes les données de l'ED.
disposant en général d'un référentiel. Ce genre d'outil dispose d'un moteur
❑ Il renferme également des informations sur chaque étape de transformation ;
lors de la construction du DW ; sur le passage d'un niveau de
données à un autre lors de l'exploitation du DW. 2. Database-embedded : les transformations sont intégrées dans la BD ;
• Le rôle des métadonnées est de permettre :
o La définition des données 3. Code-generators : les transformations sont conçues et un code est
o La fabrication des données
o Le stockage des données généré. Ce code est déployable indépendamment de la base de données.
o L'accès aux données
o La présentation des données.
Catégories des systèmes d'ETL Catégories des systèmes d'ETL
Avantages des suites ETL : Avantages des suites ETL (suite) :
✓ Le référentiel de méta-data des outils ETL peut produire automatiquement des rapports de
✓ Développement simple, rapide et moins coûteux. Les coûts de l'outil seront amortis
rapidement pour les projets sophistiqués ou de grandes envergures. mise en correspondance des données et d'analyse de dépendance de données
✓ Des ressources disposant de connaissances du domaine d'affaire et n'ayant pas de ✓ Les outils ETL disposent de connecteurs intégrés pour la plupart des sources de données.
grandes compétences en programmation peuvent développer avec l'outil. Ils permettent aussi d'effectuer des conversions complexes de types de données (selon la
source et la destination)
✓ Les outils ETL intègrent des référentiels de gestion des méta-data, tout en permettant de
synchroniser les méta-data avec les systèmes sources, les BDs de l'ED et autres outils BI.
✓ Les outils ETL offrent des mécanismes de cryptage de compression en ligne de données
✓ Les outils ETL permettent la génération automatique du méta-data à chaque étape du
✓ La plupart des outils ETL offre une très bonne performance même pour une grande
processus ETL et renforcent la mise en place d'une méthodologie commune de gestion de
méta-data qui doit être respectée par tous les développeurs. quantité de données.
✓ Les outils ETL disposent de programme intégré qui permet de faciliter la documentation, la ✓ Un outil ETL peut, le cas échéant, gérer des scénarios d'équilibrage de la charge entre les
création et la gestion de changement. L'outil ETL doit bien gérer les dépendances complexes
serveurs.
et les erreurs qui peuvent surgir en cours d'exécution.
✓Un outil ETL peut être complété ou amélioré en utilisant le scripting ou la programmation.
Catégories des systèmes d'ETL Administration d'un ED
Avantages des ETL-Maison : ❑ L'ED est un aspect physique du SI de l'entreprise. Il doit être par conséquent
évolutif. Les données doivent donc changer. On doit procéder à d'autres
✓Les outils de tests unitaires automatique sont disponibles seulement pour les outils alimentations et donc gérer l'actualisation des données.
développé maison.
❑ Il existe des outils qui prennent en charge les tâches de rafraîchissement des
✓Les techniques de programmation orientée objet permettent de rendre consistantes la
données.
gestion des erreurs, la validation et la mise à jour des méta-data.
✓Il est possible de gérer manuellement les méta-data dans le code et de créer des interfaces ❑ Ils procèdent par réplication pour propager les maj effectuées dans les BD
pour la gestion de ces dernières sources, dans l'ED.
✓.Disponibilité des programmeurs dans l'entreprise. ❑ Le mécanisme de réplication et une opération de copie de données d'une BD
vers une ou plusieurs BD.
✓ Un outil ETL est limité aux capacités du fournisseur.
✓ Un outil ETL est limité à l'outil de scripting propriétaire. ❑ Les réplications sont alors synchrones ou asynchrones.
✓Un outil développé maison donne une grande flexibilité et si le besoin se présente. Il est ❑ Le rafraîchissement des données peut se faire également par des processus
possible de tout faire. de transformation qui exploitent les méta-données.
Administration d'un ED (suite) Administration d'un ED (suite)
❑ La fonction d'administration porte sur un aspect fonctionnel (qualité et la
pérennité des données) mais aussi sur un aspect technique (maintenance,
optimisation, sécurisation,...)
❑ La fonction de DBA est très recherchée
❑ Elle concerne l'ensemble des tâches du processus d'entreposage de la ❑ Les DBA sont bien rémunérés (mieux que les développeurs)
sélection des données de production à la mise à disposition pour construire les
espaces d'analyse.
❑ Les compétences demandées chez les DBA :
❑ L'administrateur de l'ED doit maîtriser la gestion des données (données, ❑ Data warehousing (très recherché)
provenance des données, méta-données).
❑ Services de transformation des données (ETL)
❑ Les données agrégées sont aussi une production (information) de l'entreprise
comme les données de production, doivent être entreposées. ❑ Environnement de réplication
Rôles et responsabilités Rôles et responsabilités (suite)
3. Développeur ETL
1. Gestionnaire ETL
❑ Développer les routines ETL.
❑ Gérer quotidiennement l'équipe ETL.
❑ Tester les routines ETL.
❑ Définir les standards et procédures de l'environnement de développement ETL
❑ S'assurer que les résultats du processus ETL répondent aux besoins d'affaire
(Règles de nomenclature, Meilleures pratiques…)
(Collaboration étroite avec l'architecte ETL)
❑ Superviser le développement, les tests et l'assurance qualité
4. Analyste système
2. Architecte ETL
❑ Rassembler des besoins d'affaire.
❑ Concevoir l'architecture et l'infrastructure de l'environnement ETL.
❑ Documenter les besoins d'affaire.
❑ Concevoir le mappage logique de données.
❑ Travailler en collaboration avec toute l'équipe du DW (Non seulement celle du
❑ Livrer les routines ETL en production.
système ETL).
❑ Appréhender les besoins d'affaire.
❑ Connaître les systèmes source.
❑ Résoudre les problèmes techniques complexes.
Rôles et responsabilités (suite) Exploitation de l’entrepôt
5.Spécialiste qualité de données
❑ Business Intelligence:
❑ S'assurer de la qualité des données dans l'entrepôt de données en • Possibilité de visualiser et d’exploiter une masse
entier. importante de données complexes
❑ S'assurer que les règles d'affaire sont bien implantées par les processus
❑ Trois principaux outils:
ETL (en collaboration avec l'analyste système et l'architecte ETL)
• OLAP :On-Line Analytical Processing
6.DBA
• Data mining: fouille de données
❑ Installer, configurer, migrer et maintenir la base de données. • Formulation de requêtes et visualisation des résultats
❑ Traduire le modèle logique de données en modèle physique.
Architecture d’un entrepôt de données Domaines d’applications
❑ Souvent une architecture trois-tiers ❑ Banque, Assurance
• Serveur d’entrepôt (“Warehouse Database Server”) • Détermination des profils client (prêt, …)
• Très souvent un système relationnel (ex. Oracle) ❑ Commerce
• Ciblage de clientèle
• Serveur OLAP (“OLAP Server”) de type ROLAP,
MOLAP, ou HOLAP • Compagnies de grande production
• Aménagement des rayons (2 produits en corrélation)
• Clients
• Outils de requêtes et de production de rapports ❑ Compagnies téléphoniques
• Outils d’analyse et de prospection de données ❑ Santé
Base de données vs. Entrepôt de donnée SGBD et DW
Service Service Service

OLTP: On-Line commercial Financier livraison
❑ Les objectifs de performances dans les BD ne sont pas les mêmes
que ceux dans les EDs : Transactional BD prod BD prod BD prod
Processing
o BD : requêtes simples (OLTP), méthodes d’accès et Clientèle
indexation
o ED : requêtes OLAP souvent complexes!!!
H
I
❑ La nécessité de combiner des données provenant de diverses sources, d’effectuer Data Warehouse S
T
des agrégations dans un ED et d’offrir des vues multidimensionnelles OLAP: On-Line O
R
Analitical Clientèle I
❑ Les données d’un ED sont souvent non volatiles et ont donc une plus longue Processing Q
U
durée de vie que celles d’une BD E
OLTP VS DW Cycle de vie de l’entrepôt de données
OLTP DW
Orienté transaction Orienté analyse ANALYSE
Orienté application Orienté sujet

Données courantes Données historisées CONCEPTION
Données détaillées Données agrégées
Données évolutives Données statiques
CONSTRUCTION
Utilisateurs nombreux, Utilisateurs peu nombreux,
administrateurs/opérationnels manager
Temps d’exécution: court Temps d’exécution: long DÉPLOIEMENT
Cycle de vie Cycle de vie
❑ Spécification des besoins ❑ Analyse
• Développer le schéma de l’entrepôt
• Rassembler clairement et fidèlement les besoins des
• Définir les processus nécessaires à la mise en place de l’entrepôt
utilisateurs (décideurs) (extraction de données à partir des sources, transformations)
• Clarifier les objectifs spécifiques

❑ Conception (3 niveaux)
o Comportement de la clientèle, analyse de tendances de
prévisions, etc.
• Conceptuel : mise au point du schéma, définition des méta-
données
• Énumérer les dimensions
• Logique : adapté aux particularités du serveur de l’entrepôt
• Définir l’architecture du système (modèle de données), l’usage (ROLAP, MOLAP, etc.)
final (rapports, requêtes, outils d’analyse et visualisation) • Physique: choix d’index, vues matérialisées, fragmentation
Cycle de vie
❑ Construction
• Développer des programmes d’extraction, d’épuration et de
transformation de données
❑ Déploiement
• Fournir une installation initiale incluant la connexion aux données
sources, la synchronisation et la réplication de données
• Permettre des extensions futures
• Offrir la formation pour les groupes d’intervenants

• Offrir les divers mécanismes d’administration de l’ED (reprise,
MODELISATION DES ED
sécurité, performances)
• Offrir les outils nécessaires à l’exploitation des données et à la
consultation des méta-données
LES ENTREPOTS DE DONNEES - Data Warehouse 61 62
Modélisation classique (OLTP) Requêtes décisionnelles plus complexes !!
❑ Le modèle relationnel ❑ Exemples
❑ Combien de clients âgés entre 20 et 30 ans et résidant à Alger ont-ils acheté

• Table, attributs, tuples, vues, …
une caméra vidéo au cours des 5 dernières années ?
• Normalisation (redondance)
❑ Quelle est la répartition des ventes par produit, ville et par mois au cours de
• Requêtes simples (sélection, projection, jointure, …)
la présente année?
❑ Le critère temps ❑ Quelles sont les composantes des machines de production ayant eu le plus
grand nombre d’incidents imprévisibles au cours de la période 1992-97 ?

• Représentation du passé
Critère temps est la base de l’analyse décisionnelle
Récapitulatif OLAP
Base de données Entrepôt de données
❑ Traitement analytique interactif (Codd) typique
Opération ▪ Gestion courante ▪ Support à la décision
dans les systèmes informationnels
Modèle ▪ Entité association ▪ Etoile, flocon de neige
Normalisation ▪ Plus fréquente ▪ Rare ❑ Catégorie de traitements dédiés à l’aide à la décision

Données ▪ Actuelle, brutes ▪ Historiques, agrégées
Mise à jour ▪ immédiate ▪ Plus différée ❑Analyses diverses (multidimensionnelles)

Perception ▪ Bidimensionnel ▪ Multidimensionnelle ❑ Information : surtout dérivée et sommaire
Opérations ▪ Lecture/écriture ▪ Lecture et rafraichissement ❑ Aide à la prise de décision
Taille ▪ Des giga-octets ▪ Vers des téra, péta-octets
Modélisation Multidimensionnelle Hyper cube OLAP
❑ Dimension: ❑ Objectifs
• Présente le point de vue selon lequel on veut voir le données • Obtenir des informations déjà agrégées selon les
décrites par un ensemble d’attributs· Axe de l’analyse besoins des utilisateurs
• Exemple: Commandes, achats, réclamations, produits, clients,... • Représentation de l’information dans un hyper
cube à N dimensions
❑ Mesures/faits
• Fonction numérique qui peut être évaluée en tout point du data ❑ Opérations OLAP
cube en agrégeant les données correspondant à ce point • Fonctionnalités qui servent à faciliter l’analyse
multidimensionnelles: opérations réalisables sur l’hyper cube
• Mesure d’activité (critère d’analyse)
• Exemple: Chiffre d’affaire, nombre de ventes, gain
Exemple d’un cube de données Vue multidimensionnelle des données
❑ Le volume des ventes (mesure) en fonction de : Produit, Temp et
Produits Région Localisation (Dimension)
Voiture Dimensions: Produit, Région, Temps
Est
Camion
95 100 120 60 76 130
Ouest
Bus
110 70 102 110
Hiérarchie des dimensions
125 130
120 90 10 120
120 110 90
Centre Pays Année
100 20 100 120 120 95
105 12 65 90 92 105 Région Trimestre

Nombre de Bus
85 80 132 120 102 35
vendus le mois d’ Avril Ville Mois
dans la région Ouest
Janvier Février Avril Temps
Local Jour
Comment stocker le cube de données Modèle ROLAP
❑ ROLAP: Relational On-Line Analytical Processing ❑ Exploiter l’expérience des modèles relationnels
• Les données sont stockées comme des tables relationnelles: (un grand succès!!)
une table de faits et des tables de dimension
❑ Il faut des modèles bien adaptés aux ED!
❑ MOLAP: Multidimensional On-Line Analytical
• Schéma en étoile (star schema)
Processing
• Schéma en flocon de neige (snowflake schema)
• le cube de données est stocké sous forme d’un tableau multi-
dimensionnel. • Schéma en constellation
Modèle en étoile Schéma en étoile
Table de dimension
❑ Autant de tables de dimension qu’il existe de
Table de dimension
Temps Produit
dimensions TID Table des faits PID

Jour Description
Mois Ventes Marque
• Exemple Trimestre Catégorie
Année TID Emballage
o Temps, Produit, Client PID
1 094 n-uplets 300 000 n-uplets
MID
CID Table de dimension
Table de dimension
PrixUnitaire
Magasin
❑ Une table de faits contenant la clé de chaque Client Montant
CID
dimension et des mesures Nom
100 000 000 n-uplets
MID
Nom
Genre Ville
• Exemple Ville Adresse
Age
o Montant en dollars, nombre d’unités vendues 3 000 000 n-uplets 500 n-uplets
Requête type Avantages & Inconvénients
Requête de Jointure en étoile :
SELECT P.Marque, sum(dollars_sold),
sum(units_sold)
+ Simple
FROM Ventes V, PRODUIT P, TEMPS T
WHERE V.PID = P.PID (Jointure)
AND V.TID = T.TID (Jointure) + Le plus utilisé !!!
AND T.Trimestre = ‘T1’ (Sélection) PRODUIT
GROUP BY P.Marque PID
ORDER BY P.Marque Description
Marque
TEMPS
VENTES
Catégorie
Type_Paquet
- Possibilité de redondance car les tables de
TID
Jour
TID
PID
300000 tuples dimension ne sont pas nécessairement
Requêtes de jointure en étoile
• Plusieurs jointures
Mois
Trimestre
MID
Dollars_sold
MAGASIN
MID
normalisées
Année Units_sold
Nom
• Suivies par des sélection 1094 tuples Ville
100000000 tuples Adresse
1200 tuples - Taille de dimensions plus grosse
Modèle en flocon de neige Exemple d’un modèle en flocon de neige
Hiérarchie de dimension
❑ Variante du modèle en étoile Année Trimestre Jour Temps Produit

TID PID
Trimestre Mois Jour Table des faits
Jour Description
Année Trimestre Mois
❑ Les tables de dimension sont normalisées Ventes Marque
Catégorie
TID Emballage
❑ Réduction de la redondance mais exécution parfois PID

MID
Hiérarchie de dimension
CID
PrixUnitaire
plus lente des requêtes (jointure de tables) Région Ville Client Magasin
Montant
Région Ville CID MID

Pays Département Nom Nom
❑ Modèle adopté par Oracle!! Genre
Ville
Ville
Adresse
Age
Définition d’un schéma en étoile avec DMQL Définition d’un schéma snowflake avec DMQL
define cube ventes_star [Temps, Produit, Client]
define cube ventes_snowflake [temps, item, branche, lieu]
Montant_vente = sum(somme),
Montant_vente = sum(somme), Mesures
moyenne_vente = avg(somme), Mesures
unités_vendues = count(*) Dimensions
moyenne_vente = avg(somme),
Dimensions define dimension item as (Id_item, nom_item, marque, type,
unités_vendues = count(*) fournisseur(Id_fournisseur, type_fournisseur))
define dimension branche as (Id_branche, nom_branche, type_branche)

define dimension Temps as (TID, Année, mois, jour)
define dimension temps as (Id_temps, jour, jour_semaine, mois, trimestre, année)
define dimension Produit as (PID, nom_item, marque, taille, poids)
define dimension lieu as (Id_lieu, rue, ville(Id_ville, département, pays))
Hiérarchies
define dimension Client as (Cid, Nom, Sexe, Age, Ville)
MOLAP: Représentation Tableaux ROLAP vs. MOLAP
Avantages Inconvénients
Temps Trimestre 1 Trimestre 2 Trimestre 3 Trimestre 4 Total
Produit Ville P N Total P N Total P N Total P N Total P N Total ▪ Standard bien établi
▪ Absence de vue conceptuelle
TV LCD 12 34 46 22 36 58 24 37 61 33 55 88 91 162 253 ▪ Efficace pour le transactionnel
ROLAP ▪ SQL peut être inadéquat pour
Lecteur DVD 29 66 95 44 50 94 56 55 111 44 39 83 173 210 383 ▪ Capacité d’expansion (téra-
la formation de tableaux croisés
Caméoscope 55 34 89 69 27 96 31 26 57 68 70 138 223 157 380
octet)
Total 96 134 230 135 113 248 111 118 229 145 114 309 487 529 1016
▪ Inadéquat pour le
transactionnel
▪ Implémentation souvent plus
Répartition des ventes par produit, temps et ville MOLAP ▪ Capacité d’expansion limitée
performante que ROLAP
P : Poitiers, N : Nantes (dizaine de géga-octet)
▪ Absence de standard
Serveurs ROLAP [Microstrategy] Serveurs MOLAP
Hybrid OLAP Opérations de base OLAP
❑Roll-up (ou drill-up)
❑ HOLAP combine ROLAP et MOLAP
❑Drill-down
❑ Les données sont partitionnées en deux sous-ensembles
❑Slice & dice
❑Données non fréquentes sont stockées comme tables relationnelles
❑Données fréquentes sont stockées comme tableaux multidimensionnels ❑Pivot
❑Données brutes dans ROLAP
❑Données agrégées dans MOLAP
❑Cette séparation est transparente pour l’utilisateur.
Optimisation des requêtes
❑ Caractéristiques des entrepôts
Optimisation des Entrepôts de • Grand volume de données (TB)

• Requêtes décisionnelles complexes
Données • Peu de mises à jour (ajout seulement!)
❑ Exigence des décideurs

• Temps de réponse raisonnable
• Respect des délais
Objectif Exécution rapide des requêtes ∀ la complexité des requêtes

ou des données
Nécessité de techniques d’optimisation

93 LES ENTREPOTS DE DONNEES - Data Warehouse 94
Techniques utilisées Classification
❑ Vues matérialisées
• Une vue est une requête nommée
• Une vue matérialisée : les données résultant de sa requête
sont stockées et maintenues
❑ Index
• Structures permettant d'associer à une clé d’un n-uplet
l'adresse relative de cet n-uplet
❑ Traitement parallèle
❑ Groupement
❑ Fragmentation
Vues matérialisées Exemple
❑ Exigence de ressources:
• Espace disque CREATE MATERIALIZED VIEW VUE1
• Coût de maintenance (rafraîchissement des données) ENABLE QUERY REWRITE
• Coût de calcul AS
SELECT *
·Impossibilité de matérialiser toutes les vues FROM Vente, Client, Article
WHERE Vente.noClient = Client.noClient AND
❑ Problème de Sélection des Vues (PSV): Vente.noArticle = Article.noArticle
- Sélectionner un ensemble de vues afin de maximiser ou

minimiser une fonction objectif sous une contrainte
- Fonction « objectif »:
Optimiser le coût d’exécution des requêtes ou Optimiser le coût
de maintenance
Maintenance des vues matérialisées Réécriture des requêtes
❑ Processus de réécriture:
❑ Vues matérialisées sont calculées à partir des • Après le processus de sélection des vues, toutes les requêtes
sources (tables) définies sur l’entrepôt doivent être réécrites en fonction des vues
❑ Mise à jour des sources implique la mise à jour des ❑Sélectionner la meilleure réécriture pour une requête est
vues une tâche difficile.
❑ Deux méthodes de maintenance ❑Processus supporté dans la plupart des SGBD

• Statique multidimensionnels (Oracle)
• Incrémentale
Index avancés Classification des Index
❑ Index populaires dans les entrepôts:
• Index simple: sur une seule table ou une seule vue (arbre B, Index
index binaire, index de projection)
• Index de jointure: sur plusieurs tables dans un schéma en

étoile SingleTable Multiple Tables
• index de jointure en étoile B-tree, Projection
Star Join Index,
Bitmap Join Index
• Index de jointure binaire
❑ Problème de sélection d’index

Single Multiple Single Multiple
Attribute Attributes Attribute Attributes
❑ Algorithmes de sélection d’index
Techniques d’indexation Principe de l’index bitmap
❑Index bitmap (index binaire) • Soit un attribut A, ayant prenant n valeurs possibles [v 1, …,vn] (domaine)
• Création d’un index bitmap sur l’attribut A:

❑ Populaire dans les produits OLAP
– On crée n tableaux de bit, un pour chaque valeur vi
• Microsoft SQL server, Sysbase IQ, Oracle
– Le tableau contient un bit pour chaque tuple t
• Un vecteur de bits pour chaque valeur d’attribut – Le bit d’un tuple t est à 1 si: t.A = vi, à 0 sinon
❑ Opération bit à bit pour l’exécution de requêtes Table Employé Index binaire sur l’attribut Fonction
ROWID(RID) N°E Nom Fonction ROWID(RID) Soudeur Fraiseur Sableur Tourneur

• Comparaison
00055 :000 :0023 1 Karim Fraiseur 00055 :000 :0023 0 1 0 0
• Jointure 00234 :020 :8922 2 Hichem Soudeur 00234 :020 :8922 1 0 0 0
• Agrégation 19000 :328 :6200 3 Salim Tourneur 19000 :328 :6200 0 0 0 1
21088 :120 :1002 4 Ali Sableur 21088 :120 :1002 0 0 1 0

• Plus compact que les B+ arbres (compression)
Index de jointure Index de jointure Bitmap : Exemple
• Pré-calculent une opération de jointure Ventes Ville
Client SELECT count(*)
• Utilisés avec les schémas en étoile RIDS CID PID TID Montant
RID P Pr N
RIDC CID Nom Ville FROM Ventes V, Client C
•
1 616 106 11 25 1 1 0 0
Maintient des relations entre 6 616 Gilles Poitiers
2 616 106 66 28 2 1 0 0 WHERE V.CID = C.CID
5 515 Yves Paris
3 616 104 33 50
– Une clé étrangère (identifiant des tables de dimensions) AND C.Ville = ‘Poitiers’
3 1 0 0
4 414 Patrick Nantes
Table Client 4 515 104 11 10 4 0 1 0
3 313 Didier Nantes 5 414 105 66 14 5 0 0 1
– Les clés primaires de la table des faits IdLigne noClient nomVille 2 212 Eric Poitiers 6 212 106 55 14 6 1 0 0
1 111 Pascal Poitiers 7 111 101 44 20 7 1 0 0
Index de jointure
C1 1 Poitiers 8 111 101 33 27 8 1 0 0 CREATE BITMAP INDEX
9 212 101 11 100 9 1 0 0
IdLigneVente idLigneClient idLigneArticle
Produit 10 313 102 11 200 10 0 0 1 Ventes_Pictaviens_bjix ON
C2 2 Nantes
V1 C1 A1 RIDP PID Nom Catégorie
11
12
414
414
102
102
11
55
102
103
11
12
0
0
0
0
1
1
Ventes(Client.Ville) FROM
V2 C2 A2 C3 3 Poitiers
6 106 Sonoflore Beauté 13 515 102 66 100 13 0 1 0 Ventes, Client WHERE
5 105 Clarins Beauté 14 515 103 55 17 14 0 1 0
V3 C3 A1 4 104 WebCam Multimédia 15 212 103 44 45 15 1 0 0
Ventes.CID = Client.CID
C4 4 Paris 3 103 Barbie Jouet 16 111 105 66 44 16 1 0 0
… 17 212 104 66 40 17 1 0 0
2 102 Manure Jardinage
18 515 104 22 20 18 0 1 0
Table Ventes 1 101 SlimForm Fitness
Table Article 19 616 104 22 20 19 1 0 0
IdLigne noClient noArticle DateVente Montant IdLigne noArticle catégorie
20 616 104 55 20 20 1 0 0 Deux opérations :
21 212 105 11 10 21 1 0 0
V1 1 10 10/01/2008 100 Temps 22 212 105 44 10 22 1 0 0 1. Lire dans le bitmap la

A1 10 Beauté 23 212 105 55 18 23 1 0 0
RIDT TID Mois Année
24 212 106 11 18 24 1 0 0 colonne P
V2 2 20 10/01/2008 200 6 11 Janvier 2003 25 313 105 66 19 25 0 0 1
A2 20 Beauté
5 22 Février 2003 26 313 105 22 17 26 0 0 1 2. Compter le nombre de 1.
27 0 0 1
➔ Pas de lecture dans la table
27 313 106 11 15
V3 3 10 4 33 Mars 2003
10/01/2008 500 A3 40 Beauté 3 44 Avril 2003
… A4 50 Jouet
2
1
55
66
Mai
Juin
2003
2003
Ventes
A5 60 Jouet
Caractéristiques des Bitmaps Intérêt des index de jointure binaire
CREATE BITMAP INDEX EMPDEPT_IDX ON
❑ Les opérations de comparaison, jointure et d’agrégation sont
EMP1(DEPT1.DEPTNO)
réduites à une arithmétique sur les bits, d’où un traitement plus
FROM EMP1, DEPT1
efficace
WHERE EMP1.DEPTNO = DEPT1.DEPTNO
❑ La réponse à une requête multidimensionnelle va consister à SELECT /*+ INDEX(EMP1 EMPDEPT_IDX) */ COUNT(*)
faire l’intersection des vecteurs de bits des diverses dimensions FROM EMP1, DEPT1
WHERE EMP1.DEPTNO = DEPT1.DEPTNO;
❑ Réduction significative en espace et nombre d’accès en COUNT(*)
mémoire secondaire 14
Elapsed: 00:00:00.67
Bitmap Join Index Example 2 Bitmap Join Index Example 2
Deux tables EMP5/EMP6 ayant 2 million
d’instances chacune, empno est la clé étrangère
select count(*)
from emp5, emp6
create bitmap index emp5_j6 on where emp5.empno=emp6.empno
emp6(emp5.empno) from emp5, emp6
where emp5.empno=emp6.empno;
COUNT(*)
Elapsed: 00:01:07.18
Index created. 2005007

Elapsed: 00:02:29.91
Bitmap Join Index Example 2 Bitmap Join Index Example 2
FORCER L’UTILISATION DE L’INDEX
Plan d’exécution
select /*+ index(emp6 emp5_j6) */ count(*)
0 SELECT STATEMENT Optimizer=CHOOSE from emp5, emp6
1 0 SORT (AGGREGATE) where emp5.empno=emp6.empno
2 1 NESTED LOOPS
COUNT(*)
3 2 TABLE ACCESS (FULL) OF 'EMP6'
2005007
4 2 INDEX (RANGE SCAN) OF 'EMP5I_EMPNO' (NON-UNIQUE) Elapsed: 00:00:00.87! Comme avec les tables de petites tailles!
Bitmap Join Index - 10,000 plus rapide Selection of BJI : Formalization
Plan d’exécution INPUT
❑ Set of dimension tables D={D1, D2, …, Dd}
❑ Fact Table F
0 SELECT STATEMENT Optimizer=CHOOSE ❑ Workload of frequently queries Q
❑ Storage Space S
1 0 SORT (AGGREGATE) OUTPUT
❑ Set S_BJI of BJI

2 1 BITMAP CONVERSION (COUNT) OBJECTIVES
❑ Reduce execution cost of Q

3 2 BITMAP INDEX (FULL SCAN) OF 'EMP5_J6'
❑ Size (S_BJI)  S
Selection of BJI : Complexity BJI: Existant
❑ Workload
 A={A1, A2, …, AK} is a set of indexable attributes ❑ Storage Space
 A potential BJI is defined on a subset of A

 N the number of potential BJI Identification of
Low Cardinality Attributes
❑ Manual
Indexables Attributes
❑ Automatic
Datamining Algorithms
❑ Close [Aouiche & al. 05] Pruning Search Space
Select One BJI ❑ Dynaclose [Bellatreche & al. 07]
Construction of finale
configuration
Select More Than One
BJI
Final Configuration
Our approach : Single attribute BJI Our approach : Multiple Attributes BJI
❑ Workload
❑ Workload ❑ Storage Space
❑ Storage Space
Identification of Candidates Attributes

Identification of candidats attributes
Construction of One BJI by Query

Initialisation of configuration
Config = Amin_Card;
Config:=  {BJI/Query}
Cost No Size(Config) >

Enrich configuration By Adding BJI Pruning Strategies
Model S
HCA : High Cardinality Attributes
NLT : Attributes belonging to small tables
Final Configuration Yes
LUA : Less Used Attributes
Final Configuration
LES ENTREPOTS DE DONNEES - Data Warehouse 117 LES ENTREPOTS DE DONNEES - Data Warehouse CBE : Cost-Based Elimination 118
La fragmentation de données
Définition
❑ Décomposer les objets de la BD (relation, index, vues) en un ensemble de

morceaux appelés Partitions.
Fragmentation horizontale
❑ La table est fragmentée par rapport à ses instances en un ensemble de lignes.
Fragmentation verticale
❑ La table est fragmentée selon ses attributs en un ensemble de colonnes.
Fragmentation mixte
❑ La table est fragmentée horizontalement et verticalement.
Types de fragmentation Types de fragmentation
Fragmentation horizontale
Fragmentation verticale
– Décomposer les objets en un ensemble de lignes (instances)
– Décomposer les objets en un ensemble de colonnes (attributs).
A1 A2 A3 A4 A5 A1 A2 A3 A4 A5
Attributs I1
I2
I2
I3
A1 A2 A3 A4 A5
I4 I4
I5
I1 I8
I6
I7
I2
A1 A2 A3 A4 A5 I8
I3 I9
I10
I1
I4
Instances
I5
I5
I6
I6
I7
A1 A4
A1 A2 A3 A4 A5
I8 I1 A1 A2 A1 A3 A5
I2 I1 I1
I9 I3 I3 I2 I2
I4 I3 I3
I9
I10 I5 I4 I4
I6 I5
I5
I7 I6
I6
A1 A2 A3 A4 A5 I8 I7
I7
I9 I8
I8
I9
I7 I10
I9
I10
I10
I10
Types de fragmentation Types de fragmentation
Fragmentation mixte Fragmentation mixte
❑ Horizontale suivie d’une verticale. ❑ Verticale suivie d’une horizontale
A1 A2 A3 A4 A5 A1 A2 A3 A4 A5
A1 A2 A3 A4 A5
I1
I1 I1
I5 I2
I2
I6
I3
I3 A1 A2 A3 A4 A5
I4
I2
I4
I5
I4
I5 I8 I6
I6 I7
A1 A2 A3 A4 A5
A1 A4 A1 A2 A1 A3 A5
I7 I3 I8
I2 I2 I2
I9
I9
I8 I4 I4 I4
A1 A2 A3 A4 A5 I10
I9 I8 I8 I8
I7
I10
I10
A1 A4 A1 A2 A1 A3 A5
I3 I3 I3
A1 A4 A1 A2 A1 A3 A5
I9 I9 I9
I1 I1 I1
I5 I5 I5
A1 A4 A1 A2 A1 A3 A5
I6 I6 I1 I1 I1
A1 A4 A1 A2 A1 A3 A5
I6
A1 A2
I2 I2 I2 I7 I7 I7
A1 A4 A1 A3 A5
I2 I2
I2
I3 I3 I3
I10 I10 I10
I4 I4
I4 I4 I4 I4
I8
I8
I8
I5 I5 I5
A1 A4
A1 A2 I6 I6 I6
A1 A3 A5
I3 A1 A4 A1 A2 A1 A3 A5
I3 I7 I7 I7
I3
I9
I9
I9 I8 I8 I8 I1 I1 I1
A1 A2 I9 I9 I9
A1 A4
I7 A1 A3 A5
I5 I5 I5
I7 I10 I10 I10
I10 I7
I10 I6 I6 I6
I10
Fragmentation Horizontale Primaire et dérivée (I) Fragmentation Horizontale Primaire et dérivée (II)
Fragmentation horizontale primaire (FHP) Fragmentation horizontale dérivée (FHD)
– Fragmenter une table en utilisant les prédicats de sélection définis – Fragmenter une table (S) selon des attributs d’une autre table (T) :
sur cette table (existence de lien entre S et T)
Prédicat : Attribut  Valeur,  {=,<, , >, ,} et valeur Domaine(Attribut).
− Ventes(Client_id, Produit_id, Date, Montant)
Client1 Ventes1
– Exemple: Client (Client_id, Nom, Ville) − Ventes1=Ventes Client1
− Client1 :  Ville=‘ Alger’(Client)
Client1
− Ventes2=Ventes Client2 Algérois
Client
Algérois
− Client2 :  Ville=‘Béchar’(Client) Client2 Ventes2
Impact de la FHD sur les requêtes Béchariens
Impact de la FHP sur les requêtes Client2
– Optimisation des sélections Béchariens – Optimisation de la jointure entre S et T
Client1 Ventes1 Ventes2

Ventes
Select Nom, Age Client Select sum(Montant)
Algérois Select Nom, Age
From Client From Client C, Ventes V Select sum(Montant)
From Client2 Where C.CID=V.CID and
Client2 From Ventes2
Where Ville=Béchar
Béchariens Ville=Béchar Client1 Client2
Client
Béchariens
Algérois
Intérêt de la fragmentation horizontale(I) Intérêt de la fragmentation horizontale(II)
Améliorer la performance Amélioration de la performance
1. Partition Elimination (Pruning) 2. Partition Wise Joins
– Elimination des partitions non pertinentes ❑ Elimination des jointures non pertinentes
– Possibilité d’exécution parallèle des sous ❑ Possibilité d’exécution parallèle des sous-jointures
requêtes
Serveur
Select
From Select
Where Serveur From
Where
Requête Fragment
Pertinent
Utilisateur Requête
Utilisateur Résultat local
Fragment non Table1

Table2
Pertinent
Serveur Serveur
Table
Fragment
Pertinent
Résultat local
Résultat Résultat
Fragment non
Pertinent
Intérêt de la fragmentation horizontale(III) Exemple d’ajout de données
Améliorer la manageabilité
Fragmentation horizontale préserve le schéma logique Alimentation hebdomadaire d’une table
• Toutes les opérations se font au niveau partition – L’administrateur partitionne sa table par semaine
• Possibilité de manipulation individuelle ou collective des partitions
– L’alimentation de l’entrepôt consiste alors à ajouter une partition à
Manipuler une partition à la fois.
• Possibilité de définir des index locaux aux partitions la table
• Existences de plusieurs Fonctions de manipulation des partitions – Aucune autre partition ne sera touchée.
Fonction Signification
ADD PARTITION Ajouter une partition à une table déjà fragmentée
COLESCE PARTITION Redistribuer les tuples d’une partition dans les autres partitions
Semaine 1 Semaine 3
DROP PARTITION Supprimer une partition ainsi que son contenu Semaine 5
EXCHANGE PARTITION Convertir une table non fragmentée en une partition d’une autre table et Semaine 2 Semaine 4
inversement
MERGE PARTITION Fusionner deux partitions dans une seule
SPLIT PARTITION Eclater une partition en deux partitions
TRUNCATE PARTITION Vider une partition sans la supprimer
Intérêt de la fragmentation horizontale(IV) Améliorer la maintenance et la disponibilité
Améliorer la maintenance et la disponibilité
La manipulation au niveau partition permet Améliorer la maintenance et la disponibilité
• Cibler la maintenance sur certaines partitions La possibilité de stocker les partitions sur des emplacements différents
• Minimiser le temps de maintenance
La possibilité de stocker les partitions sur des emplacements différents
permet
permet • L’effet des pannes de disques est limité
• L’effet des pannes de disques est limité
• Partitions saines toujours disponibles • Partitions saines toujours disponibles
Maintenance
Crash
Partition1 Partition 3
Partition5
Partition2 Partition4
Partition1 Partition 2 Partition 3 Partition 4 Partition6
Fragmentation horizontale et index Fragmentation et index
Table non Table non
Index fragmentée
Index fragmentée
Un index peut être défini sur une table fragmentée ou non
Un index défini sur une table fragmentée peut être fragmenté ou non.
Table non fragmentée
Index global
– Peut être non fragmenté défini sur une table fragmentée

Index non fragmentée Index fragmentée
– Peut être fragmenté où chaque partition de l’index référence plusieurs
partitions de la table Index Table Index Table Index Table
Global fragmentée Global fragmentée Local fragmentée
Index local
– Equi-partitionné avec la table qu’il référence

Table fragmentée
– Chaque partition de l’index référence une et une seule partition de la table
Index global non fragmenté Index global fragmenté

Index local
Evolution de la fragmentation horizontale Evolution Académique (I)
Evolution Académique Approches de fragmentation
Entrepôts de données et BD
scientifiques
· Conception physique
· Performance
· Manageabilité Approches de fragmentation
· Magasins de données
· Bellatreche 00
Entrepôts de données Entrepôts de données

BD Centralisées BD parallèles et distribuées
parallèles distribués
· Conception (fragmentation et
· Niveau logique · Traitement parallèle
allocation) · Conception
· Ceri et al. 82 · Traitement intra, inter- des requêtes
requêtes · Stohr00
· Ceri84, Ozsu99, Valduriez93
10g2000
8 80709i8i?8
2004 Approches basées
prédicats
Approches basées
affinités
Approches basées modèle
de coût
138 139
Evolution Académique (II) Evolution Académique (III)
Approches basés prédicats Ensemble de prédicats Approches basées Affinités Ensemble de
P={P1, P2, …, Pn} transactions
T={T1, T2, …,Tn}
❑ Avantages ❑ Adaptation des travaux de Navathé sur
Table T Table T
- Simple la fragmentation verticale
❑ Inconvénients Détermination d’un ensemble ❑ Regrouper les prédicats souvent utilisés Enumération des prédicats simples
complet et minimal de prédicats
- Complexité : 2n minterms générés ensemble pour former des fragments

Construction de la matrice d’usage
Génération des minterms
M = {mi/mi = ∧qj q∗j , 1 ≤ i ≤ 2n, 1 ≤ j ≤n},
horizontaux des prédicats
- Aucune métrique pour estimer la où q∗j = qj ou q∗j = ¬qj
qualité du schéma obtenu ❑ Avantages

Génération de la matrice
d’aﬃnité des prédicats
Simplification des minterms - Complexité réduite
❑ Inconvénients Regroupement des prédicats
Génération des fragments
horizontaux
Ti = σmi(T)
- Aucune métrique pour estimer la
Génération des fragments
qualité du schéma obtenu horizontaux
Fragments Fragments Fragments Fragments

T1 T2 T3 Tk
LES ENTREPOTS DE DONNEES - Data Warehouse 140 LES ENTREPOTS DE DONNEES - Data Warehouse Fragments Fragments Fragments 141
Fragments
T2 Tk
140 T1 T3 141
Evolution Académique (IV) Evolution industrielle
Approches basées modèle de Ensemble de requêtes
Q={Q1, Q2, …,Qn}
coût Table T
Chaque schéma de fragmentation est

évalué en utilisant un modèle de coût Enumération des prédicats simples
?
2001
2003
1999
2007
1997 Range- Range
Le modèle de coût permet d’estimer Construction d’un ensemble de List- Range
prédicats simple et complet Range
le coût d’exécution des requêtes les Global Range
Hash List Global Hash
List-List
Indexes Range- Hash Range-List Indexes List- Hash
plus fréquentes sur le schéma Génération des schémas de
fragmentation
fragmenté Reference
Virtual Column
Evaluation des schémas de
Modèle de coût ?11g
10g
9i
8i
8 Interval
fragmentation
Partition Adviser
Inconvénient
Sélection du meilleure schéma
- Le nombre de fragments générés peut
être très important
Fragments Fragments Fragments Fragments

T1 T2 T3 Tk
142 143
Modes de fragmentation Fragmentation par intervalle « Range »
Client 1
Age Age<18
Mode de fragmentation
Client 2
0 18 60 120
18Age<60
2 Domaine(Age) Client 3
Mode simple Mode composite
Client Age60
CREATE TABLE Client

(Client_id NUMBER(5),
Range List Hash Nom Varchar2(20),
Ville Varchar2(20),
Age Number(3),
Genre Varchar2(1))
PARTITION BY RANGE (Age)
(
PARTITION Client_Moins_18 VALUES LESS THAN (18) TABLESPACE TBSMoins27,
Range-Hash Range-List Range-Range List-Range List-List List-Hash PARTITION Client_18_59 VALUES LESS THAN (60) TABLESPACE TBS27-59,
PARTITION Client_60_Et_Plus VALUES LESS THAN (MAXVALUES) TABLESPACE TBSPlus60
);
Fragmentation par liste « List » Fragmentation par hachage « Hash »
Client 1 Client 1
CID F(CID)=x
Ville Ville=‘Béchar’
Client 2 Client 2
Poitiers Paris, Nantes Autres F(CID) F(CID)=y
Ville=‘Alger’ ou
Ville=‘Ouargla’
Domaine(Ville) Client 3 Fonction de Client 3
Client hachage
Ville= Autres F(CID)=z
Client
CREATE TABLE Client CREATE TABLE Client

(Client_id NUMBER(5), (Client_id NUMBER(5),
Nom Varchar2(20), Nom Varchar2(20),
Ville Varchar2(20),
Ville Varchar2(20),
Age Number(3),
Genre Varchar2(1))
Age Number(3),
PARTITION BY List (Ville) Genre Varchar2(1))
( PARTITION BY Hash (CID)
PARTITION Client_Béchar VALUES (‘Béchar’) TABLESPACE TBSBECHAR, (
PARTITION Client_Alg_Oua VALUES (‘Alger’,’Ouargla’) TABLESPACE TBSALGOUA, PARTITIONS 3
PARTITION Client_Autres VALUES (DEFAULT) TABLESPACE TBSAUTRES
STORE IN (TBS1, TBS2, TBS3)
);
);
Modes de fragmentation composite Modes de fragmentation composite
Client 11
Client 1 Age<18 ET Genre=‘M’
CREATE TABLE Client
List
(Genre) Client 12 (Client_id NUMBER(5),
Age<18 ET Genre=‘F’ Nom Varchar2(20),
Age<18 Ville Varchar2(20),
Age Genre Age Number(3),
Client 21
Client 2
Genre Varchar2(1))
18Age<60 ET Genre=‘M’ PARTITION BY RANGE (Age)
List Client 22
Range SUBPARTITION BY LIST (Genre)
(Genre)
(Age) 18Age<60 ET Genre=‘F’ SUBPARTITION TEMPLATE(
18Age<60 SUBPARTITION Client1 VALUES ('M') TABLESPACE TBSMasculin ,
Client 31
SUBPARTITION Client2 VALUES ('F') TABLESPACE TBSFéminin )
Client Age60 ET Genre=‘M’
Client 3 (
List Client 32 PARTITION Client_Moins_18 VALUES LESS THAN (18),
(Genre) PARTITION Client_18_59 VALUES LESS THAN (60),
Age60 ET Genre=‘F’
PARTITION Client_60_Et_Plus VALUES LESS THAN (MAXVALUES)
Age60 );
Premier niveau de Deuxième niveau

fragmentation de fragmentation
Fragmentation dérivée par le mode Référence
Fragmenter une table selon le schéma de fragmentation d’une autre table
en utilisant le lien par clé étrangère.
CREATE TABLE Ventes

Sélection d’un schéma de fragmentation
Client1 Ventes1
(Client_id NUMBER(5),
Time_id NUMBER(5)), horizontale pour un entrepôt de
données relationnel
Montant NUMBER(20),
Algérois
CONSTRAINT order_items_fk
Client2 Ventes2 FOREIGN KEY(Client_id) REFERENCES Client(Client_id)
Béchariens )
PARTITION BY REFERENCE(order_items_fk);

Scénarii de fragmentation d’un ED relationnel Notre démarche de fragmentation
Ventes Client
1. Fragmenter (virtuellement/physiquement) des tables de dimension en utilisant la
fragmentation primaire
2. Fragmenter la tables des faits (en utilisant les schémas de fragmentation des
tables de dimension)
VENTE1 CLIENT1
Exemple PRODUIT Age  18
VENTE2 CLIENT2
Ventes1 Ventes1 Client1 18 < Age  30
Client Ventes1
Ventes Client1 Client1 TEMPS CLIENT3
VENTE3
Ventes2 Ventes2
Client2
Ventes2
30 < Age  40
Client2
Client2
VENTE4 CLIENT4
ventes3 ventes3
Age > 40
Fragmentation des TD Fragmentation de la TF Fragmentation indépendante Fragmentation des TD Explosion du nombre de fragments
de ma TF et des TD
+ Optimisation des - Pas d’optimisation des + Optimisation des sélection k
 Mi
+ Optimisation des sélections
N =
sélection jointures + Optimisation des jointures Mi : nombre de fragments de la table de dimension Di
- Pas d’optimisation des
- Pas d’optimisation de - Pas d’optimisation des - explosion du nombre de k : nombre de tables de dimension fragmentées
jointures
la jointure sélections fragments i =1
152 153
Représentation d’un schéma de fragmentation Fragmentation Dirigée par le Nombre de Fragments: Formalisation
Entrées
Décomposition des domaines des attributs de fragmentation en sous domaines
Codage d’un schéma de fragmentation • Entrepôt de données composé de
Age<18 18-30 30-45 45-60 >60
Exemple
Age 0 1 0 1 2
– Un ensemble D de tables de dimension D={D1, D2, …, Dd}
M F
❑Trois attributs de dimension: Genre 0 0 – Une table des faits F
Age, Genre, Saison été
t automne hiver printemps
Saison 0 0 0 1
• Charge de requêtes les plus fréquentes Q={Q1, Q2, …, Qm}
• W : seuil (fixé par l’administrateur)
Partition P0 Partition P1
Les tables sont fragmentées comme suit
Sorties :
Table Client en 3 fragments sur Age (Genre n’est pas utilisé)
–Client1 : Age <18 OU 30Age<45 – Ensemble D’ D des tables de dimension fragmentées
–Client2 : 18Age<30 OU 45Age<60 – Ensemble de N fragments de faits F1, F2, …, FN
–Client 3 : Age60 Table Ventes fragmentée en :
3x2=6 fragments Objectifs :
Table temps en 2 fragments sur Saison
–Temps 1 : Saison=été OU automne OU hiver – Réduire le temps d ’exécution de Q
–Temps2 : Saison=printemps – NW
154 155
NP-complétude du problème de fragmentation horizontale Algorithmes de sélection
Problème de fragmentation horizontale à un seul domaine (PFHSD)
– Une seule table de dimension
– Un seul attribut A composé de n sous domaines

❑Algorithme Génétique
– Nombre de schémas possibles : Nombre de Bell Bn
– Pour n grand alors Bnnn.

❑Algorithme de Hill Climbing
Réduction à partir du problème 3-Partition
– 3-Partition NP-Complet
– PFHSD NP-Complet ❑Algorithme de Recuit Simule

Le problème de fragmentation est plus compliqué
– Plusieurs tables de dimension
– Plusieurs attributs par table de dimension

k
– Nombre de schémas de fragmentation
B
i =1
ni
156 157
Algorithme de sélection : Algorithme Génétique Algorithme de Sélection: Hill Climbing
Principe
Extraction des prédicats de sélection Requêtes
1. Générer une solution initiale
- Fréquences 2. Améliorer itérativement cette solution
- Facteurs de sélectivité • Mesure de Qualité
Age 0 d’une
1 0Solution
1 2 Age 0 1 0 1 0
Génération des sous-domaines Genre 0 0
Merge(P0,P2, Age, SF)
0 0
– Modèle coût estimant le nombre d’entrées-sorties lors Genre
de l’exécution des requêtes.
Saison Saison
0 0 0 1 0 0 0 1
Solution initiale
6 fragments
Codage des chromosomes – Algorithme d’affinité
4 fragments
• Sous domaines sont groupés selon l’affinité (fréquence d’utilisation)
Sélection Amélioration
Age 0 1 0 1 0
Split(P0, Genre, SF’)
Age 0 1 0 1 0
Fonction d’évaluation
– Merge
Genre0 0 Genre 0 1
Saison Saison
•
0 0 0 1
Fusionner deux partitions en une seule.
0 0 0 1
Croisement Modèle de coût – Split 4 fragments 8 fragments
• Eclater une partition de sous domaines en deux partitions
Mutation
158 159
Algorithme de sélection : Recuit Simulé Validation sous Oracle(I)
Etat-Courant=Affinity
Même principe que HC T=T0 Problèmes rencontrés
Acceptation de mauvaises – FHP sur n (n>2) attributs n’est pas supportée.

Etat-Suivant = Voisin(Etat-Courant)
solutions – FHD sur (m >1) tables de dimension n’est pas supportée.

Oui Coût(Etat-Suivant)<Coût(Etat-
Eviter les optimums locaux. Courant)
Solutions
Non
Coût ( Etat − Courant) − Coût ( Etat − Suivant)  rand [ 0 ,1] Non

1. Méthode d’implémentation de la FHP (ajout d’une nouvelle propriété)
e T
Oui
2. Méthode d’implémentation de la FHD (vues matérialisée)
Etat-Courant=Etat-Suivant
 Nécessité de réécrire les requêtes sur les schémas fragmentés
Equilibre
• Identifier les fragments valides pour chaque requête

T=g(T)
• Réécrire la requête sur ces fragments
Gel
Fin
160 163
Validation Sous Oracle(II) Validation sous Oracle(III)
Ventes
Implémentation de la FHP sur plusieurs attributs Implémentation de la FHD en RIDS CID PID TID Montant ColFF
Col
1-1
–
1 616 106 11 25
Fragmentation de la table Client sur Age, Sexe, Ville utilisant plus d’une table de 2 616 106 66 28 1-2
1-1
– Age : Age<26, 26Age60, Age>60 → Range dimension 3
4
616
515
104
104
33
11
50
10 4-1
9-2
– Genre : M, F → Range-List Client
5 414 105 66 14
10-2
RIDC
CREATE MATERIALIZED VIEW V 6 212 106 55 14
1-2
– Ville : Poitiers, Paris, Nantes →? 6
CID
616
Nom
Gilles
Age Genre Ville
15AS M
Col
Poitiers
1
C 7
8
111
111
101
101
44
33
20
27 1-1
9 212 101 11 100 10-1
5 515 Yves 25 F Paris
SELECT v.CID, 4v.PID, v.TID, Montant, Col ||'-'||Col as Col
C 10 313 T
102 11 F 200 9-1
Clients masculins ayant moins de 26 ans habitant Poitiers 4 414 Patrick 33 M Nantes9 9-1
3 313 Didier 50FROM Ventes9v, Client c, Temps t
M Nantes
11 414 102 11 102
9-2
12 414 102 55 103
RIDC CID Nom Age Genre Ville ColC 2 212 Eric 40WHERE v.CID=10 c.CID
F Poitiers 4-2
13 515 102 66 100
6 616 Gilles 15 M Poitiers 1 1 111 Pascal 20 M Poitiers
1 14 515 103 55 17 4-2
Client 1 111 Pascal 20 M Poitiers 1
AND v.TID = t.TID 15 212 103 44 45 10-2
Temps 1-2
16 111 105 66 44
RIDC CID Nom Age Genre Ville ColC RIDT TID Mois Année Trimestre ColC 10-2
RIDC CID Nom Age Genre Ville ColC 17 212 104 66 40
6 616 Gilles 15 M Poitiers 1 6 11 Janvier 2003 Q1 1 RIDS CID 18PID 515 TID104 Montant
22 Col
20 F 4-1
5 515 Yves 25 F Paris 4 1-1
5 515 Yves 25 F Paris 4 5 22 Février 2003 1 616 19106 616 11104 22
25 1-1
20
VentesQ1
effectuées1 durant le premier
1-2
4 414 Patrick 33 M Nantes 9 RIDC CID Nom Age Genre Ville ColC 4 33 Mars 2003 Q1
trimestre par des1 clients masculins ayant 3 616 20104 616 33104 55
50 20
1-1
21 212 105 11 10 10-1
3 44 Avril 2003
moins Q2
de 26 ans 2et habitant Poitiers 8 111 101 33 27 1-1
3 313 Didier 50 M Nantes 9 4 414 Patrick 33 M Nantes 9 22 212 105 44 10 10-2
2 55 Mai 2003 Q2 2 19 616 23104 212 22105 20 1-1 10-2
2 212 Eric 40 F Poitiers 10 3 313 Didier 50 M Nantes 9 55 18
1 66 Juin 2003 Q2 2 24 212 106 11 18 10-1
1 111 Pascal 20 M Poitiers 1 RIDC CID Nom Age Genre Ville ColC 25 313 105 66 19 9-2
9-1
LES ENTREPOTS DE DONNEES - Data Warehouse
2 212 Eric 40 F Poitiers 10 LES ENTREPOTS DE DONNEES - Data Warehouse
26 313 105 22 17
164 27 313 106 11 15 165
9-1
164 165
Validation Sous Oracle (III)
Entrepôt global
Architecture Q
DataSet
W
Module de
sélection de SFH
(AG, RS, HC)
SF
Module de
fragmentation
Scripts
Fragments Horizontaux
Module de Q’
réécriture
AF RS AG HC
24,02
Millions
20,76 21,43
SÉLECTION MULTIPLE DE
25
17,60
20
Résultats TECHNIQUES D’OPTIMISATION

Temp(ms)
15
10

166
Classification des techniques Illustration des sélection isolée et multiple
❑ Sélection isolée : choisir une seule technique
❑ Sélection multiple : choisir plusieurs techniques
Première classification Critères

[Dexa 07] C1. Stockage
C2. Mise à jour
Deuxième classification
[Dawak 08]
Sélectionner les deux Sélectionner les deux

techniques d’une manière techniques
Administrateur indépendante simultanément
FH : Ceri 82, Bellatreche 00 IX : Chaudhuri 98, Golfarelli 02 FH, VM, IX : Sanjay 04, Zilio 04, Gebaly 08
FV : Navathe89 TP : Stohr 00 FH, IX, TP : Stohr 00
LES:Gupta
VM ENTREPOTS
99, DE
LeeDONNEES
01 - Data Warehouse VM, IX : Bellatreche 00, Aouiche 05 168 LES ENTREPOTS DE DONNEES - Data Warehouse 169
FH, FV : Stratos 04
Implémentation séquentielle Implémentation conjointe
• Plusieurs sélections isolées ❑ Considération d’un seul espace de recherche
❑ Utilisation d’un algorithme global
Algorithme de Instances ➔ Adaptée pour les techniques ayant de fortes similarités (Vues Matérialisées, Index)
sélection IX IX
Choix des
techniques
Algorithme de Instances
sélection des VM VM
Techniques candidates
• Inconvénient
– Absence de prise en compte des similarités et dépendances entre les techniques Techniques candidates
d’optimisation
– Une vue peut être indexée ➔ Sélectionner des vues ensuite des index pourrait être un ❑ Combinaison de plusieurs problèmes NP-Complets
scénario pertinent (ordre de sélection). ➔ Complexité élevée
Réduction de la complexité de l’implémentation conjointe Sélection combinée : HP&BJI
Deux types de dépendance [IBM’04] • La combinaison repose sur les similarités entre techniques d’optimisation
• Dépendance forte
• Approches de combinaison
– TO1 dépend fortement de TO2 : tout changement dans la sélection de TO2 ➔ changement dans
la sélection de TO1. – Séquentielle : chaque technique est sélectionnée indépendamment de l’autre
• Exemple : Si une vue V est sélectionnée, de nouveaux index sur V peuvent être sélectionnés. • Exemple : fragmentation horizontale et verticale
• Dépendance faible
• Inconvénient : Ne prends pas en compte les interactions entre les techniques
– TO1 dépend faiblement de TO2 : changement dans la sélection de TO2 n’affecte pas la sélection
de TO1. – Combinée : les techniques sont sélectionnées simultanément
• Un seul espace de recherche est considéré.
• Exemple : la sélection des vues et des index.
• Avantage : elle prend en compte les interactions inter-techniques
• Inconvénient : la complexité du problème augmente.

– Notre approche de combinaison
L’ordre de sélection Sélection simultanée

Ordre de sélection est important. • Utiliser la fragmentation horizontale pour élaguer (réduire) l’espace de recherche des
n’est pas important Si TO2 dépend fortement de TO1
des techniques index de jointure bitmap.
1. TO1
2. TO2
173
Exploitation de la similarité pour tuner Exemple
SELECT count(*)
FROM Ventes V, Client C, Produit P, Temps T
1. Sélectionner un schéma de fragmentation • ED WHERE V.CID = C.CID AND V.TID=T.TID AND V.PID=P.PID
• Requêtes
2. Déterminer les requêtes non bénéficiaires • Espace S
AND C.Ville = ‘Poitiers’ AND T.Mois=‘Juin’ AND
• Seuil W P.Catégorie=‘Beauté’
❑ Utiliser le taux  fixé par l’administrateur
❑ si( Coût(Q, FS )
) alors
 Q est bénéficiaire
Coût(Q,  ) Fragmentation
(GA, RS, HC, …etc.) ❑Fragmentation sur Ville et Mois
Coût(Q,) , Coût(Q,FS) : coût avant et après fragmentation ❑Fragment valide pour la requête est Ventes_PJ : Ventes effectuées le mois de juin par des clients de Poitiers
3. Déterminer les attributs candidats (BJIASET) Déterminer requêtes Client1=ville=Poitiers(Client)
Temps6=mois=juin(Temps)
non bénéficiaires Modèle de RIDC CID Nom Ville
❑ Attributs candidats = Attributs de faibles coût 6 616 Gilles Poitiers RIDT TID Mois Année
2 212 Eric Poitiers 1 66 Juin 2003
cardinalités dans les requêtes non Déterminer les attributs 1 111 Pascal Poitiers CAT_BJI
Candidats (BJIASET)
Ventes_PJ Catégorie
bénéficiaires et non utilisés pour fragmenter Produit
Algorithme Glouton RIDP PID Nom Catégorie RIDS CID PID TID Montant RID B M J Jr F
l’entrepôt 6 106 Sonoflore Beauté
5 105 Clarins Beauté 2 616 106 66 28 2 1 0 0 0 0
4. Sélectionner un ensemble de BJIs avec l’algorithme 4
3
104
103
WebCam
Barbie
Multimédia
Jouet 16 111 105 66 44 16 1 0 0 0 0
2 102 Manure Jardinage
glouton 1 101 SlimForm Fitness
17 0 1 0 0 0
17 212 104 66 40
• Schéma de fragmentation
• Configuration d’IJB
174 175
Validation
BJIFIRST HPFIRST (W=100) HPFIRST BJIFIRST (S=200 Mo)
18 7
Millions
Millions
16 6,5
14 6
12 5,5
10
I/O
5
I/O
8
4,5
6
4
4
3,5
2
3
0
100 500 1000 5000 10000
20 40 60 80 100 120 160 180 200
W
Space (Mo)
Sélection séparée (S) Sélection séparée (W)
NoneOp BJIFIRST HPFIRST HP&BJI

Our Approach Partitioning 24,49
Millions
8
Millions
25
7
6
20 14,95
5 13,73
12,27
I/O
4
Temp(ms)
15
3
2 10
1
0
0 0.2 0.4 0.6 0.8 1
5
Kamel Boukhalfa
Boukhalk@gmail.com
LAMBDA 0
Paramètre de tuning  Validation Oracle 10g

176

Cours - Datawarehouse

Transféré par

Informations du document

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

Cours - Datawarehouse

Transféré par

Droits d'auteur :

Formats disponibles

Présentation de l’Enseignant

Laboratoire des Systèmes Informatiques

• Pr. Kamel Boukhalfa

❑ Docteur de l’université de Poitiers-France et de l’USTHB

❑ Professeur depuis 2017

❑ Emails souvent utilisés

• Site Web personnel

Pr. Kamel Boukhalfa ❑ Production scientifique

Boukhalk@gmail.com ❑ Téléchargement de cours

LES ENTREPOTS DE DONNEES - Data Warehouse 2

❑ Big Data ❑ Techniques de Fouille de données

• Modélisation multidimensionnelle OLAP

• Optimisation des Entrepôts de données

Pourquoi et ❑ Caractéristiques de ces données:

– Détaillées: organisation des données selon les processus fonctionnels, données

organisé de façon spécifique, approprié à la prise de décision.

Un Entrepôt de Données (Data Warehouse)

• organisées pour le support d'un processus d'aide à la des données

❑ Recherche (Stanford 1995)

• Dispositif de stockage d’informations intégrées de Produit

3. Données non volatiles 4. Données datées

• Utilisateurs plus ciblés

❑ pas de réelle intégration des données

❑ différentes vues non-réconciliées

❑ les requêtes peuvent facilement bloquer

les transactions en cours

– Réalisation des transformations avant l’insertion dans le DW:

– Données souvent détruites après chargement dans le DW

– Donne accès aux données contenues dans le DW

• Rapports gestion des donnés entreposées.

Donnés sources données cibles Donnés sources données cibles

❑ Les données extraites doivent être marquées par “ horodatage ” afin

Service Service Service

Orienté application Orienté sujet

• Clarifier les objectifs spécifiques

• Permettre des extensions futures

• Offrir la formation pour les groupes d’intervenants

❑ Combien de clients âgés entre 20 et 30 ans et résidant à Alger ont-ils acheté

grand nombre d’incidents imprévisibles au cours de la période 1992-97 ?

Normalisation ▪ Plus fréquente ▪ Rare ❑ Catégorie de traitements dédiés à l’aide à la décision

Mise à jour ▪ immédiate ▪ Plus différée ❑Analyses diverses (multidimensionnelles)

105 12 65 90 92 105 Région Trimestre

dimensions TID Table des faits PID

❑ Variante du modèle en étoile Année Trimestre Jour Temps Produit

❑ Réduction de la redondance mais exécution parfois PID

Région Ville CID MID

define dimension branche as (Id_branche, nom_branche, type_branche)

❑Données fréquentes sont stockées comme tableaux multidimensionnels ❑Pivot

❑Données brutes dans ROLAP

❑Données agrégées dans MOLAP

❑Cette séparation est transparente pour l’utilisateur.

Optimisation des Entrepôts de • Grand volume de données (TB)

Données • Peu de mises à jour (ajout seulement!)

❑ Exigence des décideurs

Objectif Exécution rapide des requêtes ∀ la complexité des requêtes

Nécessité de techniques d’optimisation

- Sélectionner un ensemble de vues afin de maximiser ou

❑ Deux méthodes de maintenance ❑Processus supporté dans la plupart des SGBD

• Index de jointure: sur plusieurs tables dans un schéma en

❑ Problème de sélection d’index

• Création d’un index bitmap sur l’attribut A:

ROWID(RID) N°E Nom Fonction ROWID(RID) Soudeur Fraiseur Sableur Tourneur

• Jointure 00234 :020 :8922 2 Hichem Soudeur 00234 :020 :8922 1 0 0 0

• Agrégation 19000 :328 :6200 3 Salim Tourneur 19000 :328 :6200 0 0 0 1