En apartados anteriores, habíamos visto como las bases de datos relacionales supusieron la solución para el problema de redundancia que surgía cuando usábamos los ficheros planos para almacenar los datos. No obstante, las bases de datos relacionales presentaban otros problemas, y no tardaron en surgir otras alternativas de bases de datos que organizaban los datos de forma diferente, y que son conocidas en su conjunto como bases de datos no relacionales. En este post, recorreremos estas bases de datos, describiendo brevemente los distintos tipos y explicando como estructuran los datos para su almacenamiento.
La rigidez de las bases de datos relacionales
Al abandonar los ficheros planos y empezar a usar las bases de datos relacionales, solucionamos el problema de redundancia. Ya no teníamos que repetir datos en varias filas y además reducíamos sensiblemente el número de errores en la introducción de los datos, lo que obviamente redundaba en una notable mejora de la calidad de los mismos.
Tras aprender a definir la estructura de la base de datos y a cargar, borrar o actualizar, los datos en las tablas, nos queda aprender como consultar los datos. Esto lo haremos con los comandos SQL para la recuperación de datos, las conocidas como consultas de selección, donde el comando SELECT resulta fundamental.
La sintaxis básica es:
SELECT [ALL | DISTINCT] <lista de campos> FROM <lista de tablas>
[WHERE ….]
[GROUP BY…]
[HAVING….]
[ORDER BY…]
En este post vamos a estudiar los principales comandos SQL para modificar los datos de las tablas de nuestra base de datos. Básicamente tenemos tres comandos para realizar las tres operaciones básicas:
INSERT INTO
Escribir un dato nuevo.
Sintaxis:
INSERT INTO <Tabla> [(campo1,campo2…..)]
VALUES (valor1, valor2, …)
La instrucción debe tener tantos valores como campos se pretenden rellenar y dichos valores deben ser del tipo que almacena el campo destino. En caso de no ser compatible el tipo de dato que queremos almacenar con el tipo del campo destino, se produciría un error y no se completaría la escritura de los datos.
UPDATE
Modificar el valor de un dato: Hay que indicar la tabla y los campos que se quieren actualizar. También podemos indicar un criterio que deben de cumplir los registros para que se produzca la actualización, pero esto es opcional.
Sintaxis
UPDATE tabla
SET campo1 = valor1, campo2 = valor 2,…
WHERE <criterio>
DELETE
Borrar un dato: Con esta instrucción, eliminamos los registros de la tabla indicada tras el comando FROM, y que cumplan los criterios definidos tras el comando WHERE
Sintaxis
DELETE FROM tabla
WHERE <criterios>
Y para practicar estos comandos, realizaremos el ejercicio siguiente:
Ejemplo: Manipulación de datos con SQL
Partimos de la BBDD ProveedoresSQL, que creamos en el post anterior. En ella ya tenemos creadas las dos tablas con las que de momento estamos funcionando: Proveedores y Productos. Pero estas están vacías, todavía no hemos cargado ningún dato.
Paso 1: Sentencias SQL para la carga de datos en la tabla proveedores.
Pongamos que primero vamos a cargar los datos en la Tabla proveedores. Las tres primeras sentencias para cargar los tres primeros registros serían:
INSERT INTO Proveedores (idProveedor, NombreProveedor, ContactoProveedor, Telefono) VALUES(1,"Arroces La Cigala","Maria Alvarez","677889922");
INSERT INTO Proveedores (idProveedor, NombreProveedor, ContactoProveedor, Telefono) VALUES(2,"Arroces La Cigala","Maria Alvarez","677889924");
INSERT INTO Proveedores (idProveedor, NombreProveedor, ContactoProveedor, Telefono) VALUES(3,"Azucarera Sevillana","Rodrigo Mendez","622525885");
En el módulo que creamos en el ejercicio anterior, y que bautizamos con el nombre “PracticasConSQL”, creamos el siguiente procedimiento para ejecutar estas sentencias SQL:
Estas sentencias SQL, al ser sentencias de modificación de datos que no afectan a la estructura de la BBDD, podríamos haberla ejecutado desde la vistaSQL en el interfaz de Access. No obstante, vemos como hacerlo por código en VBA, por si tuviéramos muchos datos y tuviéramos que leerlos de un fichero.
Paso 2: Borrando registros erroneos
Inmediatamente después de la carga nos damos cuenta que el segundo registro en realidad está duplicado, tenía el campo del Teléfono mal. Decidimos eliminar el registro completo, lo cual hacemos ejecutando la siguiente sentencia SQL:
DELETE Proveedores.idProveedor, Proveedores.NombreProveedor, Proveedores.ContactoProveedor, Proveedores.Telefono
FROM Proveedores
WHERE (Proveedores.idProveedor=2);
En esta ocasión, lo hacemos desde la vistaSQL de Access.
Paso 3: Actualizando datos
Ya hemos visto como cargar un registro nuevo en una tabla y como borrarlo completamente, nos queda aprender a actualizar el valor de un campo, sin afectar al resto del registro.
Supongamos que Rodrigo Mendez, el contacto de Azucarera Sevillana nos llama para decirnos que ha cambiado el teléfono, que su nuevo numero es 698527414.
Tendríamos que actualizar el número de teléfono de este contacto, para lo que podemos usar la siguiente sentencia SQL:
UPDATE Proveedores SET Proveedores.Telefono = "698527414"
WHERE (Proveedores.ContactoProveedor="Rodrigo Mendez");
Si ejecutamos ahora esta sentencia SQL, veremos como se nos actualiza el valor del teléfono de Rodrigo Mendez. He establecido la condición por el nombre del contacto, pero podía haberlo hecho por el número de registro (el 3).
NOTA:
Este post es parte de la colección “Sistemas de acceso y almacenamiento de datos”. Puedes ver el índice de esta colección aquí.
SQL significa Structured Query Language, que puede ser traducido como lenguaje de consultas estructuradas. Luego se trata de un lenguaje de programación que emplearemos para hacer consultas. Y es el lenguaje de programación más ampliamente usado para trabajar con bases de datos relacionales.
¿Qué es SQL?
Por tanto, podemos definir SQL como un lenguaje de programación que emplearemos para gestionar las bases de datos relacionales.
En este apartado, vamos a ver como pasar los datos de un fichero a una base de datos relacional, y de esta manera organizar nuestros datos de manera más eficiente y evitar errores. Para verlo en la práctica, trasladaremos los datos del fichero de proveedores de Antonio a una base de datos Access.
Paso 1: Creamos una base de datos
Creamos una base de datos nueva, le ponemos el nombre que queramos, por ejemplo: Proveedores
Paso 2: Creamos una tabla con todos los datos del fichero
Lo primero que haremos, será traernos todos los datos de nuestro fichero de proveedores a una única tabla. Lógicamente, en esta tabla vamos a tener mucha información redundante, ya que sencillamente vamos a copiar la estructura de nuestro fichero.
Para poder explicar adecuadamente el proceso, he generado algunos datos más, e introducido algunos errores que perfectamente podrían haberse cometido al registrar la información en un fichero y repetir ciertos datos varias veces. Nuestros datos de partida serían:
Tabla de datos
Paso 3: Definiendo las estructuras de las nuevas tablas
Estudiando la estructura de nuestros datos, vemos que hay cierta información, la relativa a los datos del proveedor, que se repite varias veces en varios registros. Por el contrario, la información de producto varia de un registro a otro, incluso cuando el producto es el mismo, pueden tener distinto precio.
En esta situación, lo que tiene sentido es crear una tabla para los datos de proveedores con los siguientes campos: NombreProveedor, ContactoProveedor y Telefono. Y una segunda tabla con los datos Producto y Precio.
Tabla1:
NombreProveedor.
ContactoProveedor.
Telefono
Tabla2:
Producto.
Precio.
Paso 4: Relación entre las tablas creadas
No obstante, si sencillamente separamos los datos, y los colocamos en tablas independientes, estaríamos perdiendo información muy valiosa, no sabríamos que producto con que precio corresponde a cada proveedor.
Tenemos que establecer una relación entre las dos tablas creadas, de forma que no se pierda información, que sepamos que producto corresponde a cada proveedor. Necesitamos por tanto un campo en la Tabla2 que identifique de forma univoca al proveedor. Este campo, lo tenemos que tener también en la Tabla1 para poder establecer la relación.
Escogemos NombreProveedor de Tabla1 como campo para la relación. Podríamos haber escogido cualquier otro, siempre que no tuviera valores repetidos, ya que si los tuviera, ese duplicado representaría a dos proveedores, y no tendríamos forma en Tabla2 de saber a cual de los dos nos referimos.
La estructura definida para nuestra BBDD tendría el siguiente aspecto:
Relaciones entre tablas
Paso 5: Chequeando y mejorando la calidad de los datos
Antes de proceder a la creación de las nuevas tablas, debemos chequear la calidad de los datos. Para ello vamos a realizar diversas consultas sobre la tabla de partida que contiene todos los datos:
Consulta_1: Calidad_NombreProveedor
Para chequear los datos de los nombres de Proveedores. Agrupamos los nombres de los proveedores y contamos las veces que aparecen.
El código SQL de la consulta sería:
SELECT FicheroInicialProveedores.NombreProveedor, Count(FicheroInicialProveedores.NombreProveedor) AS CuentaDeNombreProveedor
FROM FicheroInicialProveedores
GROUP BY FicheroInicialProveedores.NombreProveedor
ORDER BY FicheroInicialProveedores.NombreProveedor;
Más adelante introduciremos el lenguaje SQL, de momento, para esta práctica, sencillamente crearemos una consulta en Access y, en la vistaSQL, copiaremos la sentencia SQL de la consulta.
Ejecutamos la consulta y obtenemos el siguiente resultado:
Resultado de la consulta cuenta de proveedores
Podemos observar que hay dos registros “sospechosos”:
“Azucarera Sevilana” seguramente es erróneo y corresponde a “Azucarera Sevillana”, sencillamente nos comimos una “l” al introducir dicho registro.
De igual forma, “Frutas Gutierez” es erróneo, en realidad es “Frutas Gutierrez”, en este caso nos comimos una “r”.
Consulta_2: Corrección_NombreProveedor
Al manejar tan pocos datos en esta practica, podríamos estar tentados de actualizar los datos directamente en los registros afectados. Pero en una situación real, con muchísimos más registros, estas actualizaciones no podemos realizarlas de manera manual una a una, sino que las realizaríamos mediante consultas de actualización.
La primera de las consultas de actualización sería:
UPDATE FicheroInicialProveedores SET FicheroInicialProveedores.NombreProveedor = "Azucarera Sevillana"
WHERE (((FicheroInicialProveedores.NombreProveedor)="Azucarera Sevilana"));
Si ejecutamos la consulta, buscamos los registros que tengan nombre de proveedor: “Azucarera Sevilana” y le cambiamos el valor a “Azucarera Sevillana”.
Lógicamente, la consulta para corregir el nombre de Frutas Gutierez sería la misma con otros literales:
UPDATE FicheroInicialProveedores SET FicheroInicialProveedores.NombreProveedor = "Frutas Gutierrez"
WHERE (((FicheroInicialProveedores.NombreProveedor)="Frutas Gutierez"));
Tras ejecutar estas dos consultas de actualización, ejecutamos la anterior consulta: Consulta_1: Calidad_NombreProveedor
El resultado que obtenemos ahora es el siguiente:
Consulta cuenta de proveedores
Donde ya no detectamos registros de NombreProveedor que sean erróneos.
Consulta_3:Calidad_ContactoProveedor:
Realizamos una operación similar para los datos del campo: ContactoProveedor y veremos que en este caso no detectamos errores.
Consulta_4: Calidad_Tabla1
Y finalmente, realizamos la consulta sobre todos los datos de la que sería nuestra Tabla1, con la información de proveedores.
En este caso si detectamos errores, hay algunos contactos que aparecen con más de un número de teléfono, lo que es erróneo, se produce porque nos hemos equivocado cuando introducimos los datos.
La sentencia SQL de esta consulta sería:
SELECT FicheroInicialProveedores.NombreProveedor, FicheroInicialProveedores.ContactoProveedor, FicheroInicialProveedores.Telefono, Count(FicheroInicialProveedores.NombreProveedor) AS CuentaDeNombreProveedor
FROM FicheroInicialProveedores
GROUP BY FicheroInicialProveedores.NombreProveedor, FicheroInicialProveedores.ContactoProveedor, FicheroInicialProveedores.Telefono;
Si la ejecutamos, obtendríamos el resultado:
Consulta que muestra los errores de introducción
Donde podemos ver dos resultados con cuenta 1, que probablemente sean erróneos. Para aquellos proveedores que tienen más de un número de teléfono, habría que asegurarse de cual de ellos es el correcto, y actualizar los datos en la tabla vía consultas de actualización.
Tras corregir estos errores, si ejecutamos de nuevo la Consulta_4: Calidad_Tabla1, obtendremos:
Consulta que muestra que se han corregido los errores
Donde ya no detectamos errores.
NOTA: La información de producto también convendría repasarla e intentar mejorar la calidad de los datos. No obstante, eso queda fuera del objetivo de esta práctica
Paso 6: Generando las nuevas tablas
Una vez hemos revisado la tabla con todos los datos de proveedores, y corregido los errores detectados, vamos a crear las nuevas tablas definidas en el Paso 4.
Consulta_5: Creación_Tabla1
Ejecutamos la siguiente consulta para generar la tabla de proveedores:
SELECT FicheroInicialProveedores.NombreProveedor, FicheroInicialProveedores.ContactoProveedor, FicheroInicialProveedores.Telefono INTO Proveedores
FROM FicheroInicialProveedores
GROUP BY FicheroInicialProveedores.NombreProveedor, FicheroInicialProveedores.ContactoProveedor, FicheroInicialProveedores.Telefono
ORDER BY FicheroInicialProveedores.NombreProveedor;
Tras su ejecución, veremos que hemos creado la Tabla Proveedores que corresponde a la Tabla1 de nuestra estructura.
A continuación, generaremos la otra tabla de nuestra estructura, la que contiene la información de Productos. Hay que recordar que en esta tabla necesitamos tener también el campo NombreProveedor, ya que será el que usemos para establecer la relación con la Tabla1.
Consulta_6: Creación_Tabla2
Ejecutamos la siguiente instrucción SQL para generar la Tabla2:
SELECT FicheroInicialProveedores.NombreProveedor, FicheroInicialProveedores.Producto, FicheroInicialProveedores.Precio INTO ProductosEnProveedores
FROM FicheroInicialProveedores
ORDER BY FicheroInicialProveedores.NombreProveedor;
Tras ejecutar ambas consultas, tendremos dos nuevas tablas: Proveedores y ProductosEnProveedores. Estas tablas se relacionarán por medio del campo NombreProveedor:
Nuevas relaciones
Paso 7: Accediendo a los datos
Mediante la relación definida entre los campos NombreProveedor de ambas tablas, podremos acceder a los datos de ambas tablas de manera combinada.
Imaginemos que queremos saber que proveedores nos pueden suministrar Naranjas. En este caso podríamos emplear únicamente la Tabla “ProductosEnProveedores” porque en ella tenemos toda la información que estamos buscando.
Pero si queremos que también nos aparezca en la consulta el contacto del proveedor y el teléfono, porque estamos buscando los proveedores que nos pueden suministrar Naranjas para realizar un pedido. En este caso, necesitamos recuperar datos de ambas tablas de manera coordinada.
Consulta_7: Naranjas
Ejecutamos la siguiente instrucción SQL para obtener la información de los proveedores que suministran Naranjas y poder hacerles un pedido.
SELECT Proveedores.NombreProveedor, Proveedores.ContactoProveedor, Proveedores.Telefono, ProductosEnProveedores.Producto, ProductosEnProveedores.Precio
FROM Proveedores INNER JOIN ProductosEnProveedores ON Proveedores.NombreProveedor = ProductosEnProveedores.NombreProveedor
WHERE (((ProductosEnProveedores.Producto)="Naranja"));
La instrucción INNER JOIN es la que define la relación entre ambas tablas, pero esto lo veremos más adelante cuando aprendamos SQL.
Si ejecutamos la consulta, obtendríamos el siguiente resultado:
Consulta relacionando datos de distintas tablas
Paso 8: Conclusiones
Repasemos lo que hemos hecho para entender el cambio de paradigma que supuso la irrupción de las bases de datos relacionales.
Previamente almacenábamos los datos en ficheros y registrábamos toda la información cada vez que insertábamos una nueva información. En nuestro ejemplo, teníamos que introducir de nuevo todos los datos del proveedor, aunque sólo quisiéramos registrar un nuevo producto para un proveedor ya conocido y registrado. Esto al final ocasionaba muchos errores y una perdida importante de calidad en los datos.
Con las bases de datos relacionales, estructuramos los datos en tablas y definíamos relaciones entre ellas que nos permitían recuperar todos los datos que necesitáramos. De esta forma evitábamos introducir la misma información muchas veces, minimizábamos errores y contribuíamos a mantener la calidad de nuestros datos.
Además, definíamos una estructura de datos que era independiente del soporte físico que almacenaba los datos, dejando a los gestores de BBDDs (software) gestionar la interacción de nuestra estructura con el soporte físico de los datos. Por supuesto, este nivel de abstracción facilita enormemente el trabajo con los datos y reduce el número de errores.
NOTA:
Este post es parte de la colección “Sistemas de acceso y almacenamiento de datos”. Puedes ver el índice de esta colección aquí.
La base de datos relacional vino a dar respuesta a la necesidad de estructurar la información que se venía manejando en distintos ficheros. La creciente cantidad de datos con los que se trabajaba hacía que cada vez se crearan más ficheros con datos y forzó a encontrar una manera eficiente de estructurar toda esa información.
¿Qué es una base de datos relacional?
En realidad, una base de datos relacional no es otra cosa que un software que nos permite manejar estructuras de datos entre las que se crean relaciones. De esta forma, los datos no están aislados en las distintas estructuras, sino que están relacionados a través de las relaciones que se crean entre partes de estas estructuras.
Las estructuras en una base de datos relacional son las tablas, compuestas de varias columnas y filas. Las columnas representan los atributos de los datos que queremos almacenar, que normalmente denominaremos campos. Y en cada fila registramos un conjunto de valores para los distintos atributos, conformando lo que denominaremos un registro.
Para las organizaciones, sus datos son cruciales, y no pueden arriesgarse a perderlos ante un eventual fallo de los sistema de almacenamiento. Tanto es así, que no se conforman con los sistemas de redundancia de datos, sino que implementan sistemas de copias de seguridad, que realizan copias temporales de los datos en soportes adicionales. De esta forma, ante un fallo grave de los sistemas de negocio, se dispondrían de unos datos de respaldo que permitirían recuperar la actividad, sin perdida significativa de información y sin dañar el negocio.
El soporte más habitual empleado por estos sistemas son las cintas magnéticas, que proporcionan un modo de acceso secuencial a los datos. Son por tanto menos versátiles que los discos duros que proporcionan un modo de acceso aleatorio, pero el coste de almacenamiento es más bajo.
Los sistemas de copias de seguridad, realizan una copia temporal de los datos, en un instante concreto. Es decir, es una foto fija de los datos que tenemos en un instante. Si posteriormente modificamos esos datos, no tendríamos copia de las modificaciones. Esto habrá que tenerlo muy en cuenta cuando definamos nuestras políticas de copias de seguridad y la periodicidad con la que realizamos las copias de respaldo. Por ejemplo, si realizamos un copia de seguridad total todos los lunes, y tenemos un fallo de sistema un viernes, al recuperar los datos volveríamos atrás a los datos que teníamos el lunes, habríamos perdido todas las modificaciones realizadas desde el martes al viernes. En cualquier caso, perder las actualizaciones de algunos datos, el trabajo de algunos días, es asumible frente a perder toda la información y tener que parar el negocio.
Las arquitecturas de almacenamiento podemos clasificarlas en dos tipos atendiendo al acceso requerido, ya sea directamente a fichero o a disco duro. Veamos ambos tipos
Acceso a disco duro: También llamado acceso a bloques, este tipo de acceso se da cuando el cliente requiere acceder directamente al disco. El sistema de ficheros del ordenador cliente gestionara los accesos a disco. Entonces, pueden darse tres situaciones:
1.- Disco interno: El cliente este accediendo al disco interno de su ordenador. Lo haría empleando los buses internos del ordenador, si se trata de un ordenador personal probablemente utilizaría ATA o SATA, y si es un servidor seguramente emplearía SCSI.
2.- DAS (Direct attached storage): El cliente accede a una cabina de discos duros directamente conectada a su ordenador.
3.- SAN (Storage Area Network): En este caso el cliente también accede a una cabina de discos duros pero esta vez no está directamente conectada al ordenador, sino que está en red.
Acceso a fichero: El cliente trabaja a nivel de fichero, que solicita a un servidor NAS (Network attached storage) que se ocupa de todas las gestiones.
En la siguiente figura pueden apreciarse las cuatro arquitecturas de almacenamiento comentadas:
Un RAID (Redundant array of independent disks) o Sistema RAID, es un conjunto de discos redundantes e independientes. Redundantes porque van a guardar información redundante para asegurar la tolerancia a fallos y mejorar la disponibilidad. E independientes, porque no existe dependencia entre ellos, lo que nos permite sustituir cualquier disco del conjunto por uno nuevo, y funcionará perfectamente con los discos que ya teníamos.
Este tipo de agrupaciones de discos, tiene como objetivo mejorar las prestaciones que podríamos alcanzar con un único disco. Dependiendo del tipo de combinación podremos mejorar la seguridad, la capacidad de almacenamiento o la disponibilidad de los datos. Y el controlador del sistema se ocupará de que, para el servidor, esta combinación de discos aparezca como uno sólo, bajo la misma letra de unidad.
