Sempre vejo desenvolvedores iniciantes tremerem quando eu falo de JOIN. Mas na realidade acho que eles são mal compreendidos, e por isso, antes de começarmos a falar do comando SELECT, quero conversar sobre alguns aspectos do modelo relacional, que farão com que os JOINS sejam mais simples de serem escritos.

Não fique triste, mas neste artigo não falaremos de SQL Server 2017 e nem de SQL Azure. Este artigo é aplicável a qualquer banco de dados relacional.

Crie um modelo de dados

Já falei sobre isso no artigo “Por que você vai criar o modelo de dados?”, mas não custa te lembrar que quando você modela os seus dados, você minimiza a chance da sua aplicação fracassar. E digo isso porque aqueles bugs cujo pop-up aparece na tela são os melhores e mais fáceis de resolver. Problema de verdade temos com os erros que não sabemos que existem, e com os dados inconsistentes no banco de dados.

Modelo x Diagrama

90% da população mundial (ok, exagerei) acha que criar um modelo de dados significa criar um diagrama que segue 8 milhões de convenções (exagerei novamente).

Um modelo de dados pode ser representado através de um diagrama, que pode ou não seguir convenções.

Para você que está começando eu aconselho a sempre criar um diagrama para representar o seu modelo. Eu sempre crio um conjunto de quadradinhos e vou refinando até que eu entenda a necessidade de negócio. Quando eu entender, aí sim eu começo a fazer um modelo Entidade-Relacionamento.

Modelagem de Dados

Entidades

Uma entidade é a representação de um bloco conceitual de dados, ou seja, é a representação de alguma coisa que interessa para o nosso sistema.

Na dúvida para identificar uma entidade? Use o seguinte critério de classificação:

• Entidades são coisas tangíveis
• Funções exercidas por elementos, ou desempenhadas por pessoas ou organizações
• Eventos ou ocorrências
• Interações
• Especificações

Lembre-se: uma entidade é algo que é importante no contexto do seu sistema.

Atributos

Atributos são as características das entidades, para as quais eles conferem identificação e qualificação.

Um conjunto de atributos deve ser:

• Fatorado, ou seja, cada atributo capta um aspecto diferente da entidade;
• Mutuamente independente, ou seja, o valor de um atributo deve ser independente do valor dos outros atributos;
• Completo, ou seja, todas as informações relevantes da entidade devem dar origem aos atributos.

Tabelas

Uma tabela é a representação física de uma entidade. Por exemplo, a entidade carro foi criada no meu banco de dados SQL Server com o nome tbCarro.

Colunas

Uma coluna é a representação física de um atributo, e tem algumas propriedades importantes. Eu destaco o Nome, o Tipo de dados e a Nulidade (existem outras propriedades para um atributo, mas estas três são obrigatórias).

Chave primária – Primary Key – PK

A chave primária nada mais é do que um ou vários atributos que identificam unicamente cada instância de uma entidade. Por exemplo, criamos a entidade carro, que possui os atributos chassi, quantidade de portas, motor, placa, cor e etc.

Eu chamo de instância da entidade carro, cada carro que eu cadastrar na tabela tbCarros. O que identifica unicamente cada carro é o chassi, por isso ele será a chave primária da entidade carro e da tabela tbCarro.

Existem duas condições para um atributo ou um conjunto de atributos ser/serem a chave primária de uma tabela:

• Devem ser únicos
• Não podem receber nulos
• Relacionamentos

Lembrando que uma entidade representa somente um aspecto importante para o nosso sistema. Podem existir muitas entidades manipuladas pelo nosso sistema, e elas normalmente estarão RELACIONADAS. Um relacionamento nada mais é do que uma associação entre entidades.

A grande sacada dos relacionamentos e o motivo pelo qual eu defendo de forma ferrenha os diagramas, é que é mais fácil entender o fluxo da informação quando temos uma representação visual.

Um relacionamento tem propriedades importantes e que você deve conhecer.

Cardinalidade

Define o grau de relação entre as entidades, e pode ter os seguintes valores:

• Um para Zero ou Um:

Imagine que temos a entidade Pessoa e a entidade Funcionário. Um Funcionário só pode ser uma Pessoa, e a PK de ambas as entidades é o CPF.

• Um para Zero, Um ou Muitos:

Imagine que temos a entidade Pessoa e a entidade Telefone. Uma Pessoa pode ter vários números de telefone. Para identificar quem é o dono do telefone é preciso que o CPF (que é a PK da entidade Pessoa) seja um atributo da entidade Telefone.

• Muitos para Muitos:

Imagine a entidade Pessoa e a entidade Produtos. Uma Pessoa pode comprar vários Produtos e um Produto pode ser comprado por várias pessoas. Neste caso deve existir uma entidade de ligação, que possui como atributos o CPF da Pessoa e o Código do Produto.

Tipos de Relacionamento

Os tipos de relacionamento representam as regras de negócio que devem ser implementadas no banco de dados.

Relacionamento Identificado

Neste tipo de relacionamento, a PK da entidade pai faz parte da PK da entidade filha. Isso significa que a entidade filha não existe sem a entidade pai.

Relacionamento Não Identificado Mandatório

Neste caso a PK da entidade pai migra para a entidade filha, como um atributo (ou conjunto de atributos) obrigatório, mas não faz parte da PK. Isso significa que a entidade filha não depende da entidade pai para ser identificada, mas depende da entidade pai para existir.

Relacionamento Não Identificado Não Mandatório

Neste caso a PK da entidade pai migra para a entidade filha, como um atributo (ou conjunto de atributos) que não é obrigatório, e nem faz parte da PK. Isso significa que a entidade filha não depende da entidade pai.

Chave Estrangeira – Foreign Key – FK

Quando falamos dos relacionamentos, em vários momentos eu escrevi que a PK da tabela pai migrou para a tabela filha estabelecendo um relacionamento. A PK da tabela pai na tabela filha é chamada de chave estrangeira (porque migrou de uma tabela para outra), Foreign Key ou de forma reduzida FK.

Os JOINS

Joins são operações entre conjuntos, nada mais do que isso!

Tipos de JOIN

Cross Join

O primeiro tipo de join significa que você quer combinar todos os elementos de um conjunto com todos os elementos de outro conjunto. Em outras palavras você quer combinar todas as linhas de uma tabela com todas as linhas de outra tabela, fazendo um produto cartesiano.

Você percebe que não precisa existir relacionamento entre as entidades para fazer um cross join? Ele é simplesmente o produto cartesiano de duas tabelas.

Inner Join

Neste caso, significa que dados dois conjuntos, queremos somente os elementos comuns entre os eles.

Por que eu falei dos relacionamentos antes de falar dos joins?

Imagine duas tabelas relacionadas (PK da tabela pai, e FK na tabela filha). Como fazer o um INNER JOIN entre elas?

Se o inner join significa que buscamos aquilo que é comum às duas tabelas, devemos usar os atributos que elas têm em comum, ou seja, a PK da tabela pai e a FK da tabela filha.

Usando um comando SQL Genérico, podemos entender o INNER JOIN assim.

SELECT <colunas> FROM <tabelaPAI> INNER JOIN <tabelaFILHA> ON

<tabelaPAI>.PK = <tabelaFILHA>.FK

Left Join

Dados dois conjuntos, queremos os dados que eles possuem em comum e também aqueles que pertencem somente ao conjunto da esquerda.

Neste caso, imagine que a tabela pai é a tabela de Pessoas (PK é o CPF) e a tabela Filha é a tabela de Automóvel (FK é o CPF). Nem todas as pessoas possuem um automóvel. Imagina que você precisa de uma consulta de todas as Pessoas e os dados do Automóvel. A sua consulta usaria um LEFT JOIN, como o descrito abaixo:

SELECT <colunas> FROM <Pessoas> LEFT JOIN <Automóvel> ON

<Pessoa>.CPF = <Automóvel>.CPF

Right Join

Dados dois conjuntos, queremos os dados que eles possuem em comum e também daqueles que pertencem somente ao conjunto da direita.

Imagine que seu sistema controla todos os Sinistros que uma Seguradora pagou. Todo Sinistro está relacionado a um Seguro, mas nem todo Seguro tem um Sinistro. O seu sistema precisa exibir uma listagem com todos os Seguros indicando aqueles que possuem Sinistro. A consulta genérica para este caso seria:

SELECT <colunas> FROM <Sinistro> RIGHT JOIN <Seguro> ON

<Sinistro>.FK = <Seguro>.PK

Left e Right join possuem algo em comum?

Sim. Eles são espelho um do outro e dependem única e exclusivamente da ordem em que você coloca as tabelas no seu comando. No exemplo anterior eu poderia ter escrito a tabela de Seguro primeiro e ter feito um left join com a tabela Sinistro. Veja o exemplo abaixo (que retornaria exatamente o mesmo resultado do exemplo anterior).

SELECT <colunas> FROM <Seguro>  LEFT JOIN <Sinistro> ON
<Seguro>.PK =<Sinistro>.FK

Conclusão

Escrever joins corretamente é vital para o sucesso da sua aplicação e para o seu sucesso como desenvolvedor. Nem sempre os bancos de dados serão simples e poucas vezes as consultas envolverão somente uma tabela. Por isso escrevi este artigo e tentei ser o mais clara possível com os conceitos que eu considero muito importantes para um desenvolvedor iniciante.

Por favor, não fique com dúvidas! Me procure se algum ponto não estiver claro o suficiente.

Resumindo

Referências

Se você quer saber mais sobre modelagem de dados (aconselho muito!), recomendo que leia o livro do professor Carlos Barbieri. Muito do que você leu neste artigo aprendi lendo e relendo este livro.