Implementando relatórios inteligentes com a plataforma Microsoft Business Intelligence

Publicado em: 16 de janeiro de 2006

Este artigo apresenta um resumo do livro Applied Microsoft Analysis Services, de Teo Lachev. Aprenda a criar relatórios “inteligentes” usando SSRS (Reporting Services), SSAS (Analysis Services) e procedimentos CLR armazenados do SQL Server. Obtenha os relatórios demonstrados neste artigo baixando o código de exemplo.

Nesta página

Criando relatórios de mineração de dados
Resumo
Livros relacionados:

Criando relatórios de mineração de dados

A inteligência comercial deve ajudar os usuários a analisar padrões do passado para planejar o futuro. A mineração de dados apresenta muitas oportunidades de implementar uma nova geração de relatórios com recursos analíticos de previsão. Esses relatórios podem processar padrões históricos para apresentar visualizações de oportunidades e tendências. Os dois relatórios de exemplo (Targeted Campaign e Sales Forecast) incluídos neste artigo demonstram como você pode utilizar recursos de mineração de dados do SSAS para criar relatórios “inteligentes”. O primeiro relatório apresenta uma lista dos dez clientes principais que têm mais probabilidade de comprar um determinado produto. O segundo relatório usa o histórico de vendas passadas para prever vendas futuras.

Figura 1.  O relatório Targeted Campaign usa um modelo de mineração de dados para exibir uma lista de compradores potenciais.

Figura 1.  O relatório Targeted Campaign usa um modelo de mineração de dados para exibir uma lista de compradores potenciais.

Esses relatórios usam o cubo SOS OLAP, cuja definição está incluída no projeto SOS OLAP Analysis Services. O cubo inclui modelos de mineração de dados para campanha dirigida (Targeted Campaign.dmm) e previsão de vendas (Sales forecasting.dmm). A discussão sobre os modelos de mineração de dados está além do escopo deste artigo. Antes de executar os relatórios, verifique se você implantou o cubo SOS OLAP para o servidor do Analysis Services (no BI Studio, clique com o botão direito do mouse no nó do projeto SOS OLAP e escolha Deploy).

Targeted Campaign

Suponha que você precise preparar um relatório padrão que liste os compradores mais prováveis. A Figura 1 mostra o relatório Targeted Campaign, que atende a esse requisito. O usuário final pode filtrar o relatório por categoria de produto. O relatório mostra os dez clientes principais que podem comprar um produto da categoria selecionada e a probabilidade estimada.

Criando a consulta DMX

Para implementar um relatório que origina dados de um modelo de mineração, é necessário criar uma consulta DMX (Data Mining Extension) para recuperar os dados previstos de um modelo de mineração. A criação de uma instrução de consulta DMX é fácil com o Construtor de Consultas gráfico.

  1. Crie um novo conjunto de dados dsCampaign que use o SOS OLAP como uma fonte de dados.

  2. No menu suspenso Dataset (guia Data), selecione o conjunto de dados dsCampaign para abri-lo no Construtor de Consultas.

  3. Selecione o botão de picareta da barra de ferramentas para alternar para o modo de comando DMX (Figura 2).

    Figura 2.  Alterne para o modo de comando DMX para criar uma consulta DMX.

    Figura 2.  Alterne para o modo de comando DMX para criar uma consulta DMX.

Para produzir a consulta necessária para o relatório Targeted Campaign, usei o modo de Design do Construtor de Consultas. A visualização vTargetMail desempenha a função da tabela de casos que contém os novos clientes. Assim como no MDX, as consultas DMX podem ter parâmetros. O espaço reservado do parâmetro @ProductCategory será substituído durante o tempo de execução pelo valor da categoria de produto selecionada. Se desejar testar o parâmetro durante o tempo de design, você pode clicar no botão Query Parameters da barra de ferramentas. Na caixa de diálogo Query Parameters seguinte, digite @ProductCategory como um nome de parâmetro e o nome da categoria como o valor do parâmetro.

Como o relatório precisa dos dez clientes principais que terão mais probabilidade de comprar um produto da categoria selecionada, tive que finalizar a consulta no modo SQL (clicando com o botão direito do mouse fora das duas tabelas e escolhendo SQL. Eu precisava introduzir uma cláusula ORDER na consulta a fim de classificar pela coluna de probabilidade prevista e usar SELECT TOP 10 para completar a consulta.

Construindo o parâmetro do relatório

Assim como no modo de comando MDX, no momento em que você introduz um espaço reservado de parâmetro na consulta DMX, o Report Designer cria um parâmetro no nível do relatório. Para tornar o parâmetro controlado por dados, usei um segundo conjunto de dados (dsCategory), que busca as categorias de produtos no banco de dados da AdventureWorks. Usei esse conjunto de dados para derivar os valores disponíveis dos parâmetros.

Depois de cuidar da consulta e dos parâmetros do relatório, fica fácil criar o layout do relatório. Usei uma região de tabela que é ligada ao conjunto de dados dsCampaign. Em seguida, arrastei os campos dsCampaign do painel Datasets e soltei-os na região da tabela para criar as três colunas. O relatório também demonstra como a formatação condicional baseada em expressão pode ser usada para alternar a cor do plano de fundo das linhas da tabela.

Figura 3.  O relatório Sales Forecast usa um modelo de mineração de dados de sessão para prever vendas futuras.

Figura 3.  O relatório Sales Forecast usa um modelo de mineração de dados de sessão para prever vendas futuras.

Previsão de vendas

A previsão de vendas é um requisito de relatório crítico para a maioria das empresas. Ao mesmo tempo, tradicionalmente, a previsão de vendas sempre foi um relatório difícil de implementar, e as previsões sempre foram incorretas devido à saída incorreta dos modelos matemáticos usados. Nesta seção, quero mostrar como a mineração de dados do SSAS pode ser usada para criar relatórios de previsão de vendas convincentes e consistentes.

Do ponto de vista do usuário, o relatório Sales Forecast (Figura 3) é simples. O usuário final digita o ano do período do histórico e o número dos meses previstos. O relatório exibe os números de vendas do ano selecionado seguidos pelos números previstos (sombreados em cinza). Os dados são divididos pelo modelo e território do produto, em linhas, e pelo tempo (em meses), em colunas.

Escolhendo a abordagem de implementação

O algoritmo Time Series não dá suporte à transmissão de um conjunto de dados de entrada usando uma instrução Prediction Join. Como resultado, a única maneira de fazer a previsão a partir de um conjunto de dados arbitrário é criar um novo modelo de dados Time Series ligado a esse conjunto de dados. Uma forma de se fazer isso é criar um modelo de mineração de sessão que é descartado automaticamente pelo servidor ao final da sessão do usuário. Do ponto de vista do SSRS, você tem pelo menos três opções para criar um relatório que use um modelo de mineração de sessão. Primeiro, você pode implementar uma extensão de dados personalizada para gerar o modelo, recuperar os resultados como um conjunto de dados (ou leitor) do ADO.NET e converter os resultados em um formato que o SSRS entenda.

Segundo, você pode chamar o código personalizado em um assembly .NET externo que gera o modelo de mineração de sessão e recupera os resultados por meio de expressões no relatório. Demonstrei uma abordagem semelhante em meu livro Microsoft Reporting Services in Action (consulte Resources). As duas abordagens mencionadas acima compartilham as mesmas vantagens e desvantagens. Elas são difíceis de implementar e depurar. É preciso distribuir e registrar a extensão do conjunto de dados personalizado (ou do assembly externo) com o Report Server. Finalmente, as extensões personalizadas têm suporte apenas nas edições Standard e Enterprise do SSRS.

Com o advento dos procedimentos CLR armazenados do SQL Server 2005, uma terceira abordagem é mudar a lógica de programação para um procedimento CLR armazenado. Um procedimento CLR armazenado é um código .NET empacotado como um procedimento armazenado. Em minha opinião, os procedimentos CLR armazenados abrem um novo mundo de cenários de implementação e integração que eram difíceis, se não impossíveis, com as versões anteriores do SQL Server. Quando o procedimento CLR armazenado é implementado e implantado, ele pode ser chamado a partir do seu relatório exatamente como um procedimento armazenado normal. A desvantagem dessa abordagem é que ela requer o SQL Server 2005. Vamos usar um procedimento CLR armazenado para implementar o relatório Sales Forecast.

Implementando o modelo de mineração SalesForecast

Ao implementar um procedimento CLR armazenado, pode ser mais fácil adotar uma abordagem em duas etapas. Primeiro, para acelerar o desenvolvimento e o teste, você escreve e depura o código .NET em um projeto do .NET padrão, por exemplo, um aplicativo de console. Quando o código estiver pronto, você o move para um procedimento CLR armazenado e registra o procedimento no SQL Server 2005. Na solução Ch18, você encontrará um aplicativo de console TimeSeries que demonstra a primeira etapa do processo e o assembly AdventureWorks que inclui a versão final do procedimento armazenado CreateSessionModel.

Você pode usar as instruções AMO ou DMX DDL para criar o modelo de mineração. A listagem 1 mostra o código abreviado do aplicativo de console TimeSeries que gera e consulta o modelo de sessão usando apenas o DMX. Na pasta TimeSeries, você encontrará um arquivo chamado SalesForecast.dmx, que pode ser usado para testar as instruções DMX no Management Studio.

Listagem 1.  Criando um modelo de mineração de sessão que retorna os dados históricos e previstos.

Private Sub CreateSessionModel(ByVal Year As Integer, _
        ByVal numberMonths As Integer)
 
    command.CommandText = "DROP MINING STRUCTURE SessionForecast_Structure"
       command.Connection = connection
    command.ExecuteNonQuery()
 
' Create a session model
    query = "CREATE SESSION MINING MODEL SessionForecast ( " _
    & "TimeIndex LONG KEY TIME, ModelRegion TEXT KEY," _
    & "Amount LONG CONTINUOUS PREDICT" _
    & ") Using Microsoft_Time_Series WITH DRILLTHROUGH"
 
    command.CommandText = query
    command.ExecuteNonQuery()
 
    Dim startMonth As Integer = Int32.Parse(Year.ToString() & "01")
    Dim endMonth As Integer = Int32.Parse(Year.ToString() & "12")
 
    ' Train the model
    query="INSERT INTO SessionForecast,TimeIndex,ModelRegion,Amount,Quantity) " _
     & "OPENQUERY([Adventure Works DW], " _
      & "'Select TimeIndex, ModelRegion, Amount " _
     & "FROM [vTimeSeries] WHERE (TimeIndex >= " & startMonth & _
    &  "And TimeIndex <= " & endMonth & ") ORDER BY TimeIndex')"
 
    command.CommandText = query
    command.ExecuteNonQuery()
 
    Dim predictions As New DataSet
    ' Get predicted results
    query = "SELECT ModelRegion, " _
    & "(SELECT $TIME, [Amount], PredictVariance([Amount]) " _
    & "FROM PredictTimeSeries([Amount], @NumberMonths)) " _
    & "FROM [SessionForecast]"
 
    command.CommandText = query
    command.Parameters.Add("NumberMonths", numberMonths)
    adapter.SelectCommand = command
    ' Fill the dataset
    adapter.Fill(predictions)
 
    ' Get the cases
    query = "SELECT ModelRegion, TimeIndex, Amount  FROM [SessionForecast].CASES"
    command.CommandText = query
    adapter.SelectCommand = command
    Dim cases As New DataTable
    adapter.Fill(cases)
 
    ' Merge cases and predictions
    Dim results As DataTable = PopulatePredictedColumns(predictions.Tables(0))
    results.Merge(cases)
End Sub

Primeiro, o código tenta descartar a estrutura de mineração da sessão. Normalmente, o código não o localiza e emite um erro. Isso ocorre porque um modelo de mineração de sessão é descartado automaticamente quando a sessão do usuário é encerrada. No entanto a instrução DROP MINING STRUCTURE pode ser útil durante a depuração, por exemplo, quando você precisa alterar uma consulta e recriar a estrutura sem reiniciar o aplicativo.

Criando o modelo de mineração

Em seguida, o código cria o modelo de mineração de sessão SalesForecast. Para os objetivos do relatório Sales Forecast, precisamos apenas de três colunas – TimeIndex (o mês), Model Region (estamos fazendo a previsão por meio da combinação de modelo-região em linhas) e Amount (a coluna na qual estamos fazendo a previsão). Usei as mesmas colunas para o modelo que aquelas incluídas na exibição SQL vTimeSeries que é usada para popular o modelo. Quando o servidor executa a instrução CREATE SESSION MINING MODEL, ele cria o modelo SalesForecast e a SalesForecast_Structure para hospedar o modelo.

Treinando o modelo

Quando o modelo de sessão é gerado, estamos prontos para treiná-lo com o conjunto de dados históricos. Fazemos isso enviando uma instrução INSERT INTO DMX, que alimenta o modelo com dados da exibição SQL vTimeSeries para o período selecionado no relatório. Essa instrução é que faz o trabalho pesado da função CreateSessionModel e demora muito tempo para ser executada. Durante a execução da instrução, o servidor popula o modelo com dados e processa (treina) o modelo a fim de produzir os resultados previstos.

Figura 4.  Os resultados previstos são retornados como uma tabela aninhada.

Figura 4.  Os resultados previstos são retornados como uma tabela aninhada.

Consultando o modelo

O código continua enviando uma consulta de previsão para obter os resultados previstos. Um modelo Time Series expõe os resultados previstos como uma tabela aninhada que contém tantas linhas quantas forem as etapas da previsão. Portanto, para recuperar os números previstos, a instrução SELECT usa uma subconsulta que retorna o mês previsto (função $TIME), o valor e a variação estimada da previsão (função PredictVariance). Dados os resultados mostrados na Figura 4, o modelo SalesForecast previu que o valor das vendas para o primeiro mês previsto (janeiro de 2004) será de US$ 121.415.

Dd569881.tip(pt-br,TechNet.10).gif Dica:

Na vida real, você deve gastar algum tempo para otimizar o modelo de mineração e reduzir a variação para obter previsões mais precisas.

Observe que o número dos meses previstos é transmitido como um parâmetro para a consulta de previsão. Os resultados previstos são inseridos no conjunto de dados predictions do ADO.NET.

Figura 5.  Os dados históricos são obtidos da tabela de casos.

Figura 5.  Os dados históricos são obtidos da tabela de casos.

Além dos valores previstos, o relatório Sales Forecast exibe os dados históricos. A segunda instrução SELECT consulta o modelo de mineração para recuperar os casos usados para treinar o modelo. Cada modelo de mineração expõe uma propriedade CASES que retorna a tabela de casos. Nem é preciso dizer que podemos obter os casos diretamente da exibição vTimeSeries para o período solicitado.  

Combinando os resultados históricos e previstos

Precisamos combinar os resultados históricos e previstos em um único conjunto de dados que contém todos os dados necessários para gerar o relatório. No entanto, da forma como estão, os dois conjuntos de dados possuem esquemas diferentes. Apenas conjuntos de dados com esquemas idênticos podem ser mesclados.  A função auxiliar PopulatePredictedColumns (não mostrada na Listagem 1) converte o conjunto de dados predictions no esquema do conjunto de dados cases, criando um novo objeto DataTable.

Como o conjunto de dados predictions possui duas tabelas unidas com uma relação (consulte a Figura 4), PopulatePredictedColumns faz o loop por cada linha pai (ModelRegion), recupera os registros filho (valores mensais previstos) e nivela as duas linhas em uma única linha. Finalmente, o código mescla os resultados previstos e os resultados de casos em uma tabela. O relatório Sales Forecast usa uma região de matriz para rotacionar o campo TimeIndex em colunas.

Trabalhando com procedimentos CLR armazenados

A última tarefa de implementação é converter o código .NET em um procedimento CLR armazenado que será chamado pelo relatório Sales Forecast. Isso envolve a criação de um projeto de banco de dados do SQL Server e a alteração do código para serializar o objeto DataTable do ADO.NET. Você precisará do VS.NET para criar um projeto do SQL Server. Se você não tiver o VS.NET, poderá implantar o assembly AdventureWorks localizado na pasta AdventureWorks\bin.

Dd569881.tip(pt-br,TechNet.10).gif Dica:

Se for necessário executar apenas uma consulta de previsão DMX, considere o uso de um procedimento armazenado do SSAS, que retorna IDataReader como uma fonte de dados para o relatório. Por exemplo, um procedimento armazenado do SSAS pode consultar um modelo de mineração e retornar os resultados usando o método AdomdDataReader.ExecuteReader. O relatório Sales Forecast usa um procedimento CLR armazenado por dois motivos principais. Primeiro, ele precisa dos resultados da mineração como um conjunto de dados do ADO.NET, para que possa combinar o conjunto de dados previstos com o conjunto de dados históricos. Da forma como está, a biblioteca de objetos do ADOMD Server não expõe o objeto AdomdDataAdapter, e eu queria evitar ter de popular uma tabela do ADO.NET por meio de programação. Segundo, os procedimentos CLR armazenados são mais flexíveis porque não estão restritos apenas ao uso do ADOMD Server.

Criando um projeto do SQL Server

A maneira mais fácil de trabalhar com um procedimento CLR armazenado é criar um projeto do SQL Server. Um projeto do SQL Server pode incluir procedimentos armazenados, funções definidas pelo usuário, tipos definidos pelo usuário e disparadores escritos em código .NET. Além disso, um projeto do SQL Server implanta automaticamente os objetos CLR no servidor do banco de dados e oferece suporte à depuração.

  1. Selecione o menu File --> New --> Project. Expanda o tipo de projeto Visual Basic e selecione Database.

  2. No painel Modelos, escolha SQL Server Project. Digite AdventureWorks como o nome do projeto. Escolha o local onde o projeto será criado e clique em OK.

  3. Renomeie o arquivo Class1.vb como Predictions. Renomeie a classe Class1 dentro dele como StoredProcedures.

  4. Copie a função CreateSessionModel, cole-a dentro da classe StoredProcedures e adicione o modificador Shared. Isso é feito porque todos os procedimentos CLR armazenados devem ser compartilhados (estáticos em C#).

  5. Para informar ao BI Studio que a função CreateSessionModel é um procedimento CLR armazenado, decore-a com o seguinte atributo: <Microsoft.SqlServer.Server.SqlProcedure()>.

    CreateSessionModel requer uma referência à biblioteca de objetos AdomdClient. Para minha surpresa, quando abri o diálogo Add References em um projeto do SQL Server, descobri que a guia SQL Server lista apenas alguns assemblies confiáveis, e o AdomdClient não está entre eles. Para que o AdomdClient seja mostrado em Add References, é necessário primeiro registrar esse assembly no banco de dados AdventureWorksDW.

  6. No Management Studio, conecte-se ao SQL Server que hospeda o banco de dados AdventureWorksDW. Clique com o botão direito do mouse em AdventureWorksDW, selecione New Query para abrir uma nova janela de consulta e execute o seguinte comando T-SQL:

    ALTER DATABASE [AdventureWorksDW] SET TRUSTWORTHY ON
    

    Figura 6.  É necessário registrar um assembly não-confiável explicitamente antes de fazer referência a ele a partir de um projeto do SQL Server.

    Figura 6.  É necessário registrar um assembly não-confiável explicitamente antes de fazer referência a ele a partir de um projeto do SQL Server.

    Esse comando diz ao SQL Server para confiar no banco de dados AdventureWorksDW, e ele é obrigatório porque precisamos elevar as permissões do assembly AdomdClient paraUnsafe.

  7. Expanda AdventureWorksDW database --> Programmability --> Assemblies.

  8. Clique com o botão direito do mouse na pasta Asssemblies e selecione New Assembly.

  9. Navegue até o local de Microsoft.AnalysisServices.AdomdClient.dll (o local de instalação padrão é C:\Arquivos de Programas\Microsoft.NET\ADOMD.NET\90).

  10. Altere o conjunto de permissões para Unsafe (Figura 6). Clique em OK para registrar o AdomdClient.

  11. De volta ao projeto do SQL Server AdventureWorks, selecione Project --> Add Reference. Na caixa de diálogo Add References, mude para a guia SQL Server, selecione o assembly AdomdClient e clique em OK para criar uma referência para ele.

  12. Compile o projeto. Se tudo estiver bem, o projeto será compilado com sucesso.

    A última tarefa de conversão é serializar os resultados do procedimento armazenado.

Retornando os resultados

Um procedimento CLR armazenado não pode retornar resultados tabulares como um objeto DataTable. Em vez disso, os resultados devem ser transmitidos em um formato bem definido usando um pipe conectado (objeto SqlPipe). A listagem 2 demonstra como isso pode ser feito.

Listagem 2  Um procedimento CLR armazenado deve produzir resultados tabulares.

Dim results As DataTable = PopulatePredictedColumns(predictions.Tables(0))
results.Merge(cases)
Dim record As SqlDataRecord = TableRowToSqlDataRecord(results)
SqlContext.Pipe.SendResultsStart(record)
 
For Each row As DataRow In results.Rows
    record.SetValues(row.ItemArray)
    SqlContext.Pipe.SendResultsRow(record)
Next
SqlContext.Pipe.SendResultsEnd()

Primeiro, o procedimento CLR armazenado deve informar o chamador sobre o formato dos resultados retornados enviando de volta um cabeçalho de metadados (Pipe.SendResultsStart). TableRowToSqlDataRecord (não mostrado na função da Listagem 2) é usado para gerar o cabeçalho. Sua tarefa é mapear os tipos de dados do .NET para tipos de dados do SQL Server. Em seguida, CreateSessionModel faz o loop pelas linhas da tabela e chama Pipe.SendResultsRow para produzir cada linha. Finalmente, CreateSessionModel chama Pipe.SendResultsEnd para que o chamador saiba que o final do conjunto de resultados foi atingido.

Figura 7.  É possível depurar um procedimento CLR armazenado no BI Studio.

Figura 7.  É possível depurar um procedimento CLR armazenado no BI Studio.

Testando procedimentos CLR armazenados

Com o BI Studio, é fácil testar o procedimento CLR armazenado. Siga estas etapas para depurar o procedimento armazenado CreateSessionModel.

  1. Abra as propriedades do projeto AdventureWorks e selecione a guia Database. Clique no botão Browse e selecione a referência ao banco de dados AdventureWorksDW para implantar o projeto no banco de dados AdventureWorksDW. Se o AdventureWorksDW não existir, crie uma nova referência de banco de dados que aponte para o banco de dados AdventureWorksDW.

  2. De volta ao Solution Explorer, clique com o botão direito do mouse no projeto do SQL Server AdventureWorks e selecione Deploy. O BI Studio registra o assembly AdventureWorks e todos os seus objetos CLR no banco de dados AdventureWorksDW.

  3. Coloque um ponto de interrupção dentro do procedimento CLR armazenado.

  4. Pressione Ctrl+Alt+S para abrir o Server Explorer. Expanda AdventureWorksDW connection --> Stored Procedures. Clique com o botão direito do mouse no procedimento armazenado CreateSessionModel e selecione Step Into Stored Procedure (Figura 7).

  5. Na caixa de diálogo Run Stored Procedure que é exibida em seguida, digite os valores dos parâmetros, por exemplo, 2003 para o parâmetro @Year e 3 para o parâmetro @NumberMonths.

    Quando tiver testado o procedimento CreateSessionModel, você poderá usá-lo para alimentar um conjunto de dados de relatório.

Implementando a navegação de análise

O relatório Sales Forecast demonstra também o recurso interativo de navegação de análise que tem o suporte do SSRS. Semelhante a uma ação de análise do UDM, uma ação de análise do SSRS pode ser usada para gerar um relatório que mostra os detalhes por trás de um item de relatório. Quando o relatório Sales Forecast é processado, o usuário pode clicar em qualquer número histórico de vendas. Isso gera o relatório Daily Product Sales, que exibe o histórico diário de produtos para o mês e o território de vendas correspondentes. Por exemplo, se o usuário clicar na primeira célula (US$ 41.227), o relatório Daily Product Sales mostrará as vendas agregadas do produto na Europa, divididas por dia.

Figura 8.  Implemente a análise do relatório anexando uma ação de hiperlink a um item do relatório.

Figura 8.  Implemente a análise do relatório anexando uma ação de hiperlink a um item do relatório.

Para implementar uma ação de análise na caixa de texto Amount da região de matriz:

  1. Clique com o botão direito do mouse na caixa de texto Amount, selecione Properties e vá para a guia Navigation.

  2. No painel Hyperlink, selecione a opção Jump to report e selecione o relatório Daily Product Sales.

  3. Clique no botão Parameters e faça a correspondência entre os parâmetros do relatório mestre e do relatório de análise (Figura 8).

Inicialmente, eu estava planejando demonstrar a opção Jump to URL, que dá mais flexibilidade para construir o link da URL. Por exemplo, supondo que você tenha uma função incorporada que defina a variável reportLink para conter o endereço da URL do relatório Daily Product Sales, a ação de navegação de URL a seguir abriria o relatório em uma nova janela e redimensionaria a janela.

"javascript:void(window.open('" & reportLink & "','_blank',
 'location=no,toolbar=no,left=100,top=100,height=600,width=800'))"

O problema com a navegação de URL e os relatórios OLAP é que os valores dos parâmetros geralmente conteriam o E comercial (&), por exemplo, [Date].[Time Index].&[200312]. Isso apresenta um problema com a opção de capacidade de endereçamento da URL porque o Report Server interpreta o & como um espaço reservado de parâmetro de consulta. Nem mesmo o uso do escape no valor do parâmetro (a função escape do JavaScript ou %26 para o &) ajuda, porque o Internet Explorer cancela o uso do escape no valor automaticamente. Se alguém descobrir uma solução alternativa para usar caracteres especiais e capacidade de endereçamento da URL, me avise.

Resumo

O SSAS e o SSRS são tecnologias complementares que podem ser usadas em conjunto para implementar soluções completas de inteligência comercial. Neste artigo, mostrei como você pode criar relatórios inteligentes que usam a mineração de dados para exibir resultados de previsão.

Os procedimentos CLR armazenados do SQL Server abrem um novo mundo para a recuperação, o processamento e a geração de relatórios de dados. Eles podem canalizar o poder do Microsoft .NET e encapsular a lógica de programação complexa. Muitos cenários de integração de dados que exigiam extensões de dados personalizadas do SSRS podem ser implementados muito mais facilmente com o SQL Server 2005 e os procedimentos CLR armazenados.

Livros relacionados:

Applied Microsoft Analysis Services 2005 (em inglês)

Microsoft Reporting Services in Action (em inglês)