En el capítulo anterior de INNER JOIN varias tablas, vimos un ejemplo. Vamos a intentarlo con otro diferente, y un poco más visual, haber si lo conseguimos.
Una de las explicaciones que nos pueden ayudar a enfocar correctamente la idea de INNER JOIN, son los diagramas de Venn, pero esto de cara a los datos que vamos a querer. Sin embargo los diagramas de las tablas nos ayudan a entender mucho mejor como se relacionan las tablas.
Diagrama de Venn
Diagrama de tablas
Imagina que tenemos una página web de la empresa, que tiene usuarios con su login, empleados, departamentos y empresas.
Nota: Code 1.0, prepara el escenario, no hace falta entenderlo.
-- Code 1.0
Create table dbo.Usuarios
(
id int primary key
, loginUser varchar(100)
, passwordUser varchar(100)
);
Create table dbo.Empresas
(
id int identity(1, 1) primary key
, marcaComercial varchar(100)
);
Create table dbo.Departamentos
(
id int identity(1, 1) primary key
, detalle varchar(100)
, empresa int
, constraint fk_DepEmp foreign key(empresa)
references empresas(id)
);
Create table dbo.Empleados
(
id int identity(1, 1) primary key
, idUsuario int
, nomEmpleado varchar(100)
, departamento int
, constraint fk_EmpDep foreign key(departamento)
references departamentos(id)
, constraint fk_EmpUsr foreign key(idUsuario)
references usuarios (id)
);
go
De lo anterior, lo importante es la imágen, que tenemos que tener clara, para realizar cualquier consulta. Porque si tenemos usuarios y necesitamos la columna marcaComercial, de empresas, tenemos que navegar a través de las cuatro tablas.
Da igual la información que me soliciten, si yo tengo claro la navegavilidad de las tablas, puedo obtener cualquier dato. Si me dan un departamento y me solicitan datos de usuarios. Mi consulta tiene que ir a departamentos, relacionarse con empleados, y con usuarios.
Al final la navegabilidad de las tablas se produce por los conectores que disponen. No se puede pasar de Usuarios a Departamentos sin mencionar Empleados.
Una vez que tienes claro el flujo que tiene la información por el diseño de las tablas, hay que fijarse en las columnas que enlazan.
Normalmente las columnas representativas de una tabla en otra (claves foráneas), suelen tener un nombre que las identifica. Pero eso no quiere decir que tenga que ser así, ya que se pueden llamar como les plazca.
En el escenario planteado, la relación entre usuarios y empleados viene determinada por la columna idUsuario de la tabla empleados. No importa que la tabla usuarios no tenga nada de empleados.
Si nos solicitasen información y fíjate que digo información y no me importa las columnas aún, de usuarios y empleados, la consulta empezaría con un
-- Code 1.1
From Usuarios u inner join Empleados e
on e.idUsuario = u.id
Pero esto es lo mismo que esto:
-- Code 1.2
From Empleados inner join Usuarios
on Empleados.idUsuario = Usuarios.id
O que este otro
-- Code 1.3
From Empleados e join Usuarios a
on e.idUsuario = a.id
O que este otro
-- Code 1.4
From dbo.Empleados zxy inner join dbo.Usuarios pqs
on pqs.id = zxy.idUsuario
En los cuatro códigos (Code 1.1, Code 1.2, Code 1.3 y Code 1.4), lo único que se busca es las columnas que identifican la navegación entre ambas tablas. Se relacionan por su identificador de columna. Da igual que el id de la tabla de usuarios se ponga al lado izquierdo o derecho del igual.
Si mencionas un alias a la tabla, a partir de ese momento, tienes que identificar las columnas si tienen nombres diferentes por el alias. No obstante si utilizas alias, es recomendado, ponerlos siempre.
Con las dos tablas relacionadas, entonces ya hay que fijarse en la información que nos solicitan, y completaremos la consulta con un Select y alias de tabla y nombre de columna.
Si nos hubieran solicitado, nombre de login y nombre de empleado.
-- Code 1.5
Select
pqs.loginUser as loginPersonalUser,
zxy.nomEmpleado as NombreEmpleado
From dbo.Empleados zxy inner join dbo.Usuarios pqs
on pqs.id = zxy.idUsuario
Cuando nos solicitan, por ejemplo los mismos datos del departamento de contabilidad, volvemos a recurrir a la imagen y navegamos por las tablas.
Necesitamos usuarios, empleados y departamentos. La navegación de usuarios y empleados, ya la conocemos, pues añadiremos la de departamentos.
El campo departamento de la tabla de empleados, enlaza con el campo id de la tabla departamentos.
La query sería así:
-- Code 1.5
From dbo.Empleados e
inner join dbo.Usuarios u
on u.id = e.idUsuario
inner join dbo.departamentos d
on d.id = e.departamento
Relacionamos empleados con usuarios, igual que antes, y además relacionamos empleados con departamentos.
Y ¿porqué con departamentos?, si tenemos la columna departamento en Empleados. Simplemente porque en empleados tenemos su id, y nos han facilitado el detalle del departamento.
El código 1.5 es lo mismo que:
-- Code 1.6
From Departamentos d inner join
dbo.Empleados e
on d.id = e.departamento
inner join dbo.Usuarios u
on u.id = e.idUsuario
No importa la dirección del flujo de información. Importa la unión de los datos, sea por las columnas correctas.
-- Code 1.7
Select
u.loginUser,
e.nomEmpleado
From Departamentos d
inner join dbo.Empleados e
on d.id = e.departamento
inner join dbo.Usuarios u
on u.id = e.idUsuario
Where
d.detalle = 'Contabilidad'
Uniendo una tabla más, si nos solicitan la empresa para la que trabaja el usaurio de login «pepe».
Identificamos las columnas que navegan entre las tablas, y las plasmamos en la query.
-- Code 1.8
From Departamentos d inner join
dbo.Empleados e
on d.id = e.departamento
inner join dbo.Usuarios u
on u.id = e.idUsuario
inner join dbo.Empresas emp
on emp.id = d.empresa
Ahora solo nos queda mostrar las columnas de la Select y aplicar las restricciones que nos han pedido.
-- Code 1.9
Select
emp.marcaComercial as empresa
From Departamentos d inner join
dbo.Empleados e
on d.id = e.departamento
inner join dbo.Usuarios u
on u.id = e.idUsuario
inner join dbo.Empresas emp
on emp.id = d.empresa
Where u.loginUser = 'Pepe'
Por tanto para 1 sola columna de salida (marcaComercial), hemos relacionado 4 tablas. Además el motor se encarga de colocar la query en el orden que le parece oportuno para traer los datos de la manera más eficaz que pueda. Al principio seguir un orden nos ayuda a comprender las mismas, pero como ves no es requerido.
🙂
Datos y demás 