Sou bastante novo em design de DW e estou trabalhando em um DW para modelar algumas infraestruturas de TI.
O principal problema/questão neste ponto é como modelar as informações do drive.
Coletaremos dados agregados em arquivos e pastas e dados separados em unidades físicas. As informações da unidade incluirão o espaço total e livre no mínimo e serão atualizadas várias vezes por semana.
Uma das questões de negócios que precisarão ser respondidas é como o uso do drive está evoluindo ao longo do tempo. As informações da unidade também serão usadas em uma hierarquia que leva até o nível de arquivo/pasta.
As opções que vejo agora são:
Implementar
DRIVEcomo uma dimensão- Simplifica o design da hierarquia
- Isso causará problemas com relatórios? Parece contra-intuitivo para mim relatar dados com limite de tempo apenas em uma dimensão
- Também parece problemático ter uma dimensão que você SABE que mudará toda vez que atualizar seus dados
Implementar
DRIVEcomo uma tabela de fatos- Simplifica os relatórios
- Hierarquia complicada (?) - também usarei
Drivepara mapear os dados de volta para um servidor ou computador específico. É correto usar uma tabela de fatos como um nível intermediário em uma hierarquia? Eu não acho que é.
Implemente
DRIVEcomo um fato e uma dimensão- O fato conterá apenas a chave, a data e os fatos no espaço
- O Dimension incluirá outros dados não aditivos, como o computador em que está, etc.
- Parece resolver os dois problemas, mas isso é um antipadrão?
Espero ter uma tabela de fatos drive_usage com um link para uma dimensão de tempo instantâneo, uma dimensão de unidade, uma dimensão de computador e os vários fatos numéricos sobre a unidade naquele instante no tempo.
Provavelmente não deve haver nada mudando regularmente na dimensão da unidade - acho que depende da sua definição de unidade - é uma unidade física ou uma unidade lógica ou o quê. Talvez sua unidade "C" tenha um número de série e seja substituída - então a dimensão expirará e uma nova dimensão será adicionada. Essas coisas sobre uma dimensão não são realmente "fatos", são atributos. Isso não afetaria os relatórios porque os dados do computador X, unidade C, têm continuidade. Da mesma forma, se o computador X for atualizado de dual core para quad core e, portanto, houver uma alteração na dimensão (supondo que algo além do número de núcleos não seja rastreado em uma tabela de fatos, como uma revisão da placa-mãe). A capacidade de uma unidade estaria na tabela de fatos, portanto, as alterações ao longo do tempo são apenas novos fatos com novas datas. Às vezes, você pode até mesmo modelar mudanças na associação como fatos. ou seja, se as unidades físicas 1-5 estiverem na unidade lógica C em um dia e as unidades físicas 1-6 estiverem na unidade lógica C no dia seguinte, isso pode ser apenas uma alteração de fato na tabela de fatos de associação da unidade física. Isso é o que algumas pessoas chamam de tabelas de fatos sem fatos, já que o único fato é que a existência da linha mostra associação - não há muito a ser feito, exceto totalizar ou contar.
Quando você entra em pastas, modelar a hierarquia pode ser muito mais complicado dependendo do que você está tentando alcançar com rollups.
Há muita arte na modelagem DW em domínios que não são cenários comuns.