Pular para o conteúdo principal

Questão de Banco de Dados — DW - Data Warehouse — VUNESP 2026

Banco de DadosDW - Data Warehouse
Código
gp018322
Banca
VUNESP
Órgão
UNESP
Ano
2026
Cargo
V - - Analista de Informática I - Área de Atuação: Desenvolvimento de Sistemas - São Paulo
Considerando o modelo dimensional de dados utilizado para modelar um data warehouse, uma característica normalmente presente nas tabelas dimensão desse modelo é que tais tabelas
  1. Anão podem possuir mais do que dez atributos cadauma delas.
  2. Bnão são fisicamente armazenadas no data warehouse.
  3. Cnão necessitam utilizar uma chave primária.
  4. Dnão sofrem o processo de normalização.
  5. Edevem possuir um número mínimo de valores nulosentre seus registros.
Revelar gabarito e comentário

GabaritoD — não sofrem o processo de normalização.

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

Modelo dimensional e tabelas dimensão no Data Warehouse

Gabarito: letra D. No modelo dimensional de um data warehouse, as tabelas dimensão não sofrem o processo de normalização — elas são deliberadamente desnormalizadas para otimizar o desempenho das consultas analíticas, reduzindo o número de junções (joins) necessárias. Essa é a característica central que distingue a modelagem dimensional da modelagem relacional tradicional, e é exatamente o que a alternativa D afirma.

O modelo dimensional é a técnica de modelagem de dados usada em data warehouses para apoiar a tomada de decisão. Ele organiza os dados em duas categorias principais de tabelas: tabelas fato e tabelas dimensão. As tabelas fato armazenam as medidas quantitativas do negócio (como valores de venda, quantidades, lucros) e as chaves estrangeiras que as conectam às dimensões. As tabelas dimensão, por sua vez, armazenam os atributos descritivos que qualificam essas medidas — por exemplo, a dimensão "Produto" contém nome, categoria, marca; a dimensão "Tempo" contém ano, mês, dia; a dimensão "Loja" contém cidade, região, gerente.

A razão de ser da desnormalização nas dimensões é o desempenho. Em um ambiente transacional (OLTP), a normalização é aplicada para evitar redundância e anomalias de atualização. Já em um ambiente analítico (OLAP), o foco é a leitura e agregação de grandes volumes de dados. Se as dimensões fossem normalizadas em várias tabelas (como no esquema floco de neve), cada consulta exigiria múltiplas junções, tornando a análise lenta. Ao desnormalizar — ou seja, manter os atributos descritivos em uma única tabela dimensão —, o modelo estrela permite que uma consulta analítica seja respondida com uma única junção entre a tabela fato e cada dimensão. É um trade-off consciente: aceita-se redundância em troca de velocidade de consulta.

Um exemplo concreto: imagine um data warehouse de vendas com a tabela fato FATO_VENDAS (contendo valor, quantidade e as chaves de DIM_TEMPO, DIM_PRODUTO, DIM_LOJA). A dimensão DIM_PRODUTO pode ter os atributos id_produto, nome, categoria, marca, fornecedor. Em um modelo normalizado, categoria e fornecedor estariam em tabelas separadas; no modelo dimensional, todos ficam juntos na mesma tabela dimensão, mesmo que isso gere redundância (por exemplo, se dois produtos compartilham o mesmo fornecedor, o nome do fornecedor se repete). Essa redundância é aceita porque o ganho de desempenho nas consultas é enorme.

A distinção que importa aqui é entre os dois esquemas dimensionais principais: o esquema estrela e o esquema floco de neve. No estrela, as dimensões são desnormalizadas (uma única tabela por dimensão). No floco de neve, as dimensões são normalizadas em múltiplas tabelas relacionadas. Embora o floco de neve reduza a redundância, ele aumenta a complexidade das consultas e o número de junções — por isso, o estrela é o mais comum e recomendado para a maioria dos casos. A alternativa D captura exatamente essa característica fundamental das dimensões no modelo dimensional.

A pegadinha que a banca explora aqui é a inversão de conceitos: o candidato que conhece bem a teoria da normalização (aplicada a bancos relacionais transacionais) pode achar que as dimensões também devem ser normalizadas. Mas no data warehouse, a lógica é oposta — a desnormalização é uma característica deliberada e desejada. Guarde essa fronteira: OLTP normaliza, OLAP desnormaliza. É exatamente nela que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Afirma que as tabelas dimensão não podem ter mais de dez atributos. Não existe nenhuma restrição teórica ou prática quanto ao número de atributos de uma tabela dimensão. Uma dimensão pode ter 5, 15 ou 50 atributos, dependendo da necessidade de análise do negócio. O que se recomenda é que os atributos sejam relevantes para as consultas, mas não há um limite numérico fixo. A banca tenta fazer o candidato acreditar em uma regra arbitrária que não existe.

Alternativa B — ❌ Incorreta

Afirma que as tabelas dimensão não são fisicamente armazenadas no data warehouse. Isso é falso: tanto as tabelas fato quanto as tabelas dimensão são fisicamente armazenadas no data warehouse. As dimensões são parte integrante do modelo dimensional e precisam estar materializadas no repositório para que as consultas funcionem. O que pode variar é a forma de armazenamento (relacional, multidimensional, colunar), mas a existência física é obrigatória.

Alternativa C — ❌ Incorreta

Afirma que as tabelas dimensão não necessitam de chave primária. Toda tabela dimensão deve ter uma chave primária — geralmente uma chave substituta (surrogate key), que é um identificador artificial (como um número sequencial) criado justamente para garantir a unicidade de cada registro. Essa chave primária da dimensão é usada como chave estrangeira na tabela fato, estabelecendo o relacionamento entre elas. Sem chave primária, não haveria como relacionar corretamente os fatos às dimensões. A banca tenta confundir com a ideia de que a chave poderia ser dispensável, mas ela é essencial.

Alternativa D — ✅ Correta ⟵ GABARITO

Afirma que as tabelas dimensão não sofrem o processo de normalização. Exato. No modelo dimensional, as dimensões são desnormalizadas de propósito: os atributos descritivos são mantidos em uma única tabela, mesmo com redundância, para otimizar o desempenho das consultas analíticas. Essa é uma das características mais marcantes do modelo estrela, onde as dimensões são ligadas diretamente à tabela fato, sem normalização intermediária. A desnormalização reduz o número de junções e acelera a recuperação dos dados, que é o objetivo central de um data warehouse.

Alternativa E — ❌ Incorreta

Afirma que as tabelas dimensão devem possuir um número mínimo de valores nulos entre seus registros. Não há essa exigência. A presença de valores nulos em uma dimensão não é uma característica definidora do modelo dimensional. Na prática, busca-se evitar nulos em atributos que são usados como chave ou em atributos críticos para análise, mas não existe uma regra de "número mínimo de nulos". A banca tenta criar uma falsa regra de qualidade de dados que não corresponde à teoria da modelagem dimensional.

Gabarito: letra D — as tabelas dimensão não sofrem o processo de normalização, sendo deliberadamente desnormalizadas para otimizar o desempenho das consultas no data warehouse.

Link permanente: /questoes/gp018322