Agente de Tecnologia - Banco do Brasil - Banco de Dados - CESGRANRIO

Gabarite Questões · 2026-06-19T02:19:37.148Z

Simulado de Informática com 10 questões. Banca: CESGRANRIO.

Responda às questões desta prova e, ao finalizar, clique em 'Corrigir Simulado' ao final da página para conferir o gabarito.

Desempenho Global

89Resoluções

32%Média

DifícilDificuldade

•

•

•

•

•

Ensino Médio

Questão

Para gerar um gráfico de dispersão, um programador precisava consultar duas tabelas, T1 e T2. Ele decidiu, então, usar um LEFT JOIN, como em

SELECT * FROM T1 LEFT JOIN T2 USING (CHAVE);

Essa consulta resultou em 214 linhas.

Por motivos de segurança, ele fez outra consulta semelhante, apenas trocando o LEFT JOIN por um JOIN, e essa segunda consulta resultou em 190 linhas.

O que pode explicar corretamente a quantidade diferente de linhas nas consultas realizadas?

CHAVE é a chave primária de T1, mas apenas um campo da chave primária de T2.

CHAVE é a chave primária de T2, mas apenas um campo da chave primária de T1.

T1 possui linhas cujo valor de CHAVE não está presente na T2.

T2 possui linhas cujo valor de CHAVE não está presente na T1.

T2 possui linhas com todas as chaves presentes em T1, mas com campos nulos.

Questão

Ao coletar dados em um sistema compatível com SQL 2008 para fazer uma análise de dados, um programador percebeu que havia dois campos, data_de_nascimento e data_de_emissão_RG, em que o valor de data_de_emissão_RG sempre deve ser mais recente que data_de_nascimento. Percebeu, porém, que em 10% das linhas acontecia o inverso, isto é, data_de_nascimento era mais recente que data_de_emissão_RG. Ele corrigiu os dados nessas linhas, verificando que estavam consistentemente trocados, mas, preocupado que tal problema voltasse a acontecer, resolveu solicitar ao DBA uma alteração da tabela, de forma que data_de_emissão_RG sempre tivesse que ser mais recente que data_de_nascimento.

O DBA atendeu adequadamente a esse pedido do programador por meio de uma restrição em SQL 2008 do tipo

Questão

Um pesquisador conseguiu uma base de dados que mostrava terrenos classificados de acordo com:

características físicas;
tipo de negócio a ser nele implantado;
risco esperado, que compreendia os rótulos alto, médio, baixo ou nenhum.

Decidiu, então, usar um algoritmo de aprendizado de máquina que, a partir das características físicas do terreno e do tipo de negócio a ser nele implantado, aprenderia a determinar o risco esperado, enquadrando o terreno em questão em um daqueles rótulos.

Nesse cenário, que algoritmo de aprendizado de máquina é indicado para resolver esse problema?

Questão

Após um treinamento em SQL padrão 2008, compatível com ambiente MS SQL Server 2008, um escriturário do Banco Z precisou utilizar os conhecimentos adquiridos para criar uma tabela no sistema de banco de dados desse Banco. A tabela a ser criada é de fornecedores, e tem os seguintes campos: CNPJ, nome do fornecedor e país de origem. As características gerais da tabela são:

o campo CNPJ é chave primária e contém 14 caracteres, sendo que os caracteres devem se ater aos numéricos [“0” a “9”], e o caractere zero “0” não pode ser ignorado, seja qual for a posição dele (início, meio ou fim da chave);
o campo NOME contém 20 caracteres e aceita valor nulo;
o campo PAIS contém 15 caracteres e não aceita valor nulo.

Nesse contexto, o comando SQL2008 que cria uma tabela com as características descritas acima é

CREATE TABLE Fornecedores
(CNPJ INTEGER PRIMARY KEY,
NOME VARCHAR(20) ACCEPT NULL,
PAIS VARCHAR(15) NOT NULL)

CREATE TABLE Fornecedores
(CNPJ CHAR(14) PRIMARY KEY,
NOME VARCHAR(20),
PAIS VARCHAR(15) NOT NULL)

CREATE TABLE Fornecedores
(CNPJ CHAR(14) NOT NULL,
NOME VARCHAR(20) NOT NULL,
PAIS VARCHAR(15))

CREATE TABLE Fornecedores
(CNPJ CHAR(14),
NOME VARCHAR(20) NOT NULL,
PAIS VARCHAR(15) NOT NULL),
PRIMARY KEY (CNPJ)

CREATE TABLE Fornecedores
(CNPJ INTEGER(14) NOT NULL,
NOME VARCHAR(20),
PAIS VARCHAR(15) NOT NULL),
PRIMARY KEY (CNPJ)

Questão

Para que fosse mais fácil entender um sistema em desenvolvimento, um desenvolvedor usou um modelo de dados relacional (protótipo) mais simples do que o do banco de dados do sistema corporativo original, sendo que ambos utilizavam o mesmo SGDB PostgreSQL. Cabe ressaltar que esse protótipo utilizava apenas um subconjunto dos dados do sistema corporativo original e realizava apenas consultas.
Uma forma de garantir que os dados desse protótipo estejam sempre completamente atualizados em relação aos dados reais, com baixo impacto tanto na operação quanto no desempenho do sistema corporativo original, é

criar apenas VIEWS no protótipo, definidas com consultas sobre as tabelas do sistema corporativo original.

implantar TRIGGERS a cada INSERT, em todas as tabelas do sistema corporativo original, atualizando as tabelas do protótipo.

implantar TRIGGERS de atualização a cada SELECT, em todas as tabelas do protótipo.

particionar as tabelas da base do sistema corporativo original escolhendo um RANGE adequado ao trabalho do protótipo.

utilizar DUMP da base do sistema corporativo original e PSQL para a base do protótipo, a cada seção de trabalho, para atualizar a base do protótipo.

Questão

Ao desenvolver um Data Warehouse para o Banco W, um programador decidiu criar um modelo conceitual com base no modelo estrela para cada fato analisado. Ao criar a primeira tabela fato, relativa ao valor e ao prazo de empréstimos, foram identificadas as seguintes dimensões, com os seus atributos descritos em parênteses: tempo (dia, mês e ano), agência (estado, cidade, bairro e número da agência), produto (nome do produto e juros do produto) e cliente (conta e nome do cliente). Segundo as regras e as práticas da modelagem dimensional, e usando a granularidade mais baixa, que atributos devem constar da tabela fato?

fato_id, dia, mes, ano, estado, cidade, bairro, numero_agencia, nome_produto, juros_mensais_produto, conta_cliente, nome_cliente, valor_emprestimo, prazo_emprestimo

fato_id, emprestimo_id, valor_emprestimo, prazo_emprestimo

fato_id, tempo_id, agencia_id, produto_id, cliente_id, emprestimo_id

fato_id, tempo_id, agencia_id, produto_id, cliente_id, dia, mes, ano, estado, cidade, bairro, numero_agencia, nome_produto, juros_mensais_produto, conta_cliente, nome_cliente, valor_emprestimo, prazo_emprestimo

fato_id, tempo_id, agencia_id, produto_id, cliente_id, valor_emprestimo, prazo_emprestimo

Questão

Na etapa de preparação de dados em um ambiente de Big Data, pode ocorrer o aparecimento de dados ruidosos, que são dados fora de sentido no ambiente do Big Data e que não podem ser interpretados pelo sistema. Uma forma de reduzir esse efeito, e até eliminá-lo, é utilizar um método de suavização de dados, que minimiza os efeitos causados pelos dados ruidosos. Esse método consiste em

agrupar dados semelhantes em clusters, verificar os dados que se apresentam como ruidosos e não os inserir no ambiente de Big Data, substituindo cada um desses dados ruidosos pelo valor NULL.

criar um cubo de dados multidimensional para acelerar a identificação e a eliminação dos dados ruidosos encontrados, e, neste caso, os dados assumem valores predefinidos no momento do pré-processamento.

dividir os valores dos dados originais em pequenos intervalos, denominados compartimentos, e, em seguida, substituí-los por um valor geral, ou genérico, calculado para cada compartimento específico.

executar uma fusão de dados, tendo como base dados vizinhos, e obter novas variáveis que irão preencher os espaços incoerentes dentro do Big Data, eliminando o ruído.

realizar uma ação de Data Mining com atributos que se pareçam com dados ruidosos, gerando novos atributos, classificados como atributos “fantasmas”, sem valor para o tratamento do Big Data.

Questão

Um banco comercial deseja obter um tipo de banco de dados NoSQL que trate os dados extraídos de redes sociais, de modo a formar uma coleção (collection) interconectada. Nessa coleção (collection), os dados são organizados em vértices ou objetos (O) e em relacionamentos, que são relações (R) ou arestas.

Nesse modelo de banco de dados NoSQL, os dados seriam apresentados da seguinte forma:

O:Usuario{u1:Joao, u2:Jose, u3:Maria, u4:Claudio} O:Escola{e1:UFRJ, e2:URGS, e3:IFB} R:Estudaem{re1=u1:e2;re2=u2:e2;re3=u3:e1;re4=u4:e3} R:Amigode{ra1=u1:u2;ra2=u1:u3;ra3=u2:u3}

O banco de dados NoSQL que representa essa situação deve ter uma estrutura do tipo

Questão

Um administrador de um banco de dados construído por meio do MongoDB inseriu dados em uma coleção (collection) de dados da seguinte forma:

db.fornecedores.insert( { codigo: “thx1138“, nome: “Roupas Syfy ltda“, pais: “Arabia Saudita“ } )

Posteriormente, esse administrador construiu uma consulta que retornou apenas o nome, sem repetição, de todos os países que fazem parte dessa coleção (collection).

O comando utilizado para tal consulta foi

db.fornecedores.find("pais")

db.fornecedores.find().pretty({"pais":1})

db.fornecedores.find().sort({"pais":1})

db.fornecedores.distinct({"pais":0})

db.fornecedores.distinct( "pais" )

Questão

Uma empresa precisa implementar um sistema Big Data para controlar a movimentação dos produtos que a empresa oferece. Esse sistema precisa estar com a configuração de dados como sendo um fato, que seria um evento de ocorrência, como, por exemplo: as compras de um determinado insumo, em um determinado fornecedor e em um determinado instante.
Para tal finalidade, esse sistema a ser implementado deverá estar organizado segundo a configuração de

Notificações

Nada por aqui

Questão

Para gerar um gráfico de dispersão, um programador precisava consultar duas tabelas, T1 e T2. Ele decidiu, então, usar um LEFT JOIN, como em

SELECT * FROM T1 LEFT JOIN T2 USING (CHAVE);

Essa consulta resultou em 214 linhas.

Por motivos de segurança, ele fez outra consulta semelhante, apenas trocando o LEFT JOIN por um JOIN, e essa segunda consulta resultou em 190 linhas.

O que pode explicar corretamente a quantidade diferente de linhas nas consultas realizadas?

CHAVE é a chave primária de T1, mas apenas um campo da chave primária de T2.

CHAVE é a chave primária de T2, mas apenas um campo da chave primária de T1.

T1 possui linhas cujo valor de CHAVE não está presente na T2.

T2 possui linhas cujo valor de CHAVE não está presente na T1.

T2 possui linhas com todas as chaves presentes em T1, mas com campos nulos.

Questão

Um pesquisador conseguiu uma base de dados que mostrava terrenos classificados de acordo com:

características físicas;
tipo de negócio a ser nele implantado;
risco esperado, que compreendia os rótulos alto, médio, baixo ou nenhum.

Questão

o campo CNPJ é chave primária e contém 14 caracteres, sendo que os caracteres devem se ater aos numéricos [“0” a “9”], e o caractere zero “0” não pode ser ignorado, seja qual for a posição dele (início, meio ou fim da chave);
o campo NOME contém 20 caracteres e aceita valor nulo;
o campo PAIS contém 15 caracteres e não aceita valor nulo.

Nesse contexto, o comando SQL2008 que cria uma tabela com as características descritas acima é

CREATE TABLE Fornecedores
(CNPJ INTEGER PRIMARY KEY,
NOME VARCHAR(20) ACCEPT NULL,
PAIS VARCHAR(15) NOT NULL)

CREATE TABLE Fornecedores
(CNPJ CHAR(14) PRIMARY KEY,
NOME VARCHAR(20),
PAIS VARCHAR(15) NOT NULL)

CREATE TABLE Fornecedores
(CNPJ CHAR(14) NOT NULL,
NOME VARCHAR(20) NOT NULL,
PAIS VARCHAR(15))

CREATE TABLE Fornecedores
(CNPJ CHAR(14),
NOME VARCHAR(20) NOT NULL,
PAIS VARCHAR(15) NOT NULL),
PRIMARY KEY (CNPJ)

CREATE TABLE Fornecedores
(CNPJ INTEGER(14) NOT NULL,
NOME VARCHAR(20),
PAIS VARCHAR(15) NOT NULL),
PRIMARY KEY (CNPJ)

Questão

criar apenas VIEWS no protótipo, definidas com consultas sobre as tabelas do sistema corporativo original.

implantar TRIGGERS a cada INSERT, em todas as tabelas do sistema corporativo original, atualizando as tabelas do protótipo.

implantar TRIGGERS de atualização a cada SELECT, em todas as tabelas do protótipo.

particionar as tabelas da base do sistema corporativo original escolhendo um RANGE adequado ao trabalho do protótipo.

utilizar DUMP da base do sistema corporativo original e PSQL para a base do protótipo, a cada seção de trabalho, para atualizar a base do protótipo.

Questão

fato_id, dia, mes, ano, estado, cidade, bairro, numero_agencia, nome_produto, juros_mensais_produto, conta_cliente, nome_cliente, valor_emprestimo, prazo_emprestimo

fato_id, emprestimo_id, valor_emprestimo, prazo_emprestimo

fato_id, tempo_id, agencia_id, produto_id, cliente_id, emprestimo_id

fato_id, tempo_id, agencia_id, produto_id, cliente_id, valor_emprestimo, prazo_emprestimo

Questão

agrupar dados semelhantes em clusters, verificar os dados que se apresentam como ruidosos e não os inserir no ambiente de Big Data, substituindo cada um desses dados ruidosos pelo valor NULL.

executar uma fusão de dados, tendo como base dados vizinhos, e obter novas variáveis que irão preencher os espaços incoerentes dentro do Big Data, eliminando o ruído.

realizar uma ação de Data Mining com atributos que se pareçam com dados ruidosos, gerando novos atributos, classificados como atributos “fantasmas”, sem valor para o tratamento do Big Data.

Questão

Nesse modelo de banco de dados NoSQL, os dados seriam apresentados da seguinte forma:

Questão

Um administrador de um banco de dados construído por meio do MongoDB inseriu dados em uma coleção (collection) de dados da seguinte forma:

db.fornecedores.insert( { codigo: “thx1138“, nome: “Roupas Syfy ltda“, pais: “Arabia Saudita“ } )

Posteriormente, esse administrador construiu uma consulta que retornou apenas o nome, sem repetição, de todos os países que fazem parte dessa coleção (collection).

O comando utilizado para tal consulta foi

db.fornecedores.find("pais")

db.fornecedores.find().pretty({"pais":1})

db.fornecedores.find().sort({"pais":1})

db.fornecedores.distinct({"pais":0})

db.fornecedores.distinct( "pais" )

Questão