De cuando me cuestioné qué era un join

En el artículo anterior hablé sobre un ejercicio de self joins que alteró mi percepción de la realidad.

Después de haber atravesado un valle de la desesperación por algunos meses y en un pequeño impulso obsesivo, regresé a dar clases para un alumno muy mono que precisamente me pidió apoyo para aprender SQL.

En este camino de enseñanza pude por fin vislumbrar todo aquello que estaba perdiendo de vista en aquel lejano marzo cuando decidí que era momento de desempolvar mis habilidades sqlonas.

El origen de las cosas

Todo comenzó a finales de los años 60s cuando un señor llamado Ted Codd andaba bien desquehacerada y decidió que era buena idea utilizar la teoría de conjuntos para construir una forma nueva de organizar la información y consultarla.

Así nació el modelo relacional y el álgebra relacional.

El álgebra relacional tiene algunas operaciones fundamentales como la selección, la proyección, el renombramiento, el producto cartesiano, la unión y la diferencia.

El modelo, por su parte, plantea que la información se debe de almacenar en relaciones que están conformadas por tuplas y atributos.

El álgebra toma una relación y hace la operación sobre ella, dándonos como resultado otra relación.

En algún momento podré hablar con más detalles sobre cada uno de ellos.

Aquí lo que nos importa es el producto cartesiano, que es una operación que combina dos o más conjuntos para generar uno nuevo.

Producto cartesiano

Sean A = {a,b,c,d} y X={x,y,z,w}

Un producto cartesiano se define como A x X, donde cada elemento de A, se multiplica o se concatena con cada uno de los elementos de X.

Es parecida a la propiedad distributiva de los números reales, donde a(b+c)= (ab) + (ac). En este caso, la suma entre una multiplicación y otra es una unión, es decir, es una fila que se pega verticalmente a la tabla. Y la multiplicación en sí misma es una concatenación, es decir, una fila se pega a la otra fila horizontalmente.

Así, AxX={(a,x) U (a,y) U (a,z) U (a,w) U (b,x) U (b,y) U (b,z) U (b,w) U (c,x) U (c,y) U (c,z) U (c,w) U (d,x) U (d,y) U (d,z) U (d,w)}

El total de filas resultantes se da a través de multiplicar NfilasA x NfilasX = 16 filas.

JOINS

Un join, como su nombre lo dice, es una unión entre dos tablas. La unión se hace con base en el tipo de join que estemos haciendo y en la mayoría de los casos se establece una condición que debe cumplirse a la hora de generar la tabla unida.

Tenemos varios tipos de joins: INNER, LEFT, RIGHT, FULL OUTER, CROSS, NATURAL.

El comportamiento de cada uno se explica nuevamente a través de las operaciones entre conjuntos.

Los primeros cuatro joins necesitan de una condición para llevar a cabo la unión, los últimos dos no.

¿Cómo se llevan a cabo entonces?

Bueno, la primera cláusula que se ejecuta es FROM, de donde sacamos la tabla con la que vamos a trabajar. Aquí establecemos en el FROM que la tabla que vamos a trabajar se va a generar después de unir las dos tablas que le estamos diciendo a partir de una condición.

Por la parte de atrás, SQL lleva a cabo un producto cartesiano entre las dos tablas. Una vez generado ese resultado, SQL va a tomar el tipo de join y va a evaluar la condición de unión para saber qué filas se quedan después del filtrado y cuáles se descartan. También determina la manera en la que aparecen los datos. Por ejemplo, en un INNER, SQL solamente tomará aquellas filas de ambas tablas que cumplan la condición y no hay necesidad de hacer nada más.

Por otro lado, los OUTER tomarán todas las filas de uno o ambos lados de la unión, cumplan o no la condición y para los LEFT y RIGHT traerá las del lado contrario que obligatoriamente la cumplan. En estos casos sí hay que hacer un paso extra, ya que en el resultado de estos joins aparecerán valores NULL para cada columna que no cumpla la condición pero que haya sido seleccionada para estar en la tabla final.

Después de construir esta tabla, entonces se llevan a cabo las siguientes cláusulas del select por orden, pero suponiendo que no hay más, se llevará a cabo la cláusula SELECT para tomar únicamente las columnas que ahí estén definidas.

Conclusión

Pensar en conjuntos facilita la manera de entender cómo SQL lleva a cabo cada una de sus operaciones con los datos, lo que nos permite escribir consultas más eficientes, entender cómo el motor maneja los datos en memoria y generar salidas más significativas que nos puedan decir algo.