Lección 19 - Síntesis de la segunda parte

Curso SQL para principiantes


Reunión

En esta segunda parte se ha profundizado sobre la operación de reunión. El producto cartesiano es el caso más general, donde se combinan todos los registros de una primera tabla con todos los registros de las otras tablas que intervienen en la operación de reunión, esto ocurre cuando se omite la cláusula WHERE de la consulta SQL.

Podemos usar una sintaxis concreta para la operación de reunión mediante las cláusulas FROM INNER JOIN, donde se establecen a ambos lados de la expresión las tablas que van a intervenir en la operación, más la cláusula ON, donde se establecen las condiciones que ha de satisfacer la operación. La alternativa a esta sintaxis es usar las cláusulas FROM WHERE con idéntico propósito.

Totalización

Cuando realizamos una operación de reunión, a efectos lógicos, podemos considerar que el motor SQL realiza el producto cartesiano entre las tablas involucradas y posteriormente aplica sobre el resultado los filtros que establece la cláusula WHERE. Para las funciones de totalización podemos considerar lo mismo, es decir, que el cálculo se realiza sobre los registros resultantes del producto cartesiano tras ser filtrado por la cláusula WHERE.

Reunión externa

La reunión externa permite obtener datos de una tabla aunque no tenga éxito la condición que estable la operación, o lo que es lo mismo, en el resultado de la reunión externa las columnas referentes al registro padre vendrán a nulo porque la clave foránea del registro hijo contiene un valor nulo. Esto es así cuando la tabla que manda es la tabla hijo. Puede darse también a la inversa, es decir, que la consulta se construya de modo que mande la tabla padre, de modo que los registros padre que no tengan hijos se muestren con los campos de la tabla hijo a nulo en el caso de no existir ningún registro hijo para ese padre. La cláusula que permite realizar esta operación es OUTER JOIN. Que mande una u otra tabla dependerá de si aplicamos la reunión externa por la izquierda o por la derecha, es decir, de si aplicamos entre ellas LEFT OUTER JOIN o RIGHT OUTER JOIN, manteniendo las tablas que interviene fijas a ambos lados del OUTER JOIN.

* * *

Claves primarias y foráneas

La clave primaria de una tabla permite identificar de forma única cada registro de una tabla mediante los propios datos que contienen los campos que forman la clave primaria. Esta puede ser simple o compuesta, es decir, formada por uno o por varios campos. Los datos que contiene un registro en los campos que establecen la clave primaria en una tabla no se pueden repetir para ningún otro registro de la tabla, garantizándose de este modo la exclusividad y la identificación unívoca del registro.

La clave foránea de una tabla relaciona el registro que contiene la clave foránea con el registro de la tabla padre que contiene el mismo valor en su clave primaria. Dicho de otro modo, la clave foránea de una tabla siempre existirá como clave primaria en la tabla a la que apunta y con la que se relaciona. En el caso de que el campo o campos que forman la clave foránea pueden contener valores nulos, el registro puede no estar asociado a ningún registro padre.

Relaciones y cardinalidad

Existen principalmente dos tipos de relación entre tablas de una BD según la cardinalidad de la relación.

  • Relación de 1 a N
  • Relación de N a M

La relación de cardinalidad 1 a N entre dos tablas establece que por cada registro de la tabla padre se esperan varios registros de la tabla hijos, pudiendo no tener ninguno. También el registro hijo puede no tener padre definido, en cuyo caso el campo o campos que apuntan al padre contendrán un valor nulo.

La relación de cardinalidad N a M entre dos tablas precisa de una tabla auxiliar o tabla de relación para establecer o definir la relación. Si dos registros concretos de dos tablas que guardan una relación N a M NO se relacionan entre sí, significa que NO aparecerá registro alguno en la tabla de relación que apunten a estos dos registros. En una tabla de relación la clave primaria será compuesta y estará formada por los campos que son clave primaria en las tablas o maestros de los que deriva. Estos campos, los que forman la clave primaria en cada maestro, de la tabla de relación serán a su vez por separado claves foráneas de sus respectivos maestros.

* * *

Modelo entidad-relación

Es un diagrama donde se representan entidades de una realidad o actividad y sus relaciones. Es de gran ayuda para posteriormente definir la estructura de tablas de una BD con sus relaciones.

Desarrollar modelos relacionales precisa un análisis e investigación previa de la actividad que se pretende gestionar. Cuantos más datos se tengan mejor y con menos errores se podrá desarrollar el modelo entidad-relación. Por otro lado desarrollar un modelo es una ejercicio creativo que precisa de una dilatada experiencia y práctica para dominarlo.

Una vez se obtiene el diagrama del modelo entidad-relación, se obtiene de forma directa la estructura de BD aplicando un protocolo que se rige por una serie de pasos, estos son los más significativos:

  • Cada entidad será una tabla de la base de datos.
  • Las relaciones de 1 a N implican crear una clave foránea en la tabla que deriva de la entidad con cardinalidad N, que apunte a la tabla que deriva de la entidad con cardinalidad 1.
  • Las relaciones de N a M exigen crear una nueva tabla de relación en la base de datos.

En el modelo entidad relación encontraremos entidades fuertes y débiles. Las entidades fuertes tienen claves propias para identificar sus registros, mientras que las débiles deben apoyarse en una entidad fuerte para identificarlos. La clave primaria de una entidad débil siempre será compuesta y en ella intervendrá la clave foránea que apunta a la entidad fuerte de la que depende. La relación entre ambas entidades siempre será de cardinalidad 1 a N.

* * *

DML (data manipulation language)

Las instrucciones DML, lenguaje de manipulación de datos, son:
  • SELECT: esta instrucción permite obtener datos de una BD, reunirlos, unirlos, calcular, etc...
  • INSERT: instrucción que permite insertar nuevo registros en una tabla de la BD.
  • DELETE: permite eliminar registros de una tabla.
  • UPDATE: esta instrucción posibilita la modificación de datos de una tabla, es equivalente a eliminar primero el registro mediante la instrucción DELETE y volverlo a crear con la instrucción INSERT. En ocasiones la integridad referencial hará imposible eliminarlo y volverlo a crear directamente debiendo usar forzosamente la instrucción UPDATE.

Al usar estas instrucciones, salvo la instrucción SELECT, se deben tener en cuenta las restricciones de la BD. Así pues el SGBD devolverá los siguientes errores si se pretende violar la integridad referencial.

  • Clave padre no encontrada: al insertar o modificar un registro donde se está indicando una clave foránea que no existe en la tabla padre.
  • Clave primaria duplicada: al insertar o modificar un registro donde se está indicando una clave primaria que ya existe en otro registro de la misma tabla.
  • Registros dependientes encontrados: al intentar eliminar un registro al que uno o mas registros hijos de otras tablas hacen referencia, dicho de otro modo, al intentar dejar huérfanos registros hijos del registro padre que se pretende eliminar.

* * *

Funciones

Las funciones permiten formatear fechas, manipular cadenas, redondear números... y un sinfín de utilidades que son de gran ayuda sobretodo en las consultas SQL, aunque también es posible aplicarlas a cualquiera de las instrucciones DML.

Las funciones esperan parámetros con los que, en función de estos y aplicados a un algoritmo, retornar un valor como resultado. Este valor será considerado como un campo de tabla o un valor constante por la instrucción DML. El tipo de dato de los parámetros y el tipo de dato que retorna la función dependerá de la especificación de cada función.

Las funciones en ocasiones permiten agrupar por valores que de otro modo sería imposible, por ejemplo, agrupar datos por año cuando la fuente del año es un campo de tipo fecha. Otras veces nos simplificarán el trabajo pudiendo obtener el resultado en la propia consulta evitando así un tratamiento posterior por código, es decir, desde el programa donde se lanza la consulta, por ejemplo php o java.

* * *

Ejercicio 1
Supongamos que tenemos las siguientes entidades en un modelo relacional que gestiona la liga profesional de fútbol: EQUIPOS y JUGADORES. La cardinalidad de esta relación es 1 a N, puesto que un equipo tiene una plantilla de N jugadores mientras que un jugador milita en un solo equipo. ¿Es JUGADORES una entidad débil?

Ejercicio 2
Supongamos que tenemos las siguientes entidades en un modelo relacional que gestiona las reparaciones del alumbrado público de una urbanización: FAROLAS y REPARACIONES. La cardinalidad de esta relación es 1 a N, puesto que a una farola se le realizan N reparaciones mientras que una reparación se practica a una farola. ¿Es REPARACIONES una entidad débil?

Ejercicio 3
Supongamos que tenemos las siguientes entidades en un modelo relacional que gestiona la actividad de un almacén de distribución de generó: ARTICULOS y FAMILIAS. La cardinalidad de esta relación es 1 a N, puesto que una familia agrupa N artículos mientras que un artículo pertenece a una sola familia. ¿Es ARTICULOS una entidad débil?

* * *



    Lección 18 - INSERT, UPDATE, DELETE SQL
  • Lección 20 - Aplicación SQL

Creative Commons License Creative Commons License

Este curso está sujeto a la licencia Reconocimiento-NoComercial-SinObraDerivada 3.0 de Creative Commons. Usted puede copiarla, distribuirla y comunicarla públicamente siempre que especifique su autor y deletesql.com; no la utilice para fines comerciales; y no haga con ella obra derivada. Puede usted consultar la licencia completa aquí.




Volver a Curso SQL desde cero

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 5 invitados