Modelo Relacional

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