WEBAULA 1 - BANCO DE DADOS

Prévia do material em texto

Visão geral
	
	Apresentação da disciplina: 
	
	Estaremos trabalhando juntos na Disciplina de Banco de Dados II. Aqui vamos estudar o Projeto de banco de dados, Linguagem de consulta, introdução a bancos distribuídos e orientado a objeto, arquitetura de funcionamento de um SGBD,  explorando algumas destas potencialidades e características que tornam o mundo de banco de dados tão interessante, amplamente comentado, de altíssima responsabilidade e fundamental para o sucesso de um bom sistema de informação.
	
	Objetivo da Disciplina
	
	1) Apresentar o conceito de projeto de banco de dados.
2) Apresentar o modelo relacional normalizado.
3) Apresentar a linguagem de consulta estruturada SQL.
4) Apresentar as principais características dos bancos de dados distribuídos e orientado a objeto.
5) Apresentar as principais características da arquitetura de um SGBD.
6) Capacitar o aluno a modelar, normalizar e construir modelos físicos que representem fielmente o banco de dados a ser construído e permita identificar os SGBDs de mercado. Apresentar o conceito de projeto de banco de dados.
7) Apresentar o modelo relacional normalizado.
8) Apresentar a linguagem de consulta estruturada SQL.
9) Apresentar as principais características dos bancos de dados distribuídos e orientado a objeto.
10) Apresentar as principais características da arquitetura de um SGBD.
Capacitar o aluno a modelar, normalizar e construir modelos físicos que representem fielmente o banco de dados a ser construído e permita identificar os SGBDs de mercado.
	
 
	Conteúdo Programático:
	
	1. Projeto de banco de dados
1.1. Modelos lógicos x modelos físicos
1.2. O modelo relacional normalizado
1.3. Formas normais
2. Linguagem de consulta padrão - SQL
2.1. Comandos de definição de dados
2.2. Comandos de manipulação de dados
2.3. Comandos de consulta de dados
2.4. Comandos de gravação de dados
3. Introdução a banco de dados distribuídos
3.1. Distribuição lógica
3.2. Distribuição física
4. Outros modelos de banco de dados
4.1 Modelo registros
4.2 Modelo rede
4.3 Modelo hierárquico
4.4 Modelo orientado a objeto
4.5 Modelo objeto relacional
4.6 Modelo temporal
4.7 Modelo geo referenciado
	
	Metodologia:
	
	Os conteúdos programáticos ofertados nessa disciplina serão desenvolvidos  por meio das Tele-Aulas de forma expositiva e interativa (chat – tira dúvidas em tempo real), Aula Atividade por Chat para aprofundamento e reflexão e Web Aulas que estarão disponíveis no Ambiente Colaborar, compostas de conteúdos de aprofundamento, reflexão e atividades de aplicação dos conteúdos e avaliação. Serão também realizadas atividades de acompanhamento tutorial, participação em Fórum, atividades práticas e estudos independentes (auto estudo) além do Material do Impresso por disciplina.
	
	Avaliação Prevista:
	
	O sistema de avaliação da disciplina compreende em assistir a tele-aula, participação no fórum, produção de texto/trabalho no portfólio,  realização de duas avaliações virtuais, uma avaliação presencial  embasada em todo o material didático,  tele-aula e web aula da disciplina.
Web Aula 1
Título: Conceito de Transação1
	Apresentação do Professor
Olá caros alunos,
Sou o professor Roberto Yukio Nishimura, especialista em Administração da Engenharia de Software.
Estaremos trabalhando juntos na Disciplina de Banco de Dados II. Aqui vamos dar continuidade na disciplina anterior de banco de dados e explorar algumas destas potencialidades e características que tornam o mundo de banco de dados tão interessante, amplamente comentado, de altíssima responsabilidade e fundamental para o sucesso de um bom sistema de informação.
Afinal o grande insumo de um computador são os dados, que devem ser coletados, armazenados, recuperados, processados e apresentados.
Sejam bem vindos,
Aqui na unidade I vamos tratar de transações de um banco de dados.
 
1© Roberto Yukio Nishimura – UNOPAR 2009.
	Transação de um banco de dados 
Como já sabemos, um banco de dados é composto de tabelas que estão inter-relacionadas umas com as outras, de modo a representar o Diagrama Entidade Relacionamento DER que foi modelado segundo o conceito do Modelo Entidade Relacionamento MER.
As ações a serem efetuadas no banco de dados, consistem basicamente em gravar novos dados, consultar dados gravados existentes, modificar dados previamente gravados existentes e remover dados previamente gravados existentes.
Então podemos definir que existem 4 tipos de operações:
- gravar dados, que vamos tratar de agora em diante como ‘inserir dados’.
- consultar dados, que vamos continuar como está.
- modificar dados, que vamos tratar de agora em diante como ‘atualizar dados’.
- remover dados, que vamos tratar de agora em diante como ‘deletar dados’.
Pesquisar na internet enciclopédia Wikipédia o significado de CRUD.
Link para Wikipédia (http://www.wikipedia.com)
Destas operações, podemos afirmar que:
- a operação consultar dados não provoca modificações nos dados armazenados no banco de dados.
- as operações inserir dados, atualizar dados, deletar dados provocam alterações nos dados armazenados.
Um banco de dados deve sempre manter a sua integridade e consistência nos dados armazenados, para garantir que as regras de negócio estabelecidas estejam sendo cumpridas.
Neste momento dizemos que o banco de dados não está em transação.
Porém sempre que uma das três operações que provocam alterações nos dados armazenados (inserir dados, atualizar dados e deletar dados) são executados, dizemos que o banco de dados realizou uma transação.
Podemos concluir então que uma transação é quando um banco de dados sai do seu modo íntegro e consistente, realiza alguma operação de alteração de dados e retorna ao seu modo íntegro e consistente.
Para iniciar uma transação, o banco de dados recebe um aviso de início de transação que chamaremos de ‘início de transação’ ou ‘begin transaction’.
Ao final da transação, o banco de dados recebe outro aviso, agora indicando o encerramento da transação que chamaremos de ‘fim de transação’ ou ‘end transaction’.
Durante a realização de uma transação podemos colocar apenas um comando de atualização de banco de dados ou vários comandos de atualização de banco de dados.
Isto significa que uma transação pode ter uma única operação ou diversas operações.
Dentro de uma transação podemos ter também diversos comandos de consulta de dados, pois como estes comandos não modificam os dados armazenados, eles não interferem na integridade ou consistência do banco de dados.
Quanto mais operações colocarmos dentro de uma única transação, mais demorado e critico torna-se esta transação, porém o tamanho de uma transação dependerá muito da ‘regra de negócio a ser cumprida’.
	Propriedades ACID 
Todo Sistema Gerenciador de Bando de Dados (SGBD) aplica em seu funcionamento o conceito denominado ACID, que representa a inicial de quatro propriedades fundamentais.
Atomicidade
Consistência
Integridade
Durabilidade
Um SGBD não pode aplicar apenas algumas destas propriedades, todas as propriedades devem ser cumpridas, senão não podemos considerar um SGBD de verdade.
	Atomicidade 
Dizemos que uma transação é atômica, pois a transação não é divisível em partes, ou seja, a transação deve ser realizada por inteiro ou ela não pode ser realizada.
Lembramos que uma transação pode ter várias operações de alteração de dados, então ou cumprimos todas elas ou não realizamos nenhuma delas.
Ex. em uma transação realizamos a inclusão de um cliente novo, a geração de uma nota fiscal e a baixa no estoque do produto vendido, ao final desta transação, devemos confirmar a transação por inteiro e gravar todas estas operações, se esta transação não se confirmar ao final, nenhuma destas operações pode ser gravada no banco de dados, garantindo assim a atomicidade da transação.
	Consistência 
Uma transação quando inicia, os dados armazenados estão todos consistentes, ao concluir a transação os dados devem estar consistentesnovamente, ou seja, as regras de negócio devem continuar sendo executadas e cumpridas.
Ex. se realizar uma transação em uma conta bancária, onde o cliente possui um saldo de R$ 50,00 e não tem limite de crédito (não pode ficar negativo) e esta transação for uma retirada de R$ 60,00 , esta transação não pode ser concluída pois a consistência do banco de dados não estaria garantida deixando a conta com um saldo negativo.
	Integridade 
É também conhecida como Isolamento de transações.
Uma transação deve ser íntegra/isolada, ou seja, as regras de negócio devem ser cumpridas durante a realização das operações na transação independentemente de existirem mais transações simultaneamente e ao final delas, esta integridade deve permanecer .
Ex. se for estabelecida uma regra de negócio onde um cliente de uma vídeo locadora pode cadastrar até dois dependentes, mas que todo dependente deve obrigatoriamente estar vinculado a um cliente, se um determinado cliente for deletado do banco de dados, os dependentes deste cliente deverão ser deletados também, pois se eles permanecerem no banco de dados, a integridade desta regra de negócio estará comprometida e toda esta operação ocorrer simultaneamente a outras transações no banco de dados, inclusive podendo ser nas mesmas tabelas ou não.
	Durabilidade 
Uma transação depois que for realizada e confirmada deve obrigatoriamente ser durável, ou seja não pode desaparecer do banco de dados sem que uma outra transação realize esta operação.
Ex. um determinado dado que foi gravado em uma transação hoje, daqui a cinco anos, se nenhuma outra transação modificar este dado, quando este dado for consultado deverá apresentar o mesmo resultado do que foi gravado hoje, quando a transação original foi realizada.
	Confirmação ou não de uma transação
Quando terminamos uma transação, com quantas operações forem necessárias, necessitamos confirmar ou não a realização desta transação.
A confirmação desta transação é realizada com a execução de um comando de confirmação ou ‘commit’.
Neste momento as quatro propriedades do banco de dados Atomicidade, Consistência, Integridade e Durabilidade são executadas e confirmadas estas propriedades, a transação é confirmada e encerrada.
Mas se por acaso a transação não trouxe o resultado esperado, apesar dos comandos de alteração já terem sido executados, ainda podemos nos arrepender e cancelar a transação através do comando de cancelamento ou ‘rollback’.
Este comando desfaz as operações que estavam sendo realizadas até o início da transação, levando a um ponto onde as quatro propriedades ainda permanecem garantindo os dados do banco de dados.
Os comandos ‘commit’ e ‘rollback’ são muito conhecidos no ambiente dos programadores de computador, analistas de sistemas e administradores de banco de dados.
O comando ‘end transaction’ geralmente está implícito dentro dos comandos ‘commit’ e ‘rollback’.
Lembramos que um SGBD deve suportar diversas transações sendo realizadas simultaneamente, por isso mesmo, as transações podem concorrer umas com as outras, este assunto será tratado em ‘controle de concorrência’.
	Independência de transação 
Esta é outra propriedade de banco de dados que surgiu no final da década de 70 e início da década de 80.
Inicialmente os SGBDs eram praticamente todos com transações dependentes, isto significava que apesar do banco de dados ser multiusuário, suportando diversas transações ao mesmo tempo, caso uma das transações tivesse algum problema e a mesma fosse interrompida ou ‘abortada’, todas as demais transações eram interrompidas também, derrubando o banco de dados como um todo e provocando um rollback geral.
Esta situação deixava os fabricantes/fornecedores de SGBDs com um ponto de vulnerabilidade na confiança sobre seus produtos.
Para resolver esta situação, foi estabelecido o conceito de independência de transação ou ‘independent trans’.
Este conceito pregava a seguinte característica:
Se uma transação falhar e for necessário interrompê-la através do ‘abort’, que interrompa apenas esta transação e no máximo alguma outra transação que esteja na dependência dos dados desta transação interrompida.
Aquelas outras transações que estavam sendo realizadas em outros dados, deve continuar sendo executada sem nenhuma interferência.
A esta característica damos o nome de ‘independent trans’.
Espero que tenham gostado desta web-aula, aguardo vocês no nosso blog.
Web Aula 2
Título: Processamento de Transações
	Modelo de armazenamento de um banco de dados 
Um banco de dados tem como finalidade armazenar dados de uma forma organizada, coerente, consistente, integra e durável, isto já estudamos na webaula anterior, agora vamos detalhar um pouco mais como isto é feito.
Quando um comando que modifica o estado do banco de dados, por exemplo insert, update e delete, é executado, uma série de ações são desencadeadas.
O Sistema Gerenciador de Banco de Dados (SGBD), dispara internamente um comando do tipo write para o sistema operacional do computador/servidor do banco de dados.
Porém este comando não é imediatamente repassado para o sistema operacional, porque se isto ocorresse haveria um estrangulamento na comunicação do SGBD com o sistema operacional.
O que acontece então?
O comando write grava uma cópia dos dados afetados em um buffer do banco de dados ainda na memória do servidor do banco de dados.
Este buffer tem um determinado tamanho na memória principal, que é configurado e parametrizado pelo Administrador de Banco de Dados DBA.
Quando esta área de armazenamento de buffer fica cheia, o SGBD encaminha uma ordem para o sistema operacional gravar todos estes buffers em uma área do disco pertencente ao banco de dados que vamos chamar de LOG.
Depois que este LOG é gravado, uma confirmação é repassada ao SGBD avisando que o LOG já foi devidamente gravado.
Com isto o SGBD já está pronto para descarregar todas as transações confirmadas com write e que o sistema operacional está aguardando.
Este mecanismo visa diminuir a quantidade de IOs (input output) entre o sistema operacional e os discos, pois sabemos que um dos maiores gargalos em processamento de dados é exatamente a transferência de dados entre a memória principal e os discos rígidos.
Esta transferência não envolve apenas dispositivos eletrônicos, mas dispositivos eletros-mecânico também.  
O modelo das informações das transações gravadas no log é baseado na identificação do início da transação, descrição da transação e finalização da transação.
< T , Start >
< T , tabela, campo, valor velho, valor novo >
< T , Commit >
	Componentes do processamento de transações
Cada transação que está ocorrendo no banco de dados possui a sua própria área de trabalho, com uma cópia individual dos dados acessados.
Buffer do banco de dados é o nome técnico que representa estes locais.
Buffer do banco de dados são as páginas do banco de dados na memória, é controlado pelo banco de dados e/ou sistema operacional.
Quanto mais buffers de banco de dados tiverem, mais dados podem ser carregados na memória principal do servidor do banco de dados, mais transações podem ser realizadas simultaneamente e mais rápido pode ser o banco de dados.
Por isso dizemos que um servidor de banco de dados tem que ser exclusivo no equipamento, não é recomendado colocar outras aplicações no mesmo equipamento.
E quanto mais memória RAM o servidor tiver, melhor ainda.
Bancos de dados são verdadeiros consumidores de recursos computacionais como processadores, memória RAM e discos.
Buffer do sistema são os buffers responsáveis pelo armazenamento das páginas dos códigos objetos dos programas e das áreas de trabalho locais das transações ativas.
Quem controla esta área é o gerenciador de memória virtual do sistema operacional.
Buffer de log são as cópias das páginas do registro de log, de transações que foram confirmadas pelo banco de dados e aguardando serem descarregadas em disco.
O armazenamento secundário (discos rígidos do servidor do banco de dados) podeser dividido em:
Código objeto do sistema – programas aplicativos e sistema operacional
Área de troca de memória virtual – área em disco usado para armazenar páginas da memória principal que não estão em uso no momento.
Armazenamento estável on-line – mantém os registros do log necessários para uma recuperação de falha do banco de dados.
Armazenamento histórico estável – mantém os registros do log na forma de histórico das transações antigas.
	Recuperação de falhas de transação
Uma transação de banco de dados pode apresentar falha, nestes casos temos duas ações possíveis:
Reexecução em cascata – para recuperarmos uma transação T, pode ser necessário refazer diversas outras transações já confirmadas. Esta situação acontece se depois da transação T ocorrer, outras transações utilizarem dos dados atualizados por T. 
Desfazer em cascata – cascading rollback é a situação onde diversas transações precisam ser desfeitas. T1, T2 e T3 processadas, mas T1 apresenta uma falha e as transações T2 e T3 serão desfeitas também, para manter a consistência. 
Esta situação pode ocorrer quando o banco de dados utiliza o protocolo de bloqueio de duas fases ou baseado em marcador de tempo.
Vamos considerar as seguintes transações:
	T1 
	T2 
	 Read (A)
	 
	 Write (A)
	 
	 Read (B)
	Read (A) 
	 
	Write (C) e torna-se compromissada 
	 Falha em T1
	 
Uma vez que a transação T2 já está compromissada, T2 não poderá ser abortada, e a falha de T1 poderá deixar o banco de dados inconsistente, formando assim uma situação impossível de recuperar.
Para evitar este tipo de situação, os SGBDs implementam protocolos de controle de transação.
	Como é utilizado o LOG na recuperação do processamento de transações 
É realizada uma varredura completa do log.
Para evitar a leitura total do arquivo de log, utilizamos os pontos de verificação (checkpoint) para reduzir o número de registros do log que precisarão ser lidos durante uma recuperação do banco de dados.
Assim as transações que serão os nossos alvos são aquelas que iniciaram depois do último ponto de verificação e as que ainda permanecem ativas.
A leitura do log é feita do final para o começo até encontrar um checkpoint.
Cada transação identificada com um commit será incluída em uma lista refaz.
Cada transação identificada com um start, que não estiver na lista refaz vai para a lista desfaz.
Quando o checkpoint é localizado, a leitura reversa é encerrada.
O log será lido novamente no sentido inverso e cada transação que estiver na lista desfaz, o processo undo é executado.
Continua a leitura até localizar o último start da lista refaz.
Varre o log para frente e executa redo para cada entrada na lista refaz.
	DeadLock
Existem situações onde um problema transacional de concorrência de acesso pode nos levar a uma situação de deadlock.
Abraço mortal é uma situação onde duas transações T1 e T2, cada uma bloqueou inicialmente A e B respectivamente, e para concluírem suas transações agora necessitam de B e A respectivamente.
Porém nenhuma das duas transações abre mão dos seus dados previamente bloqueados.
Esta exceção é tratada pelo SBGD da seguinte forma:
Como A e B já estão bloqueadas, por T1 e T2, T1 não conseguirá B e T2 não conseguirá A.
E conseqüentemente ambas as transações ficarão paradas.
Esta é a situação de deadlock, quando isto ocorrer, uma das duas transações receberá o erro DEADLOCK e a outra prosseguirá normalmente como se nada tivesse ocorrido.
T1 e T2 estão corretos a nível de programação, inclusive se executado novamente, podem ou não apresentar deadlock novamente.
Podemos prever o deadlock com algumas ações na programação, ações estas que devem ser amplamente discutidas com os demais analistas da sua equipe e com o DBA principalmente.
O esquema mais simples aponta para bloqueio de todos os dados necessários logo no início da transação.
O problema que pode ocorrer com o bloqueio inicial dos dados é que a baixa utilização dos dados bloqueados logo no início deixe muitos outros programas parados esperando pelos dados por um longo período de tempo, atrapalhando o desempenho do banco de dados e até mesmo causando um travamento generalizado no sistema.
Existe outra situação complicada também, sempre que o seu programa é executado ele recebe um erro de deadlock, ou seja é o eterno escolhido, a esta situação chamamos de Starvation ou Inanição.
Neste caso, a sua lógica de programação deve ser revista com urgência.
Como o SGBD prevê, identifica e trata o deadlock ?
Existem basicamente duas formas de detecção e tratamento de deadlock.
Wait-die ou espere-morra é uma técnica não apropriativa, quando T1 requer um dado bloqueado por T2, permite-se que T1 espere somente se o marcado de tempo da transação for menor que T2 (T1 é mais velha que T2), T2 receberá o erro de deadlock e T1 consegue o dado. Caso contrário (T1 é mais novo que T2), T1 receberá o erro de deadlock e T2 seguirá em frente normalmente.
Wound-wait ou tome fôlego e espere já é baseado em uma técnica apropriativa, quando T1 requer um item bloqueado por T2, T1 poderá esperar pelo dado somente se o marcador de tempo de T1 for maior que T2 (T1 é mais novo que T2), T2 receberá o erro de deadlock e T1 consegue o dado. Caso contrário (T1 é mas velho que T2), T1 receberá o erro de deadlock e T2 seguirá em frente normalmente.
A maioria dos SGBDs comerciais utilizam a técnica wait-die dentro do seu núcleo.
Existem grafos de espera que permitem detecção de um deadlock e sua conferência através de um algoritmo.
Depois de detectado, o SGBD parte para a escolha da vítima (qual é o programa que vai receber o erro), sinalização do erro de deadlock para a vítima, abortar a sua transação e desfazer a sua transação aplicando um rollback nas transações já efetuadas pelo programa.
Espero que tenham gostado desta web-aula, aguardo vocês no nosso blog.