Una cláusula de unión en el lenguaje de consulta estructurado ( SQL ) combina columnas de una o más tablas en una nueva tabla. La operación corresponde a una operación de unión en álgebra relacional . De manera informal , una unión une dos tablas y coloca en la misma fila los registros con campos coincidentes: INNER, LEFT OUTER, y .RIGHT OUTERFULL OUTERCROSS
Para explicar los tipos de unión, el resto de este artículo utiliza las siguientes tablas:
Department.DepartmentIDes la clave principal de la Departmenttabla, mientras que Employee.DepartmentIDes una clave externa .
Tenga en cuenta que en Employee, "Williams" aún no ha sido asignado a un departamento. Además, ningún empleado ha sido asignado al departamento de "Marketing".
Estas son las sentencias SQL para crear las tablas anteriores:
CREAR TABLA departamento ( DepartmentID INT CLAVE PRIMARIA NO NULO , NombreDepartamento VARCHAR ( 20 ) );CREAR TABLA empleado ( Apellido VARCHAR ( 20 ), DepartmentID INT REFERENCIAS departamento ( DepartmentID ) );INSERTAR EN el departamento VALORES ( 31 , 'Ventas' ), ( 33 , 'Ingeniería' ), ( 34 , 'Clerical' ), ( 35 , 'Marketing' ); INSERTAR EN empleado VALORES ( 'Rafferty' , 31 ), ( 'Jones' , 33 años ), ( 'Heisenberg' , 33 ), ( 'Robinson' , 34 años ), ( 'Smith' , 34 ), ( 'Williams' , NULO ); CROSS JOINdevuelve el producto cartesiano de las filas de las tablas en la unión. En otras palabras, producirá filas que combinen cada fila de la primera tabla con cada fila de la segunda tabla. [1]
Ejemplo de una unión cruzada explícita:
SELECCIONAR * DE empleado CROSS JOIN departamento ; Ejemplo de una unión cruzada implícita:
SELECCIONAR * DE empleado , departamento ; La unión cruzada se puede reemplazar con una unión interna con una condición siempre verdadera:
SELECCIONAR * DE empleado INNER JOIN departamento ON 1 = 1 ; CROSS JOINno aplica ningún predicado para filtrar filas de la tabla unida. Los resultados de una operación CROSS JOINse pueden filtrar mediante una WHEREcláusula, que puede producir el equivalente de una unión interna.
En el estándar SQL:2011 , las uniones cruzadas son parte del paquete opcional F401, "Tabla unida extendida".
Los usos normales son para comprobar el rendimiento del servidor. [ ¿Por qué? ]
Una unión interna (o join ) requiere que cada fila de las dos tablas unidas tenga valores de columna coincidentes y es una operación de unión que se usa comúnmente en las aplicaciones, pero no se debe asumir que sea la mejor opción en todas las situaciones. La unión interna crea una nueva tabla de resultados combinando los valores de las columnas de dos tablas (A y B) según el predicado de unión. La consulta compara cada fila de A con cada fila de B para encontrar todos los pares de filas que satisfacen el predicado de unión. Cuando el predicado de unión se satisface al coincidir valores distintos de NULL , los valores de las columnas de cada par de filas coincidentes de A y B se combinan en una fila de resultados.
El resultado de la unión se puede definir como el resultado de tomar primero el producto cartesiano (o unión cruzada) de todas las filas de las tablas (combinando cada fila de la tabla A con cada fila de la tabla B) y luego devolver todas las filas que satisfacen el predicado de la unión. Las implementaciones de SQL reales normalmente utilizan otros enfoques, como uniones hash o uniones de ordenación y fusión , ya que calcular el producto cartesiano es más lento y, a menudo, requeriría una cantidad prohibitivamente grande de memoria para almacenarlo.
SQL especifica dos formas sintácticas diferentes de expresar uniones: la "notación de unión explícita" y la "notación de unión implícita". La "notación de unión implícita" ya no se considera una práctica recomendada [¿ por quién? ] , aunque los sistemas de bases de datos aún la admiten.
La "notación de unión explícita" utiliza la JOINpalabra clave, opcionalmente precedida por la INNERpalabra clave, para especificar la tabla a unir, y la ONpalabra clave para especificar los predicados para la unión, como en el siguiente ejemplo:
SELECT empleado . Apellido , empleado . IDDepartamento , departamento . NombreDepartamento FROM empleado INNER JOIN departamento ON empleado . IDDepartamento = departamento . IDDepartamento ; La "notación de unión implícita" simplemente enumera las tablas que se unirán en la FROMcláusula de la SELECTdeclaración, utilizando comas para separarlas. Por lo tanto, especifica una unión cruzada y la WHEREcláusula puede aplicar predicados de filtro adicionales (que funcionan de manera comparable a los predicados de unión en la notación explícita).
El siguiente ejemplo es equivalente al anterior, pero esta vez utilizando notación de unión implícita:
SELECCIONAR empleado . Apellido , empleado . IDDepartamento , departamento . NombreDepartamento DE empleado , departamento DONDE empleado . IDDepartamento = departamento . IDDepartamento ; Las consultas dadas en los ejemplos anteriores unirán las tablas Employee y department utilizando la columna DepartmentID de ambas tablas. Cuando el DepartmentID de estas tablas coincida (es decir, se cumpla el predicado de unión), la consulta combinará las columnas LastName , DepartmentID y DepartmentName de las dos tablas en una fila de resultados. Cuando el DepartmentID no coincida, no se generará ninguna fila de resultados.
Por lo tanto el resultado de la ejecución de la consulta anterior será:
El empleado "Williams" y el departamento "Marketing" no aparecen en los resultados de la ejecución de la consulta. Ninguno de ellos tiene filas coincidentes en la otra tabla respectiva: "Williams" no tiene un departamento asociado y ningún empleado tiene el ID de departamento 35 ("Marketing"). Según los resultados deseados, este comportamiento puede ser un error sutil, que se puede evitar reemplazando la unión interna por una unión externa.
Los programadores deben tener especial cuidado al unir tablas en columnas que pueden contener valores NULL , ya que NULL nunca coincidirá con ningún otro valor (ni siquiera NULL en sí), a menos que la condición de unión use explícitamente un predicado de combinación que primero verifique que las columnas de unión lo sean NOT NULLantes de aplicar las condiciones de predicado restantes. La unión interna solo se puede usar de manera segura en una base de datos que aplique integridad referencial o donde se garantice que las columnas de unión no sean NULL. Muchas bases de datos relacionales de procesamiento de transacciones se basan en estándares de actualización de datos de atomicidad, consistencia, aislamiento y durabilidad (ACID) para garantizar la integridad de los datos, lo que hace que las uniones internas sean una opción adecuada. Sin embargo, las bases de datos de transacciones generalmente también tienen columnas de unión deseables que pueden ser NULL. Muchas bases de datos relacionales de informes y almacenes de datos utilizan actualizaciones por lotes de extracción, transformación y carga (ETL) de alto volumen que hacen que la integridad referencial sea difícil o imposible de aplicar, lo que da como resultado columnas de unión potencialmente NULL que un autor de consultas SQL no puede modificar y que hacen que las uniones internas omitan datos sin indicación de un error. La elección de usar una unión interna depende del diseño de la base de datos y las características de los datos. Generalmente, una unión externa izquierda se puede sustituir por una unión interna cuando las columnas unidas en una tabla pueden contener valores NULL.
Cualquier columna de datos que pueda ser NULL (vacía) nunca debe usarse como enlace en una unión interna, a menos que el resultado deseado sea eliminar las filas con el valor NULL. Si las columnas de unión NULL se deben eliminar deliberadamente del conjunto de resultados , una unión interna puede ser más rápida que una unión externa porque la unión de la tabla y el filtrado se realizan en un solo paso. Por el contrario, una unión interna puede resultar en un rendimiento desastrosamente lento o incluso un bloqueo del servidor cuando se usa en una consulta de gran volumen en combinación con funciones de base de datos en una cláusula Where de SQL. [2] [3] [4] Una función en una cláusula Where de SQL puede hacer que la base de datos ignore índices de tabla relativamente compactos. La base de datos puede leer y unir internamente las columnas seleccionadas de ambas tablas antes de reducir la cantidad de filas usando el filtro que depende de un valor calculado, lo que resulta en una cantidad relativamente enorme de procesamiento ineficiente.
Cuando se genera un conjunto de resultados mediante la unión de varias tablas, incluidas las tablas maestras que se utilizan para buscar descripciones de texto completo de códigos de identificadores numéricos (una tabla de búsqueda ), un valor NULL en cualquiera de las claves externas puede provocar que se elimine toda la fila del conjunto de resultados, sin ninguna indicación de error. Una consulta SQL compleja que incluye una o más uniones internas y varias uniones externas tiene el mismo riesgo de valores NULL en las columnas de vínculo de unión interna.
Un compromiso con el código SQL que contiene uniones internas supone que no se introducirán columnas de unión NULL mediante cambios futuros, incluidas actualizaciones de proveedores, cambios de diseño y procesamiento masivo fuera de las reglas de validación de datos de la aplicación, como conversiones de datos, migraciones, importaciones masivas y fusiones.
Las uniones internas se pueden clasificar además como uniones equitativas, uniones naturales o uniones cruzadas.
Una unión equitativa es un tipo específico de unión basada en un comparador que utiliza solo comparaciones de igualdad en el predicado de unión. El uso de otros operadores de comparación (como <) descalifica una unión como una unión equitativa. La consulta que se muestra arriba ya ha proporcionado un ejemplo de una unión equitativa:
SELECCIONAR * DE empleado UNIRSE al departamento EN empleado . DepartmentID = departamento . DepartmentID ; Podemos escribir equi-join como se muestra a continuación:
SELECCIONAR * DE empleado , departamento DONDE empleado . DepartmentID = departamento . DepartmentID ; Si las columnas de una unión equitativa tienen el mismo nombre, SQL-92 proporciona una notación abreviada opcional para expresar uniones equitativas, mediante la USINGconstrucción: [5]
SELECCIONAR * DE empleado UNIR INTERNAMENTAL departamento USANDO ( DepartamentoID ) ; Sin embargo, la USINGconstrucción es más que un simple complemento sintáctico , ya que el conjunto de resultados difiere del conjunto de resultados de la versión con el predicado explícito. Específicamente, cualquier columna mencionada en la USINGlista aparecerá solo una vez, con un nombre no calificado, en lugar de una vez para cada tabla en la unión. En el caso anterior, habrá una sola DepartmentIDcolumna y ningún employee.DepartmentIDor department.DepartmentID.
La USINGcláusula no es compatible con MS SQL Server y Sybase.
La unión natural es un caso especial de unión equitativa. La unión natural (⋈) es un operador binario que se escribe como ( R ⋈ S ) donde R y S son relaciones . [6] El resultado de la unión natural es el conjunto de todas las combinaciones de tuplas en R y S que son iguales en sus nombres de atributos comunes. Como ejemplo, considere las tablas Employee y Dept y su unión natural:
Esto también se puede utilizar para definir la composición de las relaciones . Por ejemplo, la composición de Employee y Dept es su unión, como se muestra arriba, proyectada sobre todos los atributos excepto el común DeptName . En la teoría de categorías , la unión es precisamente el producto de la fibra .
La unión natural es posiblemente uno de los operadores más importantes, ya que es la contraparte relacional del AND lógico. Tenga en cuenta que si la misma variable aparece en cada uno de los dos predicados que están conectados por AND, entonces esa variable representa lo mismo y ambas apariciones siempre deben sustituirse por el mismo valor. En particular, la unión natural permite la combinación de relaciones que están asociadas por una clave externa . Por ejemplo, en el ejemplo anterior, una clave externa probablemente se cumple desde Employee.DeptName hasta Dept.DeptName y luego la unión natural de Employee y Dept combina todos los empleados con sus departamentos. Esto funciona porque la clave externa se cumple entre atributos con el mismo nombre. Si este no es el caso, como en la clave externa de Dept.manager hasta Employee.Name , entonces estas columnas deben renombrarse antes de que se realice la unión natural. A este tipo de unión a veces también se la conoce como equi - join .
Más formalmente, la semántica de la unión natural se define de la siguiente manera:
donde Fun es un predicado que es verdadero para una relación r si y solo si r es una función. Generalmente se requiere que R y S tengan al menos un atributo común, pero si se omite esta restricción y R y S no tienen atributos comunes, entonces la unión natural se convierte exactamente en el producto cartesiano.
La unión natural se puede simular con las primitivas de Codd de la siguiente manera. Sean c 1 , ..., c m los nombres de atributos comunes a R y S , r 1 , ..., r n los nombres de atributos únicos a R y sean s 1 , ..., s k los atributos únicos a S . Además, supongamos que los nombres de atributos x 1 , ..., x m no están ni en R ni en S . En un primer paso, los nombres de atributos comunes en S ahora se pueden renombrar:
Luego tomamos el producto cartesiano y seleccionamos las tuplas que se van a unir:
Una unión natural es un tipo de unión equitativa en la que el predicado de unión surge de manera implícita al comparar todas las columnas de ambas tablas que tienen los mismos nombres de columna en las tablas unidas. La tabla unida resultante contiene solo una columna por cada par de columnas con el mismo nombre. En el caso de que no se encuentren columnas con los mismos nombres, el resultado es una unión cruzada .
La mayoría de los expertos coinciden en que las uniones naturales son peligrosas y, por lo tanto, desaconsejan enérgicamente su uso. [7] El peligro surge de añadir inadvertidamente una nueva columna, con el mismo nombre que otra columna de la otra tabla. Una unión natural existente podría entonces utilizar "naturalmente" la nueva columna para comparaciones, haciendo comparaciones/coincidencias utilizando criterios diferentes (de columnas diferentes) que antes. Por lo tanto, una consulta existente podría producir resultados diferentes, aunque los datos de las tablas no se hayan modificado, sino solo aumentado. El uso de nombres de columnas para determinar automáticamente los vínculos de las tablas no es una opción en bases de datos grandes con cientos o miles de tablas, donde impondría una restricción poco realista a las convenciones de nombres. Las bases de datos del mundo real suelen estar diseñadas con datos de clave externa que no se rellenan de forma coherente (se permiten valores NULL), debido a las reglas comerciales y al contexto. Es una práctica común modificar los nombres de las columnas de datos similares en diferentes tablas y esta falta de coherencia rígida relega las uniones naturales a un concepto teórico para su discusión.
La consulta de muestra anterior para uniones internas se puede expresar como una unión natural de la siguiente manera:
SELECCIONAR * DE empleado NATURAL UNIRSE departamento ; Al igual que con la cláusula explícita USING, solo aparece una columna DepartmentID en la tabla unida, sin ningún calificador:
PostgreSQL, MySQL y Oracle admiten uniones naturales; Microsoft T-SQL e IBM DB2 no. Las columnas utilizadas en la unión son implícitas, por lo que el código de unión no muestra qué columnas se esperan y un cambio en los nombres de las columnas puede cambiar los resultados. En el estándar SQL:2011 , las uniones naturales forman parte del paquete opcional F401, "Tabla unida extendida".
En muchos entornos de bases de datos, los nombres de las columnas están controlados por un proveedor externo, no por el desarrollador de consultas. Una unión natural supone estabilidad y coherencia en los nombres de las columnas, que pueden cambiar durante las actualizaciones de versión exigidas por el proveedor.
La tabla unida conserva cada fila, incluso si no existe ninguna otra fila coincidente. Las uniones externas se subdividen en uniones externas izquierdas, uniones externas derechas y uniones externas completas, según las filas de la tabla que se conservan: izquierda, derecha o ambas (en este caso, izquierda y derecha se refieren a los dos lados de la JOINpalabra clave). Al igual que las uniones internas, se pueden subcategorizar todos los tipos de uniones externas como uniones equi, uniones naturales, ( θ -join ), etc. [8]ON <predicate>
No existe una notación de unión implícita para uniones externas en SQL estándar.
El resultado de una unión externa izquierda (o simplemente unión izquierda ) para las tablas A y B siempre contiene todas las filas de la tabla "izquierda" (A), incluso si la condición de unión no encuentra ninguna fila coincidente en la tabla "derecha" (B). Esto significa que si la ONcláusula coincide con 0 (cero) filas en B (para una fila dada en A), la unión devolverá una fila en el resultado (para esa fila), pero con NULL en cada columna de B. Una unión externa izquierda devuelve todos los valores de una unión interna más todos los valores en la tabla izquierda que no coinciden con la tabla derecha, incluidas las filas con valores NULL (vacíos) en la columna de enlace.
Por ejemplo, esto nos permite encontrar el departamento de un empleado, pero aún muestra los empleados que no han sido asignados a un departamento (al contrario del ejemplo de unión interna anterior, donde los empleados no asignados fueron excluidos del resultado).
Ejemplo de una unión externa izquierda (la OUTERpalabra clave es opcional), con la fila de resultado adicional (en comparación con la unión interna) en cursiva:
SELECCIONAR * DE empleado UNIÓN EXTERNA IZQUIERDA departamento EN empleado . DepartmentID = departamento . DepartmentID ; Oracle admite la sintaxis obsoleta [9] :
SELECT * FROM empleado , departamento DONDE empleado . DepartmentID = departamento . DepartmentID ( + ) Sybase admite la sintaxis ( Microsoft SQL Server dejó obsoleta esta sintaxis desde la versión 2000):
SELECT * FROM empleado , departamento DONDE empleado . DepartmentID *= departamento . DepartmentID IBM Informix admite la sintaxis:
SELECCIONAR * DE empleado , EXTERIOR departamento DONDE empleado . DepartmentID = departamento . DepartmentID 
Una unión externa derecha (o unión derecha ) se parece mucho a una unión externa izquierda, excepto que el tratamiento de las tablas se invierte. Cada fila de la tabla "derecha" (B) aparecerá en la tabla unida al menos una vez. Si no existe ninguna fila coincidente de la tabla "izquierda" (A), aparecerá NULL en las columnas de A para aquellas filas que no tengan coincidencia en B.
Una unión externa derecha devuelve todos los valores de la tabla derecha y los valores coincidentes de la tabla izquierda (NULL en el caso de que no haya ningún predicado de unión coincidente). Por ejemplo, esto nos permite encontrar a cada empleado y su departamento, pero aún así mostrar los departamentos que no tienen empleados.
A continuación se muestra un ejemplo de una unión externa derecha (la OUTERpalabra clave es opcional), con la fila de resultado adicional en cursiva:
SELECCIONAR * DE empleado UNIÓN EXTERNA DERECHA departamento EN empleado . DepartmentID = departamento . DepartmentID ; Las uniones externas derechas e izquierdas son funcionalmente equivalentes. Ninguna proporciona una funcionalidad que la otra no tenga, por lo que las uniones externas derechas e izquierdas pueden reemplazarse entre sí siempre que se cambie el orden de la tabla.
En teoría, una unión externa completa combina el efecto de aplicar uniones externas izquierdas y derechas. Cuando las filas de las tablas unidas externamente no coinciden, el conjunto de resultados tendrá valores NULL para cada columna de la tabla que no tenga una fila coincidente. Para aquellas filas que coincidan, se producirá una sola fila en el conjunto de resultados (que contiene columnas rellenadas con datos de ambas tablas).
Por ejemplo, esto nos permite ver cada empleado que está en un departamento y cada departamento que tiene un empleado, pero también ver cada empleado que no es parte de un departamento y cada departamento que no tiene un empleado.
Ejemplo de una unión externa completa (la OUTERpalabra clave es opcional):
SELECCIONAR * DE empleado UNIÓN EXTERNA COMPLETA departamento EN empleado . DepartmentID = departamento . DepartmentID ; Algunos sistemas de bases de datos no admiten directamente la funcionalidad de unión externa completa, pero pueden emularla mediante el uso de una unión interna y selecciones UNION ALL de las "filas de tabla individuales" de las tablas izquierda y derecha respectivamente. El mismo ejemplo puede aparecer de la siguiente manera:
SELECT empleado . Apellido , empleado . IdDepartamento , departamento . NombreDepartamento , departamento . IdDepartamento FROM empleado INNER JOIN departamento ON empleado . IdDepartamento = departamento . IdDepartamento UNIÓN TODOS SELECT empleado . Apellido , empleado . IdDepartamento , cast ( NULL como varchar ( 20 )), cast ( NULL como entero ) FROM empleado DONDE NO EXISTE ( SELECT * FROM departamento DONDE empleado . IdDepartamento = departamento . IdDepartamento ) UNIÓN TODOS SELECT cast ( NULL como varchar ( 20 )), cast ( NULL como entero ), departamento . DepartmentName , departamento . DepartmentID FROM departamento DONDE NO EXISTE ( SELECT * FROM empleado DONDE empleado . DepartmentID = departamento . DepartmentID ) Otro enfoque podría ser UNIR TODO de la unión externa izquierda y la unión externa derecha MENOS la unión interna.
Una autounión es unir una tabla consigo misma. [10]
Si hubiera dos tablas separadas para empleados y una consulta que solicitara que los empleados de la primera tabla tengan el mismo país que los empleados de la segunda tabla, se podría utilizar una operación de unión normal para encontrar la tabla de respuestas. Sin embargo, toda la información de los empleados está contenida en una única tabla grande. [11]
Consideremos una Employeetabla modificada como la siguiente:
Un ejemplo de consulta de solución podría ser el siguiente:
SELECCIONAR F . EmployeeID , F . LastName , S . EmployeeID , S . LastName , F . Country FROM Employee F INNER JOIN Employee S ON F . Country = S . Country WHERE F . EmployeeID < S . EmployeeID ORDENAR POR F . EmployeeID , S . EmployeeID ; Lo que da como resultado la siguiente tabla generada.
Para este ejemplo:
Fy Sson alias para la primera y segunda copia de la tabla de empleados.F.Country = S.Countryexcluye los emparejamientos entre empleados de distintos países. La pregunta de ejemplo solo quería pares de empleados del mismo país.F.EmployeeID < S.EmployeeIDexcluye los emparejamientos en los que el EmployeeIDdel primer empleado es mayor o igual que el EmployeeIDdel segundo empleado. En otras palabras, el efecto de esta condición es excluir los emparejamientos duplicados y los autoemparejamientos. Sin ella, se generaría la siguiente tabla menos útil (la tabla siguiente muestra solo la parte "Alemania" del resultado):Sólo se necesita uno de los dos pares intermedios para satisfacer la pregunta original, y el superior y el inferior no tienen ningún interés en este ejemplo.
El efecto de una unión externa también se puede obtener utilizando una UNION ALL entre una INNER JOIN y una SELECT de las filas de la tabla "principal" que no cumplen la condición de unión. Por ejemplo,
SELECCIONAR empleado . Apellido , empleado . IDDepartamento , departamento . NombreDepartamento FROM empleado UNIÓN EXTERNA IZQUIERDA departamento ON empleado . IDDepartamento = departamento . IDDepartamento ; También se puede escribir como
SELECT empleado . Apellido , empleado . IdDepartamento , departamento . NombreDepartamento FROM empleado INNER JOIN departamento ON empleado . IdDepartamento = departamento . IdDepartamento UNIÓN TODOS SELECT empleado . Apellido , empleado . IdDepartamento , cast ( NULL como varchar ( 20 )) FROM empleado DONDE NO EXISTE ( SELECT * FROM departamento DONDE empleado . IdDepartamento = departamento . IdDepartamento ) Gran parte del trabajo en sistemas de bases de datos se ha centrado en la implementación eficiente de uniones, porque los sistemas relacionales suelen requerir uniones, pero enfrentan dificultades para optimizar su ejecución eficiente. El problema surge porque las uniones internas funcionan tanto de forma conmutativa como asociativa . En la práctica, esto significa que el usuario simplemente proporciona la lista de tablas para la unión y las condiciones de unión a utilizar, y el sistema de base de datos tiene la tarea de determinar la forma más eficiente de realizar la operación. Las opciones se vuelven más complejas a medida que aumenta el número de tablas involucradas en una consulta, y cada tabla tiene características diferentes en cuanto a recuento de registros, longitud promedio de registros (considerando campos NULL) e índices disponibles. Los filtros de cláusula Where también pueden afectar significativamente el volumen y el costo de las consultas.
Un optimizador de consultas determina cómo ejecutar una consulta que contiene uniones. Un optimizador de consultas tiene dos libertades básicas:
Muchos algoritmos de unión tratan sus entradas de forma diferente. Se puede hacer referencia a las entradas de una unión como operandos de unión "externos" e "internos", o "izquierdo" y "derecho", respectivamente. En el caso de bucles anidados, por ejemplo, el sistema de base de datos escaneará toda la relación interna en busca de cada fila de la relación externa.
Los planes de consulta que implican uniones se pueden clasificar de la siguiente manera: [12]
Estos nombres derivan de la apariencia del plan de consulta si se dibuja como un árbol , con la relación de unión externa a la izquierda y la relación interna a la derecha (como dicta la convención).
Existen tres algoritmos fundamentales para realizar una operación de unión binaria: unión de bucle anidado , unión de ordenación y fusión y unión hash . Los algoritmos de unión óptimos en el peor de los casos son asintóticamente más rápidos que los algoritmos de unión binaria para uniones entre más de dos relaciones en el peor de los casos .
Los índices de unión son índices de bases de datos que facilitan el procesamiento de consultas de unión en almacenes de datos : actualmente (2012) están disponibles en implementaciones de Oracle [14] y Teradata . [15]
En la implementación de Teradata, las columnas especificadas, las funciones de agregación en columnas o los componentes de las columnas de fecha de una o más tablas se especifican utilizando una sintaxis similar a la definición de una vista de base de datos : se pueden especificar hasta 64 columnas/expresiones de columna en un único índice de unión. Opcionalmente, también se puede especificar una columna que defina la clave principal de los datos compuestos: en hardware paralelo, los valores de columna se utilizan para particionar el contenido del índice en varios discos. Cuando los usuarios actualizan las tablas de origen de forma interactiva, el contenido del índice de unión se actualiza automáticamente. Cualquier consulta cuya cláusula WHERE especifique cualquier combinación de columnas o expresiones de columna que sean un subconjunto exacto de las definidas en un índice de unión (una llamada "consulta de cobertura") hará que se consulte el índice de unión, en lugar de las tablas originales y sus índices, durante la ejecución de la consulta.
La implementación de Oracle se limita a utilizar índices de mapa de bits . Un índice de unión de mapa de bits se utiliza para columnas de baja cardinalidad (es decir, columnas que contienen menos de 300 valores distintos, según la documentación de Oracle): combina columnas de baja cardinalidad de varias tablas relacionadas. El ejemplo que utiliza Oracle es el de un sistema de inventario, donde diferentes proveedores proporcionan diferentes piezas. El esquema tiene tres tablas vinculadas: dos "tablas maestras", Parte y Proveedor, y una "tabla de detalles", Inventario. La última es una tabla de varios a varios que vincula Proveedor a Parte y contiene la mayor cantidad de filas. Cada parte tiene un Tipo de Parte y cada proveedor tiene su sede en los EE. UU. y tiene una columna de Estado. No hay más de 60 estados + territorios en los EE. UU. y no más de 300 Tipos de Parte. El índice de unión de mapa de bits se define utilizando una unión de tres tablas estándar en las tres tablas anteriores y especificando las columnas Part_Type y Supplier_State para el índice. Sin embargo, se define en la tabla Inventario, aunque las columnas Part_Type y Supplier_State están "tomadas prestadas" de Proveedor y Parte respectivamente.
En cuanto a Teradata, un índice de unión de mapa de bits de Oracle solo se utiliza para responder una consulta cuando la cláusula WHERE de la consulta especifica columnas limitadas a aquellas que están incluidas en el índice de unión.
Algunos sistemas de bases de datos permiten al usuario forzar al sistema a leer las tablas de una unión en un orden determinado. Esto se utiliza cuando el optimizador de uniones elige leer las tablas en un orden ineficiente. Por ejemplo, en MySQL, el comando STRAIGHT_JOINlee las tablas exactamente en el orden indicado en la consulta. [16]