Chaves Dimensionais

Se fatos são medidas reais geradas rapidamente, concluímos que Tabelas Fato criam uma situação de relacionamento muitos-para-muitos (M:N) entre as dimensões. Muitos clientes compram muitos produtos em diversas lojas em diversos momentos (KIMBALL e ROSS, 2010).

Deste modo, modelamos as medidas como Tabelas Fato com diversas chaves estrangeiras (Foreign Key - FK), referenciando as entidades de contexto (dimensões). E as tabelas de dimensões (entidades de contexto) possuem, cada uma, a sua chave primária (Primary Key - PK) (KIMBALL e ROSS, 2010).

Uma Tabela Fato em um modelo dimensional Star Schema é constituída, além das medidas, por múltiplas FKs, cada uma pareada com a chave primária em uma dimensão. Note que este design possibilita às tabelas de dimensão possuírem chaves primárias não existentes na Tabela Fato. Esta situação é consistente com a manutenção da integridade referencial e apropriada para a modelagem dimensional (KIMBALL e ROSS, 2010).

No mundo real, existem diversas razões convincentes para a construção de pares FK-PK como chaves substitutas (Surrogate Keys), que são apenas números inteiros sequenciais. É um grande erro definir chaves em um DW com base em chaves naturais (Natural Keys), provenientes das fontes operacionais (KIMBALL e ROSS, 2010).

Ocasionalmente, uma medida perfeitamente válida poderá envolver alguma dimensão ausente. Talvez, em algumas situações, um produto poderá ser vendido a um cliente por meio de uma transação sem uma loja definida. Neste caso, ao invés de armazenarmos null na FK de loja, podemos manter um registro especial na dimensão loja, com o valor “No Store”, e utilizá-lo para esta finalidade, por exemplo (KIMBALL e ROSS, 2010).

Logicamente, uma Tabela Fato não precisa de uma chave primária. Dependendo da situação, duas observações legítimas poderão ser representadas de forma idêntica na Tabela Fato. Da perspectiva prática, esta é uma ideia terrível, pois teremos muita dificuldade em separar tais registros por meio da utilização de instruções SQL. Será difícil verificar a qualidade dos dados se diversos registros forem representados de forma idêntica em nossa Tabela Fato (KIMBALL e ROSS, 2010).