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. Por exemplo, para fazer um relatório do total anual 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 é o “Relacionamento entre Tabelas”.
Por exemplo: um Pedido é feito por um Cliente e neste Pedido podem existir diversos Itens. As informações sobre o cabeçalho do pedido (Número do pedido, Data, Código do cliente, Endereço de entrega, Código do funcionário, etc), são armazenadas na tabela Pedidos. Já as informações sobre os itens do pedido (Número do pedido – para identificar a qual pedido pertence o item, Código do produto, Quantidade, Preço unitário, etc.), 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. Com esta separação entre as informações do cabeçalho do pedido (na tabela Pedidos) e dos Itens do pedido (na tabela Detalhes do pedido), evitamos uma série de problemas, tais como a repetição desnecessária de informações. Se colocássemos todas as informações em uma única tabela, teríamos que repetir todos os dados do cabeçalho do pedido, para cada um dos itens do pedido. E quem garante que estas informações seriam inseridas corretamente, para todos os itens de um pedido?
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 alguma maneira 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
Vamos analisar cada um deste tipos de relacionamentos, individualmente e detalhadamente.
Procure entender bem o conceito de relacionamentos, pois este é um conceito fundamental para entender o SQL Server 2005.
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: 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 é 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., estas poderiam 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, diminuindo a probabilidade de erros de digitação.
Na Figura 1.4 vemos o exemplo de um relacionamento do tipo Um para Um entre as tabelas Alunos e Alunos da Banda.

Figura 1.4 Um relacionamento do tipo Um para Um.
Relacionamento do Tipo Um para Vários
Este, sem nenhuma dúvida, é 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.
|
Promoção: Livro Windows Server 2008 R2
Curso Completo, 1222 páginas. Tudo para você se tornar um administrador de redes altamente qualificado para o mercado de trabalho e levar a sua carreira para o próximo nível!
|
Considere o exemplo entre a tabela Clientes e a tabela Pedidos. Cada Cliente é somente cadastrado uma única vez na tabela Clientes (por isso o campo Código do Cliente é uma Chave Primária, indicando que não podem ser cadastrados dois clientes com o mesmo valor no campo Código do cliente). Com isso a tabela Clientes será o lado Um do relacionamento. Por outro lado, cada cliente pode fazer diversos pedidos, portanto o mesmo valor para o campo Código do Cliente, poderá aparecer várias vezes na tabela Pedidos - tantas vezes quantos forem os pedidos que o Cliente tiver feito. Por exemplo, se o cliente cujo código for ALFKI tiver feito 10 pedidos, o código deste cliente aparecerá em 10 registros diferentes, na tabela Pedidos. Já na tabela Clientes, o código ALFKI aparecerá em um único registro, o qual representa o cadastro do cliente. Por isso que temos um relacionamento do tipo Um para Vários entre as tabelas Clientes e Pedidos, através do campo Código do Cliente, indicando que um mesmo Cliente pode fazer diversos pedidos. O lado um é na tabela Clientes – cada cliente será cadastrado um única vez; o lado vários é a tabela Pedidos – cada cliente poderá fazer vários pedidos.
Na Figura 1.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 .
No lado Um do relacionamento o campo é definido como uma Chave Primária (campo CódigoDoCliente na tabela Clientes) e no lado Vários o campo CódigoDoCliente não é uma chave primária (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.

Figura 1.5 Um relacionamento do tipo Um para Vários.
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 (não podem ser cadastrados dois ou mais pedidos com o mesmo número). 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 diversos itens de cada pedido. Este relacionamento indica que “um” mesmo “pedido” pode ter “diversos itens”, o que faz sentido.
Na Figura 1.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 1.6 Mais um exemplo de relacionamento do tipo Um para Vários.
O campo do lado Vários do relacionamento também é conhecido como sendo uma “Chave Estrangeira”. No exemplo da Figura 1.6, o campo NúmeroDoPedido, na tabela Detalhes do Pedido, seria a nossa Chave Estrangeira do relacionamento em questão. No exemplo da figura 1.5, o campo CódigoDoCliente, na tabela Clientes, seria a Chave Estrangeira.
Relacionamento do Tipo Vários para Vários
Este tipo de relacionamento ocorre em uma situação onde, em ambos os lados do relacionamento, os valores podem se repetir. Vamos considerar o caso entre as tabelas 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: 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 traria.
Para evitar problemas, é 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 1.7:

Figura 1.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 uma série de problemas no Banco de Dados, tais como informação repetida, inconsistência de dados e “mistura” de dois ou mais assuntos na mesma tabela.
Agora que já conhecemos os tipos de relacionamentos existentes, veremos o conceito de Integridade Referencial. O mecanismo da Integridade Referencial nos garante a consistência dos dados.
Integridade Referencial
A Integridade Referencial é utilizada para garantir a integridade dos dados entre as diversas tabelas relacionadas de um banco de dados, 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 de Clientes. Através da Integridade Referencial, também podemos garantir outros mecanismos importantes:
- 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 pedir para 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 da criação das tabelas e dos 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. |