Ce contenu traduit automatiquement peut être modifié par les membres de la communauté. Nous vous invitons à améliorer la traduction en cliquant sur le lien « Modifier » associé aux phrases ci-dessous.
Business Intelligence
Planning Your First Microsoft BI Solution
Stacia Misner
At a Glance:
-
Introduction to BI
-
Avoiding common problems with corporate databases
-
A walk through the Microsoft BI stack
-
Building a simple solution
Contents
Most database administrators (DBAs) have
encountered some form of business intelligence (BI) while managing their organization’s data and Microsoft SQL Server implementation.
Many other IT professionals, who don't have DBA responsibilities, have likely heard of BI but don't have firsthand experience with it or really even know what it is.
In this article, you'll find out what all the fuss is about.
Once you understand what BI technologies can really do and see how BI solutions are constructed on the Microsoft BI platform, you'll discover why BI isn't just for DBAs.
If you're savvy about BI, you'll be in a better position to support your organization's BI initiatives when they come up (and they will) and you'll also realize how you can use BI to track and analyze data relevant to your role, making your job easier and deepening your understanding of that data.
This article is the first in a series of articles that introduce the Microsoft BI stack.
In this initial article, I define BI and describe the high-level architecture of a BI solution in general terms.
I also provide some insight into the process of building a BI solution.
To delve into the SQL Server BI technologies mentioned in this article, you can read the companion articles written by Derek Comingore in this issue (see "Building a Data Foundation for a BI Solution") and by Scot Reagin and me in upcoming issues.
What Is BI?
Several years ago, while I was coauthoring Business Intelligence: Making Better Decisions Faster (Microsoft Press, 2002), I was surprised by how strongly my peers disagreed about which technologies should be considered within the domain of BI and thus within the scope of the book.
It was an enlightening experience to hear such divergent opinions among BI professionals about which tools they considered BI tools and which they excluded.
This difference of opinion still exists within the IT industry, and many continue to debate the definition of BI.
To me, BI is as much about business process as it is about technology, so I start defining BI from that perspective.
As a business process, BI is a series of activities you perform to gather and analyze data so that you can make better decisions and improve your business by sharing the results of your analysis with others.
Whether you need information to decide how to make your daily routine more efficient or to support long-range planning, such as next year's budget, the steps you take to find, transfer, format and study the data are all part of BI.
In addition, BI includes the processes you use to make your results available for later reference so you and others can measure the impact of the decisions you made after studying the data.
Typically, BI is an iterative process.
You analyze the data to see what has happened, you take action to ensure good things keep happening and bad things stop, and you then analyze the data at a later point to determine whether your actions made things better or worse and whether external factors helped or hindered your efforts.
Given this broad definition of BI, you're using BI even when you're jotting down bits of information or creating lists to help you make decisions throughout the day.
Introducing technology into some or all of the business processes you use to gather, analyze and share information can make these processes more efficient.
Organizations tend to start small when adopting BI technology, often using it at first to solve specific problems.
Over time, the use of BI technology grows incrementally as the emphasis shifts to disseminating information efficiently across the organization.
As its BI strategy continues to mature, the organization usually acquires more sophisticated tools to enable greater interaction with and exploration of data.
What's Wrong with Querying Your Corporate Databases?
In any definition of BI, data is always the focal point.
You might be wondering why you need to bother to create a BI solution when you can simply query one or more of your organization's databases to get the data you need.
If you're the sole consumer of the data that you're gathering, if you have the tools, skills and security privileges to access the corporate databases, and if all the data you need is in those sources, you probably don't need a formal BI solution.
By contrast, if you regularly need to share information with others whose technical skills and security privileges vary, you need to create a BI solution that is simple to use and maintain.
You also need to consider that once your colleagues hear about this neat BI solution, they'll want to use it too.
To anticipate this demand, your solution should be scalable from the beginning.
On the surface, allowing everyone in the company to run reports to get data from the corporate databases might seem like a good idea, but this approach probably won't be very popular with the DBAs.
As they will tell you, querying the corporate databases directly can come with more than a few problems.
Here are a few of the more common ones:
-
If the organization's data is stored in different platforms in different formats, consolidating the data into a common format that is useful for analysis can be challenging.
Data can't be copied directly from source tables into a common target table but will have to be manipulated in some way before it's stored.
-
Data definitions might not be consistent across multiple databases, and reconciling data that appears to be similar can be difficult.
For example, the revenue in a sales database might be calculated according to one set of business rules but be subject to an entirely different set of business rules in a general ledger database.
-
Each database is probably structured and optimized for inserting data or for performing lookups.
Even if you want to query just one database, running analytical queries usually requires the summarization of large quantities of data, which is an expensive operation in terms of database resources.
Consequently, your queries can take a long time to execute and can create contention for resources with other applications performing insert, update or lookup operations.
-
Historical data is often archived rather than maintained indefinitely in a corporate database.
If you want to look at trends over time—a common BI activity—your solution might need to be a repository for data that doesn't persist in the corporate database.
-
Some data required for analysis might not be available in the corporate database.
It might be in flat files, spreadsheets, or unstructured data formats like Microsoft Word documents.
More problematic is getting to the information people have stored on their local machine—or in their head.
-
Even if data is available, quality issues sometimes mean you can't use it directly from the source.
You might need to download the data and clean it up before you can analyze it.
Unless the data can be cleaned within the source, you'll need to cleanse the data manually each time you access it—making sure you apply the same rules every time.
Furthermore, you can't be sure that everyone else using the same data is following the same rules for cleaning it.
To address these problems with data access, a BI solution often includes a database created exclusively to house the data used for analysis.
Having such a database means you can avoid any resource contention problems between activities generating data and activities consuming that data.
Going a step further, you can restructure the data so that queries summarizing data can run much faster.
When you need to consolidate data from multiple data sources, you can centralize it and apply business logic to put the data into a common format with consistent meaning.
You can also incorporate data that didn't come from a database, such as an XML document or a spreadsheet, into this central location.
Another benefit of creating a separate database is that you can preserve historical data for as long as necessary after that data is purged from the source databases.
Finally, you can automate the process of cleansing and enhancing the data for analysis, ensuring that the same rules are applied each time the data is accessed.
Support for Decision Making
A BI solution should do more than give you better access to data.
It should specifically support your decision-making efforts.
In general, a BI solution should help you assess and respond to business conditions, whether you require an all-encompassing view of the entire organization or a narrow perspective of a department, workgroup, or even a team of one.
In fact, the ability to move quickly from a summarized view to a detailed view of data is an important capability in BI.
The goal of a BI solution is to let you spend your time analyzing the data and finding answers to questions rather than tracking down, consolidating, reformatting and reconciling the data itself.
When you have enough quality time to analyze the data, you can usually spot problems early and take steps to stop negative trends from continuing.
You can also use BI to discover correlations between seemingly unrelated data points and then adapt your strategies to turn your insights into dollars saved or dollars earned.
Every decision you make each day as you do your job, whether you're solving a problem or planning for the future, translates directly or indirectly into a cost or a profit for your company.
BI in Action
Understanding BI on a theoretical level is good, but seeing it in action really helps you understand its benefits.
To show you how BI works, the three other articles in this series describe the development of a BI solution for a fictional company called Adventure Works.
At the end of this article, I'll explain how to obtain the sample database for Adventure Works, which is a fictional bicycle manufacturer that sells its products worldwide.
It maintains a sales staff to sell its products wholesale to resellers such as small specialty bicycle shops or large warehouse-style shopping outlets.
Adventure Works also sells products directly to individual customers through the Internet.
The Adventure Works data provides lots of analysis opportunities that fit well into a BI solution.
Remember that a BI solution is intended to support decision making.
With this in mind, let's consider the types of questions that Adventure Works needs to answer before making key decisions:
-
Which sales channel is more profitable?
Adventure Works must decide whether to invest in adding more sales staff to develop relationships with more resellers or to expand its Internet sales presence.
To help guide this decision, analysts need the ability to compare the sales performance over time between resellers and its Internet site.
The sales performance data points (called measures) that analysts need to compare include sales dollars, order quantity and profitability.
A positive trend in profitability is the most important measure because high sales measured in dollars or number of units sold don't benefit the company if these sales result in a net loss.
-
Is demand for certain products growing or declining?
Adventure Works must match production levels to sales demand.
If demand for some products is growing, Adventure Works must adjust its manufacturing processes to ensure more of these products are available for sale and thus increase sales.
If demand for other products is declining, Adventure Works needs to reduce their production or possibly eliminate product lines to avoid an oversupply situation in which these products must be sold at a loss.
Even if you don't analyze sales data in your job, I encourage you to follow along as we build a BI solution for Adventure Works.
You can apply the same design and development principles described in this series to your own data.
The Microsoft BI Stack
Now let's take a closer look at the technology architecture of BI.
The Microsoft BI stack provides all the tools you need to build, manage and use a BI solution.
SQL Server 2008 is the foundation of the stack as the data platform hosting the data mart or data warehouse.
A data mart is a subject-specific data store.
A data warehouse is an enterprise-wide collection of data containing multiple subjects.
The line between data marts and data warehouses is blurry, but you don't need to worry about the distinctions.
In this series, I use the term data mart.
(Although this series of articles refers specifically to SQL Server 2008, you can also build a similar BI solution by using SQL Server 2005 and its BI components with little or no modification of the instructions provided.)
SQL Server 2008 includes three BI components: Integration Services (SSIS), Analysis Services (SSAS), and Reporting Services (SSRS).
These components extend the data platform with data integration functionality, multidimensional database support and a data presentation layer, respectively.
Figure 1 illustrates the relationship of these components to one another in a BI solution.
.gif)
Figure 1 SQL Server 2008 Components in a BI Solution
After you design the physical structures of your data mart, you use SSIS to populate it with the data you extract from other data sources.
SSIS provides the tools necessary to automate the processes for cleansing data, consolidating data from multiple sources and transforming the data into a structure well suited for analysis.
You can schedule the periodic execution of these processes using SQL Server Agent.
In his article on SSIS on p.
31, Derek Comingore explains how to develop extract, transform and load (ETL) processes for a BI solution.
Adding an SSAS database to your BI solution allows you to support more sophisticated, high-performing interactive queries.
You use SSAS to copy your relational data into a multidimensional database structure called a cube.
A well-designed cube optimizes data for ad hoc queries by adding indexes and the functional equivalent of summary tables (known as aggregations) to return query results that can be exponentially faster than a comparable query to a relational database.
You can also embed complex calculation logic in the cube to simplify queries that would otherwise require hundreds of lines of Transact-SQL code to replicate when using a relational data source.
Many front-end tools (called cube browsers) let you query a cube without writing a single line of code.
In next month's issue, Scot Reagin will show you how to develop a cube as part of a BI solution.
Whether you're storing your data in a SQL Server data mart or an SSAS cube, you can add SSRS to your solution architecture to make the data available to users.
SSRS is a reporting platform that includes tools to develop reports, to secure and manage published reports using a centralized administrative infrastructure and to support user access to reports.
You can use an SSRS Web application or Microsoft Office SharePoint Server 2007 (MOSS) to view reports, use the subscription feature to receive reports via e-mail, or call the SSRS Web service in your own application to display your reports.
The default view of a report displays in HTML format, but you can also export a report to other file types, such as PDF or Excel.
Next month, I'll explain more about using SSRS in the data presentation layer of your BI solution.
The Microsoft BI stack also includes several Microsoft Office technologies that expand your options for the data presentation layer.
Excel 2007 is a popular choice for supporting data analysis in BI solutions.
You can access your SQL Server data mart or browse an SSAS cube directly from Excel (as shown in Figure 2) and explore data much more freely than you can when viewing an SSRS report.
.gif)
Figure 2 Using Excel 2007 to Browse a Cube
In addition to using Excel to explore both relational and multidimensional data, you can use its data mining algorithms to uncover hidden patterns of information in your data or to detect anomalies in the data (which means you can fix problems before populating your data mart).
A great way to get started with data mining is to download a free add-in for Excel from Microsoft and then use it to analyze data that you import into Excel from any source or to view the output of a data mining model created and stored on the SSAS server.
An add-in for Visio 2007 is also available for sharing annotated data mining models.
You can learn more about downloading and using these add-ins at "Data Mining Add-Ins for Office 2007."
An increasingly popular choice for sharing data is Excel Services, which is available in MOSS.
Using Excel 2007, you first create a workbook containing a pivot table that uses an SSAS cube as its data source and you then publish the data connection and your workbook to Excel Services.
Although you can publish workbooks that contain data from other types of data sources, one of the advantages of using SSAS, pivot tables and Excel Services together is the ability to use much of the same cube browsing functionality within a pure HTML interface that preserves the familiarity of Excel.
Another advantage is the ability to centralize the administration and access of Excel workbooks.
For more information about Excel Services, refer to "Excel Services Technical Overview."
Yet another advantage of using Excel Services for cube browsing is that you can embed pivot tables and pivot charts into a MOSS dashboard page using the Excel Web Access Web Part.
A dashboard is a special SharePoint content type that allows you to present data from multiple sources on a single page using a variety of Web Parts.
You can even add a filter to the dashboard page and connect it to all or some of the Web Parts to dynamically change the content on the page based on the filter selection.
Figure 3 shows a sample MOSS dashboard.
MOSS also includes a Web Part to display SSRS reports that are stored on the MOSS server (an optional SSRS configuration known as integrated mode), or you can use Web Parts that ship with SSRS to display reports stored on the report server (the default configuration known as native mode).
.gif)
Figure 3 Using a MOSS Dashboard Page to Display Workbooks and Reports
For dashboards with even more functionality, you can use Microsoft Office PerformancePoint Server 2007 (PPS).
You use PPS to develop scorecards and dashboards that you can deploy to MOSS.
A scorecard is a report that compares actual performance to a defined target and shows the results using color-coded icons.
You can display a PPS scorecard using a special type of Web Part in a standard MOSS dashboard or as part of a PPS dashboard.
In the dashboard, you can add PPS reports to dashboard zones to present different views of the same data (as shown in Figure 4) or to show related data from different sources.
.gif)
Figure 4 Using a PPS Dashboard to Display Data
As you can see, the Microsoft BI stack provides numerous options for the development, administration and implementation of your BI solution, but it by no means prevents you from using other options.
The Microsoft BI stack from top to bottom is an extensible architecture into which you can plug your own custom applications or third-party applications when you need to support specific requirements.
An Approach to Solution Development
The best way to start learning about the Microsoft BI stack is to build a simple solution.
The companion articles in this series show you how to build a solution by using SSIS, SSAS and SSRS.
When you've finished the series, you'll have a general idea of how each of these components works.
Don't feel compelled, however, to use each component in the stack for every BI solution you build.
As you put together your BI solution, plan to spend most of your time performing data preparation tasks, such as restructuring and cleansing.
In BI terms, this set of tasks is called the extract, transform and load (ETL) process.
Before you start ETL development, you must carefully plan the design of your BI solution.
In my experience, the development of a BI solution goes more smoothly when you have a specific business problem to solve and approach the design by first considering how people need to interact with information.
By taking a user-centric approach, you can work your way backward through the applicable business processes to design a solution that properly retrieves and structures the data to support your business need.
This recommendation might seem to be an obvious approach, but I've seen many people attempt to drive the solution development from the data available out to the users and wind up with a solution that never gets used.
After you come up with the initial design, you're ready to start developing.
If your BI solution uses SSIS, SSAS and SSRS, you begin by creating and populating the BI solution's data structures using SSIS.
Once the data is in place, you continue to the next step by building a cube.
After your development is complete, you process the cube to load it with data.
You then use SSRS to develop a report that queries the cube and displays the query results in a report.
You'll see how to step through this process over the next three articles in this series.
For your own projects, you should approach this process incrementally and iteratively to make sure the results of one step work satisfactorily in subsequent steps.
Getting Started
To complete the entire BI solution described in the remaining articles in this series, you need to install SQL Server 2008, including SSIS, SSAS and SSRS.
If you have access to SQL Server, an SSAS server and a report server on your network, you need only install the development tools on your computer.
For product installation instructions, see "How to: Install SQL Server 2008 (Setup)
." You can download the sample databases used to build the solution for Adventure Works from CodePlex. The first database, AdventureWorks2008, is representative of an online transactional processing (OLTP) database, which captures the transactions generated by business operations in the sales, production and human resources departments.
You'll use this database as a source for the data mart that you build using SSIS.
The second database, AdventureWorksDW2008, is a sample of data representing best practices in data warehouse design.
You can use this database as a source for your SSAS cube if you decide to skip learning about SSIS and jump directly into cube development.
Next Steps
After you get familiar with the SQL Server BI components, you should find a simple project of your own to continue building your knowledge.
You don't need a full-fledged data mart to get started, but you should try to structure your data using the principles described in the next article in this series.
Once you start using BI, you'll probably never look at data quite the same way again.
Stacia Misner is a BI consultant, educator and author, as well as the founder and principal of Data Inspirations.
She has 25 years of experience in the IT industry, with nine years focused on the Microsoft BI stack.
Stacia has written several books about BI and SQL Server.
Her latest book, Microsoft SQL Server 2008 Reporting Services Step by Step (Microsoft Press, 2009), was released earlier this year.
She can be reached at smisner@datainspirations.com.
|
Décisionnel
Planification de votre première solution de décisionnel Microsoft
Stacia Misner
Vue d'ensemble :
-
Introduction au décisionnel
-
Éviter les problèmes courants relatifs aux bases de données d'entreprise
-
Une présentation de la pile Microsoft BI
-
Création d'une solution simple
Sommaire
La plupart des administrateurs de base de données (DBA) sont confrontés à une forme de décisionnel lors de la gestion des données de leur organisation et de l'implémentation de Microsoft SQL Server.
De nombreux autres professionnels de l'informatique, qui n'ont pas une responsabilité de DBA, ont probablement entendu parler du décisionnel mais ne l'ont jamais abordé personnellement ou ne savent même pas ce que c'est vraiment.
Dans cet article, vous découvrirez de quoi il s'agit.
Lorsque vous saurez ce que les technologies de décisionnel peuvent vraiment faire et comment les solutions de décisionnel sont construites sur la plate-forme Microsoft BI, vous découvrirez pourquoi le décisionnel n'est pas uniquement destiné aux DBA.
Si vous connaissez bien le décisionnel, vous serez en meilleure position pour soutenir les initiatives de votre organisation en la matière lorsqu'elles se présenteront (ce qui est certain) et vous saurez également comment l'utiliser pour suivre et analyser les données en rapport avec votre rôle, faciliter votre travail et parfaire votre compréhension de ces données.
Cet article est le premier d'une série qui présentent la pile Microsoft BI.
Dans ce premier article, je définis le décisionnel et décris l'architecture générale d'une solution de décisionnel en termes généraux.
Je fournis également quelques aperçus du processus de création d'une solution de décisionnel.
Pour examiner les technologies de SQL Server BI mentionnées dans cet article, vous pouvez lire les articles associés rédigés par Derek Comingore dans ce numéro (voir « Création d'une fondation de données pour une solution de décisionnel ») et par Scot Reagin et moi-même dans les prochains numéros.
Qu'est-ce que le décisionnel ?
Il y a plusieurs années, alors que j'étais co-auteur du livre Décisionnel : prendre de meilleures décisions, plus rapidement (Microsoft Press, 2002), j'ai été surprise de constater à quel point mes collègues n'étaient pas d'accord sur les technologies à considérer comme faisant partie du décisionnel et donc à inclure dans le livre.
Ce fut une expérience enrichissante d'écouter les opinions divergentes des professionnels du décisionnel sur les outils à considérer comme outils de décisionnel et ceux à écarter.
Cette différence d'opinion existe toujours en informatique et beaucoup continuent à débattre de la définition du décisionnel.
Pour moi, le décisionnel est autant affaire de processus métier que de technologie, c'est pourquoi ma définition du décisionnel commence sous cet angle.
En tant que processus métier, le décisionnel est une série d'activités qui vous permettent de rassembler et d'analyser des données en vue de prendre de meilleures décisions et d'améliorer votre activité en partageant les résultats de votre analyse avec d'autres utilisateurs.
Si vous avez besoin d'informations pour décider des moyens de rendre vos activités quotidiennes plus efficaces ou pour soutenir une planification à long terme, comme le budget de l'année suivante, les étapes que vous allez suivre pour rechercher, transférer, mettre en forme et étudier les données font toutes partie du décisionnel.
En outre, le décisionnel comprend les processus que vous appliquez pour rendre vos résultats disponibles pour référence ultérieure, afin que vous et d'autres personnes puissent mesurer l'impact des décisions qui ont été prises après examen des données.
En général, le décisionnel est un processus itératif.
Vous analysez les données pour voir ce qui s'est passé, vous prenez des mesures pour que les aspects positifs se poursuivent et que les aspects négatifs disparaissent, puis vous analysez les données ultérieurement pour déterminer si vos actions ont amélioré la situation ou l'ont fait empirer et si des facteurs externes ont favorisé ou entravé vos efforts.
Étant donné cette définition large du décisionnel, vous vous servez de cet outil même lorsque vous prenez en note des bribes d'informations ou que vous créez des listes pour vous aider à prendre des décisions pendant la journée.
Introduire une technologie dans tout ou partie des processus métier dont vous vous servez pour rassembler, analyser et partager des informations peut améliorer l'efficacité de ces processus.
Les organisations ont tendance à démarrer modestement lorsqu'elles adoptent une technologie de décisionnel, en l'utilisant souvent dans un premier temps pour résoudre des problèmes spécifiques.
L'utilisation des technologies du décisionnel augmente progressivement à mesure que l'accent est mis de plus en plus sur la diffusion efficace d'informations au sein de l'organisation.
Alors que sa stratégie de décisionnel continue d'évoluer, l'organisation acquiert généralement des outils plus sophistiqués pour permettre une plus grande interaction avec les données et améliorer leur exploration.
À quel problème êtes-vous confronté pour interroger vos bases de données d'entreprise ?
Dans toute définition du décisionnel, les données sont toujours le point central.
Vous devez vous demander pourquoi prendre la peine de créer une solution de décisionnel, alors que vous pouvez simplement interroger une ou plusieurs bases de données de votre organisation pour obtenir les données dont vous avez besoin.
Si vous êtes le seul utilisateur des données que vous rassemblez, si vous disposez des outils, des compétences et des privilèges de sécurité pour accéder aux bases de données de l'entreprise, et si toutes les données nécessaires figurent dans ces sources, vous n'avez sans doute pas besoin d'une solution formelle de décisionnel.
En revanche, si vous avez besoin de partager régulièrement ces informations avec d'autres personnes aux compétences techniques et aux privilèges de sécurité divers, vous avez besoin de créer une solution de décisionnel simple à utiliser et à gérer.
Vous devez également considérer que lorsque vos collègues seront informés de l'existence de cette solution de décisionnel simple, ils souhaiteront l'utiliser eux aussi.
Pour anticiper cette demande, votre solution doit être évolutive dès le début.
À première vue, autoriser tout le monde dans l'entreprise à produire des rapports pour obtenir des données à partir des bases de données de l'entreprise peut sembler une bonne idée, mais cette approche risque de ne pas être très appréciée des DBA.
Comme ils vous le signaleront, interroger directement des bases de données d'entreprise peut entraîner plus d'un problème.
Voici quelques exemples parmi les plus courants :
-
Si les données de l'organisation sont stockées sur différentes plates-formes et sous différents formats, consolider les données dans un format commun, utile à l'analyse, peut être difficile.
Les données ne peuvent pas être copiées directement à partir de tables sources dans une table cible commune ; elles devront être manipulées avant d'être stockées.
-
Les définitions de données risquent de ne pas être cohérentes d'une base de données à l'autre et rapprocher des données qui semblent similaires peut être difficile.
Par exemple, le chiffre d'affaire dans une base de données de ventes peut être calculé en fonction d'un ensemble de règles métier, mais être soumis à un ensemble de règles métier totalement différentes dans une base de données de comptabilité générale.
-
Chaque base de données est probablement structurée et optimisée pour insérer des données ou pour effectuer des recherches.
Même si vous souhaitez n'interroger qu'une seule base de données, exécuter des requêtes d'analyse nécessite habituellement de résumer de grandes quantités de données, ce qui représente une opération onéreuse en termes de ressources de base de données.
Par conséquent, vos requêtes peuvent mettre du temps à s'exécuter et créer une compétition au niveau des ressources avec d'autres applications qui effectuent des opérations d'insertion, de mise à jour ou de recherche.
-
Les données historiques sont souvent archivées plutôt que conservées indéfiniment dans une base de données d'entreprise.
Si vous souhaitez examiner les tendances dans le temps (une activité de décisionnel courante), votre solution devra peut-être servir de référentiel pour les données qui ne restent pas dans la base de données de l'entreprise.
-
Certaines données requises pour l'analyse risquent de ne pas être disponibles dans la base de données de l'entreprise.
Il peut s'agir de fichiers plats, des feuilles de calcul ou de formats de données non structurées, tels que les documents Microsoft Word.
Plus problématique est l'obtention des informations que les personnes ont stockées sur leur machine locale (ou dans leur tête).
-
Même si les données sont disponibles, des problèmes de qualité parfois ne permettent pas de les utiliser directement à partir de la source.
Vous devrez peut-être télécharger les données et les nettoyer avant de pouvoir les analyser.
À moins que les données puissent être nettoyées dans la source, vous devrez peut-être les nettoyer manuellement chaque fois que vous y accédez, en veillant à appliquer les mêmes règles à chaque fois.
En outre, vous ne pouvez pas être certain que tout ceux qui utilisent les mêmes données suivent les mêmes règles de nettoyage.
Pour résoudre ces problèmes d'accès aux données, une solution de décisionnel comprend souvent une base de données créée exclusivement pour héberger les données utilisées pour l'analyse.
Disposer d'une telle base de données signifie que vous pouvez éviter tout problème de compétition pour les ressources entre les activités générant des données et les activités les consommant.
Vous pouvez aller plus loin et restructurer les données afin que les requêtes qui les résument puissent s'exécuter beaucoup plus rapidement.
Lorsque vous devez consolider les données à partir de plusieurs sources, vous pouvez les centraliser et appliquer une logique métier pour les mettre dans un format commun avec une signification cohérente.
Vous pouvez également incorporer des données non issues d'une base de données, comme un document XML ou une feuille de calcul, dans cet emplacement central.
Un autre avantage offert par la création d'une base de données distincte est que vous pouvez conserver les données historiques aussi longtemps que nécessaire une fois qu'elles ont été purgées de la bases de données source.
Enfin, vous pouvez automatiser le processus de nettoyage et améliorer les données à analyser, ce qui garantit que des règles identiques seront appliquées à chaque accès aux données.
Aide à la décision
Une solution de décisionnel doit faire mieux que simplement donner un meilleur accès aux données.
Elle doit surtout vous aider à prendre des décisions.
En général, une solution de décisionnel doit vous aider à évaluer la situation de l'entreprise et à y réagir, que vous ayez besoin d'une vision globale de l'organisation entière ou d'une perspective fine sur un département, un groupe de travail ou même une équipe d'une seule personne.
En fait, la possibilité de passer rapidement d'une vue résumée à une vue détaillée des données est une fonctionnalité importante dans le décisionnel.
L'objectif d'une solution de décisionnel est de vous permettre de vous consacrer à l'analyse des données et à trouver des réponses aux questions, plutôt qu'à rechercher, consolider, reformater et rapprocher les données elles-mêmes.
Lorsque vous pouvez consacrer assez de temps utile à l'analyse des données, vous pouvez généralement repérer les problèmes à l'avance et prendre des mesures pour empêcher les tendances négatives de perdurer.
Vous pouvez également utiliser le décisionnel pour découvrir des corrélations entre des points de données apparemment non liés, puis adapter vos stratégies afin de convertir vos idées en économies ou en gains financiers.
Chaque décision prise chaque jour dans votre travail, qu'il s'agisse de résoudre un problème ou de planifier l'avenir, se traduit directement ou indirectement par un coût ou un profit pour votre entreprise.
Le décisionnel en action
Comprendre le décisionnel sur un plan théorique est excellent, mais le voir en action vous permet de comprendre vraiment ses avantages.
Pour vous montrer comment fonctionne le décisionnel, les trois autres articles de cette série décrivent le développement d'une solution de décisionnel pour une société fictive appelée Adventure Works.
À la fin de cet article, j'expliquerai comment obtenir l'exemple de base de données d'Adventure Works, un fabricant de bicyclettes fictif qui vend ses produits dans le monde entier.
Ce fabricant gère un personnel commercial pour vendre ses produits en gros aux revendeurs tels que des petits magasins spécialisés dans la bicyclette ou des grands magasins de style grande surface.
Adventure Works commercialise également des produits directement à des clients individuels via Internet.
Les données d'Adventure Works fournissent de nombreuses opportunités d'analyse adaptées à une solution de décisionnel.
N'oubliez pas qu'une solution de décisionnel est conçue pour aider la prise de décision.
Par conséquent, examinons les types de questions auxquelles Adventure Works doit répondre avant de prendre des décisions stratégiques :
-
Quelle est la filière de vente la plus rentable ?
Adventure Works doit décider soit d'investir dans du personnel de vente supplémentaire afin de développer ses relations avec davantage de revendeurs, soit de développer sa présence commerciale sur Internet.
Pour guider sa décision, les analystes doivent pouvoir comparer l'évolution des performances de ventes des revendeurs et du site Internet.
Les points de données de performances des ventes (appelés mesures) que les analystes doivent comparer comprennent les ventes en euros, la quantité des commandes et la rentabilité.
Une tendance de rentabilité positive représente la mesure la plus importante, car des ventes élevées exprimées en euros ou en nombre d'unités vendues ne profitent guère à l'entreprise si ces ventes entraînent une perte nette.
-
La demande de certains produits est-elle en augmentation ou en baisse ?
Adventure Works doit faire correspondre ses niveaux de production aux demandes commerciales.
Si la demande pour certains produits se développe, Adventure Works doit ajuster ses processus de fabrication pour garantir que ces produits seront disponibles à la vente en plus grand nombre, et donc augmenter les ventes.
Si la demande pour d'autres produits diminue, Adventure Works doit réduire leur production ou éventuellement supprimer des lignes de produits pour éviter de se trouver en surproduction et vendre ces produits à perte.
Même si vous n'analysez pas des données de ventes dans votre travail, je vous engage à rester avec nous pendant que nous créons une solution de décisionnel pour Adventure Works.
Vous pouvez appliquer les principes de conception et de développement décrits dans cette série à vos propres données.
La pile Microsoft BI
Maintenant, examinons de plus près l'architecture technologique du décisionnel.
La pile Microsoft BI fournit tous les outils nécessaires pour créer, gérer et utiliser une solution de décisionnel.
SQL Server 2008 constitue la fondation de la pile en tant que plate-forme de données hébergeant le data mart ou le Data Warehouse.
Un data mart est une banque de données spécifique à un sujet.
Un Data Warehouse est une collection à l'échelle de l'entreprise de données contenant plusieurs sujets.
La distinction entre les data marts et les Data Warehouses est floue, mais vous n'avez pas à faire la différence.
Dans cette série, j'utilise le terme data mart
(bien que cette série d'articles fasse spécifiquement référence à SQL Server 2008, vous pouvez également créer une solution de décisionnel similaire en utilisant SQL Server 2005 et ses composants BI avec peu ou aucune modification des instructions fournies).
SQL Server 2008 comprend trois composants BI : Integration Services (SSIS), Analysis Services (SSAS) et Reporting Services (SSRS).
Ces composants complètent la plate-forme de données respectivement par des fonctionnalités d'intégration de données, une base de données multidimensionnelle et une couche de présentation des données.
La figure 1 illustre les relations de ces composants entre eux dans une solution de décisionnel.
Figure 1 Composants de SQL Server 2008 dans une solution de décisionnel
Une fois conçues les structures physiques de votre data mart, SSIS vous permet de remplir celui-ci avec des données extraites d'autres sources de données.
SSIS offre les outils nécessaires pour automatiser les processus de nettoyage des données, consolider les données à partir de plusieurs sources et les transformer dans une structure adaptée à l'analyse.
Vous pouvez planifier l'exécution périodique de ces processus à l'aide de l'agent SQL Server.
Dans son article sur SSIS en p.
31, Derek Comingore explique comment développer des processus d'extraction, de transformation et de chargement (ETL) pour une solution de décisionnel.
Ajouter une base de données SSAS à votre solution de décisionnel vous permet de prendre en charge davantage de requêtes interactives, sophistiquées et aux performances élevées.
SSAS permet de copier vos données relationnelles dans une structure de base de données multidimensionnelle appelée cube.
Un cube bien conçu optimise les données pour les requêtes ad hoc en ajoutant des index et l'équivalent fonctionnel de tableaux récapitulatifs (également appelé agrégations) pour renvoyer des résultats de requête bien plus rapidement qu'une requête comparable dans une base de données relationnelle.
Vous pouvez également incorporer au cube une logique de calcul complexe pour simplifier les requêtes qui sinon nécessiteraient de répliquer des centaines de lignes de code Transact-SQL lorsque vous utilisez une source de données relationnelle.
De nombreux outils frontaux (appelés explorateurs de cube) vous permettent d'interroger un cube sans écrire une seule ligne de code.
Dans le numéro du mois prochain, Scot Reagin vous montrera comment développer un cube au sein d'une solution de décisionnel.
Si vous enregistrez vos données dans un data mart SQL Server ou dans un cube SSAS, vous pouvez ajouter SSRS à votre architecture de solution pour mettre les données à disposition des utilisateurs.
SSRS est une plate-forme de création de rapports qui inclut des outils permettant de développer des rapports, de sécuriser et de gérer des rapports publiés à l'aide d'une infrastructure d'administration centralisée et de prendre en charge l'accès des utilisateurs aux rapports.
Vous pouvez utiliser une application Web SSRS ou Microsoft Office SharePoint Server 2007 (MOSS) pour consulter les rapports, utiliser la fonctionnalité d'abonnement pour les recevoir par courrier électronique ou appeler le service Web SSRS dans votre propre application pour afficher vos rapports.
La vue par défaut d'un rapport s'affiche au format HTML, mais vous pouvez également exporter un rapport vers d'autres types de fichiers, tels que PDF ou Excel.
Le mois prochain, je vous en dirai plus sur l'utilisation de SSRS dans la couche de présentation des données de votre solution de décisionnel.
La pile Microsoft BI comprend également plusieurs technologies Microsoft Office qui étendent les options de la couche de présentation des données.
Excel 2007 est un choix courant pour prendre en charge l'analyse des données dans les solutions de décisionnel.
Vous pouvez accéder à votre data mart SQL Server ou parcourir un cube SSAS directement à partir d'Excel (comme illustré dans la figure 2) et explorer des données bien plus librement qu'en affichant un rapport SSRS.
Figure 2 Utilisation d'Excel 2007 pour parcourir un cube
Parallèlement à l'utilisation d'Excel pour explorer à la fois des données relationnelles et multidimensionnelles, vous pouvez utiliser ses algorithmes de Data Mining pour découvrir des schémas d'informations cachés dans vos données ou pour détecter des anomalies dans les données (ce qui signifie que vous pouvez résoudre les problèmes avant de remplir votre data mart).
Un bon moyen de commencer l'exploration de données consiste à télécharger depuis le site Microsoft un complément gratuit pour Excel et à l'utiliser pour analyser les données importées dans Excel à partir de n'importe quelle source ou pour afficher le résultat d'un modèle de Data Mining créé et enregistré sur le serveur SSAS.
Un complément de Visio 2007 est également disponible pour partager des modèles de Data Mining annotés.
Pour en savoir davantage sur le téléchargement et l'utilisation de ces compléments, consultez «Compléments de Data Mining pour Office 2007.»
Un choix de plus en plus répandu pour le partage des données est Excel Services, disponible dans MOSS.
À l'aide d'Excel 2007, vous commencez par créer un classeur contenant un tableau croisé dynamique qui utilise un cube SSAS comme source de données, puis vous publiez la connexion de données et votre classeur dans Excel Services.
Bien que vous puissiez publier des classeurs contenant des données issues d'autres types de sources de données, l'un des avantages d'utiliser ensemble SSAS, les tableaux croisés dynamiques et Excel Services est la possibilité d'utiliser pratiquement les mêmes fonctionnalités d'exploration de cube au sein d'une interface HTML pure qui conserve la familiarité d'Excel.
Un autre avantage est la possibilité de centraliser l'administration et l'accès aux classeurs Excel.
Pour plus d'informations sur Excel Services, reportez-vous à la «Présentation technique d'Excel Services».
Un autre avantage d'utiliser Excel Services pour explorer un cube est que vous pouvez incorporer des tableaux croisés dynamiques et des graphiques de tableau croisé dynamique dans une page du tableau de bord de MOSS à l'aide du composant WebPart Excel Web Access.
Un tableau de bord est un type de contenu SharePoint spécial qui vous permet de présenter des données provenant de plusieurs sources sur une seule page à l'aide de divers composants WebParts.
Vous pouvez même ajouter un filtre à la page du tableau de bord et le connecter à tout ou partie des composants WebParts pour modifier dynamiquement le contenu de la page selon le filtre sélectionné.
La figure 3 présente un exemple de tableau de bord de MOSS.
MOSS inclut également un composant WebPart pour afficher les rapports SSRS stockés sur le serveur MOSS (configuration SSRS facultative appelée mode intégré) ; vous pouvez aussi utiliser les composants WebParts livrés avec SSRS pour afficher les rapports stockés sur le serveur de rapports (configuration par défaut appelée mode natif).
Figure 3 Utilisation d'une page de tableau de bord de MOSS pour afficher les classeurs et les rapports
Pour des tableaux de bord avec encore plus de fonctionnalités, vous pouvez utiliser Microsoft Office PerformancePoint Server 2007 (PPS).
Vous utilisez PPS pour développer des cartes de performance et des tableaux de bord que vous pouvez déployer sur MOSS.
Une carte de performance est un rapport qui compare les performances réelles à une cible définie et affiche les résultats en utilisant des icônes de couleur.
Vous pouvez afficher une carte de performance PPS à l'aide d'un type spécial de composant WebPart dans un tableau de bord de MOSS standard ou comme partie d'un tableau de bord PPS.
Dans le tableau de bord, vous pouvez ajouter des rapports PPS aux zones du tableau de bord pour présenter différentes vues des mêmes données (comme illustré dans la figure 4) ou afficher des données connexes provenant de sources différentes.
Figure 4 Utilisation d'un tableau de bord PPS pour afficher des données
Comme vous pouvez le voir, la pile Microsoft BI offre de nombreuses options de développement, d'administration et d'implémentation de votre solution de décisionnel, mais elle ne vous empêche en aucun cas d'utiliser les autres options.
La pile Microsoft BI tout entière est une architecture extensible dans laquelle vous pouvez connecter vos propres applications personnalisées ou des applications tierces, lorsque vous devez prendre en charge des besoins spécifiques.
Une approche du développement de solutions
Le meilleur moyen pour apprendre à connaître la pile Microsoft BI consiste à créer une solution simple.
Les articles associés dans cette série vous montrent comment créer une solution à l'aide de SSIS, SSAS et SSRS.
Lorsque vous aurez terminé la série, vous aurez une idée générale du fonctionnement de chacun de ces composants.
Ne vous sentez pas obligé, cependant, d'utiliser chaque composant de la pile à chaque fois que vous créez une solution de décisionnel.
Lorsque vous créez votre solution de décisionnel, prévoyez de consacrer l'essentiel de votre temps à des tâches de préparation des données, telles que la restructuration et le nettoyage.
Dans le jargon du décisionnel, cet ensemble de tâches s'appelle les processus d'extraction, de transformation et de chargement (ETL).
Avant de commencer à développer ces processus, vous devez planifier avec soin la conception de votre solution de décisionnel.
Selon mon expérience, développer une solution de décisionnel est plus simple lorsque vous avez un problème professionnel spécifique à résoudre et que vous abordez la conception en étudiant d'abord comment les utilisateurs doivent interagir avec les informations.
En adoptant une approche orientée utilisateur, vous pouvez remonter le courant des processus professionnels applicables pour concevoir une solution qui récupère et structure correctement les données afin de prendre en compte vos besoins professionnels.
Cette recommandation peut sembler une approche évidente, mais j'ai vu beaucoup de cas où le développement de solutions commençait par les données disponibles pour descendre vers les utilisateurs, ce qui aboutissait à une solution qui n'était jamais utilisée.
Une fois muni d'une conception initiale, vous êtes prêt à commencer à développer.
Si votre solution de décisionnel utilise SSIS, SSAS et SSRS, vous commencez par créer et remplir les structures de données de la solution de décisionnel à l'aide de SSIS.
Une fois les données en place, vous passez à l'étape suivante en créant un cube.
Une fois votre développement terminé, vous traitez le cube pour le charger de données.
Puis, vous utilisez SSRS pour développer un rapport qui interroge le cube et affiche les résultats de la requête dans un rapport.
Vous verrez comment avancer dans ce processus dans les trois prochains articles de cette série.
Pour vos propres projets, vous devez envisager ce processus de manière incrémentielle et itérative pour vous assurer que les résultats d'une étape fonctionnent correctement dans les étapes suivantes.
Mise en route
Pour réaliser la solution de décisionnel entière décrite dans les autres articles de cette série, vous devez installer SQL Server 2008, y compris SSIS, SSAS et SSRS.
Si vous avez accès à SQL Server, à un serveur SSAS et à un serveur de rapports sur votre réseau, il suffit d'installer les outils de développement sur votre ordinateur.
Pour obtenir des instructions sur l'installation du produit, consultez «Comment installer SQL Server 2008 (installation) ». Vous pouvez télécharger les exemples de bases de données utilisés pour créer la solution d'Adventure Works depuis CodePlex. La première base de données, AdventureWorks2008, est représentative d'une base de données de traitement transactionnel en ligne (OLTP), qui capture les transactions générées par les opérations métier dans les services ventes, production et ressources humaines.
Vous utiliserez cette base de données comme source du data mart que vous créez à l'aide de SSIS.
La deuxième base de données, AdventureWorksDW2008, est un exemple de données représentant les méthodes recommandées pour la conception d'un Data Warehouse.
Vous pouvez utiliser cette base de données comme source pour votre cube SSAS, si vous décidez d'ignorer les explications sur SSIS et de passer directement au développement du cube.
Étapes suivantes
Une fois familiarisé avec les composants SQL Server BI, vous devez trouver un projet simple qui vous soit propre pour continuer à améliorer vos connaissances.
Il n'est pas nécessaire de disposer d'un data mart complet pour commencer, mais vous devez essayer de structurer vos données en utilisant les principes décrits dans l'article suivant de cette série.
Une fois que vous aurez commencé à utiliser le décisionnel, vous ne regarderez sans doute jamais plus les données tout à fait de la même manière.
Stacia Misner est consultant en décisionnel, formatrice et auteur, ainsi que la fondatrice et directrice de Data Inspirations.
Elle possède 25 ans d'expérience dans le secteur informatique, dont neuf axés sur la pile Microsoft BI.
Stacia a écrit plusieurs livres sur le décisionnel et SQL Server.
Son dernier livre, Microsoft SQL Server 2008 Reporting Services Step by Step (Microsoft Press, 2009), a été publié cette année.
Vous pouvez lui écrire à l'adresse smisner@datainspirations.com.
|
|
TechNet Features
TechNet SubscriptionsVous n'êtes pas abonné à Technet ? Abonnez-vous aujourd'hui et faites partie des premiers à accéder à des milliers de produits Microsoft, tels que :
|