El universo de las bases de datos relacionales + SQL

Un modelo de base de datos según su utilidads

Para Gavin (2006) una base de datos estructura cómputo para alojar y recuperar "una gran colección de información organizada".

En cambio, un modelo de base de datos es una plantilla diseñada que organiza datos (e impone reglas en cómo serán o no organizados), o editados, o cambiados controladamente según una necesidad única dentro de una gran base de datos.

Un modelo de base de datos responde a las siguientes preguntas:

¿Qué tipos de entidades (grupos de datos) existen?
¿Cómo se relacionan?
¿Qué operaciones son válidas sobre ellas?

Por ejemplo, no es lo mismo administrar una gigante base de datos, como la del Municipio de Guayaquil. Eso requiere alojar nombres, direcciones y pagos de miles de usuarios en tiempo real (exige integridad –no deben repetirse datos– y seguridad -no deben ser accesibles o alterados por terceros–, además de actualizaciones en línea y respuesta inmediata en las consultas).

En contraste con una base de datos que solo requiere guardar el puntaje (transaccional, con menos concurrencia -menos usuarios al mismo tiempo haciendo lo mismo–) en un sencillo videojuego instalado en mi celular.

Ya expliqué en esta sección algunos tipos de modelos de bases de datos. Los resumo aquí:

De archivo simple (como en los formatos de archivos .csv) donde los datos tan solo estan separados por comas.
Modelo de base de datos jerárquico (con los datos ramificados y conectados de arriba hacia abajo, según su descendencia de mayor -dato padre- a menor -dato hijo-). El problema con ese modelo es que existe una sola ruta para hallar un dato.
Modelo en red (los mismos datos ramificados, conectados o relacionados entre sí mediante enlaces previamente diseñados), pero esta vez pueden ser accedidos desde distintas rutas y no solamente por la descendencia de arriba hacia abajo.
Modelo de objeto, según Gavin (2006, p. 12) refiere a una estructura tridimensional de datos, permitiendo diferentes puntos de ubicación o de ingreso para hallar un dato único. El problema con este modelo es que los datos no siempre estan vinculados entre sí (como en el modelo relacional), por lo que hallar más de un dato es muy complejo con el modelo de objeto .
Modelo relacional, en forma de tablas con campos de datos conectados según un dato único compartido entre esas tablas. En este modelo un dato muy anidado a profundidad es mejor accedido tan solo ubicando otro dato relacionado directamente.

En otras palabras, ya que diferente software (como un videojuego o la base de datos del Municipio de Guayaquil, por ejemplo) alojan datos según su capacidad y posibilidad de uso, existirá un modelo diferente de base de datos para cada plataforma. Es decir, cada modelo de base de datos se diseña según cómo será accedido por los usuarios.

Diagrama de tres modelos de bases de datos: jerárquico, de red y relacional, en Guayaquil, Ecuador, tomado de www.duduromeroa.com — **Tres modelos de bases de datos**: primero, jerárquico (una sola ruta de búsqueda pero limitada a las jerarquías); segundo, de red (más de una ruta de búsqueda, pero limitada a los vínculos diseñados); y tercero, modelo de entidad relacional (en inglés, ERD -entity relacional DataBase– en el cual organiza los datos en tablas conectadas mediante un único dato común e irrepetible).

Diseñando desde las relaciones de los datos

Diseñar desde las relaciones de los datos significa aclarar cuál es la secuencia real que provoca la existencia de un dato antes de ser insertado en una tabla de datos.

Por ejemplo, si una librería necesita enlistar los libros que venderá, es muy posible que en este año 2026 un autor solo haya publicado un libro; o que ya tenga publicado muchos libros; o que el mismo autor no tenga publicado ningún libro este año.

Ejemplo xxxx

xxxx

Si bien solo el autor estará en la lista, el flujo del negocio de una librería depende de la cantidad de libros publicados por uno o muchos autores. Una librería nunca podría vender libros que no existan. Por lo que los datos a ingresar deben regirse bajo un criterio de integridad.

Así mismo, más de un autor podría tener un mismo nombre o un mismo apellido. O sus libros podrían tener similar título, pero con diferente año de publicación o con más de un colaborador en la obra. El desafío de diseñar desde las relaciones de los datos es evitar que los datos se solapen o se reescriban.

Ejemplo de tabla relacional, con columnas, registros (o tuplas), en Guayaquil, Ecuador, tomado de www.duduromeroa.com — **Ejemplo de tabla relacional**, con columnas, registros (o tuplas). Si bien los datos en más de un campo podrían estar repetidos (como en el apellido Palacio) el código que representa cada fila es único. Basado en Gavin Powell, (2006). Beginning Database Design. Wiley P.

Tipos de datos

Los tipos de datos definen qué especie de dato es permitido para cada campo (y cuál no se permite). Por lo que funcionan como un filtrado para cada dato de cada campo. Por ejemplo, los datos ingresados para cada registro en el campo Código únicamente deben ser numéricos enteros sin decimales (a menos que se indique lo contrario).

Otro tipo de dato son los caracteres alfanúmericos (o strings, en la jerga técnica). Durante el diseño de la tabla es posible indicar la extensión máxima de cada tipo de dato.

Representar relaciones en una tabla relacional

Como ya explicamos, las bases de datos deben abstraer lo que ocurre en la vida real. En el ejemplo de una librería vimos que es posible que uno o más autores hayan publicado uno o muchos libros. Esas dimensiones (uno, muchos; o muchos a muchos; o cero a uno, etc.) se convierten en relaciones entre dos o más tablas que deben ser expuestas.

Ejemplo de relaciones entre tablas en bases de datos relacionales, en Guayaquil, Ecuador, tomado de www.duduromeroa.com — **Ejemplo de relaciones entre tablas** en bases de datos relacionales Basado en Gavin Powell, (2006). Beginning Database Design. Wiley P.

Claves o índices (keys en inglés)

Un identificador numérico y sencuencial para cada fila o tupla es como un número de cédula para un ciudadano. La clave (o índice) es irrepetible (aunque algunos de los campos tengan datos repetidos). La clave va vinculada a una fila de datos y (lo más importante) sirve como identificador de enlace en otros grupos de datos (en este caso, tablas).

Existen tres tipos de claves (o de índices, o de keys): Clave primaria, clave foránea y clave única.

Clave primaria: Es única e identifica a una única fila o tupla de datos. Es usada para crear relaciones entre tablas.
Clave única: lo es porque no se repite. No toda clave única es clave primaria.
Clave foránea: Es la copia de una clave primaria que inició en una tabla-padre y luego es alojada en otra tabla-hijo. La clave foránea crea una relación inter-tabla, referenciando fila con otros datos.
Cuando una clave primaria es aprovechada para vincular datos en una nueva tabla, entonces esa primaria se convierte en foránea.