Transformando o Banco de Dados Relacional OLTP em Modelo de Data Warehousing

Question

Quais são as abordagens de design comuns adotadas no carregamento de dados de um modelo de banco de dados OLTP de relacionamento com entidades relacionadas a um modelo de data warehouse/marts de esquema Kimball?

• Você usa uma área de estadiamento para realizar a transformação e depois carregar no armazém?
• Como você vincula os dados entre o armazém e o banco de dados OLTP?
• Onde/Como você gerencia o processo de transformação - no banco de dados como sprocs, pacotes DTS/SSIS ou SQL do código do aplicativo?

Answer 1

Pessoalmente, eu tendem a trabalhar da seguinte forma:

1. Projete o data warehouse primeiro. Em particular, projete as tabelas necessárias como parte do DW, ignorando quaisquer tabelas de estadiamento.
2. Projete o ETL, usando o SSIS, mas às vezes com os SSIs chamando procedimentos armazenados nos bancos de dados envolvidos.
3. Se alguma tabela de estadiamento for necessária como parte do ETL, é bom, mas, ao mesmo tempo, verifique se eles são limpos. Uma tabela de estadiamento usada apenas como parte de uma única série de etapas de ETL deve ser truncada após a conclusão dessas etapas, com ou sem sucesso.
4. Eu tenho os pacotes SSIS, consulte o banco de dados OLTP pelo menos para puxar dados para as tabelas de estadiamento. Dependendo da situação, eles podem processar as tabelas OLTP diretamente no data warehouse. Todas essas consultas são realizadas com (Nolock).
5. Documento, documento, documento. Deixe claro quais entradas são usadas por cada pacote e para onde a saída vai. Certifique -se de documentar os critérios pelos quais a entrada é selecionada (últimas 24 horas? Desde o último sucesso? Novos valores de identidade? Todas as linhas?)

Isso funcionou bem para mim, embora eu admita que não fiz muitos desses projetos, nem nenhum realmente grande.

Answer 2

Atualmente, estou trabalhando em uma pequena casa de dados de tamanho pequeno/médio. Estamos adotando alguns dos conceitos que Kimball apresenta, ou seja, o esquema de estrelas com tabelas de fatos e dimensões. Nós o estruturamos para que os fatos se juntem apenas às dimensões (não ao fato ou à dimensão da dimensão - mas essa é a nossa escolha, não dizendo que é da maneira que deve ser feita), por isso achatamos todas as juntas de dimensão à tabela de fatos.

Usamos o SSIS para mover os dados do db de produção -> db de origem -> estadiamento db -> relatórios de banco de dados (provavelmente poderíamos ter usado menos DBS, mas é assim que caía).

O SSIS é muito bom, pois permite estruturar seus fluxos de dados muito logicamente. Utilizamos uma combinação de componentes SSIS e Procs armazenados, onde um bom recurso do SSIS é a capacidade de fornecer comandos SQL como uma transformação entre um fluxo de dados de origem/destino. Isso significa que podemos chamar Procs armazenados em todas as linhas, se quisermos, o que pode ser útil (embora um pouco mais lento).

Também estamos usando um novo recurso do SQL Server 2008 chamado Change Data Capture (CDC), que permite auditar todas as alterações em uma tabela (você pode especificar quais colunas deseja olhar nessas tabelas), por isso usamos isso no DB de produção para dizer o que mudou para que possamos mover apenas esses registros para o banco de dados de origem para processamento.

Answer 3

Eu concordo com a resposta altamente classificada, mas pensei em adicionar o seguinte:

* Do you use a staging area to perform the transformation and then

carregar no armazém?

Depende do tipo de transformação se exigirá estadiamento. O estadiamento oferece benefícios de dividir o ETL em pedaços mais gerenciáveis, mas também fornece uma área de trabalho que permite que as manipulações ocorram nos dados sem afetar o armazém. Pode ajudar a ter (pelo menos) algumas pesquisas de dimensão em uma área de preparação que armazenam as teclas do sistema OLTP e a chave do mais recente registro DIM, para usar como uma pesquisa ao carregar seus registros de fatos. A transformação acontece no processo ETL em si, mas pode ou não exigir alguma encenação para ajudá -lo ao longo do caminho.

* How do you link data between the warehouse and the OLTP database?

É útil carregar as chaves de negócios (ou chaves primárias reais, se disponíveis) no data warehouse como uma referência de volta ao sistema OLTP. Além disso, a auditoria no processo DW deve registrar a linhagem de cada bit de dados, gravando o processo de carga que o carregou.

* Where/How do you manage the transformation process - in the

Banco de dados como sprocs, pacotes DTS/SSIS ou SQL do código do aplicativo?

Isso normalmente seria em pacotes SSIS, mas geralmente é mais executado transformar na consulta de origem. Infelizmente, isso torna a consulta de origem bastante complicada de entender e, portanto, manter, portanto, se o desempenho não for um problema, a transformação no código do SSIS é melhor. Quando você faz isso, esse é outro motivo para ter uma área de preparação, pois você pode fazer mais junções na consulta de origem entre tabelas diferentes.

Answer 4

A explicação do processo de John Saunders é uma boa.

Se você deseja implementar um projeto DataWarehouse no SQL Server, encontrará todas as informações necessárias para a entrega de todo o projeto dentro do excelente texto "O Microsoft Data Warehouse Toolkit".

Divertido o suficiente, um dos autores é Ralph Kimball :-)

Answer 5

Você pode querer dar uma olhada em Modelagem de Vault de Dados. Ele afirma resolver alguns problemas solitários, como alterar atributos.