B ase de

Dados em Modelo Relacional

UNIVERSIDADE TECNICA DE ANGOLA

CURSO DE ENGENHARIA INFORMATICA

MODELO RELACIONAL
DEPENDÊNCIAS FUNCIONAIS
NORMALIZAÇÃO

Estudante: Antonio Dieyi Kalu

Prof.: Doria Hebo

Luanda

Junho de 09
Elaborado por Antonio Kalu, estudante de Informatica
1
 B ase de
Dados em Modelo Relacional

UNIVERSIDADE TECNICA DE ANGOLA

CURSO DE ENGENHARIA INFORMATICA

TRABALHO DE BASE DE DADOS I

TEMA:

• Modelo Relacional;
• Dependências Funcionail;

• Normalização (0FN, 1FN, 2FN, 3FN).

Prof.: Doria Hebo

Estudante: Antonio Kalu

Nº 2916

Turma: EIN 2.2

Luanda

Elaborado por Antonio Kalu, estudante de Informatica

2
 B ase de
Dados em Modelo Relacional

Junho de 2009

Indice
1. Introduão.........................................................................................................................03

2. Modelo Relacional..........................................................................................................03

3. Dependências Funcionais..........................................................................05

4. Normalização..............................................................................................06

4.1 Forma não Normalizada..........................................................................06

4.2 Primeira Forma Normalizada.................................................................07

4.3 Segunda Forma Normalizada..................................................................08

4.4 Terceira Forma Normalizada...................................................................09

5. Conclusão.....................................................................................................10

6. Referências bibliograficas..........................................................................10

Elaborado por Antonio Kalu, estudante de Informatica

3
 B ase de
Dados em Modelo Relacional

1. Introdução
Desde o surgimento da tecnologia de informação, começou-se a armazenar informações em
computadores; informações estas que as vezes servia para utilização publica dentro de uma
organização ou qualquer fim. Estes dados eram armazenados sem serem arquitectados o que
provocava dificuldades em procurar o desejado. Surgiu então a necessidade de criar algo que
organizasse e gerenciasse dados, foram criados por varios engenheiros sistemas de
gerenciamento de bases de dados em varios Modelos (madelo Hierarquico, modelo em Rede,
modelo Recional,...). Neste artigo vou falar do Modelo Relacional

2. Modelo Relacional
O modelo relacional é um modelo de dados, adequado a ser o modelo subjacente de um
Sistema Gerenciador de Banco de Dados (SGBD), que se baseia no princípio em que todos os
dados estão guardados em tabelas (ou, matematicamente falando, relações). Toda sua
definição é teórica e baseada na lógica de predicados e na teoria dos conjuntos.

O conceito foi criado por Edgar Frank Codd em 1970, sendo descrito no artigo "Relational
Model of Data for Large Shared Data Banks". Na verdade o modelo relacional foi o primeiro
modelo de dados descrito teoricamente, os bancos de dados já existentes passaram então a ser
conhecidos como (modelo hierárquico, modelo em rede ou Codasyl e modelo de listas
invertidas).

O modelo relacional para gerência de bancos de dados (SGBD) é um modelo de dados

baseado em lógica e na teoria de conjuntos.

Historicamente ele é o sucessor do modelo hierárquico e do modelo em rede. Estas

arquiteturas antigas são até hoje utilizadas em alguns data centers com alto volume de dados,
onde a migração é inviabilizada pelo custo que ela demandaria; existem ainda os novos
modelos baseados em orientação ao objeto, que na maior parte das vezes são encontrados
como kits de construção de SGBD, ao invés de um SGBD propriamente dito.

O modelo relacional foi o primeiro modelo de banco de dados formal. Somente depois seus
antecessores, os bancos de dados hierárquicos e em rede, passaram a ser também descritos em
linguagem formal.

A linguagem padrão para os bancos de dados relacionais, SQL, é apenas vagamente

remanescente do modelo matemático. Atualmente ela é adotada, apesar de suas restrições,
porque ela é antiga e muito mais popular que qualquer outra linguagem de banco de dados.

A principal proposição do modelo relacional é que todos os dados são representados como
relações matemáticas, isto é, um subconjunto do produto Cartesiano de n conjuntos. No
modelo matemático (diferentemente do SQL), a análise dos dados é feita em uma lógica de
predicados de dois valores (ou seja, sem o valor nulo); isto significa que existem dois

Elaborado por Antonio Kalu, estudante de Informatica

4
 B ase de
Dados em Modelo Relacional

possíveis valores para uma proposição: verdadeira ou falsa. Os dados são tratados pelo
cálculo relacional ou álgebra relacional.

O modelo relacional permite ao projetista criar um modelo lógico consistente da informação

a ser armazenada. Este modelo lógico pode ser refinado através de um processo de
normalização. Um banco de dados construído puramente baseado no modelo relacional estará
inteiramente normalizado. O plano de acesso, outras implementações e detalhes de operação
são tratados pelo sistema DBMS, e não devem ser refletidos no modelo lógico. Isto se
contrapõe à prática comum para DBMSs SQL nos quais o ajuste de desempenho
frequentemente requer mudanças no modelo lógico.

O princípio básico do modelo relacional é o princípio da informação: toda informação é

representada por valores em relações (relvars). Assim, as relvars não são relacionadas umas
às outras no momento do projeto. Entretanto, os projetistas utilizam o mesmo domínio em
vários relvars, e se um atributo é dependente de outro, esta dependência é garantida através
da integridade referencial.

Exemplo de uma base de dados

Um exemplo, bem simples da descrição de algumas tabelas e seus atributos:

Cliente(ID Cliente, ID Taxa, Nome, Endereço, Cidade, Estado, CEP, Telefone)

Pedido de compra(Número do pedido, ID Cliente, Factura, Data do pedido, Data prometida,

Status)

Item do pedido(Número do pedido, Número do item, Código do produto, Quantidade)

Nota fiscal(Número da nota, ID Cliente, Número do pedido, Data, Status)

Item da nota fiscal(Número da nota,Número do item,Código do produto, Quantidade

vendida)

Exemplo: cliente

ID Cliente ID Taxa Nome Endereço

=================================================================
1234567890 555-5512222 João Carlos Rua bigodone, 120 ...
2223344556 555-5523232 Dorotéia Santos Avenida barbeiro,12 ...
3334445563 555-5533322 Lisbela da Cruz Rua dos bigodes,123 ...
4232342432 555-5325523 E. F. Codd Rua do gilete,51 ...

A normalização de banco de dados é normalmente realizada quando projeta-se um banco de

dados relacional, para melhorar a consistência lógica do projeto do banco de dados e o
desempenho transacional.

Existem dois sistemais mais comuns de diagramação que ajudam na representação visual do
modelo relacional: O diagrama de entidade-relacionamento DER, e o diagrama correlato
IDEF utilizado no método IDEF1X criado pela Força aérea americana baseado no DER.

Elaborado por Antonio Kalu, estudante de Informatica

5
 B ase de
Dados em Modelo Relacional

3. Dependencias Funcionais
A dependência funcional (DF) é um dos conceitos fundamentais no desenho dos modelos de
dados relacionais. A dependência funcional é uma associação que se estabelece entre dois ou
mais atributos duma relação e define-se do seguinte modo: Se A e B são atributos, ou
conjuntos de atributos, da relação R, diz-se que B é funcionalmente dependente de A se cada
um dos valores de A em R tem associado a si um e um só valor de B em R; a DF tem a
notação: A - B

Na Figura 2-5 é apresentada a notação gráfica relacionada com a dependência funcional. A

dependência funcional é representada por uma linha horizontal que parte do(s) atributo(s)
mais à esquerda, terminando com setas nos atributos dependentes, localizados à direita. Todos
os atributos que não fazem parte da chave primária de uma relação são funcionalmente
dependentes dela.

DF Total e DF Parcial
• DF Total – se um atributo Ax depende funcionalmente de todos os atributos que compõem a
CP de uma tabela T, diz-se que Ax possui DF total da CP de T
• DF Parcial – se um atributo Ax depende funcionalmente apenas de alguns atributos (não
todos!) que compõem a CP de uma tabela T, diz-se que Ax possui DF parcial da CP de T

Elaborado por Antonio Kalu, estudante de Informatica

6
 B ase de
Dados em Modelo Relacional

DF Transitiva ou Indireta
• Se um atributo não-chave Ax possui DF total da CP de uma tabela T e também possui DF
total de um ou mais atributos não-chave de T, então diz-se que Ax possui DF transitiva ou
indireta da CP de T.

4. Normalização
Descrição de normalização

Normalização é o processo de organizar dados numa base de dados. Este processo envolve a
criação de tabelas e o estabelecimentos de relações entre essas tabelas, de acordo com regras
concebidas para proteger os dados e para tornar a base de dados mais flexível, através da
eliminação da redundância e da dependência inconsistente.

Os dados redundantes desperdiçam espaço em disco e criam problemas de manutenção. Se é

necessário alterar dados que existem em mais do que um local, esses dados têm de ser
alterados exactamente do mesmo modo em todos os locais. Uma alteração de morada de um
cliente é muito mais fácil de implementar se esses dados estiverem apenas armazenados na
tabela Clientes e em mais nenhum local da base de dados.

Existem algumas regras para a normalização de bases de dados. Cada regra é chamada
"formula normal". Se a primeira regra é respeitada, diz-se que a base de dados está na
"primeira formula normal". Se as três primeiras regras são observadas, considera-se que a
base de dados está na "terceira formula normal". Apesar de ser possível existirem outros
níveis de normalização, considera-se que a terceira formula normal corresponde ao nível mais
alto necessário para a maior parte das aplicações.

De um modo geral, a normalização requer mais tabelas e alguns clientes acham este
procedimento confuso. Se decidir violar uma das três primeiras regras da normalização,
certifique-se de que a sua aplicação antecipa quaisquer problemas que possam ocorrer, tais
como a existência de dados redundantes e dependências inconsistentes.

Elaborado por Antonio Kalu, estudante de Informatica

7
 B ase de
Dados em Modelo Relacional

4.1 Forma não Normalizada (0FN)

– Obtenção de uma representação padrão para as fontes de dados

– Pode ter uma ou mais tabelas aninhadas possui atributos multivalorados–atributo que ao
invés de conter valores atômicos, contém múltiplos valores ou contém uma tabela que pode,
por sua vez, ser aninhada.

Exemplo de tabela não Normalizada

4.2 Primeira formula normal

• Eliminar grupos repetitivos em tabelas individuais.

• Criar uma tabela separada para cada conjunto de dados relacionados.

• Identificar cada conjunto de dados relacionados com uma chave primária.

Não utilizar múltiplos campos numa só tabela para armazenar dados semelhantes. Por
exemplo, para controlar um item de inventário que pode ser proveniente de duas origens
possíveis, um registo de inventário pode conter campos para Código de fornecedor 1 e
Código de fornecedor 2.

Elaborado por Antonio Kalu, estudante de Informatica

8
 B ase de
Dados em Modelo Relacional

1022 Chaves 412 101-07

1022 Chaves 412 143-01

4123 Silva 216 201-01

4123 Silva 216 214-01

4.3 Segunda formula normal

Uma tabela está na 2FN sse ela estiver na 1FN e não possuir DFs parciais.
• tabelas com DFs parciais devem ser desmembradas em tabelas que possuam DFs
totais
• Tabelas cuja CP possui apenas um atributo estão automaticamente na 2FN
• Criar tabelas separadas para conjuntos de valores que são aplicáveis a múltiplos
registos.

• Relacionar estas tabelas com uma chave externa.

Os registos só devem depender da chave primária de uma tabela (uma chave composta, se for
necessário). Por exemplo, vamos tomar em consideração o endereço de um cliente num
sistema contabilístico. O endereço é requerido pela tabela Clientes, mas também pelas
tabelas Encomendas, Expedição, Contas a receber e Conjuntos. Em vez de armazenar o
endereço do cliente sob a forma de uma entrada separada em cada uma destas tabelas,
armazene-o num só local, quer seja na tabela Clientes quer numa tabela Endereços separada.

Elaborado por Antonio Kalu, estudante de Informatica

9
 B ase de
Dados em Modelo Relacional

4.4 Terceira formula normal

• Uma tabela está na 3FN sse ela estiver na 2FN e não possuir DFs transitivas – tabelas
com DFs transitivas devem ser desmembradas em tabelas que não possuam tais DFs
• Tabelas que possuem zero ou apenas um atributo que não faz parte da CP estão
automaticamente na 3FN
• Eliminar campos que não dependam da chave.

Os valores existentes num registo que não fazem parte da chave desse registo não devem
estar na tabela. De um modo geral, sempre que o conteúdo de um grupo de campos pode ser
aplicado a mais do que um registo da tabela, deve pensar em colocar esses campos numa
tabela separada.

Elaborado por Antonio Kalu, estudante de Informatica

10
 B ase de
Dados em Modelo Relacional

5. Conclusão

Elaborado por Antonio Kalu, estudante de Informatica

11
 B ase de
Dados em Modelo Relacional

A utilização do modelo relacional com as suas principais farramentas, dependências

funcionais bem estabelecidas, Normalização cumprindo as suas formas para sistemas de
bases de dados é um metodo muito eficiente para construcção e gerenciamento das mesmas,
pois com es modelo de SGBD consegue se construir sistemas de bases de dados consistentes
e com boa performance.

6. Referências bibliográficas
• Pesquisa pelo Wikipedia.com;

• Apostila do Modelo relacional para base de dados pelo Apostilando.com;

• www.supot.mycrosof/bd.

Elaborado por Antonio Kalu, estudante de Informatica

12