Abaixo comentamos a prova de Técnico Judiciário Área Apoio Especializado – Especialidade Informática do TRIBUNAL REGIONAL FEDERAL DA 3 REGIÃO relacionada aos assuntos de banco de dados. Temos 5 questões de SQL e uma questão relacionada a normalização.
Vamos então comentar cada uma das questões. Notadamente a FCC vem melhorando a qualidade na elaboração da prova, isso privilegia o concurseiro que possui uma preparação mais aprofundada com os conceitos bem consolidados.
Atenção: Para responder às questões de números 61 a 66, considere as informações abaixo.
61. Considere que a tabela Processo foi criada sem chave primária. Nesse caso, para definir a chave primária, antes de serem inseridos registros, deve-se utilizar a instrução SQL
(A) ADD CONTRAINT PRIMARY KEY(NumeroSeqProcesso, DigitoProcesso, AnoAjuizamentoProcesso) from Processo;
(B) UPDATE TABLE Processo ADD PRIMARY KEY(NumeroSeqProcesso, DigitoProcesso, AnoAjuizamentoProcesso);
(C) ADD TO Processo PRIMARY KEY(NumeroSeqProcesso, DigitoProcesso, AnoAjuizamentoProcesso);
(D) INSERT INTO Processo PRIMARY KEY(NumeroSeqProcesso, DigitoProcesso, AnoAjuizamentoProcesso);
(E) ALTER TABLE Processo ADD PRIMARY KEY(NumeroSeqProcesso, DigitoProcesso, AnoAjuizamentoProcesso);
Comentário: A questão bem tranquila se você lembrar que a criação de uma chave primária pode ser feita durante a criação da tabela ou por meio do comando ALTER TABLE adicionando a chave primária, vejam a sintaxe abaixo:
ALTER TABLE Persons
ADD PRIMARY KEY (P_Id);
A maior parte dos SGBDs permite que você dê um nome a sua constraint. A sintaxe desta opção é apresentada abaixo:
ALTER TABLE Persons
ADD CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName)
Gabarito: E
62. Se a tabela Processo for ligada a uma outra tabela em um relacionamento 1:n, sendo 1 processo para n da outra tabela,
(A) nem todos os registros cadastrados na outra tabela precisarão estar relacionados a algum processo existente na tabela Processo.
(B) as colunas NumeroSeqProcesso, DigitoProcesso e AnoAjuizamentoProcesso terão que aparecer obrigatoriamente na outra tabela como parte da chave primária.
(C) será obrigatório que na outra tabela seja cadastrado, pelo menos, um registro para cada valor da chave primária da tabela Processo.
(D) a chave primária da outra tabela precisa, necessariamente, aparecer na tabela Processo, para que seja garantida a integridade referencial.
(E) as colunas NumeroSeqProcesso, DigitoProcesso e AnoAjuizamentoProcesso terão que aparecer na outra tabela, para haver integridade referencial.
Comentário: Esse questão do relacionamento entre a tabela processo e outra tabela em 1:n, basta pensar o seguinte. Supondo que um processo tenha vários ministro do supremo ligados a ele. E cada ministro só possa ter um processo por vez. Para simplificar vamos pensar que a chave tem apenas um nome genérico que é a descrição do processo: LAVAJATO, POSSEDELULA, MOSSACKFONSCECA. Agora basta associar cada um dos processos a lista de ministros para termos uma relação 1:n. Se voltarmos para os termos da questão, bastaria substituir os nomes dos processos pelos seus respectivos atributos que compõe a chave primária, no caso: NumeroSeqProcesso, DigitoProcesso e AnoAjuizamentoProcesso.
Lewandowski (LAVAJATO)
Carmen Lúcia (MOSSACKFONSCECA)
Celso de Mello (MOSSACKFONSCECA)
Marco Aurélio (POSSEDELULA)
Gilmar Mendes (POSSEDELULA)
Dias Toffoli (MOSSACKFONSCECA)
Luis Fux (LAVAJATO)
Rosa Weber (MOSSACKFONSCECA)
Teori Zavascki (LAVAJATO)
Roberto Barroso (POSSEDELULA)
Edson Fachin (MOSSACKFONSCECA)
Gabarito: E
63. Um Técnico Judiciário de TI executou um comando SQL e foram exibidas as informações abaixo.
Ano < 2000
2
O comando digitado pelo Técnico foi:
(A) SELECT COUNT(AnoAjuizamentoProcesso) LABEL ‘Ano < 2000’ FROM Processo WHERE AnoAjuizamentoProcesso<2000;
(B) SELECT COUNT(*) AS ‘Ano < 2000’ FROM Processo WHERE AnoAjuizamentoProcesso<2000;
(C) SELECT COUNT(AnoAjuizamentoProcesso) AS Ano < 2000 FROM Processo WHERE AnoAjuizamentoProcesso<2000;
(D) SELECT COUNT(AnoAjuizamentoProcesso) AS ‘Ano < 2000’ FROM Processo WHERE AnoAjuizamentoProcesso>2010;
(E) SELECT AVG(AnoAjuizamentoProcesso) AS ‘Ano < 2000’ FROM Processo WHERE AnoAjuizamentoProcesso<2000;
Comentário: Essa questão tem uma pegadinha, precisamos entender que, como utilizamos caracteres reservados para definição do alias, necessariamente utilizamos as aspas para delimitar seu nome, isso torna a alternativa C incorreta. Essa é minha primeira observação a respeito da questão.
Se tivéssemos a aspas na alternativa C ela estaria correta, visto que as instâncias ou tuplas da tabelas Processo não apresentam nenhuma coluna nula para a coluna AnoAjuizamentoProcesso, e mesmo que existissem, elas seriam eliminadas pela restrição descritas na cláusula WHERE.
Observem que a alternativa B, encontra-se perfeitamente correta. Utiliza a sintaxe correta do comando SELECT, contando a quantidade de linhas cujo valor da coluna AnoAjuizamentoProcesso<2000 e fazendo o rename correto da coluna que aparece no resultado.
Gabarito: B
64. Ao executar um comando SQL, foram exibidos os dados abaixo.
Anos
2014
2012
2007
2002
2000
1999
1997
O comando digitado foi:
(A) SELECT DISTINCT AnoAjuizamentoProcesso AS Anos FROM Processo ORDER BY DEC;
(B) SELECT DISTINCT AnoAjuizamentoProcesso AS Anos FROM Processo ORDER BY AnoAjuizamentoProcesso DESC;
(C) SELECT AnoAjuizamentoProcesso AS Anos FROM Processo ORDER BY AnoAjuizamentoProcesso DESC;
(D) SELECT AnoAjuizamentoProcesso AS ‘Anos’ FROM Processo WITH DISTINCT OPTION;
(E) SELECT DISTINCT AnoAjuizamentoProcesso AS ‘Anos’ FROM Processo ORDER BY AnoAjuizamentoProcesso;
Comentário: A questão acima trata de duas cláusulas que podem ser usadas dentro do comando SELECT. A primeira trata de retirar tuplas duplicadas do resultado da consulta. Para fazer isso, basta usar o termo DISTINCT dentro do select. A outra refere-se a ordenação do resultado de uma consulta, utilizamos a cláusula ORDER BY ASC|DESC, onde ASC mostra o resultado em ordem crescente e DESC exibe a resposta ordenada descendentemente. Desta foram podemos encontra nossa resposta na alternativa B.
Gabarito: B
65. O super-usuário root do banco de dados deseja conceder permissão para que o usuário Paulo possa alterar os dados dos registros contidos na tabela Processo. Para isso ele deve digitar a instrução
(A) CREATE ROLE ON Processo FOR update TO Paulo;
(B) ADD PERMISSION TO Paulo FOR update ON Processo;
(C) GRANT update ON Processo TO Paulo;
(D) CREATE ROLE update ON Processo TO Paulo WITH GRANT OPTION;
(E) GRANT OPTION update FROM Processo TO Paulo;
Comentário: Para incluirmos uma permissão sobre determinado objeto de SQL devemos, por padrão, usar o comando GRANT. A sintaxe do comando pode ser vista abaixo:
GRANT privilege_name
ON object_name
TO {user_name |PUBLIC |role_name}
[WITH GRANT OPTION];
Vejam que primeiramente você deve definir os privilégios que serão atribuídos aos usuários ou roles. Depois você vai dizer sobre qual o objeto do banco de dados a permissão será dada. A última etapa é definir o usuário ou a role. Temos a opção de definir um privilégio como PUBLIC, ou seja, todos que tem acesso ao banco de dados terão a permissão. Por fim, é possível utilizar a cláusula WITH GRANT OPTION que permite ao usuário que recebe repassar a permissão para outros usuários.
Seguindo a sintaxe definida acima, podemos encontrar nossa resposta na alternativa C.
Gabarito: C
66. Após receber permissão para alterar os dados dos registros contidos na tabela Processo, o usuário Paulo inseriu diversos registros utilizando a instrução INSERT e em seguida constatou, por meio da instrução SELECT, que estes dados foram inseridos adequadamente. Porém, outros usuários que acessam a tabela não visualizarão os dados inseridos por Paulo até que ele execute o comando
(A) commit
(B) refresh
(C) end transaction
(D) endpoint
(E) close section
Comentário: Essa questão trata de alguns conceito interessantes. O primeiro deles é a característica de isolamento das transações. Segundo o enunciado, podemos observar que as modificações feitas por uma transação não são vistas por outro usuário até o momento do commit. Neste momento os dados já estão devidamente armazenado em uma memória não volátil. Outro ponto interessante que podemos derivar da questão é o nível de isolamento descrito para o sistema. Neste caso podemos usar: Read committed, Repeatable read ou Serializable.
Gabarito: A
68. Uma entidade Departamento é composta pelos atributos abaixo.
Código do Departamento
Matrícula do Funcionário
Nome do Departamento
Nome do Funcionário
Telefone do Departamento
Telefone do Funcionário
Número da CTPS
Considerando-se que só poderá ser cadastrado um único número de telefone, tanto para os departamentos quanto para os funcionários, para que a entidade seja normalizada adequadamente, deve-se
(A) aplicar a segunda forma normal (2FN), que requer que todos os valores de atributos em uma entidade sejam atômicos, eliminando grupos repetidos e colocando-os cada um em uma entidade separada.
(B) aplicar a segunda forma normal (2FN), de forma que todos os demais atributos sejam dependentes da chave primária, que deverá ser composta pelos atributos Código do Departamento e Matrícula do Funcionário.
(C) aplicar a primeira forma normal (1FN), colocando os atributos Matrícula do Funcionário, Nome do Funcionário, Telefone do Funcionário e Número da CTPS em uma entidade Funcionário relacionada adequadamente à entidade Departamento.
(D) criar mais duas entidades, Funcionário e Telefone, relacionando todas elas com cardinalidade 1:n, com o lado n na entidade Departamento.
(E) eliminar os campos Matrícula do Funcionário, Nome do Funcionário e Telefone do Funcionário, já que estes campos são os únicos que não contém dados do departamento, mas sim do funcionário.
Comentário: Analisando a questão acima podemos começar tentando supor quais são as dependências funcionais possíveis dentro do conjunto de atributos listados. Podemos perceber claramente dois determinantes principais Código do Departamento e Matrícula do Funcionário.
Código do Departamento à Nome do Departamento, Telefone do Departamento
Matrícula do Funcionário à Nome do Funcionário, Telefone do Funcionário,Número da CTPS
CTPS é o número da carteira de trabalho e previdência social.
Vejam que a normalização em tabelas deve partir desta separação, caso contrário teremos as informações de departamento presentes em todos os funcionários cadastrados.
Sobre as alternativas que temos como possíveis para a resposta, dado que a entidade definida no enunciado da questão é a entidade Departamento, temos que separar os atributos que e coloca-los em outra entidade Funcionario. Essa ideia está descrita na alternativa C, mas temos uma ressalva a fazer. Precisamos aplicar a segunda forma normal e não apenas a primeira, como está descrito na alternativa.
A definição da 2FN diz que não deve existir dependência parcial. Enquanto a definição da primeira diz que todos os atributos devem ser atômicos, vejam que a relação departamento não tem problemas com a 1FN desde o início do processo de normalização. É possível, portanto, requerer a anulação da questão.
Gabarito: C (cabe recurso)
Espero que tenham gostado! Qualquer dúvida estou às ordens!
Thiago Cavalcanti
Olá, tudo bem? Hoje responderemos ao questionamento sobre a constitucionalidade das emendas de redação e…
Neste artigo você encontrará um resumo do Transtorno de Personalidade Esquizotípica, pertencente ao tópico de…
Olá, pessoal, tudo bem? As funções essenciais à justiça estarão em pauta hoje no nosso…
Confira quais são os hospitais de lotação! Iniciais de até R$ 17,9 mil! O edital…
Neste artigo você encontrará um resumo do Transtorno de Personalidade Evitativa, pertencente ao tópico de…
Olá, pessoal, tudo bem? Hoje vamos falar sobre controle de constitucionalidade. Dada a proximidade da…
