Você está na página 1de 6

Unopar Virtual - Portflio Mdulo 3 - Bancos de Dados II - Tarcisio - Document Transcript

1. SISTEMA DE ENSINO PRESENCIAL CONECTADO TECNOLOGIA EM ANLISE E DESENVOLVIMENTO DE SISTEMAS TARCSIO CAVALCANTE UCHA SISTEMA DE ENSINO PRESENCIAL CONECTADO ATIVIDADE PORTFOLIO BANCO DE DADOS II Curitiba 2009 2. TARCSIO CAVALCANTE UCHA ATIVIDADE PORTFOLIO BANCO DE DADOS II Trabalho apresentado ao Curso Tecnolgico em Anlise e Desenvolvimento de Sistemas da UNOPAR - Universidade Norte do Paran, para o Mdulo 3 - Fundamentos dos Sistemas de Informao. Orientador: Prof. Prof. Roberto Y. Nishimura. Curitiba 2009 3. SUMRIO 1 MODELO RELACIONAL NORMALIZADO MRN ............................................. 3 2 PADRO SQL ..................................................................................................... 6 3 PROCESSAMENTO DE TRANSAES ............................................................ 8 4 CONTROLE DE CONCORRNCIA .................................................................. 10 REFERNCIAS ......................................................................................................... 12 4. 3 1 MODELO RELACIONAL NORMALIZADO MRN Num projeto de banco de dados necessrio identificar os dados e fazer com que estes representem eficientemente o mundo real. Os SGDB Sistemas Gerenciadores de Bancos de Dados ou SGBDR Sistemas Gerenciadores de Bancos de Dados Relacionais so baseados no Modelo Relacional de Dados, que tem o princpio de que todos os dados so guardados em tabelas. Conceito criado por Edgar Frank Codd em 1970. Foi o primeiro modelo de dados descrito teoricamente. O Modelo Entidade Relacionamento apresenta algumas situaes de difcil implementao prtica. Para resolver isso, Codd props um processo de Normalizao de Dados (ou normalizao de tabelas) que aplica uma srie de regras s tabelas de um banco de dados, para verificar se estas esto corretamente projetadas. O objetivo da normalizao evitar problemas provocados por falhas no projeto do banco de dados, eliminando redundncias e evitando problemas com insero, eliminao e atualizao de dados. Com a normalizao bem sucedida, o espao de armazenamento de dados diminui, as tabelas podem ser atualizadas com maior eficincia. Normalmente aps a aplicao das Regras de Normalizao, algumas tabelas acabam sendo divididas em duas ou mais tabelas. Esse processo causa a simplificao dos atributos de uma tabela, contribuindo significativamente para a estabilidade do modelo de dados, reduzindo-se consideravelmente as necessidades de manuteno. Inicialmente Codd estabeleceu trs Formas Normais, chamando-as de Primeira, Segunda e Terceira Formas Normais. Uma definio mais forte da Terceira Forma Normal foi depois proposta por Boyce e Codd, chamada Forma Normal Boyce-Codd. Depois uma Quarta e uma Quinta Formas Normais foram propostas, baseadas nos conceitos de dependncias multivaloradas e de juno, respectivamente: Primeira Forma Normal, ou 1FN Segunda Forma Normal, ou 2FN Terceira Forma Normal, ou 3FN Forma Normal Boyce-Codd, ou FNBC ou BCNF Quarta Forma Normal, ou 4FN

5. 4 Quinta Forma Normal, ou 5FN Cada uma das formas normais representa uma condio mais forte que a anterior na lista, mas para a maioria dos efeitos prticos, considera-se que as bases de dados esto normalizadas se aderirem Terceira Forma Normal. Outro ponto a notar que os projetistas de um banco de dados no precisam normalizar at a forma normal mais alta possvel. As relaes podem permanecer em um estado de normalizao mais baixo, como 2FN, por razes de desempenho. (ELMASRI; NAVATHE, 2005 apud NISHIMURA, 2009, p. 81). O processo sequencial, iniciando pela 1FN. No possvel pular uma forma normal, assim como no possvel fazer uma forma normal errada e passar para a prxima. Se uma tabela obedece s regras de uma forma normal, esta obedece igualmente s regras das formas normais anteriores. Uma tabela est na Primeira Forma Normal quando seus atributos no contm grupos de Repetio, ou tambm, a 1FN requer que todos os valores de colunas em uma tabela sejam atmicos (indivisveis). necessrio identificar atributos que representam o armazenamento de um mesmo dado em locais diferentes; atributos repetidos; atributos com mais de uma ocorrncia. Uma regra de ouro para a 1FN no misturar assuntos em uma mesma tabela (BATTISTI, 2004). Ao identificar esses erros, os atributos devem ser transferidos para uma nova tabela (ou tabelas), mantendo um relacionamento com a tabela original. As tabelas resultantes devem obedecer 1FN. Para aplicar as regras das formas normais seguintes necessrio entender de Dependncia Funcional. Existe dependncia funcional X Y entre dois atributos X e Y, se os valores de X determinam os valores de Y. Se em um novo registro da tabela, o valor de X se repetir, obrigatoriamente o valor de Y tambm se repetir. A Segunda Forma Normal ocorre quando a chame primria composta por mais de um campo. Se uma tabela est na 1FN e possui chave primria simples, j est automaticamente na 2FN. Uma tabela, para estar na 2FN, no pode conter dependncia funcional entre seus atributos no-chave com apenas parte de sua chave primria, isto , cada atributo no-chave deve ser dependente da chave primria inteira. Com as dependncias encontradas, divide-se a tabela em duas (ou 6. 5 mais) outras tabelas, mantendo as tabelas resultantes na 2FN. Battisti (2004) explica a Terceira Forma Normal: Na definio dos campos de uma entidade podem ocorrer casos em que um campo no seja dependente diretamente da chave primria ou de parte dela, mas sim dependente de outro campo da tabela, campo este que no a Chave Primria. Para estar na 3FN, a relao R deve obedecer a 2FN e no pode conter dependncias funcionais dos atributos nochave com outros atributos no- chave. Mais uma vez se divide a tabela em outras para solucionar o problema encontrado. As tabelas resultantes devem obedecer 3FN. A 3FN aquela que, na maioria dos casos, termina o processo de normalizao. 7. 6 2 PADRO SQL A linguagem SQL (Structured Query Language, ou Linguagem Estruturada de Consulta) uma linguagem de pesquisa declarativa para bancos de dados relacionais. Foi desenvolvida pela IBM nos anos 70 como uma interface para o System R, um sistema experimental de um banco de dados relacional que tinha por objetivo demonstrar a viabilidade da implementao do modelo relacional proposto por Codd. A sua grande vantagem sobre os modelos anteriores, dada sua linguagem no procedural e manipulao de conjuntos de dados com um nico comando, a torna uma das maiores razes para o sucesso dos SGBDs comerciais. Embora criada pela IBM, rapidamente surgiram vrios

dialetos desenvolvidos por outros produtores. Essa rpida expanso levou necessidade de uma padronizao da linguagem. Na dcada de 80, a ANSI (American National Standards Institute Instituto Nacional Americano de Padres) e a ISO (International Standards Organization Organizao Internacional de Padres) chegaram verso padro da SQL, chamada SQL-86 ou SQL1. Houve ainda uma reviso em 1992 (SQL-92 ou SQL2) e outra em 1999 (SQL-99 ou SQL3). A adoo da linguagem SQL por vrios SGBDs permite que os programadores sejam mais independentes do SGBD, podendo escrever declaraes em um programa aplicativo e acessar os dados em dois ou mais SGBDs relacionais, sem ter de alterar a SQL em ambos SGBDs. A SQL uma linguagem abrangente, possuindo comandos que definem e manipulam a estrutura de armazenamento e procedimentos (DDL) e comandos de manipulao de dados (DML). Os comandos DDL (Data Definition Language Linguagem de Definio de Dados) permitem a criao e manuteno da estrutura de armazenamento de um SGBD, como tabelas, colunas etc. Esses comandos no acessam dados, mas interferem em sua existncia e forma de armazenamento ou acesso. Comandos bsicos da DDL: CREATE (cria um objeto (uma tabela, por exemplo) dentro de um banco de dados). 8. 7 DROP (apaga um objeto dentro de banco de dados). ALTER (existente em alguns SGBDs, permite que o usurio altere um objeto do banco de dados, adicionando uma coluna a uma tabela, por exemplo). Os comandos DML (Data Manipulation Language Linguagem de Manipulao de Dados) permitem gravar, consultar, alterar ou apagar dados de um banco de dados. Alguns comandos bsicos: SELECT (o comando mais usado permite ao usurio especificar uma query com uma descrio do resultado desejado). INSERT (usado para inserir uma linha (tupla) a uma tabela existente). UPDATE (modifica dados previamente armazenados). DELETE (remove registros (linhas) de uma tabela). H outras partes da SQl, como a DCL (Data Control Language Linguagem de Controle de Dados) que controla aspectos de autorizao de dados e licenas de usurios; a DTL (Data Transaction Language Linguagem de Transao de Dados), onde esto inseridos os comandos COMMIT e ROLLBACK, que, respectivamente, confirma a transao e desfaz a transao de forma permanente; e ainda a DQL (Data Query Language Linguagem de Consulta de Dados), que faz parte do comando SQL mais utilizado, o SELECT, que composto de vrias clusulas (FROM, WHERE, GROUP BY etc.) e opes (operadores lgicos e relacionais e funes de agregao) que possibilitam elaborar consultas simples ou mais elaboradas. 9. 8 3 PROCESSAMENTO DE TRANSAES Um banco de dados composto de tabelas inter-relacionadas umas com as outras, representando um Diagrama Entidade Relacionamento DER, modelado segundo conceito de um Modelo Entidade Relacionamento MER. Num banco de dados, h quatro aes que podem ser efetuadas, consistindo em gravar, consultar, modificar e remover dados. Todas as aes citadas provocam alteraes nos dados armazenados, com exceo da ao de consulta. Essas aes so realizadas atravs das seguintes operaes: Gravar (INSERIR) dados; Consultar dados; Modificar (ATUALIZAR) dados; Remover (DELETAR) dados. As operaes bsicas usadas em Bancos de Dados Relacionais so definidas pelo acrnimo CRUD: Create, Retrieve, Update e Delete (INSERT, SELECT, UPDATE e DELETE, no padro ISO/SQL). Quando as operaes que alteram dados so executadas, o banco de dados realiza uma Transao. Uma transao pode ter uma ou diversas

operaes. Dentro de uma transao, tambm possvel ter uma ou vrias operaes de consulta de dados, no interferindo na integridade e consistncia do banco de dados. Um Sistema Gerenciador de Banco de Dados (SGBD) precisa deve sempre garantir a integridade e consistncia dos dados armazenados, para garantir o cumprimento das regras de negcio estabelecidas. Para tanto uma Transao deve aplicar o conceito ACID e suas quatro propriedades fundamentais: Atomicidade; Consistncia; Integridade (ou Isolamento); e Durabilidade. O conceito ACID garante que uma transao no pode ser dividida em partes (Atomicidade), devendo ser realizada por inteiro. Todas as operaes da transao devem ser realizadas, ou nenhuma delas. As regras de negcio devem ser executadas e cumpridas sempre. Ao final de uma transao, a Consistncia dos dados deve continuar, como antes do incio da transao. Independente de outras transaes simultneas, a transao deve ser executada isoladamente, cumprindo as regras de negcio durante as operaes, permanecendo a Integridade do banco 10. 9 de dados ao final da transao. A Durabilidade deve garantir que aps a realizao de uma transao, os dados adicionados e modificados no banco de dados devem permanecer e os dados removidos no devem retornar, a no ser que outra transao realize essas operaes. As operaes COMMIT e ROLLBACK so comandos que garantem a atomicidade de uma transao, confirmando ou no sua execuo. COMMIT indica o final de uma transao bem-sucedida, com todas as operaes executadas, mantendo a consistncia do banco de dados. ROLLBACK, ao contrrio, indica uma transao mal-sucedida, informando ao sistema que algo saiu errado, que alguma operao no foi ou no pde ser executada, e que as operaes j realizadas devem ser desfeitas. Para que um SGBD realize as operaes de retornar ao estado original do banco de dados, este utiliza tcnicas de transaes de logs: Quando executada uma operao que modifica os dados, o SGBD escreve um registro de transao no log, gerando duas cpias de cada linha afetada pelo comando, uma mostrando a linha antes da alterao e outra mostrando a linha depois da alterao. Somente aps o log ser escrito que o SGBD modifica a linha no banco de dados. Se for executado um comando ROLLBACK, o SGBD examina o log para encontrar os registros anteriores modificao. Com esses registros, o SGBD restaura as linhas modificadas para o estado anterior, cancelando todas as alteraes feitas no banco de dados durante a transao. Na prtica, os principais SGBDs comerciais usam tcnicas de logs mais sofisticadas que a descrita acima, como a utilizao de pontos de verificao (checkpoints) para reduzir o nmero de registros de log que precisaro ser lidos durante a recuperao do banco de dados. Esses checkpoints so identificados em cada comando COMMIT ou START das transaes. Duas listas so criadas: uma lista refaz e uma lista desfaz. Toda transao identificada com um COMMIT includa na lista refaz. Cada transao identificada com um START e que no estiver na lista refaz, vai para a lista desfaz. A leitura do log realizada do final para o comeo at localizar o checkpoint. Quando este localizado, o SBGD l o log no sentido inverso e para cada transao que estiver na lista desfaz, o processo UNDO executado. A leitura continua at o ltimo START da lista desfaz, ento varre o log para frente e executa um comando REDO para cada transao da lista refaz. 11. 10 4 CONTROLE DE CONCORRNCIA O grande desafio de um SGBD a capacidade de tratar diversas transaes simultaneamente. A execuo

concorrente de programas dos usurios essencial para o bom desempenho do SGBD. Quando dois ou mais usurio acessam um banco de dados ao mesmo tempo, os processos de transaes tomam uma nova dimenso. Agora o SGBD deve no somente recuperar falha ou erros de uma transao, mais ainda, a transao de um usurio no pode interferir nas transaes de outros usurios. Por mais que as transaes, isoladamente, preservem a consistncia do banco de dados, se forem executadas concorrentemente, sem nenhum controle, anomalias de sincronizao podero ocorrer, como a perda de consistncia do banco de dados, acesso a dados inconsistentes e perda de atualizaes. Para evitar essas anomalias, surge o conceito de serializao, ou escalonamento das execues. A serializao garante que as transaes que so executadas concorrentemente tenham o mesmo efeito de que se fossem executadas em sequncia. Um modo de assegurar a seriabilidade atravs de tcnicas de bloqueio (locks) de dados. Quando uma transao T acessa um item do banco de dados, nenhuma outra transao concorrente (X) pode modificar aquele item, que est bloqueado pela transao T at o trmino da mesma. Muitos SGBDs usam dois tipos de bloqueios: compartilhado (para leitura de dados) e exclusivo (para gravao, modificao e eliminao de dados). No bloqueio compartilhado (shared), uma transao obtm o bloqueio de um item do banco de dados para leitura do mesmo e permite que outra transao possa obter um bloqueio (de modo compartilhado) e leia este mesmo item. Nenhuma das transaes poder gravar este item. No bloqueio exclusivo (exclusive), uma transao que obtenha o bloqueio de um item do banco de dados para gravao, nenhuma outra transao poder obter bloqueio (compartilhado ou exclusivo) deste item. Um problema que pode ocorrer com o uso de bloqueios o DEADLOCK. Quando uma transao A espera um recurso bloqueado pela 12. 11 transao B para finalizar e a transao B igualmente espera um recurso da transao A para finalizar, ficando as duas transaes nesse impasse. Para resolver o deadlock, o SGBD arbitrariamente elimina uma das transaes, liberando os bloqueios para a outra transao. Um dos protocolos que garante a serializao o protocolo de bloqueio em duas fases (two-phase locking protocol), que exige que cada transao emita suas solicitaes de bloqueio e desbloqueio em duas fases distintas: expanso e encolhimento. Uma transao s tem incio quando ela consegue adquirir todos os bloqueios necessrios, entrando em fase de expanso, onde no pode ainda liberar nenhum dos bloqueios feitos. Todos os pedidos de bloqueios devem ocorrer antes do primeiro desbloqueio. Uma vez que a transao libera o primeiro bloqueio, esta entra em fase de encolhimento, onde no poder solicitar nenhum outro bloqueio at concluir as operaes. S ento poder iniciar outra transao, entrando novamente em fase de expanso solicitando novos bloqueios. 13. 12 REFERNCIAS BATTISTI, Jlio. O modelo relacional de dados parte 04. In: iMasters, por uma internet mais criativa e dinmica. 2004. Disponvel em <http://imasters.uol.com.br/artigo/2521/bancodedados/o_modelo_relacional_de_ dad os_-_parte_04/>. Acesso em: 12 mar. 2009. CASANOVA, Marco A; MOURA, Arnaldo V. Princpios de Sistemas de Gerncia de Bancos de Dados Distribudos. 1999. Disponvel em <http://www.inf.puc- rio.br/~casanova/>. Acesso em 19 mar. 2009. MACHADO J. e ABELHA A. Bases de dados relacionais. Texto de apoio. Universidade do Minho, Departamento de Informtica, Braga, Portugal, 2004. Disponvel em <http://gia1.di.uminho.pt/gia/pdfs/BD1.pdf>. Acesso em: 12 mar. 2009.

MODELO relacional. In: WIKIPDIA, a enciclopdia livre, 2009. Disponvel em <http://pt.wikipedia.org/wiki/Modelo_relacional>. Acesso em: 12 mar. 2009. NISHIMURA, Roberto Yukio (Org.). Banco de dados II. So Paulo: Pearson Education do Brasil, 2009. NORMALIZAO de dados. In: WIKIPDIA, a enciclopdia livre, 2009. Disponvel em <http://pt.wikipedia.org/wiki/Normaliza%C3%A7%C3%A3o_de_dados>. Acesso em: 12 mar. 2009. REVERBEL, Francisco. Gerncia de Transaes. Slide de apoio. Universidade de So Paulo USP, Instituto de Matemtica e Estatstica, Departamento de Cincia da Computao, 2000. Disponvel em <http://www.ime.usp.br/~reverbel/BD- 00/Slides/s08.pdf>. Acesso em 19 mar. 2009. SALGADO, Ana C.; FONSECA, Fernando e TIMES, Valria. Modelo Relacional. Slide de apoio. Centro de Informtica da Universidade Federal de Pernambuco, 2002. Disponvel em <http://www.di.ufpe.br/~if559/slides/modrel1.ppt>. Acesso em: 12 mar. 2009. SANTOS JR., Joaquim V. dos; BARROS, Estevam A. de; LELES, Ginaldo R. Processamento de Transaes. Trabalho acadmico. Universidade Federal de Gois, Instituto de Informtica, 2002. Disponvel em <http://www.inf.ufg.br/~juliano/ensino/especializacao/cursoapsi/2001/Processa mento deTransacoes.doc>. Acesso em: 19 mar. 2009. SQL. In: WIKIPDIA, a enciclopdia livre, 2009. Disponvel em <http://pt.wikipedia.org/wiki/SQL>. Acesso em: 14 mar. 2009.

Você também pode gostar