A taberna do Pônei Saltitante

1. Conhecendo a Taberna

1.1. Introdução

Neste projeto iremos utilizar como exemplo de negócio um empreendimento famoso conhecido na literatura que é a Taberna do Pônei Saltitante localizada na cidade de Bree presente nas obras de J.R.R. Tolkien.

Figura: O Senhor dos Anéis. — *Figura: O Senhor dos Anéis* [WIKIPEDIA,O Senhor dos Anéis.]

1.2. Habilidades que serão aprendidas

Neste projeto serão apresentadas técnicas de modelagem de banco de dados e dicas importantes para construir uma base de dados organizada evitando redundâncias.

Identificar e descrever objetos conceituais a partir da regra de negócio;
Construir relacionamentos entre os objetos;
Aplicar regras de normalização;
Diagramar modelos de dados lógico e relacional;
Implementar comandos para construção do banco de dados relacional utilizando PostgreSQL.

Informação: Manipular e construir objetos conceituais facilita a documentação e apresentação de projetos de banco de dados.

2. O projeto

Neste projeto vamos implementar os seguintes elementos :

Modelo Lógico das regras negociais da Caverna do Pônei Saltitante;
Modelo Relacional;
Comandos para construção.

2.1. A cidade de Bree

*Figura: A cidade de Bree.* [TOLKIEN GATEWAY, Bree]

A cidade de Bree conseguiu se manter prospera próspera no Norte, apesar das guerras e tumultos que destruíram o Reino dos Dúnedain do Norte. Dizem que quando os homens foram para o Ocidente, Bree já estava lá e quando os antigos reis retornaram, encontraram Bree os esperando. Dizem que foi fundada pors homens que não voltaram para Beleriand na Primeira Era, e após a queda do Reino de Cardolan na guerra conta Angmar se tornou uma cidade independente.

É a única região na Terra-média, onde Homens e Hobbits convivem em harmonia e e um importante centro comercial para elfos e anões, que são bens de comércio ou viagens de um reino para outro. O centro econômico e social é a Taverna do Pônei Saltitante, conhecida por ter as melhores bebidas do Norte.

2.2. Taverna do Pônei Saltitante e o projeto

*Figura: A Taberna do Pônei Saltitante.*

A Taberna do Ponei Saltitante está ampliando o seu atendimento, buscando atender melhor sua variada clientela, Orc´s, Elfos, Hobbits e Humanos, este último com uma preferência estranha por dispositivos. Também se aliou ao Ferreiro da cidade a fim de diversificar os produtos, acrescentando espadas, escudos, elmos e outros.

Para tal, procura implementar um sistema informatizado para registrar as seguintes informações:

Pedidos dos clientes;
Registro de compras;
Registro de funcionários;
Cargos dos funcionários;
Registro de clientes e suas classificações;
Tabela de preços;

2.3. Detalhes dos atributos

Os cargos tem um valor para ser acrescido no salário do empregado;
Os cargos estão hierarquicamente organizados;
Empregados são registrados com um número de matricula;
Empregados tem um salário base;
E-mail´s dos clientes são registrados;
Raças dos clientes são registrados a fim de personalizar o atendimento;
Endereço dos clientes são registrados;
Clientes são classificados por tipos (Padrão, Especial e Classe A);
Os pedidos dos clientes são feitos em um caderno e nem sempre resultam em uma venda;
Produtos podem ser compostos de outros itens, como por exemplo uma espada com pedras preciosas, aumentando a sua eficácia. Vendemos as pedras em separado também;

2.4. Necessidades

Figura: The Prancing Pony. — *Figura: The Prancing Pony* [TOLKIENGATEWAY,Wiki The_Prancing_Pony]

Quantos clientes estão registrados e quais são suas raças?
Quantos clientes por classe estão registrados?
Qual o valor total das vendas para os clientes da classe Padrão?
Qual o volume de vendas por período?
Quanto cada empregado vendeu por período?
Qual o produto mais vendido?

3. O modelo de dados

Sob a estrutura do banco de dados está o modelo de dados: um conjunto de ferramentas conceituais usadas para a descrição de dados, relacionamentos entre dados, semântica de dados e regras de consistência.

Figura: The_Pillars_of_the_Kings. — *Figura: The_Pillars_of_the_Kings* [TOLKIENGATEWAY, Argonath]

3.1. Existem diversos tipos de modelos de banco de dados, entre eles

Modelo de Arquivos flat;
Modelo Relacional;
Modelo Hierárquico;
Modelo de Rede;
Modelo Orientado a Objeto;

3.2. Processo de Desenvolvimento de Banco de dados

A seguir para descrever os passos do processo para modelar os dados.

Requisitos de informações de negócio - Analise e interpretação da Regra de negócio;
Modelagem de dados Conceitual - Construção do Modelo Lógico;
Design de Banco de dados - Construção do Modelo Relacional;
Criação do Banco de Dados - Construção do modelo no PostgreSQL utilizando comandos SQL;

3.3. Modelo Lógico

Tem por base a percepção de que o mundo real é formado por um conjunto de objetos chamados entidades e pelo conjunto dos relacionamentos entre esse objetos.

Tem o objetivo de facilmente ser interpretado por todos os usuários, utilizando diagramas e representações gráficas dos objetos do negócio.

3.3.1. Elementos do modelo lógico

Entidades;
Atributos e a sua opcionalidade;
Especialização e Generalização;
Relacionamentos e a sua opcionalidade e cardinalidade.

Exemplo:

3.4. Modelo Físico

Estende detalhes do modelo de lógico e tem as seguintes características:

Define com precisão tipos de dados e definições de tabelas;
Identifica exibições, índices e outros objetos de banco de dados;
Descreve como os objetos devem ser implementados no banco de dados específico;
Apresenta chaves primárias e estrangeiras;

Exemplo:

3.5. Comparando os modelos

Análise	Design
Modelo Lógico	Modelo Físico
Entidade	Tabela
Atributo	Coluna
Instância	Linha
UID Primário	Chave Primária
UID Secundário	Restrição Exclusiva
Relacionamento	Chave Estrangeira
Restrição de Negócio	Restrições de Verificação

3.6. Banco de Dados Relacional

Armazena informações em tabelas com linhas e colunas;
Uma tabela é uma coleção de registros;
Uma linha é denominada registro ou instância;
Uma coluna é chamada de campo ou atributo;

Regras:

O nome das tabelas é único;
Nas tabelas o nome das colunas é exclusivo;
As tabelas podem contar várias linhas;
As tabelas tem um valor para identificar as linhas de forma exclusiva;

Exemplo:

CLIENTE ID	CPF	NOME	TIPO	ENDERECO	EMAIL	SEXO_ID	CIDADE_ID
1	001.546.578-04	Aragorn Passos Largos	P	Gondor	aragorn21@gmail.com, passos.largos@hotmail.com	M	35
2	698.474.456-78	Arwen de Valfenda	P	Valfenda	arwenvalfenda@gmail.com	F	13

4. Criando o modelo de dados

Neste capítulo iremos iniciar a analise das necessidades de negócio utilizando o conceito de Regra de Negócio para orientar a análise.

4.1. A Regra de negócio

Permite ao desenvolvedor/arquiteto entender o relacionamento e as restrições das entidades participantes;
Ajuda a entender o procedimento de padronização seguido por uma organização ao lidar com um grande volume de dados;
Devem ser simples e fáceis de entender;
Devem estar atualizadas;

4.2. Mãos a obra

Figura: Angus McBride. — *Figura: Angus McBride* [TOLKIENGATEWAY, Celebrimbor]

O nosso objetivo é extrair informações da regra de negócio a fim de identificar objetos e regras conceituais. Para tal tarefa seguiremos as seguintes premissas:

Identificar Objetos que existem no mundo real ou representam o negócio;
Devemos ser capazes de detalhar as características de cada objeto identificado;
Os objetos devem ser de fácil construção em uma tabela/lista;

A seguir vamos apresentar os objetos extraídos da regra.

4.2.1. Pedidos dos clientes

NÚMERO	DATA	PRODUTO	CLIENTE
123	11/12/2017	Escudo de Carvalho	Thorin
124	05/02/2018	Arco Élfico dourado	Legolas
125	21/04/2018	Punhal de Troll	Aragorm

Existe no mundo real no formato de uma agenda;
Pode ser detalhado : número do pedido,data do pedido, cliente, valor e produto;

4.2.2. Registro de Funcionários

MATRICULA	NOME	SALÁRIO
480001	Bilbo Baggins	1.000
480453	Samwise Gamgee	1.000
480689	Peregrin Took	1.100

Existe no mundo real
Pode ser detalhado : identificação ou matricula, nome e salário;

4.2.3. Cargos dos Funcionários

CARGO ID	NOME
01	Atendente
03	Gerente de Vendas
02	Contabilidade

Existe no mundo real no formato de uma tabela (lista), fixada na sala do gerente;
Pode ser detalhado : nome do cargo e identificação;

4.2.4. Registro de classificação de clientes

ID	NOME
01	Humano
02	Elfo
03	Hobbit
04	Uruk Hai

São classificações de clientes, não existem no formato de listas mas são estão presentes no negócio pois diferenciam o atendimento e os produtos;
Pode ser detalhado : nome da raça e uma identificação;

4.2.5. E-mail dos Clientes

EMAIL
lurtzuruk@terramedia.com
passoscurtos@gmail.com
mariadoc.brandeduque@terramedia.com
elendil@hotmail.com

Identificam um cliente ou funcionário mas não fazem sentido isolados;
Pode ser detalhado mas com outras informações associadas: nome do cliente ou funcionário, identificação e matricula
Na verdade o e-mail é parte do cliente;

Nota importante.

Entender os seguintes conceitos ajudam a fazer a análise:

Dado.

Informação.

Conhecimento.

4.3. Regras e restrições

Figura: The One Ring. — *Figura: The One Ring* [WIKIMEDIA COMMONS,Zanastardust]

Um Anel para governar todos eles,

Um Anel para encontrá-los,

Um Anel para trazê-los todos e na escuridão prendê-los.

Regras	Restrições
Para cada nota são registrados os produtos vendidos.	Um produto pode estar em mais de uma nota; Uma nota pode ter mais de um produto; O valor do produto pode ter descontos e acrescimentos.
Os Clientes tem uma determinada raça; O sexo dos clientes são registrados como M = Masculino e F = Feminino;	Um cliente tem uma raça e uma raça pode estar presente em vários clientes;Somente as letras M ou F podem ser registrados para cada cliente;

5. O SQLDeveloper com PostgreSQL

Neste capítulo vamos utilizar o SQLDeveloper para implementar o modelo de banco de dados.

O que é o SQLDeveloper?

Ferramenta gráfica desenvolvida pela ORACLE;
Permite a implementação de estruturas de banco de dados executando comandos SQL;
Construção de modelos lógicos e físicos;

5.1. Instalação no linux Ubuntu

Instale Java 8;
Baixando o SQLDeveloper Oracle;
Descompactando o SQLDeveloper.

Descompacte o programa no diretório /opt para padronizar as instalação

sudo unzip ~/Downloads/sqldeveloper-*-no-jre.zip -d /opt/
sudo chmod +x /opt/sqldeveloper/sqldeveloper.sh
sudo ln -s /opt/sqldeveloper/sqldeveloper.sh /usr/local/bin/sqldeveloper

Alterando o arquivo sqldeveloper.sh

#!/bin/bash
unset -v GNOME_DESKTOP_SESSION_ID<
cd /opt/sqldeveloper/sqldeveloper/bin && bash sqldeveloper $*

Testando.
```
sqldeveloper.sh
```

Adicionando ao Desktop

Arquivo : /usr/share/applications/sqldeveloper.desktop

[Desktop Entry]
Exec=sqldeveloper
Terminal=false
StartupNotify=true
Categories=GNOME;Oracle;Utility;Development;
Type=Application
Icon=/opt/sqldeveloper/icon.png
Name=Oracle SQL Developer
Comment=SQLDeveloper Oracle
Version=?
GenericName=ORACLE SQL DEVELOPER

5.2. Instalando no Windows

Baixe o aplicativo de preferência com JDK incluído
Descompacte em uma pasta de trabalho, por exemplo: c:\desenvolvimento\SQLDeveloper
- Baixe o driver JDBC para PostgreSQL;
Execute o SQLDeveloper.exe;
Adicione o driver do PostgreSQL : Menu->Ferramentas->Banco de Dados->Drivers JDBC de Terceiros;

5.3. Data Modeler

Acesse em Menu > Exibir > Data Modeler > Browser;
Na janela Browser clique no Modelo Lógico com botão direito e escolha Mostrar para que barra de menu apresente as opções de construção de modelos;

6. O modelo lógico

Figura: Estruturas narrativas. — *Figura: Estruturas narrativas: O modelo funcional de PROPP.*

6.1. Entidade

Define-se entidade como aquele objeto que existe no mundo real com uma identificação distinta e com um significado próprio.

São coisas que existem no negócio, ou ainda, descrevem o negócio.

Uma entidade tem um conjunto de propriedades e os valores para alguns conjuntos dessas propriedades devem ser únicos.

Exemplo :

Notas fiscais (número, data, valor total)
Clientes (cpf, nome, sexo,endereço)
Produtos (código, endereço, valor)
Cidade (id,nome, estado)

6.2. Representação no modelo lógico

6.3. Representação no modelo relacional (Tabela)

6.3.1. Tabela Cliente

CLIENTE ID	CPF	Nome
1	001.546.578-04	Aragorn N Gondor
2	787.354.789-55	Legolas N Valfenda
3	000.000.000-00	Gandalf E Terra Média

6.4. Restrições

Os nomes não podem conter espaços em branco;
Não usar caracteres especiais “@#$%¨&*”;
Não usar palavras reservadas: INSERT, UPDATE, DELETE, SELECT e etc;
Tamanho de 30 caracteres;

7. Os relacionamentos

Toda entidade é representada por um conjunto de atributos.

Exemplo modelo relacional:

Atributos são propriedades descritivas de entidades. Cada instância de CLIENTE será formada por valores nestes atributos, e o conjunto destes valores devemos visualizar como uma linha de uma tabela.

ID	CPF	NOME	TIPO	ENDERECO	EMAIL	SEXO_ID	CIDADE_ID
1	001.546.578-04	Aragorn Passos Largos	P	Gondor	aragorn21@gmail.com ,passos.largos@hotmail.com	M	35
2	698.474.456-78	Arwen de Valfenda	P	Valfenda	arwenvalfenda@gmail.com	F	13
3	000.000.000-00	Gandalf o Cinzento	E	Terra Média	mago@gmail.com	M	500

7.1. Tipos de atributos

7.1.1. Simples

Expressam um valor indivisível. Exemplo : SEXO_ID

7.1.2. Compostos

Expressam mais de um valor, pode ser dividido. Exemplo: NOME e ENDERECO

7.1.3. Monovalorados

Exemplo : CIDADE_ID para a entidade cliente

7.1.4. Multivalorado

Pode contar vários valores. Exemplo : EMAIL

7.1.5. Atributos nulos

Podem ser nulos. Exemplo : EMAIL

7.1.6. Atributo derivado

O valor deriva de outro atributo. Exemplo : VALOR TOTAL
O VALOR TOTAL é construído com outros objetos ou atributos como descontos, acréscimos e A SOMA TOTAL DE TODOS OS PRODUTOS daquela venda.

7.2. Restrições de atributos

Os nomes não podem conter espaços em branco;
Não usar caracteres especiais “@#$%¨&*”;
Não usar palavras reservadas: VARCHAR,CHAR,INTEGER e etc;
Tamanho de 30 caracteres;

7.3. Representação

\s# = Chave primária ou (P) no modelo relacional;
F = Chave estrangeira, somente no modelo relacional;
O = Atributo;
“*” = Obrigatório;

8. Chave primária

Este(s) atributo(s) cujos valores nunca se repetem, sempre tem(têm) a função de atuar(em) como identificador(es) único(s) das instâncias da entidade. Chave primária então é o atributo (ou conjunto de atributos concatenados) que identifica uma única ocorrência dentro de uma tabela.

Representação no modelo lógico (#).
Representação no modelo relacional (P).
A coluna ID é a chave primária da tabela e apresenta as seguintes características:
Não se repete
Não é nula
É um índice (estrutura de acesso mais rápida)

ID	CPF	NOME	TIPO	ENDERECO	EMAIL	SEXO_ID	CIDADE_ID
1	001.546.578-04	Aragorn Passos Largos	P	Gondor	aragorn21@gmail.com ,passos.largos@hotmail.com	M	35
2	698.474.456-78	Arwen de Valfenda	P	Valfenda	arwenvalfenda@gmail.com	F	13
3	000.000.000-00	Gandalf o Cinzento	E	Terra Média	mago@gmail.com	M	500

9. Especializações

9.1. Especialização

Considere a entidade CLIENTE, ela pode ser definida em um conjunto de entidades classificados como :

PADRÃO (P);
ESPECIAL (E);
CLASSE A (A);

ID	CPF	NOME	TIPO	ENDERECO	EMAIL	SEXO_ID	CIDADE_ID
1	001.546.578-04	Aragorn Passos Largos	P	Gondor	aragorn21@gmail.com ,passos.largos@hotmail.com	M	35
2	698.474.456-78	Arwen de Valfenda	P	Valfenda	arwenvalfenda@gmail.com	F	13
3	000.000.000-00	Gandalf o Cinzento	E	Terra Média	mago@gmail.com	M	500

O processo de projetar os subgrupos dentro de um conjunto de entidades é chamado de especialização, o qual nos permite distinguir os tipos de clientes.

ID	CPF	NOME	TIPO	ENDERECO	EMAIL	SEXO_ID	CIDADE_ID
1	001.546.578-04	Aragorn Passos Largos	P	Gondor	aragorn21@gmail.com ,passos.largos@hotmail.com	M	35
2	698.474.456-78	Arwen de Valfenda	P	Valfenda	arwenvalfenda@gmail.com	F	13

Auxilia na segurança dos dados, pois restringe a sua visualização e acesso.

Podemos restringir o acesso as colunas e linhas de uma tabela,como por exemplo :

NOME	TIPO	ENDERECO	EMAIL
Gandalf o Cinzento	E	Terra Média	mago@gmail.com

9.1.1. Generalização

Praticamente a generalização é o inverso da especialização.

Por exemplo: a entidade PRODUTO é na realidade uma generalização para diversas entidades de dados de PRODUTOS (registrados em várias filias).

PRODUTOS - Todos os produtos ID e NOME.

ID	NOME
11	Espada de Eldor
12	Espada Élfica
21	Escudo de carvalho
22	Escudo de Mitrill

PRODUTO - Espadas ID e NOME

ID	NOME
11	Espada de Eldor
12	Espada Élfica

PRODUTOS - Escudos ID e NOME

ID	NOME
21	Escudo de carvalho
22	Escudo de Mitrill

Em Sistemas Distribuídos podemos resumir a visualização de diferentes entidades em somente uma.

Exemplo: Espadas podem estar armazenadas em uma cidade e escudos em outra.

Um relacionamento é uma associação entre uma ou várias entidades. Por exemplo: podemos definir um relacionamento que associa o cliente ARAGORN com a cidade DOR-LÓNIM. Esse relacionamento especifica que cliente ARAGORN é um cliente que mora em DOR-LÓNIM.

Outro exemplo:

Os clientes Compram Produtos;
As Notas Tem Produtos;
As Notas Tem Vendedores;
Os Vendedores Registram Notas

10. Cardinalidade

No relacionamento entre duas entidades o número de ocorrências de uma entidade que está associado a outra entidade determina a cardinalidade.

Um para Um;
Um para Muitos;
Muitos para Muitos;

Representação

Ramificação - Um ou mais valores
Tracejado - Opcional
Ponta única - Apenas um valor
Ponta contínua - Obrigatório

10.1. Um para Um

Significa que cada elemento da entidade PEDIDO relaciona-se com somente um elemento de entidade NOTA.

Modelo lógico.

Um PEDIDO tem uma NOTA -> NOTA tem um PEDIDO

Modelo relacional.

Tabelas.

PEDIDO ID	DATA
1	12/11/2016
3	02/04/2017
6	10/10/2017

NOTA ID	DATA	VALOR_TOTAL	SERIE	CHAVE	PEDIDO_ID
1	12/11/2016	2.500,00	00012345	QERE001	1
3	02/04/2017	2.500,00	00012378	QERE010	3
6	10/10/2017	2.500,00	00019874	QERE022	6

10.2. Um para muitos

Um elemento da entidade CIDADE relaciona-se com muitos elementos da entidade CLIENTE, mas cada elemento da entidade CLIENTE somente pode estar relacionado a um elemento da entidade CIDADE. Modelo lógico

Uma CIDADE tem vários CLIENTES-> CLIENTE pertence a uma CIDADE

Modelo Relacional

Tabelas

CIDADE ID	DESCRICAO	UF
1	Valfenda	CO
2	Castelo Sul	SR
3	Vento Bravo	AR

CLIENTE ID	CPF	NOME	TIPO	ENDERECO	EMAIL	CIDADE_ID
1	001.546.578-04	Aragorn	N	Gondor	…	1
2	787.354.789-55	Legolas	N	Valfenda	…	1
3	000.000.000-00	Gandalf	E	Terra Média	…	2

Chave primária;
Chave estrangeira, referência a chave primária de outra tabela;

10.3. Muitos para muitos

Um elemento da entidade PRODUTO relaciona-se com muitos elementos da entidade NOTA e cada elemento da entidade NOTA está relacionado a um elemento da entidade PRODUTO. Modelo lógico.

Um PRODUTO pode estar em várias NOTAS-> NOTA tem vários PRODUTOS

Modelo relacional. Tabelas.

PRODUTO ID	DESCRICAO	VALOR
1	Espada Bronze	150,00
3	Escudo Prata	420,00
6	Arco de Madeira	100,00

PRODUTO_NOTA	PRODUTO_ID	NOTA_ID	QUANTIDADE	VALOR_VENDA
1	1	1	1,0	150,00
2	3	1	1,0	420,00
3	6	3	2,0	100,00

NOTA ID	DATA	VALOR_TOTAL	SERIE	CHAVE	PEDIDO_ID
1	12/11/2016	2.500,00	00012345	QERE001	1
3	02/04/2017	2.500,00	00012378	QERE010	3
6	10/10/2017	2.500,00	00019874	QERE022	6

Para a organização dos dados é construída uma tabela (tabela de relacionamento) entre as duas entidades;

A nova tabela herda as chaves primárias das duas tabelas que ela relaciona;

Importante verificar que a tabela tem outros atributos que expressam valores únicos do negócio , QUANTIDADE e VALOR_PRODUTO pois para cada venda eles variam;

É um tipo especial de relacionamento onde as entidades se relacionam com elas mesmas. Tipos de auto-relacionamentos.

10.4. Auto-relacionamento Um-para-Muitos

Considere a entidade CARGOS, observe que alguns cargos são filhos de outros cargos (ordem hierárquica).

Modelo lógico.
Modelo relacional.

Tabela.

CARGO ID	DESCRICAO	VALOR	CARGO_ID
1	Gerente Comercial	1.000,00
2	Atendente	500,00	1
3	Embalador	500,00	1
4	Gerente de Negócio	4.000,00
5	Contador	2.000,00	4

10.5. Auto-relacionamento Muitos-para-Muitos.Muitos para muitos

Observe que os itens registrados na entidade PRODUTO podem ser compostos de vários outros itens, componentes. Por outro lado, um item componente pode participar da composição de muitos itens

Modelo lógico.
Modelo relacional.

Tabelas.

PRODUTO ID	DESCRICAO	VALOR	CATEGORIA_ID
1	Espada de aço da montanha da perdição	200,00	2
2	Poder de gelo	300,00	4
3	Escudo de Carvalho	180,00	6
4	Pedra azul	20,00	5
5	Garrafa de Bafo de Yeti	10,00	5

COMPONENTE	PRODUTO_ID	PRODUTO_ID1
1	2
32	24	25

É um processo matemático formal, que tem seus fundamentos na teoria dos conjuntos. Através deste processo pode-se, gradativamente, substituir um conjunto de entidades e relacionamentos por um outro, o qual se apresenta “purificado” em relação às anomalias de atualização (inclusão, alteração e exclusão) as quais podem causar certos problemas, tais como: grupos repetitivos (atributos multivalorados) de dados, dependências parciais em relação a uma chave concatenada, redundância de dados desnecessárias, perdas acidentais de informação, dificuldade na representação de fatos da realidade observada e dependências transitivas entre atributos. Anomalias.

Considere o formulário de NOTAS apresentado a seguir. Podemos considerar que uma entidade formada com os dados presentes neste documento, terá a seguinte apresentação:

NOTAS ID	DATA	CLIENTE	EMAIL	ENDERECO	CIDADE	UF	PRODUTO_ID	DESCRICAO	UNID.	QUANTIDADE	VALOR
1	12/11/2016	Elendur	elendur@hotmail.com, elendur12r@gmail.com	Rua das Flores	LAGO	VL	1	Espada de fogo	P	1	200,00
1	02/04/2017	Elendur	elendur@hotmail.com, elendur12r@gmail.com	Rua das Flores	LAGO	VL	2	Escudo de Carvalho	P	1	180,00
3	10/10/2017	Durin II	durinii@yahoo.com.br	Caverna de Orgrimar	Floresta Negra	GO	8	Cajado de Gelo	P	1	1.200,00
3	30/11/2017	Eldacar	el65@gmail.com, jhon65@gmail.com	Caverna de Orgrimar	Floresta Negra	GO	12	Cajado de Fogo do Vulcão	P	1	1.300,00

Caso a entidade fosse implementada como uma tabela em um banco de dados, as seguintes anomalias iriam aparecer:

Anomalia de inclusão: ao ser incluído um novo cliente, o mesmo tem que estar relacionado a uma venda;
Anomalia de exclusão: ao ser excluído um cliente, os dados referentes as suas compras serão perdidos;
Anomalia de alteração: caso algum fabricante de produto altere a faixa de preço de uma determinada classe de produtos, será preciso percorrer toda a entidade para realizar múltiplas alterações;

10.6. Formas Normais

Primeira Forma Normal (1FN);
Dependência Funcional;
- Total e parcial;
- Transitiva;
Segunda Forma Normal (2FN);
Terceira Forma Normal (3FN);
Forma Normal de BOYCE/CODD (FNBC);
Quarta forma normal (4FN).

10.6.1. Primeira forma normal (1FN)

Uma tabela está na 1FN se e somente se:

Todos seus atributos forem atômicos, atributos compostos não são permitidos EMAIL;
Cada ocorrência da chave primária (ID) deve corresponder a uma e somente uma informação de cada atributo, ou seja, a entidade não deve conter grupos repetitivos;

NOTAS ID	DATA	CLIENTE	EMAIL	ENDERECO	CIDADE	UF	PRODUTO_ID	DESCRICAO	UNID.	QUANTIDADE	VALOR
1	12/11/2016	Elendur	elendur@hotmail.com, elendur12r@gmail.com	Rua das Flores	LAGO	VL	1	Espada de fogo	P	1	200,00
1	02/04/2017	Elendur	elendur@hotmail.com, elendur12r@gmail.com	Rua das Flores	LAGO	VL	2	Escudo de Carvalho	P	1	180,00
3	10/10/2017	Durin II	durinii@yahoo.com.br	Caverna de Orgrimar	Floresta Negra	GO	8	Cajado de Gelo	P	1	1.200,00
3	30/11/2017	Eldacar	el65@gmail.com, jhon65@gmail.com	Caverna de Orgrimar	Floresta Negra	GO	12	Cajado de Fogo do Vulcão	P	1	1.300,00

10.6.1.1. Dependência funcional

Dizemos que um atributo ou conjunto de atributos A é dependente funcional de um outro atributo B contido na mesma entidade se, a cada valor B existir nas linhas da entidade em que aparece, um único valor de A . Em outras palavras, A depende funcionalmente de B, Exemplo : Na entidade NOTA, o atributo DATA depende funcionalmente de ID.

O exame das relações existentes entre os atributos de uma entidade deve ser feito a partir do conhecimento (conceitual) que se tem sobre a realidade a ser modelada.

Dependência funcional parcial ou total.

Na ocorrência de uma chave primária concatenada, dizemos que um atributo ou conjunto de atributos depende de forma completa ou total desta chave primária concatenada, se e somente se, a cada valor da chave (e não parte dela) está associado a um valor para cada atributo. Quando um atributo só depende de parte da chave primária concatenada e não dela como um todo é dito “dependente parcial”. A dependência total ou parcial só acontece quando a chave primária é concatenada.

Exemplo:

Dependência total: Na Entidade PRODUTO, o atributo QUANTIDADE depende de forma total da chave primária concatenada PRODUTO_ID + NOTA_ID

Dependência funcional transitiva

Quando um atributo ou conjunto de atributos A depende de outro atributo B que não pertence à chave primária (mas é dependente funcional desta) dizemos que A é Dependente Transitivo de B. Exemplos: Na entidade NOTA, os atributos ENDERECO, CIDADE e UF são dependentes transitivos do atributo

CLIENTE.

NOTAS ID	DATA	CLIENTE	EMAIL	ENDERECO	CIDADE	UF	PRODUTO_ID	DESCRICAO	UNID.	QUANTIDADE	VALOR
1	12/11/2016	Elendur	elendur@hotmail.com, elendur12r@gmail.com	Rua das Flores	LAGO	VL	1	Espada de fogo	P	1	200,00
1	02/04/2017	Elendur	elendur@hotmail.com, elendur12r@gmail.com	Rua das Flores	LAGO	VL	2	Escudo de Carvalho	P	1	180,00
3	10/10/2017	Durin II	durinii@yahoo.com.br	Caverna de Orgrimar	Floresta Negra	GO	8	Cajado de Gelo	P	1	1.200,00
3	30/11/2017	Eldacar	el65@gmail.com, jhon65@gmail.com	Caverna de Orgrimar	Floresta Negra	GO	12	Cajado de Fogo do Vulcão	P	1	1.300,00

10.6.2. Segunda forma normal (2FN)

A segunda forma normal assegura que não exista dependência funcional parcial no modelo de dados. Para aplicarmos a segunda forma normal em um modelo de dados devemos observar se alguma entidade do modelo possui chave primária concatenada e verificar se existe algum atributo ou conjunto de atributos com dependência parcial em relação a algum atributo da chave primária concatenada.

Exemplo:

A entidade PRODUTO_NOTA apresenta uma chave primária concatenada e por observação, notamos que os atributos QUANTIDADE e VALOR_VENDA dependem de forma parcial do atributo PRODUTO_ID, que faz parte da chave primária.

10.6.3. Terceira forma normal (3FN)

A terceira forma normal assegura que nenhuma entidade do modelo de dados possui atributos com dependência transitiva. Assim, uma entidade está na 3FN se nenhum de seus atributos possui dependência transitiva em relação a outro atributo da entidade que não participe da chave primária, ou seja, não existe nenhum atributo intermediário entre a chave primária e o próprio atributo observado.

Ao retirarmos a dependência funcional transitiva, devemos criar uma nova entidade que contenha os atributos que dependem transitivamente de outro e a sua chave primária é o atributo que causou esta dependência. Também não devem conter atributos derivados, como por exemplo VALOR TOTAL.

10.6.4. Forma Normal de Boyce/Codd

A forma normal 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 tratarem 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:

TURMA_CURSO	ALUNO_ID	TURMA	CURSO_ID	PROFESSOR_ID
0012015	0101	SIS	01	0072003
0022015	8901	DIR	01	4592005
0032015	9001	PSI	01	0072003

Um mesmo professor pode ministrar aulas entre cursos e turmas diferentes. Sendo assim podemos identificar três chaves candidatas que são determinantes nessa entidade: CURSO_ID+TURMA, CURSO_ID+PROFESSOR_ID e TURMA+PROFESSOR_ID. O atributo PROFESSOR_ID é parcialmente dependente do CURSO_ID e de TURMA, mas é totalmente dependente da chave candidata composta CURSO_ID+TURMA. Dessa forma a entidade deve ser desmembrada, resultando em duas: uma que contém os atributos que descrevem o aluno em si e outra cujos atributos designam um professor.

TURMA_ALUNO	TURMA	CURSO_ID	ALUNO_ID
0101	SIS	01	0012015
8901	DIR	01	0022015
9001	PSI	01	0032015

TURMA_PROFESSOR	TURMA	CURSO_ID	PROFESSOR_ID
0101	SIS	01	0072003
8901	DIR	01	4592005
9001	PSI	01	0072003

10.6.5. Quarta Forma Normal (4FN)

Uma tabela está na 4FN, se e somente se, estiver na 3FN e não existirem dependências multivaloradas.

11. Referências

Tolkien Gataway

A taberna do Pônei Saltitante

March 1, 2024 21 minuto(s) de leitura

Neste projeto serão apresentadas técnicas e dicas de modelagem de banco de dados.