Júlio Battisti Livros e Cursosa sua sala de aula na internet

Neste tópico iremos revisar alguns conceitos básicos sobre Bancos de Dados. Para a melhor utilização do Microsoft Office Access 2007 é importante o conhecimento e correto entendimento dos conceitos apresentados. Revisaremos os Seguintes Conceitos:

• Entidades e Atributos;
• Chave Primária;
• Relacionamentos entre Entidades (Tabelas);
• Integridade Referencial;
• Normalização de Tabelas;
• Um Problema Proposto.

1.1 - Entidades e Atributos:

Toda a Informação de um Banco de Dados do Microsoft Office Access 2007 é armazenada em Tabelas, que na linguagem do Banco de Dados, também são chamadas de Entidades. Por exemplo, poderíamos ter uma Tabela "Clientes", onde seriam armazenadas informações sobre os diversos clientes.

Sobre 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" de cada Cliente, muitas vezes chamados de campos da entidade Cliente. O Conjunto de todos os Atributos de um cliente e os valores dos mesmos 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;
Campos ou Atributos -> Características Individuais da Entidade.
Considere o Exemplo da figura a seguir, onde temos uma Tabela Cliente com os seus diversos Campos ( atributos):

Figura 02 - Tabela Cliente e Seus Campos - Código do Cliente, Nome da Empresa, etc.

No exemplo da figura anterior temos uma entidade: "Clientes" e seus diversos atributos: "Código do Cliente", "Nome da Empresa", "Nome do Contato", "Cargo do Contato", "Endereço", etc. Em cada linha temos um conjunto de atributos e seus valores. Cada linha forma um Registro. Cada Coluna é um atributo da Tabela Clientes.

Conforme veremos em um dos exercícios mais adiante, 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.

Exercício: Neste exercício iremos abrir o Banco de Dados C:\Curso\curso_av.mdb e analisar as suas entidades e os atributos de cada entidade.

  Para Analisar as Entidades e os Atributos das Entidades do banco curso_av.mdb faça:

• Abra o Microsoft Office Access 2007: Iniciar -> Programas -> Microsoft Office -> Microsoft Access 2007;
• Na tela que surge dê um clique em "Mais". Surgirá a caixa de diálogo Abrir;
• No campo "Examinar" escolha unidade (C:);
• Nas pastas que surgem dê um duplo clique para abrir a pasta Curso;
• Dentro de Curso dê um duplo clique no arquivo curso_av.mdb para abrí-lo;
• Obeserve ao seu lado esquerdo é mostrado um menu com todas as tabelas do seu banco.Dê um duplo clique na tabela Clientes para abri-lá. Quais os atributos da Tabela Cliente?
• Dê um clique no "x" para fechar a Tabela Clientes;
• Dê um clique duplo em "Pedidos" para abrir a Tabela Pedidos;
• Observe os diferentes Atributos da Tabela Pedidos.

1.2 - Chave Primária:

O Conceito de "Chave Primária" é fundamental para o Correto Entendimento do Funcionamento de um Banco de Dados. Vamos Procurar entender o que significa um Campo Ser a chave Primária de uma Tabela e como tornar um Campo a Chave Primária de uma Tabela.

"Quando um Campo é definido como uma Chave Primária, estamos informando ao Microsoft Office Access 2007 que não podem existir dois registros com o mesmo valor de Chave Primária, ou seja, os valores no campo Chave Primária precisam ser únicos. Por exemplo, se o campo "Número da Identidade" da tabela Clientes é definido como sendo uma Chave Primária, estou dizendo ao Microsoft Office Access 2007 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 de uma Tabela, isto é, de posse do valor da Chave Primária somente localizaremos um registro com aquele valor no campo Chave Primária.

É um  identificador exclusivo para cada linha. Em um banco de dados relacional, como o Microsoft Office Access 2007, você divide seus dados em tabelas baseadas em tópicos. Na sequência, você utiliza relacionamentos de tabelas e chaves primárias para dizer ao Access como reunir novamente esses dados. O Microsoft Office Access 2007  utiliza campos de chave primária para integrar rapidamente os dados de várias tabelas e combinar esses dados de uma forma que faça sentido.
Na próxima figura será mostrado 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 03 - Campo "Código do Cliente" definido como Chave Primária.

  Ao clicarmos no Botão Modo de Exibição você escolhe a maneira de visualizar a estrutura da Tabela.

Figura 04 - Modo de Exibição da tabela.

Dos modos de exibição acima os mais utilizados são: Modo Design e Modo Folha de Dados. No Modo Design é onde definimos quais atributos farão parte da tabela, bem como as características de cada atributo, tais como Tipo de Dados, Tamanho Máximo, Máscara de Entrada, etc. No Modo Folha de Dados é que podemos digitar as informações, Inserir Novos Registros, alterar os Registros existentes, etc.

Ao entrar no Modo Design, conforme indicado pela figura a seguir, observe que na linha do Atributo "Código do Cliente", existe uma chave. Esta chave indica que o Campo é Marcado como uma "Chave Primária". Além disso, na propriedade "Indexado" deste campo você pode Notar que aparece "Sim (Duplicação Não Autorizada)", indicando que não podem haver valores duplicados para um campo do tipo Chave Primária.

Figura 05 - Campo Chave Primário Indexado e Com Duplicação Não Autorizada.

Exercício: Neste exercício iremos Redefinir o campo Código do Cliente para que ele deixe de ser uma Chave Primária, feito isso iremos para o Modo Folha de Dados e Adicionaremos um Cliente com o Código de Cliente Duplicado ( Igual a um que já existe na Tabela), depois retornaremos ao Modo Design e tentaremos redefinir o campo Código do Cliente como Chave Primária.

Para Modificar o Campo Código do Cliente faça o seguinte:

• Se ainda não estiver no Modo Design da Tabela Clientes, vá para o Modo Design. Para isso faça: Dê um clique em Clientes para marcar a Tabela e depois um clique no botão Design;
• Selecione a Linha "CódigoDoCliente". Para selecionar coloque o mouse bem a esquerda da linha, até que o cursor se transforme em uma flecha apontando para a direita, aí de um clique e toda a linha será selecionada;
• Com a linha selecionada dê um clique no botão com o desenho da chave  que encontra-se na aba design, feito isso o campo deixará de ser uma chave primária, conforme pode ser notado pelo fato da chave ter sumida da linha Código do Cliente;
• Vá para o Modo Folha de Dados, através do Botão Modo de Exibição.
• No Modo Folha de Dados vá para o final da Tabela e insira um Cliente com os seguintes Dados:                                                                       

• Observe que mesmo inserindo um cliente com o mesmo Código de Outro Cliente (ADAMN) o Microsoft Office Access 2007 permitiu a inserção de Dados. Agora temos dois clientes com o mesmo Código do Cliente, o que na prática causa uma série de Problemas ao Banco de Dados;
• Marque a linha do registro que você acabou de inserir e tecle DEL, isso irá eliminar o registro recém digitado;
• Volte para o Modo Design e marque a linha Código do Cliente. Feito isso dê um clique no botão com a Chave, para redefinir este campo como sendo uma Chave Primária.  Observe que automaticamente o Microsoft Office Access 2007 passou a Propriedade Indexado para "Sim (Duplicação Não Autorizada)";
• Dê um clique no botão com o Diskete  para salvar a tabela. Volte para o modo Folha de Dados e tente inserir um Registro com os dados indicados acima ( Código ADAMN, Nome da Empresa ABC de 123, etc);
• O Microsoft Office Access 2007 permitiu que você inserisse esse registro ? Por que ?

Um último detalhe importante para lembrarmos é que a Chave Primária pode ser formada pela combinação de Mais de Um Campo. Podem existir casos em que um único campo não é capaz de atuar como chave primária, pelo fato do mesmo apresentar valores repetidos. Nestes casos podemos definir uma combinação de 2 ou mais campos para ser a nossa chave primária. Para fazer isso coloque a tabela no Modo Design, selecionar todas as linhas que definirão a "Chave Primária Composta", e depois dê um clique no botão com a chave.

Além disso, uma tabela somente pode ter uma Chave Primária, seja ela simples ou composta.

Neste item aprendemos o conceito de Chave Primária, a sua Importância e como Definir um Campo de uma Tabela como sendo a Chave Primária. Também testamos inconsistências que podem ser introduzidas nos dados pelo fato de não termos uma Chave Primária definida corretamente ( No nosso exemplo, conseguimos inserir um Cliente com o Mesmo Código de outro cliente já cadastrado).

No próximo ítem aprenderemos outro importante conceito: Conceito de Relacionamentos entre Tabelas.

1.3 - Relacionamentos entre Tabelas:

Conforme podemos ver no nosso Banco de Dados curso_av.mdb, existem diversas tabelas: Clientes, Produtos, Pedidos, Detalhes do Pedido, etc. Embora as informações estejam separadas em cada uma das Tabelas, na prática devem existir um relacionamento entre as mesmas. Por exemplo: Um Pedido é feito Para 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.

No Banco de Dados, precisamos de alguma maneira para representar estes relacionamentos da vida Real, em termos das tabelas e seus atributos. Isto é possível com a utilização de "Relacionamentos entre tabelas", os quais podem ser de três tipos: Um para Um, Um para Vários e Vários para Vários.

1.3.1 - 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 apresentam valores repetidos. Na prática existem poucas situações onde utilizaremos um relacionamento deste tipo.

Um exemplo poderia ser o seguinte: 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 estrutura 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 é cadastrado 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 de 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, inclusive aumentando a probabilidade de erros de digitação.

Observe na figura à seguir um exemplo de um Relacionamento do tipo “Um para Um” entre as tabelas Alunos e Alunos da Banda.

Figura 06 - Relacionamento Um para Um entre as Tabelas Alunos e Alunos da Banda.

1.3.2 - 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 relacionados podem se repetir várias vezes.

Considere o exemplo entre a tabela Clientes e Pedidos. Cada Cliente somente é cadastrada 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 Código de um Cliente poderá aparecer várias vezes na tabela Pedidos, tantas vezes quantos forem os pedidos que o Cliente tiver feito. Por isso que temos um relacionamento do tipo “Um para Vários” entre a tabela Clientes e Pedidos, através do campo CódigoDoCliente, indicando que um mesmo Cliente pode realizar diversos pedidos.

Observe na figura a seguir temos um exemplo de Relacionamento “Um para Vários” entre as Tabelas Clientes e Pedidos do banco de dados curso_av, através do campo códigoDocliente:

Figura 07 - Relacionamento Um para Vários entre as Tabelas Clientes e Pedidos.

Observe que o lado Vários do relacionamento é representado pelo símbolo do infinito ( ¥ ).

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

No nosso Banco de Dados curso_av.mdb, temos diversos outros exemplos de relacionamentos do tipo Um para Vários, conforme descrito na Próxima Tabela:

Mais adiante veremos como implementar, na prática, estes relacionamentos. Algumas observações importantes sobre relacionamentos:

• O Nome dos Campos envolvidos no Relacionamento, não precisa ser, necessariamente, o mesmo, conforme indicado pelo relacionamento entre os campos CódigoDaTransportadora e Via, na tabela anterior;
• Sempre o Lado um do Relacionamento deve ser uma chave primária, já o lado vários não pode ser uma chave Primária;
• De Preferência, antes de Criar os Relacionamentos verifique se o tipo dos campos a serem relacionados é o mesmo, além de características como máscaras de entrada e formato.

1.3.3 - Relacionamento do tipo Vários para Vários:

Seria uma situação onde em ambos os lados do relacionamento os valores poderiam se repetir. Vamos considerar o caso entre Produtos e Pedidos. Posso ter Vários Pedidos nos quais aparecem 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.

Na prática não temos como implementar um relacionamento deste tipo, devido a uma série de problemas que teríamos. Por exemplo, na tabela Pedidos teríamos que repetir o Número do Pedido, Nome do Cliente, Nome do Funcionário, Data do Pedido, etc para cada item do Pedido.

Para evitar este tipo de problema é bastante comum quebrarmos um relacionamento do tipo Vários para Vários em dois relacionamentos 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 do relacionamento. No nosso exemplo foi criada a tabela Detalhes do Pedido, onde ficam armazenadas as informações sobre os diversos itens de cada pedido, aí ao invés de termos um relacionamento do tipo Vários para Vários, teremos dois relacionamentos do tipo um para vários, conforme descrito pela próxima tabela:

Na figura abaixo temos a representação dos dois relacionamentos Um para Vários:

Figura 08 - Tabela Detalhes do Pedido ficou com o lado Vários dos Relacionamentos.

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 uma série de 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 como Implementar relacionamentos no Microsoft Office Access 2007e a utilização da Integridade Referencial como uma maneira de Garantir a Consistência dos Dados.

1.4 - Integridade Referencial:

A Integridade Referencial é Utilizada para garantir a Integridade dos dados entre as Tabelas Relacionadas. 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 Microsoft Office Access 2007não permite que seja cadastrado um Pedido para um Cliente ainda não Cadastrado. Também podemos garantir o seguinte:

• Quando o Código de um cliente for alterado na Tabela Clientes, podemos pedir para o Microsoft Office Access 2007 que ele atualize, 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".
• Quando um Cliente for excluído da Tabela Clientes, podemos pedir para que o Microsoft Office Access 2007 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".

Essas opções, conforme veremos logo em seguida, podem ser configuradas quando da Definição dos Relacionamentos. Ambas as opções não são obrigatórios. 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. Por exemplo, se nos quiséssemos manter um histórico com os Pedidos de cada Cliente, não utilizaríamos a opção "Propagar exclusão dos registros relacionados"; caso não nos interessasse manter um histórico dos pedidos, poderíamos utilizar esta opção.

1.5 - Definindo Relacionamentos no Microsoft Access 2007:

Para Definir Relacionamentos no Microsoft Office Access 2007 faça o Seguinte:

• Com as tabelas criadas. Dê um clique na aba Ferramentas de Banco de Dados -> Relações - > Mostrar Tabelas.

Figura 09 - Guia Ferramentas de Banco de Dados - Relações.

• Ao clicar em relações a surgirá a opção Mostrar Tabela. Veja  a seguir:

Figura 10 - Mostrar Tabela.

•  Dê um clique sobre a opção Mostrar Tabela surgirá à caixa de diálogo com todas as tabelas existentes no seu banco de dados, no qual você adicionará as tabelas que farão parte de algum dos relacionamentos. Para Adicionar uma Tabela, basta marcá-la e dar um clique no botão "Adicionar". Você pode adicionar todas as tabelas de uma única vez. Para isto dê um clique na primeira, libere o mouse, tecle SHIFT e fique segurando SHIFT pressionado e dê um clique na última tabela. Com isso todas serão selecionadas, agora ao dar um clique no botão Adicionar, todas as tabelas serão adicionadas. Caso não queira adicionar todas, mas somente algumas e de uma maneira intercalada, ao invés de usar a tecla SHIFT, utilize a tecla CTRL. Com a tecla CTRL uma tabela é selecionada à medida que você vai clicando com o mouse sobre o nome da tabela.

Figura 11 - Dê um clique para selecionar a Tabela e depois clique no botão Adicionar.

• Após ter adicionado as tabelas, vamos criar um relacionamento, basta arrastar um campo de uma tabela sobre o campo da outra tabela na qual será estabelecido o relacionamento. Por exemplo, para estabelecer o relacionamento Um para Vários entre as tabelas Clientes e Pedidos, arraste o campo "CódigoDoCliente" da tabela Clientes, sobre o campo "CódigoDoCliente" da Tabela Pedidos. Ao largar um campo sobre o outro, o Microsoft Office Access 2007abre a caixa de diálogo “Editar Relações” conforme indicado na figura a seguir:

Figura 12 - Definindo as Características do Relacionamento.

• Observe que, por padrão, o campo "Impor Integridade Referencial" não está marcado. Ao marcá-lo serão disponibilizadas as Opções de "Propagar atualização dos campos relacionados" e "Propagar exclusão dos registros relacionados". Observe, também, que o Microsoft Office Access 2007já definiu este relacionamento como sendo do tipo Um para Vários. Isso acontece porque o Microsoft Office Access 2007identifica o campo Código do Cliente na tabela Clientes como sendo uma chave primária, o que automaticamente transforma o Relacionamento como sendo do tipo Um para Vários. Se em ambas as tabelas o campo Código do Cliente fosse definido como Chave Primária, o relacionamento, automaticamente, seria do tipo Um para Um.
• Após marcar as opções desejadas, basta dar um clique no botão "Criar" e pronto, o Microsoft Office Access 2007cria o Relacionamento, o qual é indicado através de uma linha entre as duas tabelas ( Clientes e Pedidos ), com o número 1 no lado da Chave Primária e o Sinal de infinito no lado Vários. Caso você precise alterar as características de um determinado relacionamento, basta dar um duplo clique sobre a linha do relacionamento, que o  Microsoft Office Access 2007abrirá a janela indicada na figura 11, para que você possa fazer as alterações desejadas.
• Este diagrama que exibe as Tabelas e os Relacionamentos entre as mesmas é conhecido como "Diagrama Entidades x Relacionamentos", lembrando que entidades é apenas um outro nome para as nossas tabelas.
• Antes de fechar o Diagrama Entidades x Relacionamentos, dê um clique no botão salvar  ou pressione CTRL + B para salvar as alterações que foram feitas. A qualquer momento você pode acessar o Diagrama Entidades x Relacionamentos para fazer alterações ou para revisar os relacionamentos, para isto basta clicar na aba Ferramentas de Banco de Dados -> Relações.

Exercício: Agora vamos a um exercício prático, onde será definido os diversos relacionamentos para o nosso banco de dados curso_av.mdb.

Para definir os Relacionamentos para o banco de dados curso_av.mdb:

• Abra o banco de dados curso_av.mdb
• Clique na aba Ferramentas de Banco de Dados -> Relações > Mostrar Tabela;
• Adicione todas as tabelas, conforme explicado anteriormente;
• Defina os Relacionamentos conforme indicado na tabela abaixo.

• Habilite a Integridade Referencial  em todos os Relacionamentos, habilite a opção "Propagar atualização dos campos relacionados" e deixe desabilitada o opção de "Propagar exclusão dos registros relacionados".
• Salve as alterações e feche a Janela dos Relações, clicando no "x" da mesma. Clique no "x" mais de baixo, pois o "x" mais acima irá fechar todo o Microsoft Access 2007.
• Abra a Tabela Pedidos e tente adicionar um pedido para o Cliente com Código do Cliente igual a ABCDE. O Microsoft Office Access 2007Permitiu que você inserisse o Pedido para esse Cliente ?  Por Que ?

1.6 - Normalização de Tabelas:

O conceito de Normalização foi introduzido por Codd em um artigo sobre o Modelo Relacional em 1970.

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 em um 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ência dos mesmos.

O Processo de Normalização aplica uma série de Regras sobre as Entidades de um Banco de Dados, para verificar se as mesmas estão corretamente projetadas. Embora existam 5 formas normais (ou regras de Normalização), na prática usamos um conjunto de 3 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 entender o Processo de Normalização na Prática, através de exemplos.

1.6.1 - Primeira Forma Normal:

"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 Próxima Figura:

Figura 13 - Tabela que não está na Primeira Forma Normal.

Podemos Notar que uma tabela com esta estrutura apresentaria diversos problemas. Por exemplo se um Casal Tivesse mais de 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 sejam digitado exatamente igual todas às 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: Criar 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 de Pais pode ter Vários Filhos.

Observem na figura abaixo as duas tabelas: Pais e Filhos já normalizada.

Figura 14 - Informações sobre Pais e Filhos em Tabelas Separadas.

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

1.6.2 - Segunda Forma Normal:

Ocorre quando a chave Primária é composta por mais de um campo. 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. Se algum campo depender somente de parte da chave composta, então este campo deve pertencer à outra tabela.

Observe o Exemplo Indicado na Tabela da Figura a seguir:

Figura 15 - Tabela com uma Chave Primária Composta e 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, por isso que 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 abaixo, sendo que as duas tabelas resultantes estão na Segunda Forma Normal.

Figura 16 - Informações sobre Avaliações e Cursos em Tabelas Separadas.

OBS -> A Distinção entre a Segunda e a Terceira forma normal, que veremos mais adiante, muitas vezes é confusa. A Segunda Forma normal, na maioria das vezes, está ligada a ocorrência de Chaves Primárias compostas.

1.6.3 - Terceira Forma Normal:

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

Quando isto ocorre, dizemos que a tabela não está na Terceira Forma Normal, conforme indicado pela tabela da figura abaixo:

Figura 17 - Não está na Terceira Forma Normal.

OBS: A figura 16 é uma tabela com um Campo dependente de Outro campo que não é a Chave Primária.

Observe que o Campo DescriçãoDoCargo depende apenas do Campo CódigoDoCargo, o qual não faz parte da Chave Primária. Por isso dizemos que esta tabela não está na terceira forma normal.

Para Solucionar este problema, a solução também é simples. Novamente basta dividir a tabela em duas outras, conforme indicado pela figura abaixo. As duas tabelas resultantes estão na Terceira Forma Normal.

Figura 18 - Tabelas Resultantes que estão na Terceira Forma Normal.

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.

Projeto Proposto:

Neste ítem iremos projetar um Banco de Dados. Iremos aplicar os conhecimentos sobre Entidades, Atributos, Relacionamentos, Chave Primária e Normalização.

Antes de começarmos a trabalhar com o Microsoft Office Access 2007 precisamos fixar bem os conceitos anteriormente vistos, aplicando os mesmos em um Projeto de Um Banco de Dados.

Um banco de dados bem projetado fornece um acesso conveniente às informações desejadas. Com uma boa estrutura, se gasta menos tempo na construção de um banco de dados e, ao mesmo tempo, assegura-se resultados mais rápidos e precisos.

Nunca é demais lembrar que jamais devemos misturar assuntos em uma mesma tabela.