Bases de Datos

Las Bases de Datos (BD) están en nuestro día a día y son de gran relevancia para prácticamente todas las aplicaciones que usamos y para prácticamente todas las empresas que conocemos. Sin las Bases de datos no tendríamos forma de almacenar la información, y cada vez tenemos más información que guardar así que cada vez tiene más importancia.

En este artículo, te voy a explicar qué son las bases de datos, cómo se diseñan las bases de datos y la teoría principal de las bases de datos en general. Espero que te sea de ayuda ya sea para implementar un programa que haga uso de esta información o simplemente para aprobar una asignatura.

Así que, ¡vamos a ello!

Introducción a bases de datos

En primer lugar, es importante que conozcas el concepto de Base de Datos. Una Base de Datos es una forma estructurada de almacenar información. Las Bases de Datos están formadas por tablas relacionadas entre si, donde se guardan los datos de diferentes elementos que comparten características.

A efectos prácticos, una base de datos es una tabla o un conjunto de tablas, donde en cada columna se almacena siempre el mismo tipo de valor.

Por ejemplo, si quisiéramos diseñar una BD que almacene los videojuegos que tenemos en nuestra colección, primero tendríamos que decidir qué nos interesa guardar. A priori, nos interesa guardar el título, la empresa que lo distribuye, la plataforma en la que tenemos dicho videojuego y el año de lanzamiento.

Si con esta información que queremos guardar, almacenamos una fila de la tabla con los datos:

• Final Fantasy VII Remake
• Square Enix
• PS4
• 2020

Ya sabemos a qué videojuego nos referimos. Si estructuramos los datos de esta manera y lo implementamos correctamente, al crear nuestra base de datos podremos consultar los videojuegos que tenemos de una plataforma concreta, o que se hayan lanzado en un año concreto, entre otras cosas.

Este es un ejemplo sencillo de lo qué es una base de datos, a lo largo de esta parte del curso iremos viendo más ejemplos que se irán haciendo más complejos según avancemos.

Ahora bien, ¿por qué nos hacen falta las Bases de Datos? Cada vez manejamos más información. En las empresas, en los establecimientos, o incluso una app en la que almacenes la información de lo que comes. En todas partes tenemos datos. Estos datos suelen almacenarse de forma que se puedan interpretar y están relacionados entre sí.

Por eso, entre otras cosas, nos hacen falta las bases de datos. Cuando la información que almacenamos empieza a crecer, es inviable manejarlo manualmente y por eso es deseable almacenar dicha información en una base de datos.

Una vez queda claro (o eso espero) la importancia que tienen las bases de datos en la vida, vamos a ir pasando a los siguientes puntos. En ellos te voy a explicar cómo podemos implementar Bases de Datos en programación, desde las opciones más sencillas hasta lo más complejo.

Por último, te voy a dar consejos basados en mi experiencia y en la teoría de Bases de Datos, sobre lo que debes hacer y lo que debes evitar mientras estés diseñando e implementando tu base de datos.

Como implementar Bases de Datos

En cuanto a las formas de implementar las bases de datos, me refiero a como hacerlo físicamente: donde guardar la información y en qué formato. En general las bases de datos en programación suelen implementarse con un gestor de bases de datos.

Los Sistemas Gestores de Bases de Datos (SGBD) son sistemas que nos permiten la creación y manejo de bases de datos. Cada lenguaje de programación tiene uno o varios SGBD asociados.

Las bases de datos pueden manejarse sin necesidad de un lenguaje de programación, mediante consultas SQL. Esta sería la forma más directa de manejar una base de datos.

Los SGBD son una capa intermedia entre la base de datos y nuestro programa, que nos permite utilizar funciones del lenguaje de programación utilizado para llevar a cabo, internamente, las consultas SQL, sin necesidad de hacerlo de una manera externa.

Sin embargo, también podemos crear nuestras bases de datos de forma más sencilla si no tenemos tanta información que almacenar y si únicamente la vamos a utilizar nosotros en nuestro ordenador. Esta forma más sencilla sería almacenar la información de forma estructurada en un fichero.

A continuación, voy a ir punto por punto comentándote cuales son las diferentes formas en las que puedes montar una base de datos y en qué casos conviene más una u otra.

Bases de datos sobre ficheros

Este tipo de Bases de Datos está pensado para sistemas más pequeños, donde necesitamos almacenar cierto tipo de información pero que nos sirve con guardar los datos de una tabla, por ejemplo.

Se utiliza en situaciones donde nos interesa guardar información estructurada que no depende de otras fuentes de datos. Por ejemplo, la base de datos de médicos, pacientes y citas que nombraba anteriormente, nos obliga a crear al menos tres tablas: médicos, pacientes y citas u horario. Estas tres tablas están relacionadas entre sí.

Implementar una BD de este tipo sobre ficheros directamente va a darnos más problemas que ventajas, por tanto no merece la pena. Sin embargo, para el primer ejemplo que puse en el que queríamos almacenar nuestra colección de juegos, si que valdría, ya que nos interesa guardar (en principio) los datos de la tabla que comenté: título, distribuidor, plataforma y año de lanzamiento.

Para implementar una BD sobre ficheros, la idea es guardar manualmente los datos de la tabla en un fichero, sin necesidad de utilizar SGBD.

Por ejemplo, guardar para los datos anteriores debemos escribir en una línea de fichero: Final Fantasy VII Remake; Square Enix; PS4; 2020;. He puesto como ejemplo el separador ";" para indicar donde empieza y termina cada una de las columnas de la tabla, que sería algo así:

Esta manera de gestionar BD está pensado, como ya te he comentado, para BD pequeñas y que vayan a ser (idealmente) utilizadas sólo en un ordenador y por una persona.

Existen formatos de ficheros para guardar la información estructurada, siendo uno de los más utilizados JSON, ya que nos permite almacenar los datos de forma etiquetada y de fácil interpretación.

Este tipo de Bases de Datos están muy bien para almacenar pequeños conjuntos de información o para nuestro uso personal de alguna aplicación.

Bases de datos con tablas en local o centralizada

La siguiente opción es utilizar un SGBD centralizada, es decir, guardando la información únicamente en un ordenador. Esta manera de implementar una base de datos nos permite utilizar utilizar un sistema de consulta ya especificadas a la BD, en lugar de simplemente almacenar la información, como era el caso anterior.

Es buena idea utilizar este tipo de implementación cuando lo que vamos a montar es una base de datos para una pequeña empresa que sólo tiene una sucursal, por ejemplo. La mayor limitación es que todo se almacena en un único lugar. 

Sin embargo, no es tan limitado como puede parecer, ya que este tipo de Bases de Datos no tienen porque ser accesibles únicamente desde el ordenador en el que están montadas. De hecho, normalmente no es el caso, ya que suelen tener un sistema de gestión de la información que nos permiten acceder a la BD desde diferentes ordenadores. Para ver esta idea de forma clara, voy a ponerte un ejemplo gráfico.

De esta forma, se tiene una base de datos en local a la que tienen acceso varios usuarios. Además, esta opción tiene más ventajas, ya que si sólo tenemos los datos en un lugar, estos estarán más protegidos. Sin embargo, también hay que tener en cuenta que si le pasa algo a la máquina en la que tenemos almacenada la información, es fácil perder todos los datos.

Por eso en este tipo de sistemas es importante hacer copias de seguridad periódicas en máquinas externas.

Bases de datos con tablas distribuidas

Esta opción es la que más envergadura tiene, ya que esta basada en tener la misma Base de Datos físicamente en diferentes máquinas. Estas máquinas se mandan mensajes de actualización entre ellas para que todas las copias de la base de datos estén en la última versión.

Con este tipo de organización, tenemos la ventaja de que tenemos muchas más copias de la información y esto aporta seguridad. Si algo le pasase a una de las máquinas que tiene la información almacenada, el sistema informático completo no tendría ningún problema, ya que los datos se podrían pedir a otra de las copias.

Además, esta opción no nos obliga a tener una gran cantidad de copias de seguridad, ya que la infraestructura en sí nos proporciona diferentes copias de la información, situadas físicamente en diferentes lugares.

De esta manera, es extremadamente complicado que se pierdan los datos, siempre y cuando haya suficientes máquinas diferentes en el sistema distribuido y estén en unas condiciones óptimas.

Por ejemplo, no tendría mucho sentido poner todas las máquinas en el mismo sitio, ya que si ocurre algo en ese lugar como por ejemplo: incendio, corte de luz, inundación, etc, si que se acabarían perdiendo los datos. Puede parecer muy alarmista, pero hay que tener en cuenta cualquier posible suceso cuando se organiza algo a gran escala.

Sin embargo, también es importante resaltar que no tiene el mismo valor económico montar una infraestructura en la que hace falta utilizar varias máquinas que otra en la que sólo nos hace falta una.

Teoría de las bases de datos

Ahora que ya te he explicado las diferentes maneras en las que podemos implementar un SGBD, voy a explicarte la teoría que hay que seguir para diseñar correctamente una Base de Datos. Estos aspectos son independientes al lenguaje de programación que vayamos a utilizar en los programas que accedan a la base de datos, por supuesto.

Para ir entendiendo la teoría que voy a exponer, vamos a acompañarla de un ejemplo, que posteriormente implementaremos paso por paso. Como ejemplo, vamos a imaginar que tenemos que crear y manejar una base de datos de una protectora de animales. Concretamente, tendremos que tener en cuenta los datos de los animales, de los trabajadores y de las personas que han adoptado algún animal. Estos datos han de relacionarse entre sí y seguir algunas normas establecidas que hay a la hora de diseñar una base de datos.

Para diseñar una base de datos donde almacenar información es preciso llevar a cabo ciertas decisiones de diseño, que van a depender de los datos que tengamos.

Pero en general, toda construcción de base de datos está constituida por los mismos pasos: primero debemos identificar las tablas que necesitamos crear para la representación de los datos; después, debemos especificar los datos que queremos guardar en cada tabla e identificar la clave primaria de la tabla. Una vez tenemos las tablas creadas, hay que relacionarlas entre sí y manejar los datos que podamos tener repetidos.

Identificar Tablas

Para identificar las tablas debemos ser capaces de separar los diferentes elementos que vamos a tener en nuestra base de datos y agruparlos. Por ejemplo, si quisiéramos almacenar los datos de videojuegos, como vimos en el ejemplo anterior, podríamos tener la tabla de videojuegos, donde se almacena la información de los mismos.

Especificar datos

Una vez tenemos las tablas identificadas, debemos ser capaces de asignarles unos campos o atributos, que será la información que necesitamos almacenar en cada caso. Estos atributos son comunes a todos los elementos que vamos a querer añadir a la tabla. Siguiendo el ejemplo de los videojuegos, en este caso queremos guardar el nombre del videojuego, la empresa distribuidora, la plataforma, y el año de lanzamiento.

Identificar Clave Primaria

La clave primaria es aquella que nos permite identificar cada fila de la tabla con el menor número de atributos posibles. Lo ideal es únicamente con un atributo aunque no en todos los casos es posible y a veces hay que elegir dos o tres. Preferiblemente, la clave primaria debería estar compuesta por una clave numérica. No es obligatorio pero facilita las operaciones.

Esta clave primaria es muy importante identificarla bien, ya que nos sirve para identificar cada uno de los elementos de nuestras tablas y diferenciarlos del resto, pero además también nos van a servir en los siguientes pasos de la creación de la base de datos.

En nuestro ejemplo podríamos utilizar el nombre del videojuego. Sin embargo, como te he comentado, es mejor utilizar valores numéricos para la clave. Así que en este caso vamos a añadir un nuevo atributo: código de barras. De esta manera, siempre se podrá identificar de forma inequívoca a qué videojuego nos referimos con esta clave primaria.

Relacionar Tablas entre sí

Una vez tenemos las tablas, atributos y claves primarias identificadas, llega el momento de hacer las relaciones entre tablas. Si no hacemos esta relación, los datos entre las tablas serán inconexos.

En nuestro ejemplo, en principio, no tenemos nada más que una tabla, así que no tendremos que manejar las relaciones entre tablas.

Manejar Datos Repetidos

Los datos repetidos en las bases de datos pueden dar muchos problemas a largo plazo. Por eso, una muy buena práctica es hacer comprobaciones de que no tendremos datos repetidos a lo largo de nuestras bases de datos. Para ello, debemos comprobar haciendo pequeñas pruebas si puede darse el caso de que tengamos este problema.

En el ejemplo, tenemos datos repetidos, así que vamos a analizar. Cuando almacenamos un videojuego y especificamos la plataforma, este atributo va a repetirse en varias ocasiones, ya que plataformas hay pocas y juegos hay muchos. Entonces, la mejor práctica es dividir la información y crear una nueva tabla que guarde las plataformas, asociadas a un ID.

Por ejemplo, tendríamos la tabla de plataformas con el ID 1 para playstation, ID 2 para XBOX, ID 3 para Nintendo e ID 4 para PC, por ejemplo. Es muy genérico, pero para el ejemplo nos vale. De esta manera, tendríamos las tablas:

Ahora si que hay relaciones entre las tablas, la clave primaria de la tabla plataformas (ID) es una clave foránea en la tabla de videojuegos.

Aspectos importantes y aspectos que debemos evitar cuando creamos una Base de Datos

Cuando creamos una base de datos debemos tener en mente desde el principio cuales son nuestras intenciones al almacenar la información y también cuales pueden ser nuestras intenciones de crecimiento.

Es decir, Vamos a suponer que se plantea la base de datos para una tienda de libros donde guardamos clientes, libros y compras en tres tablas (ver ejemplo completo en esta entrada del blog). Después de tener esta base de datos en funcionamiento durante varios años, imaginemos que queremos añadir a nuestro sistema la funcionalidad de mandar un email a los clientes con ofertas.

Obviamente, si no se ha guardado el email de los clientes hasta ese momento, solo se enviarán mensajes a los nuevos clientes. Por eso, es buena idea añadir esta información de contacto desde un inicio en el diseño de nuestra base de datos, aunque en principio no pensemos que se pueda utilizar.

Un punto muy importante a la hora de diseñar nuestra base de datos es que no debemos, bajo ningún concepto, manejar datos repetidos. Esto ya lo sabes porque te lo expliqué en la fase de diseño, pero ahora te explico porqué es así. En nuestro ejemplo de videojuegos manejamos el punto de datos repetidos en plataforma, donde especificamos 4 en concreto que son las que se usan en la tabla principal de videojuegos, haciendo referencia a sus ID.

¿Por qué lo hacemos así en lugar de poner directamente el nombre de la plataforma? Sencillo: si escribimos manualmente la plataforma siempre que añadimos un nuevo producto, es más fácil que nos equivoquemos y la escribamos mal. En ese caso, aparte de las plataformas que si que existen, puede que en la base de datos haya plataformas como nintnedo, plasytation, XVOX o CP, por ejemplo.

Entonces pensarás, pero puede ocurrir lo mismo y que pongamos un número que no hace referencia a la plataforma que queremos especificar. Bueno, al menos usando esta técnica evitamos poner mal un nombre y si añadimos, por ejemplo 5 a nuestro atributo plataforma, y en la tabla de plataformas no existe dicha entrada, va a avisarnos y lanzar un error. De forma que no podremos añadir elementos que no existan en la tabla.