Exportar (0) Imprimir
Expandir Tudo
Expandir Minimizar

Migração para o Analysis Services 2005

Publicado em: 19 de agosto de 2005
Por Michael Young, da Proclarity Corporation, e Dave Wickert, da Microsoft Corporation

Artigo técnico sobre o SQL Server
Aplica-se a: SQL Server 2005

Resumo: este documento orienta você pelo processo de migração para o Analysis Services do SQL Server 2005. O UDM (Unified Dimensional Model) oferece novas oportunidades de design aos desenvolvedores de cubos. O UDM reuniu os mundos dos relatórios relacionais e dos relatórios OLAP para fornecer um fórum unificado a ambos os ambientes de solicitação de dados. A compreensão das novas opções de design e de como elas afetam sua organização otimizará a migração. O Migration Wizard é uma ferramenta rápida e eficaz para mover cubos existentes para o Analysis Services 2005. Este documento apresenta informações sobre o assistente e ajuda você a decidir se deve utilizá-lo. Em alguns casos, é melhor refazer o design a partir do zero, para ter certeza de que você está aproveitando adequadamente os novos recursos do Analysis Services 2005.

Nesta página

Sobre o Project REAL
Introdução
Questões de design de cubo que têm impacto sobre a migração
Ferramentas de migração
Migração no Project REAL
Migração versus redesign
Conclusão

Sobre o Project REAL

O Project REAL é um esforço no sentido de descobrir práticas recomendadas para criar aplicativos de inteligência comercial baseados no Microsoft® SQL Server™ 2005 através da criação de implementações de referência baseadas em cenários reais de clientes. Isso significa que dados reais de clientes são usados para superar os mesmos problemas que os clientes enfrentam durante a implantação. Esses problemas incluem:

  • O design de esquemas.

  • A implementação de um processo de ETL (extração, transformação e carregamento) de dados.

  • O dimensionamento de sistemas para produção.

  • O gerenciamento e a manutenção contínuos dos sistemas.

Ao trabalhar com cenários reais de implantação, conseguimos compreender o funcionamento das ferramentas. Nosso objetivo é tentar abordar toda a gama de problemas que uma grande empresa enfrenta durante uma implantação de verdade. Este documento descreve a função da migração no Project REAL. O Project REAL usa dados de dois clientes de inteligência comercial da Microsoft. A Fase 1 do projeto foi criada especialmente para um grande varejista de equipamentos eletrônicos que mantém os dados de vendas e de inventário em um data warehouse com o Microsoft SQL Server 2000. O DTS (Data Transformation Services) do SQL Server 2000 é utilizado para gerenciar o fluxo de dados no banco de dados relacional e, de lá, nos cubos do Analysis Services do SQL Server 2000 voltados para a geração de relatórios e consultas interativas. Esse cliente mantém aproximadamente 200 GB de dados no armazenamento relacional. Todos esses dados são subseqüentemente processados em cubos do Analysis Services. A implementação da Fase 1 se concentra principalmente nas preocupações que um cliente atual do SQL Server 2000 pode ter ao conduzir uma migração para o SQL Server 2005. Nossos resultados representam amplamente a migração da funcionalidade existente, com uns poucos recursos novos utilizados quando apropriado. Na área de migração do Analysis Services, os dados de cubos foram movidos para o Analysis Services 2005 usando principalmente o Migration Wizard. Foram adicionados novos recursos aos cubos depois da migração para a nova versão.

A Fase 2 do Project REAL baseia-se em um conjunto mais amplo de dados de outro cliente e experimenta mais recursos novos do SQL Server 2005 do que a Fase 1. Isso ocorre porque a Fase 2 é principalmente uma nova implementação de uma solução do SQL Server 2005. O objetivo da Fase 2 era demonstrar muitos dos novos recursos do Analysis Services. Foi determinado que era necessário refazer o design dos cubos na Fase 2, e o Migration Wizard não foi utilizado. Procure futuramente por mais documentos sobre o Project REAL.

Introdução

O Analysis Services 2005 oferece uma abordagem renovadora ao OLAP e permite integrar totalmente o OLAP e as exigências de relatórios relacionais. Utilizando o Analysis Services 2005, é possível reduzir a carga de administração geral dos cubos e, ao mesmo tempo, melhorar a experiência do usuário final. A abordagem do UDM (Unified Dimension Modeling) ao design oferece uma ponte direta entre os mundos dos relatórios relacionais e dos relatórios OLAP. Ele alterou a forma pela qual os cubos são fundamentalmente estruturados.

Os novos recursos do Analysis Services 2005 permitem abordar melhor os padrões comuns de navegação, atingir e ultrapassar as exigências de relatórios relacionais e OLAP, lidar com tipos exclusivos de dados e reduzir a sobrecarga de memória relacionada ao fornecimento de análises.

Este documento fornecerá orientações ao longo do processo de migração e ajudará você a determinar o caminho ideal de migração para sua organização. É possível migrar tanto usando ferramentas internas de migração quanto remodelando os cubos existentes. Este documento descreve as mudanças de design no Analysis Services 2005 e como a estrutura atual de seu cubo será afetada por elas.

Este documento cobre as principais etapas do Migration Wizard. Ele também apresenta algumas perguntas que você deve fazer a si mesmo para determinar se o uso do assistente é sua melhor opção.

Este documento ajuda a determinar se você deve usar o Migration Wizard como ponto de partida para seus cubos ou se deve remodelar seus cubos a partir do zero.

Questões de design de cubo que têm impacto sobre a migração

Os cubos do Analysis Services 2005 são muito diferentes daqueles de versões anteriores do produto. Se você fizer a migração usando o Migration Wizard, o Analysis Services tentará duplicar seus cubos atuais no novo ambiente. Embora isso o leve rapidamente à nova plataforma, não permitirá que você aproveite todos os novos recursos de design no Analysis Services 2005.

O Analysis Services 2005 apresenta o UDM (Unified Dimensional Model). A função do UDM é mesclar integralmente os mundos dos relatórios OLAP e relacionais. Tradicionalmente, os ambientes OLAP se destacam no fornecimento de caminhos de navegação para fazer drill-up e drill-down dos dados. Os dados são armazenados em níveis. Os relatórios relacionais se destacam na geração de relatórios em que um campo pode ser colocado em qualquer parte do relatório.

Uma dificuldade com o OLAP surge quando os usuários localizam campos de interesse, mas eles não se ajustam às hierarquias definidas pelo administrador do cubo. Quando esses campos-chave não se ajustam a uma hierarquia natural com outros campos, como eles são incluídos na análise? Para abordar esse problema, uma organização pode contar com duas abordagens diferentes — tanto uma ferramenta OLAP quanto uma ferramenta relacional, por exemplo.

O UDM resolve o problema da integração da análise e dos relatórios relacionais de imediato permitindo que todos os campos de interesse sejam tratados como atributos de primeira classe. O UDM permite uma flexibilidade que não estava disponível anteriormente. O UDM consiste em vários componentes de alto nível, o que permite um design flexível. Esses recursos são:

  • Hierarquias de atributo e hierarquias definidas pelo usuário

  • Atributos relacionados

  • Modos de exibição de fonte de dados

  • Grupos de medidas

  • Perspectivas

As seções a seguir descrevem como cada um desses itens tem influência sobre o design de seus cubos no Analysis Services 2005. Isso ajudará a escolher seu melhor caminho de migração.

Hierarquias de atributo

Com o Analysis Services 2005, é possível criar atributos a partir de qualquer campo que queira incluir na análise Os atributos podem, então, ser utilizados na análise ou em um relatório relacional. Além disso, é possível organizar os atributos em hierarquias para fornecer um caminho de navegação. De uma perspectiva de navegação, as hierarquias de atributo e as definidas pelo usuário substituem a dimensão do Analysis Services 2000. Em conseqüência, será comum os cubos terem muitas, muitas hierarquias de atributo. Na prática, cubos grandes e complexos poderiam conter centenas de atributos. No Analysis Services 2000, era comum considerar como prática recomendada a utilização de um pequeno conjunto de dimensões. Isso ocorreu por dois motivos:

  • Para ajudar a usar a memória com eficiência. Todas as dimensões assumiam como padrão o armazenamento MOLAP e cada membro era carregado na memória. Um pequeno número de dimensões compartilhadas permitiu rapidez no processamento e nos tempos de resposta às consultas.

  • Para adicionar contexto para o usuário. Para os usuários, é difícil conceitualizar mais de seis ou oito dimensões e manter o contexto enquanto fracionam, dividem, fazem drill-up ou drill-down.

    O UDM muda tudo isso. Cada campo que você gostaria de ver na análise pode, e na maioria dos casos vai, ser adicionado como atributo no cubo. Você pode, então, obter vários atributos e colocá-los em hierarquias definidas pelo usuário. As hierarquias definidas pelo usuário podem ser hierarquias tradicionais ou hierarquias fortes, em que muitos filhos apontam para um só pai. Ou podem ser uma hierarquia de navegação, em que os atributos podem ser colocados com diferentes caminhos de navegação, independentemente da cardinalidade entre pai e filho. Esse método de design apresenta as seguintes vantagens:

  • Qualquer campo pode ser colocado em qualquer parte do relatório ou do modo de exibição de seus dados. É muito fácil colocar um único campo em colunas e linhas independentes dos outros campos na hierarquia.

  • Os cubos podem ser mais representativos do data warehouse ou do armazenamento de dados. O cubo do Analysis Services 2005 pode conter muitos atributos, hierarquias definidas pelo usuário e medidas (a partir de várias tabelas de fatos). Isso permite que o cubo seja uma representação mais próxima dos dados de origem.

  • Os cubos podem conter dados de várias tabelas de dimensão e várias tabelas de fatos. Virtualmente, não há limitação para os tipos de design que é possível produzir.

  • Podem ser definidos caminhos de navegação para todos os tipos de dados. Não há mais restrições para os tipos de hierarquias a serem criadas.

  • Para fins de geração de relatórios, não são mais necessárias as propriedades membros e as dimensões virtuais. Geralmente, os administradores de cubos do Analysis Services 2000 eram forçados a adicionar propriedades membros e, em seguida, dimensões virtuais, de modo que pudessem adicionar colunas aos relatórios. Isso não é mais necessário, pois os atributos são a base das análises e dos relatórios, e, na maioria dos casos, um atributo representa uma só coluna.

Atributos relacionados

O conceito de propriedades membros foi expandido no Analysis Services 2005. Agora, a propriedade membro tradicional está disponível como um relacionamento de atributo. Ao consultar propriedades membros, você verá não só as propriedades membros tradicionais, mas todos os relacionamentos de atributos. Os relacionamentos de atributos são utilizados pelo Aggregation Wizard a fim de determinar onde as agregações podem ser executadas. Será necessário haver relacionamentos de atributos entre atributos que estejam organizados em níveis. Por exemplo, uma hierarquia comum de cliente poderia incluir País, Região, Estado, Cidade e Cliente como níveis. Para aproveitar as agregações, Cidade teria um relacionamento de atributo com Estado. O Formula Wizard também usa relacionamentos de atributos para determinar o melhor mecanismo para executar um cálculo.

As propriedades membros eram geralmente utilizadas para facilitar a geração de relatórios no Analysis Services 2000. Para exibir uma coluna que não fizesse parte da hierarquia, uma propriedade membro poderia ser utilizada para exibir o valor da coluna. A propriedade membro poderia ser exibida como um membro calculado, uma dimensão virtual ou por meio de uma ferramenta de terceiros que a expusesse nativamente. Com o UDM, a criação de propriedades membros para fins de relatório não é mais necessária, pois todas as colunas de interesse podem ser facilmente adicionadas como atributos. Os atributos podem, então, ser colocados em colunas e linhas para facilitar as exigências da análise.

Observação:  o Analysis Services 2005 usa relacionamentos de atributos para determinar os cálculos necessários à agregação em hierarquias definidas pelo usuário. Sem os relacionamentos de atributos nas hierarquias, as agregações não seriam criadas. Em hierarquias fortes, um filho terá o nível de seu pai como relacionamento de atributo. O processo de agregação para hierarquias de atributo depende desse relacionamento.

Modos de exibição de fonte de dados

O Analysis Services 2005 adiciona uma camada extra de abstração entre o cubo e a fonte de dados. O modo de exibição de fonte de dados permite separar logicamente o cubo de suas fontes de dados. Uma ou mais fontes de dados podem ser combinadas em um modo de exibição de fonte de dados para fornecer uma representação lógica dos dados. O modo de exibição de fonte de dados pode ser uma seleção de tabelas obtida a partir das fontes de dados ou pode ser uma consulta nomeada. A consulta nomeada é uma instrução SQL escrita de forma que você possa carregar os dados como quiser (como um modo de exibição relacional, mas uma consulta nomeada é armazenada no DSV). O cubo é, então, criado a partir do modo de exibição de fonte de dados.

Os modos de exibição de fonte de dados:

  • Fornecem uma camada de abstração a partir das fontes de dados.

  • Podem incluir várias fontes de dados. Elas podem ser vários bancos de dados no mesmo servidor ou bancos de dados em servidores diferentes.

  • Fornecem consultas nomeadas para que você grave a consulta que o Analysis Services usa para carregar os dados. Isso pode ser utilizado para filtrar, limitar ou otimizar o carregamento de dados a partir da origem.

  • Podem ser utilizados para renomear os dados a fim de fornecer uma camada separada de nomeação a partir da fonte real dos dados.

  • Permitem a representação de chaves lógicas para definir o relacionamento entre as tabelas de fatos e de dimensão.

  • Oferecem suporte a cálculos nomeados. Cada cálculo nomeado armazena uma expressão, que é utilizada para criar a definição da coluna.

  • Fornecem a base para a criação do cubo.

Grupos de medidas

Uma das principais áreas de preocupação com seus novos cubos deve ser o contexto no qual o usuário está exibindo os dados. É possível criar um cubo a partir de várias tabelas de fatos. Cada uma dessas tabelas de fatos pode ter várias medidas e um nível diferente de granularidade. Dessa forma, o cubo não somente terá até centenas de atributos, mas também terá medidas de diferentes tabelas de fatos e granularidade diferente.

Por exemplo, imagine um cubo com um grupo de medidas Vendas Reais, com detalhamento de Produto, Armazenamento, Cliente e Dia (quem comprou o quê, onde, quando?). O cubo também tem um grupo de medidas Previsão, com detalhamento de Classe de Produto, Armazenamento e Mês (o que venderemos e onde venderemos nos próximos meses?). Além disso, ele tem um grupo de medidas Inventário, com detalhamento de Produto, Armazenamento e Semana (quanto tínhamos em estoque, onde e quando?). Combinando esses três grupos de medidas no mesmo cubo, podemos obter informações de tendências. Por exemplo, a falta de produtos em estoque impactou suas vendas e como isso deve direcionar suas projeções para o futuro? Isso pode ser feito porque todos os fatos podem ser combinados no mesmo cubo. No Analysis Services 2000, você criaria dois cubos e os combinaria em um cubo virtual. No Analysis Services 2005, você tem um só cubo com vários grupos de medidas (um para cada tabela de fatos).

Embora isso seja muito flexível para o criador de cubos, nem sempre oferece o contexto necessário para o usuário final. A maioria dos usuários finais não tem familiaridade com o design do armazenamento de dados ou do data warehouse. Os grupos de medidas podem ser criados para separar medidas diferentes umas das outras, a fim de fornecer contexto para o usuário. As medidas com níveis semelhantes de granularidade podem ser agrupadas e tratadas (do ponto de vista administrativo) como uma só unidade. Por padrão, os grupos de medidas são organizados pela tabela de fatos da qual são recuperados. As medidas extraídas de uma única tabela de fatos deve ter um nível semelhante de granularidade. Todas as medidas dentro de uma tabela de fatos única pertencerão ao mesmo grupo de medidas. Os grupos de medidas fornecem o seguinte conjunto de vantagens:

  • As medidas podem vir de várias tabelas de fatos.

  • As medidas podem ser agrupadas por granularidade.

  • Vários níveis de granularidade podem ser incluídos em um só cubo de base.

  • A segurança pode ser aplicada a grupos específicos de medidas.

  • Os grupos de medidas podem ser expostos por meio de uma ou mais perspectivas e agrupados com as dimensões que façam sentido para o usuário final. Os grupos de medidas ajudam a fornecer contexto para o usuário final.

Perspectivas

No Analysis Services 2000, os cubos eram geralmente definidos com um número menor de dimensões e um número definido de medidas a partir de uma só tabela de fatos. Para adicionar medidas de granularidade variada ou para exibir várias dimensões de cubos diferentes, você podia criar um cubo virtual a fim de combinar vários cubos de base para dar a aparência de algo bem maior. Isso permitia que você se preparasse para o resultado final. Não somente nos permitia lidar com os problemas de granularidade, mas também ajudava com o consumo de memória no Analysis Services 2000.

Com o UDM, isso mudou. Agora, o cubo pode ter centenas de hierarquias de atributo, hierarquias definidas pelo usuário e vários grupos de medidas (que vêm de diferentes tabelas de fatos). Por causa disso, o design do cubo é muito flexível. O problema que permanece é o contexto do usuário. Em algum ponto, é necessário restringir a exibição dos dados de forma que eles façam sentido para o usuário final. A exibição dos dados deve permitir que o usuário atenda facilmente às exigências de seu projeto.

As perspectivas fornecem contexto para o usuário final. Uma perspectiva é um conjunto de atributos, hierarquias definidas pelo usuário, ações e grupos de medidas que você deseja agrupar como uma coleção lógica. A perspectiva fornece a base para a parte analítica e fornece contexto para o usuário. Será muito comum ter um grande cubo, com centenas de atributos e várias medidas. Assim, muitas perspectivas serão criadas para os usuários interagirem com a coleção de dados que fizer mais sentido para sua tarefa. O UDM é destinado aos administradores do cubo — as perspectivas são para o usuário final. As perspectivas não podem ser utilizadas para implementar segurança.

Dica:  as perspectivas são expostas às ferramentas front-end de modo semelhante à forma como os cubos eram apresentados no Analysis Services 2000. Se os seus usuários estão acostumados a observar um conjunto de cubos aos quais se conectam e navegam, você pode dar a eles uma sensação parecida implementando perspectivas que incluam as mesmas dimensões e medidas que havia nos cubos do Analysis Services 2000. Por exemplo, é possível ter um cubo físico Vendas com diferentes perspectivas, baseadas nos diferentes usos comerciais desses dados, como a perspectiva de um gerente de produto ou a perspectiva de um gerente de loja, ou ainda a perspectiva de um gerente regional. Na verdade, cada uma delas é exposta como um cubo para o usuário final (como o cubo de base, maior e mais complexo), mas as dimensões, os cálculos, os grupos de medidas e outras entidades foram todos adaptados apenas para aquele uso comercial específico.

Resumo das questões de design

No Analysis Services 2005, os cubos podem ter muitos atributos, hierarquias definidas pelo usuário e medidas. O UDM combina o melhor do mundo OLAP com o melhor do mundo dos relatórios relacionais para oferecer oportunidades ilimitadas no design de cubos. O resultado final do design de cubos pode ser muito mais abrangente do que o necessário para o usuário. É possível usar grupos de medidas e perspectivas para fornecer contexto para os usuários. Na maioria dos casos, a perspectiva será a base para a experiência do usuário.

Ferramentas de migração

O Analysis Services 2005 fornece ferramentas para ajudá-lo no processo de migração. Quando você instala o Analysis Services 2005 em uma máquina que já tem o Analysis Services 2000 instalado e decide fazê-lo na instância padrão, é solicitado que você execute o Migration Wizard durante a instalação. Se você decidir não usar o assistente durante a instalação, poderá usá-lo posteriormente como uma ferramenta autônoma.

O Migration Wizard permite migrar um cubo do Analysis Services 2000 para uma nova versão ou criar um script XMLA (XML for Analysis) para executar a migração posteriormente. Os assistentes são rápidos e eficientes. Será necessário determinar se o resultado final atende às suas necessidades. Em alguns casos, o Migration Wizard é um grande ponto de partida; em outros, é melhor refazer o design. Mesmo que você pretenda refazer o design de seus cubos, a execução do Migration Wizard é uma boa idéia. No mínimo, é uma experiência muito útil e educativa ver como o assistente converte seus objetos. Em última análise, você pode decidir não usar as recomendações e refazer o design do esquema usando os assistentes de design normais, mas pelo menos poderá ver como o Migration Wizard executaria uma atividade semelhante, mesmo que você não concorde com suas decisões finais.

O Analysis Services 2005 contém duas ferramentas internas de migração. A primeira ferramenta é a opção de migração durante a instalação do Analysis Services 2005.

A segunda é o Migration Wizard ser iniciado como processo autônomo, como uma de suas principais ferramentas no grupo de programas do SQL Server 2005.

Migration Wizard

O Migration Wizard faz todo o possível para duplicar os cubos que você tinha no Analysis Services 2000. O objetivo do assistente não é fornecer uma prática recomendada para o cubo do Analysis Services 2005. Com isso em mente, é fácil ver por que ele faz as escolhas que faz. Depois de concluído o assistente, é preciso determinar as etapas adicionais necessárias para chegar ao melhor aproveitamento de todos os recursos do Analysis Services 2005.

O assistente solicita que você selecione os bancos de dados OLAP que deseja migrar. Depois de selecionar os bancos de dados OLAP apropriados, você deve determinar se deseja movê-los diretamente para o Analysis Services 2005 ou se gostaria de gerar um script XMLA. O script pode ser executado posteriormente, a partir do SQL Server Management Studio.

Para executar o Migration Wizard

  1. No grupo de programas do SQL Server 2005, abra o Migration Wizard. O Migration Wizard é uma das ferramentas do Analysis Services. O assistente deve aparecer como mostrado na Figura 1.

    Figura 1: O Migration Wizard do Analysis Services 2005 pode migrar seus cubos do Analysis Services 2000

    Figura 1: O Migration Wizard do Analysis Services 2005 pode migrar seus cubos do Analysis Services 2000

  2. Clique em Next para exibir a seção Source and Destination Page do assistente.

  3. Forneça a fonte e o destino dos dados como mostrado na Figura 2. A fonte de dados deve ser sua instância do Analysis Services 2000. O destino deve ser sua instância do Analysis Services 2005. É possível selecionar um arquivo de script em vez de um destino. Isso faz o assistente gerar um script XMLA que poderá ser executado posteriormente para gerar seus cubos.

    Figura 2: A origem e o destino dos dados precisam ser fornecidos como base para a migração

    Figura 2: A origem e o destino dos dados precisam ser fornecidos como base para a migração

  4. Depois de fornecer uma origem e um destino, clique em Next. O assistente lê os metadados na fonte de dados e exibe a tela Select Databases to Migrate.

  5. Selecione os bancos de dados que devem ser migrados. Por padrão, o nome do banco de dados de destino é gerado para você. O assistente tenta criar um banco de dados com o mesmo nome. Se já existir um banco de dados com o mesmo nome, o assistente gerará um nome que adicionará um valor incremental começando com 1 no final do nome. Para fornecer um nome, clique na célula Destination Database e atribua um nome, como mostrado na Figura 3.

    Figura 3: É possível renomear o banco de dados de destino atribuindo-lhe o nome que você gostaria de usar no Analysis Services 2005

    Figura 3: É possível renomear o banco de dados de destino atribuindo-lhe o nome que você gostaria de usar no Analysis Services 2005

  6. Depois de fornecer os nomes dos bancos de dados a serem migrados e os bancos de dados de destino, clique em Next.

  7. A parte Validating Objects do assistente é iniciada. Ele demora algum tempo para ser executada (dependendo da quantidade de metadados nas fontes de dados). À medida que os objetos são validados, o assistente exibe mensagens de aviso e de erro para os dados com problemas potenciais. É possível exibir detalhes sobre as alterações que o assistente fez em seus dados. Por exemplo, se uma dimensão for renomeada, você receberá uma mensagem de aviso informando como ela foi renomeada. Mais adiante neste documento, ressaltaremos alguns dos problemas potenciais que poderiam ocorrer com o uso do Migration Wizard.

    É possível usar os recursos View Log e Save Log para exibir e filtrar os detalhes e salvá-los em um arquivo, para exame posterior. Quando tiver examinado os detalhes dos objetos, clique em Next.

  8. A tela Migrating Database será exibida. O assistente está executando a migração; os metadados estão sendo gerados. Os dados, entretanto, não são transferidos. Será necessário processar os novos cubos para preenchê-los com dados.

  9. Depois de migrar os bancos de dados, clique em Next para concluir o assistente.

    Observação:  quando os bancos de dados OLAP são migrados, os metadados do cubo são migrados para o Analysis Services 2005. Depois de migrar, você precisará processar o cubo. Os dados serão, então, carregados no cubo a partir da fonte de dados, e você poderá navegar pelos dados.

Os seguintes itens não são migrados com o assistente:

  • Partições remotas

  • Cubos vinculados

  • Opções de drill-through

O assistente faz algumas escolhas durante a migração para mapear os recursos antigos para os novos recursos. Fique atento aos seguintes itens:

  • As propriedades membros são migradas para relacionamentos de atributo. Você notará que o termo relacionamento de atributo é utilizado principalmente no Business Intelligence Development Studio. Se você consultar a API em busca de propriedades membros, ela retornará todos os relacionamentos de atributo. Além de seu conjunto de propriedades membros originais, cada nível na hierarquia terá um relacionamento de atributo adicional para seu nível pai. O relacionamento de atributo é utilizado pelo mecanismo de agregação para fornecer o relacionamento entre seus pontos de dados. Esses relacionamentos são necessários para a sintetização dos cálculos. Esses atributos relacionados não devem ser removidos. Se você tiver adicionado outras propriedades membros para lidar com requisitos específicos de relatórios, poderá remover os atributos relacionados a relatórios, já que as colunas também devem ser definidas como dimensões de atributos.

  • Alguns cálculos nomeados podem ser criados para você no modo de exibição de fonte de dados. Esses cálculos nomeados armazenam a expressão que é utilizada para criar a coluna. Eles serão nomeados como columnx , começando com column1 em cada tabela. Isso ocorre quando se tem um nome de membro ou uma identificação de membro para um nível que esteja baseado em uma expressão no Analysis Services 2000. Nele, as caixas de propriedade de identificação de membro e nome de membro permitiam que as instruções do tipo SQL fossem utilizadas para tratar de questões como a concatenação. Elas agora são armazenadas como expressões. Por exemplo, o cubo da Foodmart tem um exemplo disso na dimensão Customers. Durante a migração, você perceberá, na tabela Customers (no modo de exibição de fonte de dados e também adicionada como atributo), uma nova coluna chamada Column1. Ao examinar as propriedades, você verá que a origem é uma concatenação das colunas First Name e Last Name.

  • Quase todas as colunas das tabelas de fonte de dados são adicionadas como dimensões de atributos. As colunas excluídas são as que têm tipos de dados que o Analysis Services exclui como não interessantes, o que inclui: carimbo de data/hora, identificador exclusivo e tabela. Todas colunas numéricas, de data e baseadas em caracteres são atributos adicionados.

  • Cubos virtuais são migrados como cubos. Os grupos de medidas não são adicionados ao cubo. Eles são migrados como grupos de medidas vinculados que apontam de volta para o cubo de base. Para cada cubo de base ao qual o cubo virtual original faz referência, haverá um cubo de medida vinculado apontando de volta para a base.

  • As dimensões virtuais estão sujeitas às regras de mesclagem de dimensões. As dimensões virtuais eram baseadas em propriedades membros e podiam incluir um ou mais níveis. Se a dimensão virtual tivesse um nível único, ela seria mesclada na dimensão na qual se baseava. Se a dimensão virtual tivesse vários níveis, ela seria convertida em uma dimensão real. Por exemplo, no banco de dados da Foodmart, temos três dimensões virtuais. Para ilustrar isso, veremos Position (que tem vários níveis) e Store Size in Sq Ft (que tem um único nível). Na migração, Position é criada como uma nova dimensão. Store Size in Sq ft é mesclada na dimensão de armazenamento. Square Feet é adicionada como atributo à dimensão.

  • Para cada ação, você receberá uma mensagem declarando que ela será migrada como um comando. Na interface do usuário do Analysis Services 2005, você verá que os comandos ainda são citados como ações.

  • Os modos de exibição de fonte de dados são criados automaticamente e criarão consultas nomeadas para representar um conjunto de colunas de uma tabela. O modo de exibição de fonte de dados criado inclui todas as tabelas de fatos e dimensão que eram utilizadas no banco de dados OLAP do Analysis Services 2000.

  • As partições são migradas, embora os scripts utilizados para criá-las automaticamente sejam migrados para scripts XMLA. As partições usam uma ligação de consulta utilizando a mesma instrução SQL que é emitida pelo Analysis Service 2000 para processar a partição.

  • As funções são migradas com segurança de dimensão e de cubo. O Analysis Services 2005 permite mais tipos de implementações de segurança. Se você quiser implementar qualquer uma das novas opções de segurança, terá de fazê-lo após a migração.

  • Várias dimensões de hierarquia são migradas, mas nem sempre nomeadas da forma desejada. Por exemplo, as dimensões Time.Fiscal e Time.Calendar no Analysis Services 2000 vão provavelmente migrar para Time e Time 1. Se você já tiver uma hierarquia chamada Time, ela migrará para Time TimeDim e TimeDim 1. Isso pode ser confuso. Embora esse não seja o resultado desejado, é muito fácil renomear dimensões.

Depois que o Migration Wizard for concluído, talvez você queira entrar no Business Intelligence Development Studio para examinar os resultados e fazer as modificações necessárias. As tarefas a executar após a migração incluem:

  • Renomear as dimensões de forma que elas se ajustem à sua convenção de nomenclatura.

  • Determinar se todas as hierarquias definidas pelo usuário estão nas dimensões apropriadas. Em alguns casos, o Migration Wizard cria mais dimensões do que é necessário. Talvez você possa consolidar algumas de suas hierarquias definidas pelo usuário e excluir as dimensões adicionais. Isso ajuda a garantir que os novos nomes das dimensões não afetam suas consultas MDX atuais nem causam falhas nas consultas.

  • Dar um nome aos cálculos nomeados. Columnx é o nome aplicado a cada cálculo nomeado que é adicionado ao seu modo de exibição de fonte de dados. Atribua um nome apropriado à coluna.

  • Definir as configurações de drill-through como uma ação de drill-through. Agora, o drill-through é executado como uma ação e terá de ser configurado.

Para renomear uma dimensão no Business Intelligence Development Studio, use o procedimento a seguir.

Para exibir seu novo cubo e renomear uma dimensão

  1. No grupo de programas do SQL Server 2005, abra o Business Intelligence Development Studio.

  2. Ao abrir a ferramenta, você provavelmente começará com a página inicial do Visual Studio.

  3. Para abrir seu cubo, clique em Open no menu File. Clique em Analysis Services Database, como mostrado na Figura 4.

    Figura 4: No Business Intelligence Development Studio, é possível abrir um banco de dados existente do Analysis Services

    Figura 4: No Business Intelligence Development Studio, é possível abrir um banco de dados existente do Analysis Services

  1. É solicitado que você crie um banco de dados (Create a Database) ou abra um existente (Open an Existing Database). Selecione Open an Existing Database e forneça suas informações de instância e de banco de dados.

  2. No Solution Explorer, você deve ver seu banco de dados, bem como uma lista de cubos e dimensões que foram gerados.

  3. Para renomear uma dimensão, clique nela com o botão direito do mouse e clique em Rename. Digite então um novo nome, como mostrado na Figura 5.

    Migration Wizard - Figura 5

    Figura 5: É fácil renomear objetos no Analysis Services 2005

O Migration Wizard não implementa uma série de novos recursos, uma vez que eles não têm um recurso equivalente no Analysis Services 2000. Esses recursos são acessados em guias e caixas de propriedades nas ferramentas administrativas do Analysis Services. Os recursos de alto nível que não são implementados incluem, mas não se limitam a:

  • KPIs (Key Performance Indicators)

  • Conversões

  • Dimensões vários para vários

  • Dimensões de desempenho de papéis

  • Medidas semi-aditivas


Migração no Project REAL

Os cubos e bancos de dados OLAP utilizados no Project REAL foram criados a partir de um novo design. Os assistentes do Analysis Services 2005 foram utilizados como base para o design do cubo. Como processo secundário, com a intenção de comparar resultados, o Migration Wizard foi utilizado contra um conjunto de dados de exemplo da Barnes and Noble Booksellers. Os dados utilizados compartilharam amplamente as dimensões e muitas das dimensões compartilhadas eram virtuais. Depois que o Migration Wizard foi executado, foram feitas as seguintes observações:

  • Todas as dimensões virtuais se basearam em propriedades membros a partir de uma tabela de itens. Na migração, cada uma delas foi mesclada com (ou renomeada como) a dimensão do item. Cada dimensão virtual foi adicionada à dimensão do item como uma hierarquia definida pelo usuário. Cada uma delas foi feita visível por padrão e pode ser referenciada da mesma forma que era antes da migração. Isso aumenta a possibilidade de que as consultas anteriores continuem a funcionar simplesmente com o uso do novo provedor.

  • Um modo de exibição de fonte única dos dados foi criado a partir da fonte única de dados utilizada no Analysis Services 2000. O modo de exibição de fonte de dados representava todas as tabelas utilizadas pela fonte de dados existente.

  • O único cubo virtual foi migrado para um cubo no Analysis Services 2005. Cada cubo de base foi migrado como um grupo separado de medidas: um para Store Sales, um para Store Inventory e um para Distribution Center Inventory.

  • Todas as informações de segurança, inclusive a segurança dos dados e das funções, foram migradas adequadamente.

  • Com exceção da dimensão Time, que foi renomeada como Time.Fiscal e Time.Calendar (como descrito anteriormente, na discussão sobre várias hierarquias), as dimensões não tinham conflitos de nomenclatura. Conseqüentemente, elas tinham no Analysis Services 2005 o mesmo nome que tinham no Analysis Services 2000.

  • No todo, o processo foi rápido, ininterrupto e bem-sucedido ao criar no Analysis Services 2005 os mesmos cubos que existiam no Analysis Services 2000.

  • Nos dados do inventário, usamos as novas medidas semi-aditivas a fim de definir LastNonEmptyChild para todas as medidas de itens em estoque e itens encomendados. Como essa é uma nova funcionalidade no Analysis Services 2005, removemos os cálculos complexos que eram repetidamente utilizados para as sintetizações semi-aditivas.


Migração versus redesign

O Migration Wizard fornece uma boa análise inicial de seus dados nos cubos do Analysis Services 2005. Observe, no entanto, que os cubos criados com o Migration Wizard têm o propósito de duplicar os cubos que você criou no Analysis Services 2000. Esse talvez não seja o resultado desejado. Em alguns casos, será possível simplesmente usar o assistente para migrar e, então, adicionar os recursos desejados. Em outros casos, será melhor refazer o design dos cubos na nova arquitetura. O conjunto de perguntas a seguir ajudará a determinar se o Migration Wizard é um bom ponto de partida ou se você deve refazer o design.

  • Você tem muitos cubos pequenos que são limitados em dimensões e em medidas? Geralmente, os administradores de cubos do Analysis Services 2000 criavam muitos cubos pequenos. Se você usar o assistente, cada um desses cubos será migrado para cubos individuais no Analysis Services 2005. Como no Analysis Services 2005 você não está limitado por questões como o uso da memória, medidas de tabela única de fatos, contagens distintas e propriedades membros, talvez não queira usar muitos cubos pequenos. Talvez seus dados façam mais sentido em um pequeno número de cubos maiores, com perspectivas que forneçam o contexto do usuário. Se você usou muitos cubos para fornecer o contexto do usuário, talvez o melhor seja refazer o design dos cubos no Analysis Services 2005.

  • Há muitas propriedades membros adicionadas às suas dimensões para fins de relatórios? Agora, as colunas podem ser adicionadas como dimensões de atributos para ajudar no layout dos relatórios e na navegação. Não é necessário ter todas as propriedades membros como atributos relacionados. Isso poderia exigir muita limpeza manual após a migração, e talvez seja melhor refazer o design de seus cubos.

  • Você usou dimensões particulares para muitos de seus cubos? As dimensões particulares serão migradas como dimensões. Se você tiver usado muitas dimensões particulares e o mesmo tipo de dimensão para diferentes cubos, perceberá que o sistema vai duplicar essas dimensões como dimensões do Analysis Services 2005. Isso exigirá que você limpe os nomes das dimensões e edite os cubos. Nesse caso, você provavelmente levará em conta um redesign.

  • Você tem muitos membros calculados que agora estão habilitados como medidas? Agora, as medidas têm mais funções agregadas do que podem utilizar. A lista de funções agregadas expandiu-se a partir da lista original de Sum, Count, Distinct Count, Min e Max para incluir Average of Children, None, First Child, Last Child, First Non Empty Child e Last Non Empty Child. Se você tiver criado membros calculados que possam agora ser utilizados como medidas, convém considerar um redesign ou, pelo menos, avaliar a extensão da limpeza após a migração.

  • Você alterou significativamente seu processo de ETL ou criou modos de exibição em seu banco de dados relacional a fim de criar uma fonte única de dados para seu cubo? Se você deseja que seus dados venham naturalmente de várias fontes de dados, talvez seja melhor refazer o design de seus cubos e criar as consultas nomeadas em seus modos de exibição de fonte de dados a fim de carregar os dados.

  • Você teve que lidar com contagens distintas? No Analysis Services 2000, as contagens distintas exigiam muita atenção. Elas eram limitadas a uma por cubo e sugeria-se que a contagem distinta estivesse em seu próprio cubo e fosse combinada com outras medidas em um cubo virtual. Essa restrição não existe mais, e talvez você não fique contente com a alternativa que terá de aplicar.

  • Você está usando muitas dimensões e muitos cubos virtuais? Elas serão migradas para dimensões reais e eles, para cubos reais. Nas dimensões virtuais, é provável que isso não seja o que você quer, porque a coluna pode ser criada facilmente como uma dimensão de atributo. Com os cubos virtuais, é provável que você precise limpar o cubo virtual ou os cubos de base, porque agora os dados foram duplicados. Se parecer que a limpeza será muito extensa, talvez seja melhor refazer o design do cubo.

  • Você gosta do design de seu cubo, mas gostaria de usar os novos recursos fornecidos no Analysis Services 2005? Se você estiver satisfeito com seus cubos e sente que eles funcionarão com as novas exigências de design do Analysis Services 2005, deverá usar o Migration Wizard para mover seus dados para a nova versão. Você poderá, então, adicionar os novos recursos que deseja. Para obter uma lista abrangente dos novos recursos, consulte a documentação do produto.


Conclusão

Com o UDM (Unified Dimensional Model), completa-se a ponte entre os relatórios relacionais e os relatórios OLAP. As novas opções de design que você tem como o Analysis Services 2005 abrem a porta para oportunidades ilimitadas de design e melhoram significativamente a experiência do usuário final com análises e relatórios. O Migration Wizard é uma ferramenta excelente, que pode orientar você ao longo desse caminho. Usando o Migration Wizard, os bancos de dados OLAP podem ser portados muito facilmente para a nova versão, de forma que você possa começar a aproveitar os novos recursos. O Migration Wizard faz o possível para recriar seus cubos atuais no Analysis Services 2005. No final, você talvez decida que as alterações de design são tão significativas que seria preferível começar a partir do zero em vez de usar o Migration Wizard. Para tomar a decisão entre o redesign e o assistente, é melhor avaliar o que você tem no momento e quanto disso deseja alterar no Analysis Services 2005.

Para obter mais informações:
http://www.microsoft.com/sql/


Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
Mostrar:
© 2014 Microsoft