El Proyecto | Sobre nosotros | Contribuir | Donaciones | Licencia

HOME

Toda organización que funciona durante el tiempo suficiente acaba acumulando datos: clientes, productos, movimientos, incidencias. Al principio esos datos caben en una hoja de cálculo y todo parece ir bien. El problema aparece más tarde, cuando la hoja crece, la usan varias personas a la vez y nadie sabe ya cuál de las tres versiones del fichero es la buena. En esta lección vamos a entender por qué existen las bases de datos: qué problemas concretos resuelven, qué vocabulario se usa para hablar de ellas y qué papel juega el software que las gestiona. No escribiremos todavía ni una línea de SQL; lo que buscamos es que, cuando lleguemos a él, sepas exactamente qué estás resolviendo y por qué.

Para que nada quede en abstracto, todo el curso gira alrededor de un caso único: BiblioRed, la red de bibliotecas municipales de una ciudad ficticia. Lo conocerás en esta misma lección y lo iremos construyendo módulo a módulo hasta tener un sistema de información completo.

Contenido

El escenario: BiblioRed y sus hojas de cálculo
Dato e información: no son lo mismo
Qué es una base de datos
Qué es un SGBD (definición funcional)
Vocabulario esencial: entidad, atributo, tabla, fila, columna, clave
Esquema e instancia
Los seis problemas que resuelve una base de datos
Diagnóstico de la hoja de cálculo de BiblioRed
Errores comunes y consejos
Ejercicios
Conclusión

El escenario: BiblioRed y sus hojas de cálculo

BiblioRed es la red de bibliotecas municipales de una ciudad ficticia. Tiene cuatro sucursales, unos 12.000 socios registrados y un fondo de unos 40.000 ejemplares. Hoy funciona así:

Cada sucursal mantiene su propia hoja de cálculo de préstamos, en una carpeta compartida.
El catálogo de libros está en otra hoja distinta, que mantiene una persona de la sucursal central.
Las altas de socios se apuntan en un tercer fichero, y en algunas sucursales todavía en papel.
Cuando alguien quiere saber si un libro está disponible, llama por teléfono a la otra sucursal.

El sistema "funciona" en el sentido de que la biblioteca abre cada día. Pero produce errores constantes: préstamos duplicados, socios con dos fichas, libros que figuran disponibles y no lo están. La dirección ha decidido migrar a una base de datos de verdad, y nosotros somos el equipo que va a diseñarla.

En esta lección nos limitamos a entender el problema. El diseño empieza en el módulo 4.

Dato e información: no son lo mismo

Es la distinción fundacional de toda la disciplina, y conviene tenerla clara desde el principio.

Un dato es un hecho en bruto, sin contexto: 2026-03-14, 9788420412146, 14.
La información es el resultado de interpretar datos en un contexto: "el 14 de marzo de 2026, la socia número 14 tomó prestado el libro con ISBN 9788420412146".
El conocimiento aparece cuando la información se agrega y permite decidir: "los préstamos de narrativa suben un 20 % en marzo, conviene reforzar el fondo".

Nivel	Qué es	Ejemplo en BiblioRed
Dato	Hecho aislado, sin significado propio	`2026-03-14`
Información	Dato con contexto y relación	Préstamo del socio 14 el 14/03/2026
Conocimiento	Patrón extraído de mucha información	La narrativa se presta más en primavera

Una base de datos almacena datos, pero está diseñada para que sea barato y fiable convertirlos en información. Esa es su razón de ser: no guardar, sino permitir preguntar.

Qué es una base de datos

Una base de datos es una colección de datos relacionados entre sí, organizada según una estructura definida, almacenada de forma persistente y gestionada de manera que varios usuarios y aplicaciones puedan consultarla y modificarla de forma controlada.

Vale la pena desmenuzar la definición, porque cada palabra descarta algo:

Colección de datos relacionados: no es un montón de ficheros sueltos. Los préstamos apuntan a socios, los socios a sucursales, los ejemplares a libros. Las relaciones forman parte de la base de datos tanto como los datos.
Estructura definida: antes de guardar nada se decide qué forma tienen los datos. Esa decisión se llama esquema y la veremos en el apartado 6.
Persistente: sobrevive al cierre del programa, al reinicio del servidor y, si está bien administrada, a un fallo del disco.
Acceso controlado y compartido: varias personas pueden trabajar a la vez sin pisarse, y cada una ve solo lo que le corresponde.

Una hoja de cálculo cumple lo de "persistente" y poco más. Por eso funciona hasta cierto tamaño y luego deja de funcionar.

Qué es un SGBD (definición funcional)

La base de datos son los datos. El SGBD (Sistema Gestor de Bases de Datos, en inglés DBMS) es el software que los gestiona. Es la pieza que se interpone entre las aplicaciones y los ficheros del disco para que nadie tenga que tocar esos ficheros directamente.

Funcionalmente, un SGBD ofrece:

Definición de datos: permite declarar qué estructuras existen (tablas, columnas, tipos, restricciones).
Manipulación de datos: insertar, consultar, modificar y borrar.
Control de acceso: quién puede hacer qué.
Control de concurrencia: coordinar a muchos usuarios simultáneos sin corromper nada.
Recuperación ante fallos: si se va la luz a mitad de una operación, dejar los datos en un estado coherente.
Optimización: decidir cómo ejecutar una consulta de la forma más rápida posible.

flowchart LR
    A["Aplicación web<br/>de BiblioRed"] --> S["SGBD<br/>(PostgreSQL)"]
    B["Terminal del<br/>mostrador"] --> S
    C["Informes de<br/>dirección"] --> S
    S --> D[("Ficheros de datos<br/>en disco")]

Fíjate en la idea clave del diagrama: ninguna aplicación toca el disco. Todas hablan con el SGBD, y el SGBD es el único que sabe cómo están guardados realmente los datos. Eso es lo que permite cambiar el almacenamiento sin romper las aplicaciones.

Ejemplos de SGBD que usaremos en el curso: PostgreSQL (servidor completo, será nuestra referencia), SQLite (motor embebido, para practicar sin instalar nada pesado) y MongoDB (documental, en el módulo 3).

Lo que hay dentro de un SGBD —optimizador, motor de almacenamiento, gestor de buffers, catálogo— y cómo se organiza su arquitectura lo veremos en detalle en la lección 01-04. Aquí nos basta con saber qué hace visto desde fuera.

Vocabulario esencial

Este es el vocabulario mínimo para poder hablar del resto del curso. Lo presentamos con el ejemplo de BiblioRed.

Término	Definición	Ejemplo en BiblioRed
Entidad	Un tipo de "cosa" del mundo real sobre la que guardamos datos	Socio, Libro, Ejemplar, Préstamo, Sucursal
Atributo	Una característica de una entidad	Un Socio tiene nombre, DNI, correo, fecha de alta
Tabla	La estructura donde se almacenan todas las ocurrencias de una entidad	La tabla `socios`
Columna (campo)	La realización de un atributo dentro de una tabla	La columna `correo` de `socios`
Fila (registro)	Una ocurrencia concreta de la entidad	La fila de la socia "Marta Alsina"
Clave primaria	Columna (o conjunto) que identifica cada fila de forma única	`socio_id` en `socios`
Clave ajena	Columna que apunta a la clave primaria de otra tabla	`socio_id` dentro de `prestamos`

Visualmente, la tabla socios de BiblioRed podría tener este aspecto:

socios
+-----------+------------------+------------------------+-------------+
| socio_id  | nombre           | correo                 | sucursal_id |  <- columnas
+-----------+------------------+------------------------+-------------+
| 14        | Marta Alsina     | [email protected]   | 2           |  <- fila
| 15        | Iván Pereda      | [email protected]   | 1           |
| 16        | Nuria Bastos     | [email protected]   | 2           |
+-----------+------------------+------------------------+-------------+
     ^
  clave primaria

Dos precisiones que suelen confundir a quien empieza:

Entidad es un concepto de diseño; tabla es su materialización. Se diseña pensando en entidades y se implementa en tablas. Cuando lleguemos a los diagramas entidad-relación (lección 04-02) esta distinción será central.
Fila y registro se usan casi como sinónimos, igual que columna y campo. "Fila" y "columna" son los términos del modelo relacional; "registro" y "campo" vienen del mundo de los ficheros. Verás ambos en la literatura.

Una clave es simplemente un atributo (o combinación) que sirve para identificar. Es un concepto tan importante que le dedicaremos parte del módulo 2: sin claves no hay forma de relacionar tablas, y sin relaciones no hay modelo relacional.

Esquema e instancia

Otra distinción que hay que interiorizar pronto:

El esquema es la definición de la estructura: qué tablas existen, qué columnas tiene cada una, de qué tipo son, qué restricciones cumplen. Cambia poco, y cuando cambia es un evento (una "migración").
La instancia (o estado) es el contenido en un momento dado: las filas concretas que hay ahora mismo. Cambia constantemente, cada vez que alguien presta un libro.

La analogía habitual: el esquema es como la definición de un formulario en blanco; la instancia son todos los formularios rellenados que hay hoy en el archivador.

	Esquema	Instancia
Qué describe	La estructura	Los datos
Frecuencia de cambio	Baja (migraciones planificadas)	Alta (cada operación)
Ejemplo BiblioRed	"`prestamos` tiene fecha_prestamo de tipo fecha"	"Hay 3.412 préstamos activos ahora"
Quién lo cambia	Diseñador / administrador	Usuarios y aplicaciones

Esta separación es lo que hace posible razonar sobre una base de datos sin mirar sus datos: si conoces el esquema, sabes qué preguntas se pueden responder. En el módulo 4 aprenderás a diseñar esquemas y en el módulo 5 a mejorarlos mediante normalización.

Los seis problemas que resuelve una base de datos

Aquí está el núcleo de la lección. Una base de datos no es "una hoja de cálculo más grande": resuelve seis problemas que una hoja no puede resolver.

7.1 Redundancia

El problema: el mismo dato guardado en varios sitios. En BiblioRed, el nombre del socio aparece en cada fila de préstamo, en la hoja de altas y en la lista de morosos.

Qué provoca: ocupa espacio (lo de menos) y, sobre todo, obliga a actualizar en N sitios. Si el socio cambia de correo, hay que acordarse de todos.

Cómo se resuelve: guardando cada dato una sola vez en su tabla y referenciándolo desde donde haga falta. Es el principio que formaliza la normalización (módulo 5).

7.2 Inconsistencia

El problema: consecuencia directa de la anterior. Si el dato está en cinco sitios y solo actualizas cuatro, ahora tienes dos verdades contradictorias y ninguna forma de saber cuál vale.

Cómo se resuelve: eliminando la redundancia y añadiendo restricciones de integridad que el SGBD hace cumplir siempre, sin depender de la disciplina de nadie.

7.3 Falta de integridad

El problema: nada impide escribir barbaridades. Una fecha de devolución anterior a la de préstamo. Un préstamo asociado a un socio que no existe. Un DNI repetido.

Cómo se resuelve: el SGBD permite declarar reglas —tipos de datos, NOT NULL, unicidad, claves ajenas, comprobaciones— y rechaza cualquier operación que las viole. La diferencia con una hoja de cálculo es que la regla vive en los datos, no en la buena voluntad del que teclea. Lo veremos en la lección 02-06 y en la 04-04.

7.4 Falta de control de concurrencia

El problema: dos bibliotecarios abren la hoja a la vez, cada uno anota su préstamo y el segundo en guardar sobrevive; el primer préstamo desaparece. O peor: el último ejemplar de un libro se presta dos veces porque ambos leyeron "disponible: 1".

Cómo se resuelve: el SGBD gestiona transacciones y bloqueos, de modo que las operaciones simultáneas producen el mismo resultado que si se hubieran hecho una detrás de otra. Es el tema del módulo 6 (lecciones 06-01 y 06-02).

7.5 Falta de seguridad

El problema: quien tiene acceso al fichero lo ve todo. El becario que registra préstamos ve también los datos personales de 12.000 socios y podría borrarlos por accidente.

Cómo se resuelve: usuarios, roles y permisos por tabla y por operación. El mostrador puede insertar préstamos pero no borrar socios; dirección puede leer estadísticas pero no modificar el catálogo. Se trata en la lección 06-04.

7.6 Falta de independencia de datos y persistencia fiable

El problema: en la hoja de cálculo, la forma de guardar y la forma de usar son la misma cosa. Si reorganizas las columnas, se rompen todas las fórmulas y todos los informes. Y si el fichero se corrompe, la única copia es la que alguien recordó hacer.

Cómo se resuelve: el SGBD separa cómo se guardan los datos de cómo se consultan. Puedes añadir un índice, cambiar el almacenamiento o mover la tabla de disco sin tocar una sola consulta. A eso se le llama independencia de datos y lo formalizaremos en la lección 01-04. La persistencia fiable, por su parte, se apoya en registros de transacciones y copias de seguridad.

Diagnóstico de la hoja de cálculo de BiblioRed

Veamos el problema con datos reales (ficticios). Esta es una parte de la hoja prestamos_sucursal_norte.xlsx tal como está hoy:

Socio	Email socio	Teléfono	Libro	Autor	ISBN	Sucursal	Fecha préstamo	Devolución
Marta Alsina	[email protected]	600 111 222	El mapa del tiempo	Félix Palma	9788401339097	Norte	02/03/2026	16/03/2026
M. Alsina	[email protected]	600111222	El mapa del tiempo	F. Palma	9788401339097	norte	05/04/2026
Iván Pereda	[email protected]	600 333 444	Los pilares de la Tierra	Ken Follet	9788401337208	Norte	07/04/2026	01/04/2026
Marta Alsina	[email protected]	600 111 222	El mapa del tiempo	Félix J. Palma	978840133909	Norte	09/04/2026
Nuria Bastos	[email protected]	600 555 666	Los pilares de la Tierra	Ken Follett	9788401337208	Sur	10/04/2026

Un examen atento revela al menos ocho defectos, y todos son instancias de los problemas del apartado anterior:

Redundancia de socio: el correo y el teléfono de Marta Alsina están escritos tres veces. Si cambia de teléfono, hay que corregir tres filas (y las de las otras tres sucursales).
Redundancia de libro: el título, el autor y el ISBN de "El mapa del tiempo" se repiten en cada préstamo. Con 40.000 ejemplares y años de historial, esto multiplica el fichero.
Inconsistencia en el nombre del socio: "Marta Alsina" y "M. Alsina" son la misma persona, pero ningún programa lo sabe. Contar socios distintos da un número equivocado.
Inconsistencia en el autor: "Ken Follet" y "Ken Follett", "Félix Palma" y "Félix J. Palma". Buscar por autor devuelve resultados incompletos.
Dato erróneo sin detectar: [email protected] (una letra cambiada) y el ISBN 978840133909 (le falta un dígito). Nada validó esos campos al escribirlos.
Violación de una regla de negocio: el préstamo de Iván Pereda tiene fecha de devolución (01/04) anterior a la de préstamo (07/04). Es imposible, y ahí está.
Formato incoherente: "Norte" y "norte"; teléfonos con y sin espacios. Cualquier agrupación por sucursal tratará "Norte" y "norte" como valores distintos.
Fragmentación: la fila de Nuria Bastos dice "Sur", pero esta es la hoja de la sucursal Norte. La misma información vive en dos ficheros y nadie sabe cuál manda.

A esto hay que añadir dos problemas que la tabla no muestra pero que ocurren cada día:

Concurrencia: si dos personas del mostrador abren la hoja a la vez, uno de los dos préstamos se perderá al guardar.
Sin control de acceso: cualquiera con acceso a la carpeta compartida ve teléfonos y correos de todos los socios.

Hacia dónde vamos (sin diseñarlo todavía)

La solución consistirá en dejar de tener una tabla que lo mezcla todo y pasar a tener varias tablas, cada una con una responsabilidad, unidas por claves:

flowchart TD
    S["socios<br/>(datos de la persona, una vez)"] --> P["prestamos<br/>(quién, qué ejemplar, cuándo)"]
    E["ejemplares<br/>(copias físicas)"] --> P
    L["libros<br/>(título, ISBN, una vez)"] --> E
    SU["sucursales"] --> E

Con esa estructura, el correo de Marta Alsina se escribe una sola vez; el ISBN de "El mapa del tiempo", una sola vez; el SGBD impide registrar un préstamo de un socio inexistente, y una restricción impide que la fecha de devolución sea anterior a la de préstamo.

Cómo se llega a ese diseño, cómo se justifica y cómo se escribe en SQL es exactamente el recorrido de los módulos 2, 4 y 5. Por ahora quédate con el diagnóstico: todos los males de la hoja de cálculo tienen nombre propio y solución conocida.

Errores Comunes y Consejos

Confundir "base de datos" con "SGBD". Se dice "trabajo con PostgreSQL" cuando PostgreSQL es el gestor, no la base de datos. Es una imprecisión inofensiva en conversación, pero conviene tenerlo claro: un mismo SGBD aloja muchas bases de datos.
Creer que una base de datos es solo un almacén más rápido. Su valor principal no es la velocidad, sino la garantía: integridad, concurrencia y recuperación. Una hoja de cálculo pequeña puede ser más rápida de abrir; lo que no puede es garantizar nada.
Pensar que la redundancia es un problema de espacio. El espacio es barato. El problema de la redundancia es que hace inevitable la inconsistencia: en cuanto un dato está en dos sitios, tarde o temprano diferirán.
Diseñar la base de datos copiando la hoja de cálculo tal cual. Es la tentación número uno al migrar. Una tabla ancha con 30 columnas que lo mezcla todo reproduce en la base de datos exactamente los mismos problemas. Migrar implica rediseñar.
Empezar a escribir tablas antes de entender el dominio. Antes de crear nada hay que saber qué entidades existen y cómo se relacionan. Dedicar una hora a hablar con los bibliotecarios ahorra semanas de correcciones.
Consejo práctico: cuando analices un sistema existente, haz siempre el ejercicio del apartado 8. Coge una muestra real de datos y busca duplicados, valores contradictorios y reglas violadas. Ese inventario es la mejor justificación posible del proyecto ante quien lo paga.

Ejercicios

Ejercicio 1: Clasificar dato, información y conocimiento

Para cada elemento, indica si es un dato, información o conocimiento, y justifica brevemente:

9788401337208
"El ejemplar 3 de Los pilares de la Tierra está prestado hasta el 24/04/2026."
"La sucursal Norte concentra el 45 % de los préstamos de la red."
Marta Alsina
"Los socios menores de 25 años piden más cómic que el resto."

Ejercicio 2: Identificar entidades y atributos

A partir de la descripción de BiblioRed y de la hoja de cálculo del apartado 8, enumera al menos cuatro entidades que deberían existir en la base de datos, con tres atributos cada una. No diseñes tablas ni claves ajenas todavía: solo identifica las "cosas" del dominio y sus características.

Ejercicio 3: Diagnóstico de una hoja de cálculo

Esta es otra hoja de BiblioRed, reservas.xlsx:

Socio	Libro	Sucursal recogida	Fecha reserva	Estado	Responsable
Iván Pereda	Los pilares de la Tierra	Centro	12/04/2026	pendiente	Ana G.
ivan pereda	Los Pilares de la Tierra	centro	12/04/2026	Pendiente	Ana
Nuria Bastos	El mapa del tiempo	Norte	13/04/2026	recogida	ana g.
Nuria Bastos	El mapa del tiempo	Norte	32/04/2026	Pendiente	Luis M.

Enumera todos los problemas que detectes, indicando en cada caso a cuál de los seis problemas del apartado 7 corresponde.

Soluciones

Solución 1

Dato. Un número aislado; sin contexto no sabemos ni que es un ISBN.
Información. Datos (ejemplar, título, fecha) puestos en relación y con significado.
Conocimiento. Es un patrón agregado sobre muchos préstamos, útil para decidir (por ejemplo, reforzar personal en Norte).
Dato. Una cadena de texto; por sí sola no dice si es un socio, un autor o una empleada.
Conocimiento. Patrón extraído del cruce de dos dimensiones (edad y categoría), directamente accionable para la política de compras.

Solución 2

Una respuesta razonable (hay variantes válidas):

Entidad	Atributos
Socio	nombre completo, correo electrónico, teléfono
Libro (la obra)	título, ISBN, año de publicación
Ejemplar (la copia física)	código de ejemplar, estado de conservación, fecha de adquisición
Préstamo	fecha de préstamo, fecha de devolución prevista, fecha de devolución real
Sucursal	nombre, dirección, horario
Autor	nombre, apellidos, nacionalidad

El punto clave del ejercicio es distinguir Libro de Ejemplar. "Los pilares de la Tierra" es una obra, pero BiblioRed tiene seis copias físicas repartidas entre sucursales. Lo que se presta es un ejemplar, no un libro. Confundir ambos es uno de los errores de modelado más frecuentes en sistemas de bibliotecas, y ya se intuye en la hoja de cálculo: no hay forma de saber qué copia se llevó Marta.

Solución 3

#	Problema detectado	Categoría del apartado 7
1	Las filas 1 y 2 son la misma reserva duplicada, escrita con distinta capitalización	Redundancia + inconsistencia
2	"Iván Pereda" / "ivan pereda" y "Centro" / "centro": mismo valor, escritura distinta	Inconsistencia (formato)
3	"pendiente" / "Pendiente" / "recogida": el estado no está limitado a un conjunto cerrado de valores	Falta de integridad
4	"Ana G." / "Ana" / "ana g.": el responsable se escribe libre, no se referencia a una tabla de empleados	Redundancia + inconsistencia
5	Fecha `32/04/2026`: no existe	Falta de integridad (tipo de dato)
6	Filas 3 y 4: la misma reserva aparece a la vez como "recogida" y como "pendiente"	Inconsistencia (dos verdades contradictorias)
7	El libro se identifica por título en texto libre, sin ISBN ni referencia al catálogo	Redundancia + falta de integridad
8	Cualquiera con acceso al fichero puede editar o borrar cualquier fila sin traza	Falta de seguridad
9	Dos empleados editando a la vez perderían una de las reservas	Falta de control de concurrencia

Observa que el problema 6 es especialmente grave: no es un error de formato, es que el sistema no tiene ni idea de cuál es el estado real de la reserva. Ese es el momento en que una organización descubre que necesita una base de datos.

Conclusión

En esta lección hemos establecido los cimientos conceptuales del curso:

Distinguimos dato, información y conocimiento: la base de datos guarda lo primero para que sea barato obtener lo segundo y lo tercero.
Definimos base de datos (colección estructurada, persistente y compartida de datos relacionados) y SGBD (el software que la gestiona, garantizando definición, manipulación, seguridad, concurrencia y recuperación).
Fijamos el vocabulario que usaremos todo el curso: entidad, atributo, tabla, fila, columna, clave primaria y clave ajena, y separamos esquema (la estructura) de instancia (los datos de ahora mismo).
Identificamos los seis problemas que resuelve una base de datos: redundancia, inconsistencia, falta de integridad, falta de control de concurrencia, falta de seguridad y falta de independencia de datos.
Aplicamos todo eso a BiblioRed, diagnosticando una hoja de cálculo real y anticipando —sin diseñarla aún— la estructura de varias tablas relacionadas que la sustituirá.

Ya sabemos qué es una base de datos y por qué la necesitamos. La siguiente pregunta natural es: ¿todas las bases de datos son iguales? La respuesta es que no, ni de lejos. En la lección 01-02, Tipos de Bases de Datos, recorreremos las grandes familias —relacionales, documentales, clave-valor, columnares, de grafos, y varias más— para entender qué estructura de datos propone cada una, para qué problema nació y cómo se decide cuál conviene. Y volveremos a BiblioRed para preguntarnos qué partes de su sistema piden una base de datos relacional y cuáles quizá pidan otra cosa.

Conceptos Básicos de Bases de Datos