Cómo abstraer la base de datos para una aplicación. Introducción

En octubre de 2021, participé en el reto de tripulaciones como parte del bootcamp de Ciencia de datos en The Bridge, donde nos enfrentamos al reto de crear una aplicación partiendo de una idea hasta la presentación del prototipo.

Teníamos que hacer una aplicación con una calculadora de huella de carbono, para lo que tuvimos que buscar información sobre cómo calcularla y qué debíamos tener en cuenta. Los chicos de UX/UI pusieron mucho de su parte para hacer una propuesta de valor atractiva, con muchas opciones y, además, gratuita para el usuario final.

Formaba parte del equipo de Ciencia de datos, nuestras tareas estaban enfocadas en la parte que no se ve, en el back-end, donde, a partir de la propuesta y diseño de aplicación que habían hecho UX/UI, teníamos que abstraer las ideas y estructurar la base de datos, buscar datos y cómo realizar las diferentes partes e integraciones de la aplicación, trabajando con los compañeros de Full Stack. A mí, como se puede intuir, me tocó diseñar y escribir la base de datos.

El grupo de trabajo dedicaba su tiempo libre al proyecto, todos trabajábamos y teníamos el tiempo muy limitado, tanto para el desarrollo como para la presentación de la aplicación.

La parte que nunca llegamos a terminar en back-end fue la calculadora; nos limitaba tener que utilizar datos públicos —o a los que pudiéramos acceder mediante técnicas de scrapping—. Los compañeros encargados se dieron cuenta de que era complicado acceder a ellos —son datos muy difíciles de conseguir y las empresas que los tienen liberaban, como mucho, muestras pequeñas que no nos servían para lo que queríamos hacer—.

Tengo que mencionar aquí a mi compañero, Jorge N., de Full Stack, con quien estuve trabajando codo con codo para sacar la base de datos y conectarla en el back-end; hicimos todo lo posible para conseguirlo, pero nos quedamos ahí. Al final, era un trabajo titánico que, con el tiempo que teníamos, era imposible realizar; como era previsible, según la complejidad de diseño y funcionalidades que habíamos hecho. No llegamos al objetivo y no presentamos un prototipo, pero sí explicamos los problemas que nos habíamos encontrado y cómo habíamos planteado el desarrollo posterior. Teníamos cierto optimismo con seguir trabajando en ella, pero el tiempo hizo lo que mejor sabe hacer: recordarte todas las obligaciones que hacen que vayas postergándolo al futuro indefinidamente.

Aunque los proyectos no se acaben o salgan bien, se puede aprender mucho del proceso; por ejemplo, ahora sé que, de comenzar un nuevo reto tan complejo, me enfrentaría al trabajo y al desarrollo utilizando un modelo incremental o uno iterativo, porque nuestro mayor error fue querer hacerlo todo a la vez desde el principio.

Lo sé, no has llegado hasta aquí para que te hable de modelos de trabajo para el desarrollo de aplicaciones, sino de la parte que me tocó hacer durante aquellas semanas de trabajo para que Jorge pudiera montar y hacer magia posteriormente: la base de datos.

Elección del modelo

Cuando te enfrentas a un proyecto sin ninguna referencia o alguien que dicte las normas, acabas dándote cuenta de que tienes muchas formas diferentes de abordar el problema y que existen muchas soluciones posibles. Lo que requiere de evaluar las diferentes opciones y elegir aquella que resuelva mejor el problema. No tiene que ser la solución perfecta, muchas veces la ideal es inviable.

Cuando estudiamos bases de datos, la clasificación más habitual es diferenciarlas en dos bloques según la organización de los datos: relacionales y no relacionales. Pero esta es solo una síntesis.

Esta clasificación se utiliza para simplificar —las que te encuentras normalmente son relacionales—, por lo que el resto de las opciones acaba aglutinándose.

Entonces, ¿cómo podemos clasificar y entender las diferentes bases de datos? Por ejemplo, podemos hacer una clasificación de bases de datos según la interacción del usuario: estáticas o dinámicas; todas las bases de datos pueden comportarse de ambas maneras, porque la interacción del usuario dependerá de la relación que tenga con ella y de sus permisos.

• Bases de datos estáticas: bases de datos de consulta, el usuario no puede modificar la información que contiene.
• Bases de datos dinámicas: el usuario puede modificarla y actualizar la información que contiene.

El comportamiento que tienen los usuarios con una base de datos es relevante, pero se podría considerar como una clasificación externa, basada en cómo se interactúa, no en cómo es; que es en lo que debe enfocarse el análisis para decidir cuál encaja mejor con el proyecto. Así, por organización de los datos, nos encontramos con varias que darían para una entrada cada una:

• BBDD lógicas: permiten hacer deducciones a través de inferencia. Surgen como respuesta a la limitación de una base de datos relacional para realizar consultas recursivas y deducir relaciones indirectas de los datos almacenados. El lenguaje que utilizan es declarativo y permite deducir según hechos y reglas almacenadas.
• BBDD distribuidas: son aquellas que tienen los datos repartidos entre diferentes nodos, donde cada nodo es una máquina individual que, normalmente, no comparte espacio con otra y que se comunica con otros nodos a través de una red por la que envían y reciben datos. Existen principalmente cuatro formas de distribuir los datos en estas: Centralizada, Particionadas, Replicadas y uno Mixto entre particionadas y replicadas.
• BBDD documentales: son aquellas que permiten la indexación del texto completo. Su principal ventaja está en las búsquedas de información interna y en su gran capacidad para almacenar grandes volúmenes de datos. Dentro de estas se encuentran sistemas de índices optimizados, llamados tesauros.
• BBDD jerárquicas: este modelo se organiza como las raíces de un árbol, donde un nodo padre puede tener varios hijos y estos hijos ser padres de otros, organizando la información en cascada. Son especialmente útiles para aplicaciones que manejan gran volumen de datos compartimentados, permite tener estructuras estables y con buen rendimiento. La deficiencia del modelo está en su incapacidad para evitar la redundancia de información.
• BBDD no relacionales: son las que no utilizan el esquema tabular de filas y columnas del modelo relacional. Estas bases de datos buscan la optimización según los requisitos particulares del tipo de datos que almacenan; es decir, todos los casos descritos aquí, menos las basadas en el modelo relacional, son bases de datos no relacionales.
• BBDD multidimensionales: desarrolladas para aplicaciones muy concretas, son muy similares a las bases de datos relacionales, diferenciándose a nivel conceptual: en estas, los atributos de las tablas pueden ser de dos tipos: representan dimensiones de la tabla o métricas de aprendizaje.
• BBDD multimodelo: son aquellas que, dentro de un único back-end, integran diferentes tipos de modelo de bases de datos.
• BBDD orientadas a grafos: representan la información con nodos (entidades) y sus relaciones, aplican la teoría de grafos para recorrer el grafo y describir los atributos de las entidades y relaciones.
• BBDD orientadas a objetos: es un modelo joven, en ella se almacenan los objetos completos (estado y comportamiento) y cumple con los conceptos más importantes del paradigma de objetos: encapsulación, herencia y polimorfismo.
• BBDD de red: es un modelo que mejora a su predecesor, el modelo jerárquico; en la red, un nodo puede tener varios padres, lo que supone una gran mejora y soluciona la redundancia de datos. La gran complejidad de este modelo hace que sea raro encontrarlo en aplicaciones destinadas para usuarios legos en programación.
• BBDD relacionales: son las más habituales porque se centran en representar problemas reales y administrar dinámicamente los datos. A diferencia del modelo de red, el lugar y la forma de almacenamiento de datos no es relevante, lo que es una gran ventaja para recuperar información a través de consultas almacenadas. La estructura de datos en las relacionales se basa en tablas de datos compuesta por registros que describen, a través de los campos, una información (o un caso dentro de la base de datos). Estas tablas, además, pueden relacionarse con otras para aportar mayor consistencia y evitar redundancias que, de no existir, serían recurrentes.
• BBDD transaccionales: son raras y su función es enviar y recibir datos a gran velocidad. Las bases de datos transaccionales están dirigidas al análisis de calidad, la producción y la industria. Su finalidad es recolectar y recuperar datos con gran velocidad, por lo que suelen pecar de redundancias e información duplicada.

Para el desarrollo de la base de datos elegí el modelo relacional, porque era el más común y solucionaba bien el problema; además, me sentía cómoda trabajando con SQL y, al final, si necesitaba alguna característica de alguno de los otros tipos, podía convertir posteriormente la base de datos en una multimodelo.

Si quieres saber cómo la planteé y dibujé, permanece atento, iré escribiendo sobre el proceso de creación de la base de datos poquito a poco.

Contenido originalmente publicado en Medium el 18 de mayo de 2022 (https://medium.com/@erebyel/introduccion-a-la-abstraccion-de-una-base-de-datos-b39bae6a2d5a)