Para que você tenha um banco de dados relacional otimizado é muito importante que se atente ao design lógico do mesmo, inclusive as tabelas e as relações entre elas. Um bom design lógico torna-se o alicerce de um ótimo desempenho de banco de dados e dos aplicativos. A normalização do design lógico de um banco de dados envolve o uso de métodos formais para separar os dados em várias tabelas relacionadas.

Várias tabelas estreitas com menos colunas são características de um banco de dados normalizado. Poucas tabelas largas com mais colunas são características de um banco de dados não normalizado.

Muitas vezes, uma normalização razoável melhora o desempenho. Quando índices úteis estiverem disponíveis, o otimizador de consulta SQL Server é eficiente para selecionar junções rápidas e eficazes entre as tabelas.

Para que você obtenha maior proveito desse artigo é necessário que você tenha conhecimento prévio sobre normalização de dados, uma vez que nesse artigo falaremos sobre relacionamentos SQL.

Relacionamentos SQL

Relacionamentos são informações relacionadas entre sí, mas geralmente armazenadas em diferentes tabelas ou de alguma forma em uma tabela relacionada com ela mesma.

Baseados em campos em comum, normalmente campos chaves, utilizamos o parâmetro JOIN ou alguma de suas variações.

A sintaxe do parâmetro JOIN é a seguinte:

SELECT [colunas]
FROM Tabela1
JOIN Tabela2 On Tabela1.FK = Tabela2.PK

Repare que a condição do relacionamento é basicamente informar qual campo da tabela1 é igual ao campo da tabela2, geralmente esses campos são chaves sendo um deles chave primária e outro chave estrangeira, porém, isso não é uma regra.

O parâmetro JOIN possue várias variações e estas variações estão implementadas na maior parte dos bancos de dados disponível atualmente.

A seguir, veremos algumas das variações dos JOIN.

Para ilustrar o exemplo, considere as seguintes tabelas criadas no banco de dados SQL Server 2008.

Inner Join

O Inner Join é o Join Padrão utilizado nas operações de relacionamento nos bancos de dados quando nenhum outro Join é utilizado.

Ele gera o produto cartesiano entre as tabelas.

Gerar o produto cartesiano significa basicamente que esse tipo de join combina todas as linhas da primeira tabela com todas as linhas da segunda que satisfaçam as condições da cláusula especificada no relacionamento.

Um exemplo de Inner Join pode ser visto no seguinte comando SQL:
 


Repare que o resultado do SQL retorna 6 colunas, ou seja,  todas as colunas da tabela USUARIO e também todas as colunas da tabela DEPARTAMENTO.

Repare também que no resultado nós obtemos dois retornos de "COD_DEPARTAMENTO". Isso ocorre porque ao especificarmos "*" em nosso SELECT, ele retorna todas as colunas das tabelas que solicitamos.

Vale ressaltar também que para montar relacionamentos não é obrigatório que os campos utilizados na condição do relacionamento tenham os mesmos nomes, eles podem ter nomes diferentes desde que seja informada a condição do relacionamento no SQL.

Equi Join

O Equi Join é similar ao primeiro join apresentado, com a característica que as chaves do relacionamento apresentado devem haver os mesmos nomes.

Na verdade o Equi Join é uma forma simplificada de escrever o Inner Join quando temos os campos relacionados com os mesmos nomes.

Analise o SQL abaixo:

Select *

From Usuario
Join Departamento USING (Cod_Departamento);

O SQL acima retornará todos os campos de ambas as tabelas visto que ambas tem a coluna com o nome "COD_DEPARTAMENTO", contudo, no  SQL Server e Sybase a clausula "USING" não é suportada.

Non Equi Join

É possível também criar relacionamentos entre tabelas que não possuam campos em comum.

Considere as seguintes tabelas:

 E os dados populados: 


A tabela PESSOAS apresenta algumas pessoas de uma empresa e seus salários e a tabela SALARIO representa alguns cargos com faixa salarial cadastrada.

Para que possamos criar um relacionamento onde o resultado seja o nome da pessoa, seu salário e qual é o seu cargo baseado na sua faixa salarial, podemos fazer a expressão SQL dessa forma:

SELECT P.NOME, S.CARGO, P.SALARIO

FROM PESSOAS P
INNER JOIN SALARIO S ON P.SALARIO BETWEEN S.SALARIO_INICIAL AND S.SALARIO_FINAL

Note que após o parâmetro "FROM", temos o nome da tabela "PESSOAS" e logo em seguida um "P". Essa é uma forma de criar "alias" (apelidos) para as tabelas.

O intuito de criar apelidos para as tabelas é facilitar a forma como escrevemos a expressão SQL, ou seja, estamos dizendo que P é igual PESSOAS na expressão SQL.

O operador BETWEEN é utilizado para estabelecer um range entre um valor inicial e um valor final.

O resultado dessa expressão SQL é: 


Note que o Non Equi Join é apenas o nome dado ao termo de qualquer uma das outras expressão JOIN que não possua um campo em comum entre as tabelas.

Left Join

Esse tipo de JOIN obtém no resultado algumas linhas que não satisfazem a condição especificada do relacionamento em questão.

A propriedade LEFT que existe nesse JOIN, indica que as linhas da tabela à esquerda irão aparecer no resultado, mesmo que os registros não satisfaçam as condições especificadas no relacionamento.

Para exemplificar melhor a idéia, considere as tabelas abaixo populadas:

Tabela PESSOAS:
 

NOME

CPF

CIDADE

RAY SILVA

111.111.111-11

JUNDIAI

GUILHERME SILVA

222.222.222-22

JUNDIAI

 

Tabela VEICULOS:
 

CPF

VEICULO

PLACA

111.111.111.11

PEUGEOUT 206

AAA-0000

NULL

FIESTA

BBB-1111


Ao executarmos o SQL:

SELECT * FROM PESSOAS
LEFT JOIN VEICULOS ON PESSOAS.CPF = VEICULOS.CPF

O resultado será:
 

 

NOME

CPF

CIDADE

CPF

VEICULO

PLACA

RAY SILVA

111.111.111.11

JUNDIAI

111.111.111.11

PEUGEOUT 206

AAA-0000

GUILHERME SILVA

222.222.222.22

JUNDIAI

 

 

 


Repare que o todos os dados da tabela da ESQUERDA (LEFT) foram selecionados.

Com esse exemplo acima, podemos entender perfeitamente como o RIGHT JOIN funciona, considerando que os dados serão retornados da tabela da direita por sua vez.

Full Join

Utilizando o mesmo exemplo de tabelas acima, o Full Join atua de forma que TODOS os registros, independentes do relacionamento feito serão apresentados. Podemos considerar que o Full Join nesse caso traria o resultado tanto do LEFT JOIN quanto do RIGHT Join.

NOME

CPF

CIDADE

CPF

VEICULO

PLACA

RAY SILVA

111.111.111.11

JUNDIAI

111.111.111.11

PEUGEOUT 206

AAA-0000

GUILHERME SILVA

222.222.222.22

JUNDIAI

 

 

 

 

 

 

 

FIESTA

BBB-1111


Self Join

Até então nós falamos como relacionar diferentes tabelas, contudo, também é possível fazer um relacionamento da tabela com ela mesma.

Considere a tabela populada abaixo para esse exemplo:

Tabela INDICADOS
 

NOME

CPF

CIDADE

INDICADO

RAY SILVA

111.111.111.11

JUNDIAI

 

EDUARDO ALBA

222.222.222.22

JUNDIAI

111.111.111.11


A idéia da tabela é salvar o nome, cpf e cidade de um usuário e se ele foi indicado por alguém. Podemos considerar então que a indicação seja feita através da coluna CPF. Dessa forma, Eduardo foi indicado por Ray.

Para conseguirmos essa informação, temos que fazer um relacionamento da tabela com ela mesma!

Considere a expressão SQL abaixo:

SELECT A.NOME, B.NOME AS INDICADO_POR

FROM INDICADOS A JOIN INDICADOS B ON A.INDICADO = B.CPF

O resultado será:

NOME

INDICADO_POR

EDUARDO ALBA

RAY SILVA


Nesse artigo pudemos aprender algumas maneiras de trabalhar com relacionamentos no SQL. É muito importante que a modelagem do seu banco de dados seja feita da melhor maneira possível para assegurar que não hajam redundâncias e também melhorar o desempenho do seu banco de dados e das aplicações que acessarem o banco.

Para saber mais:

Aprofunde seus conhecimentos sobre este tema na comunidade SQL Server
Aprofunde seus conhecimentos sobre normalização de banco de dados

Exibições: 8210

Comentar

Você precisa ser um membro de DevBrasil para adicionar comentários!

Entrar em DevBrasil

Comentário de Thiago Oliveira em 2 fevereiro 2012 às 8:17

Parabéns, bacana seu post

Comentário de Michaell Dantas em 13 janeiro 2012 às 8:21

Valew Ray meu garoto...Excelente artigo....Parabéns !!!!

Comentário de Ray Silva em 31 dezembro 2011 às 11:49

Obrigado pelo feedback!

Comentário de Telmo Guibor em 31 dezembro 2011 às 11:18

Garoto... essa foi do peru!! tá de parabéns mesmo.. muito bem explicada e de maneira simples e fácil...realmente.. um show! Até eu que não sou muito da parte de banco de dados gostei demais.. imagina quem tá iniciando e aprendendo.. ainda mais em faculdade ahe.. PARABÉNS.!

Comentário de Márcio Araújo em 31 dezembro 2011 às 0:41

Que artigo Ray. Isso você tira de letra DBA. Tem uns termos que eu não sabia que tinha valeu.

Comentário de Cleiton Felipe de Moraes em 29 dezembro 2011 às 15:54

Parabéns Ray muito bom....

Comentário de Rafael Zaccanini em 29 dezembro 2011 às 11:35

Parabéns...Muito bem explicado ;)

© 2019   Criado por Ramon Durães.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço