Questão de Banco de Dados — Visão (View) — FGV 2026
Banco de Dados›Visão (View)
Código
fg127347
Banca
FGV
Órgão
AL-RO
Ano
2026
Nível
Superior
Cargo
Analista Legislativo (Tecnologia da Informação - Banco de Dados)
Um gerente de RH precisa acessar os dados de funcionários, mas não deve ter permissão para visualizar a coluna SALARIO de todos eles. O DBA precisa implementar uma solução de segurança no nível de objeto para atender a esse requisito.Assinale a afirmativa correta sobre o uso de Views para implementar a restrição de acesso a colunas específicas.
AViews não podem ser usadas para segurança, pois elas apenas fornecem um nome alternativo para a tabela base.
BO DBA pode criar uma VIEW que omite a coluna SALARIO da tabela FUNCIONARIO e conceder ao gerente de RH privilégios SELECT apenas sobre a View.
CA View deve incluir todos os campos da tabela base, e a restrição de coluna deve ser aplicada por meio de uma Stored Procedure.
DA restrição deve ser aplicada usando uma TRIGGER AFTER SELECT que define o valor de SALARIO como NULL se o usuário for o gerente de RH.
EA segurança no nível de coluna é impossível de ser implementada sem o uso de criptografia TDE em toda a tabela.
Revelar gabarito e comentário▾
GabaritoB — O DBA pode criar uma VIEW que omite a coluna SALARIO da tabela FUNCIONARIO e conceder ao gerente de RH privilégios SELECT apenas sobre a View.
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”.
Views e segurança no nível de coluna
Gabarito: letra B. Views podem ser usadas como mecanismo de segurança para restringir o acesso a colunas específicas, criando uma "tabela virtual" que omite dados sensíveis. O DBA pode criar uma VIEW que projeta apenas as colunas permitidas (excluindo SALARIO) e conceder privilégios SELECT sobre essa view ao gerente de RH, sem dar acesso direto à tabela base.
A banca testa o conhecimento de que views são objetos de segurança no banco de dados, conforme descrito na literatura: elas fornecem uma visão limitada e controlada dos dados, restringindo o acesso de usuários ().
Alternativa
Afirmação sobre Views e Segurança
Correta?
Justificativa
A
Views não podem ser usadas para segurança, pois são apenas apelidos.
❌
Views encapsulam consultas e podem omitir colunas/linhas, servindo como camada de segurança.
B
Criar uma VIEW omitindo SALARIO e conceder SELECT apenas sobre ela.
✅
Solução clássica: view como "tabela virtual" restringe acesso a colunas sensíveis.
C
View deve incluir todas as colunas; restrição via Stored Procedure.
❌
View com todas as colunas não restringe; SP não é mecanismo padrão para restringir SELECT.
D
Usar TRIGGER AFTER SELECT para anular SALARIO.
❌
Triggers não respondem a SELECT na maioria dos SGBDs; abordagem insegura.
E
Segurança em coluna impossível sem criptografia TDE.
❌
Views são mecanismo válido e mais simples que criptografia para esse caso.
Alternativa A — ❌ Incorreta
Afirma que views "apenas fornecem um nome alternativo para a tabela base" e não podem ser usadas para segurança. Isso é falso: views são muito mais que apelidos; elas encapsulam consultas e podem omitir colunas ou linhas, servindo como camada de segurança. O próprio texto de apoio () enumera o aumento de segurança como uma das principais utilidades de views.
Alternativa B — ✅ Correta ⟵ GABARITO
Exatamente a aplicação correta: criar uma VIEW sem a coluna SALARIO e conceder permissão SELECT apenas sobre ela. O gerente de RH enxergará apenas os dados permitidos, sem acesso à coluna sensível. Isso é um padrão clássico de segurança no nível de objeto usando views.
Alternativa C — ❌ Incorreta
Diz que a view deve incluir todos os campos da tabela base e que a restrição deve vir de uma Stored Procedure. Isso contradiz o propósito: se a view incluir todas as colunas, ela não restringe nada. Além disso, stored procedures não são o mecanismo adequado para restringir colunas em consultas — elas podem ser usadas, mas não substituem a view como solução de segurança para SELECT.
Alternativa D — ❌ Incorreta
Sugere usar uma TRIGGER AFTER SELECT que define SALARIO como NULL. Triggers não podem ser acionadas por comandos SELECT na maioria dos SGBDs (elas respondem a INSERT, UPDATE, DELETE). Mesmo que fosse possível, não é uma abordagem prática nem segura, pois o dado ainda seria transmitido antes de ser alterado, criando janela de risco. A solução correta é a view.
Alternativa E — ❌ Incorreta
Afirma que segurança no nível de coluna é impossível sem criptografia TDE. Isso é falso: views, permissões granulares (GRANT em colunas específicas) e outras técnicas (como máscara de dados) permitem restringir colunas sem criptografia de toda a tabela. TDE é uma camada adicional, não um requisito.
PEGA ESSA DICA!
Em bancos de dados relacionais, views são ferramentas versáteis para segurança, desempenho e simplificação. Para restringir colunas, crie uma view com apenas as colunas necessárias e conceda acesso somente a ela. Lembre-se: views não armazenam dados, são consultas armazenadas (tabelas virtuais).