En este post, vamos a ver como pasaríamos de guardar los datos en un fichero a guardarlos en una base de datos relacional, trasladaremos los datos del fichero de proveedores de Antonio a una BBDD 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:

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:

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:

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:

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:

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:

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 relacionaran por medio del campo NombreProveedor:

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:

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 “Arquitectura de Datos” que reproduce los apuntes de la clase que imparto sobre el tema en ESIC. Puedes ver el índice de esta colección aquí.