EXERCICIOS DE REVISAO_CORRIGIDOS!
4 pág.

EXERCICIOS DE REVISAO_CORRIGIDOS!


DisciplinaBanco de Dados I9.119 materiais74.564 seguidores
Pré-visualização2 páginas
Exercícios de Revisão \u2013 BD3
Igor Domingues de Freitas
Arquitetura com Compartilhamento Total: compartilhamento de disco e de memória principal. As vantagens são uma extrema eficiência na comunicação entre os processadores e a desvantagem é que não é extensiva ao uso de muitos processadores. 
Arquitetura com Compartilhamento Fraco: compartilhamento apenas de disco, mas cada um deles possui sua própria memória. Não há gargalo para estender o número de processadores e é mais tolerante a falhas, pois se o processador ou sua memória falham, outro processador pode assumir suas tarefas. No entanto, ainda há restrição da interconexão com o sistema de memória secundária. A conexão entre os processadores se torna mais lenta que a anterior. 
Sem compartilhamento: modelo com vários processadores onde não há compartilhamento. Há uma maior flexibilidade quando à escala e pode dar suporte a um grande número de processadores. No entanto, o custo de comunicação e os acessos a discos remotos, que são maiores que na arquitetura com memória ou disco compartilhado, já que 
a transmissão de dados envolve interação por software em ambos os lados.
JDBC e ODBC são conectores com o banco de dados. ODBC é o padrão do Windows, podendo fazer a ligação de qualquer linguagem com qualquer BD. O JDBC é o padrão de java. A conexão do jdbc é mais lenta (jdbc->odbc->bd), mas a oracle diz que é mais fácil de se utilizar.
	1.
	Importa todas as funções de sql do java.
	2.
	Realiza a conexão com o BD a partir dos dados passados (servidor, usuário, senha).
	3.
	Cria um novo statement.
	4.
	Realiza uma query e guarda em rs.
	5.
	Verifica na metabase os tipos dos objetos.
	6.
	Um loop para \u201candar\u201d no retorno da query.
	7.
	Encerra o statement.
	8.
	Encerra a conexão com o BD.
View é uma tabela criada a partir de uma seleção. Ela é sempre executada quando se quer enxergar essa visão (a menos que ela seja materializada). Ela serve para mostrar dados de tabelas diferentes em uma mesma tabela (mas há o custo de execução do select).
Stored Procedure é um procedimento armazenado dentro do BD. Um pequeno programa que roda ao ser chamado em algum momento do programa (por exemplo, para realizar um backup de hora em hora, pode haver uma stored procedure para isso).
Triggers servem para manter as regras do banco. Por exemplo, antes de realizar um update, se aquele update realmente pode ser realizado (deixar o salário de um empregado maior do que o de seu chefe). São regras que serão conferidas antes/ao invés/depois de realizar o update/delete/insert.
Inserirmos algo que não pode estar presente ali. Por exemplo, querer inserir uma pessoa do estado de SP numa view onde há um select de pessoas do RJ. Para garantirmos que isso não possa ser feito, é necessário colocar WITH CHECK OPTION.
Gatilhos podem criar loops infinitos. Não há uma padronização entre SGBDs, há sobrecarga no SGBD, afinal ele precisará rodar o trigger antes de realizar a instrução, há SGBDs que não utilizam triggers.
Read Uncommitted: Gera dirty, fuzzy e phantom reads. 
Read Commited: Gera fuzzy e phantom reads.
Repeatable Read: Gera somente phantom reads.
Serializable: não gera nenhuma.
Dirty Read: Uma transação está realizando alterações, enquanto isso (e antes da primeira dar commit), a 2ª lê os dados. Os dados serão exibidos, mas não com as alterações feitas (mas sem commit). Há uma leitura \u201csuja\u201d dos dados. 
Ler uma modificação não efetivada (fictícia).
Fuzzy Read: Uma transação faz uma busca e a resposta é retornada. Enquanto isso uma outra transação remove o item que a primeira transação tinha procurado. Se a primeira transação tentar executar a mesma busca, a resposta será diferente.
Dentro da mesma transação
Phantom Read: Uma transação faz uma busca que retorna pessoas do estado do RJ e enquanto isso outra transação insere novas pessoas do RJ. A leitura não será completa, pois novos dados foram inseridos.
A serializable não oferece riscos, mas bloqueia as transações a apenas uma de cada vez.
Pool de conexões são conexões já previamente abertas com o servidor. Realizar conexões com o banco é algo muito custoso, então o pool de conexões gera ganhos no desempenho da aplicação. A aplicação utiliza a conexão e depois a devolve para o pool. Compartilhamento de recursos e aumento de desempenho são as vantagens do pool de conexões. Basicamente o pool de conexões só é efetivo em arquiteturas de 3 camadas.
A arquitetura em duas camadas é mais simples e apropriada para pequenas aplicações, mas possui suas limitações: é mais difícil de instalar, a escalabilidade é menor e é mais difícil de acessar fontes heterogêneas. Já a arquitetura em três camadas oferece uma melhor manutenção, o monitoramento é mais fácil (pois há uma separação maior), melhora a integração entre plataformas, se reduz os problemas de manutenção.
Falso. É mais do que apenas uma representação, ela atua também como uma camada de validação e abstração.
Verdadeiro. Isso estará na camada de controle, porque são regras de negócio.
Falso. Não é uma busca de controle de integridade dos dados.
Criação de um pool de conexões, para reduzir a taxa de overhead no banco de dados (a explicação já foi dita no exercício 8). Não é eficiente em duas camadas, pois o pool de conexões se conecta ao servidor. Não teria vantagens em pequeno porte (que é o mais utilizado com duas camadas).
Há gastos na divisão da consulta. Ao fazermos paralelo, a consulta é dividida entre os processadores, na hora da divisão e COMO será dividido, há um custo (também há custos na junção). Por isso o tempo diminui, mas não é n vezes maior que o anterior.
 
Falsa. O desempenho seria melhor em alguns casos, mas não sempre. Em casos onde há muitas modificações nos dados daquela visão, sempre haverá que atualizar a visão (o que piora o desempenho).
VERDADEIRO. Já que visões materializadas são dados que raramente são reexecutadas, elas se tornam um tipo de tabela fixa, enquanto a view normal, eh atualizada constantemente, sempre que a aplicação eh aberta
O que já foi dito no item a, sempre haverá que atualizar a visão materializada quando ocorrerem mudanças nos dados das tabelas que ela materializa. Haveria de ter uma política de atualização da visão, ou seja, em alguma época os dados estariam desatualizados, além de ela ocupar espaço em disco.
Depende do RAID utilizado, seja para rapidez de escrita ou de leitura de dados ou por segurança. A vantagem é justamente uma rapidez de escrita, leitura e maior segurança. As desvantagens são justamente o custo elevado (é necessário mais de um HD) e o fato de que uma maior rapidez de escrita piora a capacidade de leitura e vice-versa. Não há um RAID superior, depende de pra que ele será utilizado.
RAID 0: particiona os dados em n discos. Serve para uma maior capacidade de escrita, mas para ler os dados é mais devagar, já que ele precisa juntar os dados. Em termos de segurança é péssimo, já que perder um disco significa perder todos os dados. 
RAID 1: é o RAID que oferece segurança para os dados, já que você sempre terá uma cópia deles no outro disco caso um deles dê problema. Os problemas estão em: capacidade de escrita maior, já que ele precisa escrever os dados em 2 discos, o custo (de dinheiro) é o mesmo, mas para ter sempre a mesma quantidade de espaço. (RAID0 se comprarmos 2 HDs de 500GB, teremos 1TB para armazenar. No RAID1 se comprarmos 2 HDs de 500GB, teremos 500GB para armazenar, pois o outro será uma cópia).
No RAID4 o hotswap poderia ser realizado (se ele fosse utilizado) no disco de paridade, já que ele não é necessário a todo tempo, só na hora da perda de dados. No RAID5 é inviável, já que há pedaços do dado em cada disco, então não é possível realizar uma troca de HDs na hora. 
Cluster de 3 computadores, para garantir a alta disponibilidade do sistema.
RAID5. O RAID5 serve justamente para uma