Sommaire

• Notions de SI opérationnel et de SI décisionnel

ENTREPÔTS DE DONNEES • Architecture d’un entrepôt de données
ARCHITECTURE ET FONCTIONNALITES • Différents mode de représentation des données
multidimensionnelles
Mokrane Bouzeghoub
• Opérations sur les données multidimensionnelles
http://www.prism.uvsq.fr
• Problèmes d’hétérogénéité des données

• Chargement et rafraîchissement d’un entrepôt de données

• Méta données et méta modèles de DW

• Autres architectures d’intégration de données

Besoin d'intégration de données Système d'information opérationnel

v.s système d'information décisionnel
Livraison et
distribution Relations Contexte:
client (CRM) • données distribuées
• sources autonomes
• données hétérogènes
• ...

Système SI Système de
Gestion des Système
d'information décisionnel Pilotage
Données résumées, contrats Opérant
agrégats, indicateurs opérationnel
Applications
financière But
• Réduire le temps
Gestion des
d'acquisition des données
commandes • Transparence de
• Déluge de données
l'hétérogénéité
• Flexibilité, évolutivité • Pénurie de connaissances sur ces
données
 Notion de donnée et
Exemple: un DW dans les télécoms
notion d'information
– Sujets
Date Heure Numéro Destinat Durée Coût • suivi du marché: lignes installées/ désinstallées, services
et options choisis, répartition géographique, répartition
5-3 07:05 00216188 Tunisie 04:08 6.30
5-3 16:12 00216188 Tunisie 08:10 11.50
entre public et différents secteurs d'organisations
6-3 09:40 00441216 UK 10:20 16.45 • comportement de la clientèle
6-3 20:20 04426576 BdRhnes 16:30 8.40 • Comportement du réseau
– Historique
• 5 ans pour le suivi du marché
• 1 an pour le comportement de la clientèle
• 1 mois pour le comportement du réseau
– Sources
• fichiers nouveaux clients élaborés par les agences
régionales
6 8 10 12 14 16 18 L M M J V S D • fichier facturation de l'entreprise
• sources externes: études INSEE

Importance du choix du granule Contraintes

et du volume des données
• Le granule affecte le volume du DW et le type de
requêtes
• Facturation détaillée dans l'historique
200 appels/mois, 50 car/appel, sur 2 mois, Total 20 000 car/abonné
• Sans facturation détaillée
un seul article de 50 car / abonné dans l'historique
- Mais les deux choix ne permettent pas la même analyse
– le DW doit être totalement indépendant des systèmes
opérationnels
– les tâches d'alimentation, rafraîchissement et calcul sont
totalement asynchrones
– les données provenant des sources internes passent par le
réseau
– Les sources externes sont recopiées dans leur globalité

• Le volume du DW détermine le type de serveur de BD à – les modifications sur les sources internes ne sont pertinentes que

utiliser et les développements à réaliser si elles représentent plus de 1% du volume total des données.

• AT&T: 20TB pour le suivi des appels sans fil – Les modifications sur les sources externes sont acquises
• Wal-Mart: BD consommateurs: 70TB périodiquement une fois par mois.
 Requêtes
• Sujet: Comportement clientèle
–Nombre moyen d'heures par client, par mois et par
région
–Répartition des appels clients sur la semaine
–Répartition des appels clients sur la journée
–Nombre moyen de numéros appelés représentant 20%
d'une facture, 50% d'une facture
–Durée moyenne d'une communication urbaine par ville
–Durée moyenne d'une communication internationale
Application de production v.s
application d'aide à la décision
–Les applications de production sont constituées
de traitements factuels concernant les produits,
les ressources ou les clients de l'entreprise
• OLTP: On Line Transaction Processing
–Les applications d'aide à la décision sont
constituées de traitements ensemblistes
réduisant une population à une valeur ou un
comportement
• OLAP: On Line Analytical Processing

Architecture d'un DW Contenu d'un DW

– Des données historisées
• fournies par les sources
META
DATA • archivées dans l’ODS

EXTRACTION – Des données agrégées

CLEANING
• par des fonctions de calcul
CDW
EXTRACTION
• Par des algorithmes de data mining
RECONCILIATION
CLEANING INTEGRATION CUSTOMISATION
• Par des techniques de résumés
HIGH-LEVEL
AGGREGATION
EXTRACTION
CLEANING – Des métadonnées
• décrivant la structure des données de base ou agrégées
DATA
SOURCES
ODS DATA • donnant des explications sur la qualité, le mode de
MARTS
dérivation, la duréee de vie, le rafraichissement, etc...
 Représentation d’un entrepôt de
Caractéristiques des données d'un DW
données
– Orientées sujet
• Clientèle • Représentation conceptuelle
• produit/production – schémas en étoile
• marché/transaction – en flocons
– en constellation
• politique/stratégique
– Intégrées
• codage • Représentation logique
– tables
• format
– Cubes
• structure
– Non volatiles
• Représentation physique
• pas de mise-à-jour directement
– vues matérialisées
• chargement en masse

Le schéma en étoile Le schéma en flocons

Product Table Store Table Product Table Store Table

Product_id Store_id District Table
Product_id Store_id
Product_desc District_id District_id
Product_desc Store_desc
– Une table « faits » … ... District_id
District_desc
par indicateur
Sales Fact Table
– Une table Product_id Sales Fact Table
dénormalisée pour Store_id Item_id
Item_id
chaque dimension Store_id
Day_id Sales_dollars
– associations en Sales_dollars Sales_units
étoile entre les tables Sales_units
... Time Table Dept Table Mgr Table
« faits» et Item Table
Time Table Week_id Item_id Dept_id Dept_id
« dimensions » Item Table
Period_id Item_desc Dept_desc Mgr_id
Day_id Item_id
Month_id Year_id Dept_id Mgr_id Mgr_name
Item_desc
Period_id ...
Year_id
 Schéma en constellation Choix des tables « faits » et
« dimensions »
Warehouse Table Product Table Store Table
• Analyse des requêtes
Warehouse_id Product_id Store_id – attributs « group-by » indiquent les dimensions
Warehouse_loc Product_desc District_id – attributs agrégés indiquent les mesures
– attributs « where » sont les attributs des tables factuelles ou
Inventory Fact Table Sales Fact Table dimensionnelles
Product_id Item_id
Shelf_id Store_id
Cost_dollars Sales_dollars
Qty_on_hand Sales_units • Exemple :
select sale.store_id, sale_product_id, sum (sale.price)
Time Table
Week_id Item Table from product P, sale S
Period_id Item_id where P.product_id=S.product_id and P.product_desc = « clothes »
Year_id Dept_id group by store_id, product_id
Utilisé lorsqu'il est nécessaire
d'avoir plusieurs tables factuelles

Représentation logique Représentation abstraite

et algèbre de cubes
DuréeMoy Départ. Mois Région

5 Info Janv IdF Temps

5 Phys Janv IdF Mois Trimestre Année
18 Philo Janv IdF
7 Droit Janv IdF
12 Info Févr IdF
8 Phys Févr IdF Fournisseur
9 Philo Févr IdF
15 Droit Févr IdF Produits Catégorie Ventes
18 Info Mars IdF
12 Phys Mars IdF Client
Philo IdF Item Représentant
22 Mars
25 Droit Mars IdF Région
Clients
Dimensions: Attributs, Tuples

ou : Départ., Mois, Région

 Exemple Généralisation de la
notion de cube
Droit Philo Phys Info • Etant donné un cube à N dimensions, il est possible de dériver
NPC tous les cubes de dimension N-1, N-2,…, N-N, (=> Treillis de 2n
BDR 18 24 7 15 cubes). All
IDF 9 12 25 8 15

7 18 5 5 8 25
5 17
Janv 7 18 5 5 Dept Région Mois
8
12
Févr 15 9 8 12 6
Mars 18
25 22 12 18 Dept,Région Région,Mois

Dept,Mois

Dept,Région,Mois

Problématiques Représentation interne:

vues matérialisées
Questions :
• Comment implémenter ces cubes ?
• Comment stocker les données agrégées ?
• Comment accéder aux données par les
dimensions des cubes ?
V1 V2 • L’entrepôt de données
est perçu comme un
Approche : Approche :
Bases de données spécialisée Base de données OLAP-Ready V3 V6 ensemble de vues
V4 V5 – matérialisées
V8
V7 – ou abstraites
 Le choix de la matérialisation des Opérations sur les cubes
vues
! Rotate / Pivot ! Roll-up (grain supérieur)
V1(K,A,B,C,D,E) V2(A,E,F) V3(E,G,H,I)
! Switch ! Drill-down (grain inférieur)
! Split ! Slice (Projection)
La matérialisation est ! Dice (Sélection)
! Nest / Unest
une technique de
cache qui doit ! Push / Pull
optimiser:
• coût d'évaluation
• coût de maintenance ! Jointure
• coût de stockage ! Union
• fraîcheur des données ! Intersection
! Différence
R1(K,A,B,X) R2(Y,C,D,E,W) R3(Y,C,D,E,Z)

Décomposition (Split) Projection (Slice)

Droit Philo Phys Info S’applique sur les valeurs d'une dimension
NPC 18 24 7 15
BDR 9 12 25 8 15 Info
IDF 7 18 8 25 Droit IDF BDR NPC Droit Philo Phys Info NPC
5 5
7 18 5 5 5 17 NPC BDR 15
Janv 8 Janv 7 9 18 18 24 7 15 8
12 BDR IDF
Févr 15 9 8 12 6 Spl
it Févr 15 <> <> IDF 9 12 25 8 15 5 25
18 5 17
Mars 25 22 12 18 Mars 25 <> <> 7 18 5 5 8 25 Janv 8
5 Slice Févr 12 6
7 18 5 5 17
Janv 8
12 Mars 18
Info IDF BDR NPC Phys IDF BDR NPC Philo IDF BDR NPC Févr 15 9 8 12 6
Mars 18
Janv 5 8 15 Janv 5 25 7 Janv 18 12 24 25 22 12 18
Févr 12 17 25 Févr 8 <> <> Févr 9 <> <>
Mars 18 6 8 Mars 12 <> <> Mars 22 <> <>
 Composition d’opérations
Changement de granule (Roll-up)
(Dice - Slice - Roll-up)
Droit Philo Phys Info
o n) Région 11,3 18 12,3 9,3 Droit Philo Phys Info
R égi 9,3 NPC
( 24 15
-u p Janv 11,3 18 12,3 9,3 Dice BDR 15
ll 25
Ro Févr <> <> <> 18 18 IDF
Droit Philo Phys Info 18 25
<> <> 10,6 10,6
Mars <> NPC 18 17
Droit Philo Phys Info 18 24 7 15 Janv
NPC 18 24 7 BDR 9 12 25 8 15
15 IDF Févr 15
BDR 9 15 7 18 5 5 8 25
12 25 8 25 22 18 18
IDF 7 18 5 5 8 25 7 18 5 5 5 17 Mars
Janv 8
7 18 5 5 5 17 R o ll- u 15 9 8 12 12 6
Janv 8 p (*.) 13,5 Févr
15 9 8 12 12 13
,5 18 Philo Slice
Févr 6 13,5 Mars 25 22 12 18 NPC
18 24
Mars 25 22 12 18 BDR 24
Droit Philo Phys Info IDF 18
NPC 16
BDR 10,3 16 18
Ro

Roll-up Janv
IDF 15,6 16,3 8,3 11,6
ll-

20,1
up

Févr
15,6 16,3 8,3 11,6
(T

Mois 20,1
22
r

Mars
im
)

Drill-Down Langages OLAP

• Opération inverse de Roll-up.
• S'applique sur le treillis des cubes; fait passer d'un • Extensions de SQL
granule élevé à un granule plus détaillé.
All

Dept Région Mois

Dept,Région Région,Mois

Dept,Mois

Dept,Région,Mois
 Gestion de l’hétérogénéité des Exemples de problèmes
données sur une source
Contradiction Incohérence
Incohérence
• types d’anomalies
• anomalies mono-sources NSS Nom Age Sex Adresse Tel
• anomalies multisources 1450578… Dupont 48 F Lyon 013925…

2621192… Leduc Lise 45 F Monpellier 024567…

2621192… L. Leduc 46 F ------------ 022530…

• Quelle transformations appliquer?
• Comment organiser/synchroniser ces Unicité/ Typo
Format Valeur nulle
transformations ? doublon Erreur saisie

Exemple de problème sur deux Exemple de problème sur deux

sources (jointure) sources (union)
CAR Num Color X
1 azura
CAR Num Num Color X Y 1 blue
2 vermilion Incohérence!
4 40 green - - 2 blue
3 red
4 green

Source 2
Source 1
U Source 2
CAR Num Color X CAR Num Color Y Source 1
azura 10 blue
1
2 vermilion 2O blue CAR Num Color X CAR Num Color X
30 red azura 1 blue
4 green 1
40 green vermilion 2 blue
2
4 green 3 red
4 green
Approche de résolution: Utilisation de
graphes conceptuels Définition du niveau de précision
T T

blue green red blue red

Light blue deep blue vermilion ruby Level of Light blue deep blue vermillon ruby
accuracy

azura Sevilla azura Sevilla

Ontologie = mots + concepts + liens

Fonctionnalités de base des ETL
sémantiques
• Extraction de données sources (E)
W-C relations – Traitement de l’hétérogénéité des systèmes ! tables sources
WORD CONCEPT – Extraction d’un cliché des données
Polysemy – Extraction des changements survenus depuis la dernière fois

Lexical Relations Semantic Relations
Synonymy Hyponymy/Hypernymy (isa)
Nominal/Verbal Meronymy/Holonymy (partof)
Casual, Spatial, Attr
Converse
Axiomes: Disjointness, covering, narrow/broader
• Transformation (T)
– Graphe orienté acyclique ou programme structuré (type L4G) contenant des
opérations de transformations de données
• Chargement (L)
– Chargement du résultat d’un processus de transformation de données dans un
système cible (le + souvent une BD)
• Planification
– Regroupement de plusieurs processus de transformation/chargement
– Planification calendaire ou événementielle de leur exécution
 La phase de chargement initial Caractéristiques

PREPARATION INTEGRATION AGGREGATION CUSTOMIZATION

• C'est la phase ultime de la conception du DW. Avant cette
phase le DW n'existe pas pour les utilisateurs
S1 – Pas de contrainte sur les temps de réponse
C1

– Nécessite plus de disponibilité des sources

• Les 4 phases de chargement peuvent être exécutée

séquentiellement ou planifiée dans le temps
– avec un certain parallélisme dans la phase préparatoire

• Le scénarion de chargement initial est défini statiquement.

Data Extracted Cleaned Operational Data Corporate data Datamarts
sources Data Cleaned Store (ODS) warehouse
(CDW)

La phase de rafraîchissement Caractéristiques

et de maintenance
PREPARATION INTEGRATION AGGREGATION CUSTOMIZATION • Il peut y avoir un asynchronisme complet entre les
différentes activités de rafraîchissement
–un niveau de parallélisme élevé dans la phase de préparation
C1

S1

–chaque sources a sa propre disponibilité (fenêtre d'accès)

–chaque source a sa propre stratégie d'accès et d'extraction (pull, push)
–le nettoyage des données peut être monosource et multisource

• Il n'y a pas un modèle de planification unique pour les

activités de rafraîchissement
Corporate
–dépendant de chaque type d'application (utilisateurs)
Data Extracted Cleaned History of Operational ODS Datamarts
sources data data of data Data Store History
data warehouse –évolutif dans le temps
(ODS) (CDW)
 Modèle de planification Les Workflows

• Un processus de chargement ou de rafraîchissement • Fournissent un cadre de représentation

est vu comme un ensemble d'activités organisées et conceptuel
coordonnées –facilitant la conception
– exécutées par la machine ou par un humain –facilitant la compréhension et l'échange de spécifications
– flexible pour subir des modifications
– évolutif dans le temps • Fournissent un modèle de référence
–facilitant le raisonnement
–offrant de multiples support pour l'étude de diverses
• Les Workflow sont des modèles adaptés pour la propriétés
planification de tâches •des diagrammes d'éta-transition, des réseaux de Petri, des règles actives
– utilisés pour composer des services web (BPEL)
– business process (re)engineering (BPR)
– travail coopératif (CSCW)

Type de tâches et types d’événements Scénario de rafraîchissement (1)

Temporal/external event
Customization
After-Propagation event
BeforeQueryEvaluation
Customization
BeforeCustomization

Before-Customization event Update Propagation

Update Propagation Temporal/external event

History management
History management After-Integration event AfterIntegration
Before-Propagation event
EveryBeginingTrimester Data Integration
Data Integration Temporal/external event BeforeIntegration

S1 DataCleaning S2 DataCleaning
Before-Integration event History management
After-Cleaning event
AfterExtraction
S2 History management
DataCleaning AfterExtraction
S1 Data Extraction S2 Data Extraction S3 Data Extraction

Data Extraction Temporal/external event EveryEndTrimester EveryEndMonth

 Scénario de rafraîchissement (2) Scénario de rafraîchissement (3)
BeforeQueryEvaluation
Customization

BeforeCustomization
Customization
Update Propagation

Update Propagation
BeforePropagation

Data Integration
BeforeIntegration Data Integration

S1 DataCleaning S2 DataCleaning

AfterExtraction AfterExtraction
S1 DataCleaning S2 DataCleaning

S1 Data Extraction S2 Data Extraction S3 Data Extraction

S1 Data Extraction S2 Data Extraction S3 Data Extraction
Every3Hours EveryHour

Atouts des workflows Principaux produits d’ETL

• Flexibilité Produit Transformation Exécution Contrôles Prix

– permettent de coordonner des activités avec des sémantiques Data Stage Graphe + langage type Basic;
mode pas à pas; saisie
Interprétation;
exécution parallèle et
Explicites + logs; nettoyage 100 K! +
avec Quality Stage
encapsulées interactive flux tendu

– permettent de décomposer/recomposer récursivement les Informatica Graphe complet + appels à des Interprétation; Explicites + logs; 100 K! +
procédures; pas à pas exécution parallèle et
activités flux tendu
– permettent une réorganisation dynamique de l'orchestration Genio Langage L4G + appels Interprétation Analyse d’impact 50 K!
procédures
• Intuitivité Sunopsis Graphe complet + appels à des Interprétation Explicites et modules de 35 K!
procédures; pas à pas connaissance
– facilité d'utilisation
Sagent Graphe complet + appels à des interprétation Explicites + logs; Address 50 K!
– facilité de lecture / validation procédures; pas à pas Cleanser, Merge and Purge

• Support d’évaluation de la qualité BO Data Integrator Graphe complet + appels à des

procédures; pas à pas
Interprétation,
parallélisation
Explicites + logs 75 K! +
 BO Data Integrator Informatica

Synthèse: Principales tâches de Les métadonnées d’un

conception d'un DW entrepôt de données
Conception
Besoins
fonctionnels
Besoins non
fonctionnels schéma • Différentes vues des ressources
métier
– schémas des sources de données
Analyse des
besoins Identification – schéma métier (entreprise)
des sources
de données
– schémas clients (utilisateurs)
Détection des
Evaluation
qualité
changements • Différents niveaux d'abstraction
Sélection Evaluation
des sources qualité – conceptuel, logique, physique
Stratégies
- matérialisation
-accès Pull/Push
• Mappings inter-niveaux d'abstraction
Identification Evaluation
Définition – transformation de schémas
Evaluation mapping
qualité des activités qualité
linguistiques
• Mappings inter-ressources
Définition
– linguistiques, opérationnels
Planification Identification Définition
règles de
des activités des événements des extracteurs
transformation
 Vue d’ensemble des méta données Autres méta données
Mappings

ev el
v
• Nommage des données (lexique)

ca l L e
el
Inter-ressources

el
ev
L o p tu a
lL

lL
• Formattage des données (format caché)

ic a
nc

gi
Co

ys
Ph
• Contraintes sur les données (explicites ou implicites)

S
CE
Client Views

AN
• Historique des évolutions des données

ST
IN
Business Schema

TA
• Statistiques sur l'utilisation des données (fréquence

DA
Source schemas
accès/màj, sélectivité)
DATA TYPES • Qualité des données
Mappings –…
inter-niveaux

Importance et utilité des méta données Pourquoi un métamodèle?

• Richesse des méta données • Fixer la terminologie commune à plusieurs

– réduit les coûts de développement
– limite les erreurs d'interprétation des données
domaines
• Permettre l'interopérabilité opérationnelle entre
• Permettre l'interopérabilité opérationnelle entre plusieurs plusieurs systèmes hétérogènes
systèmes hétérogènes
• Gérer la complexité en passant à un niveau
d'abstraction supérieur
• La gestion efficace des méta données est un outil de
maitrise de la complexité des systèmes d'intégration de • Fournir un schéma de référence aux méta
données
données (appelé souvent référentiel)
 Méta modélisation Principales méta classes
DW DEF
Un métamodèle
est un modèle de
modèles.
DATA DEF PROCESS DEF

META MODEL
CLIENT ENTREPRISE SOURCE
mapping mapping
PERSPECTIVE PERSPECTIVE PERSPECTIVE

mapping mapping

S
S

CE
PE

AN
TY

CONCEPTUAL LOGICAL PHYSICAL

ST
TA

IN
DA

LEVEL LEVEL LEVEL

TA
DA
Standards de méta modèles Le référentiel MOF
MOF DTD/Schema
• IRDS (ANSI) : relationnel Niveau M3 vocabulaire générique
Méta-Métamodèle
• MOF (OMG) : objet CWM, EAI, IDL,
Schéma Middleware
• CWM (OMG) : sous cas de MOF Niveau M2
vocabulaire / domaine
Métamodèles
• Dublin Core: objet, XML
Business Models, DTDs,
• … Classes Java
Niveau M1 Schémas BD/Apps
• Implémentations restreintes Modèles Apps
Objets utilisateurs
• Support pour l’ingénierie dirigée par les modèles (outils Docs XML
CASE, MDA, MDE) Niveau M0 Objets Java
Objets Données
 Common Warehouse model Couche de Base
(CWM, OMG)
Management 4 couches de description
toutes modélisées en UML
Contributeurs
IBM, Unisys, NCR, Hyperion, Oracle, Genesis,
Analysis
UBS, Dimension EDI...
Sauf Microsoft qui a sa propre offre
Adopté par l'OMG en juin 2000 (Oslo)
Resource différentes implémentations (partielles)
Environnement de
modélisation
Notation UML
méta modèle UML
Foundation étendu aux concepts des
DW
Base

Couche Fondation Fondation: exemple de méta modèle

Représente • Business Information "Méta modèles
Connaissances métier – Parties responsables et leurs coordonnées
Types de données – Documentation et commentaires généraux
partagés par les
– Hiérarchies de types spécifiques
Expressions de calcul *

*
ModelElement
autres packages
Clés et les Indexes +ownedElement *
(from Core)

Déploiement de logiciels +namespace 0..1

Mapping de types Namespace

(from Core)

Méta modèles partagés par les autres *

Location
locationType : String
address : String
packages ResponsibleParty
responsibility : String
Email
emailAddress : String
emailType : String
city : String
postCode : String
/ modelElement : ModelElement area : String
/ contact : Contact / contact : Contact country : String
/ contact : Contact
*
* * {ordered}
*
Document
{ordered}
reference : String Telephone
/ modelElement : ModelElement phoneNumber : String
phoneType : String
{ordered} * * * / contact : Contact
*
* Contact * {ordered}
/ responsibleParty : ResponsibleParty
Description ResourceLocator
/ email : Email
body : String * url * url : String
/ location : Location
language : Name / telephone : Telephone / contact : Contact
/ modelElement : ModelElement {ordered}
/ url : ResourceLocator
Couche Ressources de Données
Décrit les containers de
données logiques et physiques
Sources de données
opérationnelles
Données cibles de l'entrepôt
Les modèles logiques
Méta modèles partagés par
les autres packages
Gestion de l'entrepôt de données
Orchestration des activités de
l'entrepôt
Process liés à l'entrepôt
Enchaînement des activités
Transformations des données
Evénements déclencheurs
Opérations de surveillance
Métriques
Couche Analyse de Données
Décrit la production et l'analyse
d'informations de décision
Décrit les structures analytiques
déployées
Définit les transferts de données et
leurs transformations
Détérmine les modes de restitution
des données
Bilan sur les méta données
• Les méta données décrivent les SI sur plusieurs
dimensions
–Outil de gestion de la complexité
–Outil de représentation de l’hétérogénéité
• Les méta données constituent en elles-mêmes un sujet
d’étude et de modélisation (méta modèle, méta
modélisation)
–Existence de standards
–Fondation des outils CASE et des ETL.
 Autres systèmes EAI: Entreprise Application Integration
d’intégration de données
Middleware centré sur la communication entre applications
• EAI
• Avantages
– réduire le pb de latence des données par
• Médiateurs synchronisation des mises à jour en
temps réel
– utiles pour les applications nécessitant
• Data Grid une très grande fraîcheur des données

• Portails Web • Limites

– pas d'intégration de données (nettoyage,
• Systèmes P2P transformation, réconciliation, agrégation)
– peu adaptés aux applications B2B
– souvent limités à une connectivité entre
les produits majeurs (Oracle, SAP, Siebel,
People Soft)
• Nombreux problèmes communs avec les entrepôts • perpétuent les problèmes de
l'intégration en offrant des
de données architectures dont les coûts
d'évolution elevés ne permettent
plus une intégration flexible des
données

Médiateur Data Grid

Infrastructure communautaire de services de gestion et de partage de
Middleware dédié à l'accès transparent à des sources de données
# génome et biologie
données hétérogènes Q # astronomie et recherche spatiale
• Avantages # informations épidémiologiques
– grande disponibilité des données
– fraîcheur des données élevée SCH VIRTUEL REQ. MED
• Avantages
– sources de données relationnelles CACHE
ou XML – partage de ressources de calcul
DEC. REQ/REC RES
– partage de ressources
• Limites d'informations
– Hypothèses fortes sur la – très haute disponibilité
disponibilité des sources de Wrap Wrap Wrap – composabilité des ressources
données
– inadaptée pour des sources de • Limites
données fortement hétérogènes SL1 SL2 SL3
• transformations de données – droit de propriété
complexes et coûteuses SD1 SD2 SD3 – confidentialité
 Portail Web
– vue uniforme d’informations agrégées à
partir de sources de données hétérogènes
• applications existantes
• bases de données
• systèmes documentaires
– portail vertical par opposition aux portails
horizontaux
• e.g. Yahoo, Excite, Alta Vista, Lycos
– pour des utilisateurs spécifiques
• décideurs, employés, clients,
fournisseurs
• intranet ou extranet

• Problème
– difficile d’accéder à toute l’information de
l’entreprise