Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0

UNIVERSIDAD DE VALLADOLID ESCUELA TÉCNICA SUPERIOR DE INGENIEROS DE TELECOMUNICACIÓN TRABAJO FIN DE GRADO GRADO EN INGENIERÍA DE TECNOLOGÍAS ESPECÍFICAS DE TELECOMUNICACIÓN, MENCIÓN EN TELEMÁTICA Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 AUTOR: D. Julián Rodríguez Hernández Tutor: Dr. D. Ignacio de Miguel Jiménez Valladolid, 30 de Junio de 2021 TÍTULO: Diseño e implementación de una base de datos para un cuadro de mando para la Industria 4.0 AUTOR: D. Julián Rodríguez Hernández TUTOR: Dr. D. Ignacio de Miguel Jiménez DEPARTAMENTO: Teoría de la Señal y Comunicaciones e Ingeniería Telemática TRIBUNAL PRESIDENTE: D. Evaristo J. Abril Domingo VOCAL: D. Juan Carlos Aguado Manzano SECRETARIO: D. Ignacio de Miguel Jiménez SUPLENTE: D. Ramón J. Durán Barroso SUPLENTE: Dña. Noemí Merayo Álvarez RESUMEN La irrupción y el auge del Big Data deriva y desemboca en multitud e innumerables colecciones de datos, las cuales deben ser almacenadas en “algún lugar” para posteriormente ser utilizadas y realizar diferentes operaciones o procesos de análisis, y evaluación que se requiera con los mismos. En muchas ocasiones, estos procesos están apoyados en cuadros de mando o dashboards, de tal manera que nos proporcionan una apariencia más visual e intuitiva, a la vez que se pueden realizar múltiples escenarios en el acto. Ahora bien, muchas empresas siguen dependiendo fuertemente de hojas de cálculo Excel para almacenar información, cuando en muchas ocasiones es más eficiente el uso de bases de datos. El objetivo de este proyecto consiste en partir de la información almacenada actualmente por una hipotética empresa en una hoja Excel (potencialmente voluminosa), diseñar e implementar una base de datos para almacenar dicha información, con el objetivo de que sirva como soporte para un cuadro de mando o dashboard. Para ello se parte de unas determinadas especificaciones que marcan las directrices que posee un archivo Excel, el cual contiene esa colección de datos. Una vez analizadas las pautas del archivo Excel se desarrolla el diseño de la base de datos y su implantación funcional. Para acabar desplegando un script de migración que hace posible y efectiva la exportación de los datos albergados primeramente en el archivo Excel hacia la base de datos diseñada. Finalmente se pone en funcionamiento todo el conjunto global diseñado. PALABRAS CLAVE Datos, archivo Excel, migración, base de datos, dashboard ABSTRACT The emergence and rise of Big Data derives and leads to a multitude and countless collections of data, which must be stored "somewhere" to be used later and perform different operations or processes of analysis and evaluation that are required with them. In many cases, these processes are supported by dashboards, in such a way that they provide us with a more visual and intuitive appearance, at the same time as multiple scenarios can be carried out on the spot. However, many companies still rely heavily on Excel spreadsheets to store information, when in many cases it is more efficient to use databases. The objective of this project is to start from the information currently stored by a hypothetical company in an Excel sheet (potentially voluminous), design and implement a database to store this information, with the aim of serving as a support for a dashboard. To do this, we start from certain specifications that mark the guidelines that an Excel file has, which contains that collection of data. Once the guidelines of the Excel file have been analysed, the design of the database and its functional implementation are developed. Finally, a migration script is deployed to make possible and effective the exportation of the data firstly stored in the Excel file to the designed database. In the end, the entire designed global set is put into operation. KEYWORDS Data, Excel file, migration, database, dashboard AGRADECIMIENTOS En primer lugar, quiero dar las gracias a mi tutor Nacho, por haberme dado la oportunidad de desarrollar este TFG, por toda su ayuda, asesoramiento y consejos compartidos a lo largo de este camino, sin el cual no habría sido posible llevarlo a cabo. Me gustaría también mencionar y agradecer a todos los miembros del Grupo de Comunicaciones Ópticas, los cuales me han acogido y proporcionado un ambiente afectuoso y familiar durante mi estancia y desarrollo de las prácticas en él. Muchas gracias a mi compañero Pablo, quien paralelamente estaba desarrollando el cuadro de mando para el cual ofrecería y serviría mi base de datos creada, con el que me he entendido y compenetrado a la perfección durante su elaboración y por compartir multitud de conversaciones fortalecedoras. Quiero manifestar y mostrar todo mi agradecimiento a mis padres, Jose e Isabel, y a mi hermana Isabel, por creer siempre en mí y estar siempre a mi lado mostrando su apoyo incondicional. Finalmente, agradecer a mis compañeros de titulación, especialmente, Francisco, Rodrigo y Sergio, todo el apoyo y ayuda durante la realización de la misma y por todas las vivencias compartidas durante estos años. Capítulo 1: Introducción 1 1 Introducción Este primer capítulo introductorio de la presente memoria del Trabajo Fin de Grado refleja las motivaciones vigentes para llevarse a cabo y los objetivos que se pretenden lograr mediante desarrollo y realización del proyecto implicado. Del mismo modo, se presentan las pautas o fases marcadas para su consecución y las herramientas o medios empleados para la obtención del conjunto global. Finalmente, para concluir se describe la estructura y distribución del resto del documento. 1.1 Motivación En la actualidad, casi la totalidad de las empresas basan sus operaciones, transacciones o registros de los innumerables datos con los que trabajan apoyándose en las bases de datos. Pero esto antes no era así como tal, y tenían que basar ese apoyo en un papel o cuaderno en el que plasmar los registros pertinentes de lo que se quisiera reflejar. Posteriormente, se fue introduciendo el mismo método, pero en formato electrónico, y en muchos casos utilizando la aplicación informática Microsoft Excel. Si anteriormente se plasmaban los datos de manera física, es decir, a puño y letra en una hoja de un cuaderno o individual e independiente, con la ayuda de este otro software el registro poseía el mismo fin, pero cambiando el modo o método, ya que bastaba con encender el equipo en el que estuviese instalada dicha aplicación y anotar en sus hojas de cálculo los datos que se precisara. Sin embargo, Excel es una aplicación dirigida realmente a analizar datos y no a administrarlos, pues no es realmente un Sistema de Gestión de Bases de Datos. El último de los pasos para la mejora y sofisticación del hecho acaecido en las anteriores líneas es, como ya anunciaba al principio, el registro y almacenamiento de todos Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 2 ellos en bases de datos, desde y con las cuales apoyarse e interactuar para consultar o modificar cualquiera de los datos de referencia involucrados en la operación que se disponga a llevar a cabo. Todavía es común que muchas empresas almacenen sus datos en hojas de cálculo en lugar de en auténticas bases de datos, y ese es el escenario de partida que toma este TFG. Se asume una empresa ficticia que tiene sus datos almacenados actualmente en hojas de cálculo Excel y que desea migrarlos hacia una base de datos. El objetivo del TFG es por tanto doble. Por un lado, se trata de diseñar y crear una base de datos que dé cabida a dicha colección de datos. Por otro, se trata de diseñar e implementar un procedimiento para migrar esos datos desde las hojas de cálculo hacia la base de datos, teniendo en cuenta además que dichos datos puedan ser objeto de cualquiera operación que se desee desempeñar a través de un cuadro de mando. Puesto que el TFG asume una empresa ficticia, parte del trabajo realizado en el mismo ha consistido en la generación de los datos de partida en Excel, y con respecto a la elaboración de un cuadro de mando, ese ha sido el objetivo de un Trabajo Fin de Máster relacionado [1]. 1.2 Objetivos del TFG 1.2.1 Objetivo general El objetivo global de todo el conjunto de desarrollo del Trabajo Fin de Grado es diseñar e implementar una base de datos que sirva como soporte para un cuadro de mando o dashboard y, a su vez, migrar datos recogidos y almacenados en un archivo Excel a la base de datos diseñada previamente. 1.2.2 Objetivos específicos Para llegar a lograr lo descrito en el párrafo anterior, lo mejor será identificar y señalar una serie de objetivos específicos que deberán ser alcanzados a lo largo de las distintas fases del proyecto. Estos objetivos específicos son: • Diseñar y crear datos relacionados consecuentemente en un archivo Excel a partir de unas especificaciones dadas. (Puesto que el TFG se va a desarrollar suponiendo un escenario hipotético, es necesario crear de forma Capítulo 1: Introducción 3 sintética los datos de partida, y ese es, por tanto, uno de los primeros objetivos del proyecto). • Diseñar, crear e implementar una base de datos. • Desarrollar una herramienta automatizada (script) que permita la exportación y migración de datos desde un archivo Excel hacia una base de datos. • Implementar y poner en funcionamiento en un entorno global todos los objetivos citados anteriormente. 1.3 Fases y pautas para el desarrollo del TFG Una vez reconocidos y marcados los objetivos que se pretenden desarrollar, el planteamiento llevado a cabo para hacerlos posibles ha sido designar y seguir una serie de fases evolutivas y, en consecuencia, mediante las cuales poder llegar a conseguirlo con éxito: 1. Propuesta de un escenario de partida de una empresa que dispone de datos almacenados en Excel y desea migrarlos hacia una base de datos. 2. Creación de un archivo Excel con datos ficticios pero consecuentes con los especificado en el escenario de partida. 3. Reconocimiento y comparación de diferentes herramientas y tecnologías como alternativas para el diseño e implementación de la base de datos. 4. Familiarización con las herramientas y tecnologías elegidas. a. WampServer b. MySQL c. phpMyAdmin 5. Fase de diseño, desarrollo y despliegue de la base de datos. Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 4 6. Análisis y planteamiento para la migración de los datos desde el archivo Excel a la base de datos creada. 7. Creación y desarrollo del script automatizado para la migración de los datos desde el archivo Excel a la base de datos creada. 8. Fase de despliegue y evaluación del conjunto creado. 9. Fase de revisión, corrección y consolidación del conjunto global. 10. Obtención y evaluación de resultados. 11. Planteamiento y extracción de conclusiones. 12. Elaboración del documento de la memoria del Trabajo Fin de Grado. 1.4 Herramientas utilizadas en la realización del TFG Para la realización de todo el trabajo completo se ha requerido del uso de determinadas herramientas, aplicaciones software y lenguajes de programación además de multitud de horas de trabajo a papel y bolígrafo para realizar los primeros bocetos enfocados al diseño de la base de datos. Como recogía y las anunciaba en el apartado anterior 1.3, tres son las herramientas fundamentalmente sobre las que se cimienta este TFG. En primer lugar, la instalación de la aplicación software WampServer [2], la cual está compuesta por una pila o conjunto de soluciones software que presentan diferentes prestaciones. El acrónimo Wamp, que forma parte del nombre, tiene el siguiente significado: • W, de soporte únicamente para sistema operativo Windows. Es el sistema operativo base empleado para la realización de este TFG. • A, de servidor Apache. Ofrece disponer de un servidor web local en nuestro equipo. • M, con relación a MySQL. Incluye sistema de gestión de bases de datos relacionales MySQL. Capítulo 1: Introducción 5 • P, perteneciente al lenguaje de programación PHP. Mediante el cual poder crear o emplear multitud de herramientas operacionales al ejecutarse junto con Apache y comunicarse con MySQL. MySQL ha sido el sistema de gestión de bases de datos relacionales elegido y mediante el cual se ha ido dando forma y confeccionando la base de datos. Poniendo en ejecución la aplicación anterior se puede hacer uso de otra de las herramientas implicadas, que es phpMyAdmin. Se trata de un software gratuito, el cual también viene instalado internamente al hacer lo propio con WampServer. Este permite realizar un manejo de la administración y gestión de la base de datos mediante una API establecida a la que se tiene acceso a través del navegador. Admite un amplio abanico de operaciones con bases de datos, tablas, relaciones, índices, etc., que se pueden realizar mediante la interfaz de usuario, ejecutándose bajo la comunicación de MySQL. De la misma manera, también posee un cuadro de diálogo donde poder ejecutar directamente declaraciones SQL. Otra de las herramientas de las que se ha necesitado su uso, es de un editor de texto, en el cual desarrollar todo el código descrito en lenguaje PHP, para conseguir realizar la migración automatizada a la nueva base de datos de los datos recogidos hasta el momento únicamente en el archivo Excel. 1.5 Estructura de la Memoria del TFG El desarrollo del presente documento está distribuido de la siguiente manera: 1. Empezando por el capítulo en el que nos encontramos, Capítulo 1, se ha introducido una pequeña presentación, no exhaustiva, del TFG. Qué es lo que se pretende conseguir y cómo se ha llevado a cabo. 2. El Capítulo 2 proporciona el marco teórico asociado al TFG. 3. Una vez identificados los temas a abordar es hora de ponerse a desarrollarlos. Por ello, el Capítulo 3 presenta el escenario hipotético que se plantea resolver, y así realiza una descripción detallada del funcionamiento que está realizando Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 6 la empresa ficticia ACME para obtener los requisitos necesarios con los que poder diseñar y desarrollar la base de datos óptima. 4. Todo el diseño y desarrollo de la base de datos viene enmarcado y explicado en el Capítulo 4. 5. En poder de la base de datos, el Capítulo 5 denota cómo se ha realizado la herramienta para la migración de los datos del archivo Excel a la base de datos recientemente diseñada. También se describen y recogen los resultados obtenidos al poner en ejecución y sincronizar la herramienta de migración y la base de datos. 6. Desarrollada la totalidad de los fundamentos que basan el TFG, es hora de extraer y compartir las conclusiones pertinentes al respecto y aportar algunas posibles visiones de futuro. Esto es lo que refleja lo escrito en el Capítulo 6. 7. Finalmente, para concluir el documento se ha introducido un Anexo. Guía de ejecución complementario al final, en el que se detalla un ejemplo de ejecución en el que se puede llevar a cabo todo lo desarrollado a lo largo de la presente memoria de este Trabajo Fin de Grado. Capítulo 1: Introducción 7 Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 8 2 Marco teórico 2.1 Introducción A nadie sorprende ya en los días que vivimos el término base de datos, puesto que llevan siendo utilizadas desde hace mucho tiempo. En concreto, la primera base de datos creada data en la década de los 60 [3]. Si bien es cierto, que cada día con abundante frecuencia desempeñan activamente un papel importante en cualquier acción cotidiana que realizamos a través de cualquier dispositivo electrónico, fundamentalmente. Pero también, un simple ejemplo de ellas es la realización de una lista de la compra, donde plasmamos en un papel los productos y la cantidad de estos necesarios, y de esta manera estamos confeccionando nuestra pequeña base de datos. Otro ejemplo de ellas es nuestra agenda telefónica, en la cual anotamos conjuntamente nombres y números de teléfono con un significado implícito. Otra de las certezas que existe, es que aproximadamente la totalidad de operaciones que se desarrollan en la red están sujetas a una o incluso varias bases de datos. Desde el comercio electrónico, la banca on-line, hasta la reserva de una habitación para unas merecidas vacaciones o para realizar la inspección técnica de tu vehículo necesitan de esa conexión con las mismas. Actualmente, en cualquier actividad desarrollada se genera multitud de información la cual, con cada vez más frecuencia, es recomendable almacenarla en algún lugar para poder tener acceso a ella en un momento dado. Cada vez la cantidad de datos producida es más elevada continuamente, hasta el punto de que ha sido acuñado el anglicismo Big Data para referirnos a ese indeterminado y desmesurado volumen de información. Capítulo 2: Marco teórico 9 Es por ello por lo que, dependiendo de la actividad desarrollada, cantidad y volumen que adquiera esa información así será desarrollado de una u otra manera ese lugar donde depositarla. 2.2 Definición y tipos El significado que le damos al término base de datos puede ser muy amplio y va desde lugar donde se almacena información, hasta conjunto de datos pertenecientes a un mismo contexto y almacenados sistemáticamente para su posterior uso; pasando por estructuras especializadas que permiten a sistemas computarizados guardar, manejar y recuperar datos con gran rapidez; conjunto de datos almacenados en memoria externa que están organizados mediante una estructura de datos, o lugares diseñados para almacenar grandes cantidades de datos de forma sistematizada con el fin de que podamos acceder a ellos de forma rápida y eficiente. No nos podemos quedar con una definición concreta puesto que todas ellas son verídicas, por ello que lo mejor sería realizar una abstracción de ideas de cada una y crear una fusión híbrida a raíz de todas ellas. Dependiendo de la información que se vaya a almacenar en la misma y de la función que se desee desempeñar con ellas, existen distintos tipos de modelado de las bases de datos [4]. Algunos de los más destacados son: • Jerárquicas: la estructura que tienen es semejante a la estructura de un árbol. De un nodo raíz o padre pueden derivar otros nodos (hijos) con el objetivo de preservar los datos organizándose en un orden particular. Podemos hacernos una idea si recordamos como distribuye Microsoft Windows las carpetas y archivos. La Figura 1 representa una idea visual de la distribución de este tipo de bases de datos. Figura 1. Base de datos jerárquica Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 16 • Clave foránea o ajena: columna o conjunto de atributos de una tabla (hija) que se utiliza para “hacer referencia” a una clave, y en consecuencia una fila concreta, en otra tabla (padre o referenciada). Volviendo al ejemplo de la Figura 6, como ya adelantaba previamente, las columnas idCliente, idProducto e idFecha son las claves primarias simples correspondientes en las tablas Cliente, Producto y Fecha respectivamente. En el caso de la tabla Ventas, posee una clave primaria compuesta formada por sus atributos idCliente, idProducto e idFecha. Estos a su vez, pueden ser evidenciados individualmente como tres llaves foráneas haciendo referencia a las columnas con mismo nombre, pero alojadas en cada una de las tres tablas padre restantes, y el conjunto de ellas forman la clave primaria de la tabla Ventas. Otro de los elementos característicos en las bases de datos relacionales son los índices. A simple vista en el ejemplo no pueden ser identificados dado que requeriría conocer en mayor nivel su implementación, no solo en disposición del diagrama relacional. Los índices son atributos designados cuyo cometido es poder ubicar y seleccionar filas de manera eficiente sin tener que rastrear y explorar toda la tabla. Pueden estar compuestos por un único atributo o un conjunto de ellos. Están muy ligados a las claves puesto que mediante las claves podemos realizar las mismas facilidades que nos ofrecen los índices, aunque en ocasiones se puede designar como índice una columna que no es parte de un clave. En el caso concreto de MySQL, clave e índice son sinónimos y, por lo tanto, se puede referir a los atributos o columnas declaradas con esa naturaleza empleando ambos términos. MySQL es un ejemplo de sistema de gestión de bases de datos que más adelante se detallará qué son y para qué se utilizan. En resumen, las características fundamentales y más destacadas en la estructura de un modelo de base de datos relacional son las siguientes: • Una base de datos relacional está compuesta por varias tablas o relaciones. • Las tablas no pueden compartir un mismo nombre. Este debe ser distinto por cada una de ellas. • Cada una de las tablas están formadas a su vez por filas y columnas. • Cada fila de la tabla puede ser llamada también tupla o registro. Capítulo 2: Marco teórico 17 • A cada columna de la tabla se le conoce también como atributo o campo. • Dentro de las tablas, las filas pueden estar en cualquier orden. • En el interior de las tablas, los atributos pueden estar en cualquier orden. • Por definición, todas las filas de una tabla son distintas. No puede haber dos filas exactamente iguales conteniendo los mismos valores. • Las tablas deben tener una clave. Las claves pueden estar formadas por uno o varios atributos. • Las claves primarias son clave principal de una tupla o fila y son las que permiten conseguir la integridad de los datos almacenados. • Las relaciones entre las tablas padre y las tablas hijas se forman mediante las claves establecidas en ellas, claves primarias y foráneas o ajenas respectivamente. • Las claves ajenas de las tablas hijas deben poseer el mismo tipo de datos y los mismos posibles valores que la clave primaria de la tabla padre. • Para cada columna de una tabla se establece un tipo de dato que ostenta un conjunto de valores posibles llamado su dominio. El dominio contiene todos los valores posibles que pueden aparecer en esa columna. • El grado de la tabla es el número de columnas o atributos establecidos en la tabla. • La cardinalidad es el número de filas o tuplas dispuestas en la tabla. 2.3.2 Normalización En general, unos de los resultados implícitos en el diseño de una base de datos relacional es generar un conjunto de tablas que permitan almacenar la totalidad de la información disponible en todas ellas, de tal forma que no exista duplicidad o redundancia alguna y, a la vez, están relacionadas entre sí mediante las claves establecidas en cada una de ellas, permitiendo así acceder y recuperarla fácilmente en el momento que sea estimado oportuno. Esto se consigue mediante el diseño de esquemas de relación que se hallen en la forma normal adecuada. Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 18 La normalización es una técnica de diseño o proceso de reorganización de las bases de datos relacionales en el que se aplican una serie de reglas para poseer una estructura de datos robusta y saneada. El objetivo principal de este proceso es evitar que se produzcan en la base de datos problemas reconocidos en su terminología como anomalías, tales como: • Evitar la redundancia o duplicidad de los datos. • Preservar y proteger la integridad de los datos. • Optimizar el espacio de almacenamiento. • Prevenir problemas de actualización en las tablas. • Reforzar la veracidad y seguridad de los datos. • Facilitar el acceso e interpretación de los datos. • Reducir el tiempo y complejidad de supervisión de la base de datos. La aplicación de la teoría de la normalización garantiza que el diseño es capaz de evitar cualquier anomalía indeseada. Es por ello por lo que las bases de datos relacionales son mucho más robustas y poseen menor vulnerabilidad ante los fallos, cumpliendo con lo que en informática se denomina ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad) [5]. Para garantizar todo ello, como antes decía, existen diferentes niveles normales, que dependiendo del nivel de normalización que quiera adoptar una base de datos, sus tablas deben de cumplir las reglas presentes en cada uno de ellos. Cada uno de los niveles inmediatamente superior incluye con obligatoriedad que se haya adoptado y cumplido las reglas del nivel inferior. La imagen de la Figura 7, mostrada a continuación, nos ayuda a comprender mejor lo descrito en la anterior expresión. Capítulo 2: Marco teórico 19 Figura 7. Niveles de normalización A continuación, y sin entrar en detalles de exhaustiva profundidad, se especifican los niveles y sus correspondientes reglas [4]: • Primera forma normal (1FN) ▪ Cada una de las columnas o atributos debe poseer nombre único. ▪ Cada columna o atributo debe albergar un único tipo de dato. ▪ Cada columna o atributo tiene que contener un único valor. ▪ Dos o más filas no pueden contener valor idéntico. ▪ El orden de las filas o columnas es irrelevante. ▪ Las columnas no pueden contener grupos repetidos. • Segunda forma normal (2FN) ▪ Estar en primera forma normal (1FN). ▪ Todos los campos o atributos que no son clave dependen de todos los campos o atributos que son clave. Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 20 • Tercera forma normal (3FN) ▪ Estar en segunda forma normal (2FN). ▪ No puede contener dependencias transitivas. Una dependencia transitiva se produce cuando el valor de un campo que no es clave depende del valor de otro campo que tampoco es clave. • Forma normal de Boyce-Codd (BCFN) ▪ Estar en tercera forma normal (3FN). ▪ Todos los determinantes son a su vez claves candidatas. Un determinante es un campo o atributo que determina el valor en otro de los campos. • Cuarta forma normal (4FN) ▪ Estar en la forma normal de Boyce-Codd (BCFN). ▪ No puede contener una dependencia multivaluada no relacionada (también se le reconoce como dependencia multivaluada independiente). Se conoce como atributo multivaluado o de valor múltiple a aquel atributo que puede contener dos o más valores para un determinado valor de la clave. Y se produce una dependencia multivaluada cuando dos o más atributos pueden adoptar múltiples valores para un mismo valor de clave y dichos atributos son independientes entre sí. • Quinta forma normal (5FN) ▪ Estar en cuarta forma normal (4FN). ▪ Puede contener dependencias multivaluadas no relacionadas ya que la tabla no puede ser fragmentada más sin que dé lugar a pérdida de información. Un esquema relacional de base de datos que satisface todos los niveles o formas de normalización da lugar a un esquema que arroja la suficiente claridad y donde cada Capítulo 2: Marco teórico 21 acontecimiento elemental producido en la misma estará correctamente definido y distinguido del resto. No obstante, en algunos modelos o diseños se pueden implementar redundancias o agrupaciones de datos por motivos específicos, como pueda ser realizar una búsqueda más con mayor rapidez y aumentar así el rendimiento en la lectura, o necesidades de la propia empresa que la gestiona y violar así algunas de las reglas especificadas en los diferentes grados de normalización. A ese proceso se le conoce como desnormalización. 2.3.3 Sistemas Gestores de Bases de Datos Relacionales (SGBDR) Los sistemas de gestión de bases de datos relacionales (SGBDR) son servicios o herramientas software que permiten crear, gestionar y administrar las bases de datos relacionales, así como elegir o manejar las estructuras necesarias para almacenar y buscar los datos de la información contenida de la manera más eficiente a la vez que garantiza la seguridad y la integridad de estos. Mediante ellos podemos crear, eliminar, modificar, leer y actualizar (funciones más básicas en cualquier base de datos) la información en nuestra base de datos. Algunos ejemplos de estos sistemas de gestión más populares y arraigados son: MySQL, Oracle Database, Microsoft SQL Server, PostgreSQL, IBM Db2, SQLite y Microsoft Access. Otro ejemplo es MariaDB. Este sistema está relacionado directamente con MySQL, ya que es una derivación del mismo y comparten la mayoría de las características, aunque incluye algunas extensiones más. Es propiedad de Oracle Corporation [6]. Dependiendo de las características que posea la base de datos que queramos administrar y gestionar, en función del ámbito en el que se vaya a englobar a la misma y reconociendo el abanico de criterios para el manejo de esta, se deberá decir por uno u otro. Aunque en muchos de los casos el principal motivo para decidir la elección entre unos y otros viene residido en el precio del coste que hay que abonar por hacer uso de este, dado que algunos de ellos carecen de gratuidad y exigen de pago. La Figura 8, presente en la siguiente página, muestra un gráfico de la evolución en función de la popularidad de los mismos. Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 22 Figura 8. Popularidad de los sistemas gestores de bases de datos relacionales más utilizados (Fuente: www.db-engines.com) MySQL Es un sistema de gestión de código abierto y cuenta con licencia pública y gratuita para poder disfrutar de su uso. En la actualidad es propiedad de Oracle Corporation, aunque cuando se creó se desarrolló como un proyecto independiente a esta sociedad, la cual luego lo absorbió. Su funcionamiento está basado en el modelo cliente-servidor. Hace uso del lenguaje de consulta estructurado SQL (Structured Query Language). Soporta compatibilidad multiplataforma con los principales sistemas operativos más utilizados, entre ellos los más destacados del mercado: Linux, Mac y Windows. Su uso no necesita de unos requisitos elevados en cuanto a propiedades de recursos clave del ordenador (CPU, disco duro, RAM…). Este gestor ofrece niveles de rendimiento y eficiencia de los más elevados del mercado, dado que posee una elevada velocidad para realizar las operaciones, a la vez que hace un uso bajo de los recursos. Se trata de un sistema muy flexible y fácil de usar, a la vez que nos proporciona un nivel muy elevado de seguridad. Ofrece una gran capacidad de integración con lenguajes como, por ejemplo, PHP o .NET para dar forma a la creación de innumerables aplicaciones web, la sinergia conseguida de la asociación Apache-MySQL-PHP es de las más utilizadas para ello. En su contra reside que no es un gestor recomendado para hacer uso del mismo con bases de datos de tamaño elevado [7]. Capítulo 2: Marco teórico 23 Oracle Database Es el otro principal competidor por alzarse con la corona del sistema de gestión de bases de datos relacionales más usado en la actualidad. Ha sido desarrollado por la compañía Oracle Corporation. Es multiplataforma, puede ser utilizado en los diferentes sistemas operativos instalados. La principal diferencia que existe con MySQL es que se trata de un sistema de gestión de bases de datos que para disfrutar de su amplia variedad de funciones requiere de subscripción por pago, ya que es un software con licencia privada y enfocado más al entorno empresarial, mientras que MySQL es un sistema de código abierto. Aunque actualmente ambos sistemas son propiedad de Oracle Corporation, se les suele reconocer como sistema de gestión gratuito (MySQL) y sistema de pago (Oracle Database) de la misma compañía (aunque MySQL también dispone de versiones de pago) [8]. Microsoft SQL Server Es un sistema propiedad de Microsoft. Al igual que ocurre con Oracle, este también es un sistema gestor comercial enfocado al ámbito empresarial, por lo que requiere de pago para obtener la licencia de acceso para trabajar con él. Su uso siempre estuvo ligado con sistema operativo Windows, pero desde hace unos años también está disponible para Linux. Basa su funcionamiento en el modelo cliente-servidor [9]. PostgreSQL Se trata de un sistema de gestión y administración de bases de datos relacionales, enfocado a bases de datos orientadas a objetos. Es multiplataforma, se puede utilizar en todos los principales sistemas operativos del mercado, además de ser un sistema con licencia gratuita y de código abierto. Posee varias interfaces de programación desarrolladas en diversos lenguajes de programación. Es un gestor que trabaja con mayor lentitud cuanto menor tamaño poseen las bases de datos administradas, puesto que su diseño está destinado a gestionar grandes volúmenes de datos [10]. 2.3.3.1 Lenguaje SQL Lo cierto es que cada día más casi la totalidad de los sistemas de gestión de bases de datos relacionales son más compatibles entre sí y comparten muchas de las Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 24 funcionalidades. Un motivo de que esto sea posible es que todos ellos comparten el mismo lenguaje estandarizado para realizar las operaciones. Si nos fijamos, muchos de ellos comparten la palabra SQL en sus nombres. SQL es el lenguaje estándar de programación empleado por los sistemas de gestión de las bases de datos relacionales para realizar la multitud de operaciones que deseemos con los datos. Es un lenguaje estándar, el cual está creado y diseñado para la administración, gestión y recuperación de la información en cualquier base de datos relacional. Es un lenguaje de declaraciones, en el cual indicando las palabras de instrucción reservadas se especifican las órdenes e implícitamente en la declaración de la expresión se denota cual debe ser el resultado esperado [11]. 2.3.3.2 Futuro Actualmente y cada vez con más peso están irrumpiendo con fuerza los sistemas de bases de datos al completo basados en la nube, dejando atrás los sistemas de implementación software como tal. La principal razón asociada al desarrollo de este tipo no es otro que el menor coste para el almacenamiento y mantenimiento de estos, y la comodidad que el uso de ellos supone en los equipos remotos desde los cuales poder tener acceso completo al sistema. Microsoft Azure SQL y Google BigQuery son ejemplos de ellos. Si nos hemos detenido a observar la Figura 8, vemos como desde inicios de pasado año 2020, Microsoft Azure SQL ha experimentado un crecimiento más abrupto y mucho mayor al que pueda presentar cualquier otro de los involucrados en el gráfico. Capítulo 2: Marco teórico 25 Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 32 finalizar el proceso de valoración de la calidad, este revisa la medida de evaluación y si observa cualquier anomalía que pueda darse o cualquier razonamiento u objeción que no le convenza, debido a que pueda haberse dado el caso de producirse algún error, este puede realizar y comprobar nuevamente la medida manualmente. Así, de esta manera modificaría la previamente realizada por el software de la máquina. En consecuencia, un operador puede modificar o no las medidas que realice el software implementado en una máquina. Una vez realizado el test, este quedará registrado mediante la fecha y hora en la que ha llevado a cabo su cometido, dichos valores se almacenan en el registro que tiene mismo nombre, FECHA Y HORA. A su vez, se detallará a cada uno de ellos con un nuevo identificador, denominado CÓDIGO DE TEST, compuesto en primer lugar, por los cuatro dígitos del año, seguidos por los dos dígitos del mes y continuando con los del día en el que se ha realizado. Finalmente, se les añadirá a los valores anteriores, el número de prueba que ha realizado la máquina a lo largo de ese día, en formato de tres dígitos y rellenando los valores a la izquierda con ceros si así fuese necesario. Para reconocerlo e identificarlo más claramente pondremos un ejemplo: supongamos que una máquina realiza el cuarto test del día 13 de Julio de 2020. Entonces ese test llevará asociado como CÓDIGO DE TEST el valor 20200713004. Otra de las características relacionadas con las marcas temporales de los tests, es la franja horaria en la que han sido desempeñados, dado que, unido a la política temporal de la empresa, en función del instante de tiempo en el que se desarrolle el test, pertenecerá a uno de los tres turnos establecidos. Los tests realizados entre las 07:00:00 horas, incluida esta, y las 15:00:00 horas de un mismo día pertenecen, y quedarán reflejados, al TURNO de mañana. Si han sido efectuados a partir de las 15:00:00 horas, hora válida para este turno, pero antes de las 23:00:00 horas se corresponden con el TURNO de tarde. Y finalmente si han sido llevados a cabo y están registrados desde las 23:00:00 horas, hora incluida, hasta antes de las 07:00:00 horas, su ubicación es el TURNO de noche. El propósito de los tests puede estar destinado en base a tres tipos de los que puede ser objeto: análisis, investigación o producción. Que se almacenará o recogerá en un campo denominado TIPO DE TEST. Como se dijo anteriormente, previamente a los análisis de evaluación de la calidad, los lotes de los diferentes productos son emplazados en las diversas máquinas. Cada uno Capítulo 3: La empresa ficticia ACME. Situación previa y análisis de requisitos 33 de esos lotes de productos lleva consigo un identificador de lote asociado, ID LOTE, y poder ser así reconocida su partida de fabricación. De la misma manera ocurre con los productos, cada producto concreto con el que se conforman los lotes posee su identificador individual, este será ID PRODUCTO. Un lote está formado por un conjunto de elementos. La política de identificadores de lotes y de productos dependen de las empresas que los generan. Veámoslo de forma más intuitiva con un ejemplo: supongamos que tenemos una fabricación de tornillos. En este caso los tornillos serán nuestro producto concreto y tienen como ID PRODUCTO = 4C. La producción de tornillos de un día concreto (1000 cajas de 100 tornillos cada una) constituye un lote, y cada caja es lo que denominaremos elemento. Así pues, por ejemplo, la producción de tornillos (producto con ID PRODUCTO = 4C) del 4 de enero de 2021 constituye el lote con identificador ID LOTE = 12AB de dicho producto. Este lote está constituido a su vez por 1000 elementos (las 1000 cajas). Para llevar a cabo la evaluación de la calidad, se realiza un análisis de un número concreto de elementos (cajas en nuestro ejemplo) que componen el lote de un determinado producto, que se registrará en el campo NÚMERO DE ELEMENTOS ANALIZADOS, pero ese número concreto de elementos a analizar puede variar en los diferentes tests ejecutados, de la misma manera que pueden variar los elementos que conforman el lote del producto de partida. El análisis de esos elementos puede realizarse de forma aleatoria u ordenada. Si el modo aplicado, el cual quedará reflejado en otro campo denominado MODO DE ANÁLISIS, es el aleatorio, se seleccionan al azar el número de elementos que previamente anunciábamos de entre todos los elementos que conforman el lote y se lleva a cabo el análisis de estos (por ejemplo, se seleccionan aleatoriamente 20 de las cajas de tornillos que constituyen cada lote). Si el modo elegido es el ordenado, el análisis se realizará de los primeros elementos del lote (en el ejemplo anterior, las 20 primeras cajas). En las distintas pruebas de evaluación de los productos se van analizando y valorando el número de defectos presentes en cada uno de los elementos que forman el lote y de que naturaleza son. La cantidad y tipología de los posibles defectos presentes se gradúa en una escala como las siguiente: NÚMERO DE DEFECTOS MENORES (por ejemplo, cuántos tornillos de la caja tienen ligeras imperfecciones), NÚMERO DE DEFECTOS MAYORES (por ejemplo, cuántos tornillos tienen defectos apreciables, pero pueden utilizarse sin problemas) y NÚMERO DE DEFECTOS CRÍTICOS (tornillos con defectos que impiden su uso). Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 34 Una vez contabilizados y clasificados los defectos detectados, se procede a calcular el valor global resultante de la prueba de análisis, que quedará almacenado en el campo NIVEL DE DEFECTOS. Para establecer el criterio de evaluación, las diferentes configuraciones llevan asociados directamente tres parámetros que darán forma al resultado del test, cómo bien anunciaba en el punto previo. El primero de ellos es el SISTEMA DE CÁLCULO. En función de él, nos determinará qué ecuación va a ser aplicada para obtener el NIVEL DE DEFECTOS. Los otros dos valores asociados son dos umbrales, UMBRAL BAJO y UMBRAL ALTO. Estos dos valores limitarán y determinarán la CALIDAD resultante de la fabricación del lote de productos. Es importante destacar que a mayor valor de NIVEL DE DEFECTOS peor habrá sido el proceso de elaboración, y, en consecuencia, peor nivel de CALIDAD otorgado. Y viceversa, si esa cantidad es menor, nos estará indicando que se ha detectado menor presencia de defectos y, por lo tanto, mejor CALIDAD presenta. El procedimiento posterior, es comparar el valor obtenido de NIVEL DE DEFECTOS con los umbrales anteriormente definidos. Dependiendo de la comparación con los dos umbrales, UMBRAL BAJO y/o UMBRAL ALTO, el resultado arrojado será superior, inferior o quedará limitado entre ambos. Lo cual nos determinará la CALIDAD resultante con la que han sido elaborados los diferentes lotes de productos. El método de comparación es el siguiente: • Se compara el valor de NIVEL DE DEFECTOS con el UMBRAL BAJO establecido y si el resultado es menor al valor del umbral, la CALIDAD con la que ha sido elaborado ese lote de productos es alta. • Si lo que ocurre es lo contrario, se compara el valor de NIVEL DE DEFECTOS con el otro umbral, UMBRAL ALTO. De esta nueva comparación, se pueden obtener dos resultados, que el valor sea mayor, o que sea menor al umbral. Si ocurre el primero de los resultados, la CALIDAD determinada será automáticamente baja. Si no es así, y el valor es menor al UMBRAL ALTO, entonces el valor quedará limitado entre ambos umbrales, lo que nos hace indicar que la CALIDAD en este caso será media. Capítulo 3: La empresa ficticia ACME. Situación previa y análisis de requisitos 35 • Reflejar que, si el valor de NIVEL DE DEFECTOS adopta el mismo valor que cualquiera de los dos umbrales, la CALIDAD será media. No obstante, si no se está de acuerdo con la resolución o procedimiento llevado a cabo en cada uno de los tests realizados, cada uno de ellos tiene la posibilidad de verse repetido con otro nuevo test. En este caso la nueva prueba tendrá una mayor duración en su procesado, pero arrojará una mayor fiabilidad en los resultados. Esta posibilidad quedará patente en un campo, llamado TEST EXTENDIDO, que puede tomar los valores de sí o no. Finalmente, por cada test realizado existe también un campo en el que se puede anotar y describir cualquier comentario, objeción o explicación que haya dado lugar en el desarrollo del test. Este campo está identificado con el nombre de COMENTARIOS. 3.2.4 Almacenamiento de datos. Archivo Excel. Durante el proceso de la actividad anteriormente descrita, entran en escena todas las variables y campos presentados, tomando valores concretos en la realización de los sucesivos análisis de calidad. Actualmente, tanto los resultados obtenidos, como las configuraciones, softwares, preferencias o las diferentes opciones que han sido seleccionadas a la hora de realizar las pertinentes pruebas de análisis y valoración del nivel de calidad con el que han sido elaborados los productos resultantes, tanto propios como externos, son recogidos y almacenados en un archivo Excel. Como ya he anunciado en anterior ocasión, parte del propósito global de este TFG es que todos estos datos almacenados y recogidos en dicho archivo Excel, sean migrados y, por lo tanto, estén presentes en la base de datos diseñada y creada. Una vez dicho lo anterior, y entrando en detalle en lo que nos concierne en este punto de la memoria, veamos cuál es la estructura, distribución y contenido del archivo Excel. Sabemos ya que la empresa realiza pruebas o tests de evaluación del nivel de calidad a productos elaborados por ellos mismos o bien someten a dichas valoraciones a productos derivados de otras empresas ajenas. Entrando a detallar la estructura del archivo, en él existen varias hojas en las que se albergan únicamente las pruebas realizadas a los Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 36 Productos Propios y otras en las que se reúnen las que son efectuadas a los Productos Externos, diferenciando también en esas mismas hojas las factorías en las que han sido ejecutadas. En concreto, el archivo consta de cuatro hojas. La primera de ellas refleja las pruebas sometidas a los Productos Propios que se han realizado en la factoría de Valladolid. La siguiente hoja recoge los tests efectuados al mismo tipo de productos pero que han sido llevados a cabo en la factoría salmantina. En la tercera de las hojas, los tests almacenados son los realizados por las tecnologías de las instalaciones situadas en la factoría vallisoletana, esta vez, a los Productos Externos. Para finalizar con la cuarta de las hojas registrando los análisis a los productos provenientes de otras empresas y que han sido llevados a cabo en la factoría de Salamanca. La estructura y distribución de cada una de las hojas es siempre la misma, estableciendo en la primera de las filas el nombre o enunciado del campo que, a continuación, en la segunda fila y sucesivas, tomará el valor concreto que haya sido decretado, ya sea como parámetro de configuración, de preferencia, de consecuencia… o arrojado, si es un valor resultado de la prueba ejecutada. Es decir, la primera fila alberga los enunciados de los campos por lo que quedarán registrados todos los componentes que son partícipes, directa e indirectamente, en la realización de los tests de evaluación de la calidad de los productos elaborados. Posteriormente, todos los valores de una misma fila reflejarán y detallarán las identificaciones involucradas en un mismo test. Para entender de manera más intuitiva lo dicho anteriormente, a continuación, se detalla un breve resumen y dos tablas en las que se recogen y muestran todos los valores a los que hacía referencia en el párrafo anterior: El fichero Excel contiene cuatro hojas, correspondientes a PRODUCTOS PROPIOS, una hoja por cada factoría, y a PRODUCTOS EXTERNOS, de la misma manera una hoja por cada factoría. De esta forma el fichero Excel está distribuido de la siguiente manera: 1. 1ª Hoja: PRODUCTOS PROPIOS en la factoría de VALLADOLID. 2. 2ª Hoja: PRODUCTOS PROPIOS en la factoría de SALAMANCA. 3. 3ª Hoja: PRODUCTOS EXTERNOS en la factoría de VALLADOLID. 4. 4ª Hoja: PRODUCTOS EXTERNOS en la factoría de SALAMANCA. Capítulo 3: La empresa ficticia ACME. Situación previa y análisis de requisitos 37 La distribución de las hojas Excel en el caso de los PRODUCTOS PROPIOS, sería cómo se recoge en la siguiente Tabla 2: COLUMNA CAMPO DESCRIPCIÓN VALORES A FACTORÍA Nombre de la factoría en la que se realiza el test. VALLADOLID / SALAMANCA B CÓDIGO DE PAÍS Código del país donde está ubicada la factoría. ES C ID MÁQUINA Número natural. Identifica la máquina que realiza el test. Es único a nivel global de la empresa. No hay dos máquinas con el mismo identificador. 1, 2, 3... D ID TEST Número natural correlativo que identifica la prueba de análisis. No se resetea jamás. En cada máquina empieza desde 1. 1, 2, 3... E CÓDIGO DE TEST Ej: Formato 191216003 (3ª prueba hecha el 16/12/19). Nótese que distintas máquinas pueden tener los mismos códigos de test. 20210518001 - 20210522004 F FECHA Y HORA Fecha y hora de realización del test. 18/05/2021 00:02:45 - 22/05/2021 21:16:35 G OPERADOR Nombre y apellidos de la persona que supervisa la prueba de evaluación. NOMBRE APELLIDOS H ID OPERADOR Número natural. Único por cada operador a nivel global de la empresa. 1, 2, 3... I TURNO Mañana, tarde, noche. MAÑANA / TARDE / NOCHE J TIPO DE TEST Investigación, Producción, Análisis. INVESTIGACIÓN / PRODUCCIÓN / ANÁLISIS K ID SOFTWARE Número natural. Identifica el software con el que opera la máquina. 1, 2, 3... L ID CONFIGURACIÓN Número natural. Refleja la configuración concreta de la máquina. 1, 2, 3... M ID PRODUCTO Valor alfanumérico. Identifica el producto. 1A / 2B / 3C / 4D / 5E / 6F / 7G / 8H / 9I N ID LOTE Valor alfanumérico. Identifica el lote de producción. 12AB / 34CD / 56EF / 78GH / 90IJ Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 38 COLUMNA CAMPO DESCRIPCIÓN VALORES O PROTOCOLO DE MEDICIÓN 1, 2, 3, 4, 5. 1 - 5 P VARIANTE PROTOCOLO 1 Número natural. En el caso anterior de emplearse el protocolo 1, este puede haber utilizado una de sus variantes 1, 2, …, 10 1 - 10 Q MODO DE ANÁLISIS Ordenado, Aleatorio. Si se eligen los elementos a analizar de forma correlativa (ej. primeros 10 elementos) o aleatoria (10 elementos al azar) ORDENADO / ALEATORIO R NÚMERO DE ELEMENTOS ANALIZADOS Número de elementos del lote que se analizan. 1, 2, 3, … S NÚMERO DE DEFECTOS MENORES Número total de defectos menores detectados en el test. 0, 1, 2, ... T NÚMERO DE DEFECTOS MAYORES Número total de defectos mayores detectados en el test. 0, 1, 2, ... U NÚMERO DE DEFECTOS CRÍTICOS Número total de defectos críticos detectados en el test. 0, 1, 2, ... V NÚMERO TOTAL DE DEFECTOS Suma total de todos los tipos de defectos anteriores. 0, 1, 2, ... (Suma de los tres anteriores) W SISTEMA DE CÁLCULO DE CALIDAD Número natural que identifica qué fórmula se utiliza para calcular la calidad del lote en función de los defectos encontrados y su tipología. 1, 2, 3... X NIVEL DE DEFECTOS Valor numérico real calculado en función del tipo de defectos y el sistema de cálculo de calidad. Número real Y CALIDAD ALTA/MEDIA/BAJA Compara el nivel de defectos con dos umbrales definidos. ALTA / MEDIA / BAJA Z TEST EXTENDIDO SI/NO. La prueba extendida tiene mayor duración que la estándar, pero tiene más fiabilidad en los resultados. SI / NO Capítulo 3: La empresa ficticia ACME. Situación previa y análisis de requisitos 39 COLUMNA CAMPO DESCRIPCIÓN VALORES AA COMENTARIOS Texto. Observaciones y comentarios relacionados con el test. AAAA - ZZZZ Tabla 2. Distribución en Excel para Productos Propios La distribución de las hojas del archivo Excel en el caso de que los productos valorados sean los PRODUCTOS EXTERNOS, es análoga a la anterior, pero se incluye al final de los anteriores un campo adicional que es: ID PROVEEDOR, toma valores 1, 2, 3… e identifica al proveedor externo que ha fabricado el producto testeado (Tabla 3): COLUMNA CAMPO DESCRIPCIÓN VALORES … … … … AB ID PROVEEDOR Número natural. Identifica al proveedor al que pertenece el lote analizado. 1, 2, 3... Tabla 3. Distribución en Excel para Productos Externos 3.2.5 Información adicional. Conjuntamente al archivo Excel anteriormente descrito, existen determinados datos de configuración, software y proveedores asociados a la empresa, recogidos paralelamente en un cuaderno electrónico de notas del que también hace uso la empresa. En él recoge características de descripción y parámetros concretos asociados a cada uno de los softwares o configuraciones que posee y puede implantar en las máquinas de la empresa en un momento dado, a la vez que hace lo mismo para identificar el nombre del proveedor con su identificador asociado. A algunos de ellos ya he hecho alusión en anteriores ocasiones. Los valores asociados a los diferentes softwares son: 1. ID SOFTWARE: Número natural que identifica un software concreto. 2. NOMBRE: Apelativo descriptivo del software. 3. VERSIÓN: Identificación de la versión del software. 4. PARÁMETRO A: Valor de ajuste del software empleado. 5. PARÁMETRO B: Valor de ajuste del software empleado. Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 40 Por parte de la configuración vienen definidos los siguientes: 1. ID CONFIGURACIÓN: Número natural que identifica una configuración concreta. 2. NOMBRE: Apelativo descriptivo de la configuración. 3. SISTEMA DE CÁLCULO: Número natural que identifica el procedimiento de evaluación empleado para calcular la calidad final del lote analizado. 4. UMBRAL BAJO: Valor de referencia fijado para la valoración de calidad como alta o media. 5. UMBRAL ALTO: Valor de referencia fijado para la valoración de calidad como media o baja. En el caso de los proveedores asociados los valores anotados en el cuaderno electrónico son: 1. ID PROVEEDOR: Número natural que identifica un proveedor concreto. 2. NOMBRE PROVEEDOR: Apelativo descriptivo del proveedor. De manera que a la hora de almacenar la información relativa a la realización de las diversas pruebas en el archivo Excel, lo que aparece reflejado en él haciendo referencia a todo lo aquí arriba plasmado son los valores de ID CONFIGURACIÓN, ID SOFTWARE e ID PROVEEDOR los cuales llevan asociados directamente e identifican cada una de las descripciones anteriores. 3.2.6 Implementaciones futuras En este apartado se reflejarán algunos de los planteamientos y valoraciones llevadas a cabo por la empresa ACME y que ha decidido implantar para llevar a cabo la nueva forma de almacenamiento, en la nueva base de datos creada, y extender el funcionamiento anteriormente expuesto en la sección 3.2.3. La primera de ellas es que todas las modificaciones, o no alteraciones, que cualquier operador realice quedarán reflejadas en otra variable la cual almacenará un carácter. Esta Capítulo 3: La empresa ficticia ACME. Situación previa y análisis de requisitos 41 variable tendrá el nombre de VALIDACIÓN y puede recoger cualquiera de los siguientes valores: V (Validado por el operador tras revisar el test), M (Modificado por el operador tras revisar el test), N (No revisada por el operador) y NULL. • Si el carácter presente en esta variable es V, quiere decir que el test ha sido llevado a cabo por el software y el operador lo ha validado dando por buenas las medidas de análisis producidas en él. • Si, en lugar de presentar el valor anterior, presenta una M, nos estará indicando que dicha valoración ha sido realizada por el software, pero posteriormente se ha visto reevaluada por el operario allí presente y, en consecuencia, ha sido modificada. • Si el valor recogido es el carácter N, determina que la prueba de análisis ha concluido y ha sido ejecutada por el software, pero en este caso no ha sido revisada por ningún operador. • Por último, aquellos tests de los que se desconozca la naturaleza y supervisión de los mismos, serán reconocidos con el valor NULL. Este último valor, será el que reflejen todos los tests almacenados en el archivo Excel a la hora de ser migrados y recogidos en la nueva base de datos diseñada, dado que hasta la fecha del nuevo diseño era una consideración que no había sido llevada a cabo. Otra de las posibilidades que de cara al futuro se va a implementar, es el desglose o distinción de cada uno de los defectos y del tipo al que pertenezca, identificados en cada uno de los elementos analizados en los tests realizados. Esto significa que todos los elementos analizados de un mismo lote serán identificados y cada uno de ellos llevará asociado el número y tipo de defectos que le han sido detectados. Hasta ahora, el registro de la cuantía y tipo de defectos detectados en el test de análisis reflejaba el sumatorio global de todos ellos, pero no identificaba de ninguna manera los elementos en los que habían sido hallados. Esto es lo que se pretende con esta nueva futura implantación, indistintamente de cómo sea el modo de análisis llevado a cabo en disco test. Veamos más claro con un ejemplo, lo que se reconoce a día de hoy y hasta dónde se quiere extender y destacar exhaustivamente en cada análisis. Imaginemos que en la máquina con ID MÁQUINA = 3 se ha llevado a cabo un test de análisis de 64 elementos, identificado con Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 48 MEDICIÓN, MODO DE ANÁLISIS, NÚMERO DE ELEMENTOS ANALIZADOS, etc… Todo ello se reconocerá y entenderá de mejor manera a la hora de plasmar el diseño de la propia base de datos, más adelante. 4.2.2 Funcionalidades futuras Como se anunciaba previamente en el capítulo anterior, ACME ha decidido después de estudiar y valorar, extender y profundizar en el modo de analizar los productos. Dichas consideraciones son: la diferenciación entre los tests con las medidas de análisis realizadas automáticamente, pero revisadas por el operador (que pueden ser validadas o modificadas), de las no revisadas por él. La otra se trata de la identificación de cada elemento que ha formado parte del análisis del conjunto global del test y la determinación del número y grado al que pertenecen los defectos padecidos y detectados en cada uno de dichos elementos. En la primera de las consideraciones se pretende registrar la validación, modificación o falta de supervisión y revisión por parte de los operadores al mando a la hora de que las medidas de análisis llevadas a cabo en los tests sean determinadas por el software ejecutado en la máquina. Para ello debemos dejar constancia en nuestro diseño de la base de datos, de manera que cada prueba realizada lleve asociado uno de entre los valores posibles que pueda darse en los diferentes casos y que ya se expusieron en el capítulo anterior, más en concreto, en el apartado 3.2.6. La otra nueva implantación es la separación e identificación de la cantidad de defectos y el grado al que pertenecen, de todos los defectos que aparezcan y estén presentes en cada elemento que forme parte de cada uno de los análisis realizados. Para ello deberemos introducir un nuevo atributo o variable, el cual identifique por sí solo a cada uno de los elementos del lote que acabará siendo objeto de análisis. Aunque ya ha sido anunciado en alguna ocasión, vuelvo a adelantar que se tratará del campo ID ELEMENTO. Esta nueva segregación se tendrá en cuenta tanto para las medidas de análisis realizadas por el software y validadas directamente como para las que no han seguido el mismo camino y han tenido que ser modificadas y/o corregidas. Hasta ahora nada de esto había ocurrido, y solo estaban registrados los totales de la suma global por cada grado o tipo de defecto del total de elementos analizados. Capítulo 4: Diseño de la Base de Datos 49 4.3 Diseño Una vez realizado el estudio y la valoración de las consideraciones previas o requisitos de partida, estamos en condiciones de abordar la siguiente fase que no es otra que comenzar a esbozar y realizar el diseño que adoptará la base de datos. A continuación, veremos de forma más clara e intuitiva todo lo recogido en el punto anterior y la manera de relacionar todo ello mediante la presentación del diseño llevado a cabo. Teniendo en cuenta las consideraciones y particularidades anteriores, se ha optado por realizar un diseño de la base de datos normalizado en tercera forma normal (3FN). El caso más común y popular para almacenar y recoger los datos en algunos de los diversos campos extendidos a lo largo de todas las tablas es el de cadenas de caracteres de diferente longitud. A la hora de considerar el almacenamiento de los diferentes datos contemplados en cadena de caracteres se ha determinado seguir el siguiente criterio por motivos de eficiencia en el rendimiento y la rapidez de realizar las consultas posteriormente a los datos recogidos en dichos campos y en cuanto al ahorro del espacio de la memoria empleada para su almacenamiento [12]. Primando el rendimiento ya que el objetivo y fin de la base de datos es dar soporte a un cuadro de mando, el cual deberá ejecutar innumerables consultas para realizar las diferentes operaciones que se quieran llevar a cabo, pero sin descuidar un gasto excesivo y en vano de la memoria en el momento de almacenar dichos datos. Tratando de conseguir el equilibrio entre ambas justificaciones. • Si la cantidad de caracteres que se van a almacenar en el campo de un registro es fija, siempre se utilizará CHAR para ese atributo. • Si la cantidad de caracteres a almacenar en dicho campo del registro varía, entonces se usará VARCHAR. Es notable que los diferentes identificadores de los distintos registros sean almacenados como un número natural (UNSIGNED INT), dado que no tiene mucho sentido que estos mismos tomen valores negativos. De la misma manera ocurre con los valores de aquellos datos a almacenar cuyo valor negativo no tenga ningún sentido y significado dentro del marco operativo dónde se desarrolla la actividad de ACME, para cuyo objetivo es el diseño de la presente base de datos. Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 50 En el caso de que el valor o parámetro a registrar sea un número decimal, la naturaleza del atributo para recoger dicho dato será de tipo “coma flotante” o decimal (FLOAT). La manera de ilustrar el diseño será una explicación individual de cada una de las tablas que albergaran los numerosos registros con sus correspondientes datos y que en conjunto conforman nuestra base de datos, para posteriormente exponer el resultado global de todas ellas y las relaciones que se atañen entre ellas y que hacen posible la robustez y trazabilidad del diseño de la base. 4.3.1 Tablas La base de datos se compone de diez tablas independientes, de tal manera que al vincularse y crearse las relaciones pertinentes entre ellas se conforma finalmente nuestra base de datos, relaciones que más adelante se verán. De momento vamos a centrarnos en cómo están estructuradas cada una de las tablas. La manera de presentar cada una de ellas seguirá el siguiente orden: 1. Una breve descripción de la tabla junto con la representación de la misma. 2. Una tabla resumen en la que se recogen las columnas o atributos que forman parte de ella junto con los comentarios pertinentes y explicativos sobre alguno de ellos concretos que sea necesario subrayar. En la tabla se especificará el nombre del atributo, una breve descripción de este, el tipo de dato que recoge y si puede tomar valor nulo. En la misma tabla junto al nombre aparecerá un icono de llave primaria si es que ese atributo es o forma parte de ella. 3. Finalmente se repetirá el mismo procedimiento, pero en lugar de los atributos, los protagonistas ahora serán los índices y claves de cada una de las tablas partícipes. 4.3.1.1 Tabla tests En primer lugar, empezaremos por la tabla principal, desde la cual surgen o giran en torno a ella el resto. Esta tabla está titulada con el nombre de tests, ya que en esta tabla se almacenarán todos y cada uno de los tests que han sido llevados a cabo en las diferentes Capítulo 4: Diseño de la Base de Datos 51 máquinas y que están recogidos en el archivo Excel debido al desempeño de la actividad. Recogerá las principales características y particularidades que describen la realización de las diferentes pruebas y las consecuentes prestaciones que han arrojado los resultados de las mismas. Podemos verla a continuación en la Figura 10. Figura 10. Tabla tests Como se observa, la tabla dará cabida para albergar los 23 atributos que conforman los distintos registros y que veremos descritos brevemente en la siguiente tabla resumen, Tabla 4. TABLA TESTS (ATRIBUTOS) # CAMPO DESCRIPCIÓN TIPO DATO NULO 1 id_maquina Identifica la máquina en la que ha sido efectuado el test. unsigned int(11) No 2 id_test Identifica el test realizado. unsigned int(11) No 3 fecha_hora Fecha y hora en la que se ha realizado el test. datetime No 4 codigo_test Código asociado al test. char(11) No 5 id_operador Identifica al operador de supervisado del test. unsigned int(11) No 6 id_software Identifica el software instalado en la máquina. unsigned int(11) No Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 52 TABLA TESTS (ATRIBUTOS) 7 id_configuracion Identifica la configuración establecida en la máquina. unsigned int(11) No 8 turno Turno en el que se ha realizado el test. (Mañana / Tarde / Noche) varchar(6) No 9 tipo_test Objeto del test. (Análisis / Investigación / Producción) varchar(13) No 10 Id_proveedor Identifica el proveedor de los productos evaluados en el test. unsigned int(11) No 11 id_producto Identifica el producto evaluado. varchar(20) No 12 id_lote Identifica el lote de productos evaluado. varchar(20) No 13 protocolo_medicion Protocolo empleado en el análisis. (1 / 2 / 3 / 4 / 5) varchar(3) No 14 modo_analisis Forma de analizar los elementos. (Aleatorio / Ordenado) varchar(9) No 15 numero_elementos_analizados Cantidad de elementos del lote objeto de análisis. unsigned int(11) No 16 defectos_menores Cantidad de defectos de tipología menor detectados en el test. unsigned int(11) No 17 defectos_mayores Cantidad de defectos de tipología mayor detectados en el test. unsigned int(11) No 18 defectos_criticos Cantidad de defectos de tipología crítica detectados en el test. unsigned int(11) No 19 nivel_defectos Valor numérico real calculado en función de la cantidad y tipo de defectos y del sistema de cálculo de calidad. float No 20 calidad Resultado de comparar el nivel de defectos con dos umbrales. (Alta / Media / Baja) varchar(5) No 21 validacion Atributo de validación, comprobación, modificación… por parte del operador al mando de la supervisión del test. (N / M / V / NULL) char(1) Sí Capítulo 4: Diseño de la Base de Datos 53 TABLA TESTS (ATRIBUTOS) 22 test_extendido Campo de señalización para una nueva prueba de análisis. (NO / SI) char(2) No 23 comentarios Descripción adicional del test. text No Tabla 4. Registros contenidos en tabla tests De los atributos recogidos en cada uno de los registros que se almacenarán en la tabla, quizás el que más llame la atención en su forma de almacenar sea codigo_test, ya que se trata de un número compuesto por los dígitos de la fecha en el que el test fue efectuado seguido del número de test realizado por la máquina en esa fecha, como ya fue explicado en la sección 3.2.3. Pero a pesar de tratarse de un número se almacena como un conjunto de once caracteres en la forma char(11), dado que si se almacena como un entero de dichos once dígitos, el espacio de almacenamiento que consumiría cada uno de ellos sería mucho mayor. Puesto que los últimos 3 caracteres se utilizan para indicar el número de test realizado ese día en esa máquina, dicha codificación admite un máximo de 1000 tests cada día. Se asume que ese valor es razonable, incluso con vistas al futuro, por lo que se decide mantener ese tipo de codificación. TABLA TESTS (ÍNDICES) NOMBRE DESCRIPCIÓN PRIMARIO ÚNICO ÍNDICE PRIMARY Índice de clave primaria compuesta. Formada por id_maquina e id_test. Sí Sí Sí id_maquina Identificador de máquina No No Sí id_software Identificador de software No No Sí id_configuracion Identificador de configuración No No Sí id_operador Identificador de operador No No Sí Id_proveedor Identificador de proveedor No No Sí Tabla 5. Índices de la tabla tests La anterior Tabla 5 recoge los índices involucrados en la consecución de esta primera tabla descrita. La tabla tests posee una clave primaria compuesta formada por id_maquina e id_test, de manera que queden identificados de manera única e independiente cada uno de los tests efectuados en la totalidad de las diferentes máquinas. Así mismo, se reflejan otros cinco índices, id_maquina, id_software, id_configuracion, id_operador e id_proveedor, necesarios para crear las relaciones con otras de las tablas contenidas en la Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 54 base de datos, como son: maquinas, software, configuracion_calidad, operadores y proveedores, respectivamente. Las relaciones creadas y que vinculan entre sí las diferentes tablas se expondrán de manera más extendida y completa más adelante en la sección 4.3.2 titulada Relaciones. 4.3.1.2 Tabla maquinas En primer lugar, que la palabra maquinas no esté acentuada no es a causa de un error ortográfico, sino que al diseñar la base de datos el nombramiento de cada una de las tablas y atributos no deben contener acentos, caracteres especiales o de tipo raro. Por ello que sucederá lo mismo con alguna tabla más. Dicho lo anterior, el diseño y estructura de esta tabla está realizado de tal forma que, al volcar y realizar la migración de los datos, únicamente van a quedar almacenadas en ella las máquinas en las que se han llevado a cabo los diferentes tests registrados, el tipo de producto a los que efectúa los análisis dicha máquina, la factoría en la que está situada y el código de país relacionado con la ubicación de la factoría (ver Figura 11). Repárese que en el archivo Excel existirán innumerables tests con los mismos valores repetidos y que pertenecen a los registros antes citados. En esta tabla de la base de datos no ocurrirá así, ya que el diseño de esta tabla está realizado de tal forma que solo serán registrados una única vez. Figura 11. Tabla maquinas Los diferentes atributos que conformarán los distintos registros y le darán forma al completar la tabla son los mostrados en la Tabla 6. De esta tabla quiero destacar el atributo tipo_producto, el cual es de tipo char y tiene capacidad para dos caracteres, char(2). Ya que como se muestra en la tabla puede reflejar dos posibles combinaciones de caracteres: PP o PE, dependiendo de si la máquina efectúa tests de análisis a Productos Propios o Productos Externos, respectivamente. Por otro lado, en esta tabla, con el propósito de simplificar la base de datos, se ha decidido desnormalizar al recoger la factoría y el código de país directamente en esta tabla. Capítulo 4: Diseño de la Base de Datos 55 TABLA MAQUINAS (ATRIBUTOS) # CAMPO DESCRIPCIÓN TIPO DATO NULO 1 id_maquina Identifica la máquina en la que se ejecutan los tests. unsigned int(11) No 2 tipo_producto Tipo de producto que analiza la máquina. (PP / PE) char(2) No 3 factoria Localización de la factoría. varchar(20) No 4 codigo_pais Código asociado al país en el que se ubica la factoría. char(2) No Tabla 6. Registros contenidos en tabla maquinas TABLA MAQUINAS (ÍNDICES) NOMBRE DESCRIPCIÓN PRIMARIO ÚNICO ÍNDICE PRIMARY Índice de clave primaria. id_maquina Sí Sí Sí Tabla 7. Índices de la tabla maquinas La tabla maquinas estará consternada por una clave primaria la cual es referenciada por el índice id_maquina. Nos lo muestra la anterior Tabla 7. Este índice será el que diferencie indistintamente a cada una de las máquinas propiedad de la empresa en las que se hayan llevado a cabo los tests plasmados en el archivo Excel. 4.3.1.3 Tabla operadores Otra de las tablas involucradas será la que albergue a todos los operadores de la empresa ACME que vengan anotados en el archivo Excel al haber estado supervisando las pruebas de valoración de la calidad de los diferentes tests. Dicha tabla será la que ilustra la Figura 12. Figura 12. Tabla operadores En ella se asociará en cada tupla acumulada en la tabla, cada identificador de cada operador con su respectivo nombre y apellidos como se representa en la Tabla 8. En este caso se ha decidido simplificar al máximo y colocar el nombre y apellidos del operador en un único campo y no recoger información adicional. En un escenario real, debería existir una tabla mucho más completa con todos los datos relativos al operador. Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 56 TABLA OPERADORES (ATRIBUTOS) # CAMPO DESCRIPCIÓN TIPO DATO NULO 1 id_operador Identifica al operador. unsigned int(11) No 2 nombre_operador Nombre y apellidos del operador. varchar(60) No Tabla 8. Registros contenidos en tabla operadores TABLA OPERADORES (ÍNDICES) NOMBRE DESCRIPCIÓN PRIMARIO ÚNICO ÍNDICE PRIMARY Índice de clave primaria. id_operador Sí Sí Sí Tabla 9. Índices de la tabla operadores Como es de esperar y ocurre así en la mayoría de las tablas de la base de datos y de la misma forma que ocurría anteriormente en la tabla maquinas, en este caso el índice que representa la clave primaria de la tabla operadores será id_operador. De tal manera que cada uno de los operadores quede claramente diferenciado de otro al poseer cada operador un id_operador único. Esto es lo que viene reflejado en la Tabla 9. 4.3.1.4 Tabla configuracion_calidad La siguiente de las tablas es la que reflejará todos los valores relacionados con las diferentes configuraciones que le han sido establecidas y, por lo tanto, con las que han trabajado las diferentes máquinas. En ella los diferentes registros tendrán asociados el valor de identificación de la configuración, el nombre que recibe esta, el número (identificador) que representa el sistema de cálculo que empleará dicha configuración para obtener el nivel de defectos y los valores de los dos umbrales con los que comparar el valor anterior y obtener así la calidad de producción del lote analizado. Si recordamos y echamos memoria hacia atrás, la empresa ACME solo tenía presente en el archivo Excel, el identificador de configuración empleado en el desarrollo del test. El resto de los valores estaban anotados en el cuaderno de notas externo con el que también trabaja la empresa. De esta manera, al diseñar esta tabla, representada en la Figura 13, ACME tendrá un acceso más globalizado y directo a todo ello realizando un solo click. Los atributos antes mencionados y que darán lugar a la formación de las sucesivas tuplas recogidas en la tabla configuracion_calidad son los que vienen recogidos en la Tabla 10. Capítulo 4: Diseño de la Base de Datos 57 Figura 13. Tabla configuracion_calidad TABLA CONFIGURACION_CALIDAD (ATRIBUTOS) # CAMPO DESCRIPCIÓN TIPO DATO NULO 1 id_configuracion Identifica la configuración a establecer en la máquina. unsigned int(11) No 2 nombre_configuracion Nombre de la configuración. varchar(20) No 3 sistema_calculo Identifica el sistema de cálculo empleado para obtener el nivel de defectos. unsigned int(11) No 4 umbral_bajo Valor de frontera para el nivel de defectos y distinguir entre calidad alta o media. float No 5 umbral_alto Valor de frontera para el nivel de defectos y distinguir entre calidad media o baja. float No Tabla 10. Registros contenidos en tabla configuracion_calidad La columna o atributo sistema_calculo tomará valores de un número natural, ya que ACME actualmente solo trabaja con tres valores distintos identificados por los valores del 1 al 3. En el futuro la empresa podría plantearse ampliarlos. TABLA CONFIGURACION_CALIDAD (ÍNDICES) NOMBRE DESCRIPCIÓN PRIMARIO ÚNICO ÍNDICE PRIMARY Índice de clave primaria. id_configuracion Sí Sí Sí Tabla 11. Índices de la tabla configuracion_calidad Esta nueva tabla estará franqueada por un índice de clave primaria fundado en id_configuracion (ver Tabla 11), el cual nos permitirá distinguir, caracterizar, ordenar, etc, cada una las configuraciones con las que haya operado la empresa y que se almacenarán en esta tabla. 4.3.1.5 Tabla software El diseño de la tabla presentada a continuación (Figura 14), tabla software, brota de una cuestión idéntica a la anterior, dado que en el archivo Excel solamente viene recogido Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 64 TABLA MEDIDAS_SOFTWARE_NO_ACEPTADAS (ÍNDICES) NOMBRE DESCRIPCIÓN PRIMARIO ÚNICO ÍNDICE idMaquinaEidTest Índice de clave foránea compuesta. Formada por id_maquina e id_test. No Sí Sí Tabla 21. Índices de la tabla medidas_software_no_aceptadas Para lograr está distinción en dicha tabla, nos encontramos con un índice de clave foránea, cuya tabla referenciada sigue siendo la tabla tests. Nuevamente, como ocurría en en la tabla variante_protocolo_1 y se puede apreciar en la Tabla 21, está formado por el identificador de la máquina, id_maquina, junto con el identificador del test en dicha máquina, id_test. 4.3.1.10 Tabla medidas_software_por_elemento_no_aceptadas En último lugar, nos encontramos con la tabla medidas_software_por_elemento_no_aceptadas, provista también para la implantación de las futuras funciones en el desempeño de la actividad. Esta tabla no es más que una extensión de la tabla anterior, pero en este caso detallando el nivel de análisis y detección de defectos por elemento analizado. Esto es, identificando la cantidad y tipo de defecto por cada elemento analizado del lote de productos proporcionado a analizar en la máquina pertinente. Por ello que en esta tabla se incluye un atributo más a los que idénticamente presentaba la tabla medidas_software_no_aceptadas. Ese atributo es id_elemento, mediante el cual se identificará al elemento analizado en cuestión y con el que se asociarán los defectos detectados y de la tipología que son, manteniendo y compartiendo todos ellos el mismo id_maquina e id_test. Podemos ver la anterior tabla medidas_software_no_aceptadas como una tabla resumen de esta nueva tabla (medidas_software_por_elemento_no_aceptadas, Figura 19), para realizar operaciones de identificación, búsqueda o consulta de manera más rápida y eficiente, y esta otra para realizar otras operaciones con mayor grado de detalle. Capítulo 4: Diseño de la Base de Datos 65 Figura 19. Tabla medidas_software_por_elemento_no_aceptadas Los atributos agrupados en la tabla medidas_software_por_elemento_no_aceptadas se detallan en la siguiente Tabla 22. TABLA MEDIDAS_SOFTWARE_POR_ELEMENTO_NO_ACEPTADAS (ATRIBUTOS) # CAMPO DESCRIPCIÓN TIPO DATO NULO 1 id_maquina Identifica la máquina en la que ha sido efectuado el test. unsigned int(11) No 2 id_test Identifica el test realizado. unsigned int(11) No 3 id_elemento Identifica el elemento analizado. unsigned int(11) No 4 num_defectos_menores Cantidad de defectos de tipología menor detectados en el elemento. unsigned int(11) No 5 num_defectos_mayores Cantidad de defectos de tipología mayor detectados en el elemento. unsigned int(11) No 6 num_defectos_criticos Cantidad de defectos de tipología crítica detectados en el elemento. unsigned int(11) No Tabla 22. Registros contenidos en tabla medidas_software_por_elemento_no_aceptadas TABLA MEDIDAS_SOFTWARE_POR_ELEMENTO_NO_ACEPTADAS (ÍNDICES) NOMBRE DESCRIPCIÓN PRIMARIO ÚNICO ÍNDICE idMaquinaEidTestEidElemento Índice de clave foránea compuesta. Formada por id_maquina e id_test. Asociada junto con id_elemento. No Sí Sí Tabla 23. Índices de la tabla medidas_software_por_elemento_no_aceptadas De nuevo, como ocurría en la tabla medidas_consolidadas, para alcanzar este tipo de detalles en el análisis de cada elemento debemos asociar al índice de clave foránea formado por id_maquina e id_test, el atributo id_elemento (ver Tabla 23). De esta manera podemos reconocer con el mismo identificador de máquina e identificador de test, la prueba de evaluación que se ha llevado a cabo, y distinguir mediante el identificador de elemento, el elemento concreto que se quiera consultar o detallar. Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 66 4.3.2 Relaciones Previamente a proceder con la explicación de las relaciones asociativas y que mantienen ligadas y vinculadas unas tablas con otras para conseguir la robustez y preservar la integridad de los datos, es importante no entender el término relación del título de este epígrafe como haciendo referencia la acepción de relación como tabla de una base de datos, ya que relación también puede ser utilizado como término formal con el que se reconoce a una tabla de una base datos. En este caso haremos alusión del término relación con un uso más general del mismo como es la acepción de “relacionado con”, “conexión, correspondencia de algo con otra cosa” [Real Academia Española, Diccionario de la Lengua Española, 2021. https://dle.rae.es/relación] al referirnos a las relaciones o conexiones entre las diferentes tablas de la base de datos. Primeramente, para que dos tablas se puedan relacionar o vincular deben presentar alguna de ellas un campo el cual sea clave primaria de la misma. Ambos campos, clave y no clave, deben ser del mismo tipo de dato y tamaño para así coincidir y poder recoger el mismo tipo de valores. El nombre que reciba el atributo o los atributos que vayan a formar la relación entre las tablas no tienen por qué compartir el mismo nombre en las dos. Por ejemplo, no podemos relacionar dos tablas si una dispone de un campo que es clave de tipo dato int recogido bajo el nombre de id_persona y la otra recoge un atributo con tipo de dato varchar apodado con el nombre de id_persona. Para ello deberían ser los dos atributos o bien tipo int, recogidos bajo el mismo o distinto nombre en cada tabla, o de tipo varchar, con el mismo o distinto nombre en cada tabla de igual manera. Por lo tanto, teniendo en cuenta estas consideraciones previas y llevándolas hasta el diseño de las tablas con las que queremos formar nuestra base de datos, a la vez que mantenemos en mente la estructura y formación de las claves e índices presentes en cada tabla y que se han presentado recientemente en el punto anterior 4.3.1 para cada una de ellas, estamos en condiciones de ir creando las diferentes relaciones que vincularán con la presencia de los posteriores datos migrados y almacenados en los correspondientes registros la totalidad de las tablas de base de datos. Capítulo 4: Diseño de la Base de Datos 67 4.3.2.1 Relaciones de clave simple Para ir dándole forma y detalle al diseño global, se comenzarán a plasmar las relaciones que incluyen las tablas con presencia de claves simples. Esto es, aquellas tablas que presentan un único atributo como clave primaria de la misma. Las tablas que poseen esta condición de clave primaria simple son: maquinas, operadores, software, configuracion_calidad y proveedores. En cada una de ellas nos encontramos con que los atributos id_maquina, id_operador, id_software, id_configuracion e id_proveedor están designadas claves primarias de cada una de las anteriores tablas respectivamente. Como se detalló anteriormente la tabla principal o matriz la cual albergará los valores de las características y particularidades implicadas, y los resultados arrojados en la ejecución de las pruebas de valoración de la calidad será la tabla tests. Algunas de esas particularidades recogidas en esta última tabla son la máquina que está realizado el test (atributo id_maquina), el operador al supervisado del test (id_operador), tanto el software (id_software) como la configuración (id_configuracion) montada en el desarrollo de la prueba evaluativa o el proveedor al cual pertenecen los productos que están siendo evaluados (id_proveedor). En este caso el nombre de los atributos de las diferentes tablas coincide, pero insisto nuevamente que esta condición no es necesaria. Como el tipo de dato que guardarán también son el mismo en ambas tablas a relacionar, podemos crear la relación entre la tabla tests y las tablas mencionadas al principio. Quedando el diseño relacional como el mostrado en la Figura 20 (siguiente página). De esta manera, atendiendo a los valores registrados en los atributos vinculados de la tabla tests, podemos conocer y detallar el resto de los datos contenidos en los atributos restantes de las diversas tablas y así obtener mayor grado de información asociada al respecto de los valores establecidos en los identificadores en el desarrollo de los sucesivos tests. Por ejemplo, si durante el desarrollo de un test, el campo id_operador ha registrado un determinado valor, observando la tabla operadores podemos averiguar qué nombre y apellidos corresponden al operador con ese id_operador. Y actuar de forma idéntica con el resto de los identificadores de las otras tablas. Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 68 Figura 20. Relaciones de clave simple 4.3.2.2 Relaciones de clave compuesta De igual manera que ocurre con las claves simples, se crearán también relaciones con otras tres tablas, que veremos ahora, a través de la clave primaria compuesta de la tabla tests, formada por los atributos id_maquina e id_test. La clave primaria de la tabla tests, nos permitirá identificar inequívocamente cada uno de los tests realizados en la máquina concreta en la que se ha llevado a cabo. Hay que recordar que esta clave de ser de naturaleza compuesta, ya que el campo id_test comenzará con valor 1 para la primera prueba realizada en cada una de las máquinas y se va incrementando por cada nuevo test que se haya efectuado en la misma, por lo que podemos tener, por ejemplo, un id_test repetido con valor 3, pero nunca podrá estar asociado a un id_maquina idéntico. De esta manera, al asociar id_test e id_maquina, podemos averiguar y distinguir que se trata del test con id_test el que sea y ha sido efectuado en la máquina con id_maquina que corresponda. Con la formación de esta clave primaria compuesta en la tabla tests se derivan otras claves foráneas de los mismos atributos, en las cinco tablas restantes: Capítulo 4: Diseño de la Base de Datos 69 variante_protocolo_1, medidas_software_no_aceptadas, medidas_consolidadas y medidas_software_por_elemento_no_aceptadas. Siendo estas últimas las tablas hijas o referenciantes y la tabla de origen tests, la maestra o referenciada. Aunque podemos realizar una pequeña distinción entre las tres primeras y las dos últimas. De momento en este apartado, nos centraremos en las dos primeras (variante_protocolo_1, y medidas_software_no_aceptadas). Si se observa más adelante la Figura 21, se puede entender de forma más visual lo explicado en el párrafo anterior, se pueden ver plasmadas las relaciones de claves foráneas involucradas. Para el caso de la tabla variante_protocolo_1, la relación de clave foránea nos permitirá establecer en dicha tabla todos los tests efectuados en las distintas máquinas, los cuales únicamente se hayan realizado bajo el protocolo de medición 1, pudiendo observar en ella la variante de este protocolo utilizada (campo variante_protocolo_1). Siguiendo la misma interpretación, en la tabla medidas_software_no_aceptadas, diseñada para las funcionalidades venideras, podemos reconocer que ese test ha sido descartado posteriormente al análisis realizado por el software de la máquina y contabilizar los defectos globales de cada tipo detectados en los test descartados. 4.3.2.1 Relaciones de clave compuesta asociada a id_elemento Las dos tablas que restan de la totalidad, medidas_consolidadas y medidas_software_por_elemento_no_aceptadas, siguen la misma explicación que las tres anteriores en el efecto de la vinculación de clave foránea con la tabla tests, nada más que presentan un pequeño matiz. Este matiz es que la clave foránea presente en estas dos tablas lo hace también compartiendo clave de la misma tabla con el atributo id_elemento, tal y como se plasma en la Figura 22. La razón no es otra que identificar de manera inequívoca dentro del mismo test, a cada uno de los elementos analizados del lote evaluado y conocer así individualmente los defectos que presenta y a que tipología pertenecen. Este plan de análisis más detallado y estricto era una funcionalidad no aplicada en la actualidad, pero para considerar su implantación cercanamente. Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 70 Figura 21. Relaciones de clave compuesta Figura 22. Relaciones de clave compuesta asociados con id_elemento Capítulo 4: Diseño de la Base de Datos 71 De esta forma se podrán reconocer los tests que han sufrido correcciones con respecto a los valores determinados inicialmente y poder acceder tanto a los valores corregidos como a los originales en caso de ser necesarios. Los primeros serán englobados en la tabla medidas_consolidadas y los segundos en la tabla medidas_software_por_elemento_no_aceptadas. 4.3.3 Base de datos (conjunto global) Después de plantear y describir cada una de las tablas individualmente, detallar las relaciones creadas y que vinculan las tablas entre sí, únicamente queda por ver el aspecto del resultado global de la base de datos. Ello se puede apreciar en la Figura 23, reservando la página siguiente al completo para plasmarla y obtener así una mejor visualización de esta. A la hora de realizar la migración de los datos contenidos en el archivo Excel a la misma, las tablas irán recogiendo los valores de sus correspondientes registros y se establecerán las relaciones antes mencionadas mediante los valores asociados que contemplen los atributos seleccionados para ello. Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 72 Figura 23. Diagrama Relacional de la Base de datos Capítulo 4: Diseño de la Base de Datos 73 Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 80 con la misma. Finalmente, si el proceso ha ido según lo esperado y no ha surgido ningún error, se muestra un mensaje reflejando el éxito de la migración en pantalla. 5.2.3 Resultados Manifestada la situación de partida y con conocimiento del modo que se ha llevado a cabo para ejecutar cada una de las operaciones del script de migración, solo queda, por tanto, llevar a cabo dicha actuación y que el volcado de los datos de una ubicación a otra se haga efectivo. Finalmente, y después de todo ello, se habrá logrado conseguir el propósito y objetivo principal del TFG, realizar la migración automatizada de los datos contenidos en el archivo Excel a la base de datos diseñada e implementada. Estando en condiciones de dar soporte y cobertura al cuadro de mando que le sea asociado. El aspecto final de algunas de las tablas contenidas en la base de datos cambiará de apariencia y presentarán en ellas los datos que previamente había almacenados en el archivo Excel. Muestra de ello son la Figura 30 y Figura 31 correspondiéndose con los registros ahora contenidos en la tabla tests. La Figura 32 hace lo propio con la tabla maquinas. Las dos siguientes figuras, Figura 33 y Figura 34, pertenecen a los datos registrados y contenidos en las tablas configuracion_calidad y operadores, respectivamente. Por último, en la Figura 35 se recoge un fragmento de la totalidad de los tests que se almacenan en la tabla variante_protocolo_1. Figura 30. Primer fragmento del aspecto final de la tabla tests Capítulo 5: Herramienta automatizada para la migración. Resultados 81 Figura 31. Segundo fragmento del aspecto final de la tabla tests Figura 32. Aspecto final de la tabla maquinas Figura 33. Aspecto final de la tabla configuracion_calidad Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 82 Figura 34. Aspecto final de la tabla operadores Figura 35. Fragmento del aspecto final de la tabla variante_protocolo_1 Capítulo 5: Herramienta automatizada para la migración. Resultados 83 Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 84 6 Conclusiones y Líneas Futuras El último de los capítulos que recoge esta memoria de Trabajo de Fin de Grado está reservado para presentar las conclusiones que se han extraído a lo largo del desarrollo del presente proyecto y también poder exponer u ofrecer posibles líneas de actuación futura para seguir perfilando y mejorándolo. 6.1 Conclusiones La primera de las conclusiones no es otra que el objetivo general de este TFG se ha cumplido. La base de datos ha sido creada y ha dado cabida para albergar a los datos migrados desde un archivo Excel, los cuales han sido trasferidos gracias a la ayuda del script implementado. Pero a medida que el trabajo iba progresando se ha podido ir abstrayendo algunas otras más que se exponen a continuación. Alojar los datos es una base de datos es más práctico, organizado, escalable y manejable que tenerlos almacenados en un archivo Excel. Además, son infinidad de posibilidades las que se pueden ofrecer a raíz de poseer la información almacenada en una base de datos. En este caso concreto, al servir de soporte para un cuadro de mando o dashboard (desarrollado en un TFM realizado paralelamente) y derivar la multitud de información con la cual poder monitorizar, operar y obtener decisiones, forman un conjunto global potente a la par que muy útil. Obviamente, cuando se dispone de una gran cantidad de datos para realizar una migración de estos a otro lugar donde almacenarlos, será mejor recurrir a un proceso Capítulo 6: Conclusiones y Líneas Futuras 85 automatizado que hacerse de forma manual. El proceso será más breve y la probabilidad de cometer errores presentará un carácter más nulo. Antes de abordar un planteamiento, cuestión o problema, se recomienda analizar la información de conocimiento desde la que se parte. Posteriormente, proponer o diseñar un plan de etapas y actuación, y los objetivos que se quieren conseguir en cada una de ellas. Tener en cuenta en la realización de las mismas las diferentes posibilidades y herramientas que se pueden emplear para conseguir dichos propósitos. Ir comprobando y evaluando etapa a etapa si se ha conseguido lo propuesto. En su defecto, realizar las modificaciones pertinentes. En disposición de conseguir y lograr dar por finalizada la última de las etapas, comprobar y validar el conjunto global desarrollado y si se ha dado solución al planteamiento, cuestión o problema inicial. Otro de las reflexiones que destaca es que, aunque en un momento determinado, en cualquier contexto, se requiera de la decisión de uso de una determinada alternativa a la hora de presentar un abanico de ellas, no siempre la que se tiene que utilizar es la más potente, la más ampliamente utilizada, la más recomendada, etc., sino que depende de las prioridades o preferencias que se establezcan con anterioridad en cada caso. Actualmente, no se requiere crear bases de datos desde cero. La razón es que existen diversidad de frameworks, los cuales son herramientas que facilitan modelos conceptuales y estructurados a partir de los que ir adaptando, modificando y desarrollando nuestro software o aplicación como se requiera o desee. 6.2 Líneas Futuras La base de datos es capaz de almacenar los datos recogidos y de los que previamente se partía en el archivo Excel. En disposición de la misma, se me ocurren algunas otras funcionalidades posibles con las que podemos extender y mejorar su práctica. Una vez creada e implementada la base de datos, una de las posibilidades que se podría realizar es crear una aplicación web junto con la cual poder instaurar la base de datos para que la empresa pueda seguir desempeñando su trabajo y realizando sus pertinentes tests de evaluación de los lotes de productos facilitados para que, a su vez, Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 86 todos los parámetros, variables, factores y resultados involucrados en los mismos queden registrados directamente en la base de datos. Otra opción posible sería configurar en la misma aplicación buscadores que ayudaran a filtrar los tests de evaluación llevados a cabo y almacenados en la base de datos, en función del parámetro, factor o motivo que sea necesario o preferible en un momento dado. Un nuevo aspecto funcional que se le podía incluir es la creación de perfiles o tipo de usuarios que posean diferentes privilegios para operar con la base de datos. Es decir, un perfil de usuario que tengan acceso de lectura únicamente, otros que puedan acceder tanto para leer como para modificar datos de la misma, etc… En relación con el script automatizado para la migración de los datos, dadas las limitaciones que hay hasta el momento, ya que se debe de ingresar en el código del mismo el nombre del archivo que se quiere importar y alojarlo en una ubicación concreta… Un aspecto más práctico y que reduciría esa limitación, podría ser el de conseguir que mediante dicha herramienta nos presentara un posible cuadro de diálogo en el que nos preguntara o permitiera realizar una búsqueda por los directorios y seleccionar el archivo Excel con el que se quisiera realizar la migración. Capítulo 6: Conclusiones y Líneas Futuras 87 Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 88 7 Referencias [1] P. Marina Boillos, “Desarrollo de cuadros de mando (dashboard) para la Industria 4.0”, Trabajo Fin de Máster (Máster en Ingeniería de Telecomunicación). Universidad de Valladolid, ETSI de Telecomunicación, 2020. http://uvadoc.uva.es/handle/10324/43254 [2] R. Bourdon, Página web oficial del software WampServer. 2021. https://www.wampserver.com/en/ [3] A. Silberschatz, H. F. Korth & S. Sudarshan, “Fundamentos de Bases de Datos”. 6ª Edición. MacGraw-Hill ,2014. [4] R. Stephens, “Diseño de Bases de Datos”. Anaya, 2009. [5] R. Elmasri & S. B. Navathe, “Fundamentals of Database Systems”. 7ª Edición. Pearson Addison-Wesley, 2016. [6] MariaDB, Documentación oficial de MariaDB. Página web oficial de MariaDB, 2021. https://mariadb.org/documentation/ [7] Oracle Corporation, Documentación oficial de MySQL. Página web oficial de MySQL, 2021. https://dev.mysql.com/doc/ [8] Oracle Corporation, Documentación oficial de Oracle database. Página web oficial de Oracle, 2021. https://docs.oracle.com/en/database/oracle/oracledatabase/index.html Capítulo 7: Referencias 89 [9] Microsoft, Documentación oficial de Microsoft SQL Server. Página web oficial de Microsoft, 2021. https://docs.microsoft.com/es-es/sql/sql-server/?view=sql-server- ver15 [10] PostgreSQL Global Development Group, Documentación oficial de PostgreSQL database. Página web oficial de PostgreSQL, 2021. https://www.postgresql.org/docs/13/index.html [11] W3schools, Documentación y manual de uso del lenguaje SQL. Página web oficial de w3schools, 2021. https://www.w3schools.com/sql/default.asp [12] Oracle Corporation, Los tipos CHAR y VARCHAR (Documentación oficial de MySQL). Página web oficial de MySQL, 2021. https://dev.mysql.com/doc/refman/5.7/en/char.html [13] PHP, Documentación y manual de uso oficial de lenguaje PHP, 2021. https://www.php.net/manual/es/ [14] PHPspreedsheet, Documentación y manual de usuario oficial de PHPspreedsheet, 2021. https://phpspreadsheet.readthedocs.io/ Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 96 usuario es root y la contraseña estará vacía. Por lo tanto, estos valores se presentarán por defecto y lo que tenemos que hacer es presionar en Continuar. 3) Ya dentro de phpMyAdmin, arriba a la izquierda, nos presenta la posibilidad de crear una Nueva base de datos. Hacemos click y nos pedirá el nombre de la base de datos. Ponemos el que queramos, aunque nosotros estamos trabajando con el nombre acme. A la derecha nos presenta las preferencias de cotejamiento que va a usar nuestra nueva base de datos, pinchamos en el menú despegable y escogemos utf8_spanish_ci. 4) Creada ya la base de datos, aunque se encuentre vacía, nos aparecerá junto con el resto, en el lateral izquierdo. Debemos escoger y seleccionarla para a continuación trabajar con ella. 5) Una vez seleccionada, en la parte superior entre las distintas opciones con las que podemos operar, seleccionamos Importar. 6) A continuación, nos pedirá seleccionar nuestro archivo .sql. Debemos buscar y seleccionar el archivo acme.sql que le he proporcionado. El resto de las opciones las dejamos por defecto y al final pulsamos en Continuar. 7) Finalmente, ya tenemos nuestra base de datos completada con las diferentes tablas y relaciones que deben implementar sus características. 8.4 Migración del archivo Excel 1) Primeramente, debemos acceder al directorio creado automáticamente cuando instalamos WampServer. Este deberá estar en el disco dónde instalamos la aplicación y con el nombre que la denominamos en la instalación. Si todo se hizo o dejó por defecto, este directorio debería tener esta ruta: C:\wamp64. 2) Una vez dentro del mismo, debemos acceder al directorio www. 3) Dentro de él podemos crear tantos directorios como proyectos con los que trabajar. Por lo tanto, para llevar a cabo el nuestro, descomprimimos en este directorio el Capítulo 8: Anexo. Guía de ejecución 97 archivo comprimido ACME.zip, lo que dará lugar a un nuevo directorio con el nombre de ACME. 4) En consecuencia, si accedemos al mismo (la ruta completa en la que deberíamos estar llegado este punto sería C:\wamp64\www\ACME) debemos comprobar la existencia de los siguientes archivos: ACME.xlsx, baseDatos_acme.php, conexion_acme.php, cierreConexion_acme.php, migracionExcel_acme.php y la carpeta vendor. 5) Disponemos ya de todo, lo único que nos queda es ejecutar nuestra herramienta para completar nuestra migración y poblar nuestra base de datos creada previamente. Para ello, debemos abrir nuestro navegador e introducir en él la dirección: http://localhost/ACME/migracionExcelACME.php 6) Una vez ejecutada la instrucción anterior, se mostrará un mensaje de éxito en la pantalla, lo que indica que todo se ha ejecutado correctamente y ya podemos consultar nuestra base de datos completada en la aplicación phpMyAdmin, accediendo a ella tal y como se explicó en los primeros puntos de la sección anterior 8.3. Observaremos que la migración se habrá realizado correctamente y que los datos están almacenados en sus correspondientes tablas. Diseño e implementación de una base de datos como soporte para un cuadro de mando para la Industria 4.0 98