Banco de Dados I Aula 07/10

Formas Normais
Normalizao um processo a partir do qual se aplicam regras a todas as tabelas do BD
com o objetivo de evitar falhas no projeto, como redundncia de dados e mistura de
diferentes assuntos numa mesma tabela.
Ao projetar um BD, se temos um modelo de entidades e relacionamentos e a partir de
construirmos o modelo relacional seguindo as regras de transformao corretamente, o
modelo relacional resultante estar, provavelmente, normalizado. Mas nem sempre os
modelos que nos deparamos so implementados dessa forma e, quando isso acontece, o
suporte ao BD dificultado em ambos os casos, necessrio aplicar as tcnicas de
normalizao, ou para normalizar (se caso citado), ou apenas validar o esquema criado
(primeiro caso citado). Aplicando as regras descritas a seguir, possvel garantir um BD
mais ntegro, sem redundncias e inconsistncias.
Primeira Forma Normal 1FN
Dizemos que uma entidade est na 1FN quando no h itens repetidos (itens
multivalorados) dentro dela, ou seja, somente devem existir valores atmicos
(indivisveis) nos atributos das tuplas assim, para converter uma entidade no
normalizada na 1FN, precisamos decomp-la em tantas entidades quantas forem
necessrias para no ter itens repetidos.
Em outras palavras podemos definir que a 1FN no admite repeties ou campos que
tenham mais de um valor.
Procedimentos:
Identificar a chave primria da entidade;
Identificar o grupo repetitivo e remove-lo da entidade;
Criar uma nova entidade com a chave primria da entidade anterior e o grupo
repetitivo.
Exemplo de 1FN
Considere a tabela cliente: cod_cliente, nome, telefone e endereo.


Cod_cliente Nome Telefone Endereo
C001 Jos 9563-6312
9847-2501
Rua Seis, 85 Morumbi 12536-965
C002 Maria 3265-8596 Rua Onze, 64 Moema 65985-963
C003 Jonas 8545-8956
9598-6301
Praa Ramos Liberdade 68858-633
Separando os itens multivalorados:
Cod_cliente Nome Telefone Rua Bairro CEP
C001 Jos 9563-6312
9847-2501
Rua Seis, 85 Morumbi 12536-965
C002 Maria 3265-8596 Rua Onze, 64 Moema 65985-963
C003 Jonas 8545-8956
9598-6301
Praa Ramos Liberdade 68858-633





Exerccio
Montar na 1FN
Matrcula Nome Turma Telefone Unidade
C001 Maria da Silva Biologia ECO1 9999-8888
8888-9999
Principal Realengo
C002 Paula de Souza Biologia ECO2 2222-3333
8888-4444
Campus 2 Realengo
C003 Claudia Fonseca Psicologia MEME1 3333-4444 Praia Barra
C004 Wiza Arruda Psicologia FREUD 3333-2222
4444-5555
Praia Barra

Separando os itens multivalorados:










Cod_cliente Nome Rua Bairro CEP
C001 Jos Rua Seis, 85 Morumbi 12536-965
C002 Maria Praa Onze, 64 Moema 65985-963
C003 Jonas Praa Ramos Liberdade 68858-633
Cod_cliente Telefone
C001 9563-6312
C001 9847-8596
C002 3265-8596
C003 8545-8956
C003 95986301
Matrcula Nome Sobrenome Disciplina Turma Unidade Bairro
C001 Maria da Silva Biologia ECO1 Principal Realengo
C002 Paula de Souza Biologia ECO2 Campus2 Realengo
C003 Claudia Fonseca Psicologia MEME1 Praia Barra
C004 Wiza Arruda Psicologia FREUD Praia Barra
Matrcula Telefone
C001 9999-8888
C001 8888-9999
C002 2222-3333
C002 8888-4444
C003 3333-4444
C004 3333-2222
C004 4444-5555
Banco de Dados I Aula 21/10

Segunda forma normal 2FN
Colocar as entidades na 2FN um pouco mais difcil, pois envolve o
conhecimento das dependncias funcionais. A entidade se encontra na 2FN se, alm de
estar na 1FN, todos os seus atributos so totalmente dependentes da chave primria, isso
significa que atributos que so parcialmente dependentes devem ser removidos.
Se o nome do produto j existe na tabela produtos, ento no necessrio que
ele exista na tabela vendas. A 2FN trata destas anomalias e evita que valores fiquem em
redundncia no B.D.
Procedimentos
- Identificar os atributos que no so funcionalmente de toda a chave primria.
- Remover da entidade todos esses atributos identificados e criar uma nova
entidade com eles.
A chave primria da nova entidade ser o atributo do qual os atributos
removidos so funcionalmente dependentes.
Exemplo: Tabela vendas (N Pedido, Cod_Protudo, Produto, Quant, Valor_Unit,
Subtotal)
N Pedido Cod_Produto Produto Quant Valor_Unit Subtotal
1005 1-934 Impressora Laser 5 1,500.00 7500,00
1006 1-956 Impressora Deskjet 3 350,00 1050,00
1007 1-923 Impressora Matricial 1 190,00 190,00
1008 1-900 Impressora Mobile 6 980,00 5880,00

Qual os atributos removidos so funcionalmente dependentes.
N Pedido Cod_Produto Quant Valor_Unit Subtotal
1005 1-1934 5 1500,00 7500,00
1006 1-956 3 350,00 1050,00
1007 1-923 1 190,00 190,00
1008 1-900 6 980,00 5880,00

N Pedido Subtotal
1005 7500,00
1006 1050,00
1007 190,00
1008 5880,00









Banco de Dados I Aula 28/10
Forma Normal de Boyce / Codd FNBC
A forma normal de Boyce / Codd foi desenvolvida com o objetivo de resolver
algumas situaes que no eram inicialmente cobertas pelas trs formas normais, em
especial quando haviam vrias chaves na entidade, formadas por mais de um atributo
(chaves compostas) e que ainda compartilham ao menos um atributo. Isso nos leva a
concluir que o problema se devia ao fato de at agora as formas normais trataram de
atributos dependentes de chaves primrias.
Assim, para estar na FNBC, uma entidade precisa possuir somente atributos que
so chaves candidatas.
Vamos analisar o caso em que temos uma entidade formada pelos seguintes
atributos:
Cod_Aluno, Cod_Curso, Cod_Turma, Cod_Professor
Cod_Aluno Cod_Curso Cod_Turma Cod_Professor
A001 SI01 1P 345
A002 DR01 2P 432
A003 AD01 3P 423

Um mesmo professor pode ministrar aulas entre cursos e turmas diferentes.
Sendo assim podemos identificar 3 chaves candidatas que so determinantes nessa
entidade:
Cod_Curso + Cod_Turma / Cod_Curso + Cod_Professor / CorTurma + CodProfessor
O atributo Cod_Professor parcialmente dependente do Cod_Curso e de
Cod_Turma, mas totalmente dependente da chaves candidata composta Cod_Curso +
Cod_Turma.
Desta forma a entidade deve ser desmembrada, resultando em duas: uma que
contm os atributos que descrevem o AWNO em si, e outra WJ01 atributos designam o
professor.
Cod_Aluno Cod_Turma Cod_Curso
A001 1P SI01
A002 2P DR01
A003 3P AD01



Gerncia de Transaes
Transaes
- Conceito bsico para controle de concorrncia e recuperao: A transao.
* Leituras (READS) e escritas (WRITES)
*Aes Especiais: Commit (Compromissamento ou efetivao de transao),
Abort ( Aborto de transao)
- O SGBD v cada transao como uma sequncia de leituras e escritas delimitada por
comandos BEGIN e Commit (ou ABort).
Cod_Turma Cod_Curso Cod_Professor
1P SI01 345
2P DR01 432
3P AD01 432

Concorrencia em um SGBD
- A execuo concorrente de programas dos usurios essencial para o bom
desempenho do SGBD.
*Como acessos a disco so frequentes e relativamente lentos, muito importante
manter a CPU ocupada executando vrios programas concorrentemente.
- Uma aplicao pode efetivar muitas operaes sobre os dados lidos de um BD, mas
para o SGBD s importam as leituras e as escritas realizadas.
- Usurios submetem transaes e podem pensar que cada transao roda sozinha, como
dona da mquina.
*A concorrncia implementada pelo SGBD, que entrelaa aes (READS /
WRITES de objetos no BD.) das vrias transaes.
*Cada transao deve deixar o BD em um estado consistente.
- O SGBD impes restries de integridade especificadas nos comandos CREATE
TABLE, mas no entende realmente a semntica dos dados (por exemplo: ele no sabe
computar os juros em uma conta de poupana)
-Questes: Efeitos de entrelaamento de transaes e de quedas do sistema.


Banco de Dados I Aula 04/11
As propriedades ACID
Atomicidade ou todas as aes da transao acontecem, ou nenhuma delas acontece.
Consistncia se a transao consistente e o BD comea consistente, ele termina
consistente.
Isolamento a execuo de uma transao isolada da execuo de outras transaes.
Durabilidade se uma transao concluda com sucesso (atravs de uma operao
COMMIT bem sucedida), ento seus efeitos so persistentes (durveis).
Satisfazendo as propriedades ACID
- Controle de concorrncia
*Garante a consistncia e o isolamento, dada a atomicidade das transaes.
Em um SGBD so tarefas do mdulo gerente de LOG.
- VOGGING e recuperao
*Garantem a atomicidade e a durabilidade.
Em um SGBD so tarefas do mdulo gerente de LOG.
Exemplo:
-Considere duas transaes:
T1: BEGIN | A= A+100 , B= B-100 | END
T2: BEGIN | A= 1.06*A , B = 1.06*B | END
-Intuitivamente, a primeira transao est transferindo R$ 100 da conta B para a conta
A. A segunda est creditando% de juros em ambas as contas.
-No h garantia que T1 vai executar antes de T2 ou vice-versa, se ambas forem
submetidas praticamente juntas. Contudo, o efeito invisvel tem de ser equivalente ao
dessas duas transaes rodando serialmente (uma depois da outra), em uma ordem
qualquer.
-Considere o seguinte entrelaamento (ESCALONAMENTO):
T1: A= A+100 B= B-100
T2: A= 1.06*A B= 1.06*B
-Tudo bem com o ESCALONAMENTO acima. Vejamos outro:
T1: A= A+100 B= 1.06*B
T2: A= 1.06*A , B= 1.06*B
-Como o SGBD v o segundo ESCALONAMENTO:
T1: R(A) , W(A) R(B) , W(B)
T2: R(A) , W(A) , R(B) , W(B)


O SGBD no pode permitir escalonamentos como este!
T1: R(A) , W(A) R(B) , W(B)
T2: R(A) , W(A) , R(B) , W(B)
Grafo de dependncias -------------
T1 T2
-------------

- Grafo de dependncias: Um n por transao, flecha de T1 para T2 se T2 ler ou
escrever um objeto escrito pela ltima vez por T1.
-O ciclo do grafo revela o problema. O resultado de T1 depende de T2 e vice-versa.
-Escalonamentos Equivalentes: Para qualquer estado do BD, o efeito (no conjunto
de objetos no BD) de executar um ESCALONAMENTO idntico ao efeito de
executar o outro ESCALONAMENTO.
-Escalonamento Serializvel: Um escalonamento que equivalente a uma execuo
serial das transaes.
-Se o grafo de dependncias de um escalonamento for acclico (no tiver ciclos),
dizemos que o ESCALONAMENTO serializvel quanto ao conflito (CONFLICT
SERIALIZABLE) tal ESCALONAMENTO equivalente a um escalonamento serial.
-Essa a condio que tipicamente assegurada pelos SGBDs. Ela suficiente
(mas no necessria) para que o ESCALONAMENTO seja serializvel.

Assegurando a Seriabilidade
Protocolo de travamento bifsico (TOW-PHASE LOCKING OU ZPL)
-Baseado em bloqueios ou travas (locks).
-Cada transao, antes de ler um objeto, precisa obter um bloqueio S (Shared ou
Compartilhado) sobre o objeto. Antes de escrever em um objeto, a transao precisa
obter um bloqueio X (exclusivo) sobre o objeto.
-Depois que uma transao retirar algum bloqueio ela no poder requisitar novos
bloqueios.
*Variao: O protocolo ZPL ESTRITO, no qual cada transao retm seus
bloqueios at ser efetivada (COMMIT) ou abortada.
Enquanto uma transao detiver algum bloqueio X sobre um objeto, nenhuma outra
transao conseguir um bloqueio (S ou X) sobre o objeto.
Banco de Dados I AULA 11/11
Atomicidade das transaes
-Uma transao pode dar um COMMIT depois de completar todo o seu trabalho, ou
pode dar um ABORT (ou ser abortada pelo SGBD) depois de executar algumas aes.
-Uma propriedade muito importante garantida pelo SGBD e que todas as transaes so
atmicas. O usurio pode pensar que uma transao ou executa todas as suas aes De
uma s vez s, ou no executa ao nenhuma.
*O SGBD faz um LOG de todas as aes, para poder desfazer (UNDO) as aes
das transaes abortadas.
-Isso garante que se cada transao preserva a consistncia do BD, ento todo
escalonamento serializvel tambm preserva a consistncia do BD.
Abortando uma transao
-Se uma transao T1 for abortada, todas as suas aes devero ser desfeitas. Alm
disso, se T2 tiver lido um objeto descrito por T1, ento T2 tambm precisar ser
abortada.
-A maioria dos sistemas evita esses abordos em cascata retendo os bloqueios de uma
transao at que a transao de COMMIT (usando o protocolo ZPL estrito).
*Se T1 escrever em um objeto, ento T2 s vai poder ser o valor escrito depois
que T1 der COMMIT.
-Para desfazer as aes de uma transao abortada, o SGBD mantm um LOG no qual
cada escrita registrada. Este mecanismo tambm usado para recuperao de
CRASHAS: quando sistema volta, so abortadas todas as transaes que estavam ativas
no momento da queda.
SYSTEM LOG
As seguintes aes so registradas no LOG:
*T1 escreve em um objeto: so registrados o valor antigo (imagem anterior) e o
valor novo ( ).
*O registro do LOG precisa ir para disco antes da modificao no objeto
(esta tcnica se chama WRITE-AHEAD-LOGGING ou WAL).
*T1 de um COMMIT ou um ABORT: um registo de LOG indicando esta ao.
Registros de LOG so encadeados atravs de um identificador de transao, de modo
que seja fcil desfazer uma transao especificada.
-O log mantido em disco(s) prprio(s). Para se ter armazenamento estvel (stable
storage) usa-se a tcnica de espelhamento de blocos (dois blocos fsicos para cada bloco
lgico).
-Todas as aes de LOG (e, de fato, todas as aes de controle de concorrncia, tais
como bloquear/desbloquear dados, lidar com deadlocks, etc.) so efetuadas
transparentemente pelo SGBD.
Algoritmo de recuperao de CRASHES
-Trs fases:
*Anlise: varre o LOG para frente (desde o ltimo checkpoint) para identificar todas as
escritas que pudesses estar pendentes e todas as transaes que estavam ativas quando o
sistema caiu.
*Redo: refaz todas as escritas que podem estar pendentes de modo a assegurar que todos
os WRITES registrados no LOG foram de fato efetivados em disco.
-Usa as imagens posteriores nos registros de LOG dessas escritas.
*Undo: varre o LOG para trs, desfazendo as escritas de todas as transaes que
estavam ativas quando o sistema caiu.
-Usa as imagens anteriores nos registros de LOG dessas escritas.