Tabela Fato

Tabelas Fato são tabelas para armazenamento de medidas. A maioria das medidas armazenadas em Tabelas Fato dizem respeito a séries temporais, em que são armazenados timestamps e chaves estrangeiras conectando a dimensões de data calendário.

Cada linha em uma Tabela Fato corresponde a um evento de medição. A ideia de que um evento de medição no mundo físico tem um relacionamento de um para um com uma única linha na tabela de fatos correspondente é um princípio fundamental para a modelagem dimensional. Todo o resto é construído a partir dessa premissa (KIMBALL e ROSS, 2013).

Tabelas Fato são a figura central de qualquer modelo dimensional. Toda Tabela Fato deve possuir uma única e explícita granularidade definida. A granularidade de uma Tabela Fato deve ser definida durante o processo de modelagem. Kimball e Ross (2010) recomendam que a definição da granularidade (explicitar exatamente o que uma Tabela Fato representa) seja a primeira ação a ser realizada na modelagem de uma Tabela Fato. Podem ser feitas declarações atômicas ou de alto nível, representando agrupamentos e sumarizações. Após definir a granularidade, deve-se então definir precisamente as dimensões possíveis associadas.

Kimball e Ross (2010) recomendam que os detalhes mais atômicos disponíveis nos sistemas de origem devem ser refletidos no DW por meio de Tabelas Fato. Um registro fato (fact record) em um modelo dimensional é criado como uma resposta 1:1 para a medida de um evento em um processo de negócio específico. Tabelas Fato são definidas pela física do mundo real.

Os fatos de uma Tabela Fato devem ser “Verídicos à Granularidade”. Por exemplo, os seguintes fatos são exemplos apropriados para a declaração "line item of a doctor’s bill”:

• • Date (of treatment)
  • Doctor (or provider)
  • Patient
  • Procedure
  • Primary Diagnosis
  • Location (such as the doctor’s office)
  • Billing Organization (an organization the doctor belongs to)
  • Responsible Party (either the patient or the patient’s legal guardian)
  • Primary Payer (often an insurance plan)
  • Secondary Payer (maybe the responsible party’s spouse’s insurance plan)

Outros fatos, como “Valor cobrado no ano até a data corrente para o paciente para todos os tratamentos” não são Verídicos. Neste caso, quando aplicações de BI combinam registros de fato arbitrariamente, estes Fatos Inverídicos produzem resultados sem sentido e inúteis. Olhando desta maneira, este tipo de fato é perigoso pois induz usuários de negócio a erros. Este tipo de fato agregado deve ser omitido do design do DW e calculado diretamente na aplicação de BI (KIMBALL e ROSS, 2013).

Como os dados de medição são esmagadoramente o maior conjunto de dados, eles não devem ser replicados em vários locais para várias funções organizacionais na organização. Permitir que usuários de negócios de várias organizações acessem um único repositório centralizado para cada conjunto de dados garante o uso de dados consistentes em toda a empresa (KIMBALL e ROSS, 2013).

É teoricamente possível que um fato medido seja textual; no entanto, a condição raramente surge. Na maioria dos casos, uma medida textual é uma descrição de algo e é extraída de uma lista discreta de valores. O designer deve fazer todos os esforços para colocar os dados textuais em dimensões onde possam ser correlacionados de forma mais eficaz com os outros atributos de dimensão textual. Você não deve armazenar informações textuais redundantes em tabelas de fatos. A menos que o texto seja exclusivo para cada linha na tabela de fatos, ele pertence à tabela de dimensão. Um fato de texto verdadeiro é raro porque o conteúdo imprevisível de um fato de texto, como um comentário de texto de forma livre, torna-o quase impossível de ser analisado (KIMBALL e ROSS, 2013).

Tabelas Fato correspondem a medidas resultantes de eventos observáveis, e não a demandas de relatórios específicos (KIMBALL e ROSS, 2013).