9Equipo-11Práctica - Jorge González

Vista previa del material en texto

UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO
FACULTAD DE INGENIERÍA
Lab. de Bases de Datos
Grupo: 07 - Semestre: 2022-1
Práctica 11 :
Utilización de distintos tipos de JOIN, Subconsultas y
Vistas
FECHA DE ENTREGA: 25/11/2021
Profesora:
López Pelcastre Martha M.I.
Alumno:
N.L: 26 Téllez González Jorge Luis
Facultad de Ingeniería Lab. de Bases de Datos______________________________________________________________________________________________________________
Índice
1. Objetivo_________________________________________________________________________________________2
2. Introducción
2.1. El concepto de JOIN en SQL_________________________________________________________2
2.2. Tipos de JOIN en T-SQL______________________________________________________________3
2.3. Vistas__________________________________________________________________________________8
3. Desarrollo
3.1. Consultas con distintos tipos de JOIN_____________________________________________9
3.1.1. Ejercicio A)____________________________________________________________________9
3.1.2. Ejercicio B)__________________________________________________________________10
3.1.3. Ejercicio C)__________________________________________________________________11
3.1.4. Ejercicio D)__________________________________________________________________12
3.1.5. Ejercicio E)__________________________________________________________________13
3.1.6. Ejercicio F)__________________________________________________________________14
3.1.7. Ejercicio G)__________________________________________________________________15
3.2. Uso de diferentes tipos de vistas_________________________________________________16
3.2.1. Ejercicio I)___________________________________________________________________16
3.2.2. Ejercicio J)___________________________________________________________________16
3.2.3. Ejercicio K)__________________________________________________________________17
3.2.4. Ejercicio L)__________________________________________________________________17
4. Conclusiones__________________________________________________________________________________18
1
Facultad de Ingeniería Lab. de Bases de Datos______________________________________________________________________________________________________________
1. Objetivo
El alumno pondrá en práctica el uso de los distintos tipos de JOIN, realizará diferentes tipos de
subconsultas y creará vistas.
2. Introducción
2.1 El concepto de JOIN en SQL
El operador Join se trata de una unión de 2 relaciones por medio de la aplicación de un
predicado p para asociar las tuplas de una tabla R con las de otra tabla S. Este operador se trata
de una parte fundamental dentro de las bases de datos relacionales con el fin de realizar
consultas que involucran un conjunto de tablas relacionadas entre sí.
De forma general y en términos de álgebra relacional el operador JOIN se define de la siguiente
forma:
R ⋈p S = σp(R × S)
Donde:
● R es la primera tabla a relacionar y S la segunda.
● ⋈p es el operador Join y el subíndice p el predicado de igualdad entre valores de
las columnas.
● σp es el operador Select que satisface una condición o predicado p.
● R × S es el producto cartesiano entre R y S.
A partir de la definición anterior, es posible observar que una operación JOIN
fundamentalmente se usa un predicado para verificar la igualdad entre los valores de
una columna de R y otra de S; siendo en la práctica la igualación entre una PK de una
tabla padre y una FK proveniente de la tabla padre que fue propagada a una tabla hija;
obteniendo como resultado todos los registros de S relacionados con cada registros de la
tabla R.
El resultado de realizar una consulta por medio de un Join consiste, por tanto, en una
combinación de filas de 2 (o incluso más) tablas tomando en consideración un campo en
común entre ellas permitiendo recuperar datos relacionados entre sí pero provenientes
de distintas tablas.
El estándar SQL presenta diversos tipos de operaciones derivadas del JOIN; aunque no
todas son soportadas por cada manejador. Para efectos de esta práctica, se abordarán
conceptualmente los tipos de JOIN básicos soportados por Transact-SQL dentro del
contexto del manejador SQL Server que fueron presentados en el desarrollo de la
práctica presente.
2
Facultad de Ingeniería Lab. de Bases de Datos______________________________________________________________________________________________________________
2.2 Tipos de JOIN en T-SQL
● Inner Join
Un Inner Join se trata del caso más típico de uso de Joins para la consulta de datos
relacionados. En primer lugar, los Inner Joins únicamente consideran en una consulta
aquellos registros que tengan correspondencia con la tabla asociada; de modo que si,
por ejemplo de las tablas A y B existen registros de A que no se asocian con B o
viceversa, estos no se incluirán en el resultado final de la consulta.
La condición para que los registros sean recuperados, por tanto, es que estos deberán
tener valores idénticos en los campos que se comparan para realizar la unión en ambas
tablas; que en la práctica se tratan de una PK y FK como se mencionó previamente. De
esta forma, se puede representar por medio de un diagrama de Venn el resultado de un
Inner Join sobre dos tablas de la siguiente forma:
Natural Join
Se trata de una variante del Inner Join con un condición especial: en un Inner Join
siempre debe de especificarse la condición o el predicado para realizar la operación
JOIN, sin embargo, en el Natural Join el predicado es construido de forma automática o
natural, considerando el nombre de las columnas como la regla para realizar la
combinación; todas las columnas que tengan el mismo nombre serán empleadas para
construir el predicado del Join.
3
Facultad de Ingeniería Lab. de Bases de Datos______________________________________________________________________________________________________________
Esta variante del Inner Join debe ser usada con mucho cuidado, ya que si existen
columnas con nombres iguales puede dar lugar a ambigüedades. Por otra parte, el uso de
alias puede invalidar la igualdad entre columnas.
● Outer Join
A diferencia del Inner Join, un Outer Join permite no solo recuperar registros
relacionados provenientes de dos tablas A y B, sino que también permite obtener
aquellos registros que no tienen una correspondencia ya sea de A hacia B o viceversa.
Por ejemplo, suponiendo que se tiene una tabla A que contiene a los clientes de un
banco y otra tabla B que contiene los datos de diversas tarjetas de crédito emitidas a un
cliente, si esta consulta se hiciese con un Inner Join, el resultado sería el siguiente:
Por otra parte, realizar un Outer Join produciría el siguiente resultado:
Se observa, por tanto, que un Outer Join permitirá recuperar no solo a los clientes que
tienen asociada una tarjeta de crédito, sino que también permitirá recuperar a aquellos
que no tienen asociada una tarjeta; apareciendo los campos asociados a las TDC con
valor nulo en las filas de estos clientes.
Los Outer Join tienen 2 posibles variantes dependiendo de la dirección, o bien, la tabla
de la que se desean recuperar los registros sin relación.
Left Outer Join
Un Left Outer Join se trata de un Outer Join donde se recuperan todas las filas de la tabla
a la izquierda (A) aunque no todas posean una correspondencia en la tabla de la derecha
(B).
4
Facultad de Ingeniería Lab. de Bases de Datos______________________________________________________________________________________________________________Gráficamente esto se observaría de la siguiente forma con un diagrama de Venn:
Tanto las sentencias left o right son usadas para reflejar el orden en que las tablas son
procesadas por el manejador. Específicamente, en un Left Outer Join se obtienen todos
los registros que hacen unión en ambas tablas con respecto al campo especificado con la
cláusula ON, y de forma adicional, los registros de la tabla izquierda que no tienen
correspondencia con el lado derecho.
Con lo anterior, en el ejemplo de los clientes y las TDC, si Cliente representa a la tabla a
la izquierda y TDC a la tabla derecha, usar un Left Outer Join indicará al manejador que
procese en primer lugar a la tabla Cliente y, si hay clientes que no tienen una TDC
asociada, los mostrará en el resultado de la consulta además de aquellos que sí tienen
una TDC. Esto escrito en código SQL se vería de la siguiente forma:
Right Outer Join
A diferencia del caso anterior, un Right Outer Join implica que la tabla de la derecha es
procesada en primer lugar que la tabla a la izquierda, es decir, se recuperan todas las
filas de la tabla a la derecha (B) aunque no todas posean una correspondencia en la tabla
de la izquierda (A).
La representación de lo anterior en un diagrama de Venn se observa a continuación:
5
Facultad de Ingeniería Lab. de Bases de Datos______________________________________________________________________________________________________________
En un Right Outer Join se obtienen todos los registros que hacen unión en ambas tablas
con respecto al campo especificado con la cláusula ON, y de forma adicional, los
registros de la tabla derecha que no tienen correspondencia con el lado izquierdo.
Si aplicamos esta clase de Join al ejemplo de los clientes y las TDC, entonces se estarían
recuperando todas las TDC de crédito que tienen a un cliente asociado, y además,
aquellas TDC que no están asociadas a un cliente.
Evidentemente, esto no se presentaría en este ejemplo, ya que la entidad TDC es
dependiente de existencia con respecto a la entidad Cliente, sin embargo, si no fuera así,
ese sería el resultado obtenido.
● Full Join
Un Full Join consiste en la obtención de todas las filas tanto en las tablas A y B, sin
importar si los registros contenidos dentro de ellas guardan alguna relación. Por tanto,
se recuperarán todos los registros que contienen correspondencia, y además, aquellos
registros tanto de A como de B que no guardan ninguna relación con los de su respectiva
tabla contraria.
6
Facultad de Ingeniería Lab. de Bases de Datos______________________________________________________________________________________________________________
Realizar un Full Join es equivalente a obtener los registros comunes con un Inner Join, y
después, añadir tanto los registros de la tabla A que no tienen correspondencia con B
como los registros de B que no guardan correspondencia con los de A, estando los
campos de A o B vacíos para los registros que no tienen relación con su respectiva tabla
contraria.
Si esto se aplicase al ejemplo anterior, el resultado sería tanto los registros de Cliente y
TDC que guardan relación como aquellos Clientes que no tienen asociada una TDC así
como las TDC que no tienen asociación con un Cliente.
● Cross Join
Un Cross Join corresponde básicamente a una operación de producto cartesiano aplicada
sobre las tuplas de dos tablas A y B, de forma que se obtienen todas las posibles parejas
de registros presentes en ambas tablas.
En la práctica el producto cartesiano de dos tablas no es una operación frecuentemente
realizada debido al escaso valor que aporta a un escenario de consulta típico en bases,
por ejemplo, OLTP. Si esto se aplicara a las tarjetas y los clientes, el resultado de una
consulta con esta clase de Join consistiría en todas las posibles combinaciones posibles
entre los registros de ambas tablas; sin importar si guardan relación o no. Por ejemplo,
si hubiese en la tabla Cliente 30 filas y en la tabla TDC 12 filas, el resultado consistiría en
30 * 12 = 360 filas siendo cada una de ellas una combinación posible.
7
Facultad de Ingeniería Lab. de Bases de Datos______________________________________________________________________________________________________________
2.3 Vistas
Una vista se trata de una tabla virtual cuyo contenido se encuentra definido
exclusivamente por una consulta. De forma semejante a una tabla, una vista consiste en
un conjunto de columnas y registros con un valor, sin embargo (a menos que se
encuentra indexada), una vista como tal no existe como un conjunto de datos
almacenados dentro de una base de datos; siendo las filas y columnas de la vista
procedentes de las tablas a las que se hace referencia en la consulta que define al
contenido de la vista y que se producen de forma dinámica al hacer referencia a la vista
propiamente en una consulta.
Una vista por las características mencionadas previamente permite realizar una
consulta que involucre a una o más tablas (por medio de joins) con una notación mucho
más compacta, en lugar de tener que escribir la consulta completa siendo especialmente
eficiente en el caso de consultas complejas.
Por otra parte, las vistas brindan la posibilidad de realizar una especie de encapsulado
de los datos, de forma que, por ejemplo, los usuarios habilitados para realizar consultas
dentro de una base de datos puedan consultar parte de la información presente en una o
más tablas; aunque estos no tengan permiso de acceder a toda la información presente
en la misma que pueda ser de carácter sensible. Es decir, permiten a los usuarios obtener
acceso a los datos de una base, pero sin concederles permiso directo de acceso a las tablas
base referenciadas por la vista.
Las vistas pueden utilizarse para proporcionar una interfaz compatible con versiones
anteriores con el fin de emular una tabla que existía pero cuyo esquema ha cambiado.
8
Facultad de Ingeniería Lab. de Bases de Datos______________________________________________________________________________________________________________
3. Desarrollo
3.1. Consultas con distintos tipos de JOIN
La primera actividad de la práctica solicita realizar un serie de consultas que ejemplifiquen los
distintos tipos de JOIN presentes dentro de SQL, como: INNER JOIN, LEFT o RIGHT JOIN, entre
otros.
3.1.1. Ejercicio A)
Se requiere un reporte de los pedidos del proveedor 'FENDER AC' (idPedido, fecha del pedido,
tienda, razón social y estatus) utilizando una subconsulta y alias.
Observando los requerimientos de la consulta anterior, se puede notar que los campos
solicitados hacen referencia tanto a la tabla PEDIDO como a la tabla PROVEEDOR; por ejemplo,
siendo el campo razonSocial parte de la tabla de proveedores y el campo idPedido el
identificador de los pedidos.
Entonces, con lo anterior es posible notar que para los registros a recuperar se deberá hacer uso
de un JOIN para enlazar las foráneas de PEDIDO con las PK de PROVEEDOR y recuperar los
pedidos que hagan referencia (por medio de la foránea idProveedor) a un proveedor que tenga
en razonSocial la cadena ‘FENDER AC’. Como se requiere que únicamente se recuperen los
registros que cumplan con tal condición, se debe de usar un INNER JOIN para que la consulta
obtenga el resultado deseado y solo considere los registros que cumplan la condición de
combinación razonSocial='FENDER AC'. Con lo anterior, se escribe el siguiente código SQL:
Seleccionando los campos idPedido, fechaPedido, idTienda, idEstatus (todos campos de la tabla
PEDIDO) y razonSocial de la tabla PROVEEDOR, se realiza el INNER JOIN por medio de la FK
idProveedor junto con la condicionalde combinación. En la base utilizada el proveedor FENDER
AC con idProveedor=10 únicamente ha surtido un pedido con idPedido=2, hecho que se refleja en
resultado de la consulta planteada en contraste con la segunda que arroja todos los pedidos.
9
Facultad de Ingeniería Lab. de Bases de Datos______________________________________________________________________________________________________________
3.1.2. Ejercicio B)
Obtenga el monto total del stock de los instrumentos de percusión por tipo de sonido.
Ya que se solicita el total del stock registrado para cada instrumento de percusión
diferenciándolos por su tipo, se requiere realizar una operación de tipo INNER JOIN para
enlazar las ocurrencias de instrumentos que pertenecen al subtipo PERCUSION con su
respectivo sonido (Determinado o Indeterminado).
Por tanto, la consulta a realizar deberá incluir el campo sonido, y el stock sumado haciendo uso
de la función de agregación SUM de la tabla INSTRUMENTO, realizado el INNER JOIN con
PERCUSION y, finalmente, agrupando los resultados por sonido con GROUP BY . Para verificar la
validez de la consulta, se puede realizar otra consulta que, de forma semejante, realice un JOIN
sobre INSTRUMENTO y PERCUSION, recuperando cada instrumento, su descripción, tipo y stock
con tipoInstrumento=’P’ y ordenándolos por sonido con el fin de observar si la suma obtenida
coincide con los valores de stock registrados en la base para cada instrumento individual por
tipo.
Entonces, de la primera consulta se espera recuperar únicamente 2 valores: uno con la suma del
stock de los instrumentos de percusión con sonido determinado (D) y otro con la suma del stock
de los instrumentos de percusión pero de sonido indeterminado (I) (recordando que el uso de
GROUP BY siempre acompaña al uso de funciones de agregación ya que de lo contrario el
manejador marcará un error). Con la segunda consulta se podrá validar que la suma obtenida es
correcta. Ejecutando el código escrito, es posible observar que efectivamente la suma en ambos
casos da el resultado correcto:
10
Facultad de Ingeniería Lab. de Bases de Datos______________________________________________________________________________________________________________
3.1.3. Ejercicio C)
Obtenga la suma del total del precio de venta de los instrumentos de viento por tipo de soplo,
utilizando inner join (nombre del instrumento, soplo, total).
Para realizar la consulta anterior, deberá de considerarse el campo soplo (humano o mecánico) y
una suma del precio de venta de cada ocurrencia de instrumento de viento de acuerdo de su
tipo. Como se está haciendo referencia a un campo (soplo) de la tabla de subtipos VIENTO y a
otro campo (precioVenta) del supertipo INSTRUMENTO, se requiere forzosamente realizar un
INNER JOIN con la foránea idInstrumento para garantizar que los registros recuperados y
sumados correspondan a instrumentos que tienen su subtipo en VIENTO registrado. Además,
como se requiere el uso de la función SUM, se requiere el uso de GROUP BY para que la consulta
sea exitosa, usando al soplo como referencia para realizar al agrupamiento.
Como únicamente se tienen 2 tipos de instrumentos de viento de acuerdo a su soplo, de forma
general se pueden esperar 2 resultados de suma total de acuerdo con el tipo de soplo de cada
instrumento. En el caso que muestra a continuación, únicamente se tienen registrados
instrumentos de soplo humano, por lo que únicamente se tendrá como resultado la suma del
precio de venta de cada uno de los instrumentos de viento con soplo ‘h’. Ejecutando el código
anterior, se verifica lo anterior:
11
Facultad de Ingeniería Lab. de Bases de Datos______________________________________________________________________________________________________________
3.1.4. Ejercicio D)
Obtenga un reporte de todos los instrumentos incluyendo el costo total de la cantidad surtida para
los que tengan pedidos (left) así como precio de venta.
Esta consulta contiene diversas condiciones importantes a tener en cuenta:
● El reporte debe incluir todos los instrumentos de la base de datos.
● Si estos tienen registrado un pedido, este deberá aparecer asociado al instrumento y
debe acompañar al registro el costo total de la cantidad surtida y su precio de venta.
● En caso de que no tengan pedidos, deberán aparecer igualmente,
Dado que se desea añadir al reporte registros que no necesariamente guardan una relación con
las instancias de la tabla PEDIDO, es necesario utilizar un LEFT JOIN para incluir en el resultado
de la consulta los registros de INSTRUMENTO sin relación con algún registro de PEDIDO. Por
otra parte, en caso de que un instrumento aparezca siendo referenciado por 2 o más registros de
PEDIDO, estas relaciones deberán aparecer como 2 filas separadas en el reporte.
Entonces, con lo anterior se establece que hay que recuperar el idInstrumento, idPedido,
descripción, la cantSurtida, la suma del costo del pedido y el precio de venta registrado
inicialmente en la tabla INSTRUMENTO, como se observa a continuación:
El resultado anterior, por tanto, deberá estar compuesto por un reporte de todos los
instrumentos presentes en la base de datos, tengan o no asociado un pedido. Si tienen un
pedido, tendrán un valor en la columna cantidadTotal, y costoTotal, y en caso contrario,
permanecerán como NULL salvo en costoIndividual que hace referencia al costo de la tabla
INSTRUMENTO y precioVenta que igualmente es de la tabla mencionada. Por otra parte, SQL
Server permite definir una columna derivada para el costoTotal que se obtiene multiplicando el
costo de la tabla detallePedido con la cantSurtida para el pedido. Ejecutando la consulta anterior,
se obtiene el siguiente reporte:
12
Facultad de Ingeniería Lab. de Bases de Datos______________________________________________________________________________________________________________
Finalmente, se observa que en la consulta final se obtiene un reporte de los instrumentos en un
pedido o no, notándose que aquellos sin pedido asociado tienen idPedido, cantidadTotal y
costoTotal con valor NULL. Así mismo, se observa en el pedido 9 con el instrumento TIMBAL
que el costoTotal se calcula tomando la cantidad total surtida con el costo individual de cada
timbal, observándose por tanto un resultado consistente.
3.1.5. Ejercicio E)
Obtenga el listado de los proveedores que no han surtido pedidos (rigth).
Ahora se tiene una situación contrario al ejercicio anterior, donde se desea recuperar
explícitamente los registros de PROVEEDOR que no guardan relación alguna con la tabla
PEDIDO. Si se considera que sólo se desean obtener proveedores sin surtido, es posible afirmar
que la tabla PROVEEDOR bien puede considerarse como el conjunto B para efectos del
planteamiento de un RIGHT JOIN dado que solo se desea recuperar los elementos
pertenecientes a este conjunto sin considerar a aquellos que guardan relación con PEDIDO.
Sin embargo, si únicamente se realiza un RIGHT JOIN sin más, el resultado no será el adecuado
ya que este incluirá las intersecciones con el conjunto A (que corresponde a la tabla PEDIDO).
Obsérvese la siguiente consulta planteada: se recuperan los campos idProveedor, razonSocial,
idPedido y observaciones de las tablas mencionadas, sin embargo, al ejecutar la consulta, el
resultado consiste en todos los proveedores con pedidos, dejando hasta el final a aquellos sin
pedidos (denotados por tener idPedido y observaciones con valor nulo):
Con lo anterior, se observa que la consulta anterior no satisface la solicitud inicial de solo
obtener los proveedores sin relación con algún pedido. Sin embargo, esto se puede solucionarrápidamente estableciendo tras la declaración del RIGHT JOIN una condición con WHERE
donde se establezca que los proveedores a recuperar deberán tener un valor de idPedido nulo.
13
Facultad de Ingeniería Lab. de Bases de Datos______________________________________________________________________________________________________________
Con este cambio, el resultado se vuelve el deseado al solo obtener los proveedores que no han
surtido algún pedido (que en el caso de la base trabajada solo se trata de FALY MUSIC):
3.1.6. Ejercicio F)
Obtenga la información de los pedidos (idpedido, fechapedido, estatus), así como los estatus que no
se han utilizado en la tabla pedido, use FULL OUTER JOIN.
En primer lugar, se solicita recuperar la información de los pedidos registrados en la base, con
su identificador, la fecha del pedido y su estatus actual, y de igual forma, se requiere mostrar
aquellos estatus que todavía no han sido referenciados en la tabla PEDIDO. Entonces, como se
requiere mostrar registros que no tienen relación con otra tabla (en este caso un registro de
ESTATUS que no es referenciado en PEDIDO), se requiere usar un FULL OUTER JOIN que
permite combinar resultados de una tabla, aunque estos no tengan relación entre sí. La
siguiente consulta, por tanto permite satisfacer los requerimientos anteriores, ordenando por
idEstatus para una mejor visibilidad de los estatus que no son referenciados por un pedido:
El resultado que se espera, por tanto, es uno consistente en una serie de filas donde se registra
cada ocurrencia de un determinado estatus dentro de un registro de la tabla PEDIDO, es decir, si
por ejemplo hay 3 pedidos con estatus EN AUTORIZACION, estos aparecerán en el listado con su
respectivo idPedido y su idEstatus que hace referencia al estado actual del pedido en cuestión.
Por otra parte, si alguno de los estados presentes en la tabla ESTATUS no es referenciado por
14
Facultad de Ingeniería Lab. de Bases de Datos______________________________________________________________________________________________________________
ningún pedido, este aparecerá en el listado pero su valor en fechaPedido e idPedido será NULL:
3.1.7. Ejercicio G)
Realizar todas las posibles combinaciones de las tablas instrumentos y las tiendas (cross join).
Dado que se solicita realizar todas las combinaciones posibles entre los registros de la tabla
INSTRUMENTO y la tabla TIENDA sin tener en cuenta alguna consideración adicional, el CROSS
JOIN permite satisfacer tal consulta al realizar una multiplicación entre cada tabla de acuerdo al
número de registros dentro de cada una de ellas.
En el caso de la base de datos trabajada, se tienen un total de 16 instrumentos registrados y 5
tiendas actualmente, en consecuencia, el resultado de aplicar un CROSS JOIN entre ambas tablas
dará como resultado 16x5= 80 registros como resultado de la consulta.
15
Facultad de Ingeniería Lab. de Bases de Datos______________________________________________________________________________________________________________
3.2. Uso de diferentes tipos de vistas
3.2.1. Ejercicio I)
Cree una vista que muestre el instrumento, precio de venta, tipo de instrumento y las
características de ellos de acuerdo a su tipo.
La creación de la vista solicitada solicita incluir la descripción de cada instrumento, su
precioVenta, su tipo de instrumento y cada uno de los atributos particulares de cada uno de ellos
de acuerdo a su tipo (Cuerda, Percusión o Viento). Debido a que se requieren recuperar
atributos particulares de los 3 subtipos existentes en la base, es necesario hacer uso de un total
de 3 JOIN para recuperar los valores requeridos y enlazarlos con la tabla padre INSTRUMENTO
usando la foránea propagada como PK idInstrumento. Por otra parte, al tenerse un listado de
todos los instrumentos resulta evidente que muchos resultados no tendrán valor en ciertos
campos particulares (Por ejemplo, un instrumento de percusión no tiene un valor en
tipoCuerdas), por lo que se requiere necesariamente el uso de un LEFT JOIN para que cada
registro sea incluido en la consulta.
¿Qué pasaría si en su lugar se usara un INNER JOIN? La respuesta es sencilla: no se obtendría
ningún registro como resultado, y esto es debido a que al usar esta clase de JOIN se estaría
indicando que los registros recuperados debieran de tener valor en cada uno de los campos
específico de cada subtipo, lo cual es completamente falso e imposible de registrar dentro de la
base considerando sus condiciones de integridad.
Cabe señalar que, aunque el manejador remarca la sentencia inicial de color rojo, la vista se crea
de forma exitosa y puede usarse para realizar una consulta.
3.2.2. Ejercicio J)
Cree la vista del inciso C.
Para crear la vista solicitada, únicamente se recupera la condición SELECT y el INNER JOIN
escrito previamente con fin de agruparlo todo en una única vista que permite ejecutar todas
esas sentencias de forma mucho más compacta:
16
Facultad de Ingeniería Lab. de Bases de Datos______________________________________________________________________________________________________________
3.2.3. Ejercicio K)
Cree la vista del inciso A.
Similar al ejercicio anterior, únicamente se recupera la consulta realizada en el ejercicio A) para
incluirla en una vista creada de la siguiente forma:
3.2.4. Ejercicio L)
Revise el contenido de las vistas.
Una gran ventaja de las vistas, además de proteger el acceso a los datos de forma similar a un
encapsulamiento, es que permiten realizar consultas de forma sencilla sin tener que escribir
repetidas veces la consulta, o las subconsultas requeridas para un resultado deseado. En las
siguiente líneas de código, se observa que realizar consultas a una vista es muy sencillo y se
realiza únicamente con un SELECT * from hacía la vista a consultar. Al hacer esto, las consultas
SELECT especificadas dentro de ella se ejecutarán y arrojarán el resultado especificado en ellas:
17
Facultad de Ingeniería Lab. de Bases de Datos______________________________________________________________________________________________________________
4. Conclusiones
● Téllez González Jorge Luis:
Por medio del desarrollo de los ejercicios propuestos fue posible desarrollar de forma más clara
el concepto de Joins que ha sido referenciado múltiples durante el desarrollo de la clase teórica y
que además también se estudió brevemente durante prácticas pasadas. Con lo anterior, es
posible afirmar que esta operación representa uno de los elementos más importantes que
existen dentro de una base de datos relacional, ya que representa la operación fundamental para
relacionar los datos existentes entre 2 o más tablas distintas y que, sin su presencia, serían
imposibles de enlazar y consultar simultáneamente.
Durante el desarrollo de la práctica también se pudo estudiar la diferencia entre el Inner y el
Outer Join y abordar cada caso como una selección de elementos dentro de 2 conjuntos (o bien,
2 tablas). Así mismo, tras realizar un análisis individual del ejercicio D) se realizaron
modificaciones al mismo con respecto a la entrega en clase de forma que los datos recuperados
reflejaran de forma más adecuada los elementos solicitados en la consulta; lo que requirió un
replanteamiento en los JOINS para cumplir con la consulta solicitada.
Finalmente, con estos conceptos estudiados y con el desarrollo exitoso de los ejercicios
propuestos se puede afirmar que el objetivo principal de esta práctica ha sido cumplido con
total éxito. Un conceptotan relevante como los Join es muy importante de tener claro para
realizar consultas en una base productiva, y junto con la noción de la vistas como mecanismos
de seguridad, han brindado ideas más claras de cómo se implementan las consultas públicas en
bases productivas que se pueden hallar en prácticamente cualquier sector o servicio humano.
Referencias
1. Consultas SELECT multi-tabla - Tipos de Join. Campus MVP. Recuperado de:
https://www.campusmvp.es/recursos/post/Fundamentos-de-SQL-Consultas-SELECT-m
ulti-tabla-Tipos-de-JOIN.aspx Fecha de consulta: 22/11/2021.
2. Rodríguez C., J. A. Tema 9 Parte I. Lenguaje de Consulta de Datos (DQL). FI UNAM.
3. Vistas. Documentación de SQL. Recuperado de:
https://docs.microsoft.com/es-es/sql/relational-databases/views/views?view=sql-serv
er-ver15 Fecha de consulta: 22/11/2021.
4. ¿Qué es Cross Join? Programa en línea. Recuperado de:
https://www.programaenlinea.net/que-es-cross-join/ Fecha de consulta: 22/11/2021.
18
https://www.campusmvp.es/recursos/post/Fundamentos-de-SQL-Consultas-SELECT-multi-tabla-Tipos-de-JOIN.aspx
https://www.campusmvp.es/recursos/post/Fundamentos-de-SQL-Consultas-SELECT-multi-tabla-Tipos-de-JOIN.aspx
https://docs.microsoft.com/es-es/sql/relational-databases/views/views?view=sql-server-ver15
https://docs.microsoft.com/es-es/sql/relational-databases/views/views?view=sql-server-ver15
https://www.programaenlinea.net/que-es-cross-join/