O Modelo Relacional de Dados – Parte II

Na primeira parte deste artigo falei sobre Entidades (tabelas), Atributos (campos) e sobre o conceito de Chave Primária. Nesta segunda parte vou abordar os seguintes tópicos: Relacionamentos entre entidades (tabelas) – conceito e Relacionamentos entre entidades (tabelas) - tipos.

por Júlio Cesar Fabris Battisti

Introdução

Objetivo: Na primeira parte deste artigo falei sobre Entidades (tabelas), Atributos (campos) e sobre o conceito de Chave Primária. Nesta segunda parte vou abordar os seguintes tópicos:

• Relacionamentos entre entidades (tabelas) - conceito
• Relacionamentos entre entidades (tabelas) - tipos

Nota: Os exemplos apresentados utilizarão telas do Microsoft Access e o arquivo de exemplos Northwind.mdb, o qual é instalado juntamente com o Microsoft Access. Este arquivo está disponível, por padrão, no seguinte caminho:

C:\Arquivos de programas\Microsoft Office\Office\Samples

Porém os princípios básicos do modelo relacional aplicam-se a qualquer banco de dados baseado no modelo relacional de dados. Estes bancos de dados são algumas vezes denominados: SGBDR - Sistemas Gerenciadores de Banco de Dados Relacionais.

Relacionamentos entre Tabelas

Neste item vou apresentar o conceito de relacionamento entre tabelas, este um conceito fundamental para o Modelo Relacional de Dados. Também falarei sobre os diferentes tipos de relacionamentos existentes. Serão apresentados exemplos práticos.

Conforme descrito na Parte I, um banco de dados é composto por diversas tabelas, como por exemplo: 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, itens que são gravados na tabela Detalhes do Pedido. Além disso cada Pedido possui um número único (Código do pedido), 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 do tipo Chave Primária, 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.

Importante: O campo que relaciona duas tabelas deve fazer parte, ter sido definido, na estrutura das 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 Figura a seguir vemos o exemplo de um Relacionamento do tipo Um para Um entre as tabelas Alunos e Alunos da Banda.

Figura 1: 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, na tabela Clientes, é uma chave primária, indicando que não podem ser cadastrados 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 mesmo Código de 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ários entre as Tabelas Clientes e Pedidos do banco de dados Pedidos.mdb, através do campo código do cliente:

Figura 2: 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 (¥). Esta é a representação utilizada no Microsoft Access. Diferentes representações poderão ser utilizadas por outros bancos de dados.

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.

IMPORTANTE: Observe que o campo que é o lado vários do relacionamento não pode ser definido como chave primária. Lembrando do conceito de Chave Primária, apresentado na Parte I: Chave Primária é o campo no qual não podem haver valores repetidos. Ora, se o campo está no lado "vários", significa que ele poderá ter o seu valor repetido em vários registros. Por exemplo, na tabela pedidos, poderá haver vários registros para o mesmo cliente. Se o campo terá que ter valores repetidos, então ele não pode ser definido como chave primária.

No Banco de Dados NorthWind.mdb, Northwind.mdb, o qual é instalado juntamente com o Microsoft Access. Este arquivo está disponível, por padrão, no seguinte caminho:

C:\Arquivos de programas\Microsoft Office\Office\SamplesExistem diversos outros exemplos de relacionamentos do tipo Um para Vários, conforme descrito na Próxima Tabela:

Tabela 1: Exemplos de relacionamento de um para vários

Tipo

Lado Um

Lado Vários

Um para Vários

CódigoDoFornecedor na tabela Fornecedores

CódigoDoFornecedor na tabela

Produtos

Um para Vários

CódigoDaCategoria na tabela Categorias

CódigoDaCategoria na tabela Produtos

Um para Vários

CódigoDoProduto na tabela Produtos

CódigoDoProduto na tabela Detalhes do Pedido

Um para Vários

CódigoDoFuncionário na tabela Funcionários

CódigoDoFuncionário na tabela Pedidos

Um para Vários

NúmeroDoPedido na tabela Pedidos

NúmeroDoPedido na tabela Detalhes do Pedido

Um para Vários

CódigoDaTransportadora na tabela Transportadoras

Via na tabela

Pedidos

Um para Vários

CódigoDoCliente na tabela

Clientes

CódigoDoCliente na tabela Pedidos

Em um dos próximos artigos mostrarei 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:

Este tipo de relacionamento "aconteceria" em 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 é possível implementar um relacionamento deste tipo, devido a uma série de problemas que seriam introduzidos no modelo do banco 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 vamos criar 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:

Tabela 1: Exemplos de relacionamento um para vários e vários para um

Tipo

Lado Um

Lado Vários

Um para Vários

CódigoDoProduto na tabela

Produtos

CódigoDoProduto na tabela Detalhes do Pedido

Um para Vários

NúmeroDoPedido na tabela

Pedidos

NúmeroDoPedido na tabela Detalhes do Pedido

Na figura abaixo temos a representação dos dois relacionamentos Um para Vários, resultantes da quebra do relacionamento vários-para-vários:

Figura 3: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, na próxima Parte III, falarei sobre o conceito de Integridade Referencial como uma maneira de Garantir a Consistência dos Dados.

Conclusão:

Nesta segundo artigo da série, você aprendeu sobre os conceitos de relacionamentos, sem dúvidas um dos conceitos mais importantes do Modelo Relacional. Implementar um banco de dados sem se preocupar com um projeto cuidados dos relacionamentos, é garantia certa de "encrenca" mais adiantes. São consultas que retornam dados inesperados, são relatórios que retornam valores "absurdos" e por aí vai. É fundamental que os profissionais de desenvolvimento e de administração de banco de dados entendem o quão impotante é planejar o banco de dados, cuidadosamente, definindo quais tabelas farão parte do banco de dados, quais os campos de cada tabela, quais campos serão chave primária e qual o relacionamento entre as tabelas. Muitos acham que esta é uma "perda de tempo", que o bom mesmo é sentar e começar a implementar o banco de dados, depois "a gente vê o que dá". Ledo engano. Não é perda de tempo, muito pelo contrário, é um ganho de tempo e principalmente de qualidade no produto final. Quanto tempo é perdido depois, tentando corrigir erros e incosistências que muitas vezes são decorrentes de um banco de dados mal projetado? Uma boa leitura a todos e até a Parte III.

Entre em contato. Deixe-me conhecer a sua opinião e também suas sugestões. Entre em contato através do e-mail webmaster@juliobattisti.com.br ou diretamente através de um dos seguintes sites:

www.juliobattisti.com.br e www.certificacoes.com.br. http://www.linhadecodigo.com.br/artigo/122/o-modelo-relacional-de-dados-parte-ii.aspx