PostgreSQL Prático/Apêndices/Planejamento e Projeto de Bancos de Dados
15.1 – Planejamento e Projeto de Bancos de Dados
[editar | editar código-fonte]Projeto de bancos de dados é genérico e se aplica a qualquer SGBDR.
É com um bom planejamento do banco de dados que se determina o quão eficaz foi o processo de análise.
Introdução
O projeto do banco de dados e também os testes são muito importantes para a eficiência e consistência das informações e do aplicativo. É muito importante gastar algum tempo nesta etapa, pois depois de algum tempo de implantado fica muito trabalhoso alterar estruturas de bancos e aplicativos.
Projetos de banco de dados ineficazes geram consultas que retornam dados inesperados, relatórios que retornam valores sem sentido, etc. Um banco de dados bem projetado fornece um acesso conveniente às informações desejadas e resultados mais rápidos e precisos.
Exemplo de software de administração de SGBD para o PostgreSQL - PGAdmin
Informações de bancos de dados relacionais são armazenadas em tabelas ou entidades no Modelo Entidade Relacionamento (MER).
Dicas sobre Campos
• Não armazenar resultado de cálculos ou dados derivados de outros
• Armazenar todas as informações (campos) separadamente. Cuidado com campos que contém duas ou mais informações.
Selecionando o Campo para a Chave Primária
A chave primária é o campo ou campos que identificam de forma exclusiva cada registro.
• Não é permitido valores nulos na chave nem duplicados
• Caso a tabela não tenha um campo que a identifique, pode-se usar um campo que numere os registros seqüencialmente
Dica de Desempenho: O tamanho da chave primária afeta o desempenho das operações, portanto usar o menor tamanho que possa acomodar os dados do campo.
Exemplo
Tabela - Clientes
Campo - Nome (atributo)
Chave Primária (Primary-Key) - CPF
Todos os campos correspondentes a um único CPF juntamente com seus valores formam um Registro ou Linha (Row)
A correta determinação das tabelas, bem como dos campos é algo primordial no sucesso do projeto do banco de dados.
Chave Primária - obriga que todos os registros terão o campo correspondente à chave primária exclusivo (únicos - unique). Num cadastro de clientes, todos os clientes cadastrados terão um campo CPF exclisivo. Caso se tente inserir dois clientes com o mesmo CPF o banco não permitirá e emitirá uma mensagem de erro acusando tentativa de violação da chave primária.
Exemplos de Campos indicados para chave primária:
• CPF
• CNPJ
• Matrícula de aluno
• Matrícula de funcionário
Uma chave primária pode ser formada por mais de um campo, quando um único campo não é capaz de caracterizar a tabela.
Cada tabela somente pode conter uma única chave primária.
Relacionamentos - Um banco de dados é formado por várias tabelas. Idealmente essas tabelas devem ser relacionadas entre si para facilitar a troca de informações e garantir a integridade. Para relacionar tabelas usamos chaves existentes nas mesmas.
Tipos de Relacionamentos
• Um para um
• Um para vários
• Vários para vários
Relacionamento Um para Um
Aquele onde os campos que fazem o relacionamento são chaves primárias. Cada registro de uma tabela se relaciona com apenas um registro da outra tabela. Este relacionamento não é muito comum.
Exemplo: CorrentistaBanco - Conjuge
Relacionamento Um para Vários ou Vários para Um
Aquele onde uma tabela tem um campo chave primária que se relaciona com outra tabela através de um campo chave estrangeira. É o tipo de relacionamento mais utilizado.
Exemplos:
• Clientes - Pedidos
• Produtos - Itens
• Categorias - Itens
• Fornecedores - Produtos
• NotaFiscal - Produtos
Veja que cada um da esquerda se relaciona com vários do da direita.
Importante:
• O número de campos do relacionamento não precisa ser o mesmo
• O tipo de dados dos campos do relacionamento deve ser igual, assim como o tamanho dos campos e formatos
• Chave primária - Chave estrangeira (um - vários)
Relacionamento Vários para Vários
Este tipo de relacionamento não dá para ser implementado no modelo relacional, portanto sempre que nos deparamos com um deles devemos dividir em dois relacionamentos um para vários (criando uma terceira tabela, que armazenará o lado vários dos relacionamentos).
Exemplo:
Pedidos - Produtos
Cada pedido pode conter vários produtos, assim como cada produto pode estar em vários pedidos. A saída é criar uma tabela que contenha os itens do pedido.
Pedidos - Pedidos_Itens - Produtos
Pedidos 1 - N Pedidos_Itens N - 1 Produtos
Integridade Referencial
Ela garante a integridade dos dados nas tabelas relacionadas. Um bom exemplo é quando o banco impede que se cadastre um pedido para um cliente inexistente, ou impede que se remova um cliente que tem pedidos em seu nome.
Também se pode criar o banco de forma que quando atualizamos o CPF de um cliente ele seja atualizado em todos os seus pedidos.
Normalização de Tabelas
Normalizar bancos tem o objetivo de tornar o banco mais eficiente.
Uma regra muito importante ao criar tabelas é atentar para que cada tabela contenha informações sobre um único assunto, de um único tipo.
1a Forma Normal
Os campos não devem conter grupos de campos que se repetem nos registros.
Exemplo:
Alunos: matricula, nome, data_nasc, serie, pai, mae
Se a escola tem vários filhos de um mesmo casal haverá repetição do nome dos pais. Estão para atender à primeira regra, criamos outra tabela com os nomes dos pais e a matrícula do aluno.
2ª Forma Normal
Quando a chave primária é composta por mais de um campo.
Devemos observar se todos os campos que não fazem parte da chave dependem de todos os campos que fazem parte da chave.
Caso algum campo dependa somente de parte da chave, então devemos colocar este campo em outra tabela.
Exemplo:
TabelaAlunos
Chave (matricula, codigo_curso)
avaliacao descricao_curso
Neste caso o campo descricao_curso depende apenas do codigo_curso, ou seja, tendo o código do curso conseguimos sua descrição. Então esta tabela não está na 2ª Forma Normal.
Solução:
Dividir a tabela em duas (alunos e cursos):
TabelaAlunos
Chave (matricula, codigo_curso)
avaliacao
TabelaCursos
codigo_curso
descricao_curso
3ª Forma Normal
Quando um campo não é dependente diretamente da chave primária ou de parte dela, mas de outro campo da tabela que não pertence à chave primária. Quando isso ocorre esta tabela não está na terceira forma normal e a solução é dividir a tabela.
Lembrando: Engenharia Reversa (parte de um banco ou de um script sql e gera o modelo).
Projeto
Fases do Projeto do Banco de Dados
• Modelagem Conceitual
• Projeto Lógico
Observação.: Trataremos apenas de novos projetos.
Modelo Conceitual - Define apenas quais os dados que aparecerão no banco de dados, sem se importar com a implementação do banco. Para essa fase o que mais se utiliza é o DER (Diagrama Entidade-Relacionamento).
Modelo Lógico - Define quais as tabelas e os campos que formarão as tabelas, como também os campos-chave, mas ainda não se preocupa com detalhes como o tipo de dados dos campos, tamanho, etc.
Etapas na Estruturação e Projeto de um Banco de Dados
• Problemas a serem solucionados com o banco de dados
• Determinar o objetivo do banco de dados
• Determinar as tabelas necessárias (cada uma com um único assunto exclusivo)
• Determinar os campos de cada tabela
• Criar um DER
• Verificar a estimativa do crescimento do banco e preparar-se para isso
• Investigar como são armazenadas as informações atualmente e recolher a maior quantidade de informações para o projeto
• Adotar um modelo e justificá-lo (Os itens acima fazem parte do Modelo Conceitual, abaixo do Lógico)
• Determinar a chave primária de cada tabela. Pode haver tabela sem chave primária.
• Determinar os relacionamentos e seus tipos
Obs.: Somente quando da implementação (modelo físico) serão tratados os detalhes internos de armazenamento. O modelo físico é a tradução do modelo lógico para a linguagem do SGBDR a ser utilizado no sistema.