Desvendando a SQL � Parte 2

Demais posts desta s�rie:

Artigo do tipo Exemplos Pr�ticos
Recursos especiais neste artigo:
Artigo no estilo Curso Online.

Desvendando a SQL � Parte 2
Existe uma grande necessidade em bancos de dados relacionais de efetuar junç�es entre tabelas, seja para recuperar informaç�es que est�o �espalhadas� devido � normalizaç�o de dados, ou para sumarizar informaç�es para posterior geraç�o de relat�rios, mas o fato � que a junç�o entre tabelas � necess�ria e poder�amos dizer at� mesmo fundamental.

No entanto, este assunto causa um certo desconforto na maioria dos desenvolvedores de aplicativos que acessam bancos de dados relacionais.

O perfeito entendimento da sintaxe e sem�ntica da cl�usula JOIN em instruç�es SQL � fundamental para que se obtenha o melhor desempenho poss�vel ao recuperar dados de um bando de dados relacional.

Particularmente nesta segunda e �ltima parte deste artigo, ser�o abordadas as junç�es entre tabelas do tipo cross join, que resulta em um produto cartesiano, e tamb�m as junç�es do tipo self join, onde � feita a junç�o de uma tabela com ela mesma. Ao final apresento um pequeno estudo de caso onde utilizamos a junç�o entre tabelas para resolver um problema cotidiano.

A correta utilizaç�o desta t�cnica, al�m de facilitar muito a leitura e interpretaç�o da sem�ntica da consulta sendo executada, em v�rios casos pode oferecer um ganho de performance dependendo do grau de maturidade e intelig�ncia do sistema de gerenciamento de banco de dados relacional que se executa a consulta.

Em que situaç�o o tema � �til
Em muitos momentos � necess�rio efetuar junç�es entre tabelas para buscar dados relativos a determinada informaç�o. Em bancos de dados relacionais, a utilizaç�o da metodologia de normalizaç�o de dados � uma pr�tica comum, amplamente difundida e muito correta por�m, devido � normalizaç�o de dados, em muitos momentos � necess�rio efetuar junç�es entre tabelas para que se possa reconstruir uma informaç�o completa. � neste tipo de situaç�o que a correta utilizaç�o da junç�o entre tabelas na SQL se mostra bastante �til.

No primeiro artigo desta s�rie apresentamos quest�es importantes com relaç�o � utilizaç�o da cl�usula WHERE para efetuar junç�es entre tabelas (muitas vezes necess�rias por conta do uso de pr�ticas de normalizaç�o na definiç�o da base de dado (ler Box 1)). Sem d�vida nenhuma � a maneira mais utilizada entre os desenvolvedores de aplicaç�es.

A grande maioria dos sistemas de gerenciamento de bancos de dados relacionais j� adquiriram �intelig�ncia� suficiente para interpretar este tipo de implementaç�o e �converter� implicitamente em junç�es para poder elaborar os planos de execuç�o de maneira a obter o melhor desempenho poss�vel.

Mas infelizmente n�o podemos garantir que cem por cento dos sistemas de gerenciamento de bancos de dados relacionais possuem esta �intelig�ncia�, o que pode ocasionar em consultas com desempenho muito aqu�m do desejado.

A utilizaç�o da cl�usula JOIN resolve completamente este problema, pois ela foi criada exatamente para a finalidade de efetuar junç�es.

Outro fator que tamb�m se apresenta como muito importante para que utilizemos a cl�usula JOIN � a facilidade de visualizaç�o do c�digo da consulta. Entenda esta facilidade no tocante a manutenç�o, pois � muito mais f�cil analisar uma consulta com cada componente no seu devido lugar (junç�es na cl�usula JOIN e predicados na cl�usula WHERE) do que uma consulta onde tudo est� na cl�usula WHERE e ser� necess�rio uma an�lise mais detalhada para �separar o joio do trigo�.

E vamos combinar: a utilizaç�o da cl�usula JOIN deixa a consulta muito mais elegante.

As junç�s apresentadas no primeiro artigo foram:

� Inner join:

o Equi-join e Non Equi-join;

o Natural join;

� Outer join:

o Left outer joins;

o Right outer join;

o Full outer join.

Por�m, esta n�o s�o as �nicas maneiras de efetuar junç�es entre tabelas. H� tamb�m:

� Cross Joins: (ou junç�es cruzadas) s�o junç�es onde a condiç�o de junç�o � omitida, ou seja, cada linha de uma tabela � combinada com cada linha de uma outra tabela. O resultado deste tipo de junç�o � conhedico como produto cartesiano;

� Self Joins: (ou auto-junç�o) s�o junç�es de uma tabela com ela mesma.

E para tornar esta artigo mais completo, abordarei tamb�m os algor�tmos de junç�o:

� Nested Loop Join (ou junç�o de loop aninhado): � um algoritmo que une dois conjuntos usando dois loops aninhados;

� Block Nested Loop (ou loop de bloco aninhado): � uma variaç�o do algoritmo nested loop;

� Sort-Merge Join: (ou junç�o do tipo fus�o): a ideia principal deste algoritmo � primeiro classificar as relaç�es pelo atributo de junç�o e, desta forma, as varreduras lineares intercaladas encontrar�o os registros ao mesmo tempo;

� Hash Join (ou junç�o hash): este algoritmo necessita que haja um predicado de equi-join, ou seja, um predicado usado para comparar os valores de uma tabela com os valores da outra tabela usando o operador igual �=�.

Box 1. Normalizaç�o de Dados

Normalizaç�o de Dados � o processo de organizaç�o dos campos e tabelas de um banco de dados relacional para minimizar a redund�ncia e depend�ncia. Normalizaç�o normalmente envolve a divis�o tabelas grandes em tabelas menores (e menos redundantes) e definindo as relaç�es entre elas. O objetivo � isolar os dados de modo que as inserç�es, exclus�es e alteraç�es de campos possam ser feitas em apenas uma tabela e ent�o propagadas atrav�s da base de dados utilizando os relacionamentos definidos.

Edgar F. Codd, o inventor do modelo relacional, introduziu o conceito de normalizaç�o que hoje conhecemos como a Primeira Forma Normal (1FN, ou 1NF � First Normal Form) em 1970. Codd ent�o definiu a Segunda Forma Normal (2FN, ou 2NF � Second Normal Form) e a Terceira Forma Normal (3FN, ou 3NF � Third Normal Form) em 1971, e Codd e Raymond F. Boyce definiram a Forma Normal de Boyce-Codd (BCNF � Boyce-Codd Normal Form), em 1974.

Informalmente, uma tabela de banco de dados relacional � frequentemente descrita como "normalizada" se est� na Terceira Forma Normal e a grande maioria das tabelas na 3FN s�o livres de anomalias tanto para inserç�o quanto para atualizaç�o ou exclus�o.

A orientaç�o padr�o de projeto de banco de dados � que o Arquiteto de Dados deve criar um modelo totalmente normalizado. Uma eventual desnormalizaç�o seletiva pode, posteriormente, ser realizada por motivos de desempenho.

Um objetivo b�sico da Primeira Forma Normal, definida por Codd, em 1970, foi o de permitir que os dados sejam consultados e manipulados usando uma "sub-linguagem universal de dados", fundamentada na l�gica de primeira ordem (SQL � um exemplo deste tipo de sub-linguagem universal de dados, ainda que Codd a considerava como falha).

Os objetivos da normalizaç�o al�m Primeira Forma Normal foram definidos por Codd da seguinte forma:

1) Para libertar a coleç�o de relacionamentos de indesej�veis depend�ncias de inserç�es, atualizaç�es e exclus�es;

2) Para reduzir a necessidade de reestruturar a coleç�o de relacionamentos, por serem introduzidos novos tipos de dados e, assim, aumentar a vida �til dos programas aplicativos;

3) Para tornar o modelo relacional mais informativo para os usu�rios;

4) Para fazer a coleç�o de relacionamentos neutra com as estat�sticas de consulta, onde estas estat�sticas s�o suscet�veis de mudança � medida que o tempo passa.

Cross Join / Produto Cartesiano

Caso n�o seja especificada a condiç�o de junç�o na uni�o de duas tabelas, o SGBDR combina cada linha da primeira tabela com cada linha da segunda tabela. Este tipo de junç�o � chamada de cross join ou produto cartesiano, ambos os termos est�o corretos. O n�mero de linhas de uma cross join � o produto do n�mero de linhas em cada tabela. A Listagem 1 apresenta um exemplo de uma cross join.

Listagem 1. Cross join entre as tabelas FUNCIONARIOS e DEPARTAMENTOS.01. SQL> SELECT F.NOME||' '||F.SOBRENOME FUNCIONARIO, D.NOME_DEPTO 02. 2 FROM FUNCIONARIOS F 03. 3 CROSS JOIN DEPARTAMENTOS D; 04. 05. FUNCIONARIO NOME_DEPTO 06. ----------------------------------------- ------------------------- 07. Ricardo Rezende Vendas 08. Joao da Silva Vendas 09. Leonardo Souza Vendas 10. Rafaela Bastos Vendas 11. Felipe Carvalho Vendas 12. Olavo Santos Vendas 13. Samantha Xavier Vendas 14. Paulo Ferreira Vendas 15. Manoel Vargas Vendas 16. USjpT USjpT Vendas 17. L L Vendas 18. yevi yevi Vendas 19. kGuOBF kGuOBF Vendas 20. ... 21. ... 22. Ricardo Rezende Recursos Humanos 23. Joao da Silva Recursos Humanos 24. Leonardo Souza Recursos Humanos 25. Rafaela Bastos Recursos Humanos 26. Felipe Carvalho Recursos Humanos 27. Olavo Santos Recursos Humanos 28. Samantha Xavier Recursos Humanos 29. Paulo Ferreira Recursos Humanos 30. Manoel Vargas Recursos Humanos 31. USjpT USjpT Recursos Humanos 32. L L Recursos Humanos 33. yevi yevi Recursos Humanos 34. kGuOBF kGuOBF Recursos Humanos 35. ... 36. ... 37. Ricardo Rezende Engenharia 38. Joao da Silva Engenharia 39. Leonardo Souza Engenharia 40. Rafaela Bastos Engenharia 41. Felipe Carvalho Engenharia 42. Olavo Santos Engenharia 43. Samantha Xavier Engenharia 44. Paulo Ferreira Engenharia 45. Manoel Vargas Engenharia 46. USjpT USjpT Engenharia 47. L L Engenharia 48. yevi yevi Engenharia 49. kGuOBF kGuOBF Engenharia 50. ... 51. ... 52. Ricardo Rezende Tecnologia de Informacao 53. Joao da Silva Tecnologia de Informacao 54. Leonardo Souza Tecnologia de Informacao 55. Rafaela Bastos Tecnologia de Informacao 56. Felipe Carvalho Tecnologia de Informacao 57. Olavo Santos Tecnologia de Informacao 58. Samantha Xavier Tecnologia de Informacao 59. Paulo Ferreira Tecnologia de Informacao 60. Manoel Vargas Tecnologia de Informacao 61. USjpT USjpT Tecnologia de Informacao 62. L L Tecnologia de Informacao 63. yevi yevi Tecnologia de Informacao 64. kGuOBF kGuOBF Tecnologia de Informacao 65. ... 66. ... 67. Ricardo Rezende Compras 68. Joao da Silva Compras 69. Leonardo Souza Compras 70. Rafaela Bastos Compras 71. Felipe Carvalho Compras 72. Olavo Santos Compras 73. Samantha Xavier Compras 74. Paulo Ferreira Compras 75. Manoel Vargas Compras 76. USjpT USjpT Compras 77. L L Compras 78. yevi yevi Compras 79. kGuOBF kGuOBF Compras 80. ... 81. ... 82. Ricardo Rezende Estoque 83. Joao da Silva Estoque 84. Leonardo Souza Estoque 85. Rafaela Bastos Estoque 86. Felipe Carvalho Estoque 87. Olavo Santos Estoque 88. Samantha Xavier Estoque 89. Paulo Ferreira Estoque 90. Manoel Vargas Estoque 91. USjpT USjpT Estoque 92. L L Estoque 93. yevi yevi Estoque 94. kGuOBF kGuOBF Estoque 95. ... 96. ... 97. Ricardo Rezende XAgXTHmlAwVnDyS 98. Joao da Silva XAgXTHmlAwVnDyS 99. Leonardo Souza XAgXTHmlAwVnDyS 100. Rafaela Bastos XAgXTHmlAwVnDyS 101. Felipe Carvalho XAgXTHmlAwVnDyS 102. Olavo Santos XAgXTHmlAwVnDyS 103. Samantha Xavier XAgXTHmlAwVnDyS 104. Paulo Ferreira XAgXTHmlAwVnDyS 105. Manoel Vargas XAgXTHmlAwVnDyS 106. USjpT USjpT XAgXTHmlAwVnDyS 107. L L XAgXTHmlAwVnDyS 108. yevi yevi XAgXTHmlAwVnDyS 109. kGuOBF kGuOBF XAgXTHmlAwVnDyS 110. ... 111. ... 112. buusBIVQCauztX buusBIVQCauztX HkMmQjyagGhWVzReRFdloD 113. IKfvhGpWW IKfvhGpWW HkMmQjyagGhWVzReRFdloD 114. eiOXs eiOXs HkMmQjyagGhWVzReRFdloD 115. Q Q HkMmQjyagGhWVzReRFdloD 116. jbYJVRMVhUI jbYJVRMVhUI HkMmQjyagGhWVzReRFdloD 117. bFL bFL HkMmQjyagGhWVzReRFdloD 118. AOu AOu HkMmQjyagGhWVzReRFdloD 119. KwveCIxJpDWxMpsdF KwveCIxJpDWxMpsdF HkMmQjyagGhWVzReRFdloD 120. 121. 2144754 rows selected. 122. 123. Elapsed: 00:03:22.79"

[...] continue lendo...

Desvendando a SQL � Parte 2

Neste artigo serão abordadas as junções entre tabelas do tipo cross join, que resulta em um produto cartesiano, e também as junções do tipo self join, onde é feita a junção de uma tabela com ela mesma.

Artigos relacionados