Reporting

Un article de Wikipédia, l'encyclopédie libre.




Le reporting est la présentation périodique de rapports sur les activités et résultats d'une organisation, d'une unité de travail ou du responsable d'une fonction, destinée à en informer ceux chargés de les superviser en interne ou en externe, ou tout simplement concernés par ces activités ou résultats.

Le reporting concerne un type de rapports qui répond à la question « Que s’est-il passé ? » ou dans un contexte opérationnel à la question « Que se passe-t-il en ce moment ? ». Il existe d’autres types de rapport pour répondre à la question analytique « Pourquoi est-ce que cela s’est passé ? » et à la question pronostique « Que va-t-il se passer ? ». Tous ces différents rapports sont produits le plus souvent à partir d’un entrepôt de données.

Le terme désigne également une technique informatique de préparation de ces rapports, consistant à extraire des données pour les présenter dans un rapport humainement lisible (affichable ou imprimable).

Etapes [modifier]

Les étapes mises en œuvre sont les suivantes :

* ciblage des données puis des sources de données à rassembler, avec par exemple un paramétrage de l'année, du domaine, etc.
* extraction des informations utiles : groupement, tris, fonctions d'agrégation, calculs d'indices, etc.
* mise en forme d'un rapport avec un canevas défini
* production du rapport sous sa forme lisible
* publication ou diffusion du rapport (intranet, messagerie électronique, document, etc.)

http://www.polymorphe.org/index.php?rub=cours&matiere=12
-----------------
http://pentaho-tutorial.blogspot.com/2008/01/tutorial-design-studio-pentaho.html
----------------
http://www-igm.univ-mlv.fr/~dr/XPOSE2006/DELTIL_PEREIRA/pentaho.html
-------------
http://mondrian.pentaho.org/documentation/schema.php#Measures
----------
http://rpbouman.blogspot.com/2006/07/hands-on-mysql-samples-for-pentaho-2_12.html
------------
http://www.noname.fr/analyse-decisionnelle/installation-pentaho.html

----------
http://www.developpez.net/forums/showthread.php?t=480910
--------
http://www.systemeetl.com/articles.htm
http://www.tdwi.org/
-------

source :www.mysql.com
-------------------------------------
Chaque catégorie d’installation identifiée ci-dessus gère au moins l’un des types de trafic défini par
Gartner, et parfois plus d’un seul. D’après Gartner, c’est lorsque l’installation d’un entrepôt de données doit
gérer un trafic hétérogène que les problèmes commencent, aussi bien en ce qui concerne la gestion que la
performance. Gartner affirme ainsi :
“Les quatre types de trafic représentent un challenge pour les fournisseurs, bien plus que la taille
des données, quand bien même celle-ci est inférieure à 1 To. Outre les attentes en termes de
qualité de service, la taille et la longévité des données « utiles » diffère grandement d’un groupe à
un autre, impliquant chaque élément de l’environnement de l’entrepôt de données, depuis
l’équilibre entre les entrées et les sorties (I/O) jusqu’à l’allocation de la mémoire et du processeur,
en passant par la gestion du disque. Dans les trois prochaines années, la performance en situation
de trafic hétérogène sera la question clé lorsque l’on parlera de la performance d’un entrepôt de
données.”5
Lorsque l’on cherche à résoudre une situation de trafic hétérogène, on peut se heurter à des problèmes de
budget car cela implique souvent la séparation de l’entrepôt de données par zone d’intérêt entre plusieurs
serveurs et bases de données. C’est justement l’une des raisons pour laquelle les professionnels des
technologies de l’information se tournent vers l’open source pour répondre à leurs besoins en termes
d’entrepôts de données. Cependant le budget n’est pas la seule raison pour porter son choix sur un
SGBDR tel que MySQL pour la gestion d’entrepôts de données. De nombreux facteurs font de MySQL un
choix intéressant dans ce domaine, y compris un historique d’entreprise solide, une série de fonctions de
base particulièrement adaptées à la gestion d’entrepôts de données, une architecture et une conception
exceptionnelles qui permettent de répondre au problème du trafic hétérogène et un réseau croissant de
partenaires dans le domaine des logiciels et des outils dédiés à l’informatique décisionnelle.

je ne sais pas comment je vais vous expliquez peut être parce que c'est une longue histoire
bref je mis en dessous un livre blanc qui explique pourquoi choisir Mysql comme datawarhouse

source: http://www.mysql.fr/company/contact/ ou appelez nous au 01 70 38 72 00 (+33 1 70 38 72 00 hors de France).
------------------
Introduction
Les entreprises modernes qui mènent le jeu réalisent l’importance cruciale de disposer des informations
adéquates pour pouvoir prendre les décisions stratégiques guidant la conduite de l’entreprise. Dans ces
conditions, il n’est pas surprenant qu’une enquête du Gartner Group ait souligné en 2006 que les DSI
plaçaient l’informatique décisionnelle (Business Intelligence – BI) en tant que priorité technologique
numéro deux, quand elle n’était que dixième il y a trois ans seulement.1 Cette préoccupation a été
confirmée par une enquête effectuée en 2007 par InformationWeek qui a révélé que près de la moitié des
décideurs informatiques prévoyaient d’augmenter leur budget de BI au-dessus du niveau de 2006.2
Ces tendances montrent clairement que les entreprises avisées prennent conscience que leur capacité à
être compétitif dépend fortement de leur utilisation judicieuse de la technologie et de l’information, que ce
soit pour permettre à leurs clients de mieux communiquer, établir des relations, partager et localiser des
informations, ou pour acheter des biens et services de façon plus efficace.
Toutefois, cette recherche d’une information plus abondante et de meilleure qualité pour faciliter les
décisions a amené un certain nombre de défis intéressants. En premier lieu, le volume d’informations
géré par les entrepôts de données d’entreprise devient en lui-même un problème clé. Analysant une
enquête menée en 2006 par son cabinet, Philip Russom, directeur de la recherche chez TDWI, a affirmé :
“Les entrepôts de données vont subir une croissance moyenne annuelle de 33% en ce qui concerne leur
volume de données, voire même 50% minimum lorsqu’ils sont confrontés à de fortes exigences en
matière de données clients, de chaîne logistique, d’e-commerce ou de gestion de conformité des
données.”3 Cette même enquête a révélé que l’on comptait 36% d’entrepôts de données multi téraoctets
en 2006 et que 48% le deviendraient avant la fin de 2007.
En second lieu, l’appétit croissant pour l’informatique décisionnelle a induit des types d’utilisation
spécialisés d’entrepôts de données (des schémas différents de croissance et d’utilisation des données)
que l’on peut difficilement centraliser ou gérer dans un seul magasin d’analyse de données. Nous en
reparlerons plus loin dans ce document.
Enfin, la mise en place et la gestion d’infrastructures complexes d’informatique décisionnelle, avec
l’organisation croissante et exigeante qui en résulte, génère des budgets en augmentation constante.
D’après l’enquête d’InformationWeek citée ci-dessus, 39% des personnes sondées déploraient le fait que
le coût élevé des licences logicielles les entravait dans la réalisation de leurs projets en matière
d’entrepôts de données et d’informatique décisionnelle.
Pour faire face à ces problèmes et réaliser l’objectif de disposer de systèmes d’entrepôts de données
extensibles et réactifs, les entreprises modernes se tournent vers les solutions open source pour
satisfaire leurs besoins. Le logiciel open source a prouvé sa valeur dans le domaine du web et s’introduit
de plus en plus dans les structures d’entreprises. Ainsi, une étude du cabinet Gartner prévoit que 70%
des entreprises utiliseront des bases de données open source dès la fin de 2008.4 Dans ces conditions, il
était naturel que la technologie open source investisse le domaine des entrepôts de données et de
l’informatique décisionnelle.
Bien que le serveur de base de données MySQL se soit hissé au rang de leader incontesté dans la
gestion de données pour les applications en ligne, beaucoup se demandent s’il peut faire de même dans
le domaine des entrepôts de données et de l’informatique décisionnelle. Ce document expose la stratégie
de MySQL en ce qui concerne les entrepôts de données et démontre les possibilités et avantages
exceptionnels de cette base pour les besoins en entrepôts de données et en informatique décisionnelle.

Un examen du trafic des entrepôts de données
Dans son Magic quadrant de la catégorie systèmes de gestion d'entrepôts de données de 2006, Gartner a
identifié plusieurs types de trafic liés aux entrepôts de données, établissant ainsi des catégories
d’utilisations basées sur les différents cas rencontrés chez des entreprises activement impliquées dans
l’informatique décisionnelle. Ces types de trafic s’établissaient ainsi :
• Le chargement continuel de données (proche du temps réel) — similaire à un trafic de traitement de
transactions en ligne (OLTP).
• De grandes quantités de rapports standards allant jusqu’à des milliers par jour, nécessitant une
utilisation précise du SQL et la création d’index.
• Un nombre croissant d’utilisateurs de requêtes ad hoc générant une utilisation aléatoire, non prévisible
des données.
• Des fonctions d’analyse orientées BI dans des applications OLTP
Si l’on traduit concrètement ces différents trafics en installations d’entrepôts de données, on obtient les
types d’utilisation suivants :
1. Des petits magasins de données, opérant en temps semi réel
2. Des entrepôts de données répondant en continu à des requêtes en temps réel
3. Des entrepôts de données alimentant un reporting standard traditionnel
4. Du stockage de masses de données historiques soumises à des requêtes ad hoc
5. Des analyses liées à l’informatique décisionnelle, dans les applications OLTP (une tendance
émergeante)
A présent, examinons en détail chacun de ces types d’utilisation afin d’en comprendre les différences
essentielles.
2.1 Analyse des types d’utilisation des entrepôts de données
Le premier type d’utilisation de l’entrepôt de données est le magasin de données. Les magasins de
données sont habituellement caractérisés par deux choses : (1) leur taille et (2) leur public d’utilisateurs.
Les magasins de données ont tendance à gérer des volumes de données inférieurs et à satisfaire un
besoin plus restreint, gérant bien souvent ces données pour une zone particulière de l’entreprise ou même
une partie seulement de cette zone. La fréquence de mise à jour d’un magasin de données (la cadence
journalière ou horaire avec laquelle ses données sont rafraîchies par l’activité transactionnelle) dépend du
besoin du secteur qui utilise ces informations pour prendre des décisions. Si les décisions importantes
nécessitent de disposer des données les plus récentes possible, on peut rencontrer des systèmes
d’alimentation en temps réel. Sinon on trouvera plutôt des systèmes de rafraîchissement quotidiens ou
hebdomadaires.
L’entrepôt de données en temps réel est devenu populaire ces dernières années, principalement à
cause d’un désir croissant de disposer de l’information la plus récente possible pour battre la concurrence.
L’entrepôt de données en temps réel implique un arbitrage permanent entre les ressources affectées au
rafraîchissement des données et les requêtes adressées au même ensemble de données, une
augmentation du volume stocké à une cadence journalière ou horaire, des procédures de purges des
données inutiles et un public d’utilisateurs qui peut être large ou restreint suivant le contenu de l’entrepôt
de données.
L’entrepôt de données traditionnel, comme son nom l’indique, est le type d’utilisation auquel on pense le
plus souvent quand on parle d’entrepôts de données. Brassant de gros volumes de données, soumis à des
taux de rafraîchissement peu fréquents (qui ne sont pas définis en termes d’heures, et parfois ne sont même pas quotidiens) et desservant un public important et varié, l’entrepôt de données traditionnel
constitue généralement pour les entreprises leur première application (après le magasin de données)
lorsqu’ils mettent en place un stockage de données à des fins d’informatique décisionnelle.
L’entrepôt de données historiques est relativement nouveau et est apparu à la suite de lois assez
récentes qui obligent de nombreuses entreprises à conserver de grandes quantités d’informations à la
disposition du gouvernement ou pour répondre à d’autres contraintes de conformité. L’entrepôt de données
historiques gère des volumes de données généralement plus importants que les entrepôts de données
traditionnels et il est soumis à des rafraîchissements de fréquence moyenne, mais il génère typiquement
moins de trafic d’interrogation que les magasins de données, l’entrepôt de données en temps réel ou
l’entrepôt de données traditionnel.
L’entrepôt d’analyse de données OLTP est parfois considéré comme un retour dangereux aux temps où
les bases de données jusqu’alors consacrées à une activité transactionnelle rapide devinrent
simultanément la cible d’un flux intensif de requêtes d‘analyse. La juxtaposition de ces deux trafics signifia
bien souvent la mort d’applications qui nécessitaient des temps de réponse rapides pour satisfaire des
clients qui exigeaient d’être servis rapidement. L’entrepôt d’analyse de données OLTP constitue
généralement un serveur dorsal d’entrepôt de données pour une application OTLP standard, mais il
contient également certains objets qui sont alimentés par les transactions et sont conçus pour permettre
les requêtes d’informatique décisionnelle.
On pourrait citer d’autres types d’utilisation « niches », mais ce qui précède constitue la grande majorité de
ce que l’on trouve aujourd’hui en entreprise.

Certaines caractéristiques sont identiques. Mais il existe de nombreux éléments permettant
de différencier les deux notions.
L’infocentre est une collection de données orientées sujet, intégrées, volatiles, actuelles,
organisées pour le support
’un processus de décision ponctuel.
Le Data Warehouse est une collection de données orientées sujet, intégrées, non volatiles,
historisées, organisées pour le support d’un processus d’aide à la décision.
Dans un infocentre, chaque nouvelle valeur remplace l’ancienne valeur. Il est donc
impossible de retrouver une valeur calculée dans une session préalable aux dernières
alimentations. La non volatilité est une caractéristique essentielle du Data Warehouse.
De même, l’historisation des données dans un infocentre, il n’y a pas de gestion
d’historique des valeurs.
L’infocentre sert à prendre des décisions opérationnelles basées sur des valeurs courantes.
Au niveau d’un Data Warehouse, l’utilisateur travaille sur les historiques pour des prises de
décisions à long terme, des positionnements stratégiques et pour analyser des tendances.
Dans un infocentre, l’intégration des données est plus ou moins poussée. Le processus
d’alimentation est simple.
Le finalité d’un infocentre est de permettre aux utilisateurs d’accéder à leur données dans
leurs propres termes.

**Infocentre
Collection de données
Orientées sujet
Intégrées
Volatiles
Actuelles
Organisées pour le support d’un
processus de décision ponctuelle
Outil

**Data Warehouse

Collection de données
Orientées sujet
Intégrées
Non volatiles
Historisées
Organisées pour le support d’un
processus d’aide à la décision
Architecture


La mise en évidence des différences est exprimée par les questions suivantes :
· Quels infocentres sont motivés par des objectifs business et sont au service de la
stratégie de l’entreprise ?
· Quels infocentres permettent de connaître la concurrence, d’anticiper les besoins ?
· Quelles entreprises mesurent le retour sur investissement ?

L’infocentre est un outil alors que le Data Warehouse est une architecture.

http://projectmanagementacademy.com/etldatawarehouse.htm

ETL processes can be quite complex, and significant operational problems can occur with improperly designed ETL systems.

The range of data values or data quality in an operational system may be outside the expectations of designers at the time validation and transformation rules are specified. Data profiling of a source during data analysis is recommended to identify the data conditions that will need to be managed by transform rules specifications.

The scalability of an ETL system across the lifetime of its usage needs to be established during analysis. This includes understanding the volumes of data that will have to be processed within Service Level Agreements. The time available to extract from source systems may change, which may mean the same amount of data may have to be processed in less time. Some ETL systems have to scale to process terabytes of data to update data warehouses with tens of terabytes of data. Increasing volumes of data may require designs that can scale from daily batch to intra-day micro-batch to integration with message queues for continuous transformation and update.

Recent developments in ETL software has been the implementation of parallel processing. This has enabled a number of methods to improve overall performance of ETL processes when dealing with large volumes of data.

There are 3 main types of parallelisms as implemented in ETL applications:

Data: By splitting a single sequential file into smaller data files to provide parallel access.

Pipeline: Allowing the simultaneous running of several components on the same data stream. E.g. performing step 2: lookup a value on record 1 at the same time as step 1: add two fields together is performed on record 2.

Component: The simultaneous running of multiple processes on different data streams in the same job. E.g. doing a sort on input file 1 at the same time that the contents of input file 2 are deduped.

All three types of parallelisms are usually combined in a single job.

An additional difficulty is making sure the data being uploaded is relatively consistent. Since multiple source databases all have different update cycles (some may be updated every few minutes, while others may take days or weeks), an ETL system may be required to hold back certain data until all sources are synchronized. Likewise, where a warehouse may have to be reconciled to the contents in a source system or with the general ledger establishing synchronization and reconciliation points is necessary.


Tools

While an ETL process can be created using almost any programming language, creating them from scratch is quite complex. Increasingly, companies are buying ETL tools to help in the creation of ETL processes.

A good ETL tool must be able to communicate with the many different relational databases and read the various file formats used throughout an organization. ETL tools have started to migrate into Enterprise Application Integration, or even Enterprise Service Bus, systems that now cover much more than just the extraction, transformation and loading of data. Many ETL vendors now have data profiling, data quality and metadata capabilities.


Some ETL tools

* Ab Initio
* Barracuda Integrator
* BusinessObjects Data Integrator
* Cast Iron Systems
* CloverETL OpenSource Project‘s Home Page
* Cognos Decisionstream
* Corporater Transformer
* CoSORT CoSORT ETL tools
* Crossflo Systems DataExchange
* Data Transformation Services (Included in Microsoft SQL Server 2000)
* Embarcadero DT Studio
* Group 1 Software's DataFlow
* Hummingbird GENIO
* ETL4ALL Ikan Software Engine Based ETL Tool
* IBM Websphere DataStage (Previously Ascential DataStage)
* Informatica PowerCenter
* KETTLE (Pentaho ETL)
* MetaSuite Ikan Software Code Generator Based ETL Tool
* Microsoft Biztalk Server
* Netik Interview7
* Oracle Warehouse Builder
* Pervasive Data Integrator
* SAS Data Integration Studio (formerly ETL Studio)
* Solonde ETL (Solonde is now part of Sybase, Inc)
* SQL Server Integration Services (Included in Microsoft SQL Server 2005)
* Sunopsis
* Syncsort's DMExpress
* Talend - Open Data Solutions based on Eclipse
* Transformation Manager
* WisdomForce FastReader



A Data warehouse is an application with a computer database that collects, integrates and stores an organization's data with the aim of producing accurate and timely management of information and support for analysis techniques, such as data mining.



Definition of a Data Warehouse

Today's definition of "what is a data warehouse"? goes beyond the traditional, as the concept has evolved. The previous definition, "a data warehouse is a collection of computerised data that is organised to most optimally support reporting and analysis activity," ought to be expanded.

A data warehouse is a repository of an organization's data, where the informational assets of the organization are stored and managed, to support various activities such as reporting, analysis, decision-making, as well as other activities such as support for optimization of organizational operational processes. An enterprise data warehouse is further described as the "single point of truth", the "corporate memory", the sole historical register of virtually all transactions and important operational events that occur in the life of an organization. This data is ultimately stored and cataloged for immediate and future utilization in various forms, such as deployment into some application. It is through these various uses and deployments that this data becomes information, to be potentially exploited for benefit.

The practice of data warehousing includes the storage of virtually all transactional data, master data (customer, material), and meta data at a very detailed level. Data warehousing as a topic is linked closely with Business Intelligence (BI), but supports a wide range of activities as it essentially becomes the basis for what Bill Inmon has termed the "Information Factory", as in the "Corporate Information Factory", or the "Government Information Factory". As the concepts demonstrate, a data warehouse is actually foundational for the realization of significant overall benefits from the utilization of technology within the context of organizational operations. Data warehousing represents a natural evolution from the traditional concept of information technology, which has been mainly grounded in the automation of operations; data warehousing seeks to optimize data management and further processes data, to support its deployment and exploitation as information.

Bill Inmon's formal systems definition of a data warehouse is a computer database and its supporting components that is:

* Subject-oriented, meaning that the data in the database is organised so that all the data elements relating to the same real-world event or object are linked together;
* Time-variant, meaning that the changes to the data in the database are tracked and recorded so that reports can be produced showing changes over time;
* Non-volatile, meaning that data in the database is never over-written or deleted, but retained for future reporting; and,
* Integrated, meaning that the database contains data from most or all of an organisation's operational applications, and that this data is made consistent.



History of data warehousing

Data Warehouses became a distinct type of computer database during the late 1980's and early 1990's. They developed to meet a growing demand for management information and analysis that could not be met by operational systems.ɟ Operational systems were unable to meet this need for a range of reasons:

* The processing load of reporting reduced the response time of the operational systems,
* The database designs of operational systems were not optimised for information analysis and reporting,
* Most organizations had more than one operational system, so company-wide reporting could not be supported from a single system, and
* Development of reports in operational systems often required writing specific computer programs which was slow and expensive

As a result, separate computer databases began to be built that were specifically designed to support management information and analysis purposes. These data warehouses were able to bring in data from a range of different data sources, such as mainframe computers, minicomputers, as well as personal computers and office automation software such as spreadsheets, and integrate this information in a single place. This capability, coupled with user-friendly reporting tools and freedom from operational impacts, has led to a growth of this type of computer system.

As technology improved (lower cost for more performance) and user requirements increased (faster data load cycle times and more features), data warehouses have evolved through several fundamental stages:

* Offline Operational Databases - Data warehouses in this initial stage are developed by simply copying the database of an operational system to an off-line server where the processing load of reporting does not impact on the operational system's performance.
* Offline Data Warehouse - Data warehouses in this stage of evolution are updated on a regular time cycle (usually daily, weekly or monthly) from the operational systems and the data is stored in an integrated reporting-oriented data structure
* Real Time Data Warehouse - Data warehouses at this stage are updated on a transaction or event basis, every time an operational system performs a transaction (e.g. an order or a delivery or a booking etc.)
* Integrated Data Warehouse - Data warehouses at this stage are used to generate activity or transactions that are passed back into the operational systems for use in the daily activity of the organization.sdsds

Data Sources

Data sources refers to any electronic repository of information that contains data of interest for management use or analytics. This definition covers mainframe databases (eg IBM DB2, ISAM, Adabas, Teradata, etc.), client-server databases (e.g. Teradata, IBM DB2, Oracle database, Informix, Microsoft SQL Server etc.), PC databases (eg Microsoft Access), spreadsheets (eg Microsoft Excel) and any other electronic store of data. Data needs to be passed from these systems to the data warehouse either on a transaction-by-transaction basis for real-time data warehouses or on a regular cycle (e.g. daily or weekly) for offline data warehouses.


Data Transformation

The Data Transformation layer receives data from the data sources, cleans and standardises it, and loads it into the data repository. This is often called "staging" data as data often passes through a temporary database whilst it is being transformed. This activity of transforming data can be performed either by manually created code or a specific type of software could be used called an ETL tool. Regardless of the nature of the software used, the following types of activities occur during data transformation:

* comparing data from different systems to improve data quality (e.g. Date of birth for a customer may be blank in one system but contain valid data in a second system. In this instance, the data warehouse would retain the date of birth field from the second system)
* standardising data and codes (e.g. If one system refers to "Male" and "Female", but a second refers to only "M" and "F", these codes sets would need to be standardised)
* integrating data from different systems (e.g. if one system keeps orders and another stores customers, these data elements need to be linked)
* performing other system housekeeping functions such as determining change (or "delta") files to reduce data load times, generating or finding surrogate keys for data etc.



Data Warehouse

The data warehouse need not to be a relational database, as it must be organised to hold information in a structure that best supports not only query and reporting, but also advanced analysis techniques, like data mining. Most data warehouses hold information for at least 1 year and sometimes can reach half century, depending on the business/operations data retention requirement. As a result these databases can become very large.


Reporting

The data in the data warehouse must be available to the organisation's staff if the data warehouse is to be useful. There are a very large number of software applications that perform this function, or reporting can be custom-developed. Examples of types of reporting tools include:

* Business intelligence tools: These are software applications that simplify the process of development and production of business reports based on data warehouse data.
* Executive information systems (known more widely as Dashboard (business): These are software applications that are used to display complex business metrics and information in a graphical way to allow rapid understanding.
* OLAP Tools: OLAP tools form data into logical multi-dimensional structures and allow users to select which dimensions to view data by.
* Data Mining: Data mining tools are software that allow users to perform detailed mathematical and statistical calculations on detailed data warehouse data to detect trends, identify patterns and analyse data.



Metadata

Metadata, or "data about data", is used not only to inform operators and users of the data warehouse about its status and the information held within the data warehouse, but also as a means of integration of incoming data and a tool to update and refine the underlying DW model.

Examples of data warehouse metadata include table and column names, their detailed descriptions, their connection to business meaninful names, the most recent data load date, the business meaning of a data item and the number of users that are logged in currently.


Operations

Data warehouse operations comprises of the processes of loading, manipulating and extracting data from the data warehouse. Operations also cover user management, security, capacity management and related functions


Optional Components

In addition, the following components also exist in some data warehouses:

1. Dependent Data Marts: A dependent data mart is a physical database (either on the same hardware as the data warehouse or on a separate hardware platform) that receives all its information from the data warehouse. The purpose of a Data Mart is to provide a sub-set of the data warehouse's data for a specific purpose or to a specific sub-group of the organisation.
2. Logical Data Marts: A logical data mart is a filtered view of the main data warehouse but does not physically exist as a separate data copy. This approach to data marts delivers the same benefits but has the additional advantages of not requiring additional (costly) disk space and it is always as current with data as the main data warehouse.
3. Operational Data Store: An ODS is an integrated database of operational data. Its sources include legacy systems and it contains current or near term data. An ODS may contain 30 to 60 days of information, while a data warehouse typically contains years of data. ODS's are used in some data warehouse architectures to provide near real time reporting capability in the event that the Data Warehouse's loading time or architecture prevents it being able to provide near real time reporting capability.


Different methods of storing data in a data warehouse

All data warehouses store their data grouped together by subject areas that reflect the general usage of the data (Customer, Product, Finance etc.). The general principle used in the majority of data warehouses is that data is stored at its most elemental level for use in reporting and information analysis.

Within this generic intent, there are two primary approaches to organising the data in a data warehouse.

The first is using a "dimensional" approach. In this style, information is stored as "facts" which are numeric or text data that capture specific data about a single transaction or event, and "dimensions" which contain reference information that allows each transaction or event to be classified in various ways. As an example, a sales transaction would be broken up into facts such as the number of products ordered, and the price paid, and dimensions such as date, customer, product, geographical location and sales person. The main advantages of a dimensional approach is that the Data Warehouse is easy for business staff with limited information technology experience to understand and use. Also, because the data is pre-processed into the dimensional form, the Data Warehouse tends to operate very quickly. The main disadvantage of the dimensional approach is that it is quite difficult to add or change later if the company changes the way in which it does business.

The second approach uses database normalisation. In this style, the data in the data warehouse is stored in third normal form. The main advantage of this approach is that it is quite straightforward to add new information into the database, whilst the primary disadvantage of this approach is that it can be quite slow to produce information and reports.


Advantages of using data warehouse

There are many advantages to using a data warehouse, some of them are:

* Enhances end-user access to a wide variety of data.
* Business decision makers can get the trend reports e.g. The item with the most sales in a particular area/ country for the last two years. This may be helpful for future investments in a particular item.
* Increases data consistency.
* Increases productivity and decreases computing costs.
* Is able to combine data from different sources, in one place.
* It provides an infrastructure that could support changes to data and replication of the changed data back into the operational systems.



Concerns in using data warehouse

* Extracting, cleaning and loading data could be time consuming.
* Data warehousing project scope might increase.
* Problems with compatibility with systems already in place e.g. transaction processing system.
* Providing training to end-users, who end up not using the data warehouse.
* Security could develop into a serious issue, especially if the data warehouse is web accessible.

2 Composants constituant un datawarehouse
Les composants de la majorité des entrepôts de données sont expliqués ci-dessous.



2.1 Données sources
Les data sources se rapporte à n'importe quel dépôt d'information qui contient des données d'intérêt à l'utilisation ou à l’analyse de gestion. Cette définition couvre les bases de données d'unité centrale (par exemple IBM DB2, ISAM, Adabas, Teradata, etc.), les bases de données de serveur de client (par exemple Teradata, IBM DB2, base de données d'oracle, Informix, serveur de Microsoft SQL, etc.), les bases de données de PC (par exemple Microsoft Access, Alpha, Five), les tableurs (par exemple Microsoft Excel) et n'importe quel autre stock électronique de données. Des données doivent être passées de ces systèmes à l'entrepôt de données sur une base de transaction-par-transaction pour les entrepôts en temps réel de données ou sur un cycle régulier (par exemple quotidiennement ou hebdomadaire) pour les entrepôts de données hors ligne.

2.2 Transformation de données
La couche de transformation de données reçoit des données des points d'émission de données, les nettoie, les normalise, et les charge dans le répertoire de données. Ceci s'appelle souvent les données d'"échafaudage" pendant que les données traversent souvent une base de données provisoire tandis qu'elles sont transformées. Cette activité des données de transformation peut être exécutée ou par code manuellement créé ou par un type spécifique de logiciel. Indépendamment de la nature du logiciel utilisé, les types suivants d'activités se produisent pendant la transformation de données :

- comparer des données de différents systèmes pour améliorer la qualité des données : par exemple la date de naissance pour un client peut être blanc dans un système mais contenir des données valides dans un deuxième système. Dans ce cas, l'entrepôt de données maintiendrait la date de naissance la zone du deuxième système.

- normalisant des données de différents systèmes par exemple si un système se rapporte au "mâle" et à la "femelle", mais une seconde se rapporte seulement à "M" et à "F", ces codes devraient être normalisés)

- exécutant d'autres fonctions de ménage de système telles que fichiers de détermination de changement (ou les "delta") pour réduire les moments de chargement de données, produisant ou trouvant des clés de remplacement pour les données etc...

2.3 Le datawarehouse
L'entrepôt de données est généralement une base de données relationnelle. Il doit être organisé pour tenir l'information dans une structure que les supports questionnent. La plupart des entrepôts de données tiennent l'information pendant au moins 1 année et parfois peuvent atteindre demi de siècle, selon la condition de conservation de données de définie par l’entreprise. En conséquence ces bases de données peuvent devenir très grandes.

2.4 Rapports de données
Les données dans le datawarehouse doivent être à la disposition du personnel de l'organisation, exemple la force de vente. Il y a un nombre très grand nombre d'applications qui exécutent cette fonction. Exemple de logiciel de reporting:

- Business Intelligence Tools : Applications qui simplifient le processus de rapport de données basé sur le datawarehouse. Exemple : Brio Designer, Hyperion Intelligence

- Outils OLAP : OLAP traite les données dans les structures multidimensionnelles et permet aux utilisateurs de choisir quelles dimensions ils désirent pour la visualisation

- Les outils d'extraction de données : sont des logiciels qui permettent aux utilisateurs d'exécuter des calculs mathématiques et statistiques détaillés sur des données détaillées de datawarehouse pour détecter des tendances,
identifier des configurations et analyser des données.

Le but de l'OLAP (On-Line Analytical Processing) est de permettre une analyse multidimensionnelle sur des bases de données volumineuses afin de mettre en évidence une analyse particulière des données (il est l'objet d'un questionnement particulier).
Grâce à l'OLAP, les utilisateurs peuvent créer des représentations multidimensionnelles (appelées hypercubes ou « cubes OLAP ») selon les critères qu'ils définissent afin de simuler des situations
DW : ensemble de donnees (internes et externes) d’entreprise accessibles par les utilisateurs à travers les vues « metier ».
Son rôle : transformer les donnees en information , générer du nusiness.
Le data werhousse permet de :
Réagir plus vite que la concurrence
Prendre des décisions justes
Mieux contôler les côuts et les risques
Elargir l’offre
Cibler mieux le client
Choix typologique
DW virtuel
Lot des data Marts
DW sans accées utilisateur
Accées directe à DW et certains DM
Comment faire
Top-Down
Bottom-up
Hybride(mixte)
Difficultés
Données hétérogènes (multitude d’environnements techniques ,de structures, de formats)
Différents règles de gestion
Différents niveaux de synchronisation
Différentes plages de disponibilité
Mythes
DW contient seulement des données agrégées.
DW contient toutes les données d’entreprise.
DW doit être construit d’un seul coup
DW est massivement utilisé
DW n’est plus utilisé après le changement du business

[FONT=Courier][COLOR=blue]

La conduite d’un projet en Business Intelligence suit les règles classiques de la conduite d’un
projet informatique. Nous soulignons ici un ensemble de points particulièrement sensibles, à
l’origine de la plupart des défaillances et échecs de projets d’informatique décisionnelle :
• L’ambition des projets dès leur première édition est souvent trop élevée, avec des
projets trop complexes voulant à la fois reprendre l’existant et ajouter de nombreuses
nouvelles fonctionnalités. Un entreprise dispose toujours de rapports (même parfois
très fastidieux à produire) avant l’arrivée de la Business Intelligence. Si les utilisateurs
ont des difficultés a recevoir des résultats équivalents à l’existant avec le passage à la
Business Intelligence lors de la première mise en place, l’insatisfaction sera élevée. Il est
toujours préférable de suivre une démarche itérative : Réaliser un premier lot de
services moins ambitieux mais qui aboutit en quelques mois, puis enrichir
progressivement et en continu les services apportés. Il y a parfois loin entre le discours
et la mise en pratique de démarches itératives.
• L’expérience et la compétence de l’équipe. Même si la conduite de projet suit des
règles classiques, quelques expériences spécifiques sur le décisionnel sont souvent
essentielles dans une équipe projet. Modéliser un système décisionnel ne s’improvise
pas et peut être particulièrement complexe et spécifique.
• L’expression de besoins manque parfois de précision. Les indicateurs demandés restent
parfois trop « macroéconomiques ». Par exemple, définir l’indicateur « Chiffre
d’Affaires » ne définit pas pour autant les règles de gestion nécessaires pour obtenir
cet indicateur, avec le traitement de ses exceptions et de ses parfois nombreux cas
particuliers. Il ne faut pas oublier que le système décisionnel joue un peu un effet de
loupe sur le système d’information général. On va retrouver dans le système
décisionnel des difficultés attachées au système d’information lui-même, incohérences
en terme de données… Ces difficultés apparaissent souvent au moment de la recette du
système décisionnel et sont souvent attachés à une faiblesse de l’expression des
besoins détaillée.

L'engouement pour les projets décisionnels - Business Intelligence (BI), en anglais - est
sans précédent, car le volume de données produites par une entreprise double tous les
cinq ans. Des données qu'il faut trier puis agréger sous la forme d'indicateurs de gestion
synthétiques pour pouvoir prendre des décisions pertinentes.
« Vous pilotez un avion de nuit. Comment atterrissez-vous sans écran de contrôle ? »,
résume Jean-Michel Bras, secrétaire général d'Aexxdis, spécialiste de la logistique des
produits de santé (120 collaborateurs), qui propose des tableaux de bord métier à
l'ensemble des professionnels avec qui l'entreprise travaille.
Les outils des éditeurs propriétaires - Business Objects, Cognos, Hyperion, SAS,
Teradata, etc. - coûtent cher, car ils sont souvent facturés au nombre d'utilisateurs ou de
connexions simultanées. Les entreprises se tournent donc vers des outils open source
pour réduire les coûts de licence, de 20 à 50 % du coût total d'un projet décisionnel.
« Nous ne nous sommes même pas intéressés aux outils propriétaires tant ils sont
chers », illustre Frédéric Jourden, directeur marketing de Xinek (cinq employés), un
service de recommandation d'achat en réseau, qui utilise Pentaho pour la restitution
(tableau de bord, etc.) et MySQL pour son entrepôt de données (stockage des données).
Cependant, parce qu'elles ne sont pas aussi bien finies que les suites propriétaires, « les
suites open source requièrent parfois un effort de participation du client dans le
développement. Mais elles permettent en contrepartie de lui construire une solution sur
mesure », indique Michael Bienstein, responsable BI open source chez BearingPoint et
membre actif des projets olap4J et Mondrian.
Pour accélérer les déploiements, des éditeurs, tels Pentaho et Jasper-Soft, et des
intégrateurs comme Engineering (SpagoBI) proposent donc des suites presque complètes
intégrant ETL, moteur Olap, serveur de rapports, etc. Idem du côté des bases de
données. Si PostgreSQL et MySQL ne rivalisent pas avec Teradata, elles répondent
cependant aux contraintes de nombreux projets.
L'utilisation : mieux piloter son activité
Propriétaire ou libre, le besoin fonctionnel de l'entreprise se résume toujours à « disposer
d'informations pertinentes pour mieux vendre et faire les bons choix stratégiques ».
Aexxdis a, par exemple, déployé un portail métier proposant des tableaux de bord aux
personnes extérieures à l'entreprise et une navigation multidimensionnelle (Olap) en
interne. L'ensemble du projet repose sur des briques open source : Pentaho, PostgreSQL,
OpenLDAP, etc.
« Le management capte et analyse ainsi plus rapidement l'information structurante, ce
qui améliore le processus de décision en termes de qualité et de délai. Nos clients
disposent quotidiennement d'une quarantaine d'indicateurs et de sources d'informations
à travers un portail décisionnel sécurisé », détaille Jean-Michel Bras. Chez Xinek, Pentaho
permet de mieux comprendre l'audience du service en ligne pour proposer des cibles à
forte valeur ajoutée aux annonceurs qui rémunèrent l'entreprise en fonction des ventes
générées
Bien qu'étant un service public, le Secrétariat pour les affaires régionales de la préfecture
de région Midi-Pyrénées (SGAR, 55 employés) a suivi exactement la même démarche
(PostgreSQL, SpagoBi) afin que « les préfets des huit départements disposent de
tableaux de bord efficaces pour juger la performance des engagements pris dans le cadre
de la LOLF », explique Philippe Ourliac, chargé de mission TIC au sein du SGAR.
Le projet comprend trois datamarts stockant des indicateurs pour 34 missions,
130 programmes et 50 budgets opérationnels. C'est surtout le coût des outils
propriétaires qui explique son choix. « Avec 340 contributeurs, les coûts de licence
faisaient exploser notre budget. L'open source nous affranchit de ces coûts tout en
augmentant notre indépendance vis-à-vis d'un fournisseur », résume Philippe Ourliac. A
l'image de Sabre (système de réservation de voyages aériens) et de Swissport (gestion
des aéroports suisses, 21 000 employés), les grandes entreprises recourent plutôt à l'
open source pour rationaliser et réduire le coût de certains projets décisionnels.
« Notre base de données Teradata était surdimensionnée tant sur un plan fonctionnel
que financier. Nous avons donc opté pour MySQL », illustre Michael Benzinger, chez
Sabre. L'entreprise a créé un entrepôt de données de plus de 4 To en trois semaines, en
ne prenant en charge que le coût du matériel : 62 500 dollars au total.
De son côté, Swissport souhaitait « réduire le nombre d'outils de reporting en interne et
tirer plus de valeur ajoutée des données que nous produisons toute l'année », explique
Uwe Geercken, son responsable informatique.
La mise en oeuvre : l'ouverture facilite la cohabitation
Un projet décisionnel est souvent découpé en deux lots. L'entrepôt de données
(datawarehouse) agrège certaines données de production selon un schéma en étoile à n
dimensions métier : client, produit, etc. Contrairement à une base traditionnelle,
certaines données peuvent être dupliquées pour des raisons de performance.
La couche de restitution comprend, elle, les nombreuses briques techniques qui
permettent à l'utilisateur de visualiser les indicateurs, de créer des rapports et de
naviguer au sein des dimensions métier des données. Jusqu'à présent, aucune entreprise
ne se lançait directement dans un projet décisionnel d'envergure en s'appuyant
entièrement sur des outils open source.
Le risque technique était trop important, et, malgré leur coût de licence élevé, les outils
propriétaires satisfaisaient souvent les utilisateurs en termes de couverture fonctionnelle,
de stabilité et de performances. Sabre n'a donc remplacé Teradata par MySQL que pour
une partie seulement de son entrepôt de données. L'entreprise continue à utiliser des
outils de restitution propriétaires, « parfaitement adaptés à nos besoins », explique
Michael Benzinger.
De son côté, Swissport utilise Hyperion comme outil de restitution sur l'un de ses projets
et MySQL pour stocker les données. L'entrepôt est alimenté par une moulinette Java
« bientôt remplacée par l'ETL open source de Talend », explique Uwe Geercken. Bien
qu'ils soient faciles à mixer avec des outils propriétaires, les outils open source possèdent
quelques particularités à prendre en compte.
« Ils intègrent moins d'assistants, mais de plus en plus de démonstrations complètes à
partir desquelles on peut démarrer son projet, note Jean-Michel Bras. Ces outils offrent
des perspectives nouvelles, notamment dans le prototypage rapide des bases de
données », ajoute-t-il. Un point de vue partagé par le SGAR. « Il facilite le prototypage
tant au niveau des données que de l'interface utilisateur », confirme Philippe Ourliac.

Que le projet soit propriétaire, open source ou mixte, sa mise en oeuvre répond aux
mêmes étapes : « Définition des besoins fonctionnels, création du datamart [modèle en
étoile, NDLR], alimentation via un ETL, restitution des informations et indicateurs au sein
des interfaces choisies en fonction des utilisateurs, en accès statique et dynamique »,
énumère Jean-Michel Bras, d'Aexxdis.
Et le pragmatisme est de rigueur en termes d'architecture. « Notre ETL transfère les
données de la base de production [Oracle, NDLR], la nuit dans notre entrepôt de données
[MySQL, NDLR], car nous n'avons, pour l'instant, qu'un seul fuseau horaire à gérer »,
illustre Frédéric Jourden, de Xinek.
Les ressources nécessaires : faire appel à un spécialiste
Mis à part Swissport et Sabre qui possèdent un service informatique important, toutes les
PME font appel à un ou plusieurs prestataires. Le SGAR s'est appuyé sur Altic qui possède
à la fois des compétences en décisionnel (modélisation en étoile, etc.), et maîtrise les
outils open source associés. Même démarche pour Xinek qui a fait appel à Smile. Aexxdis
est passé par deux prestataires : Carra Consulting pour la maîtrise d'oeuvre et la
conception du projet, et Code Lutin pour sa réalisation.
« Nous voulions aller vite. Or, on ne s'improvise pas expert en décisionnel open source »,
résume Jean-Michel Bras, d'Aexxdis. Son projet s'est déroulé au forfait pour éviter toute
surprise budgétaire. « Nous n'avons eu qu'à budgéter l'application et participer aux
derniers réglages. Une solution efficace, confortable, avec des coûts maîtrisés », estimet-
il.
Aujourd'hui, pour cette entreprise, une journée/homme par mois suffit pour la
maintenance technique et applicative. Elle dispose, en revanche, de bonnes compétences
Java/JavaEE en interne, base de tous les outils décisionnels open source. « Le plus
difficile dans un projet décisionnel, c'est de modéliser la structure de données de
l'entrepôt », explique Frédéric Jourden, de Xinek.
C'est en effet à ce niveau que les choix métier les plus importants ont lieu : quelles
données de production conserver ou non ? Quels axes métier retenir pour le modèle en
étoile ? Etc. Autant de questions qui nécessitent de monopoliser des ressources en
interne. C'est pourquoi, de plus en plus de prestataires et d'entreprises privilégient un
mode itératif. « Notre projet a débuté fin 2005 et se poursuit toujours », illustre Jean-
Michel Bras.
Quant au budget, il est essentiellement constitué des coûts de conseil, de réalisation et
de production. Il est très variable selon les projets. Le projet de Xinek a, par exemple,
nécessité 100 jours/homme au total (50 000 euros) pour créer trois cubes et dix-neuf
rapports statiques sous Pentaho et MySQL.
Les Ecueils : l'engagement des utilisateurs
Globalement, les entreprises rencontrent peu de problèmes techniques lors de la mise en
oeuvre des projets. En revanche, les prestataires open source spécialistes du décisionnel
et les spécialistes du décisionnel utilisant des outils open source sont encore rares.
Heureusement, les logiciels se démocratisent vite. A l'image d'Anaska, plusieurs
organismes proposent déjà des programmes de formation, sur l'ETL open source de
Talend par exemple.
De toute façon, « les principaux écueils ne sont pas techniques, mais humains :
nouveauté pour les utilisateurs, compréhension des concepts de l'informatique décisionnelle, mise au point d'indicateurs métier pertinents, etc. », rappelle Philippe
Ourliac. « La personnalisation d'une solution open source demande un certain
engagement que les utilisateurs ne sont plus forcément prêts à faire. Ils ont pris de
mauvaises habitudes avec des solutions déjà packagées », complète-t-il.