Um Analista comprou um pen drive de 16 GB para armazenar os filmes de uma campanha publicitária da organização em que trabalha. Quando estava gravando o sexto filme no pen drive, apareceu uma mensagem informando que não havia espaço suficiente para a gravação. Os 5 filmes que conseguiu gravar foram:
Para a gravação NÃO ter ocorrido, o sexto arquivo pode ter qualquer tamanho
a) menor do que 3 GB.
|
b) maior do que 700 MB.
|
c) menor do que 3700 MB.
|
d) maior do que 1.9 GB.
|
e) maior do que 600000 KB.
|
Considere hipoteticamente a existência de empresas que terceirizam o fornecimento de Recursos Humanos a outras empresas. Cada funcionário pode ser cadastrado em várias dessas empresas terceirizadas, nos mesmos cargos ou em cargos diferentes. Um modelo abstrato de dados dessa relação entre "Empresa_Terceirizada_RH" e "Funcionario" é mostrado abaixo.
Para um Analista especializado em Tecnologia da Informação implementar o modelo mostrado na figura, em um Sistema Gerenciado de Banco de Dados relacional, terá que
a)
utilizar a linguagem SQL, adicionando o parâmetro "CROSS REFERENCES" à instrução "CREATE TABLE" na criação de ambas as tabelas para estabelecer a relação "n:m" entre elas. |
b)
excluir o campo "cargoFuncionario" da tabela "Funcionario" e inserir na tabela "Empresa_Terceirizada_RH", pois o cargo é cadastrado quando o funcionário faz a inscrição na empresa terceirizada. |
c)
criar uma tabela de ligação entre "Empresa_Terceirizada_RH" e "Funcionario", fragmentando o relacionamento "n:m" em dois relacionamentos "1:n" e colocando o campo "cargoFuncionario" como atributo simples nessa tabela de ligação. |
d)
criar uma tabela de ligação entre "Empresa_Terceirizada_RH" e "Funcionario", fragmentando o relacionamento "n:m" em dois relacionamentos "1:1", já que não é possível implementar a relação "n:m" em bancos de dados relacionais. |
e)
excluir o atributo "cargoFuncionario", pois cada funcionário poderá ter um cargo diferente em cada empresa terceirizada onde se cadastrar. |
Na instrução "CREATE TABLE" de um banco de dados Oracle, usada para criar uma tabela chamada "Escritorio", para se indicar que um campo chamado "idAdvogado" é chave estrangeira e faz referência ao campo "idAdvogado", que é chave primária da tabela "Advogado", utiliza-se o segmento
a)
"Constraint fk_column FOREIGN KEY (idAdvogado) REFERENCES idAdvogado FROM Advogado." |
b)
"Constraint fk_column FOREIGN KEY (idAdvogado) REFERENCES Advogado (idAdvogado)." |
c)
"STRANGER KEY (idAdvogado) REFERENCES idAdvogado IN Advogado." |
d)
"FK_Constraint (idAdvogado) REFERENCES Advogado (idAdvogado)." |
e)
"Constraint fk_column FOREIGN KEY (idAdvogado) REFERENCES idAdvogado ON Advogado." |
Em uma tabela chamada "Funcionario" de um banco de dados Oracle, em que estão cadastrados os dados abaixo, considere que todos os campos são do tipo "varchar2" e que o campo "idFuncionario" é chave primária.
Para exibir os dados apenas dos funcionários cujos telefones iniciem com o DDD "(21)", utiliza-se a instrução
a)
"SELECT * FROM Funcionario LIKE telefoneFuncionario = "(21)%";" |
b)
"SELECT * FROM Funcionario WHERE telefoneFuncionario LIKE "(21)*";" |
c)
"SELECT * FROM funcionario WHERE telefoneFuncionario START BY "(21)";" |
d)
"SELECT * FROM Funcionario WHO telefoneFuncionario START BY "(21)";" |
e)
"SELECT * FROM Funcionario WHERE telefoneFuncionario LIKE "(21)%";" |
Considere a existência de uma tabela chamada "Funcionario" que possui diversos campos, dentre eles o campo "nome", que aceita cadeia de caracteres, e o campo "comissao", que aceita números reais. No Oracle, para exibir o nome de todos os funcionários e suas respectivas comissões, de forma que se o funcionário não receber comissão apareça "'Sem comissão'", utiliza-se a instrução SQL
a)
"SELECT nome, VRF((comissao,null),'Sem comissão') FROM Funcionario;" |
b)
"SELECT nome, NVL((comissao,null),'Sem comissão') FROM Funcionario;" |
c)
"SELECT nome, NVL(TO_CHAR(comissao),'Sem comissão') FROM Funcionario;" |
d)
"SELECT nome, ISNULL(comissao,'Sem comissão') FROM Funcionario;" |
e)
"SELECT nome, GET((comissao,null),'Sem comissão') FROM Funcionario;" |
No Oracle, para remover a restrição "primary key" da tabela "tribunal" e a restrição "foreign key" associada a essa chave primária, utiliza-se a instrução
a)
"DELETE primary key FROM tribunal ON CASCADE;" |
b)
"ALTER TABLE tribunal DELETE primary key ON CASCADE;" |
c)
"DELETE primary key, foreign key FROM tribunal;" |
d)
"ALTER TABLE tribunal DROP primary key CASCADE;" |
e)
"DROP primary key FROM tribunal CASCADE foreign key;" |
Em um banco de dados PostgreSQL aberto e em condições ideais, um Analista especializado em Tecnologia da Informação executou as instruções abaixo em uma tabela chamada "funcionario".
Na segunda instrução UPDATE, o Analista aumentou o salário do funcionário "Paulo" em "1000.00," quando deveria aumentar o salário do funcionário "Marcos" nesse valor. Para cancelar a operação realizada, a lacuna I deve ser preenchida pela instrução
a)
"CANCEL OPERATION;" |
b)
"RESTORE TO ps1;" |
c)
"CANCEL UPDATE;" |
d)
"ROLLBACK -1;" |
e)
"ROLLBACK TO ps1;" |
Na estrutura de arquivos de configuração do JBoss Enterprise Application Platform 6, o arquivo "standalone-ha.xml"
a) é necessário nos domínios autônomo e gerenciado, podendo ser lido somente pelo mestre do domínio.
|
b)
habilita os subsistemas "mod_cluster" e "JGroups" para um servidor autônomo, para que ele possa participar de um cluster de alta disponibilidade ou de balanceamento de carga. |
c) inclui apenas os detalhes de configuração necessários para executar um servidor como um servidor mestre de domínio autônomo, não estando presente nos servidores com domínio gerenciado.
|
d)
inclui detalhes de configuração específicos para um host físico em um domínio gerenciado, como interfaces de rede, conexões de socket, o nome do host e outros detalhes específicos do host. |
e) inclui apenas os detalhes de configuração necessários para executar um servidor como um servidor escravo de domínio autônomo, não estando presente em servidores de domínio gerenciado.
|
Dentre os vários tipos de ataques de segurança pela rede de computadores, há o ataque conhecido como injeção SQL, que se aproveita das vulnerabilidades da estrutura de acesso às bases de dados. Um dos tipos de injeção SQL é conhecido como Filter Bypassing, que se caracteriza
a) pela alteração de palavras de forma a burlar os filtros de entradas.
|
b) pelo escape de caracteres da assinatura de acesso ao sistema.
|
c) pela forma indireta de busca de informações na base de dados.
|
d) pela passagem de parâmetros não filtrados e de forma direta na consulta.
|
e) pela passagem de parâmetro de tipo não validado e filtrado para a consulta.
|
O Tomcat 8 encara uma aplicação web como contexto. Para configurar esse contexto, utiliza um descritor de contexto com certas configurações, por exemplo, os recursos de nomeação ou configuração do gerenciador de sessão. Em uma aplicação web, os caminhos em que devem estar os descritores de contexto são:
A alternativa que completa a lacuna I é
a)
"META-INF/context.xml." |
b)
"WEB-APP/config.xml." |
c)
"SERVER-CONTEXT/web.xml." |
d)
"META-INF/web-context.xml." |
e)
"SERVER-CONTEXT/context.xml." |
Copyright © Tecnolegis - 2010 - 2024 - Todos os direitos reservados.