Modelos de BD

¿Qué es un modelo de datos?

Un modelo de datos es la forma en que una base de datos organiza la información y las relaciones entre sus partes. No es el contenido —qué datos hay— sino cómo están estructurados: en qué unidades se agrupan, cómo se conectan y qué reglas siguen.

Es una distinción parecida a la de un plano y una casa. El plano dice cuántos ambientes hay y cómo se comunican; no dice quién vive en cada uno. Cambiar el modelo es cambiar el plano: los datos son los mismos, pero se guardan y se consultan de otra manera.

A lo largo de la historia se propusieron varios modelos, y no todos sobrevivieron. Los dos primeros —jerárquico y de red— fueron los únicos durante un tiempo y hoy casi no se usan, pero entender por qué quedaron atrás ayuda a entender por qué el relacional se impuso.

Modelo relacional

Es el modelo dominante desde hace décadas. Fue propuesto por Edgar Codd en 1970, cuando trabajaba en los laboratorios de IBM, y su idea central era radical para la época: organizar los datos en tablas y olvidarse de cómo se guardan físicamente.

Sus principios

• Todo se guarda en tablas, con filas y columnas. No hay jerarquías ni punteros.
• Las tablas se relacionan por valores, no por posiciones: una clave foránea contiene el mismo valor que la clave primaria de la otra tabla.
• El orden de las filas no importa. Una tabla es un conjunto, no una lista ordenada. Si se necesita un orden, se pide en la consulta.
• Se consulta con un lenguaje declarativo, SQL: se describe qué se quiere, no cómo conseguirlo.

Esa última característica es la verdadera revolución del modelo. En un sistema jerárquico, para obtener un dato había que escribir un programa que recorriera la estructura paso a paso. En el relacional, se escribe una frase —"traeme los clientes de La Plata"— y el gestor decide cómo hacerlo. Eso hizo que consultar una base dejara de ser una tarea de programadores.

Modelo jerárquico

Fue el primer modelo comercial, desarrollado por IBM en los años sesenta. Organiza los datos como un árbol: hay un registro raíz y, debajo, niveles de registros hijos, cada uno con un único padre.

Es intuitivo cuando los datos tienen esa forma natural: una ciudad tiene sucursales, cada sucursal tiene empleados, cada empleado tiene tareas. Y es muy eficiente para recorrer ese árbol siempre en el mismo sentido.

El problema

La limitación aparece cuando la realidad no es un árbol. Si un mismo dato pertenece a dos ramas distintas —un producto que figura en dos pedidos, un alumno que cursa dos materias— hay que duplicarlo. No hay forma de representar que un hijo tenga dos padres. Y la consulta siempre tiene que empezar desde la raíz: para llegar a un empleado hay que entrar por la ciudad y la sucursal, aunque lo que se busque sea el empleado.

Modelo de red

Es la evolución del jerárquico, y surge para resolver justamente su limitación. En el modelo de red, un registro puede tener varios padres: los datos se organizan como una red de relaciones, no como un árbol.

Se estandarizó a fines de los sesenta y fue muy usado en sistemas grandes. Resolvía el problema de la duplicación, pero a un costo alto: las relaciones se guardaban como punteros físicos entre registros, así que la estructura quedaba rígida y las consultas seguían exigiéndole al programador recorrer la red paso a paso.

Modelo orientado a objetos

Este modelo traslada los conceptos de la programación orientada a objetos al almacenamiento: los datos se guardan como objetos completos, con sus atributos y sus métodos, y se organizan en clases con herencia.

Su ventaja es que evita el trabajo de traducir entre el mundo de los objetos del programa y el mundo de las tablas de la base. En los sistemas relacionales ese paso existe y consume bastante esfuerzo: el programa tiene objetos y la base tiene filas, y hay que convertir de uno a otro constantemente.

Su desventaja es que no tiene una base matemática tan sólida como el modelo relacional ni un lenguaje de consulta tan universal como SQL. Por eso no reemplazó al relacional: lo que se usa en la práctica son bases objeto-relacionales, que son relacionales con algunas capacidades de objetos agregadas.

Modelos no relacionales (NoSQL)

Agrupan varios modelos que comparten una característica: no usan tablas relacionadas. Surgieron con las aplicaciones web de gran escala, donde la estructura de los datos cambia rápido o el volumen es enorme.

Un punto que conviene aclarar: NoSQL no significa "mejor" ni "más moderno". Significa renunciar a algunas garantías —como la integridad referencial y las transacciones— a cambio de flexibilidad y escala. Para el listado de alumnos de una escuela, un modelo relacional es la elección correcta.

Modelo multidimensional

Está pensado para analizar, no para registrar operaciones. Los datos se organizan como un cubo: cada dimensión es un eje, y en el cruce queda una medida.

Un ejemplo concreto: las dimensiones podrían ser producto, mes y sucursal, y la medida, las ventas. Con esa estructura, responder "cuánto se vendió de este producto en marzo, en la sucursal de La Plata" es inmediato, porque está en el cruce de las tres coordenadas.

Se usa en los sistemas de análisis y reportería, y es la base de los tableros que muestran indicadores por período, por zona o por categoría. En general no reemplaza a la base relacional: se construye a partir de ella, copiando y reorganizando los datos para poder consultarlos mucho más rápido.

Modelo en la nube

Acá conviene hacer una aclaración, porque se lo suele listar junto a los otros y no es lo mismo: la nube no es un modelo de datos, es una forma de alojarlos. Una base en la nube sigue siendo relacional o documental; lo que cambia es dónde está y quién la administra.

Lo que aporta es un cambio en la forma de trabajar: no se instala ni se mantiene nada, el proveedor se ocupa del servidor, de las actualizaciones y de los respaldos, y se paga por el uso. Se accede por Internet desde cualquier lugar.

Su contrapartida también es clara: la información queda en servidores de otra empresa, el costo crece con el uso, y depender de un servicio externo tiene sus riesgos. Para un sitio educativo o un sistema de gestión chico, es una opción cómoda; para datos muy sensibles, hay que pensarlo dos veces.

Cuadro comparativo

Resumen