SISTEMA DE ENSINO PRESENCIAL CONECTADO
TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

            TARCÍSIO CAVALCANT...
TARCÍSIO CAVALCANTE UCHÔA




 ATIVIDADE PORTFOLIO
    BANCO DE DADOS II




         Trabalho apresentado ao Curso Tecnol...
SUMÁRIO




1     MODELO RELACIONAL NORMALIZADO – MRN ............................................. 3


2     PADRÃO SQL ....
3


1 MODELO RELACIONAL NORMALIZADO – MRN


               Num projeto de banco de dados é necessário identificar os dados...
4


               •   Quinta Forma Normal, ou 5FN
               Cada uma das formas normais representa uma condição mais...
5


mais) outras tabelas, mantendo as tabelas resultantes na 2FN.
                Battisti (2004) explica a Terceira Forma...
6


2 PADRÃO SQL


               A linguagem SQL (Structured Query Language, ou Linguagem
Estruturada de Consulta) é uma ...
7


               •   DROP (apaga um objeto dentro de banco de dados).
               •   ALTER (existente em alguns SGBD...
8


3 PROCESSAMENTO DE TRANSAÇÕES


               Um banco de dados é composto de tabelas inter-relacionadas umas
com as ...
9


de dados ao final da transação. A Durabilidade deve garantir que após a realização
de uma transação, os dados adiciona...
10


4 CONTROLE DE CONCORRÊNCIA


                O grande desafio de um SGBD é a capacidade de tratar diversas
transações...
11


transação B para finalizar e a transação B igualmente espera um recurso da
transação A para finalizar, ficando as dua...
12


                                 REFERÊNCIAS


BATTISTI, Júlio. O modelo relacional de dados – parte 04. In: iMasters...
Upcoming SlideShare
Loading in...5
×

Unopar Virtual - Portfólio Módulo 3 - Bancos de Dados II - Tarcisio

11,121

Published on

Trabalho apresentado ao Curso Tecnológico em Análise e Desenvolvimento de Sistemas da UNOPAR - Universidade Norte do Paraná, para o Módulo 3 - Fundamentos dos Sistemas de Informação.

Orientador: Prof. Prof. Roberto Y. Nishimura.

Tarcisio Cavalcante Uchoa
Curitiba, março de 2009

Published in: Education
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
11,121
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

Transcript of "Unopar Virtual - Portfólio Módulo 3 - Bancos de Dados II - Tarcisio "

  1. 1. SISTEMA DE ENSINO PRESENCIAL CONECTADO TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS TARCÍSIO CAVALCANTE UCHÔA SISTEMA DE ENSINO PRESENCIAL CONECTADO ATIVIDADE PORTFOLIO BANCO DE DADOS II Curitiba 2009
  2. 2. TARCÍSIO CAVALCANTE UCHÔA ATIVIDADE PORTFOLIO BANCO DE DADOS II Trabalho apresentado ao Curso Tecnológico em Análise e Desenvolvimento de Sistemas da UNOPAR - Universidade Norte do Paraná, para o Módulo 3 - Fundamentos dos Sistemas de Informação. Orientador: Prof. Prof. Roberto Y. Nishimura. Curitiba 2009
  3. 3. SUMÁRIO 1 MODELO RELACIONAL NORMALIZADO – MRN ............................................. 3 2 PADRÃO SQL ..................................................................................................... 6 3 PROCESSAMENTO DE TRANSAÇÕES ............................................................ 8 4 CONTROLE DE CONCORRÊNCIA .................................................................. 10 REFERÊNCIAS ......................................................................................................... 12
  4. 4. 3 1 MODELO RELACIONAL NORMALIZADO – MRN Num projeto de banco de dados é necessário 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 são baseados no Modelo Relacional de Dados, que tem o princípio de que todos os dados são 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 situações de difícil implementação prática. Para resolver isso, Codd propôs um processo de Normalização de Dados (ou normalização de tabelas) que aplica uma série de regras às tabelas de um banco de dados, para verificar se estas estão corretamente projetadas. O objetivo da normalização é evitar problemas provocados por falhas no projeto do banco de dados, eliminando redundâncias e evitando problemas com inserção, eliminação e atualização de dados. Com a normalização bem sucedida, o espaço de armazenamento de dados diminui, as tabelas podem ser atualizadas com maior eficiência. Normalmente após a aplicação das Regras de Normalização, algumas tabelas acabam sendo divididas em duas ou mais tabelas. Esse processo causa a simplificação dos atributos de uma tabela, contribuindo significativamente para a estabilidade do modelo de dados, reduzindo-se consideravelmente as necessidades de manutenção. Inicialmente Codd estabeleceu três Formas Normais, chamando-as de Primeira, Segunda e Terceira Formas Normais. Uma definição 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 dependências multivaloradas e de junção, 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. 5. 4 • Quinta Forma Normal, ou 5FN Cada uma das formas normais representa uma condição mais forte que a anterior na lista, mas para a maioria dos efeitos práticos, considera-se que as bases de dados estão normalizadas se aderirem à Terceira Forma Normal. “Outro ponto a notar é que os projetistas de um banco de dados não precisam normalizar até a forma normal mais alta possível. As relações podem permanecer em um estado de normalização mais baixo, como 2FN, por razões de desempenho.” (ELMASRI; NAVATHE, 2005 apud NISHIMURA, 2009, p. 81). O processo é sequencial, iniciando pela 1FN. Não é possível “pular” uma forma normal, assim como não é possível fazer uma forma normal errada e passar para a próxima. 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 não contêm grupos de Repetição, ou também, a 1FN requer que todos os valores de colunas em uma tabela sejam atômicos (indivisíveis). É necessário identificar atributos que representam o armazenamento de um mesmo dado em locais diferentes; atributos repetidos; atributos com mais de uma ocorrência. Uma “regra de ouro” para a 1FN é não 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 é necessário entender de Dependência Funcional. Existe dependência 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 também se repetirá. A Segunda Forma Normal ocorre quando a chame primária é composta por mais de um campo. Se uma tabela está na 1FN e possui chave primária simples, já está automaticamente na 2FN. Uma tabela, para estar na 2FN, não pode conter dependência funcional entre seus atributos não-chave com apenas parte de sua chave primária, isto é, cada atributo não-chave deve ser dependente da chave primária inteira. Com as dependências encontradas, divide-se a tabela em duas (ou
  6. 6. 5 mais) outras tabelas, mantendo as tabelas resultantes na 2FN. Battisti (2004) explica a Terceira Forma Normal: Na definição dos campos de uma entidade podem ocorrer casos em que um campo não seja dependente diretamente da chave primária ou de parte dela, mas sim dependente de outro campo da tabela, campo este que não a Chave Primária. Para estar na 3FN, a relação R deve obedecer a 2FN e não pode conter dependências funcionais dos atributos não-chave com outros atributos não- 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 normalização.
  7. 7. 6 2 PADRÃO 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 implementação do modelo relacional proposto por Codd. A sua grande vantagem sobre os modelos anteriores, dada sua linguagem não procedural e manipulação de conjuntos de dados com um único comando, a torna uma das maiores razões para o sucesso dos SGBDs comerciais. Embora criada pela IBM, rapidamente surgiram vários “dialetos” desenvolvidos por outros produtores. Essa rápida expansão levou à necessidade de uma padronização da linguagem. Na década de 80, a ANSI (American National Standards Institute – Instituto Nacional Americano de Padrões) e a ISO (International Standards Organization – Organização Internacional de Padrões) chegaram à versão padrão da SQL, chamada SQL-86 ou SQL1. Houve ainda uma revisão em 1992 (SQL-92 ou SQL2) e outra em 1999 (SQL-99 ou SQL3). A adoção da linguagem SQL por vários SGBDs permite que os programadores sejam mais independentes do SGBD, podendo escrever declarações 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 manipulação de dados (DML). Os comandos DDL (Data Definition Language – Linguagem de Definição de Dados) permitem a criação e manutenção da estrutura de armazenamento de um SGBD, como tabelas, colunas etc. Esses comandos não acessam dados, mas interferem em sua existência e forma de armazenamento ou acesso. Comandos básicos da DDL: • CREATE (cria um objeto (uma tabela, por exemplo) dentro de um banco de dados).
  8. 8. 7 • DROP (apaga um objeto dentro de banco de dados). • ALTER (existente em alguns SGBDs, permite que o usuário altere um objeto do banco de dados, adicionando uma coluna a uma tabela, por exemplo). Os comandos DML (Data Manipulation Language – Linguagem de Manipulação de Dados) permitem gravar, consultar, alterar ou apagar dados de um banco de dados. Alguns comandos básicos: • SELECT (o comando mais usado permite ao usuário especificar uma query com uma descrição 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 autorização de dados e licenças de usuários; a DTL (Data Transaction Language – Linguagem de Transação de Dados), onde estão inseridos os comandos COMMIT e ROLLBACK, que, respectivamente, confirma a transação e desfaz a transação 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 várias cláusulas (FROM, WHERE, GROUP BY etc.) e opções (operadores lógicos e relacionais e funções de agregação) que possibilitam elaborar consultas simples ou mais elaboradas.
  9. 9. 8 3 PROCESSAMENTO DE TRANSAÇÕES 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 ações que podem ser efetuadas, consistindo em gravar, consultar, modificar e remover dados. Todas as ações citadas provocam alterações nos dados armazenados, com exceção da ação de consulta. Essas ações são realizadas através das seguintes operações: • Gravar (INSERIR) dados; • Consultar dados; • Modificar (ATUALIZAR) dados; • Remover (DELETAR) dados. As operações básicas usadas em Bancos de Dados Relacionais são definidas pelo acrônimo CRUD: Create, Retrieve, Update e Delete (INSERT, SELECT, UPDATE e DELETE, no padrão ISO/SQL). Quando as operações que alteram dados são executadas, o banco de dados realiza uma Transação. Uma transação pode ter uma ou diversas operações. Dentro de uma transação, também é possível ter uma ou várias operações de consulta de dados, não interferindo na integridade e consistência do banco de dados. Um Sistema Gerenciador de Banco de Dados (SGBD) precisa deve sempre garantir a integridade e consistência dos dados armazenados, para garantir o cumprimento das regras de negócio estabelecidas. Para tanto uma Transação deve aplicar o conceito ACID e suas quatro propriedades fundamentais: Atomicidade; Consistência; Integridade (ou Isolamento); e Durabilidade. O conceito ACID garante que uma transação não pode ser dividida em partes (Atomicidade), devendo ser realizada por inteiro. Todas as operações da transação devem ser realizadas, ou nenhuma delas. As regras de negócio devem ser executadas e cumpridas sempre. Ao final de uma transação, a Consistência dos dados deve continuar, como antes do início da transação. Independente de outras transações simultâneas, a transação deve ser executada isoladamente, cumprindo as regras de negócio durante as operações, permanecendo a Integridade do banco
  10. 10. 9 de dados ao final da transação. A Durabilidade deve garantir que após a realização de uma transação, os dados adicionados e modificados no banco de dados devem permanecer e os dados removidos não devem retornar, a não ser que outra transação realize essas operações. As operações COMMIT e ROLLBACK são comandos que garantem a atomicidade de uma transação, confirmando ou não sua execução. COMMIT indica o final de uma transação bem-sucedida, com todas as operações executadas, mantendo a consistência do banco de dados. ROLLBACK, ao contrário, indica uma transação mal-sucedida, informando ao sistema que algo saiu errado, que alguma operação não foi ou não pôde ser executada, e que as operações já realizadas devem ser desfeitas. Para que um SGBD realize as operações de retornar ao estado original do banco de dados, este utiliza técnicas de transações de logs: Quando é executada uma operação que modifica os dados, o SGBD escreve um registro de transação no log, gerando duas cópias de cada linha afetada pelo comando, uma mostrando a linha antes da alteração e outra mostrando a linha depois da alteração. Somente após 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 à modificação. Com esses registros, o SGBD restaura as linhas modificadas para o estado anterior, cancelando todas as alterações feitas no banco de dados durante a transação. Na prática, os principais SGBDs comerciais usam técnicas de logs mais sofisticadas que a descrita acima, como a utilização de pontos de verificação (checkpoints) para reduzir o número de registros de log que precisarão ser lidos durante a recuperação do banco de dados. Esses checkpoints são identificados em cada comando COMMIT ou START das transações. Duas listas são criadas: uma lista “refaz” e uma lista “desfaz”. Toda transação identificada com um COMMIT é incluída na lista “refaz”. Cada transação identificada com um START e que não estiver na lista “refaz”, vai para a lista “desfaz”. A leitura do log é realizada do final para o começo até localizar o checkpoint. Quando este é localizado, o SBGD lê o log no sentido inverso e para cada transação que estiver na lista “desfaz”, o processo UNDO é executado. A leitura continua até o último START da lista “desfaz”, então varre o log para frente e executa um comando REDO para cada transação da lista “refaz”.
  11. 11. 10 4 CONTROLE DE CONCORRÊNCIA O grande desafio de um SGBD é a capacidade de tratar diversas transações simultaneamente. A execução concorrente de programas dos usuários é essencial para o bom desempenho do SGBD. Quando dois ou mais usuário acessam um banco de dados ao mesmo tempo, os processos de transações tomam uma nova dimensão. Agora o SGBD deve não somente recuperar falha ou erros de uma transação, mais ainda, a transação de um usuário não pode interferir nas transações de outros usuários. Por mais que as transações, isoladamente, preservem a consistência do banco de dados, se forem executadas concorrentemente, sem nenhum controle, anomalias de sincronização poderão ocorrer, como a perda de consistência do banco de dados, acesso a dados inconsistentes e perda de atualizações. Para evitar essas anomalias, surge o conceito de serialização, ou escalonamento das execuções. A serialização garante que as transações que são executadas concorrentemente tenham o mesmo efeito de que se fossem executadas em sequência. Um modo de assegurar a seriabilidade é através de técnicas de bloqueio (locks) de dados. Quando uma transação T acessa um item do banco de dados, nenhuma outra transação concorrente (X) pode modificar aquele item, que está bloqueado pela transação T até o término da mesma. Muitos SGBDs usam dois tipos de bloqueios: compartilhado (para leitura de dados) e exclusivo (para gravação, modificação e eliminação de dados). No bloqueio compartilhado (shared), uma transação obtém o bloqueio de um item do banco de dados para leitura do mesmo e permite que outra transação possa obter um bloqueio (de modo compartilhado) e leia este mesmo item. Nenhuma das transações poderá gravar este item. No bloqueio exclusivo (exclusive), uma transação que obtenha o bloqueio de um item do banco de dados para gravação, nenhuma outra transação poderá obter bloqueio (compartilhado ou exclusivo) deste item. Um problema que pode ocorrer com o uso de bloqueios é o DEADLOCK. Quando uma transação A espera um recurso bloqueado pela
  12. 12. 11 transação B para finalizar e a transação B igualmente espera um recurso da transação A para finalizar, ficando as duas transações nesse impasse. Para resolver o deadlock, o SGBD arbitrariamente elimina uma das transações, liberando os bloqueios para a outra transação. Um dos protocolos que garante a serialização é o protocolo de bloqueio em duas fases (two-phase locking protocol), que exige que cada transação emita suas solicitações de bloqueio e desbloqueio em duas fases distintas: expansão e encolhimento. Uma transação só tem início quando ela consegue adquirir todos os bloqueios necessários, entrando em fase de expansão, onde não pode ainda liberar nenhum dos bloqueios feitos. Todos os pedidos de bloqueios devem ocorrer antes do primeiro desbloqueio. Uma vez que a transação libera o primeiro bloqueio, esta entra em fase de encolhimento, onde não poderá solicitar nenhum outro bloqueio até concluir as operações. Só então poderá iniciar outra transação, entrando novamente em fase de expansão solicitando novos bloqueios.
  13. 13. 12 REFERÊNCIAS BATTISTI, Júlio. O modelo relacional de dados – parte 04. In: iMasters, por uma internet mais criativa e dinâmica. 2004. Disponível 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. Princípios de Sistemas de Gerência de Bancos de Dados Distribuídos. 1999. Disponível 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 Informática, Braga, Portugal, 2004. Disponível em <http://gia1.di.uminho.pt/gia/pdfs/BD1.pdf>. Acesso em: 12 mar. 2009. MODELO relacional. In: WIKIPÉDIA, a enciclopédia livre, 2009. Disponível em <http://pt.wikipedia.org/wiki/Modelo_relacional>. Acesso em: 12 mar. 2009. NISHIMURA, Roberto Yukio (Org.). Banco de dados II. São Paulo: Pearson Education do Brasil, 2009. NORMALIZAÇÃO de dados. In: WIKIPÉDIA, a enciclopédia livre, 2009. Disponível em <http://pt.wikipedia.org/wiki/Normaliza%C3%A7%C3%A3o_de_dados>. Acesso em: 12 mar. 2009. REVERBEL, Francisco. Gerência de Transações. Slide de apoio. Universidade de São Paulo – USP, Instituto de Matemática e Estatística, Departamento de Ciência da Computação, 2000. Disponível em <http://www.ime.usp.br/~reverbel/BD- 00/Slides/s08.pdf>. Acesso em 19 mar. 2009. SALGADO, Ana C.; FONSECA, Fernando e TIMES, Valéria. Modelo Relacional. Slide de apoio. Centro de Informática da Universidade Federal de Pernambuco, 2002. Disponível 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 Transações. Trabalho acadêmico. Universidade Federal de Goiás, Instituto de Informática, 2002. Disponível em <http://www.inf.ufg.br/~juliano/ensino/especializacao/cursoapsi/2001/Processamento deTransacoes.doc>. Acesso em: 19 mar. 2009. SQL. In: WIKIPÉDIA, a enciclopédia livre, 2009. Disponível em <http://pt.wikipedia.org/wiki/SQL>. Acesso em: 14 mar. 2009.

×