Examinei toda a lista de sites e acho que esta é a melhor correspondência. Não se trata realmente de administração de banco de dados, mas sim de design de banco de dados. Por favor, desculpe-me e me aponte para o site correto.
Estou projetando um banco de dados para um sistema de BI rudimentar. Neste momento, bati em uma parede, que é esta (explicando usando dados fictícios):
Suponha que minha tabela de fatos contenha esta informação:
John Doe flew from LAX to ATL on 1 Nov in flight AB-123
As dimensões e seus atributos são:
- Folheto - nome, clube
- Aeroporto - cidade, código
- Data - ano, mês, data
- Voo - código, padrão, atraso, preço
Agora, a partir disso, posso gerar facilmente um relatório como este:
Airport --> LAX DFW ORD ATL Total
Gold 50 40 10 25 125
Silver 240 300 95 140 775
Bronze 1000 1500 800 1800 5100
Total 1290 1840 905 1965 6000
Usando uma consulta como:
select fd.club, ad.code, count(f1.id) from flyer fd, airport ad, fact1 f1
where fd.id = f1.fid and ad.id = f1.aid and month(f1.date) = 10
group by f1.club, ad.code;
Mas meu problema vem do fato de que o status de "clube" de um aviador é um alvo em movimento. Um aviador que está em Ouro hoje poderia estar em Prata em outubro, então estou contando com ele no grupo incorreto aqui. Assim, imagino que preciso de uma tabela de fatos separada como esta:
John Doe entered Bronze club on 8/15
John Doe entered Silver club on 10/20
...
"Clube" é descartado como um atributo da dimensão original do flyer. Em vez disso, surge uma nova dimensão de clube.
E então, para gerar o relatório de que preciso, uno essas duas tabelas de fatos.
Estou no caminho certo? Ou existe uma solução alternativa e mais simples para isso? Uma alternativa que eu poderia pensar é incluir o clube na tabela de fatos original, lidando com isso durante o processo ETL. Então o fato se torna:
John Doe of Silver Club flew from LAX to ATL on 1 Nov in flight AB-123
Por favor, deixe-me saber qual abordagem é melhor ou se existe uma terceira.
A maneira de fazer isso é o que Kimball chamou de dimensão Tipo-2 ou Tipo-6 que muda lentamente. . Essencialmente, um SCD tipo 2 tem uma chave de dimensão sintética e uma chave exclusiva que consiste na chave natural da entidade subjacente (neste caso, o flyer) e uma data 'efetiva a partir de'. A chave sintética é unida à tabela de fatos, então você pode anexá-la com uma simples junção de equivalência (ou seja, você não precisa filtrar por intervalo de datas na consulta).
Todos os atributos (por exemplo, clube neste caso) são atributos do flyer. Se um desses atributos for alterado, uma nova linha será criada na dimensão registrando o novo estado, a partir da data da alteração.
O tipo-6 é como um tipo 2 comum, mas possui uma autojunção à versão atual da linha. Sempre que uma nova linha é criada para uma determinada chave natural, todas as linhas dessa chave natural são atualizadas com a autojunção para a linha atual. Você pode ou não precisar dessa funcionalidade.
Você pode consultar um status atual juntando as tabelas de fatos com a linha que foi registrada nelas - ou seja, o estado atual. Se você tiver um tipo-6, o status atual pode ser consultado por meio da autojunção, que também pode ser materializada na tabela de fatos, se desejado.
Esses dados também funcionarão bem com cubos e ferramentas de relatórios ad hoc, embora a implementação de hierarquias de cubo complexas em uma dimensão que muda lentamente seja um pouco complicada (você precisa manter espaços reservados para as chaves naturais dos níveis de hierarquia e combinações ao longo do tempo).
Um bom ponto para começar seria uma pesquisa no Google sobre "dimensão de mudança lenta do tipo 2"
Eu manteria uma tabela separada com
FlyerName, FlyerClub, StartDate, EndDateDessa forma, você acompanha as mudanças ao longo do tempo e pode saber a qualquer momento em que clube alguém estava.
O registro atual teria um
EndDatedeNULL.Em um datamart, você precisa desnormalizar atributos de variantes de tempo para sua tabela de fatos.
Seu banco de dados de origem transacional terá o nível do clube do flyer na tabela do flyer, ou possivelmente em uma tabela de histórico datada relacionada ao flyer conforme sugerido pelo JNK.
No seu datamart, você precisa aplicar o nível atual do clube de cada passageiro em particular ao registro de fato que reúne passageiro, voo, data, (etc)
No seu caso, o clube é uma propriedade variante de tempo do flyer, mas o fato que lhe interessa é a combinação de um flyer e um voo. Portanto, você precisa registrar o FlyerClub na transação do voo (tabela de fatos). Isso funcionará, desde que você não deixe os passageiros mudarem de clube no meio do voo.