Regras e Tipos de Relacionamentos no SQL Server

Regras e tipos relacionamentais em SQL

Voltando a partir de onde paramos, veja mais um tipo de relacionamento:

N:N � O relacionamento N:N (muitos-para-muitos) possui uma caracter�stica diferente dos outros. Neste caso, os dados est�o diretamente relacionados ao fato, e n�o as entidades, como observamos nos outros tipos de relacionamentos vistos anteriormente.

Importante destacar que podem n�o haver associaç�o de fatos nas situaç�es em que os relacionamentos s�o de car�ter condicional.

Neste caso, a cardinalidade deve ser determinada por meio de uma ampla an�lise quanto � possibilidade de ocorrerem relacionamentos.

Regras de Relacionamento N:N� Para estabelecer este tipo de relacionamento, devemos ter tr�s tabelas, sendo que a terceira � respons�vel por relacionar as outras duas. Para isso, � preciso que essas duas primeiras tabelas contenham uma coluna que seja chave prim�ria.

As colunas que s�o chaves prim�rias na primeira e na segunda tabela devem ser colunas com chave estrangeira na terceira. Assim, esta tabela ter� duas chaves estrangeiras, as quais formam uma chave prim�ria composta.

Vimos os tipos de relacionamentos existentes, vamos fazer agora os exemplos pr�ticos com eles.

1:1 �Lembrando que neste relacionamento, cada um dos elementos de uma entidade s� pode se relacionar com apenas um elemento de outra entidade. Ent�o, consideremos as tabelas Clientes e Documentos, em que cada um dos clientes pode ter apenas um documento (considerando que nesta tabela um mesmo cliente n�o pode ter mais de um documento), assim como cada um dos documentos s� pode pertencer a apenas um cliente.

Confira nas imagens abaixo a criaç�o das tabelas, das constraints e inserç�o de alguns registros:

Perceba que na tabela Documentos criei uma Foreign Key (chave estrangeira) se relacionando com a Primary Key da tabela

Clientes.Veja como ficar�o as tabelas:

Assim temos o relacionamento de um-para-um.

1:N � Como dito no artigo anterior, neste relacionamento, que � um dos mais comuns hoje em dia, cada elemento da entidade �A� pode ter um relacionamento com v�rios elementos da entidade �B�. Em contrapartida, cada um dos elementos da entidade B pode estar relacionado a apenas um elemento da A. Dito isto, consideremos a tabela Clientes j� criada e agora vamos criar a tabela Telefones com o c�digo a seguir, j� que neste caso cada cliente pode ter v�rios telefones, mais cada telefone pode pertencer a um, e somente um cliente:


CREATE TABLE Telefones
(
  IdTelefone      INT IDENTITY(1,1),
  IdCliente     INT NULL,
  TipoTelefone    VARCHAR(15) NOT NULL,
  NumeroTelefone    VARCHAR(15) NOT NULL
  
  CONSTRAINT PK_Telefone PRIMARY KEY (IdTelefone),
  CONSTRAINT FK_Telefones_IdCliente FOREIGN KEY (IdCliente)
          REFERENCES Clientes (IdCliente)
)

--Insiro alguns registros na tabela Telefones
INSERT INTO Telefones VALUES (1, 'Residencial', '3243-2015')
INSERT INTO Telefones VALUES (3, 'Comercial', '3221-0132')
INSERT INTO Telefones VALUES (1, 'Celular', '9777-2112')
INSERT INTO Telefones VALUES (2, 'Residencial', '3353-9899')
INSERT INTO Telefones VALUES (2, 'Celular', '8871-1015')

Confira nas imagens a seguir a inserç�o de alguns registros e o resultado da consulta a ela:

Assim temos o relacionamento de um-para-muitos.

N:N � Relembrando, neste relacionamento, que � diferente dos outros, os dados est�o diretamente relacionados ao fato, e n�o �s entidades, como os outros dois anteriores. Seguindo as regras deste tipo de relacionamento, temos que, obrigatoriamente, criar tr�s tabelas, j� que a terceira tem a responsabilidade crucial de fazer o relacionamento entre as outras duas.

Para uma melhor compreens�o, vamos usar novamente a tabela Clientes e a tabela Pedidos, criada no artigo anterior. Com elas, temos a seguinte situaç�o: um cliente pode fazer diversos pedidos, ao passo que um pedido pode ser feito por diversos clientes.

Como j� temos as tabelas criadas, vamos apenas criar a terceira tabela, denominada ClientesXPedidos, respons�vel por interliga-las. Veja as imagens a seguir de sua criaç�o, inserç�o de registros (note que ela conter� apenas as chaves das duas outras tabelas) e posterior consulta:

Perceba na imagem acima que os mesmos campos, IdCliente e IdPedido, s�o chaves prim�rias e tamb�m s�o chaves estrangeiras, criando assim o relacionamento entre as tabelas Cliente e Pedido.

Assim temos o relacionamento de muitos-para-muitos. Dif�cil? N�o n�.

Links �teis

http://technet.microsoft.com/pt-br/library/ms187404.aspx
Como funciona a DMV Sys.dm_exec_cached_plans
http://msdn.microsoft.com/en-us/library/ms180765.aspx:
Displaying Execution Plans by Using the Showplan SET Options
http://technet.microsoft.com/en-us/library/ms191158.aspx
Showplan Logical and Physical Operators Reference

Saiba mais sobre SQL Server ;)

Processamento de consultas no SQL Server:
Este artigo apresenta como funciona o processamento de uma consulta no SQL Server, identificando os principais mecanismos e componentes desse sistema.
Performance no SQL Server: eliminando o operador Sort:
Veja neste artigo como otimizar a performance de consultas no SQL Server atrav�s da remoç�o do operador Sort.
Schemas no SQL Server:
Veja neste artigo informaç�es sobre Schemas, o que �? Como criar? Como usar ? Como alterar ? Os Schemas s�o uma coleç�o de objetos dentro de um determinado database.

Exemplo Pr�tico: Regras e Tipos de Relacionamentos - SQL Server 2008 - Parte 3

Neste artigo veremos os terceiro tipo de relacionamento do SQL Server. Veremos também exemplos práticos dos três tipos de relacionamentos abordados até aqui.

Regras e tipos relacionamentais em SQL

Links �teis

Saiba mais sobre SQL Server ;)

Artigos relacionados