Chaves estrangeiras da tabela de fatos nulas?

Eu sou novo no design de data mart e preciso limpar alguns conceitos.

Eu li um pouco sobre modelagem de dimensões em que vejo que tabelas de fatos armazenam referências de chave estrangeira a tabelas de dimensões.

Agora, suponha que eu tenha uma tabela de dimensões de número de telefone e uma tabela de dimensão de telefone_extensão. (Essas tabelas têm detalhes diferentes, pelo que não posso combiná-las)

Pelo que entendi, ambas as tabelas de dimensão terão chaves primárias inteiras para obter melhor desempenho, e a tabela de fatos terá sua própria chave primária inteira e também armazenará referências de chave estrangeira a essas tabelas de dimensão.

Mas suponha que eu tenha uma situação em que nem todos os números de telefone tenham uma extensão de telefone relacionada a eles. (alguns números de telefone não precisam de extensão)

Para números de telefone que possuem um ramal, a tabela de fatos teria referências de chave estrangeira para ambas as tabelas de dimensão, mas como capturar a situação em que existem apenas números de telefone e nenhum ramal (e vice-versa, ou seja, ramal sem números de telefone) ?

Devo capturar essas informações com o número de telefone FK na tabela de fatos com um valor e uma chave estrangeira phone_extension null ?? Ou esses objetos não relacionados não são registrados nas tabelas de fatos?

Também preciso gerar relatório desse data mart. Então, começo consultando a tabela de fatos e recuperando os valores da chave de dimensão ou relatando diretamente da tabela de dimensões?

Obrigado pelo seu tempo lendo isso!
Aprecio qualquer ajuda !!

Você pode deixar o FK para algumas tabelas de dimensões como NULL se essas dimensões não forem conhecidas ou não forem aplicáveis. Você só precisa se lembrar de usar junções externas ao fazer sua consulta de relatórios.

Como alternativa, algumas pessoas criam um registro de dimensão "none" e / ou "n / a" para dimensões do data mart e, em seguida, preenchem os FKs da tabela de fatos para apontar para eles em vez de usar NULLs. As pessoas que fazem isso gostam dessa abordagem porque têm aversão a junções externas.

Pessoas que usam NK FKs em tabelas de fatos geralmente têm aversão a pessoas que possuem uma versão para junções externas. ;) (em outras palavras, essa é uma questão estilística que pode gerar guerras religiosas)

Eu digo: faça o que você preferir, mas escolha uma abordagem e a cumpra com fervor.

Não coloque nulos no Warehouse ou nos Marts.

O armazém deve estar bem normalizado (pelo menos BCNF) e, portanto, deve excluir nulos. Nulos podem ser preservados nas tabelas de preparação, se existirem em fontes de dados, mas não devem ser necessários no próprio armazém.

Marts devem ser projetados para suportar ferramentas de apresentação e consultas de usuários. Os nulos atrapalham essas coisas porque nunca são exibidos e tornam as consultas do usuário mais complexas e propensas a erros - especialmente em colunas de chave estrangeira que frequentemente estão sujeitas a junções.

as chaves de dimensão nos fatos não devem ser nulas e devem ter fk para as dimensões para eliminar a necessidade de junções externas esquerdas pelos usuários finais, relatórios etc. Todas as cargas de fatos devem fazer uma junção externa esquerda na dimensão e usar como padrão uma chave 0 nenhuma chave e falhar. É melhor falhar do que fazer uma junção à dimensão e não ter ideia de que você perdeu linhas em seu fato, até que alguns usuários finalmente a encontrem (se isso acontecer)

crie um registro "n / a" na dimensão phone_extension e vincule-o.

minha regra de themb é o único valor anulável em um datamart final dwh é o fato em si, de modo que funções agregadas como avg ainda funcionam.