Entreposage de Donnes et Aide la Dcision

1
Entreposage de Données et Aide à la Décision

• Chapitre 23, 23.828.10

2
Objectifs

• Entreposage de données OLAP vs OLTP
• Modèle de données multidimensionnelles
• Requêtes OLAP
• Design des données multidimensionnelles
• Techniques dimplémentation
• Vues et aide à la décision
• Matérialisation des vues
• Gestion et maintien des vues matérialisées

3
Vues et Aide à La Décision

• Les requêtes OLAP sont typiquement des requêtes
  dagrégats.
• Du prétraitement est essentiel pour des temps de
  réponse interactifs.
• Le CUBE est en fait une collection de requêtes
  dagrégat et du prétraitement est important à ce
  sujet le challenge majeur est de trouver ce qui
  doit être prétraité étant donné un espace limité
  disponible pour stocker le résultat du
  prétraitement.
• Un entrepôt de données peut être conçu comme une
  collection de table reproduite de manière
  asynchrone et comme des vues mises à jour
  périodiquement.
• Cela a attiré un intérêt renouvelé dans la
  maintenance des vues.

4
Requêtes sur les Vues Modification des Vues
(Evaluer sur Demande)
CREATE VIEW RegionalSales(category,sales,state) A
S SELECT P.category, S.sales, L.state FROM
Products P, Sales S, Locations L WHERE
P.pidS.pid AND S.locidL.locid
Vue
SELECT R.category, R.state, SUM(R.sales) FROM
RegionalSales R GROUP BY R.category, R.state
Requête
SELECT R.category, R.state, SUM(R.sales) FROM
(SELECT P.category, S.sales, L.state FROM
Products P, Sales S, Locations L WHERE
P.pidS.pid AND S.locidL.locid) AS R GROUP BY
R.category, R.state
Requête modifiée
5
Requêtes sur les Vues Matérialisation des Vues
(Prétraitement)

• Supposez que nous prétraitons RegionalSales et
  stockons le résultat avec un index B groupé sur
  category,state,sales.
• La requête de la page précédente peut être
  traitée au moyen dun scannage de lindex (
  index-only scan).

SELECT R.state, SUM(R.sales) FROM RegionalSales
R WHERE R.categoryLaptop GROUP BY R.state
SELECT R.state, SUM(R.sales) FROM RegionalSales
R WHERE R. stateWisconsin GROUP BY R.category
Utiliser lindex B sur la vue Matérialiséelocal
iser la 1ère Feuille qui satisfait la
clause WHERE et scanner à partir de là
Lindex sera peu utile (car un scannage de tout
le niveau des feuilles de larbre B est
nécessaire.
6
Vues Matérialisées

• Une vue dont les tuples sont stockées dans une
  base de données est dite matérialisée.
• Fournit un accès rapide (agit comme une mémoire
  cache).
• Besoin de maintainir la vue au fur et à mesure
  que la les tables sous-jacentes changent.
• Idéalement des algorithmes de maintenance
  incrémentale sont souhaitables.
• Concepts proches entreposage, OLAP, maintien
  asynchrone des bases de données distribuées,
  évaluation contraintes dintégrité et évaluation
  des triggers.

7
Matérialisation des Vues Problématiques

• Quelles vues matérialiser et quels indexes
  construire sur ces vues?
• Etant donnée une requête et un ensemble de vues
  matérialisées, peut-on utiliser ces vues pour
  donner une réponse à cette requête?
• Quelle fréquence utiliser pour rafraichir les
  vues matérialisées afin de le rendre consistantes
  avec les tables sous-jacentes?
• Comment effectuer le rafraichissement de manière
  incrémentale?)

8
Maintenance des Vues

• Deux étapes
• Propagation Calculer les changements aux vues
  lorsque celles-ci changent.
• Rafraichissement Appliquer les changements aux
  tables matérialisées.
• Une police de maintenance détermine quand
  rafraichir les vues.
• Maintenance immédiate La vue est synchronisée
  avec les tables sous-jacentes au moment de
  transaction qui modifie cette table
  sous-jacentes.
• La vue matérialisée sera toujours consistante.
• Les modifications sont ralenties.
• Maintenance différée La vue est synchronisée
  plutard dans une transaction séparée.
• La vue devient inconsistante.
• Plusieurs vues peuvent être facilement maintenues
  sans que les modifications soient ralenties.

9
Maintenance Différée

• Trois variantes
• Paresseuse retarder le rafraichissement jusquà
  la prochaine requête sur la vue et rafraichir
  juste avant de répondre à la requête.
• Périodique (Snapshot) Rafraichir
  périodiquement. Les requêtes sont traitées en
  utilisant des versions périmées de la vues (Cette
  variante est largement utilisée, spécialement
  pour des reproductions asynchrones dans les
  bases de données distribuées et dans les
  application dentreposage de données).
• Basée sur les événements p.ex. rafraichir après
  un nombre fixe de changements aux tables
  sous-jacentes.

10
Snapshots dans Oracle 7

• Une copie instantanée (snapshot) est une
  matérialisation locale dune vue stockée sur un
  site original.
• Rafraichissement périodique par reconstruction de
  la vue dans son entièreté.
• Rafraichissement rapide incrémental pour des
  instantanées simples
• chaque ligne dans la vue est basée sur une seule
  ligne dans une seule table sous-jacente
• aucun DISTINCT, GROUP BY
• aucune opération dagrégat aune sous-requête,
  aucun join ni opération ensembliste
• Les changements sur le site original sont
  journalisés par un trigger afin de supporter les
  copies instantanées.

11
Maintenance des Vues Problématiques
expensive_parts(pno) - parts(pno, cost), cost gt
1000

• Quelles infos sont disponibles? (Relations de
  base, vues matérialisées, contraintes
  dintégrité). Supposez que le tuple
  parts(p5,5000) est inséré
• Seule la vue matérialisée est disponible Nous ne
  pourrons pas dire si p5 est à insérer dans la vue
  ou pas tant que seule la vue est disponible.
• La table Parts est disponible Ajouter p5 à la
  vue sil ny a pas déjà un tuple p5 de Parts dont
  le coût est plus grand que 1000.
• (Parts pourrait ne pas être disponible si la vue
  est dans un entrepôt!)
• Si nous savons que pno est la clé de Parts Nous
  pouvons inférer que p5 nest pas déjà dans la vue
  et devons donc ly insérer.

12
Maintenance des Vues Problématiques (Suite)
expensive_parts(pno) - parts(pno, cost), cost gt
1000

• Quels changements doivent être propagés?
  (Insertions, effacements et modifications).
  Supposez que le tuple parts(p1,3000) est effacé
• Seule la vue matérialisée est disponible Si p1
  est dans la vue, il ny a pas moyen de dire si p1
  devrait être effacé ou pas.
• Si nous maintenons un compte (count --
  dérivations) pour chaque tuple de la vue, nous
  pouvons dire si p1 devrait être effacé ou pas
  (décrémenter le compte et effacer si le compte
  est 0).
• La table Parts est disponible Sil ny a pas
  déjà un tuple p1 de Parts dont le coût est plus
  grand que 1000, effacer p1 de la vue.
• Si nous savons que pno est la clé de Parts Nous
  pouvons inférer que p1 est déjà dans la vue et
  devons donc len effacer.

13
Maintenance des Vues Problématiques (Suite)

• Langage de définition des vue?
• Requêtes conjonctive (règles)
• commandes SQL appropriées
• Duplicatas
• Agrégats
• Récusions

14
Maintenance Incrémentale Insertions utilisant
une Règle
View(X,Y) - Rel1(X,Z), Rel2(Z,Y)

• Etape 0 Maintenir un compteur de dérivation pour
  chaque tuple de la vue.
• Etape 1 Calculer les ensembles de tuples delta1
  et delta2 correspondants aux relations Rel1 et
  Rel2 (delta1 et delta2 sont les ensembles de
  tuples insérés dans Rel1 et Rel2,
  respectivement).
• Etape 2 Calculer lensemble delta_new des tuples
  inserés dans la vue View(X,Y).
• Important les duplicatas ne sont pas effacés
  (maintenir un compteur de dérivation pour chaque
  nouveau tuple).
• Etape 3 Rafraîchir View(X,Y) en effectuant une
  union des multi ensembles delta_new et (I.e.
  mettre à jour les compteurs de dérivation des
  tuples existants et ajouter les tuples de
  delta_new qui nétaient pas dans View).

15
Maintenance Incrémentale Effacement utilisant
une Règle
View(X,Y) - Rel1(X,Z), Rel2(Z,Y)

• Etapes 0 - 2 Similaire aux insertions.
• Etape 3 Rafraichir la vue stockée en effectuant
  une différence des multi ensembles à la place de
  lunion.
• Pour mettre à jour les compteur de dérivation des
  tuples existants, nous devons soustraire les
  compteurs de dérivation des nouveau tuples de
  ceux des tuples existants.

16
Maintenance Incrémentale Algorithmes Généraux
Utilisant une Multitude de Règles

• Lalgorithme à compteur peut être généralisé aux
  vues définies par une multitude de règles de
  dérivations. Il peut aussi être généralisé aux
  requêtes SQL avec duplicatas, négation et
  agrégats.

17
Maintenance des Vues dEntrepôts
view(sno) - r1(sno, pno), r2(pno, cost)

• Principal changement Les vues sont dans un
  entrepôt de données et les tables sources sont
  autre part ailleurs (SGBS opérationnels, al DBMS,
  sources propriétaires, ).
• Lentrepôt est notifié de tout changement au
  niveau des tables sources (p.ex. lorsque un
  tuple est ajouté à r2)
• Lentrepôt peut nécessiter une information
  additionnelle au sujet des tables sources pour
  traiter un changement (p.ex. quest ce qui est
  dans r1 à linstant ?)
• La source répond avec linfo additionnelle et
  lentrepôt rafraichit la vue de manière
  incrémentale.

Problème Il peut y avoir des changements aux
sources entre les Etapes 1 et 3!
18
Subtilités de la Maintenance des Vues
view(sno) - r1(sno, pno), r2(pno, cost)

• Initialement r1(1,2), r2 est vide
• Exécution de insert r2(2,3) à la source r2
  notification de lentrepôt
• Lentrepôt enverra la requête dinfo
  additionnelle ?r1(sno,2) à r1
• Check pour trouver quel sno insérer dans la vue
• Exécution de insert r1(4,2) à la source
  notification de lentrepôt
• Lentrepôt enverra la requête dinfo
  additionnelle ?r2(2,cost) à r2
• Check pour voir si nous avons besoin
  dincrémenter le compteur de dérivation de
  view(4)
• Les sources r1 et r2 retourneront sno1, sno4 à
  lentrepôt ces valeurs iront dans la vue avec 1
  comme valeur du compteur de chacune de ces
  valeurs.
• La source reçoit la seconde requête et y répond
  positivement et incrémente ainsi le compteur de
  view(4).
• Ce résultat est faux! Car le compteur correct
  pour view(4) est 1!
• Doù la nécessité dalgorithmes sophistiqués pour
  la maintenance des vues dans un environnement
  distribué

19
Résumé

• Laide à la décision suppose la création de
  larges dépôts de données consolidées appelés
  entrepôts de données (data warehouses).
• Les entrepôts de données sont utilisés au moyen
  de techniques danalyse sophistiquées requêtes
  SQL complexes et requêtes OLAP pour données
  multidimensionnelles.
• De nouvelles techniques sont utilisées pour le
  design des bases de données, lindexage et les
  requêtes interactives.
• Les entrepôts de données sont des vues
  matérialisées qui exigent une maintenance au fur
  et à mesure que les sources de données changent.