Questão de Banco de Dados — Geral — FCC 2026

ETL: Transformação e Carga no Data Warehouse

Gabarito: letra A. O script INSERT INTO fato_despesas ... SELECT ... SUM(c.valor) ... GROUP BY executa a fase de transformação e carga do ETL: lê dados da tabela staging_despesas, aplica JOINs com as dimensões, agrega os valores com SUM e GROUP BY, e insere o resultado consolidado na tabela fato do modelo estrela. As demais alternativas confundem as etapas do ETL (extração, transformação, carga) ou o propósito do Data Warehouse (OLAP) com o banco transacional (OLTP).

O processo ETL (Extract, Transform, Load) é o coração da construção de um Data Warehouse. Ele tem três fases bem definidas: extração (leitura dos dados das fontes, que podem ser sistemas transacionais, arquivos, APIs etc.), transformação (limpeza, padronização, conversão de formatos, agregação, aplicação de regras de negócio) e carga (gravação dos dados já transformados no destino analítico). O script da questão faz exatamente isso: extrai da staging_despesas (área temporária de carregamento), transforma ao juntar com as dimensões (dim_orgao, dim_tempo, dim_elemento) e agregar os valores com SUM, e carrega o resultado na fato_despesas.

O modelo estrela (star schema) é a modelagem típica de Data Warehouse: uma tabela fato central, com as medidas (fatos numéricos, como valor_total), cercada por tabelas de dimensão (que descrevem os fatos, como dim_orgao, dim_tempo, dim_elemento). A tabela fato é populada com dados agregados e sumarizados, prontos para consultas analíticas (OLAP). O script faz exatamente isso: SUM(c.valor) AS valor_total com GROUP BY d.id_orgao, t.id_tempo, e.id_elemento — ou seja, consolida as despesas por órgão, tempo e elemento, gerando uma medida agregada.

A distinção crucial aqui é entre o ambiente OLTP (Online Transaction Processing) e o OLAP (Online Analytical Processing). O OLTP é o banco transacional, otimizado para muitas escritas curtas e leituras pontuais (ex.: registrar um empenho). O OLAP é o ambiente analítico, otimizado para leituras pesadas e agregações (ex.: total de despesas por órgão no ano). O Data Warehouse é o repositório OLAP, e o ETL é o processo que move os dados do OLTP para o OLAP. O script da questão não é uma consulta OLAP executada em tempo real sobre o banco transacional — é um processo de carga que popula o Data Warehouse.

A pegadinha que a banca explora é a confusão entre as etapas do ETL. A alternativa D diz que o script é a extração, mas a extração é apenas a leitura dos dados brutos — aqui há JOINs, SUM e GROUP BY, que são transformações. A alternativa C diz que é uma carga detalhada linha a linha, mas o GROUP BY prova que há agregação. A alternativa B diz que é uma consulta OLAP em tempo real, mas é um INSERT (carga), não um SELECT de exploração. A alternativa E fala em normalização, que é o oposto do modelo dimensional. Guarde a fronteira entre extrair, transformar e carregar: é exatamente nela que as alternativas se dividem.

Alternativa A — ✅ Correta ⟵ GABARITO

O script é a materialização da fase de transformação e carga do ETL. Ele lê da staging_despesas (dados brutos), aplica JOINs com as dimensões para substituir códigos por IDs, agrega com SUM(c.valor) e GROUP BY, e insere o resultado na fato_despesas. A tabela fato é populada com medidas sumarizadas (valor_total), exatamente o que o modelo estrela do Data Warehouse exige. A alternativa espelha com precisão o que o script faz: consolida dados limpos e agregados no modelo estrela.

Alternativa B — ❌ Incorreta

Confunde o processo de carga do ETL com uma consulta OLAP de exploração. O script é um INSERT INTO ... SELECT, ou seja, uma operação de escrita que popula a tabela fato — não é uma consulta de leitura para gerar dashboards. Além disso, ele não executa sobre o banco transacional em tempo real; ele lê da staging_despesas (área temporária) e escreve no Data Warehouse. A exploração OLAP viria depois, com SELECTs sobre a fato_despesas já populada.

Alternativa C — ❌ Incorreta

Afirma que a carga é detalhada, linha a linha, sem agregações. O script faz exatamente o oposto: SUM(c.valor) AS valor_total com GROUP BY d.id_orgao, t.id_tempo, e.id_elemento agrega os lançamentos do staging, consolidando vários registros em um único por combinação de dimensões. A tabela fato não preserva cada registro individual — ela guarda o total por órgão, tempo e elemento. A carga detalhada linha a linha seria um simples INSERT INTO fato_despesas SELECT ... FROM staging_despesas sem GROUP BY.

Alternativa D — ❌ Incorreta

Diz que o script é a etapa de extração do ETL, lendo dados sem transformação. A extração é apenas a leitura dos dados brutos das fontes — aqui, a leitura da staging_despesas é só o ponto de partida. O script transforma os dados ao aplicar JOINs (resolvendo códigos em IDs) e SUM/GROUP BY (agregando valores). Não é uma transferência sem transformação; é uma transformação com agregação seguida de carga.

Alternativa E — ❌ Incorreta

Confunde o modelo dimensional do Data Warehouse com a normalização do modelo relacional. A normalização visa eliminar redundância e dependências funcionais, dividindo tabelas — é típica do modelo relacional transacional (OLTP). O script, ao contrário, popula uma tabela fato desnormalizada do modelo estrela, com medidas agregadas. Não há processo de normalização de dimensões aqui; há consolidação de fatos.

Gabarito: letra A