Neste item apresentarei os passos básicos para projetar um Banco de Dados. Mostrarei como aplicar os conhecimentos sobre Entidades, Atributos, Relacionamentos, Chave Primária e Normalização.
Um Banco de Dados bem projetado fornece um acesso conveniente às informações desejadas, de tal maneira que as informações estejam disponíveis para os usuários que dela necessitarem no momento em que a informação for necessária.
Neste item estou falando do projeto físico do Banco de Dados, isto é, a definição de quais tabelas e do relacionamento entre as tabelas. O resultado final desta fase será o que chamamos de Diagrama Entidade x Relacionamentos. O projeto completo de uma aplicação de n camadas que irá rodar na rede de uma empresa, envolve várias outras etapas. A descrição completa de todas as etapas foge ao escopo deste livro, sendo disciplina de Análise de Sistemas. Um bom livro sobre o assunto é o seguinte: “Analyzing Requirementes and Defining Solution Architectures MCSD Training Kit”, Microsoft Press, ISBN: 0735608547.
Etapas no projeto e estruturação de um Banco de Dados:
- Determinar qual o objetivo do Banco de Dados. Isto ajuda na determinação de quais os dados devem ser armazenados.
- Determinar as tabelas necessárias. Após definirmos o objetivo do Banco de Dados, as informações devem ser definidas e separadas em assuntos diferentes, tais como Clientes, Empregados, Pedidos, pois cada um irá compor uma tabela no Banco de Dados.
- Determinar os campos necessários em cada tabela. Definir quais informações devem ser mantidas em cada tabela. Por exemplo, a tabela Clientes poderia ter um campo para o Código do Cliente, outro para o Nome do Cliente e assim por diante.
- Determinar quais campos serão as Chaves Primárias. Determinar, em cada tabela, qual ou quais campos serão utilizados como Chave Primária. Esta é uma etapa importante para a definição dos relacionamentos que vem a seguir. Podem ocorrer caso onde uma tabela não tem chave primária.
- Determinar os relacionamentos entre as tabelas. Decidir como os dados de uma tabela se relacionam com os dados de outras tabelas. Por exemplo, Clientes podem fazer vários Pedidos. Fornecedores podem fornecer vários Produtos, etc.
- Refinar a estrutura do Banco de Dados. Antes de inserir muitos dados, ou até mesmo antes de inserir qualquer dado, verificar se a estrutura contém erros, isto é, verificar se os resultados obtidos são os desejados. Isto é feito através do processo de Normalização de tabelas, descrito anteriormente.
Com uma boa estrutura, gasta-se menos tempo na construção e manutenção do Banco de Dados e, ao mesmo tempo, assegura-se resultados mais rápidos e precisos.
Dicas para determinação dos campos em uma tabela:
- Relacionar diretamente cada campo ao assunto da tabela. Se um campo descreve o assunto de uma tabela diferente, este campo deve pertencer a outra tabela. O mesmo acontece quando uma informação se repete em diversas tabelas. Este é um indício de que existem campos desnecessários em algumas tabelas.
- Não incluir dados derivados ou calculados. Não é recomendado armazenar o resultado de cálculos nas tabelas. O correto é que o cálculo seja executado quando necessitarmos do resultado. Normalmente os cálculos são efetuados com o uso de consultas (Views – Capítulo 9) ou através de programação (usando Stored Procedures – Capítulo 10).
- Incluir todas as informações necessárias. Como é fácil esquecer informações importantes, deve-se ter em mente todas as informações coletadas desde o início do processo e perguntar se com elas é possível obter todas os resultados esperados.
- Armazenar todas as informações separadamente. Existe uma tendência em armazenar informações em um único campo. Por exemplo, o nome do curso e o tempo de duração em uma mesmo campo. Como as duas informações foram combinadas em um único campo, ficará difícil conseguir um relatório classificado pelo tempo de duração dos cursos, por exemplo.
|
Promoção: Livro Windows Server 2008 R2
Curso Completo, 1222 páginas. Tudo para você se tornar um administrador de redes altamente qualificado para o mercado de trabalho e levar a sua carreira para o próximo nível!
|
Como escolher o campo que será a Chave Primária?
Um bom Sistema Gerenciador de Banco de Dados Relacionais (SGBDR) é aquele que encontra e nos fornece, rapidamente, todas as informações necessárias que nele estejam armazenadas, mesmo em diferentes tabelas. Para que isto seja possível é necessário incluir um campo ou conjunto de campos que identifiquem de um modo único cada registro de uma tabela. Esta informação é chamada Chave Primária, conforme descrito anteriormente. Deve-se ter certeza que este campo (ou conjunto de campos) seja sempre diferente para cada registro, por não ser permitido valores duplicados em um campo de Chave Primária.
Ao escolher campos de Chave Primária, considere os seguintes detalhes:
- Não é permitido duplicidade de valores ou nulos (informações desconhecidas).
- Caso não exista um identificador único para uma determinada tabela, pode-se usar um campo que numere os registros seqüencialmente.
- Pode-se utilizar o valor deste campo para encontrar registros.
- O tamanho da Chave Primária afeta a velocidade das operações, portanto, para um melhor desempenho, devemos utilizar o menor tamanho que acomode os valores necessários para armazenar no campo.
Na Figura 1.14, temos um exemplo de um diagrama Entidade X Relacionamentos. Este diagrama mostra a estrutura do Banco de Dados Nwind.mdb, o qual é fornecido juntamente com o Microsoft Access 97 e também como exemplo na instalação do Microsoft SQL Server 2000. Os campos que são Chave Primária estão indicados em negrito.
Figura 1.14 Um diagrama Entidade X Relacionamentos.
|
