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

Objetivo: Nesta lição vamos apresentar o conceito de relacionamento entre tabelas, este um conceito fundamental para o Modelo Relacional de Dados. Também veremos os diferentes tipos de relacionamentos existentes. Serão apresentados exemplos práticos.

Conforme podemos ver no banco de dados Pedidos.mdb, com o qual trabalhamos na lição anterior, 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 relacionamentos entre as 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 e assim por diante.

Em um banco de dados, precisamos de alguma maneira para representar estes relacionamentos da vida Real, em termos das tabelas e de 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
• 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.

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 projeto do Banco de Dados, podemos criar uma Segunda Tabela "Alunos da Banda",  a qual se relaciona com a tabela Alunos através de um relacionamento do tipo 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 de banda, etc. Quando fosse necessário buscar as informações tais como nome, endereço, etc, estas 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. 

Na Próxima Figura vemos o exemplo de um Relacionamento do tipo Um para Um entre as tabelas Alunos e Alunos da Banda.

 
Relacionamento Um para Um entre as Tabelas Alunos e Alunos da Banda. 

Com a criação deste relacionamento estamos evitando a repetição desnecessária de informações em diferentes tabelas.  

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 é cadastrado uma única vez na tabela de Clientes (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. Ao mesmo tempo 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ódigo do Cliente, indicando que um mesmo Cliente pode realizar diversos (vários) pedidos. 

Na próxima figura vemos um exemplo de um Relacionamento Um para Váriosentre as Tabelas Clientes e Pedidos do banco de dados Pedidos.mdb, através do campo código do cliente: 

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ó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 várias vezes, o que faz sentido, uma vez que um mesmo cliente pode fazer diversos pedidos. 

No Banco de Dados NorthWind.mdb, que está na pasta CursoAccBasico (lembre que você já deve ter feito Download destes arquivos, conforme orientações da Lição 1), 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. O tipo dos campos é que precisa ser o mesmo, por exemplo, se um dos campos for do tipo Texto, o outro também deverá ser do tipo Texto.

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.

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

Na prática não temos como implementar um relacionamento deste tipo, devido a uma série de problemas que seriam introduzidos no modelo de dados. 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 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 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:

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

Esta situação em que um relacionamento um 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, próxima lição veremos como Implementar relacionamentos no Microsoft Access e a utilização da Integridade Referencial como uma maneira de Garantir a Consistência dos Dados.