Banco de Dados

Aula 2 – Revisão
Modelo Relacional - Conceitos
Valor (dado): Um valor é um símbolo (termo ou
elemento simbólico) que é utilizado para
caracterizar (quantificar ou qualificar) uma
propriedade ou característica de uma entidade,
um objeto, um relacionamento ou uma ligação.
Relação (Tabela): elemento indicado por linhas e
colunas. Nomes únicos no BD.
Tupla: linha de uma tabela. Também denominada
de instância.
Atributo (Item de dado): itens que não podem ser
decompostos. São as colunas da tabela.
Domínio: valores que um campo pode assumir.
Projeto de Banco de Dados
Necessidade de Dados

Projeto MER
MER(Modelo
(Modelo
Conceitual Entidade-Relacionamento)
Entidade-Relacionamento)

Projeto
Lógico MR
MR(Modelo
(ModeloRelacional)
Relacional)

Projeto
Físico SQL
SQL

Projeto Terminado
 Modelo de Dados – Projeto Conceitual
 Não contém detalhes sobre a representação em
meio físico das informações;
 Registra que dados podem aparecer no banco
de dados, mas não registra como estes dados
estão armazenados a nível de SGBD;
 Independente de SGBD;
 Análogo a algoritmos;
 Representado pelo MER;
 Identificar todas as entidades e os relacionamentos
entre elas.
 É a chave para a compreensão do modelo conceitual
de dados;
 Modelo de Dados – Projeto Lógico
 Descreve como as informações estão
organizadas internamente, visão do usuário do
SGBD;
 Busca refinar o modelo Conceitual
(normalização);
 Leva em conta e implementa recursos como
adequação de padrão e nomenclatura;
 Dependente do tipo particular de SGBD que está
sendo usado;
 No PostgresSQL não existem procedures:
 Utiliza-se uma function que retorna um void;
CREATE OR REPLACE FUNCTION nome()
RETURN void
Oracle:
CREATE OR REPLACE PROCEDURE nome IS
 Modelo de Dados – Projeto Lógico
 Os três modelos lógicos mais conhecido são:
 Modelo de Rede: representado por um conjunto de
registros; sendo as relações através de ponteiros;
 Modelo Hierárquico: similar ao modelo de rede; a
diferença é gráfica, sendo os registros organizados
em árvores;
 Modelo Relacional: usa um conjunto de tabelas
para representar os dados, compostas por linhas e
colunas.
 Modelo Semi-Estruturado: permite a especificação
dos dados em que itens de dados individuais do
mesmo tipo possam ter diferentes tipos de
atributos;
 Ex: Banco de Dados XML;
Modelo de Dados – Projeto Lógico
 Modelo de Dados – Projeto Lógico
 Os três modelos lógicos mais conhecido são:
 Modelo de Rede: representado por um conjunto de
registros; sendo as relações através de ponteiros;
 Modelo Hierárquico: similar ao modelo de rede; a
diferença é gráfica, sendo os registros organizados
em árvores;
 Modelo Relacional: usa um conjunto de tabelas
para representar os dados, compostas por linhas e
colunas.
 Modelo Semi-Estruturado: permite a especificação
dos dados em que itens de dados individuais do
mesmo tipo possam ter diferentes tipos de
atributos;
 Ex: Banco de Dados XML;
 Modelo de Dados – Projeto Físico
 Descreve os dados no nível mais baixo
(interno);

 Trata dos aspectos de implementação do BD;

 Levar em conta as limitações impostas pelo

SGBD escolhido;

 Deve ser criado com base nos exemplos de

modelagem de dados produzidos modelo
lógico;

 É definido empregando-se a DDL (Linguagem

de Definição de Dados).
Modelo de Dados – Projeto Físico
 Dicionário de Dados:
 Junto com o MER, é necessário se manter
um documento com a explicação de
todos os objetos nele criados.
Modelo de Dados – Projeto Físico
 Também trata aspectos de implementação do
BD;
 Informações de Catalogo do SGBD (meta-dado);
 Contém descrição de como os dados estão
armazenados;
 Formato de armazenamento de cada tipo de
dados, restrições;
 Número de tuplas de uma relação;
 Tamanho em bytes de uma tupla da relação;
 Tamanho em bytes de um atributo da relação;
 Projeto Conceitual - MER

Entidades Fracas
Um conjunto de entidades pode não possuir
atributos suficientes para formar uma chave
primária; (são chamadas de entidades fracas)
Entidade Fraca: não possui chave primária
(subordinada);
Entidade Forte: Possui chave primária
(dominante);

Necessário compreender o conceito de

dependência de existência !!!
Projeto Conceitual - MER
Dependência de Existência:
Se a existência da entidade “A” depende da
existência da entidade “B”, então “A” é dito
dependente da existência de “B”.

Operacionalmente, se “B” for excluído, o

mesmo deve acontecer com “A”.

A entidade “B” é chamada de entidade

dominante e a entidade “A” é chamada de
entidade subordinada.
Projeto Conceitual - MER

Entidades Fracas:
Representação:
Projeto Conceitual - MER
 Projeto Conceitual - MER
Dependência de Existência Total_Pag

Empréstimo Pgt_Emp. Pagamento

Num_Empr. Total Num_Pag Data_Pag

 Se uma entidade empréstimo é excluída, então todas as entidades

pagamento a ela associada deverão ser excluídas também.
 Em contraste, uma entidade pagamento pode ser excluída do
banco de dados sem afetar em nada qualquer empréstimo.
 Projeto Conceitual - MER
Dependência de Existência Total_Pag

Empréstimo Pgt_Emp. Pagamento

Num_Empr. Total Num_Pag Data_Pag

Num_Pag é sequencial gerado para cada empréstimo

(discriminador);
Discriminador: conjunto de atributos que permite distinguir uma
entidade particular (instância) no conjunto de entidades;

Chave primária do conjunto entidade fraco, formada pela chave

primária do conjunto de entidades identificador mais o
discriminador do conjunto de entidades fraco;
{Num_Empr., Num_Pag}
Projeto Conceitual - MER
Dependência de Existência
Exemplo:

Valor

Conta Historic Transacao

o

Num_Conta. Saldo Num_Tran Data

Projeto Conceitual - MER
Cardinalidade/Classe 1:N

1 N
A Rel1 B
N

Rel2

N 1
C Rel3

N
Projeto Conceitual - MER

Auto-Relacionamentos
Relacionamento de uma ENTIDADE consigo
mesma.
Também chamados de Relacionamentos
RECURSIVOS.
Exemplo: Uma empresa tem a entidade FUNC
e deseja saber quais são os funcionários(as)
casados com outros funcionários(as).
 Projeto Conceitual - MER
Auto-Relacionamentos
Mike 1
Rieta
Func Casado com
Colleen
1
Sean

Jody
isto é equivalente a:
Walt
Andrew

Larry

Whitney 1 1
Func Casado com Func
Barb
Derivação MER para MR

cod nome Generalização

Cliente

Especialização

Física Jurídica

rg sexo CGC TipoOrg

Derivação MER para MR
Especialização Total - Para cada instância da entidade
genérica, existe sempre uma instância em uma das
entidades especializadas
codigo nome
Indica que todo cliente
deve ser pessoa física
Cliente ou jurídica

Física Jurídica

CPF RG CNPJ Razao Social

Derivação MER para MR
Especialização Total - São criadas relações
apenas para as especializações (entidades
filhas), usando como chave primária o
atributo identificador da entidade de nível
superior, além de seus demais atributos.
Derivação MER para MR
Especialização Parcial - Nem toda ocorrência da entidade
genérica possui correspondente em entidade
especializada
Tipo_funcionario

Indica que nem todo

Funcionário FUNCIONÁRIO é ENGENHEIRO
ou VENDEDOR ou SECRETÁRIA

Engenheiro Vendedor Secretária

 Derivação MER para MR
Especialização Parcial - Deve ser criada uma relação para cada
entidade, todas tendo como chave primária o atributo
identificador da entidade de nível superior.
Funcionário
Matr. Nome Funcao

4544 Juca Silva Eng

6856 Gustavo Borges Ven

1300 Telma Ribeiro Sec

5497 José Miguel Ven

2618 Maria do Bairro Ven

Engenheiro Vendedor Secretária
Mat Aj. Custo Espec. Mat Hr. Extra Comis. Pl. Carro Mat Ling. Curso
Estr.
5497 40 1500 ATI-1212
4544 120 Eletr 1300 Inglês Comp.
2618 20 100 AXO-5555

6856 34 800 AHA-1010

Implementando (ISA)
 Generalização & Especialização:
RG
Func E
nome
data admissão S
G
E P
N E
E ISA C
R I
A A
L L
I Motorista Secretária Engenheiro I
Z Z
A A

habilitação acidentes Idiomas CREA

Questões: 9 – 10 – 11 – 12 -
Normalização
Dependências Funcionais – Impacto na
Normalização de Dados
Exemplo:
Dada determinada cidade (não homônimas) podemos
determinar seu estado e consequentemente seu pais;
Representação:
Cidade Estado;
Estado País;

Estado é funcionalmente dependente de Cidade; ou

• Cidade determina Estado;
Pais é funcionalmente dependente de Estado; ou
• Estado determina País.
Dependências Funcionais – Impacto na
Normalização de Dados
A dependência funcional é caracterizada pela
existência de campos em uma determinada
relação cuja ocorrência de valores está
associada a valores que são preenchidos em
outros campos na mesma tabela.
Exemplo:
EMPREGADO possui dois atributos CPF e NOME.
NOME é funcionalmente dependente de CPF;
CPF NOME;
Ou seja, a partir do CPF pode-se encontrar o nome de
uma pessoa;
Dependência Funcional: Dependência
Parcial
Para efetuar a normalização de um modelo de
dados relacional, alguns tipos de dependências
funcionais são de extrema relevância:
Dependência Parcial: Ocorre quando a chave primária
é composta e existe campo (s) da relação que
depende(m) somente de parte desta chave primária
composta.
CPF_Empregad Cod_projeto Nome_Empregad Nome_Projeto Horas_Trabalhad
o o as

123456 11 Juca da Silva SoftHouse 40

654321 22 Hermano HardCore 20

Pereira
789687 33 Renata Stange LinuxWindow 40
s
Dependência Funcional: Dependência
Parcial
 Dependência Parcial:
CPF_Empregad Cod_projeto Nome_Empregad Nome_Projeto Horas_Trabalhad
o o as

123456 11 Juca da Silva SoftHouse 40

654321 22 Hermano HardCore 20

Pereira
789687 33 Renata Stange LinuxWindow 40
s

Nome_Projeto depende somente de Cod_Projeto;

Nome_Empregado depende somente de CPF_Empregado;
Horas_Trabalhadas é funcionalmente dependente da chave
primária completa (porque para determinar as horas
trabalhadas, precisamos saber o CPF do empregado e para
qual projeto ele está trabalhando através do código do
projeto).
Dependência Funcional: Dependência
Transitiva
Ocorre quando uma coluna depende não somente
da chave primária da relação, mas também de uma
segunda coluna ou conjunto de colunas da relação
que não fazem parte da chave.
Codigo_Pedido Data_Pedido Situacao_Pedi CPF_Cliente Nome_Cliente
do

1 18/03/2010 Pendente 123456 Juca da Silva

2 22/02/2010 Entregue 654211 Pedro Afonso

3 10/01/2010 Entregue 987654 Josefina

Carvalho

 Data_Pedido, Situação_Pedido e CPF_Cliente

dependem funcionalmente da chave primária;
 Nome_Cliente depende funcionalmente do CPF_Cliente
(não é chave) e indiretamente do Cod_Pedido.
Dependência Funcional: Dependência
Multivalorada
Ocorre quando o valor de um atributo determina um
conjunto de valores de um outro atributo;
Exemplo:
Se considerarmos: CPF → Dependente teremos um
problema para expressar a realidade, porque através de
um CPF poderia ocorrer de mais de um dependente ser
determinado e não apenas um; Isso caracteriza uma
dependência multivalorada;
Representação:
CPF → → Dependente (CPF multidetermina Depend.)
CPF Dependente
Joao da Silva
111.111.111-23
Maria da Silva
Pedro da Silva
Anomalias de Atualização
A mistura de atributos de várias entidades
pode gerar problemas conhecidos como
anomalias de atualização ocasionando
problemas como:
Grupos repetitivos de dados;
Dependências parciais de chave;
Redundâncias desnecessárias de dados;
Perdas acidentais de informações;
Dificuldade de representação de fatos da
realidade (modelos);
Dependências transitivas entre atributos.
Anomalias de Atualização

Podem ser divididas em três grupos:

Anomalias de Inserção: Causam a repetição
desnecessária de dados (redundância);
Anomalias de Alteração: Levam as
inconsistências e aumentam o esforço para
atualização dos dados;»
Anomalias de Exclusão: Causam a perda de
informações associadas a um dado registro.
 Exemplo 1: Anomalias de Atualização
Nome_Cl Cod_CD Dt_Compra Nome_CD Cantor Preco
i.

Antonio 22 27/08/2012 The Very Best of Fleetwood Mac 25,00

Marcos 10 13/03/2012 Money for Nothing Dire Straits 24,50

Rebeca 45 04/05/2012 Greatest Hits Bruce Springsteen 20,00

Relação Vendas

 O Cliente Tarcizio deseja comprar 5 Cds do Dire Straits iguais:

 Só pderia comprar em 5 dias diferentes e se o fisesse:
 Anomalia de Inserção: Redundância em quase todas as colunas
(5 linhas praticamente iguais – mudando só o campo
Dt_Compra - na tabela), afinal, é o mesmo CD e o mesmo
cliente;
 Anomalia de Alteração: se houvesse um aumento de preço do
CD, a atualização do preço deveria ser feita em todas as linhas
referentes àquele CD na tabela.
 Exemplo 1: Anomalias de Atualização
Nome_Cl Cod_CD Dt_Compra Nome_CD Cantor Preco
i.

Antonio 22 27/08/2012 The Very Best of Fleetwood Mac 25,00

Marcos 10 13/03/2012 Money for Nothing Dire Straits 24,50

Rebeca 45 04/05/2012 Greatest Hits Bruce 20,00

Springsteen
Relação Vendas

 Anomalia de Exclusão: A tabela só guarda

registro dos CDs que foram comprados. Dessa
forma, se só ocorreu uma única venda de um
CD e ela fosse apagada, não haveria na loja
mais nenhuma informação sobre aquele CD.
 Exemplo 2: Anomalias de Atualização
CPF Nome_Emp. Endereco_Emp. Cod_Depto Nome_Dpto

1234567 Sanda R. Das 12 Financeiro

Samambaias

7654321 Júlio R. Dos Macacos 55 Compras

6450981 Bento Av. XyZ 43 Suporte

Relação Vendas

 Anomalia de Inserção:
 Para se inserir dados de Empregados, deve-se inserir dados de
departamento também (ou colocar null);
 É dificil inserir um novo departamento que ainda não tem empregados;
 Porém CPF faz parte de chave primária da relação;
 Anomalia de Alteração:
 se o nome do depto 43 passar a ser “Administração”, todas as tuplas
possuem empregados nesse depto devem ser alteradas ou ficarão
inconsistentes;
 Exemplo 2: Anomalias de Atualização
CPF Nome_Em Endereco_Emp. Cod_Depto Nome_Dpto
p.

1234567 Sanda R. Das Samambaias 12 Financeiro

7654321 Júlio R. Dos Macacos 55 Compras

6450981 Bento Av. XyZ 43 Suporte

Relação Vendas
 Anomalia de Exclusão:
 Se for removida uma tupla da relação
Empregado e esta fora última ocorrência de um
departamento em particular, a informação
correspondente ao departamento seria perdida.
Normalização
É um processo de converter uma relação que
apresenta certos problemas em duas ou mais
relações que não os possuem;
Tem por principal objetivo evitar anomalias de
atualização no banco de dados;
Visa uma maneira “ótima” de relacionar dados em um
BD.
Foi proposto por Codd, onde se submete um esquema
de uma relação a uma série de testes para certificar-
se de que ele satisfaça certa forma normal (FN):
Caso a relação não atenda ao critério de um FN sua
estrutura é redesenhada;
Normalização - Objetivos
Analisar tabelas e organizá-las de forma que a sua
estrutura seja simples;
Evitar a perda e a repetição da informação;
Conseguir uma forma de representação adequada
para o que se deseja armazenar;
Garantir a integridade dos dados, evitando que
informações sem sentido sejam inseridas no banco de
dados;
Organizar e dividir as tabelas da forma mais eficiente
possível, diminuindo a redundância e permitindo a
evolução do banco de dados com o mínimo de efeito
colateral.
 Normalização – Ponto de Equilíbrio
A normalização possui uma sequência
hierárquica. Essa sequência diz respeito ao grau
de refinamento do Banco de Dados.

Menos R
Relações E
Mais F
Redundância I
Maioria dos N
casos para na A
3ª FN M
E
Mais Relações N
Menos T
Redundância O
 Uma relação se encontra na Primeira Forma Normal
(1FN) se todos os domínios de atributos possuem
apenas valores atômicos (indivisíveis), e que o valor
de cada atributo na tupla seja um valor simples;
A 1FN não permite relações que apresentem
atributos compostos e nem a presença de atributos
multivalorados;

CPF Nome Grau_Lente CPF Nome Curso

57453525 Leonardo Borges Programador,

57453525 Guilherme da 0.25 , 0.50 Arquiteto
Silva
98987879 Pedro de Lima Analista,
98987879 Jonas de 1.25 , 0.5 Programador,
Carvalho Operador.

Relação Paciente – Fora da 1FN Relação Empregado – Fora da 1FN

Atributo Composto Atributo Multivalorado
Atributos Compostos: Cada um dos atributos compostos
devem ser "divididos" em seus atributos componentes; Ex:
CPF Nome Grau_Lente_Esq Grau_Lente_Dir

57453525 Guilherme da Silva 0.25 0.50

98987879 Jonas de Carvalho 1.25 0.5

 Atributos Multivalorados: Quando a quantidade de

valores a serem preenchidos no atributo multivalorado
for pequena e conhecida a priori, substitui-se o atributo
multivalorado por um conjunto de atributos de mesmo
domínio, cada um monovalorado representando uma
ocorrência do valor.
CPF Nome Curso_1 Curso_2 Curso_3

57453525 Leonardo Borges Programador Arquiteto Null

98987879 Pedro de Lima Analista Programador Operador

Atributos Multivalorados: A opção anterior não é muito
utilizada uma vez que pode gerar muitos valores
"nulls" e desperdiçar espaço de armazenamento;
Quando a quantidade de valores for muito variável,
desconhecida ou grande, retira-se da relação o atributo
multivalorado, e cria-se uma nova relação que tem o
mesmo conjunto de atributos chave, mais o atributo
multivalorado também como chave;
CPF Curso
CPF Nome 57453525 Programador
57453525 Leonardo 57453525 Arquiteto
Borges
98987879 Analista
98987879 Pedro de Lima
98987879 Programador

98987879 Operador
 Uma relação está na segunda forma normal
quando duas condições são satisfeitas:
A relação está na primeira forma normal;
Todos os atributos que não fazem parte da chave-
primária dependem funcionalmente de toda a chave
primária, ou seja, nenhum dos atributos da relação
possui dependência parcial.
• Todo atributo A da relação R não é parcialmente
dependente da chave-primária de R.
CPF_Empregado Cod_projeto Nome_Empregado Nome_Projeto Horas_Trabalhada
s

123456 11 Juca da Silva SoftHouse 40

654321 22 Hermano HardCore 20

Pereira
789687 33 Renata Stange LinuxWindo 40
ws
1) Para cada atributo que não faça parte da chave primária
da relação, analisar se existe dependência parcial da chave
primária.
2) Para cada grupo de atributos que tenham a mesma
dependência parcial da chave primária, devem-se criar novas
relações que terão como chave primária a chave parcial que
estava na relação original e todo o grupo de atributos que
depende da mesma chave parcial;
3) Excluir da relação original o grupo de atributos para o qual
foi criada uma nova relação;
4) Repetir esses procedimentos para cada grupo de atributos
que tenha dependência parcial da chave primária da relação
original, até que todas as relações somente contenham
atributos que dependam de toda a chave primária
 CPF_Empregad Cod_projeto Nome_Empregad Nome_Projeto Horas_Trabalhad
o o as

123456 11 Juca da Silva SoftHouse 40

654321 22 Hermano HardCore 20
Pereira
789687 33 Renata Stange LinuxWindow 40
s
Relação Alocação
CPF_Empre Nome_Empregado CPF_Empregad Cod_proje Horas_Trabalhad
gado o to as

123456 Juca da Silva 123456 11 40

654321 22 20
654321 Hermano Pereira
789687 33 40
789687 Renata Stange Relação Alocação
Cod_Projeto Projeto
Relação Empregado
11 SoftHouse
22 HardCore
Relação Projeto
33 LinuxWindows
 Relações que não estão na 2FN podem apresentar
problemas de inconsistência devido à duplicidade dos
dados e sua perda em operações de
remoção/alteração.
Cod_Turma Sigla_Disciplina Num_SalaAula Num_Horas
11 LP 515 6
22 LP 516 6
11 BD 502 4
22 SO 510 4
22 SO 512 4

 Se a disciplina BD não for oferecida para nenhuma turma, leva

à remoção da terceira tupla da relação Turma, ocasionando a
perda do número de horas da disciplina BD, pois esta
informação não se encontra em outra relação ou tupla;
 Cod_Turma Sigla_Disciplina Num_SalaAula Num_Horas
11 LP 515 6
22 LP 516 6
11 BD 502 4
22 SO 510 4
22 SO 512 4

Relação Turma – Fora da 2FN

Outra anomalia seria a duplicidade do número de

horas da disciplina o que pode gerar inconsistências;
Atualizar Num_Horas da primeira tupla de LP;
Fato ocorre devido ao atributo Num_Horas depender somente
de uma parte da chave primária (Sigla_Disciplina);
 Cod_Turma Sigla_Disciplina Num_SalaAula Num_Horas
11 LP 515 6
22 LP 516 6
11 BD 502 4
22 SO 510 4
22 SO 512 4
Relação Turma – Fora da 2FN
Cod_Turma Sigla_Discipli Num_SalaAu
Sigla_Discipli Num_Hora na la
na s
11 LP 515
LP 6 22 LP 516
BD 4 11 BD 502
SO 4 22 SO 510
Relação Disciplina 22 SO 512
Relação Turma – na 2FN
Para que uma relação esteja na 3FN é
preciso que ela atenda a 2 pré-
requisitos:
A relação deve estar na 2FN;
Não deve existir dependência transitiva na
relação;
• Nenhum dos atributos não chave pode
depender de outro atributo não chave;
• Todos atributos devem depender completa e
exclusivamente da chave-primária;
Cod_Empregado Nome_Empregado Cargo Salario

100 Geraldo Pereira Programador 2000

101 Eduardo Almeida Analista 4000

102 Gerson Gabriel Programador 2000

Relação Funcionário – Fora da 3FN

Existe uma dependência transitiva nesta

relação:
Atributo Salario depende do Cargo;
Atributo Cargo depende do Cod_Empregado;
Representação:
• Cod_Empregado → Cargo → Salario;
1) Para cada atributo que não participe da
chave primária da relação, analisar se existe
dependência transitiva da chave primária.
2) Para cada grupo de atributos não-chaves
dependentes funcionalmente de outros
atributos não-chaves, cria-se uma nova relação;
Nova relação vai ter os atributos dependentes
como não-chaves e os atributos que causam a
dependência (determinantes) como chave
primária;
3) Repetir os passos anteriores até que todos os
atributos restantes na relação original dependam
diretamente de toda a chave primária;
4) Excluir da tabela original todos os atributos com
dependência transitiva, mantendo o atributo
determinante da transitividade;
Excluir atributos derivados de outros (calculados);
Atributo data de nascimento e idade (pode ser calculado
a qualquer momento);
 Cod_Empregado Nome_Empregado Cargo Salario

100 Geraldo Pereira Programador 2000

101 Eduardo Almeida Analista 4000

102 Gerson Gabriel Programador 2000
Relação Funcionário – Fora da 3FN

Cod_Empregad Nome_Empregad Cargo

Cargo Salár o o
io
100 Geraldo Pereira Programad
Programador 2000 or
101 Eduardo Almeida Analista
Analista 4000
102 Gerson Gabriel Programad
Relação Salario_Cargo or

Relação Funcionário na 3FN

 Relações que não estão na 3FN podem apresentar
problemas de inconsistência devido à duplicidade dos
dados e sua perda em operações de remoção/alteração.

Cod_Turma Professor Sala Capacidade

Si31 Tarcizio 509 40
Si32 Eleandro 523 50
Si33 Diego 523 50

Relação Turma – Fora da 3FN

 Se a sala 523 tiver sua capacidade atualizada de
50 para 60 (segunda tupla) teríamos um caso de
inconsistência em relação a terceira tupla;
 Cod_Turma Professor Sala Capacidade
Si31 Tarcizio 509 40
Si32 Eleandro 523 50
Si33 Diego 523 50
Relação Turma – Fora da 3FN

Sala Capacidad Cod_Turma Professor Sala

e
Si31 Tarcizio 509
509 40 Si32 Eleandro 523
523 50 Si33 Diego 523
Relação Sala Relação Turma – na 3FN
Normalização – Vantagens/Desvantagens

Vantagens:
- Redução do espaço físico;
- Manutenção dos dados e das configurações são
mais simples;
- Menos custos;

Desvantagens:
- Criação de inúmeras tabelas deixando as
informações pulverizadas;
- O tempo de processo é mais longo ao se fazer
uma consultas (join);
SQL – Restrições de Integridade

As restrições de integridade servem para

garantir as regras inerentes ao sistema que
está sendo implementado, prevenindo a
entrada de informações inválidas pelos
usuários desse sistema.

Para isso, o SGBD deve prover ferramentas

para a definição de regras de integridade, a
fim de evitar a inconsistência dos dados que
nele serão armazenados.
SQL - Integridade Referencial

Uma cláusula FOREIGN KEY inclui regras de

remoção / atualização:
FOREIGN KEY (coluna) REFERENCES tabela
[ON DELETE {RESTRICT|CASCADE|SET NULL|
SET DEFAULT}]
[ON UPDATE {RESTRICT|CASCADE|SET NULL|
SET DEFAULT}]
Supondo que T2 tem uma chave estrangeira
para T1, vejamos as cláusulas ON DELETE e ON
UPDATE;
SQL - Integridade Referencial
ON DELETE:
RESTRICT: (default) significa que uma tentativa de se
remover uma linha de T1 falhará se alguma linha em
T2 combina com a chave;
CASCADE: remoção de uma linha de T1 implica em
remoção de todas as linhas de T2 que combina com
a chave de T1;
SET NULL: remoção de T1 implica em colocar NULL
em todos os atributos da chave estrangeira de cada
linha de T2 que combina;
SET DEFAULT: remoção de linha em T1 implica em
colocar valores DEFAULT nos atributos da chave
estrangeira de cada linha de T2 que combina;
SQL - Integridade Referencial
ON UPDATE:
RESTRICT: (default) update de um atributo de T1
falha se existem linhas em T2 combinando;
CASCADE: update de atributo em T1 implica que
linhas que combinam em T2 também serão
atualizadas;
SET NULL: update de T1 implica que valores da
chave estrangeira em T2 nas linhas que combinam
são postos para NULL;
SET DEFAULT: update de T1 implica que valores da
chave estrangeira de T2 nas linhas que combinam
terão valores default aplicados;
SQL – Restrições de Integridade

As restrições de integridade podem ter um nome e

serem especificadas com a cláusula CONSTRAINT;
Isto permite que possamos no futuro eliminar
(DROP) ou alterar (ALTER) o constraint;
O exemplo a seguir mostra o uso de CONSTRAINT,
DEFAULT, ON DELETE e ON UPDATE;
SQL – Restrições de Integridade
CREATE TABLE empregado (
…
depto INT NOT NULL DEFAULT 1,
CONSTRAINT empPK
PRIMARY KEY(matricula),
ALTER TABLE
CONSTRAINT empSuperFK empregado
FOREIGN KEY(supervisor) REFERENCES DROP CONSTRAINT
empregado(matricula) empSuperFK;
ON DELETE SET NULL ON UPDATE
CASCADE,
CONSTRAINT deptoFK
FOREIGN KEY (depto) REFERENCES
departamento(codigo)
ON DELETE SET DEFAULT ON
UPDATE CASCADE
Operações com String
 Uma string é definida por caracteres entre
apóstrofo;
 Um apóstrofo pode ser inserido em uma string
usando dois apóstrofos;
 Exemplo:
 Caixa d’agua
 Pode ser escrita como: ‘Caixa d’’agua’
 A operação mais utilizada em strings é a
correspondência, usando o operador LIKE:
SELECT nome, endereco Há diferença de
FROM clientes caracteres
maiúsculos e
WHERE endereco LIKE ‘lula gomes’; minúsculos!!!
Operações com String
 Podemos especificar padrões de string através
dos caracteres (também chamados coringas):
 %: corresponde a qualquer substring;
 _: corresponde a qualquer caracter;
 Exemplos:
 ‘Maria%’: localiza qualquer string começando Maria;
 ‘%aria%’: localiza qualquer string contendo “aria”,
como Maria, maquinaria, ariane;
 ‘_ _ _’: localiza qualquer string com exatamente três
caracteres;
 ‘_ _ _%’: localiza qualquer string com pelo menos
três caracteres;
Operações com String

 Exemplo de utilização do operador LIKE

com coringa %;
SELECT nome, contato, telefone
FROM vendedor
WHERE contato LIKE ‘Bin%’;

 Pode trazer registros com contato sendo

‘Bini’, ‘Binde’ entre outros;
 Tabelas de Exemplo
Locações

Reparos

Note-se que Reparos não possui tupla para o chassi

CD260 e Locações não possui para RT155.
 Operadores do Conjunto Relacional
 INTERSECT: combina as tuplas de duas
consultas, retornando apenas as que aparecem
em ambos os resultados
 Sintaxe:
SELECT *
FROM reparos
WHERE cod_reparo=3
INTERSECT
SELECT *
FROM reparos;