El Proyecto | Sobre nosotros | Contribuir | Donaciones | Licencia

HOME

En la primera lección definimos el SGBD desde fuera: el software que se interpone entre las aplicaciones y los ficheros del disco. Ha llegado el momento de abrir la caja. Entender qué hay dentro de un gestor de bases de datos no es un lujo teórico: es lo que te permitirá, más adelante, comprender por qué una consulta tarda diez milisegundos y otra casi idéntica tarda treinta segundos, por qué existen los índices, qué garantiza realmente una transacción y qué está pasando cuando algo se bloquea.

La lección tiene dos partes. La primera es conceptual: los componentes internos de un SGBD, el viaje completo de una consulta, la arquitectura de tres niveles que hace posible la independencia de datos, la diferencia entre cliente-servidor y embebido, y los roles humanos que trabajan alrededor de una base de datos. La segunda es práctica: al terminarla tendrás PostgreSQL y SQLite instalados, sabrás conectarte a ambos y habrás creado la base de datos biblioredb, donde se ejecutará todo el SQL del resto del curso. No dejes esta lección a medias: el módulo 2 empieza escribiendo SQL, y necesitarás el entorno listo.

Contenido

Los componentes internos de un SGBD
El viaje de una consulta, paso a paso
La arquitectura ANSI/SPARC de tres niveles
Independencia de datos lógica y física
Cliente-servidor frente a base de datos embebida
Roles humanos alrededor de una base de datos
Instalación de PostgreSQL
Primeros pasos con psql y creación de biblioredb
Instalación y primeros pasos con SQLite
Alternativas: Docker y consolas en línea
Errores comunes y consejos
Ejercicios
Conclusión

Los componentes internos de un SGBD

Un SGBD moderno es un sistema complejo, pero se organiza en un conjunto de componentes bastante estable, comunes a PostgreSQL, MySQL, Oracle o SQL Server (SQLite los tiene todos también, aunque en versión reducida).

Gestor de conexiones y control de acceso

Es la puerta de entrada. Recibe la conexión del cliente, autentica al usuario (contraseña, certificado, sistema operativo) y le asigna una sesión. A partir de ahí, cada operación pasa por el control de autorización: comprobar que ese usuario tiene permiso sobre esa tabla y esa operación.

En BiblioRed, este componente es el que hará que el usuario del mostrador pueda insertar préstamos pero no borrar socios. Los permisos en detalle se ven en la lección 06-04.

Procesador y optimizador de consultas

El cerebro del sistema. Recibe una consulta en SQL —un texto que dice qué se quiere— y produce un plan de ejecución que dice cómo obtenerlo. Sus fases:

Análisis sintáctico (parser): comprueba que el SQL está bien escrito y lo convierte en un árbol.
Análisis semántico: verifica contra el catálogo que las tablas y columnas existen y que los tipos encajan.
Reescritura: aplica transformaciones equivalentes (expandir vistas, simplificar condiciones).
Optimización: genera varios planes posibles, estima el coste de cada uno usando estadísticas sobre los datos y elige el más barato.
Ejecución: recorre el plan elegido y produce las filas.

Esta pieza es la herencia directa de System R (lección 01-03) y es la que hace que SQL pueda ser declarativo.

Motor de almacenamiento

Es quien sabe cómo están realmente los datos en el disco: en qué ficheros, organizados en páginas o bloques (habitualmente de 4 u 8 KB), con qué formato de fila, y qué índices existen para llegar antes a una fila concreta. Ofrece al resto del sistema operaciones elementales: "dame la fila X", "recorre esta tabla", "busca en este índice".

Gestor de buffers (caché)

Leer de disco es órdenes de magnitud más lento que leer de memoria. El gestor de buffers mantiene en RAM las páginas más usadas y decide cuáles expulsar cuando falta espacio. Es responsable de que la segunda vez que consultas algo sea mucho más rápida que la primera.

En PostgreSQL este espacio se llama shared buffers; en la práctica, un servidor bien dimensionado sirve la inmensa mayoría de las lecturas desde memoria.

Gestor de transacciones y recuperación

Garantiza que un conjunto de operaciones se aplique entero o nada, incluso si se corta la luz a mitad. Se apoya en dos mecanismos:

El registro de escritura anticipada (write-ahead log, WAL): antes de modificar los datos, se escribe en un registro secuencial lo que se va a hacer. Si el sistema cae, al arrancar se relee ese registro y se reconstruye el estado coherente.
El control de concurrencia: bloqueos o versionado (PostgreSQL usa MVCC, Multi-Version Concurrency Control) para que muchas sesiones simultáneas no se corrompan entre sí.

Es lo que impide que dos mostradores de BiblioRed presten el mismo ejemplar a la vez. Las transacciones y los niveles de aislamiento son el contenido de las lecciones 06-01 y 06-02.

Catálogo o diccionario de datos

La base de datos sobre la propia base de datos: qué tablas existen, con qué columnas, tipos, restricciones, índices, vistas, usuarios y permisos. Y también estadísticas sobre los datos (cuántas filas tiene cada tabla, cómo se distribuyen los valores), que el optimizador usa para decidir.

Lo interesante es que en un sistema relacional el catálogo son tablas normales, consultables con SQL como cualquier otra. En PostgreSQL vive en el esquema information_schema y en las tablas pg_catalog.

Utilidades

Alrededor del núcleo hay herramientas de carga masiva, copia de seguridad y restauración, replicación y monitorización. Suelen ser programas independientes (pg_dump, pg_restore, psql).

El viaje de una consulta, paso a paso

Veamos el recorrido completo con una consulta concreta de BiblioRed. Todavía no hace falta entender la sintaxis —eso es el módulo 2—; lo que importa es el camino.

SELECT s.nombre, l.titulo, p.fecha_prestamo
FROM prestamos p
JOIN socios s ON s.socio_id = p.socio_id
JOIN ejemplares e ON e.ejemplar_id = p.ejemplar_id
JOIN libros l ON l.libro_id = e.libro_id
WHERE p.fecha_devolucion IS NULL
  AND e.sucursal_id = 2;

En lenguaje llano: "dime qué préstamos siguen abiertos en la sucursal Norte, con el nombre del socio y el título del libro".

flowchart TD
    A["Cliente<br/>(psql o aplicación)"] --> B["Gestor de conexiones<br/>autentica la sesión"]
    B --> C["Parser<br/>valida sintaxis, construye árbol"]
    C --> D["Analizador semántico<br/>consulta el catálogo:<br/>¿existen tablas y columnas?"]
    D --> E["Reescritor<br/>expande vistas, simplifica"]
    E --> F["Optimizador<br/>genera planes y estima costes"]
    F --> G["Ejecutor<br/>recorre el plan elegido"]
    G --> H["Gestor de buffers<br/>¿está la página en RAM?"]
    H -->|Sí| J["Motor de almacenamiento<br/>devuelve las filas"]
    H -->|No| I[("Disco<br/>lee la página")]
    I --> J
    J --> K["Control de acceso<br/>filtra según permisos"]
    K --> A
    D -.->|consulta| CAT[("Catálogo<br/>pg_catalog")]
    F -.->|estadísticas| CAT
    G -.->|visibilidad de filas| T["Gestor de transacciones<br/>MVCC"]

Recorramos las decisiones interesantes:

Conexión y autenticación. El cliente abre una sesión. En PostgreSQL, el proceso principal lanza un proceso dedicado para atenderla.
Parser. Si escribiste SELCT en lugar de SELECT, aquí se detiene con un error de sintaxis. Aún no se ha mirado ningún dato.
Análisis semántico. Se consulta el catálogo: ¿existe la tabla prestamos? ¿tiene columna fecha_devolucion? ¿e.sucursal_id es comparable con el número 2? Los errores de "columna inexistente" nacen aquí.
Reescritura. Si prestamos fuera una vista, se sustituiría por su definición.
Optimización. Aquí está lo sustancioso. El sistema debe decidir, entre muchas opciones:
- ¿En qué orden unir las cuatro tablas? Unir primero prestamos con ejemplares filtrando por sucursal puede dejar 300 filas; empezar por libros dejaría 40.000. El orden cambia el tiempo de ejecución en órdenes de magnitud.
- ¿Recorrer la tabla entera (sequential scan) o usar un índice? Si solo hay 300 préstamos abiertos entre un millón de filas históricas, un índice gana; si hay que leer el 80 % de la tabla, recorrerla entera es más rápido.
- ¿Qué algoritmo de unión? Bucle anidado, unión por mezcla o unión por dispersión (hash join), según los tamaños.
Estas decisiones se toman con las estadísticas del catálogo. Por eso una base de datos con estadísticas desactualizadas elige mal. En la lección 06-03 aprenderás a leer el plan elegido con EXPLAIN.
Ejecución. El ejecutor recorre el plan pidiendo páginas. Cada petición pasa por el gestor de buffers: si la página está en memoria, se sirve al instante; si no, se lee de disco y se cachea.
Visibilidad transaccional. Cada fila candidata se comprueba contra el gestor de transacciones: bajo MVCC, una fila modificada por una transacción aún no confirmada no es visible para esta sesión. Así se lee sin bloquear a quien escribe.
Permisos y resultado. Se verifica que el usuario puede leer esas tablas y las filas viajan de vuelta al cliente.

La idea que debe quedarte: tú escribes el qué; el SGBD decide el cómo, y esa decisión es donde se juega el rendimiento. Es exactamente la independencia que propuso Codd, funcionando.

La arquitectura ANSI/SPARC de tres niveles

En 1975, el comité ANSI/X3/SPARC propuso un marco para organizar cualquier SGBD en tres niveles de abstracción. Sigue siendo la referencia conceptual con la que se explican las bases de datos, porque describe por qué se puede cambiar una capa sin romper las demás.

flowchart TD
    subgraph EXT["Nivel externo (vistas)"]
        V1["Vista mostrador<br/>préstamos y socios<br/>de mi sucursal"]
        V2["Vista catálogo público<br/>título, autor,<br/>disponibilidad"]
        V3["Vista dirección<br/>estadísticas agregadas,<br/>sin datos personales"]
    end
    subgraph CON["Nivel conceptual (esquema lógico)"]
        C["Todas las tablas de BiblioRed:<br/>socios, libros, ejemplares,<br/>prestamos, reservas, sucursales,<br/>con sus relaciones y restricciones"]
    end
    subgraph INT["Nivel interno (esquema físico)"]
        I["Ficheros, páginas, formato de fila,<br/>índices B-tree, compresión,<br/>ubicación en disco"]
    end
    V1 --> C
    V2 --> C
    V3 --> C
    C --> I
    I --> D[("Disco")]

Nivel externo (o de vistas)

Lo que cada tipo de usuario ve. No hay uno solo: hay tantos como perfiles de uso. Cada vista externa muestra un subconjunto de los datos, quizá reorganizado o calculado, y oculta el resto.

En BiblioRed:

El mostrador ve los préstamos y los socios de su sucursal, con los datos de contacto necesarios para reclamar una devolución.
El catálogo público de la web ve título, autor, portada y disponibilidad. No ve quién tiene prestado cada ejemplar: sería una brecha de privacidad.
La dirección ve totales agregados por sucursal y mes, sin nombres de socios.

Los tres perfiles están mirando los mismos datos, presentados de forma distinta.

Nivel conceptual (o lógico)

La descripción completa y única de qué datos contiene la base de datos: todas las entidades, todos los atributos, todas las relaciones y todas las restricciones de integridad. Es independiente de quién los use y de cómo se guarden.

Es el nivel donde trabaja el diseñador, y el que produciremos en el módulo 4 con los diagramas entidad-relación y su transformación a esquema relacional.

Nivel interno (o físico)

Cómo se almacena realmente: qué ficheros hay, cómo se agrupan las filas en páginas, qué índices existen y de qué tipo, qué se comprime, en qué disco vive cada tabla.

Es responsabilidad del administrador y del propio SGBD, y el usuario normal no debería necesitar conocerlo para escribir consultas correctas (sí para escribirlas rápidas, y de ahí la lección 06-03).

Nivel	Responde a	Quién lo maneja	Ejemplo en BiblioRed
Externo	¿Qué ve cada usuario?	Desarrollador de aplicaciones	Vista `catalogo_publico` sin datos personales
Conceptual	¿Qué datos hay y cómo se relacionan?	Diseñador / administrador	Tablas `socios`, `libros`, `ejemplares`, `prestamos`
Interno	¿Cómo se guarda físicamente?	SGBD y administrador	Índice B-tree sobre `prestamos.socio_id`, páginas de 8 KB

Independencia de datos lógica y física

El motivo de existir de los tres niveles son las dos independencias. Son la propiedad más valiosa de un SGBD, y la que faltaba por completo en los modelos anteriores al relacional.

Independencia física

Se puede cambiar el nivel interno sin tocar el nivel conceptual ni las aplicaciones.

Ejemplos en BiblioRed:

El administrador crea un índice sobre prestamos.fecha_prestamo porque los informes mensuales van lentos. Ninguna consulta cambia; simplemente pasan a ejecutarse más rápido.
Se mueve la tabla histórica de préstamos a un disco distinto, o se comprime. Las aplicaciones no se enteran.
Se migra el servidor a otro almacenamiento. El SQL sigue siendo el mismo.

Esta independencia es muy sólida en los SGBD actuales: es prácticamente total.

Independencia lógica

Se puede cambiar el nivel conceptual sin tocar las vistas externas ni las aplicaciones que las usan.

Ejemplos en BiblioRed:

Se decide dividir la tabla socios en socios y socios_contacto para separar los datos personales. Si las aplicaciones consultan una vista llamada socios que reúne ambas tablas, siguen funcionando sin cambios.
Se añade una columna idioma_preferido a socios. Ninguna aplicación existente se ve afectada, porque ninguna la pedía.
Se añade la entidad reservas, nueva en el sistema. Las aplicaciones de préstamos ni se enteran.

Esta independencia es más difícil de lograr que la física, y solo se consigue si se ha tenido la disciplina de que las aplicaciones accedan a través de vistas en lugar de directamente a las tablas. Es una decisión de diseño, no un regalo del sistema.

	Independencia física	Independencia lógica
Qué cambia	Cómo se almacena	Qué estructura lógica hay
Qué queda intacto	Esquema conceptual y aplicaciones	Vistas externas y aplicaciones
Ejemplo	Añadir un índice, comprimir, cambiar de disco	Dividir una tabla, añadir una columna
Dificultad real	Baja: casi total	Media: requiere usar vistas

Cliente-servidor frente a base de datos embebida

Los dos gestores del curso representan los dos extremos de la arquitectura de despliegue, y compararlos aclara mucho.

Arquitectura cliente-servidor: PostgreSQL

El SGBD es un proceso independiente —a menudo en otra máquina— que escucha en un puerto de red (5432 en PostgreSQL). Los clientes se conectan por red, envían SQL y reciben resultados.

flowchart LR
    A["App web<br/>BiblioRed"] -->|"TCP :5432"| S["Proceso servidor<br/>PostgreSQL"]
    B["psql del<br/>administrador"] -->|"TCP :5432"| S
    C["Terminal del<br/>mostrador Norte"] -->|"TCP :5432"| S
    S --> D[("Ficheros de datos")]

Implica:

Acceso concurrente real desde muchas máquinas, gestionado por el servidor.
Control de acceso centralizado: usuarios, roles y permisos.
Administración: hay que instalarlo, arrancarlo, configurarlo, actualizarlo y respaldarlo (o pagar a alguien que lo haga, como vimos con los servicios gestionados en la lección 01-03).
Latencia de red en cada operación, normalmente despreciable pero no nula.

Arquitectura embebida: SQLite

No hay servidor. El motor es una biblioteca enlazada dentro del propio programa, y la base de datos entera es un fichero en el disco local. Cuando tu aplicación consulta, no habla por red: llama a una función.

flowchart LR
    subgraph P["Un solo proceso"]
        A["Aplicación"] --> L["Biblioteca SQLite"]
    end
    L --> F[("biblioredb.sqlite<br/>un fichero")]

Implica:

Cero administración: no hay servicio, ni puerto, ni usuarios. Copiar la base de datos es copiar un fichero.
Latencia mínima: no hay red ni serialización entre procesos.
Concurrencia limitada: muchos lectores simultáneos sí, pero un solo escritor a la vez sobre el fichero.
Sin control de acceso propio: la seguridad es la del sistema de ficheros. Quien puede leer el fichero, lo lee todo.

Comparación

	PostgreSQL (cliente-servidor)	SQLite (embebida)
Proceso	Servidor independiente	Biblioteca dentro de la app
Acceso	Por red (puerto 5432)	Llamada a función, fichero local
Concurrencia de escritura	Alta, muchas sesiones	Un escritor a la vez
Usuarios y permisos	Sí, completos	No (permisos del sistema de ficheros)
Administración	Necesaria	Prácticamente nula
Copia de seguridad	`pg_dump`, WAL, réplicas	Copiar el fichero
Uso típico	Servidor de aplicación, sistema multiusuario	Apps de escritorio y móviles, pruebas, aprendizaje
En BiblioRed	El sistema real en producción	Practicar y prototipar

Ninguna es mejor que la otra: resuelven problemas distintos. SQLite es, con diferencia, el motor de base de datos más desplegado del mundo (está en cada teléfono, cada navegador y cada avión), y no compite con PostgreSQL: compite con fopen().

Para BiblioRed en producción la elección es PostgreSQL, porque hay cuatro sucursales escribiendo a la vez y datos personales que proteger. Para aprender, SQLite es perfecto y por eso lo tendremos como alternativa en todo el curso.

Roles humanos alrededor de una base de datos

En una organización pequeña una sola persona hace los tres papeles; en una grande son equipos distintos. Conviene saber qué se espera de cada uno.

Administrador de bases de datos (DBA)

Responsable de que el sistema funcione, sea seguro y no pierda datos:

Instalar, configurar y actualizar el SGBD.
Definir usuarios, roles y permisos.
Planificar y probar las copias de seguridad y la restauración (una copia no verificada no es una copia).
Monitorizar rendimiento, ajustar configuración y crear índices.
Planificar capacidad, replicación y recuperación ante desastres.

En BiblioRed sería quien garantiza que el servidor de la sucursal central esté respaldado cada noche y que el personal solo vea lo que le corresponde.

Desarrollador de bases de datos / de aplicaciones

Responsable de que el esquema y las consultas sean correctos y eficientes:

Diseñar tablas, relaciones y restricciones (módulos 4 y 5).
Escribir y optimizar consultas SQL.
Gestionar las migraciones de esquema con control de versiones.
Integrar la base de datos con la aplicación.

Es el rol para el que este curso prepara de forma más directa.

Analista de datos

Responsable de extraer información de los datos existentes:

Escribir consultas de análisis y agregación (lección 02-05).
Construir informes y cuadros de mando.
Detectar problemas de calidad de datos.

En BiblioRed, quien responde a "¿qué géneros conviene reforzar en la sucursal Sur?".

Rol	Pregunta que responde	Herramientas típicas
DBA	¿Está disponible, seguro y respaldado?	`psql`, configuración, monitorización, `pg_dump`
Desarrollador	¿El modelo es correcto y las consultas eficientes?	SQL, migraciones, ORM, `EXPLAIN`
Analista	¿Qué nos dicen los datos?	SQL analítico, herramientas de visualización

Un cuarto rol, el arquitecto de datos, decide en sistemas grandes qué tecnologías se usan y cómo se integran; es quien tomaría las decisiones de la lección 01-02.

Instalación de PostgreSQL

A partir de aquí, manos a la obra. Escoge tu sistema operativo.

Linux (Debian / Ubuntu)

# Actualizar el índice de paquetes e instalar servidor y cliente
sudo apt update
sudo apt install -y postgresql postgresql-contrib

# Comprobar que el servicio está activo
sudo systemctl status postgresql

postgresql instala el servidor; postgresql-contrib añade extensiones útiles. En Debian y Ubuntu el servicio arranca solo tras la instalación.

Linux (Fedora / RHEL)

sudo dnf install -y postgresql-server postgresql-contrib

# En Fedora hay que inicializar el directorio de datos a mano
sudo postgresql-setup --initdb

sudo systemctl enable --now postgresql

macOS

# Con Homebrew (recomendado)
brew install postgresql@16
brew services start postgresql@16

La alternativa gráfica es Postgres.app, que se descarga, se arrastra a Aplicaciones y arranca con un clic. Es la opción más cómoda si prefieres no usar Homebrew.

Windows

Descarga el instalador de EDB desde postgresql.org/download/windows.
Ejecútalo y acepta las opciones por defecto, anotando la contraseña que definas para el usuario postgres: la necesitarás para conectarte.
Deja marcado pgAdmin si quieres una interfaz gráfica, y Command Line Tools (imprescindible, incluye psql).

Después, desde el menú de inicio, abre SQL Shell (psql) y pulsa Enter en cada pregunta hasta la contraseña.

Comprobar la versión

En cualquier sistema, verifica que el cliente responde:

psql --version

psql (PostgreSQL) 16.2

Si el comando no se encuentra en macOS con Homebrew, añade el directorio al PATH:

echo 'export PATH="/opt/homebrew/opt/postgresql@16/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc

Primeros pasos con `psql` y creación de `biblioredb`

psql es el cliente de línea de comandos de PostgreSQL. Es la herramienta que usaremos en todo el curso: es la más directa y la que está disponible en cualquier servidor.

Conectarse

En Linux, la instalación crea un usuario del sistema llamado postgres que es el superusuario de la base de datos:

# Abrir psql como el usuario postgres
sudo -u postgres psql

En macOS con Homebrew, tu propio usuario suele ser superusuario:

psql postgres

En Windows, usa el acceso directo SQL Shell (psql).

Verás un aviso como este:

psql (16.2)
Type "help" for help.

postgres=#

El prompt postgres=# indica: base de datos actual postgres, y # significa superusuario (un > indicaría usuario normal).

Comprobar la versión desde dentro

SELECT version();

                            version
----------------------------------------------------------------
 PostgreSQL 16.2 on x86_64-pc-linux-gnu, compiled by gcc 12.2.0
(1 row)

Fíjate en dos cosas: la instrucción termina en punto y coma (sin él, psql esperará más texto), y el resultado se presenta como una tabla con el número de filas al final.

Crear un usuario propio (recomendado en Linux)

Trabajar siempre como superusuario es mala práctica. Crea un usuario con tu nombre:

CREATE USER alumno WITH PASSWORD 'biblioRed2026' CREATEDB;

CREATEDB le permite crear bases de datos, que es lo que necesitamos.

Crear la base de datos del curso

CREATE DATABASE biblioredb OWNER alumno;

CREATE DATABASE

Esa respuesta escueta es la confirmación de que ha funcionado. biblioredb es la base de datos donde ejecutaremos todo el SQL del curso: las tablas de socios, libros, ejemplares y préstamos que diseñaremos a partir del módulo 2 vivirán aquí.

Metacomandos esenciales de `psql`

Los comandos que empiezan por barra invertida no son SQL: son instrucciones para el cliente psql y no llevan punto y coma.

Metacomando	Qué hace
`\l`	Lista las bases de datos del servidor
`\c biblioredb`	Se conecta a la base de datos indicada
`\dt`	Lista las tablas de la base de datos actual
`\d nombre_tabla`	Describe una tabla: columnas, tipos, índices
`\du`	Lista los usuarios y roles
`\conninfo`	Muestra a qué base y con qué usuario estás conectado
`\x`	Alterna la salida a formato vertical (útil con muchas columnas)
`\?`	Ayuda de los metacomandos
`\h SELECT`	Ayuda de sintaxis SQL de una instrucción
`\q`	Salir

Probémoslos:

postgres=# \l
                            List of databases
    Name    |  Owner   | Encoding |   Collate   |    Ctype    |
------------+----------+----------+-------------+-------------+
 biblioredb | alumno   | UTF8     | es_ES.UTF-8 | es_ES.UTF-8 |
 postgres   | postgres | UTF8     | es_ES.UTF-8 | es_ES.UTF-8 |
 template0  | postgres | UTF8     | es_ES.UTF-8 | es_ES.UTF-8 |
 template1  | postgres | UTF8     | es_ES.UTF-8 | es_ES.UTF-8 |
(4 rows)

Ahí está biblioredb. Las bases template0 y template1 son plantillas internas del sistema: no las toques.

postgres=# \c biblioredb
You are now connected to database "biblioredb" as user "postgres".

biblioredb=# \dt
Did not find any relations.

El prompt ha cambiado a biblioredb=#: ya estamos dentro. Y \dt dice que no hay tablas, lo cual es correcto: la base de datos está vacía y la llenaremos en el módulo 2.

Conectarse directamente desde el terminal

Para las próximas sesiones, ahorra pasos conectándote de una vez:

psql -U alumno -d biblioredb -h localhost

-U alumno: usuario.
-d biblioredb: base de datos.
-h localhost: servidor (necesario para que pida contraseña en lugar de usar la autenticación del sistema).

También puedes ejecutar una consulta sin entrar en la sesión interactiva:

psql -U alumno -d biblioredb -h localhost -c "SELECT current_database(), current_user;"

Instalación y primeros pasos con SQLite

SQLite es el plan B (y a veces el plan A) para practicar: no hay servidor que arrancar.

Instalación

# Debian / Ubuntu
sudo apt install -y sqlite3

# Fedora / RHEL
sudo dnf install -y sqlite

# macOS: viene preinstalado; para la versión más reciente
brew install sqlite

En Windows, descarga el paquete sqlite-tools desde sqlite.org/download.html, descomprímelo en una carpeta (por ejemplo C:\sqlite) y añade esa carpeta al PATH, o simplemente ejecuta sqlite3.exe desde ahí.

Comprobar la versión

sqlite3 --version

3.45.1 2024-01-30 16:01:20 e876e51a0ed5c5b3126f52e532044363a014bc594cfefa87ffb5b82257cc467a

Crear la base de datos del curso

En SQLite, crear una base de datos es crear un fichero. No hay CREATE DATABASE:

sqlite3 biblioredb.sqlite

SQLite version 3.45.1 2024-01-30 16:01:20
Enter ".help" for usage hints.
sqlite>

Un detalle importante: el fichero no se crea en disco hasta que escribas algo dentro. Si sales sin crear ninguna tabla, no habrá fichero.

Metacomandos esenciales de `sqlite3`

Aquí los comandos del cliente empiezan por punto, no por barra invertida:

Metacomando	Qué hace	Equivalente en `psql`
`.tables`	Lista las tablas	`\dt`
`.schema tabla`	Muestra el SQL de creación de una tabla	`\d tabla`
`.databases`	Muestra los ficheros de base de datos abiertos	`\l` (parcialmente)
`.open fichero.sqlite`	Abre otra base de datos	`\c`
`.headers on`	Muestra los nombres de columna en los resultados	(por defecto en psql)
`.mode box`	Formatea la salida como tabla con bordes	(por defecto en psql)
`.help`	Ayuda	`\?`
`.quit`	Salir	`\q`

Los dos primeros que deberías ejecutar siempre al abrir sqlite3, porque la salida por defecto es muy austera:

sqlite> .headers on
sqlite> .mode box
sqlite> SELECT sqlite_version();
┌──────────────────┐
│ sqlite_version() │
├──────────────────┤
│ 3.45.1           │
└──────────────────┘

sqlite> .tables
sqlite>

Vacío, como esperábamos.

Para que .headers on y .mode box se apliquen siempre, crea un fichero .sqliterc en tu carpeta personal con esas dos líneas.

Diferencias que conviene saber desde ya

	PostgreSQL	SQLite
Crear base de datos	`CREATE DATABASE nombre;`	Abrir un fichero nuevo
Metacomandos	`\l`, `\c`, `\dt`, `\d`	`.databases`, `.open`, `.tables`, `.schema`
Tipos de datos	Estrictos: una columna `INTEGER` rechaza texto	Flexibles por defecto: acepta casi cualquier valor
Usuarios	Sí	No
Salir	`\q`	`.quit`

La diferencia de tipos es la más relevante para aprender: SQLite es permisivo y dejará pasar cosas que PostgreSQL rechazaría. Si practicas en SQLite, sé consciente de que PostgreSQL será más estricto — y esa estrictez es una virtud, no un obstáculo, como vimos en la lección 01-01.

Alternativas: Docker y consolas en línea

Si no puedes o no quieres instalar nada en tu equipo, hay dos salidas perfectamente válidas.

Docker

Levanta un PostgreSQL desechable en un contenedor:

# Descargar y arrancar un PostgreSQL 16 en segundo plano
docker run --name pg-biblioredb \
  -e POSTGRES_PASSWORD=biblioRed2026 \
  -e POSTGRES_DB=biblioredb \
  -p 5432:5432 \
  -d postgres:16

Qué hace cada opción:

--name pg-biblioredb: nombre del contenedor, para referirte a él después.
-e POSTGRES_PASSWORD=...: contraseña del usuario postgres (obligatoria).
-e POSTGRES_DB=biblioredb: crea la base de datos del curso al arrancar.
-p 5432:5432: expone el puerto en tu máquina.
-d: en segundo plano.

Para entrar con psql sin instalarlo localmente:

docker exec -it pg-biblioredb psql -U postgres -d biblioredb

Gestión del contenedor:

docker stop pg-biblioredb    # parar
docker start pg-biblioredb   # volver a arrancar (los datos siguen ahí)
docker rm -f pg-biblioredb   # eliminar: SE PIERDEN LOS DATOS

Ten presente esa última advertencia: sin un volumen montado, borrar el contenedor borra la base de datos.

Consolas SQL en línea

Sin instalar absolutamente nada, sirven para seguir el curso y hacer los ejercicios:

db-fiddle.com y sqliteonline.com: permiten elegir PostgreSQL o SQLite y ejecutar SQL en el navegador.
pgexercises.com: PostgreSQL con ejercicios integrados.

Su limitación es que no persisten entre sesiones: guarda tus scripts en un fichero .sql aparte. Para el módulo 2 son suficientes; para trabajar con comodidad a partir del módulo 4, es preferible una instalación local o Docker.

Interfaces gráficas (opcional)

Si prefieres una interfaz visual, pgAdmin (viene con el instalador de Windows), DBeaver (multiplataforma, sirve para PostgreSQL, SQLite y MongoDB) o DB Browser for SQLite son buenas opciones. Recomendación: aprende primero con psql y sqlite3. La línea de comandos te obliga a entender lo que ocurre y está disponible en cualquier servidor al que te conectes.

Errores Comunes y Consejos

Olvidar el punto y coma en psql. Si escribes SELECT version() y pulsas Enter, el prompt cambia a postgres-# y parece que se ha colgado. No lo está: espera a que termines la instrucción. Escribe ; y Enter.
Confundir metacomandos con SQL. \dt no lleva punto y coma y solo funciona en psql; .tables solo funciona en sqlite3. No son parte del lenguaje SQL y no funcionan desde una aplicación.
psql: FATAL: role "tu_usuario" does not exist en Linux. Ocurre al ejecutar psql a secas: PostgreSQL intenta autenticarte con el nombre de tu usuario del sistema, que no existe como rol. Solución: sudo -u postgres psql y crea tu usuario, como en el apartado 8.
could not connect to server. El servidor no está arrancado. Comprueba con sudo systemctl status postgresql (Linux) o brew services list (macOS) y arráncalo si hace falta.
Creer que SQLite crea el fichero al abrirlo. Solo se materializa cuando escribes algo. Si ls no muestra biblioredb.sqlite, no es un fallo: es que aún no has creado ninguna tabla.
Practicar solo en SQLite y llevarse una sorpresa. SQLite acepta texto en una columna INTEGER; PostgreSQL no. Si el objetivo es trabajar con PostgreSQL, practica en PostgreSQL siempre que puedas.
Trabajar siempre como superusuario. Funciona, pero no enseña nada sobre permisos y en un entorno real es peligroso. Crear un usuario alumno cuesta una línea.
Consejo: guarda tus consultas en ficheros .sql desde el primer día, y ejecútalos con psql -f script.sql o con .read script.sql en SQLite. Tener el trabajo en ficheros versionables es la diferencia entre practicar y construir algo.

Ejercicios

Ejercicio 1: Identificar el componente responsable

Para cada situación, indica qué componente del SGBD interviene principalmente y en qué nivel ANSI/SPARC se sitúa el cambio (si aplica):

Escribes SELCT * FROM socios; y recibes un error de sintaxis.
Escribes SELECT nombre FROM sociso; y recibes "la relación no existe".
La misma consulta tarda 400 ms la primera vez y 8 ms la segunda.
El administrador crea un índice y un informe pasa de 30 s a 0,2 s, sin cambiar la consulta.
Se corta la luz a mitad de un préstamo y, al arrancar, la base de datos está coherente.
El usuario del mostrador ejecuta DELETE FROM socios; y recibe "permiso denegado".
Se divide la tabla socios en dos, pero las aplicaciones siguen funcionando gracias a una vista.

Ejercicio 2: Verificar el entorno

Realiza estas comprobaciones y anota la salida de cada una:

Comprueba la versión de psql desde el terminal.
Conéctate a PostgreSQL y muestra la versión del servidor con SQL.
Crea la base de datos biblioredb si aún no la tienes, y comprueba con un metacomando que aparece en el listado.
Conéctate a biblioredb y comprueba que no tiene tablas.
Con SQLite, crea biblioredb.sqlite, activa cabeceras y modo tabla, y muestra la versión.
En psql, averigua a qué base de datos y con qué usuario estás conectado usando un solo metacomando.

Ejercicio 3: Elegir arquitectura

Para cada escenario, decide entre PostgreSQL (cliente-servidor) y SQLite (embebida), y justifica en dos frases:

El sistema real de BiblioRed, con cuatro sucursales registrando préstamos simultáneamente.
Una aplicación móvil que permite a los socios consultar su historial sin conexión a internet.
Las pruebas automatizadas de la aplicación de BiblioRed, que deben crear y destruir una base de datos limpia en cada ejecución.
Un panel de dirección al que acceden ocho personas desde distintos edificios.
Un programa de escritorio que un bibliotecario usa para preparar el inventario anual en su portátil.

Soluciones

Solución 1

#	Componente	Nivel ANSI/SPARC
1	Parser (análisis sintáctico). El error se detecta antes de mirar el catálogo o los datos.	No aplica: es previo
2	Analizador semántico, consultando el catálogo. La sintaxis es correcta, pero la tabla `sociso` no existe.	Conceptual (se comprueba contra él)
3	Gestor de buffers. La primera ejecución lee de disco; la segunda encuentra las páginas en memoria.	Interno
4	Optimizador y motor de almacenamiento. Es un ejemplo puro de independencia física: cambia el nivel interno y ninguna consulta se modifica.	Interno
5	Gestor de transacciones y recuperación, mediante el registro de escritura anticipada (WAL).	Interno
6	Control de acceso (autorización).	Externo/conceptual, según cómo se hayan definido los permisos
7	Cambio en el esquema conceptual absorbido por el nivel externo: es un ejemplo de independencia lógica.	Conceptual, con vistas externas intactas

Solución 2

# 1
psql --version
# psql (PostgreSQL) 16.2

-- 2 (dentro de psql)
SELECT version();

-- 3
CREATE DATABASE biblioredb;

postgres=# \l

biblioredb debe aparecer en el listado.

-- 4
postgres=# \c biblioredb
You are now connected to database "biblioredb".
biblioredb=# \dt
Did not find any relations.

# 5
sqlite3 biblioredb.sqlite

sqlite> .headers on
sqlite> .mode box
sqlite> SELECT sqlite_version();

-- 6
biblioredb=# \conninfo
You are connected to database "biblioredb" as user "alumno" on host "localhost" at port "5432".

Si los seis pasos funcionan, tienes el entorno del curso listo.

Solución 3

#	Elección	Justificación
1	PostgreSQL	Cuatro sucursales escribiendo a la vez exigen concurrencia de escritura real y control de acceso centralizado; SQLite admite un único escritor.
2	SQLite	Es un almacén local por dispositivo, sin conexión y de un solo usuario. Es exactamente el caso para el que se diseñó el modelo embebido.
3	SQLite	Crear y destruir un fichero (o una base en memoria) es instantáneo y no requiere servidor, lo que hace las pruebas rápidas y aisladas. Conviene validar también contra PostgreSQL antes de desplegar, porque los tipos son más estrictos allí.
4	PostgreSQL	Acceso remoto desde varias máquinas y necesidad de permisos por rol: es cliente-servidor por definición.
5	SQLite	Un usuario, una máquina, trabajo local y sin administración. Los datos se sincronizarían después con el sistema central.

Conclusión

Con esta lección cerramos el módulo introductorio, y lo hacemos con el entorno de trabajo en marcha. Hemos visto:

Los componentes internos de un SGBD: gestor de conexiones y control de acceso, procesador y optimizador de consultas, motor de almacenamiento, gestor de buffers, gestor de transacciones y recuperación, y catálogo de datos.
El viaje completo de una consulta, desde el análisis sintáctico hasta las filas devueltas, con la optimización basada en costes como pieza decisiva del rendimiento.
La arquitectura ANSI/SPARC de tres niveles —externo, conceptual e interno— y las dos independencias de datos: la física (cambiar el almacenamiento sin tocar las consultas) y la lógica (cambiar el esquema sin romper las aplicaciones que usan vistas).
La diferencia entre cliente-servidor y embebido, con PostgreSQL y SQLite como representantes de cada extremo, y por qué BiblioRed usará el primero en producción y el segundo para practicar.
Los roles humanos: administrador, desarrollador y analista.
Y, en la práctica: instalación de PostgreSQL y SQLite en Linux, macOS y Windows, conexión con psql y sqlite3, comprobación de versiones, creación de la base de datos biblioredb y manejo de los metacomandos básicos (\l, \c, \dt, \d, .tables, .schema), además de las alternativas con Docker y consolas en línea.

Ya sabemos qué es una base de datos y qué problemas resuelve, qué familias existen y cómo elegir entre ellas, de dónde viene todo esto, qué ocurre dentro del gestor y cómo se organiza. Y, sobre todo, tenemos biblioredb esperando, vacía. En el módulo 2, Bases de Datos Relacionales, empezamos a llenarla: la lección 02-01, Modelo Relacional, formaliza qué es exactamente una relación, qué son las claves primarias y ajenas y qué reglas de integridad rigen el modelo; a partir de ahí, la lección 02-02 introduce SQL y escribiremos las primeras instrucciones reales sobre las tablas de socios, libros, ejemplares y préstamos de BiblioRed. La teoría termina aquí; a partir de la próxima lección, se teclea.

Sistemas Gestores de Bases de Datos y Arquitectura

Contenido

Los componentes internos de un SGBD

Gestor de conexiones y control de acceso

Procesador y optimizador de consultas

Motor de almacenamiento

Gestor de buffers (caché)

Gestor de transacciones y recuperación

Catálogo o diccionario de datos

Utilidades

El viaje de una consulta, paso a paso

La arquitectura ANSI/SPARC de tres niveles

Nivel externo (o de vistas)

Nivel conceptual (o lógico)

Nivel interno (o físico)

Independencia de datos lógica y física

Independencia física

Independencia lógica

Cliente-servidor frente a base de datos embebida

Arquitectura cliente-servidor: PostgreSQL

Arquitectura embebida: SQLite

Comparación

Roles humanos alrededor de una base de datos

Administrador de bases de datos (DBA)

Desarrollador de bases de datos / de aplicaciones

Analista de datos

Instalación de PostgreSQL

Linux (Debian / Ubuntu)

Linux (Fedora / RHEL)

macOS

Windows

Comprobar la versión

Primeros pasos con psql y creación de biblioredb

Conectarse

Comprobar la versión desde dentro

Crear un usuario propio (recomendado en Linux)

Crear la base de datos del curso

Metacomandos esenciales de psql

Conectarse directamente desde el terminal

Instalación y primeros pasos con SQLite

Instalación

Comprobar la versión

Crear la base de datos del curso

Metacomandos esenciales de sqlite3

Diferencias que conviene saber desde ya

Alternativas: Docker y consolas en línea

Docker

Consolas SQL en línea

Interfaces gráficas (opcional)

Errores Comunes y Consejos

Ejercicios

Ejercicio 1: Identificar el componente responsable

Ejercicio 2: Verificar el entorno

Ejercicio 3: Elegir arquitectura

Soluciones

Solución 1

Solución 2

Solución 3

Conclusión

Fundamentos de Bases de Datos

Módulo 1: Introducción a las Bases de Datos

Módulo 2: Bases de Datos Relacionales

Módulo 3: Bases de Datos No Relacionales

Módulo 4: Diseño de Esquemas

Módulo 5: Normalización

Módulo 6: Transacciones, Rendimiento y Seguridad

Módulo 7: Ejercicios Prácticos

Módulo 8: Casos de Estudio

Módulo 9: Recursos Adicionales

Primeros pasos con `psql` y creación de `biblioredb`

Metacomandos esenciales de `psql`

Metacomandos esenciales de `sqlite3`