Neste item iremos revisar alguns conceitos básicos sobre bancos de dados relacionais. Estes conceitos são importantes para a correta utilização dos bancos de dados, bem como para o projeto e criação dos mesmos.

Em muitas situações teremos que conectar nossas aplicações Web e páginas ASP.NET  com bancos de dados já existentes, neste caso precisamos conhecer os conceitos aqui apresentados, para podermos utilizar o banco de dados de uma maneira otimizada.

Em outras situações teremos que criar o banco de dados a ser utilizado pela aplicação que está sendo desenvolvida. Neste caso os conceitos apresentados neste capítulo, auxiliam na criação de um banco de dados melhor estruturado e otimizado, tanto em termos de espaço de armazenamento, quanto da qualidade, confiabilidade e disponibilidade das informações nele contidas.

Veremos os seguintes conceitos:

• Entidades e Atributos, a base de um banco de dados
• Chave Primária
• Relacionamentos entre Entidades (Tabelas)
• Integridade Referencial
• Normalização de Tabelas
• Análise de um banco de dados relacional

Entidades e Atributos:

Toda a Informação de um banco de dados relacional  é armazenada em Tabelas, as quais também são chamadas de Entidades. Por exemplo, poderíamos ter uma Tabela "Clientes", onde seriam armazenadas informações sobre os diversos clientes, uma tabela Produtos, onde são armazenadas informações sobre os produtos e assim por diante.

Para cada um dos Clientes poderíamos armazenar informações tais como: Nome, Rua, Bairro, Telefone, CEP, Data de Nascimento, etc.

Essas diversas características de cada Cliente são os "Atributos" do Cliente, muitas vezes chamados de ”campos da entidade Cliente”, ou de maneira mais simples: “Os campos da tabela Clientes”.

"O Conjunto de todos os Atributos de um cliente e os valores dos atributos forma o Registro do Cliente". Com isso teremos a tabela constituída por um conjunto de Registros (uma linha completa com informações sobre o cliente ) e cada Registro formado por um conjunto de atributos (Nome, Endereço, etc.).

Resumindo:
Entidade ou Tabela: Um conjunto de registros sobre uma determinado assunto.
Campos ou Atributos: Características individuais de cada Entidade.

Considere o Exemplo da Figura 1.1, onde temos uma tabela Clientes com os seus diversos Campos (atributos):

Figura II.1 A entidade (tabela) Clientes e seus diversos atributos (campos).

No exemplo da Figura II.1, temos uma entidade: Clientes e seus diversos atributos:

• Código do Cliente
• Nome da Empresa
• Nome do Contato
• Cargo do Contato
• Endereço

Em cada linha temos um conjunto de atributos e seus valores. Cada linha forma um Registro que identifica um Cliente. Cada Coluna é um atributo da tabela Clientes.

Um dos grandes desafios em se projetar um banco de dados com sucesso é a correta determinação das entidades que existirão no banco de dados, bem como dos atributos de cada entidade. Mais adiante veremos algumas dicas e técnicas para determinar as tabelas necessárias, bem como os campos necessários em cada tabela.

É importante lembrar que o que determina quais as tabelas e campos necessários é o escopo do problema que está sendo abordado. Por exemplo, se estamos desenvolvendo um sistema para acompanhamento do desempenho individual de cada funcionário, com certeza não teremos necessidade de uma tabela de Clientes. Por outro lado, se o desempenho de cada funcionário a ser acompanhado estiver ligado ao número de clientes atendidos pelo funcionário ou ao volume de vendas, a tabela Clientes passa a ter importância para o problema em questão.

Com isso podemos dizer que o que determina as tabelas e campos necessários é o problema real que o sistema a ser desenvolvido deverá solucionar.

Outro fato importante e que iremos repetir ao longo deste ANEXO, é que cada tabela deve conter dados de SOMENTE um determinado assunto. Não devemos “misturar” dados de diversos assuntos em uma mesma tabela. Observe o exemplo da tabela indicada na Figura II.2:

Figura II.2 Uma tabela problemática, na qual estamos “misturando” assuntos.

Observe que, nesta tabela, cometemos o erro de “misturar” dois assuntos:

• Dados sobre os “Clientes”
• Dados sobre os “Pedidos dos Clientes”

Quando este tipo de situação acontece, temos uma série de problemas que irão se refletir em todo o sistema que está sendo desenvolvido. Dentre os principais problemas podemos citar:

• Informação repetida: Observe que para cada pedido de um determinado cliente, precisamos informar novamente os campos: Nome, Endereço e Fone.
• Informação inconsistente: Observe que por um erro de digitação, o nome do cliente José da Silva está digitado incorretamente (sem o acento) no segundo registro, e o seu endereço está digitado incorretamente, no terceiro registro. Isso causa inconsistências no banco de dados, gerando resultados errados quando forem feitas pesquisas pelo nome do cliente ou pelo endereço.

Para evitar este tipo de problema, deveríamos separar as informações dos Clientes e dos seus Pedidos em duas tabelas distintas. Veremos como fazer isso mais adiante neste Anexo.

O conceito de Chave Primária:

O Conceito de Chave Primária é fundamental para entender o funcionamento de um banco de dados relacional. Vamos Procurar entender o que significa um campo ser a chave Primária de uma tabela.

Ao Definirmos um campo como sendo uma Chave Primária, estamos informando ao banco de dados que não podem existir dois registros com o mesmo valor no campo Chave Primária, ou seja, os valores no campo Chave Primária precisam ser únicos.

Por exemplo, se defino um campo “Número da Identidade” da tabela Clientes como sendo uma Chave Primária, estou dizendo ao banco de dados que não podem existir dois clientes com o mesmo valor no campo “Número da Identidade. Na prática estou garantindo que não podem ser cadastrados dois clientes com o mesmo Número de Identidade.

Em outras palavras poderíamos dizer que o Campo Chave Primária identifica de maneira única cada registro da tabela, isto é, de posse do valor da Chave Primária somente localizaremos um registro com aquele valor no campo Chave Primária.

Este é um conceito muito importante, pois conforme veremos mais adiante os conceitos de Integridade Referencial e Normalização estão diretamente ligados ao conceito de Chave Primária.

Alguns exemplos de campos que podem ser definidos como  “Chave Primária” em suas respectivas tabelas:

• O campo Número do Pedido, em um tabela de Pedidos.
• O campo Número da Identidade ou CPF em uma tabela de Clientes Pessoa Física.
• O campo Número do CNPJ em uma tabela de Clientes Pessoa Jurídica.
• O campo Código do Produto em uma tabela de Produtos.
• O campo ISBN em uma tabela de Livros.
• O campo Código do Autor em uma tabela de autores.

Na Figura I.3 vemos um exemplo da tabela Cliente onde o campo Código do Cliente é definido como uma Chave Primária. Observe que não existem dois clientes com o mesmo código.

Figura II.3 O campo Código do Cliente é uma Chave Primária.

Um detalhe importante é que a Chave Primária pode ser formada pela combinação de Mais do que um campo. Podem existir casos em que um único campo não é capaz de atuar como chave primária, pelo fato deste campo apresentar valores repetidos. Nestes casos podemos definir uma combinação de dois ou mais campos para ser a nossa chave primária. Além disso, uma tabela somente pode ter uma Chave Primária, seja ela simples ou composta.

Um cuidado especial que devemos ter é quanto ao desempenho das consultas em tabelas que possuem Chave Primária composta por mais do que um campo. Em muitas situações, o desempenho das consultas é inversamente proporcional ao tamanho da chave primária. Com isso quanto maior o tamanho da chave primária, menor o desempenho das consultas, isto é, mais demoradas se tornam as consultas. Na prática dificilmente teremos uma chave primária composta por mais do que 3 campos. Se você se deparar com uma situação em que precise uma chave primária composta de quatro ou mais campos, revise o projeto do banco de dados, por que devem existir alguns problemas.

Relacionamentos entre Tabelas:

Na prática, em um banco de dados relacional, podem existir diversas tabelas, como por exemplo:

• Clientes
• Produtos
• Pedidos
• Detalhes do Pedido
• Fornecedores
• Categorias
• Funcionários, etc.

Embora as informações estejam separadas em cada uma das Tabelas, devemos ter algum mecanismo que nos permita reunir dados de duas ou mais tabelas em um relatório ou consulta. Por exemplo, para fazer um relatório do total de vendas por funcionário, precisarei informações das seguintes tabelas:

• Funcionários
• Pedidos
• Detalhes do pedido

O mecanismo que nos permite acessar de maneira consolidada, dados de diversas tabelas é chamado de “Relacionamento entre tabelas”.

Por exemplo: Um Pedido é feito por um Cliente e neste Pedido podem existir diversos Itens, os quais são armazenados na tabela Detalhes do Pedido. Além disso cada Pedido possui um número único, mas um mesmo Cliente pode fazer diversos pedidos.

Veja que o parágrafo acima descreve relações do mundo real. Estas relações do mundo real são o nosso guia, para definir as relações entre as diversas tabelas do banco de dados.

Em um  Banco de dados precisamos de um mecanismo para representar estes relacionamentos da vida Real, em termos das tabelas e seus atributos. Isto é possível com a utilização dos Relacionamentos , os quais podem ser de três tipos:

• Um para Um
• Um para Vários
• Vários para Vários

Relacionamento do tipo Um para Um.

Esta relação existe quando os campos que se relacionam são ambos Chaves Primárias em suas respectivas tabelas. Cada um dos campos não apresenta valores repetidos. Na prática existem poucas situações onde utilizaremos um relacionamento deste tipo.

Vamos imaginar o seguinte exemplo: Imagine uma escola com um cadastro de Alunos na tabela Alunos, destes apenas uma pequena parte participa da Banda da Escola. Por questões de projeto do Banco de dados, podemos optar por criar uma segunda tabela "Alunos da Banda",  a qual pode se relacionar com a tabela Alunos através de um relacionamento Um para Um. Cada aluno somente é cadastrada uma vez na tabela Alunos e uma única vez na tabela Alunos da Banda. Poderíamos utilizar o campo “Matrícula do Aluno” como o Campo que relaciona as duas tabelas.

Na tabela Alunos da Banda poderíamos colocar apenas o Número da Matrícula do aluno, além das informações a respeito do Instrumento que ele toca, tempo em que está na banda, etc. Quando fosse necessário buscar as informações tais como nome, endereço, etc., as mesmas podem ser recuperadas através do relacionamento existente entre as duas tabelas, evitando, com isso, que a mesma informação (Nome, Endereço, etc) tenha que ser duplicada nas duas tabelas, o que diminui a probabilidade de erros de digitação.

Na Figura  II.4 vemos o exemplo de um relacionamento do tipo Um para Um entre as tabelas “Alunos” e “Alunos da Banda.”

Figura II.4 Um relacionamento do tipo Um para Um.

Relacionamento do tipo Um para Vários:

Este, com certeza, é o tipo de relacionamento mais comum entre duas tabelas. Uma das tabelas (o lado um do relacionamento) possui um campo que é a Chave Primária e a outra tabela (o lado vários) se relaciona através de um campo cujos valores podem se repetir – este campo é conhecido como Chave Estrangeira.

Considere o exemplo entre a tabela Clientes e a tabela Pedidos. Cada Cliente somente é cadastrado uma única vez (por isso o campo “Código do Cliente” é uma chave primária, indicando que não podem existir dois clientes com o mesmo código), portanto a tabela Clientes será o lado um do relacionamento. Porém cada cliente pode fazer diversos pedidos, por isso que o campo “Código do Cliente” poderá aparecer várias vezes na tabela Pedidos, tantas vezes quantos forem os pedidos que o Cliente tenha feito. Por isso que temos um relacionamento do tipo Um para Vários entre a tabela Clientes e Pedidos, através do campo “Código do Cliente”, indicando que um mesmo Cliente pode fazer diversos pedidos.

Na Figura II.5 vemos um exemplo de um relacionamento Um para Vários entre as Tabelas Clientes e Pedidos, através do campo código do cliente.

Figura II.5 Um relacionamento do tipo Um para Vários.

No lado “Um” do relacionamento o campo é definido como uma Chave Primária (campo CódigoDoCliente na tabela Clientes) e no lado “Vários” não (campo CódigoDoCliente na tabela Pedidos), indicando que no lado vários o Código do Cliente pode se repetir , o que faz sentido, uma vez que um mesmo cliente pode fazer diversos pedidos.

Podemos citar outro exemplo clássico de relacionamentos do tipo Um para Vários:

Entre as tabelas Pedidos e Detalhes do Pedido, através do campo NúmeroDoPedido. Na tabela Pedidos o campo NúmeroDoPedido é chave primária. Na tabela Detalhes do Pedido, o campo NúmeroDoPedido não é chave primária. Na tabela Detalhes do Pedido temos as informações sobre os itens de cada pedido. Este relacionamento indica que “um” mesmo “pedido” pode ter “diversos” “itens”, o que faz sentido.

Na Figura II.6 vemos um exemplo de um relacionamento Um para Vários entre as Tabelas Pedidos e Detalhes do Pedido, através do campo NúmeroDoPedido.

Figura II.6 Mais um exemplo de relacionamento do tipo Um para Vários.

Relacionamento do tipo Vários para Vários:

Este tipo de relacionamento ocorre em uma situação onde, nos dois lados do relacionamento, os valores podem se repetir. Vamos considerar o caso entre as tabelas Produtos e a tabela Pedidos. Posso ter vários Pedidos nos quais aparece um determinado produto, além disso vários Produtos podem aparecer no mesmo Pedido. Esta é uma situação em que temos um relacionamento do tipo Vários para Vários: Vários produtos podem aparecer em Vários pedidos e Vários pedidos podem conter Vários produtos.

Na prática não temos como implementar um relacionamento deste tipo, devido a uma série de problemas que este tipo de relacionamento implicaria.

Para evitar este problema é bastante comum “quebrarmos” um relacionamento do tipo Vários para Vários em dois relacionamento do tipo Um para Vários. Isso é feito através da criação de uma nova tabela, a qual fica com o lado Vários dos relacionamentos. No nosso exemplo poderíamos criar a tabela Detalhes do Pedido, onde ficam armazenadas as informações sobre os diversos itens de cada pedido. Desta forma,  ao invés de termos um relacionamento do tipo Vários para Vários, teremos dois relacionamentos do tipo um para vários, conforme indicado na Figura II.7.

Figura II.7 “Quebrando” um relacionamento Vários para Vários.

Esta situação em que um relacionamento Vários para Vários é "quebrado" em dois relacionamentos do tipo Um para Vários é bastante comum. Diversas vezes utilizamos esta técnica para eliminar problemas no Banco de Dados, tais como informação repetida e inconsistência de Dados.

Agora que já conhecemos os tipos de relacionamentos existentes, no próximo item veremos o conceito de  “Integridade Referencial.” O mecanismo da Integridade Referencial é utilizado para garantir a Consistência dos dados.

Integridade Referencial:

A Integridade Referencial é utilizada para garantir a Integridade dos dados entre as diversas tabelas relacionadas, evitando inconsistências nos dados, bem como repetições desnecessárias.

Por exemplo, existe um relacionamento do tipo Um para Vários entre a tabela Clientes e a tabela Pedidos (um cliente pode fazer vários pedidos). Com a Integridade Referencial, o banco de dados não permite que seja cadastrado um Pedido para um Cliente que ainda não foi Cadastrado na tabela  Clientes. Através da Integridade Referencial, também podemos garantir o seguinte:

• Quando o Código de um cliente for alterado na tabela Clientes, o banco de dados atualiza, automaticamente, todos os Códigos do Cliente na tabela Pedidos, de tal maneira que não fiquem registros Órfãos, isto  é , registros de Pedidos com um Código de Cliente que não existe mais na tabela Clientes. Essa ação é conhecida como "Propagar atualização dos campos relacionados" ou “Propagar atualizações em cascata”.
• Quando um cliente for excluído da tabela Clientes, podemos fazer com que o Banco de dados exclua, na tabela Pedidos, todos os Pedidos para o cliente que está sendo excluído. Essa opção é conhecida como "Propagar exclusão dos registros relacionados" ou “Propagar exclusões em cascata”, e pode ser habilitada ou não, dependendo do projeto do Banco de dados. Caso seja necessário manter todo o histórico de compras do cliente, por exemplo, esta opção não deve ser habilitada. Com isso, quando o cliente for eliminado da tabela Clientes, os seus pedidos continuarão gravados na tabela Pedidos.

Essas opções, são definidas no momento da criação do Banco de dados, quando são criadas as tabelas e definidos os relacionamentos entre as tabelas.

A Opção de Propagar atualização dos campos relacionados é utilizada na maioria das situações, já a opção de Propagar exclusão dos registros relacionados  deve ser estudada caso a caso.

Normalização de Tabelas:

O objetivo da normalização é evitar os problemas provocados por falhas no Projeto do banco de dados, bem como eliminar a “mistura” de assuntos e as correspondentes redundâncias de dados.

Uma “Regra de Ouro” que devemos observar quando do projeto de banco 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ências.

O Processo de Normalização aplica uma série de regras sobre as entidades de um Banco de Dados, para verificar se estas estão corretamente projetadas. Embora existam 5 formas normais (ou regras de Normalização ), na prática usamos um conjunto de três Formas Normais.

Normalmente, após a aplicação das regras de Normalização, algumas tabelas acabam sendo divididas em duas ou mais tabelas, o que no final acaba gerando 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, reduzindo-se consideravelmente as necessidades de manutenção.

Vamos estudar e entender o Processo de Normalização na Prática, através de exemplos.

Primeira Forma Normal:

Regra: "Uma tabela está na Primeira Forma Normal quando seus atributos não contém Grupos de Repetição."

Por isso dissemos que uma Tabela que possui Grupos de Repetição não está na Primeira Forma Normal. Considere a Tabela Indicada na Figura II.8:

Figura II.8 Uma tabela que não está na Primeira Forma Normal.

Podemos notar que uma tabela com esta estrutura apresenta diversos problemas. Por exemplo, se um casal tiver mais do que um filho, teríamos que digitar o Nome do Pai e da Mãe diversas vezes, tantas quantos forem os filhos. Isso forma um “Grupo de Repetição”.  Além do mais pode ser que por erro de digitação o nome dos pais não seja digitado exatamente igual todas as vezes, o que pode acarretar problemas na hora de fazer pesquisas ou emitir relatórios. Este problema ocorre porque "Misturamos Assuntos" em uma mesma tabela. Colocamos as informações dos Pais e dos Filhos em uma mesma tabela.

A Resolução para este problema é simples:

 “Criamos uma tabela separada para a Informação dos Pais e relacionamos a tabela Pais com a tabela Filhos através de um relacionamento do tipo Um para Vários, ou seja, Um casal pode ter Vários filhos.

Esta solução é indicada na Figura II.9.
 

Figura II.9 As tabelas Pais e Filhos estão na primeira forma normal.

As duas tabelas Resultantes da aplicação da primeira forma normal: Pais e Filhos, estão na primeira forma normal, a tabela original, a qual misturava informações de Pais e Filhos, não estava na primeira forma normal.

Segunda Forma Normal:

Podemos aplicar a segunda forma normal quando tivermos uma chave primária composta por mais de um campo, isto é, uma chave primária composta. Neste caso, devemos observar se todos os campos que não fazem parte da chave dependem de todos os campos que compõem a chave primária. Se algum campo depender somente de parte da chave composta, então este campo deve pertencer a outra tabela.

Observe o Exemplo Indicado na Tabela da Figura II.10.

Figura II.10 Uma tabela que não está na Segunda Forma Normal.

A chave primária composta é formada pela combinação dos campos NúmeroDaMatrícula e CódigoDoCurso. O campo Avaliação depende tanto do CódigoDoCurso quanto do NúmeroDaMatrícula, porém o campo DescriçãoDoCurso, depende apenas do CódigoDoCurso. Com isso temos um campo que não faz parte da chave primária e depende apenas de um dos campos que compõem a chave primária. Com isso dizemos que esta tabela não está na segunda forma normal.

A resolução para este problema também é simples: Dividimos a tabela, que não está na segunda forma normal, em duas outras tabelas, conforme indicado pela Figura II.11, sendo que as duas tabelas resultantes estão na segunda forma normal.

Figura II.11 Duas tabelas que estão na Segunda Forma Normal.

Nota:  A Distinção entre a Segunda e a Terceira forma normal,  que veremos no próximo item, muitas vezes é confusa. A Segunda Forma normal está ligada a ocorrência de chaves primárias compostas.

Terceira Forma Normal:

Na definição dos campos de uma entidade podem ocorrer casos em que um campo não seja dependente diretamente da chave primária,  ou de parte dela, mas sim dependente de um outro atributo constante na tabela, atributo este que não a chave primária.

Quando isto ocorre, dizemos que a tabela não está na terceira forma normal, conforme indicado pela tabela da Figura II.12.

Figura II.12 Uma tabela que não está na terceira forma normal.

Observe que o campo DescriçãoDoCurso depende apenas do campo CódigoDoCurso, o qual não faz parte da chave primária. Por isso dizemos que esta tabela não está na terceira forma normal.

A solução para este caso também é simples. Novamente basta dividir a tabela em duas outras, conforme indicado pela Figura II.13. As duas tabelas resultantes estão na terceira forma normal.

Figura II.13 Duas tabelas que estão na terceira forma normal.

IMPORTANTE! Com isso podemos concluir que como resultado do processo de Normalização, iremos obter um número maior de tabelas, porém sem problemas de redundância e inconsistência dos dados, ou com estes problemas minimizados.

Passos para projetar um Banco de dados.

Neste item iremos apresentar os passos básicos para  projetar um banco de dados. Aplicaremos 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. Com uma boa estrutura, gasta-se menos tempo na construção de um banco de dados e , ao mesmo tempo, assegura-se resultados mais rápidos e precisos.

OBS.: Neste item estamos falando do projeto físico do banco de dados, isto é, a definição de quais tabelas e do relacionamento entre as mesmas. 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 anexo, 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 NA 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.
• Determinar os relacionamentos. 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, normalmente, pode ser obtido através do processo de Normalização.

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.
• 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.

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 II.14 temos um exemplo de um Diagrama Entidade x Relacionamentos. Este diagrama mostra a estrutura do banco de dados NorthWind.mdb, o qual é fornecido juntamente com o Microsoft Access 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 II.14 Um diagrama Entidade x Relacionamentos.