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

PL/SQL: packages e encapsulamento de lógica no Oracle

Gabarito: letra E. A estrutura que atende ao requisito de encapsulamento, controle de visibilidade interna de funções auxiliares e manutenção centralizada da lógica é o package PL/SQL, que possui uma specification pública e um body onde ficam as funções privadas — exatamente o que o enunciado descreve. Essa é a solução nativa do Oracle para agrupar procedimentos e funções relacionados, escondendo a implementação e expondo apenas a interface desejada.

O problema apresentado é clássico em desenvolvimento de banco de dados: regras de negócio (cálculo de prescrição processual) que precisam ser reutilizadas por vários módulos, com lógica centralizada e sem expor funções auxiliares internas. Vamos entender por que o package é a resposta e por que as demais alternativas falham.

O que é um package PL/SQL?

Um package é um objeto do banco de dados que agrupa logicamente tipos, variáveis, constantes, cursores, procedimentos e funções relacionados. Ele é composto por duas partes:

• Specification (spec): a interface pública — declara o que está disponível para uso externo (procedures, functions, tipos, variáveis públicas). É o "contrato" com os usuários do package.

• Body (corpo): a implementação — contém o código real das subprogramas declarados na spec, além de poder conter subprogramas privados (não declarados na spec), que só podem ser chamados internamente pelo próprio package.

Essa separação é o coração do encapsulamento: quem usa o package só enxerga a spec; a implementação e as funções auxiliares ficam escondidas no body. Isso permite:

• Manutenção centralizada: alterar a lógica interna não exige mudar os chamadores, desde que a assinatura pública permaneça.

• Controle de visibilidade: funções auxiliares declaradas apenas no body são privadas — não podem ser chamadas de fora.

• Reutilização: vários módulos (execução penal, cível, criminal) podem chamar o mesmo package, garantindo consistência.

Por que as outras alternativas falham?

Vamos analisar cada uma:

• A) Sinônimos públicos para funções distribuídas: sinônimos são apenas apelidos para objetos existentes. Eles não encapsulam lógica nem controlam visibilidade interna — apenas facilitam o acesso. Além disso, "funções distribuídas em diferentes schemas" vai contra a ideia de centralização.

• B) Múltiplas functions no schema público: colocar várias functions soltas no schema público não encapsula nada — todas ficam visíveis e acessíveis, sem controle de visibilidade interna. Grants individuais controlam permissões, mas não escondem a implementação.

• C) Procedure para cada módulo replicando a lógica: isso é o oposto da centralização — duplica a lógica em cada módulo, dificultando manutenção e criando risco de inconsistência.

• D) View parametrizada: views são tabelas virtuais baseadas em consultas SQL. Não são parametrizadas (no sentido de receber argumentos como funções) e não servem para encapsular lógica procedural de cálculo. Uma view apenas apresenta dados; não executa lógica de negócio complexa.

A pegadinha da banca

A banca explora a confusão entre visibilidade (quem pode chamar) e permissão (quem tem grant). A alternativa B menciona "grants individuais", o que parece resolver o controle de acesso — mas grants controlam quem pode executar, não escondem a implementação. O package resolve ambos: controla visibilidade (privado vs. público) e, combinado com grants, controla quem pode executar o package como um todo.

Exemplo prático

Imagine um package PRESCRICAO_PKG:

CREATE OR REPLACE PACKAGE prescricao_pkg AS
  FUNCTION calcular_prescricao(p_tipo VARCHAR2, p_data_inicio DATE) RETURN DATE;
END;
/

CREATE OR REPLACE PACKAGE BODY prescricao_pkg AS
  -- função privada (não está na spec)
  FUNCTION ajustar_feriados(p_data DATE) RETURN DATE IS
  BEGIN
    -- lógica interna
    RETURN p_data;
  END;

  FUNCTION calcular_prescricao(p_tipo VARCHAR2, p_data_inicio DATE) RETURN DATE IS
  BEGIN
    -- usa a função privada
    RETURN ajustar_feriados(p_data_inicio + 30);
  END;
END;
/

Os módulos chamam apenas prescricao_pkg.calcular_prescricao(...); a função ajustar_feriados fica invisível externamente. Se a lógica mudar, só o body é alterado — os chamadores nem percebem.

Distinção importante: package vs. procedure avulsa

Conclusão

O requisito do enunciado — encapsulamento, controle de visibilidade interna e manutenção centralizada — é atendido exclusivamente pelo package PL/SQL. As demais alternativas ou não encapsulam, ou não centralizam, ou não existem como estrutura adequada.

Alternativa A — ❌ Incorreta

Sinônimos públicos são apenas apelidos para objetos existentes em outros schemas. Eles facilitam o acesso, mas não encapsulam lógica nem controlam visibilidade interna. Além disso, "funções distribuídas em diferentes schemas" contraria a exigência de manutenção centralizada — a lógica continuaria espalhada.

Alternativa B — ❌ Incorreta

Criar múltiplas functions no schema público expõe todas as funções, sem qualquer encapsulamento. Grants individuais controlam permissões de execução, mas não escondem a implementação nem agrupam a lógica. É o oposto do que o enunciado pede: aqui tudo fica visível e solto.

Alternativa C — ❌ Incorreta

Replicar a lógica em uma procedure para cada módulo é duplicação de código — exatamente o que se quer evitar. Viola o requisito de manutenção centralizada: uma alteração na regra de prescrição exigiria mudar várias procedures, com alto risco de inconsistência.

Alternativa D — ❌ Incorreta

Views são tabelas virtuais baseadas em consultas SQL. Não são parametrizadas (não recebem argumentos como funções) e não executam lógica procedural de cálculo. Uma view apenas apresenta dados; não serve para encapsular regras de negócio complexas como cálculo de prazos.

Alternativa E — ✅ Correta ⟵ GABARITO

O package PL/SQL é a estrutura que atende a todos os requisitos: a specification expõe a interface pública, o body contém a implementação e pode declarar funções privadas (visíveis apenas internamente). Isso garante encapsulamento, controle de visibilidade e manutenção centralizada — exatamente o que o enunciado descreve.

Gabarito: letra E