http://blog.atolcd.com/?tag=pentaho-openflashchart-traduction

Dans le cadre d’un projet Pentaho pour un client du secteur médical, nous avons étendu et amélioré certaines fonctionnalités de base de la plate-forme, notamment en ce qui concerne la partie restitution Web.

Traduction française de la plate-forme
Atol CD a entièrement effectué la traduction de la plate-forme Pentaho 1.7 GA PCI (Pre-configured Installation).
L’ensemble des fichiers de traduction sont disponibles sur GoogleCode à cette adresse :
http://code.google.com/p/pentaho-french-translation

Un zip complet des fichiers traduits est téléchargeable dans l’onglet “Download”.

Merci à Sébastien, Nicolas et Bénédicte pour leur contribution…

Amélioration du rendu des Tableaux de bord
Depuis que nous mettons en place des dashboards et des rapports sur des projets BI avec Pentaho, nous avons souvent été frustrés par l’aspect graphique rudimentaire et “old school” proposé par JFree.

Bien heureusement, Pentaho est dans le domaine de l’Open Source, par définition on peut alors assez facilement se proposer d’enrichir l’outil.

C’est donc ce que nous avons décidé de faire en créant une nouvelle couche de restitution plus vivante et conviviale à l’aide d’un projet de rendu graphique Open Source: Open Flash Chart.
Développement d’une couche de restitution web avec Open Flash Chart :
Puisque Pentaho est une plate-forme OSBI plutôt bien conçue, il est plutôt simple d’y ajouter un composant personnalisé (un “plugin” en quelque sorte…).

Ainsi, les graphiques OpenFlashChart que nous avons mis en place s’appellent de la même manière que les graphiques JFreeChart :
Un fichier xaction pour ramener les données
Un fichier xml pour décrire le graphique (le “widget”)
Une page jsp pour l’affichage du graphique
Une nouvelle classe java “OpenFlashChartHelper” a été développée afin que les données fournies par l’xaction puissent être chargées dans les graphes en Flash.

Le code de la page JSP ressemble à ceci :

%
SimpleParameterProvider parameters = new SimpleParameterProvider();
parameters.setParameter( "drill-url", "SibDashboardFlash?gir={gir}" );
parameters.setParameter( "inner-param", "gir");
parameters.setParameter( "image-width", "500");
parameters.setParameter( "image-height", "350");
StringBuffer content = new StringBuffer();
ArrayList messages = new ArrayList();
OpenFlashChartHelper.doFlashChart( "samples", "formation",
"synthese_gir.widgetFlash.xml", parameters,
content, userSession, messages, null, 1 );
%>




La seule chose qui change par rapport au code standard de Pentaho appelant JFreeChart est la méthode d’appel. Ainsi, l’objet et la méthode appelante est OpenFlashChartHelper.doFlashChart().

Les attributs de cette méthode sont les mêmes que pour le code de JfreeChart, à part qu’un nouvel attribut a été ajouté : il s’agit du numéro de graphe dans la page ( il est utilisé seulement pour différencier les appels à la bibliothèques Flash )

Le widget xml ressemble à ceci :



samples
formation
synthese_gir_data.xaction
rule_result
gir
nb_patients
columns


1
500
400

Nombre de patients par code GIR
{font-size: 20px; color:#736AFF}

#C548D1


pie

#d01f3c
#356aa0
#C79810
#65a111
#f121f1

50
2
0
45
GIR=%23x_label%23<br>%23val%23
true
#0000d0
0
0

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.

Bonjour ,
alors pour ne pas perdre de temps on a que 2 min ;)

1-telecharger :
* pentaho_j2ee_deployments-1.7.1.zip
* pentaho_solutions-1.7.1.zip
* Pentaho MySql .sql Sample Script
* MySql connector JAVA 5.1.6 -
* Tomcat
* ant

2-
s'assurer que vous avez configurer PATH,JAVA_HOME,CATALINA_HOME,JRE_HOME
3-
creer la base de donnée (Pentaho MySql .sql Sample Script pour les exemple de PENTAHO)

s'assurer avec cet exemple que vous avez 3 base de donnée exemple
4-
aller dans Pentaho_deploymenet (cd pentaho_j2ee_deployments)

saisir les commandes $terminal> ant zip-pentaho-style-war
> ant zip-pentaho-steel-wheels-style-war
> ant zip-pentaho-portal-layout-war
> ant war-pentaho-tomcat-mysql
après
> cp build/pentaho-wars/*.war /opt/apache-tomcat-5.5.26/webapps/
l> cp build/pentaho-wars/tomcat/mysql/*.war /opt/apache-tomcat-5.5.26/webapps/

(cp= copier les fichier)

5-
remarquer la création des répertoire après redémarage de Tomcat
1. pentaho/
2. sw-style/
3. pentaho-portal-layout/
4. pentaho-style/

6-
copier pentaho-solution dans le repertoir de Tomcat
7-
aller dans /apache-tomcat-5.5.26/webapps/pentaho/WEB-INF

ajouter
solution-path
/opt/pentaho/pentaho-solutions


base-url
http://localhost:8080/pentaho/


dans le ficher web.xml

8-
aller dans apache-tomcat-5.5.26/conf/

ajouter dans le ficher server.xml avant le code suivant




















avec :
1. "myserver" t= "localhost"

9-
aller dans apache-tomcat-5.5.26/webapps/pentaho/WEB-INF/classes/
et changer dans le fichier hibernate.cfg.xml

par le code :
com.mysql.jdbc.Driver
jdbc:mysql://myserver:3306/hibernate
org.pentaho.repository.MySQL5InnoDBDialect
hibuser
password
10
false
true
10-
redemarer TOMCAT et lancer Pentaho solution avec http://localhost:8080/pentaho

---------------------------------------------------

voila en 2 min (bah presque 2:p)

ok a+

Comme moi d'ailleurs c'est l'un des obstacle et le source de probleme (Pffffffffffff)
oui c'est la connexion à ma base de donnée ci dessous des définition utile et quelques exemple de chaîne de connexion

Si vous n'utilisez pas le système DSN (Data Source Name) pour se connecter à une base de données, une chaîne de connexion doit être passée à l'objet ADO (ActiveX Data Objects). Cette méthode est dit "DSN-Less". Il existe des centaines de chaînes de connexion selon le serveur de base de données utilisé. Ce tutoriel explique les principaux paramètres de cette chaîne de connexion ainsi que quelques exemples courants.


Noter qu'une base de données qui utilise ce type de connexion devrait toujours être déposée sur le serveur SOUS la racine Web pour éviter d'être disponible en téléchargement. Et que la base de données doit permettre la lecture, l'écriture, l'exécution et la suppression (RWXD). Que se soit ASP ou ASP.NET, les chaînes de connexion sont les mêmes...

Paramètres courants d'une chaîne de connexion

**Provider ou Driver
Le serveur de la base de données
ex: MICROSOFT.JET.OLEDB.4.0;
**Data Source
Le nom de votre base et son chemin d'accès (path)
ex: D:inetpubdbbase.mdb;
**User ID
Votre non d'usager (s'il y a lieu)
ex: User ID=usager;
**Password
Votre mot passe (s'il y a lieu)
Password=motpasse;
Il existe beaucoup d'autres paramètres, voir les liens en bas de la page "Autres documents".


----------------------------------------------------------------------------------------------------------

Exemple concrèt et Driver ODBC vs Provider OLE BD
Personnellement, j'utilise une chaîne de connexion OLE DB qui remplace l'ancien ODBC. ODBC est plus répandu mais OLE DB est reconnu pour être plus rapide alors aucune question ne se pose, utilisez OLE DB. La technique est toujours la même, vous devez construire la chaîne et la passer à l'objet ADO:





Chaîne de connexion OLE DB typique (recommandé)

--SQL Server:
provider=SQLOLEDB.1;DataSource=CheminMonServeur;Initial Catalog=MaBaseDeDonnées;User ID=nonDusager;Password=motDePasse;
--ACCESS:
provider=MICROSOFT.JET.OLEDB.4.0;DataSource=D:inetpubdbbase.mdb;User ID=nonDusager;Password=motDePasse;
--Oracle:
provider=OraOLEDB.Oracle;DataSource=D:inetpubdbBaseOracle;User ID=nonDusager;Password=motDePasse;
--Oracle (Microsoft):
provider=msdaora;DataSource=D:inetpubdbBaseOracle;User ID=nonDusager;Password=motDePasse;
--DB2:
provider=DB2OLEDB;Network Transport Library=TCPIP;Network Address=CheminMonServeur;Package Collection=monPackage;Host CCSID=1142;Initial Catalog=BaseDB2;User ID=nonDusager;Password=motDePasse;"
Chaîne de connexion ODBC typique (non recommandé)

--SQL Server:
DRIVER={SQL Server};server=CheminMonServeur;uid=nonDusager;pwd=motDePasse;database=baseDeDonnees;
--ACCESS:
DRIVER={Microsoft Access Driver (*.mdb)};DBQ=D:inetpubdbbase.mdb;uid=nonDusager;pwd=motDePasse;
--Oracle:
DRIVER={Microsoft ODBC for Oracle};Server=OracleServer.world;uid=nonDusager;pwd=motDePasse;database=baseDeDonnees;
--MySQL:
DRIVER={mySQL};server=CheminMonServeur;Option=16834;Database=baseDeDonnees;
--Excel:
DRIVER={Microsoft Excel Driver (*.xls)};DriverId=790;DBQ=D:inetpubdbfichier.xls;DefaultDir=D:inetpubdb;
--Visual Fox Pro
DRIVER={Microsoft Visual FoxPro Driver};SourceType=DBF;SourceDB=D:cheminAccèsfpBase;User ID=nonDusager;Password=motDePasse;

Conclusion:

Beaucoup de chose pour une simple connexion mais souvenez vous que l'essentielle est dans cette page! Une bonne connexion "sans DSN" avec une chaîne OLE DB c'est l'idéale. Reste à trouver la bonne chaîne de connexion.


---
pour plus http://www.able-consulting.com/ado_conn.htm?f=ado_conn.htm

--

Comme moi d'ailleurs c'est l'un des obstacle et le source de probleme (Pffffffffffff)
oui c'est la connexion à ma base de donnée ci dessous des définition utile et quelques exemple de chaîne de connexion

Si vous n'utilisez pas le système DSN (Data Source Name) pour se connecter à une base de données, une chaîne de connexion doit être passée à l'objet ADO (ActiveX Data Objects). Cette méthode est dit "DSN-Less". Il existe des centaines de chaînes de connexion selon le serveur de base de données utilisé. Ce tutoriel explique les principaux paramètres de cette chaîne de connexion ainsi que quelques exemples courants.


Noter qu'une base de données qui utilise ce type de connexion devrait toujours être déposée sur le serveur SOUS la racine Web pour éviter d'être disponible en téléchargement. Et que la base de données doit permettre la lecture, l'écriture, l'exécution et la suppression (RWXD). Que se soit ASP ou ASP.NET, les chaînes de connexion sont les mêmes...

Paramètres courants d'une chaîne de connexion

**Provider ou Driver
Le serveur de la base de données
ex: MICROSOFT.JET.OLEDB.4.0;
**Data Source
Le nom de votre base et son chemin d'accès (path)
ex: D:inetpubdbbase.mdb;
**User ID
Votre non d'usager (s'il y a lieu)
ex: User ID=usager;
**Password
Votre mot passe (s'il y a lieu)
Password=motpasse;
Il existe beaucoup d'autres paramètres, voir les liens en bas de la page "Autres documents".


----------------------------------------------------------------------------------------------------------

Exemple concrèt et Driver ODBC vs Provider OLE BD
Personnellement, j'utilise une chaîne de connexion OLE DB qui remplace l'ancien ODBC. ODBC est plus répandu mais OLE DB est reconnu pour être plus rapide alors aucune question ne se pose, utilisez OLE DB. La technique est toujours la même, vous devez construire la chaîne et la passer à l'objet ADO:





Chaîne de connexion OLE DB typique (recommandé)

--SQL Server:
provider=SQLOLEDB.1;DataSource=CheminMonServeur;Initial Catalog=MaBaseDeDonnées;User ID=nonDusager;Password=motDePasse;
--ACCESS:
provider=MICROSOFT.JET.OLEDB.4.0;DataSource=D:inetpubdbbase.mdb;User ID=nonDusager;Password=motDePasse;
--Oracle:
provider=OraOLEDB.Oracle;DataSource=D:inetpubdbBaseOracle;User ID=nonDusager;Password=motDePasse;
--Oracle (Microsoft):
provider=msdaora;DataSource=D:inetpubdbBaseOracle;User ID=nonDusager;Password=motDePasse;
--DB2:
provider=DB2OLEDB;Network Transport Library=TCPIP;Network Address=CheminMonServeur;Package Collection=monPackage;Host CCSID=1142;Initial Catalog=BaseDB2;User ID=nonDusager;Password=motDePasse;"
Chaîne de connexion ODBC typique (non recommandé)

--SQL Server:
DRIVER={SQL Server};server=CheminMonServeur;uid=nonDusager;pwd=motDePasse;database=baseDeDonnees;
--ACCESS:
DRIVER={Microsoft Access Driver (*.mdb)};DBQ=D:inetpubdbbase.mdb;uid=nonDusager;pwd=motDePasse;
--Oracle:
DRIVER={Microsoft ODBC for Oracle};Server=OracleServer.world;uid=nonDusager;pwd=motDePasse;database=baseDeDonnees;
--MySQL:
DRIVER={mySQL};server=CheminMonServeur;Option=16834;Database=baseDeDonnees;
--Excel:
DRIVER={Microsoft Excel Driver (*.xls)};DriverId=790;DBQ=D:inetpubdbfichier.xls;DefaultDir=D:inetpubdb;
--Visual Fox Pro
DRIVER={Microsoft Visual FoxPro Driver};SourceType=DBF;SourceDB=D:cheminAccèsfpBase;User ID=nonDusager;Password=motDePasse;

Conclusion:

Beaucoup de chose pour une simple connexion mais souvenez vous que l'essentielle est dans cette page! Une bonne connexion "sans DSN" avec une chaîne OLE DB c'est l'idéale. Reste à trouver la bonne chaîne de connexion.


---
pour plus http://www.able-consulting.com/ado_conn.htm?f=ado_conn.htm

--

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.

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.

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.

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/
-------

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/
-------