Banco de Dados I – Aula 07/10

Formas Normais

Normalização é um processo a partir do qual se aplicam regras a todas as tabelas do BD

com o objetivo de evitar falhas no projeto, como redundância 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 transformação corretamente, o
modelo relacional resultante estará, provavelmente, normalizado. Mas nem sempre os
modelos que nos deparamos são implementados dessa forma e, quando isso acontece, o
suporte ao BD é dificultado em ambos os casos, é necessário aplicar as técnicas de
normalização, ou para normalizar (se caso citado), ou apenas validar o esquema criado
(primeiro caso citado). Aplicando as regras descritas a seguir, é possível garantir um BD
mais íntegro, sem redundâncias e inconsistências.

Primeira Forma Normal – 1FN

Dizemos que uma entidade está na 1FN quando não há itens repetidos (itens
multivalorados) dentro dela, ou seja, somente devem existir valores atômicos
(indivisíveis) nos atributos das tuplas assim, para converter uma entidade não
normalizada na 1FN, precisamos decompô-la em tantas entidades quantas forem
necessárias para não ter itens repetidos.

Em outras palavras podemos definir que a 1FN não admite repetições ou campos que
tenham mais de um valor.

Procedimentos:

 Identificar a chave primária da entidade;

 Identificar o grupo repetitivo e remove-lo da entidade;
 Criar uma nova entidade com a chave primária da entidade anterior e o grupo
repetitivo.

Exemplo de 1FN

Considere a tabela cliente: cod_cliente, nome, telefone e endereço.

Cod_cliente Nome Telefone Endereço

C001 José 9563-6312 Rua Seis, 85 – Morumbi – 12536-965
9847-2501
C002 Maria 3265-8596 Rua Onze, 64 – Moema – 65985-963
C003 Jonas 8545-8956 Praça Ramos – Liberdade – 68858-633
9598-6301
 Separando os itens multivalorados:

Cod_cliente Nome Telefone Rua Bairro CEP

C001 José 9563-6312 Rua Seis, 85 Morumbi 12536-965
9847-2501
C002 Maria 3265-8596 Rua Onze, 64 Moema 65985-963
C003 Jonas 8545-8956 Praça Ramos Liberdade 68858-633
9598-6301

Cod_cliente Nome Rua Bairro CEP Cod_cliente Telefone

C001 José Rua Seis, 85 Morumbi 12536-965 C001 9563-6312
C002 Maria Praça Onze, 64 Moema 65985-963 C001 9847-8596
C003 Jonas Praça Ramos Liberdade 68858-633 C002 3265-8596
C003 8545-8956
C003 95986301

Exercício

Montar na 1FN

Matrícula Nome Turma Telefone Unidade

C001 Maria da Silva Biologia – ECO1 9999-8888 Principal – Realengo
8888-9999
C002 Paula de Souza Biologia – ECO2 2222-3333 Campus 2 – Realengo
8888-4444
C003 Claudia Fonseca Psicologia – MEME1 3333-4444 Praia – Barra
C004 Wiza Arruda Psicologia – FREUD 3333-2222 Praia – Barra
4444-5555

Separando os itens multivalorados:

Matrícula 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

Matrícula 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 difícil, pois envolve o
conhecimento das dependências funcionais. A entidade se encontra na 2FN se, além de
estar na 1FN, todos os seus atributos são totalmente dependentes da chave primária, isso
significa que atributos que são parcialmente dependentes devem ser removidos.
Se o nome do produto já existe na tabela produtos, então não é necessário que
ele exista na tabela vendas. A 2FN trata destas anomalias e evita que valores fiquem em
redundância no B.D.
Procedimentos
- Identificar os atributos que não são funcionalmente de toda a chave primária.
- Remover da entidade todos esses atributos identificados e criar uma nova
entidade com eles.
A chave primária da nova entidade será o atributo do qual os atributos
removidos são 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 são 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 situações que não eram inicialmente cobertas pelas três formas normais, em
especial quando haviam várias 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 primárias.
Assim, para estar na FNBC, uma entidade precisa possuir somente atributos que
são 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 são 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
contém os atributos que descrevem o AWNO em si, e outra WJ01 atributos designam o
professor.
Cod_Aluno Cod_Turma Cod_Curso
Cod_Turma Cod_Curso Cod_Professor
A001 1P SI01
1P SI01 345
A002 2P DR01
2P DR01 432
A003 3P AD01
3P AD01 432

Gerência de Transações
Transações
- Conceito básico para controle de concorrência e recuperação: A transação.
* Leituras (READS) e escritas (WRITES)
*Ações Especiais: Commit (Compromissamento ou efetivação de transação),
Abort ( Aborto de transação)
- O SGBD „vê‟ cada transação como uma sequência de leituras e escritas delimitada por
comandos BEGIN e Commit (ou ABort).
Concorrencia em um SGBD
- A execução concorrente de programas dos usuários é essencial para o bom
desempenho do SGBD.
*Como acessos a disco são frequentes e relativamente lentos, é muito importante
manter a CPU ocupada executando vários programas concorrentemente.
- Uma aplicação pode efetivar muitas operações sobre os dados lidos de um BD, mas
para o SGBD só importam as leituras e as escritas realizadas.
- Usuários submetem transações e podem pensar que cada transação roda sozinha, como
„dona‟ da máquina.
*A concorrência é implementada pelo SGBD, que entrelaça ações (READS /
WRITES de objetos no BD.) das várias transações.
*Cada transação deve deixar o BD em um estado consistente.
- O SGBD impões restrições de integridade especificadas nos comandos CREATE
TABLE, mas não entende realmente a semântica dos dados (por exemplo: ele não sabe
computar os juros em uma conta de poupança)
-Questões: Efeitos de entrelaçamento de transações e de quedas do sistema.

Banco de Dados I – Aula 04/11

As propriedades ACID

Atomicidade – ou todas as ações da transação acontecem, ou nenhuma delas acontece.

Consistência – se a transação é consistente e o BD começa consistente, ele termina

consistente.

Isolamento – a execução de uma transação é isolada da execução de outras transações.

Durabilidade – se uma transação é concluída com sucesso (através de uma operação

COMMIT bem sucedida), então seus efeitos são persistentes (duráveis).

Satisfazendo as propriedades ACID

- Controle de concorrência

*Garante a consistência e o isolamento, dada a atomicidade das transações.

° Em um SGBD são tarefas do módulo gerente de LOG.

- VOGGING e recuperação

*Garantem a atomicidade e a durabilidade.

 °Em um SGBD são tarefas do módulo gerente de LOG.

Exemplo:

-Considere duas transações:

T1: BEGIN | A= A+100 , B= B-100 | END

T2: BEGIN | A= 1.06*A , B = 1.06*B | END

-Intuitivamente, a primeira transação está transferindo R$ 100 da conta B para a conta

A. A segunda está creditando% de juros em ambas as contas.

-Não há garantia que T1 vai executar antes de T2 ou vice-versa, se ambas forem

submetidas praticamente juntas. Contudo, o efeito invisível tem de ser equivalente ao
dessas duas transações rodando serialmente (uma depois da outra), em uma ordem
qualquer.

-Considere o seguinte entrelaçamento (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 não 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 dependências -------------

T1 T2
-------------

- Grafo de dependências: Um nó por transação, 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 é idêntico ao efeito de
executar o outro ESCALONAMENTO.

-Escalonamento Serializável: Um escalonamento que é equivalente a uma execução

serial das transações.

-Se o grafo de dependências de um escalonamento for acíclico (não tiver ciclos),

dizemos que o ESCALONAMENTO é serializável quanto ao conflito (CONFLICT –
SERIALIZABLE) tal ESCALONAMENTO é equivalente a um escalonamento serial.

-Essa é a condição que é tipicamente assegurada pelos SGBDs. Ela é suficiente

(mas não necessária) para que o ESCALONAMENTO seja serializável.

Assegurando a Seriabilidade
Protocolo de travamento bifásico (TOW-PHASE LOCKING OU ZPL)

-Baseado em bloqueios ou travas (locks).

-Cada transação, antes de ler um objeto, precisa obter um bloqueio S (Shared ou

Compartilhado) sobre o objeto. Antes de escrever em um objeto, a transação precisa
obter um bloqueio X (exclusivo) sobre o objeto.

-Depois que uma transação retirar algum bloqueio ela não poderá requisitar novos
bloqueios.

*Variação: O protocolo ZPL ESTRITO, no qual cada transação retém seus

bloqueios até ser efetivada (COMMIT) ou abortada.

Enquanto uma transação detiver algum bloqueio X sobre um objeto, nenhuma outra
transação conseguirá um bloqueio (S ou X) sobre o objeto.

Banco de Dados I – AULA 11/11

Atomicidade das transações

-Uma transação 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 ações.

-Uma propriedade muito importante garantida pelo SGBD e que todas as transações são
atômicas. O usuário pode pensar que uma transação ou executa todas as suas ações “De
uma só vez só”, ou não executa ação nenhuma.
 *O SGBD faz um LOG de todas as ações, para poder desfazer (UNDO) as ações
das transações abortadas.

-Isso garante que se cada transação preserva a consistência do BD, então todo
escalonamento serializável também preserva a consistência do BD.

Abortando uma transação

-Se uma transação T1 for abortada, todas as suas ações deverão ser desfeitas. Além
disso, se T2 tiver lido um objeto descrito por T1, então T2 também precisará ser
abortada.

-A maioria dos sistemas evita esses “abordos em cascata” retendo os bloqueios de uma
transação até que a transação de COMMIT (usando o protocolo ZPL estrito).

*Se T1 escrever em um objeto, então T2 só vai poder ser o valor escrito depois
que T1 der COMMIT.

-Para desfazer as ações de uma transação abortada, o SGBD mantém um LOG no qual
cada escrita é registrada. Este mecanismo é também usado para recuperação de
CRASHAS: quando sistema volta, são abortadas todas as transações que estavam ativas
no momento da queda.

“SYSTEM LOG”
As seguintes ações são registradas no LOG:

*T1 escreve em um objeto: são registrados o valor antigo (imagem anterior) e o

valor novo ( ).

*O registro do LOG precisa ir para disco antes da modificação no objeto

(esta técnica se chama WRITE-AHEAD-LOGGING ou WAL).

*T1 de um COMMIT ou um ABORT: um registo de LOG indicando esta ação.

Registros de LOG são encadeados através de um identificador de transação, de modo

que seja fácil desfazer uma transação especificada.

-O log é mantido em disco(s) próprio(s). Para se ter armazenamento estável (stable

storage) usa-se a técnica de espelhamento de blocos (dois blocos físicos para cada bloco
lógico).

-Todas as ações de LOG (e, de fato, todas as ações de controle de concorrência, tais
como bloquear/desbloquear dados, lidar com deadlocks, etc.) são efetuadas
transparentemente pelo SGBD.

Algoritmo de recuperação de CRASHES

-Três fases:
*Análise: varre o LOG para frente (desde o último checkpoint) para identificar todas as
escritas que pudesses estar pendentes e todas as transações 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 trás, desfazendo as escritas de todas as transações que
estavam ativas quando o sistema caiu.

-Usa as imagens anteriores nos registros de LOG dessas escritas.