Configurando Dim e tabelas de fato para um Data Warehouse

Question

Eu estou encarregado de criar um datawarehouse para um cliente. As tabelas envolvidas realmente não seguir os exemplos tradicionais lá fora (produtos / encomendas), então eu preciso de alguma ajuda para começar. O cliente é essencialmente um centro de processamento de casos (similar a um caso legal). Cada dia, novos casos são inseridos no DB sob a mesa de "casos". Cada coluna contém alguns pouco de informação relacionada com o caso. Como o caso está sendo processado, tabelas adicionais de um-para-muitos são preenchidos com eventos relacionados com o caso. Existem muito poucos destes tabelas de eventos, tabelas de exemplo pode ser: (, caso dept1, caso DEPT2, caso dept3 caso aberto, etc.). Cada uma dessas tabelas tem uma caseid que mapeia volta à mesa de "casos". Há também algumas tabelas de pesquisa envolvidos.

Atualmente, as necessidades de relatórios referem-se a expor os gargalos nas várias fases e a granularidade está no nível hora para certas áreas do processo.

Eu posso estar pedindo muito aqui, mas eu estou procurando alguma orientação de como eu deve configurar minhas tabelas Dim e fato ou alguma outra sugestão que possa ter.

Answer 1

Eu sugiro que você confira os livros de Kimball, particularmente esta , que deve ter alguns exemplos para você pensar sobre aplicações para o domínio do problema.

Em qualquer caso, você precisa decidir se um modelo dimensional é ainda apropriada. É perfeitamente possível para tratar um banco de dados 'Enterprise Data Warehouse' 3NF com diferentes índices ou resumos, ou o que quer.

Sem ver o seu esquema atual, é realmente difícil de dizer. Parece que você vai acabar com vários modelos de estrelas, com algumas dimensões conformadas amarrá-los juntos. Então você pode ter uma dimensão caso como uma das suas dimensões conformadas. Os fatos de cada outra mesa estaria em tabelas de fatos que ligam tanto para a dimensão conformado e quaisquer outras dimensões apropriadas para os fatos, assim, por exemplo, se há uma identificação do empregado em caso de abertura, que ligaria a um empregado dimensão conformado , da tabela caso open-fato. Esta dimensão conformado pode ser ligado várias vezes de várias de suas tabelas de fatos subsidiárias.

método de modelagem de Kimball é bastante simples, e pode ser seguido como uma receita. Você precisa começar por identificar todos os seus fatos, agrupando-os em tabelas de fatos, identificando dimensões individuais em cada tabela de fatos e, em seguida, agrupando-os conforme apropriado para tabelas de dimensões, e identificar o tipo de cada dimensão.

Answer 2

A tabela de fatos é o evento caso e é 'sem factos' na medida em que não tem nenhum valor numérico. As dimensões seria hora, tipo de evento, caso e talvez alguns outros, dependendo do que outros dados estão no sistema.

Você precisa consolidar as tabelas de eventos em uma única tabela fato, marcados com uma dimensão 'tipo de evento'. Os relatórios de transferência / gargalo está calculando as diferenças entre os tempos de eventos para combinações específicas de tipos de eventos em um determinado caso.

Os relatórios devem calcular os tempos evento de eventos e possivelmente bin-los em um histograma. Você também pode rotular certos tipos de combinações de eventos e aplicar o rótulo para os eventos de interesse. Estes eventos poderia então ter o tempo registrado contra eles, o que permitiria operações fatia-e-dados sobre os tempos com uma ferramenta de OLAP.

Se você quiser de referência determinadas fases na progressão do ciclo de vida que você tem uma tabela que vai tipo de caso, type1, evento de tipo 2, o tempo de referência.

Com um pouco de massagem, você pode ser capaz de usar um kit de ferramentas de mineração de dados ou até mesmo uma análise de regressão simples de detectar correlações entre atributos de casos e tempos evento de eventos (YMMV).

Answer 3

Como qualquer outra faceta de desenvolvimento, você deve abordar o problema das exigências finais ( "histórias de usuários" se você quiser) para trás. A abordagem mais conservadora para um armazém é simplesmente representar uma cópia do banco de dados de transação. De lá, orientado pelos requisitos, determinadas otimizações podem ser feitas para melhorar o desempenho de determinados padrões de acesso de dados. Eu acredito que é importante, no entanto, para ver estes como otimizações e não assumir que um armazém de dados automaticamente deve ser uma explosão complexa de todas as dimensões possíveis sobre cada fato. Minha experiência é que na maioria dos casos, uma representação reta é ideal adequada ou mesmo para 90 +% de consultas analíticas. Para o restante, considere primeiro índices, exibições indexadas, estatísticas adicionais, ou outras otimizações que podem ser feitas sem afetar as estruturas. Então, se as estruturas de agregação ou outro redundantes são necessários para melhorar o desempenho, considerar separar estes em um "Mart dados" (pelo menos conceitualmente) que proporciona uma separação entre os fatos primitivas e redundâncias destes. Finalmente, se os requisitos são muito fluidos e a agregação exige pesado para funcionar de forma eficiente desta maneira, então você pode considerar explosões atacado de dados ou seja esquema em estrela. Novamente, porém, limitar esta para o menor seção transversal dos dados possível.

Answer 4

Aqui está o que eu vim com essencialmente. Thx NXC

Fato Eventos

EventID TimeKey CaseID

Dim Eventos

EventID EventDesc

Dim Tempo

TimeKey

Dim Regiões

regionId RegionDesc

casos

CaseID RegionId

Answer 5

Este pode ser um caso de escolher uma solução antes que você tenha considerado o problema. Nem todos os datawarehouses se encaixar no modelo de esquema em estrela. Não vejo que você está agregando todos os dados aqui. Até agora, temos uma tabela sem factos facto e pelo menos uma rápida mudança de dimensão (casos).

Olhando para o que eu vejo até agora eu acho que a entidade central neste banco de dados deve ser o caso. Tentando manter o evento no meio não parece certo. Tente olhar para ele de forma diferente. Talvez, caso, eventos e eventos de caso para começar.