Questão de Banco de Dados — Banco de Dados Multidimensionais — FGV 2024

Dimensões Multivaloradas e Tabelas Ponte (Bridge Tables)

Gabarito: letra A. Quando uma tabela fato se relaciona com múltiplos valores de uma dimensão — como uma empresa que pode ter vários fundadores —, a técnica de modelagem multidimensional adequada é a Tabela Ponte (Bridge Table), que desassocia a dimensão da tabela fato, permitindo que cada fato seja associado a um conjunto variável de membros da dimensão. As demais alternativas tratam de outros problemas de modelagem dimensional, como veremos a seguir.

A modelagem multidimensional é a base dos data warehouses e sistemas OLAP, organizando os dados em tabelas fato (que armazenam as medidas quantitativas, como valores e quantidades) e tabelas dimensão (que fornecem o contexto descritivo, como produto, tempo e cliente). No modelo estrela clássico, cada tabela dimensão se relaciona com a tabela fato por uma relação 1:N — ou seja, cada registro da dimensão pode estar associado a vários fatos, mas cada fato está ligado a um único registro de cada dimensão. Esse é o padrão esperado: uma venda (fato) tem um único produto, uma única loja e um único momento no tempo.

O problema surge quando essa premissa é quebrada: e se um único fato precisar se relacionar com vários registros de uma mesma dimensão? É exatamente o caso do enunciado: a tabela FATO FUNDAÇÃO EMPRESAS se relaciona com múltiplos valores da DIMENSÃO FUNDADOR — uma empresa pode ter sido fundada por mais de uma pessoa. Se simplesmente colocássemos uma chave estrangeira para a dimensão na tabela fato, só conseguiríamos armazenar um fundador por empresa. Se, por outro lado, criássemos uma relação muitos-para-muitos direta, violaríamos o princípio da granularidade da tabela fato, que deve ter um nível único de detalhe.

A solução clássica, proposta por Ralph Kimball, é a Tabela Ponte (Bridge Table). Ela atua como uma tabela intermediária entre a tabela fato e a dimensão multivalorada, contendo as chaves dos fatos e as chaves dos múltiplos membros da dimensão associados a cada fato. No nosso exemplo, teríamos uma tabela ponte com as colunas id_empresa e id_fundador, permitindo que uma empresa apareça em várias linhas, uma para cada fundador. Isso preserva a granularidade da tabela fato (cada linha continua representando uma fundação) e resolve a multivaloração sem duplicar os fatos.

Vale destacar que a tabela ponte também pode incluir um fator de ponderação (weight factor), usado para distribuir corretamente as medidas da tabela fato entre os múltiplos membros da dimensão. Por exemplo, se uma empresa tem dois fundadores e queremos analisar o capital investido por fundador, a tabela ponte pode indicar que cada um tem peso 0,5, evitando que o valor total seja contado duas vezes em agregações.

A distinção entre as técnicas é o ponto central da questão. Enquanto a tabela ponte resolve o problema de multivaloração (um fato com vários membros de uma dimensão), as outras alternativas tratam de problemas distintos: a tabela fato sem fatos lida com a ausência de medidas; a dimensão degenerada trata de atributos descritivos que ficam na própria tabela fato; a dimensão floco de neve trata da normalização da dimensão; e a dimensão de múltiplos papéis trata de uma mesma dimensão usada com diferentes significados. Guarde essa fronteira: é exatamente nela que as alternativas se dividem.

Alternativa A — ✅ Correta ⟵ GABARITO

A Tabela Ponte (Bridge Table) é a técnica correta para implementar uma dimensão multivalorada. Ela cria uma tabela intermediária entre a tabela fato e a dimensão, permitindo que um único fato seja associado a múltiplos membros da dimensão, como uma empresa com vários fundadores. Essa abordagem preserva a granularidade da tabela fato e evita a duplicação de medidas.

Alternativa B — ❌ Incorreta

A Tabela Fato sem Fatos (Factless Fact Tables) é utilizada quando se deseja registrar a ocorrência de um evento sem uma medida numérica associada — por exemplo, registrar quais produtos foram vendidos em quais lojas em quais dias, sem valores. Ela não resolve o problema de uma dimensão com múltiplos valores por fato; trata-se de uma tabela fato que contém apenas as chaves das dimensões, sem medidas.

Alternativa C — ❌ Incorreta

A Dimensão Degenerada (Degenerate Dimension) é um atributo descritivo que permanece na própria tabela fato, sem uma tabela de dimensão separada — como o número de um pedido ou uma nota fiscal. Ela não tem relação com a multivaloração de uma dimensão; é apenas um campo de texto ou código que não justifica uma tabela própria.

Alternativa D — ❌ Incorreta

A Dimensão Floco de Neve (Snowflaked Dimension) é uma técnica de normalização da dimensão, na qual atributos de baixa cardinalidade são movidos para tabelas separadas, ligadas à dimensão original por chaves artificiais. Ela trata da estrutura interna da dimensão, não da relação entre a dimensão e a tabela fato. No caso do enunciado, o problema não é a normalização da dimensão Fundador, mas sim a relação muitos-para-muitos entre fato e dimensão.

Alternativa E — ❌ Incorreta

A Dimensão que Desempenha Múltiplos Papéis (Role-Playing Dimension) é uma única tabela de dimensão que é referenciada várias vezes pela mesma tabela fato, com diferentes significados — por exemplo, a dimensão Data usada como Data_Pedido, Data_Entrega e Data_Postagem. Ela não resolve a multivaloração; trata-se de reutilizar a mesma dimensão em diferentes contextos dentro do mesmo fato.

Gabarito: letra A — a Tabela Ponte é a técnica que resolve a dimensão multivalorada, permitindo que um fato se associe a múltiplos membros de uma dimensão.