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

Até o momento vimos como criar nossas tabelas e campos. No tópico anterior também olhamos rapidamente um relacionamento e como o mesmo pode nos ajudar a evitar a duplicação de informações no banco de dados.

Além de evitar a duplicação de informações, relacionamento serve outros propósitos tais como:

• Manter integridade das informações (veja mais adiante tópico sobre imposição de integridade referencial);
• Criar um vínculo entre informações;
• Facilitar a análise de dados.

Para criar um relacionamento é bastante simples. O que o leitor precisa ter em mente durante a criação das tabelas:

• Ter duas tabelas;
• As duas tabelas precisam ter um campo em comum (de preferência uma chave primária de numeração automática);
• Procurar manter os nomes dos campos iguais em ambas as tabelas. Embora não seja crítico, esta prática facilitará a compreensão e relacionamento dos campos, principalmente se isso ocorrer via VBA.

Para criar um relacionamento, com a janela do banco de dados aberta em Tabelas, vá a Ferramentas à Relacionamentos. Caso a janela contendo a lista de tabelas não esteja visível, clique com o botão direito do mouse sobre uma área qualquer. No menu popup que aparecerá, clique sobre Mostrar tabela...:

Figura 5‑1 Abrindo a janela de tabelas/consultas disponíveis para relacionamento

Nesta janela selecione as tabelas e/ou consultas que deseja relacionar. Clique no botão Adicionar para que as mesmas sejam adicionadas à área de relacionamentos:

Figura 5‑2 Selecionando tabelas e/ou consultas para relacionamento

Uma vez que as tabelas/consultas estejam na área de relacionamento, simplesmente arraste o campo de relacionamento de uma tabela para outra. O Access determinará automaticamente se o tipo é de um-para-muitos ou muitos-para-muitos:

Figura 5‑3 Relacionamento um-para-muitos

Com estas informações básicas em mente, vejamos os tipos de relacionamentos e como criá-los.

Relacionamentos um-para-muitos

Relacionamentos um-para-muitos é provavelmente o tipo mais comum de relacionamento onde um registro na tabela primária pode estar relacionado com vários registros de uma tabela secundária.

Por exemplo, poderíamos ter uma tabela de categorias de produtos (tabela primária) e uma tabela de produtos (tabela secundária). Neste caso, todos os produtos são categorizados de acordo com as categorias na tabela primária:

Figura 5‑4 Relacionamento um-para-muitos

A figura acima mostra este tipo de relacionamento. A tabela lojas contém uma lista de lojas ao passo que a tabela produtos contém diversos produtos. Porém, uma loja pode ter vários produtos listados para ela. Neste exemplo específico a via é uma loja para muitos produtos.

Não obstante, se o banco de dados fosse de uma cadeia de lojas o melhor relacionamento seria muitos-para-muitos para evitar a repetição de produtos, pois uma loja poderia ter vários produtos e um mesmo produto (digamos, cafeteira) pode ser vendida em várias lojas diferentes.

No próximo tópico discuto este tipo de relacionamento.

Relacionamentos muitos-para-muitos

Relacionamentos um-para-muitos­ é o tipo mais comum de relacionamento, isto é você tem um item relacionado a vários outros itens. Agora, imagine o seguinte cenário: você possui uma empresa de treinamento e deseja criar um banco de dados para controlar alunos, professores, classes, etc.

Neste cenário, não há nada que impeça que um aluno participe de várias classes. Assim como cada classe pode ter vários alunos. Da mesma forma, um professor pode dar aula para várias classes e vice-versa. Sendo assim, nós temos um relacionamento muitos-para-muitos.

Este tipo de relacionamento não pode ser feito diretamente entre duas tabelas. Portanto, nós precisamos de uma tabela intermediária a qual é utilizada para consolidar e reconciliar os dados.

Vejamos então o cenário dos alunos e salas delineado acima (mais adiante no curso veremos um estudo de caso mais elaborado deste exemplo):

Figura 5‑5 Relacionamento muitos-para-muitos

A tabela central (tblCursosAlunos), como podemos observar, possui o símbolo de infinito de ambos os lados. Isso indica que esta tabela pode conter vários registros da tabela de alunos e também vários registros da tabela de cursos.

Observe a tabela intermediária:

Figura 5‑6 Tabela intermediária para relacionamento muitos-para-muitos

O mesmo curso e aluno se repetem várias vezes na tabela intermediária. Por outro lado, quando abrimos a tabela de aluno ou cursos nós podemos expandir o relacionamento para saber quais cursos o aluno faz parte ou quais alunos pertencem a determinado curso. A pergunta pode ser colocada tanto para a tabela de alunos quanto a tabela de cursos:

Figura 5‑7 Expandindo as tabelas de alunos e cursos

Como podemos ver no na figura acima, independentemente de qual direção caminhamos podemos facilmente reconciliar as informações. Na tabela de alunos podemos rapidamente saber em quais cursos o aluno está matriculado. Por outro lado, na tabela de cursos vemos rapidamente quais alunos estão matriculados em determinado curso.

Vejamos agora como impor integridade referencial e o que isso significa em termos de segurança e integridade dos registros.

Impondo Integridade referencial

Quando impomos integridade referencial no Access o que desejamos é que o relacionamento entre registros das tabelas relacionadas sejam válidos. Por exemplo, não faria sentido relacionar e deixar um campo relacionado vazio.

Quando o leitor fez o primeiro relacionamento a janela abaixo foi apresentada:

Figura 5‑8 Editando relacionamentos

Aqui, precisamos tomar algumas decisões em relação ao que desejamos fazer.

Qual o motivo para se impor integridade referencial? Pergunte-se o que ocorreria quando você adicionasse um registro na tabela intermediária, mas entrasse somente o nome do curso. Em um cenário como este, sem a imposição de integridade, não há problema algum no momento da entrada do registro. Porém, este registro é órfão, isto é, ele não possui o outro lado do relacionamento. Deste modo, os dados não estariam verdadeiramente relacionados.

Agora, pergunte-se o que ocorreria caso um aluno fosse removido da tabela de alunos. Sem a imposição de integridade referencial e propagação para exclusão de registro, novamente teríamos registros órfãos.

Obviamente que nem um nem outro cenário é satisfatório. O que queremos é um banco de dados a prova de balas. Um banco de dados onde informações não sejam perdidas por detalhes como estes. Deste modo, podemos resumir a imposição da integridade como segue:

• Impor integridade referencial à Assegura que os relacionamentos entre registros são válidos e que informações em uma tabela são consistentes com informações requeridas em outra tabela relacionada;
• Propagar atualização dos campos relacionados à Assegura a propagação de mudanças para os registros relacionados. Por exemplo, se a informação na chave primária da tabela primária é modificada esta mudança é propagada para todos os registros relacionados na tabela secundária. Contudo, caso o campo relacionado seja de numeração automática não faz diferença esta imposição, pois não é possível editar um campo de auto numeração;
• Propagar exclusão dos registros relacionados à Assegura a propagação da exclusão de registros relacionados. Por exemplo, se um tabela de categorias está relacionada com uma tabela de produtos, se uma categoria é removida, todos os produtos relacionados também são removidos evitando registros órfãos na tabela de produtos.

Condições para integridade referencial

Para que a integridade referencial seja válida, o leitor deve observar algumas condições nos campos e tabelas que se deseja relacionar:

• O campo relacionado na tabela primária deve ser indexado e seu valor deve ser único. Para evitar problemas, o leitor deve utilizar o campo de numeração automática ou informações únicas como o número de CPF ou RG, por exemplo;
• Os campos sendo relacionados não precisam ter o mesmo nome (embora tal prática seja útil para a compreensão dos relacionamentos), mas o tipo de dado deve ser o mesmo nas tabelas primária e secundária. As exceções a esta regra são:
• Campo de auto numeração pode ser relacionado a um campo numérico desde que a propriedade do comprimento do campo numérico seja Inteiro Longo;
• Campo de auto numeração tenha a propriedade Tamanho do campo setada para Replication ID e o mesmo seja verdadeiro para o campo numérico na tabela secundária.
• As tabelas sendo relacionadas devem pertencer ao mesmo banco de dados;
• Tabelas vinculadas precisam ter integridade referencial determinada no local de origem das tabelas e as mesmas precisam ser tabelas do Access.

Regras pós aplicação de integridade referencial

Uma vez que integridade referencial tenha sido imposta entre as tabelas, o leitor precisará observar as seguintes regras:

• Não é possível remover um registro da tabela primária quando existir itens relacionados na tabela secundária. Caso seja necessária tal remoção de registro é necessário selecionar a propagação na exclusão de registros:

Figura 5‑9 Registro não pode ser excluído havendo integridade referencial para não deixar órfão

• Não é possível adicionar um registro na tabela secundária quando um registro relacionado é inexistente na tabela primária. Por exemplo, você não pode adicionar um aluno a um curso se este curso não existir na tabela de cursos;
• Não é possível modificar o valor da chave primária se a mesma já possuir valores relacionados na tabela secundária. Para que isso seja possível é necessária a propagação da atualização feita.

Tipos de associações

Na caixa de edição de relacionamento há um botão para seleção do tipo de associação. Ao clicarmos neste botão uma nova caixa de diálogo nos é dada onde podemos determinar o tipo de associação:

Figura 5‑10 Tipo de associação

As três opções são definidas abaixo:

• Primeira opção à A primeira opção refere-se à uma associação interna (Inner Join). A associação interna é aquela onde registros de duas tabelas distintas são combinados no resultado de uma consulta com a condição de que somente se os valores dos campos relacionados se encaixam na condição predeterminada. Associação interna é a associação padrão no relacionamento;
• Segunda opção à A segunda opção refere-se à uma associação externa esquerda (Left Outer Join). Neste caso, todos os registros da tabela à esquerda são adicionados à consulta, mesmo quando não há nenhum campo com valores determinados no critério na tabela à direita;
• Terceira opção àA terceira opção refere-se à uma associação externa direita (Right Outer Join). Neste caso, temos o oposto do Left Outer Join onde todos os registros da tabela à direita são adicionados mesmo quando não há registro algum dentro do critério determinado para os valores do campo da tabela à esquerda.