Lisez l'appel personnel

de Jimmy Wales,
fondateur de Wikipédia

Entrepôt de données
Un article de Wikipédia, l'encyclopédie libre.
Aller à : Navigation, rechercher
Le terme Entrepôt de données (ou base de données décisionnelle, ou encore data
warehouse) désigne une base de données utilisée pour collecter, ordonner, journaliser et
stocker des informations provenant de base de données opérationnelles[1] et fournir une aide à
la décision en entreprise.

Sommaire
[masquer]
• 1 Définition et construction
• 2 Principe de fonctionnement
○ 2.1 Intégration
○ 2.2 Historisation
○ 2.3 Organisation fonctionnelle
○ 2.4 Structure de données
• 3 Autour de l'entrepôt de données
○ 3.1 En amont
○ 3.2 En aval
• 4 Comparatif entre les bases de données de l'entreprise
• 5 Histoire
• 6 Citations
• 7 Notes et références
• 8 Voir aussi
○ 8.1 Articles connexes
○ 8.2 Liens externes

Définition et construction [modifier]

Un Entrepôt de données est une base de données regroupant l'ensemble des données
fonctionnelles d'une entreprise. Il entre dans le cadre de l'informatique décisionnelle ; son but
est de fournir un ensemble de données servant de référence unique, utilisée pour la prise de
décisions dans l'entreprise par le biais de statistiques et de rapports réalisés via des outils de
reporting.
D'un point de vue architectural, il existe deux manières de l'appréhender :
• L'architecture "de haut en bas" : selon Bill Inmon, l'entrepôt de données est une base
de données au niveau détail, consistant en un référentiel global et centralisé de
l'entreprise. En cela, il se distingue du Datamart, qui regroupe, agrège et cible
fonctionnellement les données.
• L'architecture "de bas en haut" : selon Ralph Kimball, l'entrepôt de données est
constitué peu à peu par les Datamarts de l'entreprise, regroupant ainsi différents niveau
d'agrégation et d'historisation de données au sein d'une même base.
La définition la plus communément admise est un mélange de ces deux points de vue. Le
terme "data warehouse" englobe le contenant et le contenu : il désigne d'une part la base
détaillée qui est la source de données à l'origine des Datamarts, et d'autre part l'ensemble
constitué par cette base détaillée et ses Datamarts. De la même manière, les méthodes de
conception actuelles prennent en compte ces deux approches, privilégiant certains aspects
selon les risques et les opportunités inhérents à chaque entreprise.
Principe de fonctionnement [modifier]
Intégration [modifier]
Dans les faits, les données alimentant l'Entrepôt de données sont hétérogènes, issues de
différentes applications de production, voire de fichiers dits "plats" (fichiers Excel, fichiers
texte, XML...). Il s’agit alors de les intégrer, de les homogénéiser et de leur donner un sens
unique compréhensible par tous les utilisateurs. La transversalité recherchée sera d’autant plus
efficace que le système d’information sera réellement intégré dans sa globalité. Cette
intégration nécessite notamment :
• une forte activité de normalisation et de rationalisation, orientée vers la qualité ;
• une bonne gestion des référentiels, incluant une vérification constante de leur
intégrité ;
• une parfaite maîtrise de la sémantique et des règles de gestion des métadonnées
manipulées.
La problématique de l'intégration repose sur la standardisation de données internes à
l'entreprise, mais aussi des données externes (provenant par exemple de clients ou de
fournisseurs).
Ce n’est qu’au prix d’une intégration poussée que l’on peut offrir une vision homogène et
véritablement transverse de l’entreprise. Ceci suppose que le système d’information de
l’entreprise en amont soit bien structuré, bien maîtrisé, et bénéficie déjà d’un niveau
d’intégration suffisant. Si tel n'est pas le cas, la mauvaise qualité des données peut empêcher
la mise en œuvre de l'entrepôt de données.
Historisation [modifier]
L' historisation d'un Datawarehouse repose sur le principe de conservation des données (ou
de non-volatilité des données). Afin de conserver la traçabilité des informations et des
décisions prises, les données une fois entrées dans l'Entrepôt sont stables, en lecture seule,
non modifiables par les utilisateurs. Une même requête lancée plusieurs fois à différents
moments doit ainsi restituer les mêmes résultats. Dès qu’une donnée est qualifiée pour être
introduite dans l'Entrepôt de données, elle ne peut donc plus être altérée, modifiée ou
supprimée (en delà d’un certain délai de purge). Elle devient, de fait, partie intégrante de
l’historique de l’entreprise.
Le principe de non-volatilité tranche avec la logique des systèmes de production, qui bien
souvent remettent à jour les données par « annule et remplace » à chaque nouvelle transaction.
Chaque donnée collectée se voit affecter une date ou un numéro de version pour éviter de
recouvrir une information déjà présente dans la base de données, et permettre de suivre son
évolution au cours du temps. Il y a de cette manière conservation de l'historique.
D’un point de vue fonctionnel, cette propriété permet de suivre dans le temps l’évolution des
indicateurs et de réaliser des analyses comparatives (par exemple, les ventes d'une année sur
l'autre). De ce fait, dans un entrepôt de données, un référentiel de temps unique est nécessaire.
Organisation fonctionnelle [modifier]
L'Entrepôt de données intègre au sein d'une même base les informations provenant de
multiples applications opérationnelles. On passe ainsi d’une vision verticale de l’entreprise,
dictée par des contraintes techniques, à une vision transversale, dictée par le besoin métier,
qui permet de croiser fonctionnellement les informations. L’intérêt de cette organisation est de
disposer de l’ensemble des informations utiles sur un sujet le plus souvent transversal aux
structures fonctionnelles (services) de l’entreprise. On dit que l'Entrepôt de données est
orienté « métier », en réponse aux différents métiers de l’entreprise dont il prépare l’analyse.
D'un point de vue conceptuel, les données d'un Data warehouse sont interprétables sous forme
d' indicateurs répartis selon des axes (ou dimensions) : par exemple, le nombre de clients
(indicateur) réparti par jour de vente, magasin ou segment de clientèle (axes). Techniquement,
la modélisation de l'Entrepôt de données peut matérialiser cette organisation sous forme de
tables de fait ou et de tables deréférentiel.
Structure de données [modifier]
L'Entrepôt de données a une structure de données qui peut en général être représentée par un
modèle de données normalisé 3FN ((en)3NF) pour les données de détail et/ou en étoile ou
en flocon pour les données agrégées et ce dans un SGBD relationnel (notamment lorsqu'il
s'agit de données élémentaires ou unitaires non agrégées). La traduction technique de ce
modèle se fait souvent au sein d'un cube OLAP.
L'Entrepôt de données est conçu pour contenir les données en adéquation avec les besoins de
l’organisation, et répondre de manière centralisée à tous les utilisateurs. Ainsi, il n’existe pas
de règle unique en matière de stockage ou de modélisation.
Ainsi, ces données peuvent donc être conservées :
• de préférence, sous forme élémentaire et détaillée (exemple : pour une banque, chaque
opération sur chaque compte de chaque client) si la volumétrie le permet. Les données
élémentaires présentent des avantages évidents (profondeur et niveau de détail,
possibilité d'appliquer de nouveaux axes d'analyse et même de revenir a posteriori sur
le « passé ») mais représentent un plus grand volume et nécessitent donc des matériels
plus performants.
• éventuellement, sous forme agrégée selon les axes ou dimensions d'analyse prévus
(mais ces agrégations sont plutôt réalisées dans les datamarts que dans les entrepôts de
données proprement dits). Les données agrégées présentent d'autres avantages (facilité
d'analyse, rapidité d'accès, moindre volume). Par contre, il est impossible de retrouver
le détail et la profondeur des indicateurs une fois ceux-ci agrégés : on prend le risque
de figer les données selon une certaine vue avec les axes d'agrégation retenus, et de ne
plus pouvoir revenir sur ces critères si l'on n'a pas conservé le détail (par exemple, si
 l'on a agrégé les résultats par mois, il ne sera plus possible de faire une analyse par
journée).
Autour de l'entrepôt de données [modifier]
En amont [modifier]
En amont de l'entrepôt de données se place toute la logistique d'alimentation des données de
l'entrepôt :
• extraction des données de production, transformations éventuelles et chargement de
l'entrepôt (c'est l'ETL ou Extract, Transform and Load ou encore datapumping).
• au passage les données sont épurées ou transformées par :
○ un filtrage et une validation des données (les valeurs incohérentes doivent être
rejetées)
○ un codage (une donnée représentée différemment d'un système de production à
un autre impose le choix d'une représentation unique pour les futures analyses)
○ une synchronisation (s'il y a nécessité d'intégrer en même temps ou à la même
« date de valeur » des événements reçus ou constatés de manière décalée)
○ une certification (pour rapprocher les données de l'entrepôt des autres systèmes
« légaux » de l'entreprise comme la comptabilité ou les déclarations
réglementaires).
Cette alimentation de l'entrepôt de données se base sur les données sources issues des
systèmes transactionnels de production, sous forme de :
• compte-rendu d'événement ou compte-rendu d'opération : c'est le constat au fil du
temps des opérations (achats, ventes, écritures comptables, ...), le film de l'activité de
l'entreprise ou flux ;
• compte-rendu d'inventaire ou compte-rendu de stock : c'est l'image photo prise à un
instant donné (à une fin de période : mois, trimestre, ...) de l'ensemble du stock
(clients, contrats, commandes, encours...).
La mise en place d'un système d'alimentation fiable de l'entrepôt de données est souvent le
poste budgétaire le plus coûteux dans un projet d'informatique décisionnelle.
En aval [modifier]
En aval de l'entrepôt de données (et/ou des datamarts) se place tout l'outillage de restitution et
d'analyse des données (en anglais : Business Intelligence) :
• outils de requêtage ou de reporting
• cubes ou hypercubes multidimensionnels
• data mining.
La conception d'entrepôts de données est donc un processus en perpétuelle évolution. Sous cet
angle, on peut finalement voir l'entrepôt de données comme une architecture décisionnelle
capable à la fois de gérer l'hétérogénéité et le changement et dont l'enjeu est de transformer les
données en informations directement exploitables par les utilisateurs du métier concerné.
Comparatif entre les bases de données de l'entreprise
[modifier]
Base de données de
Caractéristique Data warehouses Datamarts
production
Opération gestion courante, référentiel, analyse analyse récurrente, outil de
 pilotage, support à la
production ponctuelle
décision
3NF, étoile, flocon
Modèle de données entité/relation étoile, flocon de neige
de neige, Data Vault
rare (redondance
Normalisation fréquente maximum
d'information)
actuelles, brutes,
Données historisées, détaillées historisées, agrégées
détaillées
souvent différée,
Mise à jour immédiate, temps réel souvent différée, périodique
périodique
Niveau de
faible faible élevé
consolidation
Perception verticale transverse horizontale
lectures, insertions,
lectures, insertions,
Opérations mises à jour, lectures, mises à jour
mises à jour
suppressions
Taille en gigaoctets en téraoctets en gigaoctets
Ces différences tiennent au fait que les Entrepôts permettent des requêtes qui peuvent être
complexes et qui ne reposent pas nécessairement sur une table unique. On peut résumer les
conséquences de la transformation d'un Data warehouse en Datamart comme suit : un gain de
temps de traitement et une perte de puissance d'utilisation.
Exemples de requêtes OLAP :
• Quel est le nombre de paires de chaussures vendues par le magasin
"OnVendDesChaussuresIci" en mai 2003 ET Comparer les ventes avec le même mois
de 2001 et 2002
• 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 ?
Les réponses aux requêtes OLAP peuvent prendre de quelques secondes à plusieurs minutes,
voire plusieurs heures.
Histoire [modifier]
Les principales dates à retenir construisant l'histoire de l'Entrepôt de données sont les
suivantes :
• Années 1960 - General Mills et l'Université Dartmouth, dans un projet conjoint, créent
les termes "faits" et "dimensions".
• 1983 - Teradata introduit dans sa base de données managériale un système
exclusivement destiné à la prise de décision.
• 1988 - Barry Devlin et Paul Murphy publient l'article "Une architecture pour les
systèmes d'information financiers" ("An architecture for a business and information
systems") où ils utilisent pour la première fois le terme "Datawarehouse".
• 1990 - Red Brick Systems crée Red Brick Warehouse, un système spécifiquement
dédié à la construction de l'Entrepôt de données.
• 1991 - Bill Inmon publie Building the Data Warehouse (Construire l'Entrepôt de
Données).
• 1995 - Le Data Warehousing Institute, une organisation à but lucratif destinée à
promouvoir le datawarehousing, est fondé.
 • 1996 - Ralph Kimball publie The Data Warehouse Toolkit (La boîte à outils de
l'Entrepôt de données).
Citations [modifier]
• « Un entrepôt de données ne s'achète pas, il se construit. » - Citation généralement
attribuée à Bill Inmon, un des précurseurs du concept d'entrepôt de données.
• « Un entrepôt de données est une collection de données orientées sujet, intégrées, non
volatiles et historisées, organisées pour le support d’un processus d’aide à la
décision. » - Bill Inmon, en 1994.
Notes et références [modifier]
1. ↑ Isabelle Comyn-Wattiau, Jacky Akoka (2003), Les bases de données, PUF, Que sais-je?, 978-
2130533139, chap. IX Les bases de données décisionnelles

Voir aussi [modifier]

Articles connexes [modifier]
• Les grands éditeurs de bases de données pour entrepôt de données : IBM, Oracle,
Teradata, Microsoft et Sybase IQ.
• Datamart
• Datamining
• Modèle de données dit "en étoile" ou "en flocon"
• Executive Information System
• Hypercubes multidimensionnels
• Informatique décisionnelle
• hadoop
• M-OLAP, R-OLAP, H-OLAP, S-OLAP
Liens externes [modifier]
• Journées francophones sur les entrepôts de données et l'analyse en ligne (EDA)
• Portail de l’informatique

Ce document provient de « http://fr.wikipedia.org/wiki/Entrep%C3%B4t_de_donn

%C3%A9es ».
Catégories : Ingénierie décisionnelle | Entrepôt de données | Architecture logicielle | [+]
Catégorie cachée : Portail:Informatique/Articles liés
Outils personnels
• Créer un compte ou se connecter
Espaces de noms
• Article
• Discussion
Variantes
Affichages
• Lire
 • Modifier
• Afficher l’historique
Actions
Rechercher
Top of Form
Spécial:Recherche

Bottom of Form
Navigation
• Accueil
• Portails thématiques
• Index alphabétique
• Un article au hasard
• Contacter Wikipédia
Contribuer
• Aide
• Communauté
• Modifications récentes
• Accueil des nouveaux arrivants
• Faire un don
Imprimer / exporter
• Créer un livre
• Télécharger comme PDF
• Version imprimable
Boîte à outils
• modification de cette page le 2 décembre 2010 à 07:33.
• Droit d'auteur : les textes sont disponibles sous licence Creative Commons paternité
partage à l’identique ; d’autres conditions peuvent s’appliquer. Voyez les conditions
d’utilisation pour plus de détails, ainsi que les crédits graphiques. En cas de
réutilisation des textes de cette page, voyez comment citer les auteurs et mentionner la
licence.
Wikipedia® est une marque déposée de la Wikimedia Foundation, Inc., organisation
de bienfaisance régie par le paragraphe 501(c)(3) du code fiscal des États-Unis.
• Politique de confidentialité
• À propos de Wikipédia
• Avertissements
•