8 DICAS PARA NÃO ERRAR NA MODELAGEM DO SEU BANCO DE DADOS Um banco de dados bem modelado pode facilitar e economizar horas de programação e claro tornar sua aplicação muito mais eficiente e robusta.

1. BANCO DE DADOS

2. ApresentaçãoApresentação
Engenheira de Controle e Automação (UFPEL/2015)
Developer @ Datum TI
Redes Sociais:
facebook.com/nouara.candida
linkedin.com/in/nouaracandidaxavier
github.com/NouaraCandida
nouara.xavier@datumcorp.inf.br
Análise e Desenvolvimento de Sistemas (FAQI/2016)
Developer @ Datum TI
Redes Sociais:
facebook.com/ thales.ludwig
linkedin.com/in/thalesludwig
github.com/ThalesLudwig
thales.valentini@datumcorp.inf.br
Thales Ludwig Valentini
Nouara Cândida Xavier

3. Me tornei DBA e agora?Me tornei DBA e agora?
8 DICAS PARA NÃO ERRAR NA MODELAGEM DO SEU BANCO DE
DADOS
Um banco de dados bem modelado
pode facilitar e economizar horas de
programação e claro tornar sua
aplicação muito mais eficiente e
robusta.

4. IdiomaIdioma
DICA 1
A tabela se chamará Usuários ou Users?

5. Relacional ou Não RelacionalRelacional ou Não Relacional
DICA 2
Relacional:
• Oracle
• MySQL
• PostgreSQL
• SQLite
• SQL Server
Alta consistência de dados, além da
confiabilidade e de ser usado a
propriedade ACID(Atomicidade,
consistência, isolamento e durabilidade).
Não Relacional:
• MongoDB
• Cassandra
• Voldemort
• CouchDB
• Riak
Trocar a confiabilidade e a consistência pela
escalabilidade

6. Integridades de DadosIntegridade de Dados
DICA 3
Um banco de dados bem modelado deve
receber atenção redobrada no momento de
decidir os tipos das colunas de suas tabelas.
Tipos de Integridade:
•Integridade de tipo de dados – De acordo
com o tipo
•Integridade de vazio – Nulo ou não
•Integridade de chave – Não nulo e único
•Integridade referencial(estrangeira) – Existe
na tabela mãe

7. Generalizações e EspecializaçGeneralizações e Especializações
DICA 4
Parcial: nem toda ocorrência da entidade
genérica possui uma ocorrência
correspondente em uma
entidade especializada
Podem haver funcionários que não sejam
nem motorista e nem secretária.
Total: para toda ocorrência da entidade
genérica existe sempre uma ocorrência em
uma das entidades especializadas
Não existe a possibilidade de haver um
cliente que não seja pessoa física OU pessoa
jurídica.

8. Normalização :Tabela AninhadaNormalização: Tabela Aninhada
DICA 5
Tabela Venda
CodVenda
Cliente
Endereço
Cep
Cidade
Estado
Produto
Quantidade
ValorUnitário
ValorFinal
Tabela Venda
CodVenda
CodCliente
Produto
Quantidade
ValorUnitário
ValorFinal
Tabela Cliente
CodCliente
Nome
Endereço
Cep
Cidade
Estado
Tabela Venda
CodVenda
CodCliente
CodCidade
Produto
Quantidade
ValorUnitário
ValorFinal
Tabela Cliente
CodCliente
CodCidade
Nome
Endereço
Cep
Tabela Cidade
CodCidade
Nome
Estado

9. Normalização :Tabela AninhaNormalização: Tabela Aninhada
DICA 5
Tabela Venda
CodVenda
CodCliente
CodCidade
CodProduto
Quantidade
ValorFinal
Tabela Cliente
CodCliente
CodCidade
Nome
Endereço
Cep
Tabela
Cidade
CodCidade
Nome
Estado
Este campo depende de quem?
•A tabela Venda, deve armazenar
informações da venda;
•Dependência Funcional: Estado na
tabela Cliente, depende de Cidade
e vice e versa;
•O ValorUnitário depende de
Produto. Já a Quantidade (campo
entre Produto e ValorUnitario) não
depende do produto e sim da
Venda.
Tabela
Produto
CodProduto
Nome
ValorUnitario

10. Normalização : Dependências ParcNormalização: Dependências Parciais
DICA 6
Tabela Venda
CodVenda
CodCliente
CodCidade
CodProduto
Quantidade
ValorFinal
Verificar todos os campos não-chaves:
•O primeiro campo não-chave é Quantidade.
•Quantidade depende de Codvenda, pois para cada
venda há uma quantidade específica de itens.
•Quantidade depende de Codvenda e Codcliente, pois
para um cliente podem ser feitas várias vendas, com
quantidades diferentes.
•Quantidade não depende de Cidade. Quem depende de
Cidade é Cliente. Aqui está uma dependência parcial.
•Quantidade depende de Codproduto, pois para cada
produto da Venda á uma quantidade certa.
Tabela Venda
CodVenda
CodCliente
Produto
Quantidade
ValorFinal

11. Normalização : Dependências TranNormalização: Dependências Transitivas
DICA 7
Tabela Venda
CodVenda
CodCliente
Produto
Quantidade
ValorUnitário
ValorFinal
Este campo depende de outro que não seja a chave? Se
Sim, temos uma dependência transitiva.
•Valorfinal é o resultado do valor unitário do produto
multiplicado pela quantidade, isto é, para um valor final
existir ele DEPENDE de valor unitário e quantidade.
•O Valorunitário está na tabela Produto, relacionada à
Venda e Quantidade está na própria Venda.
• Valorfinal depende destes 2 campos e eles não são
campos-chave, o que nos leva a pensar: Se temos valor
unitário e quantidade, porque teremos valor final?
•O valor final nada mais é que o resultado de um cálculo
de dados que já está estão no banco, o que o torna um
campo redundante..
Tabela Venda
CodVenda
CodCliente
Produto
Quantidade
ValorUnitário

12. Seja um Bom ObservadorSeja um Bom Observador
DICA 8
Toda modelagem requer a
observação de um cenário ou
situação.
• Analisar
• Entrevistar
• Prever
• Estudar
• Confirmar

13. RefênciasReferências
• Edgar Frank Codd (desenvolveu o
modelo de banco de dados
relacional);
• https://imasters.com.br/artigo/7020/banco-de-dados/modelagem-de-dados-final-normalizacao

14. Obrigado!