Kimball Star-esquema típico Data Warehouse - Modelo Vistas praticável? e como Código Gen

Question

Eu tenho um armazém de dados contendo esquemas típicos estrela, e um monte de código que faz coisas como esta (obviamente muito maior, mas isso é ilustrativa):

SELECT cdim.x
    ,SUM(fact.y) AS y
    ,dim.z
FROM fact
INNER JOIN conformed_dim AS cdim
    ON cdim.cdim_dim_id = fact.cdim_dim_id
INNER JOIN nonconformed_dim AS dim
    ON dim.ncdim_dim_id = fact.ncdim_dim_id
INNER JOIN date_dim AS ddim
    ON ddim.date_id = fact.date_id
WHERE fact.date_id = @date_id
GROUP BY cdim.x
    ,dim.z

Estou pensando em substituí-lo com uma visão (MODEL_SYSTEM_1, digamos), de modo que torna-se:

SELECT m.x
    ,SUM(m.y) AS y
    ,m.z
FROM MODEL_SYSTEM_1 AS m
WHERE m.date_id = @date_id
GROUP BY m.x
    ,m.z

Mas o MODEL_SYSTEM_1 vista teria que contêm nomes de colunas exclusivas, e estou também preocupado com o desempenho com o otimizador se eu ir em frente e fazer isso, porque eu estou preocupado que todos os itens na cláusula WHERE de factos diferentes e as dimensões se otimizado, desde o ponto de vista seria através de uma estrela todo, e pontos de vista não pode ser parametrizada (menino, isso não seria legal!)

Então, minhas perguntas são -

1. É esta abordagem OK, ou é apenas vai ser uma abstração que prejudica a performance e não dar o meu nada, mas uma sintaxe muito mais agradável?

2. Qual é a melhor maneira de código-gen estes pontos de vista, eliminando nomes de coluna duplicados (mesmo se o ponto de vista mais tarde precisa ser mexido à mão), uma vez que todo o PK e FKs apropriado estão no lugar? Devo apenas escrever alguns SQL para puxá-lo para fora do INFORMATION_SCHEMA ou há um bom exemplo já está disponível.

Editar:. Eu testei, eo desempenho parece o mesmo, mesmo nos processos maiores - mesmo juntar várias estrelas que cada utilização destas vistas

A automação é principalmente porque há um número destas estrelas no armazém de dados, eo FK / PK tem sido feito adequadamente pelos designers, mas eu não quero ter que escolher através de todas as tabelas ou a documentação . Eu escrevi um script para gerar a vista (ele também gera abreviaturas para as tabelas), e funciona bem para gerar o esqueleto automagicamente de INFORMATION_SCHEMA, e então ele pode ser mexido antes de cometer a criação da vista.

Se alguém quiser o código, eu provavelmente poderia publicá-lo aqui.

Answer 1

1. Eu usei esta técnica em vários armazéns de dados que eu cuidar. Eu não tenho notado qualquer degradação do desempenho ao executar relatórios baseados fora dos pontos de vista contra uma abordagem direta mesa, mas nunca realizou uma análise detalhada.

2. Eu criei as exibições usando o designer no estúdio de gerenciamento do SQL Server e não utilizar qualquer abordagem automatizada. Eu não posso imaginar o esquema mudando muitas vezes o suficiente para que automatizar seria útil de qualquer maneira. Você pode gastar o tempo aprimorando os resultados, uma vez que teria tomado para arrastar todas as tabelas para a vista, em primeiro lugar!

Para remover a ambiguidade uma abordagem bem é de prefaciar os nomes de coluna com o nome da dimensão a que pertence. Isso é útil para os geradores de relatórios e para ninguém correr consultas ad hoc.

Answer 2

Faça a vista ou vista para em uma ou mais tabelas de fatos de resumo e materializá-la. Estes só precisam ser atualizados quando a tabela fato principal é atualizado. As visões materializadas será mais rápido para consulta e isso pode ser uma vitória, se você tem um monte de consultas que podem ser satisfeitas pelo resumo.

Você pode usar o dicionário de dados ou esquema de informações vistas para gerar SQL para criar as tabelas se você tem um grande número desses resumos ou desejo de mudar-lhes sobre freqüentemente.

No entanto, eu acho que não é provável que você iria mudar estes, muitas vezes, tão auto-gerar as definições de visualização pode não valer a pena.

Answer 3

Se acontecer de você usar o MS SQL Server, você pode tentar um UDF inline que é tão perto de um parametrizado vista quanto ele ganha.