Buscar

modelagemrelacionalenormalizaodedados

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Modelagem Relacional e
Normalização de Dados
Juliana Alvares
Modelagem Relacional
O Modelo de Dados Relacional representa os dados em um BD através de um conjunto de Relações (tabelas). Estas relações contêm informações sobre entidades ou relacionamentos existentes no domínio da aplicação utilizada como alvo para a modelagem. Informalmente uma relação pode ser considerada como uma tabela de valores, onde cada linha desta tabela representa uma coleção de valores de dados inter relacionados Estes conjuntos de valores podem estar representando uma instância de uma entidade ou relacionamento da aplicação.
Modelagem Relacional
Os nomes fornecidos às tabelas e às suas colunas podem auxiliar na compreensão do significado dos valores armazenados em cada uma das suas linhas. Em terminologia do Modelo Relacional, cada linha da relação é denominada de Tupla, o nome da coluna é denominado Atributo da relação. É importante assinalar que não se podem ter tuplas duplicadas em uma tabela.
FCODIGO 		FNOME 		FCATEGORIA 		FCIDADE
F1 					Santos 		20 						Piracicaba
F2 					Machado 		10 						São Paulo
F3 					Almeida 		30 						São Paulo
F4 					Ferreira 		20 						Campinas
F5 					Rodrigues 	30 						São Carlos
O Domínio consiste de um grupo de valores atômicos a partir dos quais um ou mais atributos (ou colunas) retiram seus valores reais. Como por exemplo o domínio do atributo FCIDADE consiste no conjunto de todos os nomes legais de cidades.
Modelagem Relacional
Modelagem Relacional
O Esquema de uma Relação consiste de um conjunto de atributos que descrevem as características dos elementos a ser modelados. É denotado por R(A1, A2, ...., An), onde cada atributo Ai toma seus valores a partir de um domínio Di; e R é o nome da relação. O número de atributos na relação n, consiste no grau da relação. Os domínios a partir dos quais os atributos da relação retiram seus valores não precisam ser necessariamente distintos. Como exemplo o esquema da relação apresentada na figura anterior é dado por:
Fornecedor (FCodigo, FNome, FCategoria, FCidade)
Modelagem Relacional
Como Esquema de um BD Relacional entende-se o conjunto de intenções (Esquemas das Relações) definidas para todas as relações da Base, e um conjunto de restrições de integridade. Sobre os nomes fornecidos aos atributos, é permitido àqueles que representem conceitos semelhantes, possuir ou não o mesmo nome em diferentes relações. Da mesma forma, atributos representando conceitos diferentes podem possuir o mesmo nome. O conjunto de restrições de integridade define regras básicas que os valores dos atributos devem obedecer quando aparecerem em uma relação.
Modelagem Relacional
A Instância de uma Relação consiste no conjunto de valores que cada atributo, definido no esquema, assume em um determinado instante, formando o conjunto de tuplas. Ou seja, as instâncias das relações formam os dados que são armazenados no BD. As relações apresentam as seguintes características:
a) Não há tuplas duplicadas em uma relação;
b) Ordem das tuplas na relação não é relevante para diferenciar as relações;
c) Os valores dos atributos devem ser atômicos, não sendo divisíveis em componentes.
Modelagem Relacional
Chave é um conjunto de atributos de uma relação e que pode ser utilizado para a realização de qualquer operação que envolva atributos e valores de atributos.
Modelagem Relacional
Uma relação pode ter várias chaves para identificação unívoca de suas tuplas, onde cada uma é denominada de Chave Candidata. Entre as chaves candidatas é escolhida uma pelo DBA (durante a fase de projeto lógico) para ser suportada pelo SGBD e assim, é mantido automaticamente a restrição de unicidade. Esta chave escolhida é denominada de Chave Primária. Desta forma, uma relação nunca apresentará tuplas repetidas em sua instância, o que significa a possibilidade de identificação de cada tupla separadamente uma da outra.
Modelagem Relacional
Da relação apresentada para fornecedores, o conjunto {FCODIGO} é a chave primária da relação, uma vez que dois fornecedores não apresentarão o mesmo código.
Modelagem Relacional
Um conjunto de atributos Fk em um esquema da relação R1 é uma Chave Estrangeira de R1 se os atributos em Fk possuem o mesmo domínio que os atributos da chave primária de uma relação R2 e os valores de Fk em uma tupla de R1 devem ser os mesmos que ocorrem em tuplas de R2 ou serem nulos, e neste caso é dito que os atributos da Fk se referenciam à relação R2.
Modelagem Relacional
Para exemplificar o conceito de chave estrangeira, considere as relações abaixo sobre Peças e Fornecedores, e das peças fornecidas por cada fornecedor (as chaves de cada relação se encontram grifadas):
FORNECEDOR(FCODIGO, FNOME, FCATEGORIA, FCIDADE);
PEÇA (PCODIGO, PNOME, PCOR, PESO, PCIDADE);
FP (FPCODIGO, FCODIGO, PCODIGO, QTDE);
Modelagem Relacional
Entre as relações anteriores, pode-se observar que FCODIGO e PCODIGO quando aparecem na relação FP são chaves estrangeiras desta relação pois são chaves primárias das relações FORNECEDOR e PEÇA, respectivamente.
Normalização de Dados
Normalização de dados é o processo formal passo a passo que examina os atributos de uma entidade, com o objetivo de evitar anomalias observadas na inclusão, exclusão e alteração de registros.
Normalização de Dados
Uma regra de ouro que devemos observar quando do projeto de um Banco de Dados baseado no Modelo Relacional de Dados é a de "não misturar assuntos em uma mesma Tabela". Por exemplo: na Tabela Clientes devemos colocar somente campos relacionados com o assunto Clientes. Não devemos misturar campos relacionados com outros assuntos, tais como Pedidos, Produtos, etc. Essa "Mistura de Assuntos" em uma mesma tabela acaba por gerar repetição desnecessária dos dados bem como inconsistência dos dados.
Normalização de Dados
Normalmente após a aplicação das regras de normalização de dados, algumas tabelas acabam sendo divididas em duas ou mais tabelas, o que no final gera um número maior de tabelas do que o originalmente existente. Este processo causa a simplificação dos atributos de uma tabela, colaborando significativamente para a estabilidade do modelo de dados, reduzindo-se consideravelmente as necessidades de manutenção.
Normalização de Dados
Objetivos
 Minimização de redundâncias e inconsistências;
 Facilidade de manipulações do banco de dados;
 Facilidade de manutenção do sistema de Informação.
Normalização de Dados
O Processo de normalização aplica uma série de regras sobre as tabelas de um banco de dados, para verificar se estas estão corretamente projetadas. Embora existam cinco formas normais (ou regras de normalização), na prática usamos um conjunto de três Formas Normais.
Vejamos as três primeiras formas normais do processo de normalização de dados.
Normalização de Dados
Primeira Forma Normal 1FN
Uma relação estará na Primeira forma normal 1FN, se e somente se todos os domínios básicos contiverem somente valores atômicos (não contiver grupos repetitivos).
Em outras palavras podemos definir que a primeira forma normal não admite repetições ou campos que tenha mais que um valor.
Normalização de Dados
Procedimentos:
a) Identificar a chave primária da entidade;
b) Identificar o grupo repetitivo e removê-lo da entidade;
c) Criar uma nova entidade com a chave primária da entidade anterior e o grupo repetitivo.
Normalização de Dados
Exemplo da primeira forma normal
Considere a tabela cliente abaixo:
Cliente
Código_cliente
Nome
* Telefone
Endereço
Normalização de Dados
Agora a tabela com os dados:
 
		Tabela desnormalizada, ou seja, não está na 1ª forma normal
Analisando teremos:
Normalização de Dados
Todos os clientes possuem Rua, CEP e Bairro, e essas informações estão na mesma célula da tabela, logo ela não está na primeira forma normal. Para normalizar, deveremos colocar cada informação em uma coluna diferente, como no exemplo a seguir:
		Tabela ainda não está na primeira forma normal
Normalização de Dados
Mesmo com o ajuste acima, a tabela ainda não está na primeira forma normal, pois há clientes
com mais de um telefone e os valores estão em uma mesma célula. Para normalizar será necessário criar uma nova tabela para armazenar os números dos telefones e o campo-chave da tabela cliente. Veja o resultado a seguir:
Normalização de Dados
		
		Tabela na 1ª forma normal
		Tabela na 1ª forma normal
Normalização de Dados
Nesse exemplo, foi gerado uma segunda entidade para que a primeira forma normal fosse satisfeita, contudo é possível manter a tabela original, admitindo-se valores duplos em uma mesma coluna, como exemplo o campo telefone ficaria assim: 11-3400-3563 e 19-3500-9650. Neste caso a tabela ficaria desnormalizada, mas muitos acabam preferindo assim, principalmente quando há poucos casos de repetição.
Normalização de Dados
Segunda Forma Normal 2FN
Uma tabela está na Segunda Forma Normal 2FN se ela estiver na 1FN e todos os atributos não chave forem totalmente dependentes da chave primária (dependente de toda a chave e não apenas de parte dela).
Normalização de Dados
Procedimentos:
a) Identificar os atributos que não são funcionalmente dependentes de toda a chave primária;
b) 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 do qual os atributos removidos são funcionalmente dependentes.
Normalização de Dados
Exemplo de segunda forma normal
Considere a tabela vendas abaixo:
Vendas
N_pedido
Código_produto
Produto
Quant
Valor_unit
Subtotal
Normalização de Dados
Agora a tabela com os dados:
	
	Tabela não está na segunda forma normal
Analisando teremos:
Normalização de Dados
O nome do produto depende do código do produto, porém não depende de N_pedido que é a chave primária da tabela, portanto não está na segunda forma normal. Isto gera problemas com a manutenção dos dados, pois se houver alteração no nome do produto teremos que alterar em todos os registros da tabela venda.
Para normalizar esta tabela teremos de criar a tabela Produto que ficará com os atributos Código_produto e produto e na tabela Venda manteremos somente os atributos N_pedido, código_produto, quant, valor_unit e subtotal. Veja o resultado:
Normalização de Dados
	Tabela na 2ª forma normal
	Tabela na 2ª forma normal
Normalização de Dados
Terceira Forma Normal 3FN
Uma tabela está na Terceira Forma Normal 3FN se ela estiver na 2FN e se nenhuma coluna não-chave depender de outra coluna não-chave.
Na terceira forma normal temos de eliminar aqueles campos que podem ser obtidos pela equação de outros campos da mesma tabela.
Normalização de Dados
Procedimentos:
a) Identificar todos os atributos que são funcionalmente dependentes de outros atributos não chave;
b) Removê-los.
A chave primária da nova entidade será o atributo do qual os atributos removidos são funcionalmente dependentes.
Normalização de Dados
Exemplo da terceira forma normal
Considere a tabela abaixo:
		Tabela não está na terceira forma normal
Normalização de Dados
Considerando ainda a nossa tabela Venda, veremos que a mesma não está na terceira forma normal, pois o subtotal é o resultado da multiplicação Quant X Valor_unit, desta forma a coluna subtotal depende de outras colunas não-chave.
Para normalizar esta tabela na terceira forma normal teremos de eliminar a coluna subtotal, como no exemplo a seguir:
Normalização de Dados
			Tabela na terceira forma normal

Teste o Premium para desbloquear

Aproveite todos os benefícios por 3 dias sem pagar! 😉
Já tem cadastro?

Outros materiais