Qual é a melhor abordagem para obter do banco de dados OLTP relacional para cubo OLAP?

Question

Eu tenho um banco de dados bastante normal OLTP normalizado e eu percebi que eu preciso fazer algumas consultas complexas, médias, desvios-padrão em diferentes dimensões nos dados.

Então eu giraram para SSAS ea criação de cubos OLAP.

No entanto, para criar os cubos Acredito que minha estrutura fonte de dados precisa estar em uma 'estrela' ou 'floco de neve' de configuração (que eu não acho que é agora).

É o procedimento normal para usar o SSIS para fazer algum tipo de processo ETL no meu principal OLTP DB em um outro banco de dados relacional que está na configuração adequada 'estrela' com fatos e dimensões, e, em seguida, usar esse DB como a fonte de dados para a cubos OLAP?

Graças

Answer 1

Sim, essa é a idéia básica. Você toma seu banco de dados OLTP altamente normalizado e de-normalize-o em cubos com a finalidade de fatiamento dos dados e, em seguida, apresentar relatórios sobre ele. A técnica de design lógico é chamado de modelagem dimensional. Há uma tonelada de grande informação sobre modelagem dimensional sobre a Grupo Kimball . Ralph Kimball é livros sobre o assunto também são excelentes. Se você quiser saber mais sobre as ferramentas de BI-se, confira os laboratórios virtuais no SSIS, serviços de análise e muito mais.

Answer 2

A resposta é: Sim., Mas

Uma dimensão em SSAS tem relações entre os atributos que podem ser utilizados um de uma série de campos para filtro de fatia por. Essas relações podem ser hierárquicas (mais de um nível de profundidade - um atributo pode ter um pai e as crianças Você também pode estabelecer broca por caminhos (chamados hierarquias no SSAS) que agem como atributos, mas têm um detalhamento guiada

..

Para fazer isso você precisa ter chaves disponíveis no banco de dados que vivem em uma relação estritamente hierárquica (isto é, as chaves não podem ter relações nebulosas onde uma criança pode ter mais de um pai). Note-se que esta não é toda a história, mas é perto o suficiente da realidade para o momento.

Estas hierarquias podem ser construídos a partir de uma estrutura de dados plano pelo sistema ou apresentados através de um floco de neve com relações marcadas-se na vista de fonte de dados subjacente (DSVs são uma parte dos metadados de cubo e pode ser usado para massagem dados de uma maneira semelhante à vista de banco de dados).

Um floco de neve é ??um esquema 3NF-ish (não estritamente tem que ser 3NF - você pode achatar partes dele na prática) que só tem 1: relações M. SSAS pode suportar algumas outras estruturas de dimensão, como pai-filho (relação pai-filho com um recursivo auto-join) e M: dimensões M (M: M relacionamentos - exatamente o que eles soam como). Dimensões deste tipo são mais complicadas, mas pode ser útil.

Se você tem as chaves em seus dados de origem que podem ter semântica de dados equivalente a um floco de neve, então você pode ser capaz de preencher seu cubo através de uma série de pontos de vista de banco de dados em seu sistema de origem que apresentam os dados subjacentes em uma suficientemente floco-like formato a utilizar para dimensões do cubo (I realmente fizeram isso em um par de ocasiões). Esquemas que fazem uso pesado de chaves sintéticos são mais propensos a trabalhar bem para isso.

Se o seu fornecedor ou outras partes não vai deixar você adicionar vistas para seu banco de dados de origem que você pode ser capaz de usar uma exibição de fonte de dados em vez disso. DSV de pode ter tabelas virtuais chamadas 'consultas nomeadas' que são preenchidos a partir de uma consulta de banco de dados.

As tabelas de fatos juntar-se às dimensões. Em SSAS2005 + você pode juntar diferentes tabelas de fatos em diferentes grãos dentro de uma dimensão. Eu normalmente não teriam muita utilidade para isso em um armazém de dados, mas esse recurso pode ser útil se você está tentando usar os dados de origem, sem ter a massageá-lo excessivamente.

Se isto não funcionar, então você pode muito bem ter que escrever um processo de ETL para preencher um esquema em estrela ou floco de neve.

Algumas ressalvas:

1. Cubes pode ser feito para ser executado em um modo em tempo real, onde eles simplesmente emitir uma consulta para os dados subjacentes. Isto tem algum risco de criar consultas ineficientes contra seus dados de origem, por isso não é recomendado a menos que você está realmente confiante de que sabe o que está fazendo.

2. A propósito de (i), você provavelmente não será capaz de usar os cubos como uma fonte de dados para as telas em seu aplicativo. Se você precisa médias calcular por algo que o usuário quer ver em uma tela, você provavelmente terá para calculá-lo em um procedimento armazenado por trás da tela.

3. Se você fizer isso, criar um banco de dados replicado e preencher o cubo off isso. Ter esta base de dados periodicamente atualizar, para que o seu processo de ETL pode ser executado a partir de um conjunto de dados internamente consistente. Se você executar a partir de um banco de dados ao vivo, corre o risco de alguns dos itens que estão sendo povoada, mais tarde, que dependem de registros que foram criados após o processo correspondente foi executado.
   Você pode ter a situação em que você executa uma carga de dimensão, e, em seguida, os novos dados são inseridos no sistema. Quando a carga tabela facto é executado, ele contém agora dados que depende dos dados de dimensão que não tenha sido carregados. Isso vai quebrar o cubo e fazer com que o processo de carregamento falhar. Batch atualizar um banco de dados replicado para executar os ETL ou cubo cargas off irá atenuar este problema.
   Se você não tem o optiem um banco de dados replicado você pode configurar mais políticas de folga para os dados em falta.

4. Se os dados de produção subjacente tem problemas significativos de qualidade de dados que serão refletidos nos cubos. GIGO.