Bases de données spatiales - Laboratoire d`Informatique de Paris 6

Master d’Informatique
Spécialité IAD
Module BDIA
niveau M2
Modèles de données avancés
Anne [email protected]
Plan
•
•
•
•
•
•
Introduction
Modèle de données spatiales
BD temporelles
BD multimedias
BD multidimensionnelles
Modèles semi-structurés
Modèle de données
• Transcrire, en termes compréhensibles par le système,
les informations du monde réel gérées par une
application.
• Représenter les données (structure)
• Manipuler les données (langage)
Modèle relationnel :
Relations et attributs
Algèbre relationnelle
Insuffisances du modèle relationnel
•
•
•
•
Opérations séparées des données
– procédures stockées non intégrées dans le modèle
Limites du modèle de données
– 1ère forme normale de Codd
– inadapté aux objets complexes (documents structurés)
– introduction de BLOB
Dysfonctionnement des langages
Mauvais support des applications non standards
– CAO, CFAO
– BD Géographiques
– Représentation du temps
– Gestion des versions
– Prise en compte du multimedia
– BD statistiques, aide à la décision, fouille de données
Modèle Objet
Concepts : objet, classe/type, héritage
• Objets complexes (utilisation orthogonale des
constructeurs ensemble, tuple, liste)
• Identité d’objet
• Extensibilité
• Langage de manipulation (OQL) complet
+
Exemple
Habite
Appartient
Voiture
nveh
couleur
marque
km
rouler()
Possède
Personne
nss
nom
prenom
datenais
vieillir()
dormir()
Loge
Appart.
étage
no
rue
code
ville
Boire
Inférieur
Buveur
type
état
boire()
Employé
fonction
salaire
primes
Supérieur travailler()
EmployéBuveur
Vin
cru
Bu_par millésime
degré
qualité
Bilan du modèle objet
• Puissance du pouvoir de modélisation (objets
complexes, héritage, encapsulation)
• Bien adapté aux applications non standards
• Un seul langage de programmation et de
manipulation de données
• Très peu de SGBD objet sur le marché : les
concepts principaux se retrouvent dans le
relationnel-objet (SQL3)
L'objet-relationnel
•
Relationnel (tables, attributs, domaine, clé) + Objet (collections,
identifiants, héritage, méthodes, types utilisateurs, polymorphisme)
•
Extension du modèle relationnel
– attributs multivalués : structure, liste, tableau, ensemble, ...
– héritage sur relations et types
– domaine type abstrait de données (structure cachée + méthodes)
– identité d'objets
Extension de SQL (SQL3)
– définition des types complexes avec héritage
– appels de méthodes en résultat et qualification
– imbrication des appels de méthodes
– surcharge d'opérateurs
•
Exemple de table et objet
Police Nom Adresse
Conducteurs
Conducteur Age
24
Paul
Paris
Paul
45
Robert
17
Accidents
Accident Rapport
134
219
037
Objet Police
Photo
Les concepts
• Extensibilité des types de données
– Définition de types abstraits
– Possibilité de types avec ou sans OID
• Support d’objets complexes
– Constructeurs de types (tuples, set, list, …)
– Utilisation de référence (OID)
• Héritage
– Définition de sous-types
– Définition de sous-tables
Bilan du modèle objet-relationnel
Puissance de modélisation de l’objet et compatibilité avec le
relationnel.
SQL3, standard en évolution, proposé par tous les grands
constructeurs (Oracle, Sybase, IBM, etc.), sous une forme
limitée.
Modèles de données spatiales
Modèles de données spatiales
• Modéliser les objets géographiques (SIG)
• Objet géographique (une ville, un fleuve, une
route…)
– Une description (attributs)
– Une composante spatiale
• Géométrie (forme)
• Topologie (localisation par rapport à d’autres objets)
• Comment modéliser la composante spatiale ?
Représentation et manipulation
• Types de base :
– Point
– Ligne
– Région
• Opérations spatiales
– Unaires
• Existence d’une propriété spatiale (résultat booléen)
• Calcul d’une longueur, d’une surface (résultat scalaire)
• Transformation spatiale, changement d’échelle, extraction
d’objets,… (résultat spatial)
– Binaires
• Prédicats topologiques, métriques (résultat booléen)
• Calcul de distance (résultat scalaire)
• Opérations ensemblistes (résultat spatial)
Utilisation du modèle relationnel
Représentation dans des tables :
– Un objet géographique est un n-uplet
– Les représentations spatiales se décomposent en plusieurs
relations :
Ex:
Pays (nom,capitale,population, id-frontiere)
Frontiere (id-frontiere,id-contour)
Contour (id-contour,ordre-point,id-point)
Point(id-point,x,y)
Requête
• Quels sont les contours de la France ?
Select F.id-contour, x, y
From Pays P, Frontiere F, Contour C, Point
PT
Where Nom=‘France’
And P.id-frontiere = F.id-frontiere
And F.id-contour = C.id-contour
And C.id-point = PT.id-point
Order by F.id-contour, ordre-point
Avantages et inconvénients
+ Utilisation de l’existant (moteur SGBD + SQL)
- Mauvaises performances
- Interrogation très lourde (beaucoup de jointures)
- Pas de calculs géométriques (tests d’adjacence,
extractions de fenêtres, etc.)
- Interface peu conviviale (manipulation de tables de
points)
- Difficultés à décrire les nouveaux types
Modèle de données spatiales
• Objectifs :
– Étendre la représentation logique des données aux données
géométriques (simplicité, représentation proche du monde
réel, indépendance des données)
– Intégrer au langage de requêtes les nouvelles fonctions
assurant les opérations applicables aux objets géométriques
– Représentation physique efficace
– Indexation efficace (les arbres B+ ne sont pas appropriés
aux données spatiales)
– Nouveaux algorithmes de jointure
Information géométrique
• Mode raster :
– Les données sont représentées dans une grille (tesselation)
de points ou de cellules.
– Une ligne ou une région se représente par des cellules
connexes
• Mode vecteur :
– Les points sont représentés par leurs coordonnées
– Les lignes sont des segments de droite
– Les régions sont des polygones (ensemble de points)
La plupart des SIG actuels utilisent le mode vecteur
Géométrie d’une collection d’objets
• Relations spatiales :
– adjacence, recouvrement, inclusion, disjonction
• Trois modèles pour représenter un ensemble d’objets
spatiaux et leurs relations spatiales :
– Modèle spaghetti
– Modèle réseau
– Modèle topologique
Modèle spaghetti
• Les objets sont représentés par des ensembles de
points.
– Ex : polygone A: <[3, 2], [3, 1], [2, 2.5], [1.5, 1.5],[3, 2]>
• Les relations topologiques sont calculées à la
demande
• Simple (représentation homogène sans restriction),
mais redondant (les frontières adjacentes sont
représentées deux fois) et peut comprendre des
incohérences (différentes sources d’information)
Modèle réseau
• Conçu pour représenter les réseaux (routier,
téléphone, électricité) :
– Deux concepts (nœuds et arcs)
– Un nœud est un point particulier qui relie une liste d’arcs
(possibilité de navigation). Les points normaux constituent
les lignes et les polygones.
– Le réseau peut être planaire (toutes les intersections sont
représentées par des nœuds) ou non planaire (seules les
intersections correspondant à un objet géographique sont
représentées)
• Description intrinsèque de la topologie
• Recherche optimale des chemins
• Pas d’information sur les relations entre objets 2D.
Modèle topologique
• Semblable au modèle réseau, mais toujours planaire.
• Décomposition planaire de l’espace en faces : une région est
représentée par une ou plusieurs faces adjacentes
[3,9]
a
[2,6.5]
b
1
[3,7]
d
2
c
[3,3]
[5.5,9]
e
[3,5] g
[4,3]
f
Region : <face1, face2>
Face1: <a,b,c,d>
Face2: <d,e,f,g>
Noeud1: <[3,7], <a,d,e>>
Arc a : <noeud1,[2,6.5],face 3, face 1, [3,9]>
Modèle topologique
• Calcul efficace des requêtes topologiques
(notamment l’adjacence)
• Cohérence des mises à jour, grâce au partage
d’objets
• Certains objets n’ont pas de sens dans les
applications réelles
• Structures complexes, et calculs coûteux
Modèles de données spatiales (1)
• Extension du relationnel avec des ADT
Type Region
PointInRegion : region x point -> bool
Overlaps: region x region -> bool
OverlapsRect: region x rectangle -> bool
Intersection: region x region -> region
Meets: region x region -> bool
Area: region -> real
• Certaines opérations ne peuvent être définies : intersection
(ligne et rectangle), union de lignes, etc. La sémantique est
difficile à préciser.
• L’interrogation s’effectue avec une extension de SQL aux
ADT
Modèles de données spatiales(2)
• Dans le modèle objet, les objets géographiques et les objets
spatiaux sont représentés de façon homogène (classes)
Class Node tuple(x:real, y:real, endpoints:list(Arc))
Class Arc
tuple(origin: Node, destination: Node, left: Polygon,
right: Polygon, vertices: list(tuple(x:real, y:real));
Class Line list(Arc)
Class Polygon
tuple (bundary: list(Arc), in_region : Region)
Class Region set(Polygon)
method PointInRegion (p:Point) in class Region: boolean
method intersection (r:Region) in class Region : Region
…
• Interrogation avec OQL
Bases de données contraintes
• Cadre théorique pour représenter l’information
géographique : modéliser un ensemble infini de
points dans un espace multidimensionnel de manière
finie et concise.
• Un objet est représenté par des contraintes linéaires
dans l’espace.
• Un polygone convexe est représenté par une
conjonction d’inéquations dans le plan.
• Les requêtes sont exprimées en logique du premier
ordre.
Exemple
P2(4,4)
P3(7,3)
P1(1,1)
Représentation du polygône :
y ≤ x ^ x ≤ 7 ^ y ≥ 1 ^ x+ 3y -16 ≤ 0
P4(7,1)
R x y
----------------1 1
7 3
4 4
7 1
Bases de données contraintes
• Modèle indépendant de la dimension de l’espace
(manipule des données à 2 ou 3 dimensions), mais la
complexité croit exponentiellement avec la
dimension.
• Langage de requêtes puissant, qui permet de répondre
efficacement à des requêtes complexes (bonne
optimisation).
• Bon candidat pour la modélisation spatio-temporelle
L’existant
• Standards : AFNOR, ANSI, ISO, BSI, FGDC, OPENGIS
consortium, ISO TC/211, OGDI…
• SIG :
– ArcInfo (1982) : fournit de nombreuses fonctions spatiales +
–
–
–
–
interfaces graphiques
ArcView : outils pour l’édition de cartes, analyse spatiale, échange
de données.
Smallworld : créé pour la CAO. Représentation de relations
topologiques
Oracle spatial : type de données spatial SDO_GEOMETRY +
extension de SQL + index spatiaux
PostgreSQL : types géométriques et opérateurs +extension spatiale
de SQL + R-tree
Bases de données temporelles
Bases de données temporelles
– Introduction et problématique
– Différentes approches de BD temporelles
– Modélisation et représentation du temps
– Langages de requêtes temporels
– Conception de BD temporelles
Introduction (1/6)
Beaucoup d'applications ont besoin de gérer le temps dans leur BD :
– gestion des enseignements d'une UFR
– comptabilité
– budgets
– entrepôts de données et olap
– gestion des stocks
– S.I.G
– assurances
– BD légales
– médecine
– réservations etc.
Introduction (2/6)
• Quasiment toutes les applications ont besoin du temps
• Intérêt de leur fournir des fonctionnalités temporelles
directement dans le SGBD, sinon...
Exemple :
Nom
Toto
Toto
Toto
Toto
Salaire
60000
70000
70000
70000
Titre
assistant
assistant
MCF
Prof
DateNais Start
Stop
12 05 65 01 01 91 31 09 96
12 05 65 01 10 96 31 09 97
12 05 65 01 10 97 31 09 98
12 05 65 01 10 98 01 01 00
• premiers pbs :
– an 2000 !
– DateNais et Nom ne varient pas.
– salaire de Toto au 10 01 2000 ?
Introduction (3/6)
• requêtes simples deviennent compliquées :
– quel est le salaire actuel de Toto ?
select Salaire from Employés
where Nom = 'Toto'
and Start <= CURRENT_DATE
and Stop >= CURRENT_DATE
} devrait être implicite
– quel est l'historique du salaire de Toto ?
Résultat
Nom
Toto
Toto
Salaire Start
60000 01 01 91
70000 01 10 96
Stop
31 09 96
01 01 00
Introduction (4/6)
– Il faut trouver tous les intervalles de temps
"fusionnables" pour lesquels le salaire de Toto est
le même : coalescence
• Très compliqué et coûteux en SQL directement (pire
que division)
• par programme : non-déclaratif
• changer schéma en (Nom, Salaire, Start, Stop), (Nom,
Titre, Start, Stop) ne marche que pour une requête
• Triggers : doivent être programmés
Coalescence
• Associer un fait à sa durée maximale de validité
• Les tables de la base sont maintenues coalescentes
• Certaines requêtes peuvent retourner des résultats noncoalescents (projection, union...)
Nom
Toto
Toto
Toto
Visité
Londres
Berlin
Lisbonne
quand?
01 01 91 projection sur Nom
01 10 96
01 10 97
Nom
Toto
Toto
Toto
quand?
01 01 91
01 10 96
01 10 97
• Fusionner les intervalles est très coûteux
– problème d’optimisation de requête
– similaire à l’élimination des doublons
– cas bitemporel : 2 possibilités (max TT ou max TV)
Introduction (5/6)
• Jointure temporelle : «historique des employés avec leur titre et
salaire»
Nom
Toto
Toto
Salaire
60000
70000
Start
Stop
01 01 91 31 09 96
01 10 96 01 01 00
Nom
Toto
Toto
Toto
Titre
assistant
MCF
Prof
Start
01 01 91
01 10 97
01 10 98
Stop
31 09 97
31 09 98
01 01 00
Il faut exprimer la condition de jointure pour tous les cas possibles
(4) entre l'intervalle pour le salaire et l'intervalle pour le titre
Intervalle Salaire
Intervalle Titre
1
2
3
4
Introduction (6/6)
• L'utilisation d'un SGBD temporel permet
– des schémas plus simples
– des requêtes plus simples
• select Salaire from Employes where Nom = 'Toto'
• select Employes1.Nom, Salaire, Titre
from Employes1, Employes2 where Employes1.Nom =
Employes2.Nom
– moins de code procédural
• Bénéfices :
– code des applis. moins complexe
– plus facile à produire, à corriger, à maintenir
– meilleures performances car sous contrôle du SGBD
SGBD temporels : différentes approches (1/2)
• Sans changer la technologie existante :
– utiliser un type date et programmer tous les traitements
• requêtes complexes, traitements coûteux, erreurs
possibles
• maintenance compliquée: modif. dans les programmes
– utiliser un ADT pour le temps
• il faut que le SGBD offre des ADT (OO et OR)
• Simplifie les requêtes et les traitements
• uniformité si l'ADT est en bibliothèque
• pas d'optimisation possible sur la sémantique du temps
SGBD temporels : différentes approches (2/2)
• En changeant la technologie
– Extension d'un modèle existant
• utiliser les concepts existants pour définir des concepts temporels (si
possible)
• approche la plus utilisée
• ajout d'opérateurs à l'algèbre (ex. jointure temporelle)
• avantage : ne pas redéfinir tout le SGBD
• inconvénient : manque de généralité et d'extensibilité (seuls certains
concepts sont rendus temporels)
– Généralisation d'un modèle existant
• tous les concepts et opérations sont rendus temporels (schéma,
données, IC...)
• le temps est orthogonal au reste
• plus compliqué et coûteux àmettre en oeuvre
Modélisation du temps : concepts (1/2)
• Instant :
– point temporel dans le monde réel
• Structure du temps :
– linéaire, avec alternative, périodique
• Limites du temps:
– Illimité, avec origine (limite inf.), limité (limites inf. et sup.)
– limites connues ou inconnues
• Densité du temps:
– Discrète (isomorphe à N), dense (isom. Q), continue (isom. R)
– le plus raisonnable a représenter : temps discret limité (ou origine)
• Chronon (temps discret) :
– plus petite unité de temps représentable
– un événement a lieu en t si il a lieu en un instant appartenant au
chronon t.
Modélisation du temps : concepts (2/2)
• Intervalle temporel :
– période de temps ayant un début et une fin
• Elément temporel :
– ensemble d'intervalles temporels (ex. les vacances)
• Manipulation des intervalles :
– vu comme des ensembles d'instants : par union, différence....
Le résultat peut être un élément temporel
– comparaison par les prédicats d'Allen
• Période de vie :
– période pendant laquelle un objet existe
Prédicats d'Allen [1983]
Jeu complet de prédicats pour manipuler les intervalles de temps
– I1 before (after) I2
«précède»
I1
I2
– I1 during (contains) I2
«pendant»
I1
I2
– I1 overlaps (overlapped_by) I2
«chevauche»
I1
I2
– I1 meets (met_by) I2
«jouxte»
I1
I2
– I1 starts (started_by) I2
«commence»
I1
I2
– I1 finishes (finished_by) I2
«finit»
I1
I2
– I1 equal I2
I1
I2
Modélisation du temps : notions de temps
• Temps utilisateur :
– non-interprété par le système, uniquement par l'utilisateur
– ex : date de naissance
• Temps de validité :
–
–
–
–
indique quand un fait est valide dans le monde réel
passé et futur. Alternatives possibles.
utilisé dans les requêtes et les contraintes.
now : présent dans le monde réel
• Temps de transaction :
–
–
–
–
indique quand un fait est enregistré dans la BD
utilisation : tracer les erreurs et corrections, croyance...
uniquement passé et linéaire
until-change : état courant de la BD
• Autres : temps de décision, etc...
Différents type de BD temporelles
• BD snapshot : non-temporelle
• BD historique :
– type le plus répandu
– temps de validité = histoire du monde réel
– besoin de langage de requête sophistiqué (raisonnement
temporel)
• BD rollback :
– temps de transaction : stocke les états successifs de la BD
– peut être utilisé pour du versionnement linéaire
• BD bi-temporelle :
– temps de validité + temps de transaction
– propriétés des BD historiques et de BD rollback
Estampillage temporel des données (1/6)
• Association du temps aux items de la BD
• Dépend de :
– la granularité de ce qui est estampillé
•
•
•
•
tuples
objets
la BD entière
attributs
– la nature des estampilles temporelles
•
•
•
•
instants
intervalles
éléments temporels
avec ou sans alternatives
Estampillage temporel des données (2/6)
• Estampillage de tuples :
– chaque dimension temporelle correspond à 1 (ou +)
attributs spéciaux
– approche par extension de technologie
– pb :
• fragmentation verticale des données d'un même item sur
plusieurs tuples
• redondance pour les attributs qui varient peu ou pas (ex.
DateNais)
Nom
Toto
Toto
Toto
Toto
Salaire
60000
70000
70000
70000
Titre
assistant
assistant
MCF
Prof
DateNais Start
Stop
12 05 65 01 01 91 31 09 96
12 05 65 01 10 96 31 09 97
12 05 65 01 10 97 31 09 98
12 05 65 01 10 98 01 01 00
Estampillage temporel des données (3/6)
• Estampillage d'objet
– même principe que tuple
– selon la granularité des sous-objets
• augmentation de la fragmentation horizontale
• diminution de la redondance : seuls les oid sont dupliqués
– peut utiliser versions d'objet pour le stockage des
différentes valeurs
oid
1
1
1
1
oid
2
Nom
Toto
Toto
Toto
Toto
Salaire
60000
70000
70000
70000
DateNais LieuNais
12 05 65 strasbourg
Titre
assistant
assistant
MCF
Prof
Start
12 05 65
Naissance
<2>
<2>
<2>
<2>
Stop
forever
Start
01 01 91
01 10 96
01 10 97
01 10 98
Stop
31 09 96
31 09 97
31 09 98
01 01 00
Estampillage temporel des données (4/6)
• Estampillage de toute la BD
– gestion des estampilles plus simple
– nécessite gestion de version par identification globale
oid
1
1
1
1
Nom
Toto
Toto
Toto
Toto
Salaire
60000
70000
70000
70000
oid
2
DateNais LieuNais
12 05 65 strasbourg
Titre
assistant
assistant
MCF
Prof
Naissance
<2>
<2>
<2>
<2>
Start
12 05 65
01 01 91
01 10 96
01 10 97
01 10 98
02 01 00
Stop
31 09 90
31 09 96
31 09 97
31 09 98
01 01 00
forever
Estampillage temporel des données (5/6)
• Estampillage d'attributs
– nécessite un modèle de données NF2
– granularité la plus fine donc redondance minimum
– gestion et requêtes plus compliquées
Nom
Toto
Salaire
Titre
(60000, 01 01 91, 31 09 96), (assistant, 01 01 91, 31 09 97),
(70000, 01 10 96, 01 01 00) (MCF, 01 10 97, 31 09 98),
(Prof, 01 10 98, 01 01 00)
DateNais
12 05 65
Estampillage temporel des données (6/6)
• Estampillage par des instants
– instant associé à un événement du monde réel
– Simple mais ne représente que
des événements discrets
Nom
• Estampillage par intervalle
Nom
Toto
Toto
Toto
Toto
Toto
Toto
Visité
Londres
Berlin
Lisbonne
Salaire
60000
70000
60000
– début et fin d'un fait.
– valeur spéciales: now, until-change, forever
– redondance si même valeur pour des intervalles disjoints
quand?
01 01 91
01 10 96
01 10 97
Start
01 01 91
01 10 96
01 10 98
Stop
31 09 96
31 09 98
now
• Estampillage par élément temporel
– pas de redondance
– beaucoup plus compliqué (parcours de liste)
• Autres (intervalles chevauchants...)
Nom
Toto
Salaire
60000
Toto
70000
élément tempo.
(01 01 91, 31 09 96) ,
(01 10 98, now)
(01 10 96, 31 09 98)
Langage de requêtes temporels
Logique temporelle (1/2)
• Logique du premier ordre / états + connecteurs temporels
–
–
–
–
–
–
considéré par rapport à un état courant
previous A (•A): A était vrai dans l’état précédent
next A (ο A): A sera vrai dans l’état suivant
A since B : A a été vrai depuis que B a été vrai
A until B : A sera vrai jusqu’à ce que B sera vrai
on peut construire d’autres connecteurs
• ♦A : true since A (A a été vrai au moins une fois dans le passé)
• ◊ A : true until A (A sera vrai au moins une fois dans le futur)
• A : ¬♦¬A (A a toujours été vrai dans le passé)
• A : ¬◊¬A (A sera toujours vrai dans le futur)
Langages de requêtes temporels
Logique temporelle (2/2)
• On suppose une base de données qui donne pour chaque
année indep(pays,ville) si pour cette année là, le pays était
indépendant et avait ville pour capitale
• En quelles années la Pologne était indépendante et pas la
Slovaquie (les états pour lesquels la formule est vraie)?
(∃Ville) (indep(‘Pologne’,Ville) ∧ ¬(∃Ville2)indep(‘Slovaquie’,Ville2) )
• Quelle ville a supplanté Cracovie à la tête de la Pologne et en
quelle année ?
(indep(‘Pologne’,Ville)∧Ville ≠ ‘Cracovie’) since
indep(‘Pologne’,‘Cracovie’)
• Quels pays ont perdu et regagné l’indépendance
(∃S1, S2)(♦ indep(X,S1) ∧ ◊ indep(X,S2) ∧ (∀S) ¬ indep(X,S)
Langages de requêtes temporels
TSQL2 (1)
• Langage de requêtes pour le modèle relationnel bitemporel
BCDM. Estampillage des tuples par éléments bitemporels
• Projet démarré en juillet 93 pour trouver un consensus après 15
ans et plus de 650 articles et 24 propositions de langages
• Création d’un table temporelle en ajoutant en fin de create table :
– as valid <granularité>
table historique
– as transaction
table rollback
– as valid <granularité> and transaction
table bitemporelle
create table Magasins(NomMag, budget, responsable) as valid state day
create table Employés(NomEmp, mag, salaire) as valid state day
create table Ventes(codeMag, ventes) as valid event day
(«state» : ensembles d’instants, «event» : instant)
Langages de requêtes temporels
TSQL2 (2)
Problèmes : Le nom peut changer avec le temps. Échelle de temps
homogène.
create table Magasin (NomMag, Budget, Resp_ID) as valid state
create table Employés (ID surrogate, Nom, Mag, Salaire) as valid state
ID
NomMag
Budget
Resp_ID
Validité
Nom NomMag Salaire
Validité
ED
Ed
Jouets
20
{[2/1/82 – 5/31/82]}
ED
Ed
Jouets
30
{[6/1/82 – 1/31/85]}
Jouets
150
DI
{[1/1/82 – 7/31/84]}
ED
Ed
Jouets
40
{[2/1/85 – 1/31/87]}
Jouets
200
DI
{[8/1/84 – 12/31/86]}
ED
Ed
Livres
40
{[4/1/87 – 12/31/87]}
Jouets
100
DI
{[1/1/87 –now]}
ED Edward
Livres
40
{[1/1/88 – now]}
DI
Di
Jouets
30
{[1/1/82 – 7/31/84]}
DI
Di
Jouets
40
{[8/1/84 – 8/31/86]}
DI
Di
Jouets
50
{[9/1/86 – now]}
Livres
150
ED
Now = 1/1/90
{[4/1/87 – now]}
Langages de requêtes temporels TSQL2 (3) :
requêtes « snapshot »
• «Qui a travaillé au magasin de jouets le 2 mars 83 ?»
select snapshot Nom from Employés as e
where NomMag = ‘Jouets’ and valid(e) contains date
‘3/2/83’
–
–
–
–
–
snapshot : renvoie un résultat non historisé
valid(e) : retourne l’intervalle de temps correspondant à e
date : génère un type instant sous forme de date
x contains y : vrai si y appartient à x
Résultat : {(‘Ed’), (‘Di’) }
Langages de requêtes temporels TSQL2 (4) :
requêtes « snapshot »
• «Quels employés ont eu le même salaire pendant une période
continue > 3ans ?»
select snapshot E2.Nom from Employés(ID, Salaire) (period)
as e1, e1(Nom) as e2
where cast(valid(e1) as interval year) >= interval ‘3’ year
–
–
–
–
period : force la coalescence
cast( x as …) : transformation
interval : génère une durée
Résultat : {(‘Di’)}
Langages de requêtes temporels TSQL2 (6) :
requêtes « time-varying »
«Quelles sont les périodes au magasin de jouets pour des employés qui
sont resté plus de 8 ans ?»
select valid(e) from Employés(ID) (period) as e
where NomMag = ‘Jouets’ and cast(valid(e) as interval year) >
interval ‘8’ year
– Résultat : { ( [1/1/82 - now ] ) }
Langages de requêtes temporels TSQL2 (7) :
requêtes « time-varying »
• «A quelles dates a-t-on réembauché quelqu’un après plus d’un
mois ?»
select begin( valid(e2) ) from Employés(ID) (period) as e1, e2
where (e1.id = e2.id) and valid(e1) precedes valid(e2)
and ( end( valid (e2)) – begin(valid( e1 )) month ) >
interval ‘1’ month
– Résultat : {(4/1/87)}
Langages de requêtes temporels
ATSQL2 (1)
• Reprend les principes de TSQL2 pour la norme SQL3
• prototype TimeDB
• gère tables temporelles et non-temporelles
create table Employés(codeEmp, nom, salaire, fonction, codeChef)
alter table Employés add validtime period (date)
Langages de requêtes temporels
ATSQL2 (1)
• compatibilité ascendante temporelle (TUC) : toute requête sur
une relation rendue temporelle est évaluée sur l’état courant.
Permet la migration des applications : si on ne précise rien, la
BD réagit comme une BD non temporelle avec l’état courant
select max(salaire) from Employés retourne le salaire max
actuel
• sémantique point par point (SEQ) : évalue la requête pour
chaque état et retourne un résultat temporel
validtime select max(salaire) from Employés
retourne une relation associant chaque max avec sa période de
validité
Restriction de la période de validité du résultat :
validtime period ‘[1/1/85 – 12/31/86]’ select nom, salaire
from Employés
Langages de requêtes temporels
ATSQL2 (2)
• sémantique inter-états (NSEQ) : permet de comparer des
états. Clause nonsequenced + extensions du langage pour
manipuler les estampilles
– construire un intervalle, extraire début et fin d’un intervalle
– prédicats équivalent à ceux d’Allen
NonSequenced ValidTime
select E1.nom from Employés as E1, Employés as E2
where E1. codeEmp = E2. codeEmp and E1.salaire >
E2.salaire
and validtime(E1) meets validtime(E2)
«quels employés ont vu leur salaire diminuer au moins une fois?»
Langages de requêtes temporels
ATSQL2 (3)
• Contraintes d’intégrité
create assertion verif_salaire
Validtime period ’[01-01-86 - 01-01-87]’ check
(not exists (select * from Employés where salaire < 3000 and
fonction like ‘responsable*’))
constraint u_nom1 unique nom
constraint u_nom2 validtime unique nom
constraint u_nom3 nonsequenced validtime unique nom
Langages de requêtes temporels ATSQL2 (4)
•
Typologie de requêtes bitemporelles
– TUC/TUC : qui gagne actuellement mieux que son chef (à ce qu’on en
sait) ?
– SEQ/TUC : qui a un jour gagné plus que son chef ?
– TUC/SEQ : de qui a-t-on pensé qu’il gagne plus que son chef ?
– NSEQ/TUC : qui a gagné plus que son chef n’a jamais gagné ?
– TUC/NSEQ : quand a-t-on pensé que quelqu’un gagne plus …
– SEQ/SEQ : quand a-t-on pensé que quelqu’un a un jour gagné plus que
son chef (au même moment) ?
– SEQ/NSEQ : quand a-t-on modifié la base pour stocker que quelqu’un
avait un jour gagné plus que son chef au même moment. ?
– NSEQ/SEQ : de qui a-t-on pensé à un moment qu’il avait gagné plus
que son chef n’avait jamais gagné ?
– NSEQ/NSEQ : quand a-t-on modifié la base pour stocker que
quelqu’un avait gagné plus que son chef n’a jamais gagné ?
Langages de requêtes temporels
Tempos (1/2)
• BD OO historique. LSR-IMAG Grenoble.
• Extension de ODMG : modèle de données,
langage de définition et langage d’interrogation
• modèle multi-granulaire du temps
• modèle d’historiques. Propriétés temporelles des
objets : instance du ADT Historique
Langages de requêtes temporels
Tempos (2/2)
• «Combien de temps l’employé 10 a t-il été responsable du magasin
de code 10 ?»
select duration(m.responsable as r when r.codeEmp = 10)
from Magasins as m where m.codeMag = 100
/* m.responsable : objet, r.codeEmp : attribut */
• «Quand l’employé 10 a t-il été mieux payé que l’employé 20 ?»
select duration(tjoin(sal10: e10.salaire, sal20: e20.salaire)
as couple when couple.sal10 > couple.sal20 )
from Employé as e10, Employés as e20
where e10.codeEmp = 10 and e20.codeEmp = 20
/* tjoin prend en entrée 2 historiques et renvoie un historique */
Conception de schéma de BD temporelle
• dans une BD relationnelle classique, on utilise la notion de
dépendance fonctionnelle :
– X Y ensembles d’attributs de R, schéma de relation
– X →Y si pour toute instance r(R)
∀ t1, t2 ∈ r, ( t1.X = t2.X) ⇒(t1.Y = t2.Y)
• cette notion se généralise directement pour un schéma de
relation temporelle en dépendance fonctionnelle temporelle:
T
– X → Y si pour toute instance r(R)
∀ t1, t2 ∈ r, ∀tv, tt (Γtv,tt t1.X = Γtv,tt t2.X) ⇒ (Γtv,tt t1.Y = Γtv,tt t2.Y)
Γtv,tt t1.X : valeur de t1.X pour les temps de validite tv et de trans. tt
Conception de schéma de BD temporelle
• La notion de dépendance fonctionnelle temporelle
permet de généraliser directement les notions de clé
et de formes normales (en remplaçant DF par DFT).
• Pb: T-BCNF n’empêche pas certaines anomalies
(nulls, redondance)
• Il faut utiliser d’autres concepts pour mieux
décomposer les schémas (périodicité de mise à jour,
par exemple).
Bases de données multimédias
Contenu
• BD Multimédia :
–
–
–
–
Caractéristiques
Modélisation
Interrogation
Architectures des SGBD multimédias
Volume des données
• Quelques chiffres…
– 100 lignes de fax : 6,4 MO
– 100 images couleur 500 MO
– 1 heure de vidéo : 1 GO
• Stockage
– Compression indispensable, mais cela a un coût (temps)
– Hiérarchies de mémoires, plusieurs supports (complique le
fonctionnement du SGBD)
• Efficacité de la recherche
– Index adaptés
Types de données
• Texte
– Les modèles classiques ne permettent pas le traitement efficace de
documents fortement structurés
• Image
–
–
–
–
–
Nombreuses applications
Description externe + description du contenu
Recherches sur le contenu
Différents codages, différentes normes
Visualisation des résultats
• Sons
– Pbs: recherche et traitement
• Vidéo
– Séquences d’images fixes ?
– Interrogation des vidéos (séquences où Belmondo se bat en duel)
– Opérations de type magnétoscope
Texte
• Difficile de définir un schéma, prenant en compte les
spécificités de chaque document : structure
hiérarchique de profondeur arbitraire, structure
hypertextuelle
• Problème de l’interrogation : parcourir, filtrer,
extraire et reconstruire, transformer, présenter
• Solutions : SGML, XML pour la représentation,
XQuery pour la manipulation.
Image
• L’image est décrite par des caractéristiques propres et
par des relations (sémantiques, fonctionnelles,
spatiales) avec d’autres objets.
• Modélisation : matrice de pixels (stockée à part
parfois)
• L’interrogation se fait sur
–
–
–
–
–
Les attributs descriptifs,
La similarité avec d’autres images (couleur, texture, forme)
Les propriétés spatiales
La texture,
La détection de contour
Son
• Donnée continue (prise en compte du temps)
• Deux façons principales de décrire le son :
– techniques de traitement du signal (séquence de
cellules codant la fréquence ou l’amplitude du
signal).
– Métadonnées décrivant le contenu (souvent fait
manuellement)
• Extraction d’informations (intensité, volume,
rythme…) pour indexer le contenu d’un son.
Vidéo
• Problèmes
–
–
–
–
–
Stockage (avec ou sans compression, différentes normes)
Modélisation
Indexation
Recherche et interrogation
Vidéo à la demande
• Modélisation
– Contenu et structure sémantique
– Structuration hiérarchique : Film, scènes, séquences, plans,
images
– Annotation manuelle (ou semi-automatique) des segments
vidéos
Interrogation de vidéos
• Indexation :
– Description du contenu visuel : couleur, texture,
mouvement des objets, mouvement de caméra, description
des objets, relations spatiales entre objet, changement de
scènes
• Interrogation :
– Langage déclaratif (SQL, OQL) + techniques spécifiques
pour interroger sur la nature visuelle, auditive, temporelle
et spatiale des données
• recherche d’images (coucher de soleil, contenant un personnage
habillé de rouge, image de la tour Eiffel, …)
• Recherche dans des séquences vidéo
• Recherche de séquences (audio, vidéo), d’objets, de mouvements,
de propriétés
SGBD Multimédias
• Stocker les objets de grande taille, en très
grande quantité (1012, 1015, 1024 octets)
• Modèles et langages spécifiques
• Interfaces spécifiques
• Index
• Performances acceptables
• Gérer les aspects temporels et spatiaux
Architecture fonctionnelle
Interface utilisateurs
Présentations multimédias
Serveur d’objets
Schéma, stockage, objets complexes, index,
transactions
Architecture physique
Client
SGBD Multimédia
SGBD
Serveur
de texte
Serveur
d’images
Serveur
données
sons et video
Métadonnées
Texte
Images
Son
video
Bases de données multidimensionnelles
BD Multidimensionnelles
•
Les applications d’aide à la décision (OLAP, Decision Support System,
Datamining) s’appuient sur des entrepôts de données, qui sont de grandes
collections d’informations provenant des diverses BD de l’entreprise.
•
Les objectifs principaux des entrepôts de données sont
– regrouper, organiser, coordonner des informations provenant de sources diverses,
– les intégrer et les stocker pour donner à l’utilisateur une vue orientée métier,
– retrouver et analyser l’information facilement et rapidement.
•
Question typique : Quels sont les produits qui se vendent le mieux dans chaque région, et
quel est l’impact des données démographiques sur ces résultats de vente ?
•
Un entrepôt de données est un système informationnel construit à partir des
systèmes opérationnels. Pour des raisons de performance, cette BD pour
l’aide à la décision est séparée des bases de données opérationnelles.
Architecture
données externes
(connaissances, règles)
datamart
datamart
olap
entrepôt
datamart
données de production
(y.c. Systèmes légués)
META-MODELES
datamart
On-Line Analytical Processing (OLAP)
& BD multi-dimensionnelles
• Comment modéliser les informations pour ce type d’applications ?
• Evolution des structures de données stockées : fichiers, bases de données
hiérarchique, bases de données relationnelles, bd. distribuées, bd. objet (multimedia).
de + en + près de la façon dont les gens visualisent et manipulent les données
• Bases de données relationnelles [Codd70] :
• Modèle simple : tables bi-dimensionnelles. Facile à mettre en oeuvre.
• Le plus répandu. La plupart des entrepôts ont leurs données venant des BD
relationnelles.
• BD relationnelles adaptées à l'OLTP (On-Line Transaction Processing) grâce au
standard SQL. Beaucoup de transactions et de requêtes simples, sur peu de
données à la fois. Gestion, production.
• BD relationnelles peu adaptées à l'OLAP (On-Line Analytical Processing)..
Requêtes moins fréquentes mais plus complexes, longues, nécessitant une
reformulation (agrégation) des données de masse. Analyse de données massives
(giga, tera octets) stockées dans l’entrepôt pour l'aide à la décision.
On-Line Analytical Processing & BD multi-dimensionnelles
Les besoins
•Transformer les données brutes (ex. ventes pour chaque produit, jour, fournisseur) en de
l'info. stratégique pour les analyses ultérieures
•Décideurs : finances, ventes, budget, marketing...
•Calculs complexes (analyse de tendance, moyennes mobiles, équations algébriques..) mais
requêtes exprimées simplement
"Total des ventes pour chaque produit par trimestre"
"les 5 meilleurs fournisseurs pour chaque catégorie de produit l'an dernier"
"pour chaque produit, sa part de marché dans sa catégorie par rapport à celle de 1994"
"les fournisseurs dont les ventes ont augmenté dans chaque catégorie de produit ces 5 dernières années"
...
On-Line Analytical Processing & BD multi-dimensionnelles
Les besoins (suite)
• Avoir des résultats à temps, pouvoir raffiner, prolonger ou reprendre les analyses → besoin
de garder et visualiser les résultats intermédiaires.
• Appréhender (visualiser) les données dans les dimensions naturelles pour les décideurs
Total des ventes pour chaque produit par trimestre
Trim1
Trim2
Trim3
Trim4
Prod1 12
14
32
22
Prod2
26
34
7
15
...
Total des ventes par catégorie de produit par fournisseur
par trimestre (+ de détail sur les fournisseurs, - sur les produits)
On-Line Analytical Processing & BD multi-dimensionnelles
BD relationnelle et OLTP
Table (relation) VentesVoiture
Attributs
nuplets
Modele
Clio
Clio
Jaguar
Jaguar
Espace
Espace
Couleur
Bleu
Rouge
Bleu
Rouge
Bleu
Blanc
Ventes
180
244
318
204
131
153
On veut des détails sur les vendeurs...
On-Line Analytical Processing & BD multi-dimensionnelles BD relationnelle et OLTP
Vendeurs
VentesVoiture
Modele
Clio
Clio
Clio
Clio
Clio
Clio
Clio
Clio
Jaguar
Jaguar
Jaguar
Jaguar
Jaguar
Jaguar
Jaguar
Jaguar
Espace
Espace
Espace
Espace
Espace
Espace
Espace
Espace
Couleur
Bleu
Rouge
Bleu
Rouge
Bleu
Rouge
Bleu
Rouge
Bleu
Rouge
Bleu
Rouge
Bleu
Rouge
Bleu
Rouge
Bleu
Blanc
Bleu
Blanc
Bleu
Blanc
Bleu
Blanc
Vendeur
Toto
Toto
Titi
Titi
Tata
Tata
Tutu
Tutu
Toto
Toto
Titi
Titi
Tata
Tata
Tutu
Tutu
Toto
Toto
Titi
Titi
Tata
Tata
Tutu
Tutu
Ventes
12
23
34
45
56
67
78
89
90
09
98
87
76
65
54
43
32
21
11
22
33
44
55
66
Vendeur
Toto
Titi
Tata
Tutu
Succursale
Auto+
Auto+
BelleCaisse
BelleCaisse
•BD relationnelle : présentation peu conviviale. Données brutes.
Normalisation
•OLTP (SQL) : mises à jour. Requêtes simples "qui, quoi" (ex. les
ventes de Toto).
•Pour l'analyse, besoin de données agrégées, synthétisées
•Possibilité d'agréger (fonctions de base uniquement) les données
sur une seule table (ex. : somme des ventes par modèle), mais très
coûteux (parcourir toutes les tables) et recalcul à chaque étape, à
chaque utilisation → tables de résumés
•Sur plusieurs tables (ex : somme des ventes par succursale),
nécessité de faire des jointures coûteuses (ici 24 * 4 = 96
comparaisons) → dénormalisation
On-Line Analytical Processing (OLAP) & BD multi-dimensionnelles
Tables de résumé
• Idée
: stocker les résultats des fonctions agrégées (ex: table des ventes par
vendeur, table de la moyenne des ventes par vendeur de chaque succursale,...) les
plus fréquemment utilisés.
• Problèmes :
•tables de résumés pré-définies. Ce qui n'est pas prévu n'est pas disponible.
•prolifération des tables de résumés →environnement de décision complexe et
confusant
Utilisateurs doivent savoir quelles tables de résumé sont disponibles et
ce à quoi elles correspondent.
•Il faut rafraîchir par rapport au données brutes → ne pas interférer la
production (concurrence)
le calcul des agrégats nécessite de lire toutes les données d'une table et
donc impose le verrouillage de tous ses n-uplets.
On-Line Analytical Processing (OLAP) & BD multi-dimensionnelles
Dénormalisation
•Idée : Stocker toutes les informations dans une seule table pour éviter les jointures.
Modele
Clio
Clio
Clio
Clio
Clio
Clio
Clio
Clio
Clio
Clio
Jaguar
Jaguar
Jaguar
...
Espace
Couleur
Bleu
Bleu
Rouge
Rouge
Bleu
Rouge
Bleu
Rouge
Bleu
Rouge
Bleu
Bleu
Rouge
...
Blanc
Vendeur
Toto
Toto
Toto
Toto
Titi
Titi
Tata
Tata
Tutu
Tutu
Toto
Toto
Toto
...
Tutu
Ventes
12
12
23
23
34
45
56
67
78
89
90
90
09
...
66
Succursale
Auto+
Auto+
Auto+
Auto+
Auto+
Auto+
BelleCaisse
BelleCaisse
BelleCaisse
BelleCaisse
Auto+
Auto+
Auto+
...
BelleCaisse
Enfants
Nono
Nana
Nono
Nana
------Nono
Nana
Nono
...
--
•Problèmes :
•Grande redondance (ex. succursale et surtout enfants de Toto) → place disque ↑ performances ↓
•Diminue la densité du stockage des données (colonne Enfants creuse) → place disque gaspillée
•Augmente aussi la taille et le nombre des index
•Seule alternative → "plus d'acier", i.e.. augmenter les capacités matérielles
On-Line Analytical Processing (OLAP) & BD multi-dimensionnelles
Vers une autre représentation des données
•Les bases de données relationnelles ne sont pas adaptées à l'OLAP car les tables
représentent une vue aplatie de structures naturellement multi-dimensionnelles.
•Non seulement perte de performances mais aussi nécessité pour les utilisateurs de savoir
comment trouver les liens entre les tables pour recréer la vue multi-dimensionnelle.
•Il est donc nécessaire de disposer d'une structure de stockage adaptée à l'OLAP, c’est-à-dire
permettant de
•visualiser les données dans plusieurs dimensions naturelles,
•de pouvoir définir et ajouter des dimensions facilement,
•de manipuler les données ainsi représentées facilement et efficacement.
Bases de données multi-dimensionnelles ("Cube")
On-Line Analytical Processing (OLAP) & BD multi-dimensionnelles
Bases de données multidimensionnelles (1)
• Une BD multidimensionnelle [Gray & al. - VLDB'96 ] est un hyper-cube :
•Les axes sont appelés dimensions définies par l'utilisateur
•Les points dans l'espace (cellules) contiennent des mesures calculées à partir de formules plus
ou moins complexes.
•Les opérateurs sur le cube sont algébriques (retournent un cube) et peuvent ainsi être combinés
VENTES
Clio
mesures
Jaguar
VVE
ENN
DDE
EUU
RR
M
M
OO
DD
EE
LL
EE
Tutu
Tata
Titi
Toto
Espace
bleu
blanc
rouge
COULEUR
COULEUR
dimensions
Base de données multi-dimensionnelle = "super-tableur"
On-Line Analytical Processing (OLAP) & BD multi-dimensionnelles
Bases de données multidimensionnelles (2)
•Représenter ce cube nécessiterait en relationnel une table de 4*3*3 = 36 nuplets à "balayer"
•Ici, pour retrouver une valeur dans une cellule, il faut faire 4+3+3 = 10 recherches seulement
Modele
Clio
Clio
Clio
Clio
Clio
Clio
Espace
Espace
...
Couleur
Bleu
Rouge
Blanc
Bleu
Rouge
Blanc
Bleu
Blanc
...
Vendeur
Toto
Toto
Toto
Titi
Titi
Titi
Tutu
Tutu
...
Ventes
12
23
22
34
45
48
55
66
...
nuplet
1
2
3
4
5
6
7
8
...
Clio
Jaguar
Tutu
Tata
Titi
Toto
Espace
bleu
Espace
Espace
Bleu
Blanc
Tutu
Tutu
55
66
35
36
blanc
rouge
M
M
OO
DD
EE
LL
EE
Clio
VVEE
NNDD
EEUU
RR
VENTES
180 244 321
Jaguar
318 204 554
Espace
131 153 43
bleu
VVEE
NNDD
EEUU
RR
On-Line Analytical Processing (OLAP) & BD multi-dimensionnelles
Opérateurs : rotation ("slicing")
blanc
rouge
COULEUR
COULEUR
CC
OO
UU
LL
EE
UU
RR
bleu
180 318 131
blanc
244 204 153
rouge
321 554 43
Clio
Jaguar
Espace
MODELE
MODELE
Rotation 90
Aucun réarrangement des données. 6 vues possibles directement
On-Line Analytical Processing (OLAP) & BD multi-dimensionnelles
Opérateurs : extraire ("dicing")
VENTES
Clio
Jaguar
Espace
180 244 321
Jaguar
102 270
318
Espace
70
131
bleu
204 554
153 43
blanc
rouge
COULEUR
COULEUR
Tutu
Tata
Titi
Toto
blanc
32
rouge
Tata
Titi
VVEE
NNDD
EEUU
RR
M
M
OO
DD
EE
LL
EE
Recherche des cellules rapide. Recalcul plus rapide sur les faces
On-Line Analytical Processing (OLAP) & BD multi-dimensionnelles
Opérateurs : ajouter une dimension
VENTES
Jaguar
10
27
Espace
7
3
blanc
rouge
janvier
janvier
Tata
Titi
Jaguar
11
21
Espace
6
11
blanc
rouge
Tata
Titi
Jaguar
4
22
Espace
11
2
blanc
février
février
Possibilité d'ajouter une dimension à tout moment
rouge
mars
mars
On-Line Analytical Processing (OLAP) & BD multi-dimensionnelles
Hiérarchies de dimensions
•Les dimensions peuvent être vues à différents niveaux de granularité, qui
correspondent à différents niveau de consolidation des données.
•Exemples :
•Vendeur → Succursale → Région → Entreprise
•Jour → Mois → Trimestre → Année → Décennie
•Ces "chemins de consolidation de données" correspondent aux hiérarchies
naturelles de l'entreprise.
•Il peut en exister plusieurs pour la même dimension
•Jour → Semaine → Année → Décennie
•Faire passer d'une vue à une vue moins détaillée : opérateur roll-up ↑
•
"
"
plus
"
•Ces opérateurs doivent être quasi-instantanés
"
drill-down ↓
Entreprise
Région
Succursale
Vendeur
On-Line Analytical Processing (OLAP) & BD multi-dimensionnelles
Opérateurs : Roll-up et Drill-down
Clio
Jaguar
Espace
180 244 72
318 204 78
131 153 57
bleu
blanc
Entreprise
35
22
9
5
35
25
42
3
3
28
9
180 244 72
8
318 204 78
Tutu
Tata }BelleCaisse
11
Titi
}Auto+
Toto
rouge
Succursale
Vendeur
131 153 57
Drill-down
27
46 BelleCai
Auto+
blanc
rouge
Entreprise
Région
Région
51
11
bleu
Roll-up
44
Succursale
On-Line Analytical Processing (OLAP) & BD multi-dimensionnelles
Architectures possibles
interface
graphique
tableur
package stat.
rôle
médiateur du
serveur
OLAP
serveur OLAP
fichiers
SGBD relationnel
Vieux SGBD
•approche dédiée : le serveur OLAP
stocke la BD multidimensionnelle dans
des structures non relationnelles.
Agrégations, roll-ups précalculés.
•approche supportée : le serveur OLAP
traduit les opérations sur le cube en des
opérations relationnelles. Les données
sont stockées sur le SGBD relat., avec
des vues matérialisées et des index
supplémentaires.
On-Line Analytical Processing (OLAP) & BD multi-dimensionnelles
Représentation des données
Les systèmes spécialisés : MOLAP (OLAP multidimensionnel)
Les données multidimensionnelles sont stockées dans un SGBD dont
les structures sont optimisées pour le stockage et le traitement des données.
Accès rapide en lecture/écriture pour de grandes quantités de données.
Les données sont séparées en plusieurs cubes denses de petite taille, pour
traiter la dispersion des données (un petit nombre de cellules possibles
a une valeur).
sources externes
opération
intégration
systèmes
opérationnels
SGBD multidimensionnel
•Arbor Essbase, IRI Express, Pilot (Pilot Software), ...
Interface OLAP
On-Line Analytical Processing (OLAP) & BD multi-dimensionnelles
Représentation des données
Les sytèmes relationnels : ROLAP
Les données multidimensionnelles sont stockées dans un SGBD
relationnel. Elles sont organisées en schémas en forme d'étoiles ou de
flocon. Accès en mode lecture.
opération
intégration
Interface OLAP
Sources de données
SGBD Relationnel
Moteur OLAP
•Redbrick, Microstrategy, MetaCube (Informix)...
On-Line Analytical Processing (OLAP) & BD multi-dimensionnelles
Architectures possibles (bilan)
•Dans les 2 approches : les efforts de recherche portent à la fois sur le calcul du cube à partir de tables
relationnelles (alimentation du serveur), et sur le calcul d'opérations complexes à partir du cube
(principalement ré-agrégation de données agrégées)
•Calcul du cube : par exemple, on veut que l'agrégation sur 3 dimensions soit la somme.
Equivaut a 2^3 = 8 "group-by" de SQL (toutes les combinaisons de dimensions)
2 types d'optimisation :
•trier les données pour calculer plusieurs agrégats à partir du même tri
•enchaîner les calculs de manière à utiliser certains résultats intermédiaires à la volée (pipe-line)
•calcul d'opérations complexes :
•précalculer certaines informations auxiliaires (pas plus que la taille du cube)
•mettre à jour ces informations incrémentalement en batch
•utilisation de techniques de codages couvrants...
Schémas
• Schéma en étoile :
– 1 table de faits centrale et plusieurs tables de
dimensions dénormalisées
– Les mesures sont stockées dans la table de faits
– Il existe une table de dimension pour chaque dimension
avec tous les niveaux d’agrégation
• Schéma en flocon
– Version normalisée du schéma en étoile
– Traitement explicite des hiérarchies de dimension
(chaque niveau est représenté dans une table différente)
– Plus facile à maintenir, plus lent lors de l’interrogation.
On-Line Analytical Processing (OLAP) & BD multi-dimensionnelles
Schémas en étoile et en flocon
Dimension
Dimension
VENDEUR
Relation de Faits
VENTES
id_vendeur
nom
succursale
région
PRODUIT
id_produit
Modèle
Couleur
id_produit
id_vendeur
id_temps
quantité
TEMPS
id_temps
Jour
Mois
Année
Dimension
PRODUIT
id_produit
Modèle
Couleur
Relation de Faits
VENTES
id_produit
id_vendeur
id_temps
quantité
Dimension
VENDEUR
id_vendeur
nom
id_succursale
TEMPS
id_temps
Jour
id_Mois
Dimension
SUCCURSALE
id_succursale
nom
région
MOIS
id_Mois
Année
BD multidimensionnelles ≠ panacée.
•
•
La technologie multidimensionnelle n'est pas toujours adaptée et ne doit pas être utilisée
"`à toutes les sauces"
Personnel
Exemple :
Toto
21
Personnel
Employé
Toto
Titi
Tata
Tutu
Tyty
Bobo
Bibi
Baba
Bubu
#employé
01
12
31
14
54
03
41
33
23
Age
21
19
63
31
27
56
45
41
19
EE
M
M
PP
LL
OO
YY
EE
EE
19
Titi
Tata
63
31
Tutu
27
Tyty
56
Bobo
Baba
45
41
Bibi
Bubu
19
31 41 23 01
Les
Lesdonnées
donnéessur
surlelepersonnel
personnelne
nesont
sont
pas
multidimensionnelles
:
pas
de
pas multidimensionnelles : pas de
relation
relationentre
entreles
leséléments
élémentsdes
des
différents
différentsnuplets
nuplets
14 54 03 12 33
##EMPLOYE
EMPLOYE
Les précurseurs des BD multidimensionnelles :
BD temporelles, BD spatiales, BD statistiques
•
Bases de données temporelles : stockage et interrogation des valeurs des
différents item de la base selon une ou plusieurs dimensions temporelles
(les plus utiles : temps de validité, temps de transaction)
seul le temps est traité comme une dimension
•
Bases de données spatiales : représentation des item selon leur forme et
position dans l'espace.
opérateurs développés géométriques, loin des opérateurs OLAP
possibilité d'utiliser les travaux sur l'indexation de telles bases
•
Bases de données statistiques : bcp de points communs, mais sans
construire un nouveau modèle. Extension du modèle relationnel pour
supporter les tables de résumé et les traitements statistiques.
Traitement non-uniforme des dimensions et des mesures.
Récupérer les techniques d'implémentation (notamment vues agrégées)
Règles d'or de Codd
•1993 : E.F. Codd formule 12 règles d'or (à la demande de Arbor soft. !!)
•1995 : 18 règles en 4 groupes :
Basiques :
1. vue multidimensionnelle
2. manipulation directe
3. médiation (accessibilité)
4. intégration d'approche dédiée et d'approche supportée.
5. support de tous les modèles d'analyse des entreprises
(seuls les plus simples sont habituellement supportés)
6. Client/serveur
7. Transparence (ne pas avoir à savoir d'où viennent les données,
même si elles viennent de sources externes).
8. Multi-utilisateurs (lecture seule ?)
Règles d'or de Codd
Caractéristiques spéciales
9. Traitement des données dénormalisées
10. Stockage des résultats à part (ne pas interférer avec les mise à jour
des transactions de production)
11. Représentation des valeurs manquantes
12. Traitement des valeurs manquantes.
Présentation des rapports:
13. Flexibilité (ajout de dimension...)
14. Performances non dégradées si nb. dim. ou taille BD augmente.
15. Ajustement de la représentation physique
Contrôle des dimensions :
16. Généricité : traitement équivalent de chaque dimension.
17. Nombre et profondeur illimités (actuellement, max. = 10 et 6)
18. Calculs à travers n'importe quelles dimensions.
Test FASMI
(Fast Analysis of Shared Multidimensional Information)
•
•
•
•
•
•
Voulu plus simple, réaliste et général que les règles de Codd
Fast : 1 seconde pour les analyses de bases, - de 5 secondes pour la plupart,
très peu au dessus de 20 secondes (au-delà de 30 secondes, CTRL-ALTDEL!). Même si on a maintenant en 5 minutes ce qui durait des heures,
l'utilisateur perd le fil de son raisonnement...
Analysis : doit servir pour n'importe quelle analyse logique ou statistique assez
facilement (sans programmer), que ce soit par des outils internes ou des appels
a des outils externes (ex. tableur).
Shared : les bonnes propriétés habituelles "multi-utilisateurs" des SGBD :
concurrence d'accès en écriture, confidentialité, sécurité.
Multidimensional (view)
Information : toute l'information nécessaire doit pouvoir être produite
(rapport de 1 à 1000 entre le produit le moins puissant et le plus puissant).
Benchmarking...
Olap Council (http://www.olapcouncil.org)
•
•
•
•
•
•
Fondé pour le développement et la standardisation de l'OLAP
Regroupe la plupart des vendeurs d'OLAP (mais pas tous!)
OLAP MDAPI : Interface standard que doivent fournir les serveurs OLAP,
de manière à ce que différents outils d'analyse puissent se développer par
rapport à ces spécifications.
Interopérabilité : le même outil d'analyse pourra alors utiliser
simultanément des données provenant de différents serveurs OLAP.
MDAPI V.5 disponible sur WWW pour commentaires. Uniquement pour
des analyses de consultation. Prochaines versions inclueront les mises à
jour rétroactives.
Même stratégie pour le benchmarking : package complet APB-1
Problèmes ouverts en OLAP
•
•
•
•
Langage et optimisation de requêtes
Stockage et indexation des BD multidimensionnelles
Utilisation pour le Data Mining
Mises à jour directe sur le cube. Rétro-action sur les
données brutes.
Modèles de données semi-structurés
Le Web
• Support naturel pour l’information répartie
• Quantité gigantesque d’informations (des milliards de pages)
• De plus en plus d’applications :
–
–
–
–
B2C( commerce électronique)
B2B (achats groupés)
Impôts (gouvernement-client)
Bibliothèques en ligne
– …
• Constat :
– Le langage du Web (HTML) n’est pas adapté à ces applications (besoin
de typage pour représenter la structure des données)
Utiliser le typage des bases de données ?
Données du Web et SGBD
• La structure n’est pas bien connue
• La structure est irrégulière
– Données manquantes, ou supplémentaires (annotations)
– Standards différents
• La structure est implicite
• La structure peut n’être que partielle
• Le typage peut n’être qu’indicatif
– Données pas toujours conformes
Données du Web et SGBD
• Le schéma est souvent a posteriori
– On a des données et on déduit le type ensuite
• Le schéma est souvent important et complexe
• Le schéma est parfois ignoré par les requêtes
– requêtes par mots-clés
• Le type d’une information peut dépendre du contexte
• Le schéma évolue très rapidement
– contre-indication pour le choix d’un SGBD
Constat
• Les modèles de bases de données classiques ont une structure
trop rigide, mal adaptée aux données du web
• Les modèles documentaires (HTML) ne proposent pas assez
de structure
modèle de données semi-structuré
Modèle semi-structuré
• Principe : partir des documents existants et trouver une
structure commune, suffisamment souple pour prendre en
compte les irrégularités, les valeurs manquantes, les
évolutions, etc.
• Les modèles semi-structurés utilisent des graphes annotés pour
représenter les données.
• Les différents modèles diffèrent par
– l’endroit où sont situées les annotations (arêtes et/ou nœuds)
–
–
l’existence ou non d’un ordre sur les fils d’un nœud
la façon de représenter le partage d’information
Exemple
LesPersonnes
&0
etudiant
personne
personne
Frere-soeur
age
23
&2
&1
nom
age
Marie
Duval
25
&4
nom
Jean
Martin
Frere-soeur age
nom
21
Paul
Martin
adresse
adresse
adresse
&3
rue
97 rue du Bac
&5
ville
Paris
rue
13 rue Didot
ville
Paris
Représentation textuelle
<LesPersonnes id=&0
<Personne id=&1
nom=“Jean Martin“
age=“25“
frere-soeur=&4
adresse=&3 />
<Personne id=&2
nom=“Marie Duval“
age=“23“
adresse=&3 />
<Etudiant id=&4
nom=“Paul Martin“
age=“21“
frere-soeur=&1
adresse=&5 />
<Adresse id=&3
rue=“97 rue du Bac“
ville=“Paris“ />
<Adresse id=&5
rue=“13 rue Dutot“
ville=“Paris“ />
/>
XML
eXtensible Markup Language
gestion de documents
SGML
Documentation
Hypertexte
HTML
gestion de données
BD structurées
(relationnel et objet)
BD semi-structurées
XML : Principes
- balisage structurel (SGML) :
- chaque champ interne au document (élément) est encadré par des
balises (tag) ouvrante et fermante : <cours>BDIA</cours>
- balisage défini par les auteurs : souplesse
- structure hiérarchique :
– Un document sur les employés contient un « nom », une « adresse », un
« téléphone ».
- séparer la structure logique des données de leur présentation
- feuille de style (XSL) : ensemble de règles pour la réalisation
sur un médium particulier
Forme sérialisée et forme arborescente
• Un document XML peut se représenter sous deux formes:
– La forme sérialisée est la forme courante (contenu marqué
par des balises). Elle est utilisée pour
• Stocker un document dans un fichier
• Echanger des documents
– La forme arborescente met en évidence la structure du
document (facilite la conception des traitements).
• Elle permet de spécifier des manipulations de données XML
• Elle peut être utilisée par certaines applications qui gèrent les
documents en mémoire (éditeurs XML).
Exemple
livre
<livre année=‘2000’>
<titre>
Data on the Web
titre
</titre>
<auteur>
Data on the Web
S. Abiteboul
</auteur>
auteur
<auteur>
P. Buneman
S. Abiteboul
</auteur>
<auteur>
D. Suciu
</auteur>
<contenu>
<chapitre> Data Model </chapitre>
<chapitre> XML</chapitre>
</contenu>
<editeur>Morgan Kaufmann</editeur>
</livre>
année
2000
editeur
Morgan Kaufmann
auteur
P.Buneman
auteur
D. Suciu
chapitre
Data Model
contenu
chapitre
XML
Remarques
• XML fournit une syntaxe, mais pas de sémantique a priori.
• Les balises peuvent avoir un sens pour l’application, mais
n’ont pas de sémantique définie par le langage.
• XML définit la structure et le contenu d’un document, mais
pas son comportement ni son traitement.
• Les briques autour d’XML (XSL, XSchema, XPath, XQuery,
etc.) permettent de manipuler et d’interroger des données
stockées dans des documents XML.
Bilan
• Echange et partage d’information
– Utilisation des mêmes balises, mais formats différents
• Interopérabilité des outils de traitement
– Parsers, éditeurs, browser
• Modularité et réutilisation
– Chaque utilisateur définit ses propres structures de
document
– Existence des DTD, des schémas, qui permet
d’automatisation des traitements et un contrôle de validité
• Accès à des sources d’information hétérogènes