Entrar Ainda não tem acesso?
1
resposta

INNER JOIN E SUBCONSULTAS

Referente ao curso Realizando consultas com SQL: Joins, Views e transações

por Orlando Pedro Souto Ferreira
| 93.9k xp | 10 posts
Técnico

Bom dia!

Segundo a instrutora: " Em "Subconsultas", consultamos dados da mesma tabela e usamos o id de clientes e pedidos, mas em nenhum momento criamos uma obrigatoriedade de que esses campos existissem para que conseguíssemos trazer as informações da tabela."

" No JOIN , precisamos que os campos que fazem a relação entre as duas tabelas existam, obrigatoriamente. Isso é necessário porque queremos que o JOIN nos traga o nome dos clientes, onde o ID que está na tabela de clientes seja igual ao ID que está na tabela de pedidos."

Achei a explicação acima um pouco confusa. Não entendi.

Fiz o teste e percebi que o INNER JOIN funciona sem o ON. Por exemplo o código SELECT * FROM clientes INNER JOIN pedidos funciona e resulta na junção de cada cliente com todos os pedidos, embora esse não seja o resultado esperado. Não há obrigatoriedade do uso do ON

Eu entendi que o INNER JOIN faz a junção de duas tabelas. No código SELECT * FROM clientes INNER JOIN pedidos, a junção ocorre mas será juntado cada cliente com todos os pedidos. Aí precisamos aplicar um filtro, ON, que irá retornar a tabela de acordo com a condição.

Enfim o ON funciona para INNER JOIN como o HAVING funciona para o GROUP BY e o WHERE funciona para SELECT nas situações gerais. Estou correto?

Poderiam por gentileza explicar a questão da obrigatoriedade mencionada pela instrutora?

1 resposta
por Mario Sergio
| 7k xp | 13 posts

Orlando vou tentar te ajudar. Pelo visto sua dúvida é em relação ao JOIN.

Notas:

  1. O JOIN é utilizada para juntar duas ou mais tabelas, ou seja, pegar informações "de um objeto" espalhados em várias tabelas.
  2. Um relacionamento gera um produto cartesiano entre as tabelas, ou seja, um dados de uma tabela é combinado com todos os dados da outra tabela.
  3. Um campo para relacionamento deve existir em todas as tabelas onde as informações estão fragmentadas. Normalmente os campos são chaves estrangeiras (FK), mas não é uma regra que o campo seja uma chave (bancos desnormalizados).

Considerando a nota1. Como estou juntando as informações de um objeto, eu tenho que ter o identificador "desse objeto" em todas as tabelas onde a busca esta sendo efetuada. No seu caso como a busca é feita por cliente e o cliente é identificado por "ID_Cliente", primary key, na tabela de pedidos eu tenho que ter o ID_Cliente, foreing key.

Considerando a nota 2. Como o Join é um produto cartesiano, para que a informação ser integra é necessário aplicar um "Filtro", como você mencionou, para ter certeza que as informações fazem parte do "objeto" que estou pesquisando. Exemplo.

Tabela Cliente: ID_Cliente, Nome

    001 João
    002 Maria

Tabela Pedido. Id_clIente, ID_pedido, Produto

    001 A Arroz
    001 F Feijão
    002 L Leite
    002 C carne

Join -> Cliente e Pedido

    001 001 A
    001 001 F
    001 002 L
    001 002 C
    002 001 A
    002 001 F
    002 002 L
    002 002 C

Como você pode notar, como resultado temos pedidos realizados pelo cliente 001 e temos pedidos não realizados pelo cliente 001, mas que fazem parte do resultado. A mesma coisa vale para o cliente 002. Esses dados não estão íntegros e para que eles representem a realidade das nossas informações é necessário incluir o campo de "RELACIONAMENTO" das tabelas, no cado o "ID_Cliente".

Join Cliente e Pedido ON Cliente.ID_Cliente = Pedido.ID_Cliente

    001 001 A
    001 001 F
    002 002 L
    002 002 C

Nesse caso o ON é uma parte do comando que avisa por qual/quais campo(s) o JOIN deve relacionar as tabelas.

Em relação ao HAVING ele é uma condição para o GROUP BY enquanto o Where é uma condição para uma tupla (Regitros)

Exemplo; Listar todos os departamentos da filial RJ, cuja soma dos salários sejam maior que 50000

    Select  DEPARTAMENTO, SUM(SALARIO)
    From tabela
    Where FILIAL = 'RJ'
    Group by DEPARTAMENTO
    Having (sum(SALARIO)>50000))

Espero ter ajudado um pouco!.