El modelo relacional

📐 Fundamento

El modelo relacional tiene términos formales y términos coloquiales. Conviene conocer ambos:

Ejemplo:

• "Hay 3 tuplas en la relación Producto" = "Hay 3 filas en la tabla Producto".
• "El dominio del atributo precio es DECIMAL" = "El tipo de la columna precio es DECIMAL".

En conversación común hablás de tablas, filas, columnas. En documentos formales / exámenes, podés ver lo otro. Las dos formas valen.

Una tabla es un conjunto matemáticamente. Eso significa:

• Sin orden entre filas.
• Sin duplicados (en teoría — en la práctica los DBMS los permiten salvo que pidas lo contrario).
• Sin orden entre columnas (al usar la tabla; al definirla sí hay orden).

Por eso un SELECT * FROM productos puede devolver las filas en cualquier orden, salvo que uses ORDER BY.

📐 Fundamento

El DDL (Data Definition Language) es el subconjunto de SQL para definir esquemas:

CREATE TABLE producto (
    codigo      VARCHAR(10)  PRIMARY KEY,
    nombre      VARCHAR(100) NOT NULL,
    precio      DECIMAL(10,2) NOT NULL CHECK (precio >= 0),
    stock       INTEGER      NOT NULL DEFAULT 0,
    activo      BOOLEAN      NOT NULL DEFAULT TRUE
);

Anatomía:

• CREATE TABLE producto — crea la tabla.
• Cada línea define una columna: nombre + tipo + restricciones.
• VARCHAR(10) — texto de hasta 10 caracteres.
• DECIMAL(10,2) — número con 10 dígitos en total, 2 después del decimal. Ideal para dinero.
• INTEGER, BOOLEAN, DATE, TIMESTAMP — otros tipos comunes.
• PRIMARY KEY — esa columna es la llave primaria (más en sección siguiente).
• NOT NULL — el valor no puede ser nulo.
• CHECK (...) — restricción personalizada (precio no negativo).
• DEFAULT — valor si no se especifica al insertar.

Tipos comunes (SQL estándar):

Modificar:

ALTER TABLE producto ADD COLUMN descripcion VARCHAR(500);
ALTER TABLE producto DROP COLUMN activo;
ALTER TABLE producto ALTER COLUMN precio TYPE DECIMAL(12, 2);

Eliminar:

DROP TABLE producto;     -- ¡cuidado, borra la tabla y los datos!

📐 Fundamento

Las llaves son las herramientas que el modelo relacional usa para identificar filas y conectar tablas.

Llave primaria (Primary Key — PK)

Identifica de manera única cada fila. La PK es obligatoria (cada tabla seria tiene una) y única.

CREATE TABLE cliente (
    id    SERIAL PRIMARY KEY,         -- entero auto-incremental
    email VARCHAR(100) UNIQUE NOT NULL
);

SERIAL (Postgres) o AUTO_INCREMENT (MySQL): el DBMS asigna automáticamente 1, 2, 3, ... al insertar.

Reglas de la PK:

1. No puede ser nula.
2. No puede repetirse.
3. Idealmente: estable (no cambia con el tiempo). Por eso preferimos un ID artificial sobre algo "natural" como el email (puede cambiar).
4. Idealmente: chica (eficiencia de índices). Un INTEGER es mejor que un VARCHAR(100).

Llave candidata

Cualquier subconjunto de columnas que identifique únicamente. La PK se elige entre las llaves candidatas; las otras se mantienen como UNIQUE.

Ejemplo: en cliente, la PK es id. Pero email también identifica únicamente. email es llave candidata y se marca UNIQUE.

Llave compuesta

A veces una sola columna no alcanza. Ejemplo: tabla de inscripciones — un alumno se inscribe a una materia.

CREATE TABLE inscripcion (
    alumno_id  INTEGER,
    materia_id INTEGER,
    fecha      DATE,
    PRIMARY KEY (alumno_id, materia_id)
);

La PK son dos columnas juntas. Un alumno puede estar en muchas materias, una materia tiene muchos alumnos, pero cada combinación es única.

Llave foránea (Foreign Key — FK)

Una columna que referencia a la PK de otra tabla. Eso "conecta" dos tablas.

CREATE TABLE pedido (
    id          SERIAL PRIMARY KEY,
    cliente_id  INTEGER NOT NULL REFERENCES cliente(id),
    fecha       TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    total       DECIMAL(10,2)
);

cliente_id REFERENCES cliente(id) significa: "este valor debe existir en la columna id de la tabla cliente".

Lo que el DBMS garantiza:

• No podés insertar un pedido con cliente_id = 999 si no existe el cliente 999.
• No podés borrar un cliente que tiene pedidos (a menos que cascadees).

Acciones en cascada (qué hacer al borrar el padre):

... REFERENCES cliente(id) ON DELETE CASCADE
... REFERENCES cliente(id) ON DELETE SET NULL
... REFERENCES cliente(id) ON DELETE RESTRICT      -- default

• CASCADE: borra los hijos también.
• SET NULL: pone NULL en los hijos.
• RESTRICT: rechaza el borrado mientras haya hijos.

📐 Fundamento

El DBMS aplica automáticamente reglas que protegen los datos:

Integridad de entidad

La PK no puede ser nula. Cada fila debe tener identidad. Implementado por la cláusula PRIMARY KEY.

Integridad referencial

Las FK deben referenciar valores existentes (o ser nulas, si la columna lo permite).

Integridad de dominio

Cada columna acepta solo valores de su tipo y restricciones:

edad INTEGER CHECK (edad >= 0 AND edad <= 150)
estado VARCHAR(10) CHECK (estado IN ('activo', 'inactivo', 'baja'))

Integridad definida por usuario

UNIQUE, CHECK, triggers, stored procedures — reglas personalizadas.

NULL — el valor que no es

NULL significa "ausencia de valor / desconocido". No es lo mismo que 0 ni que "".

SELECT * FROM cliente WHERE telefono IS NULL;       -- correcto
SELECT * FROM cliente WHERE telefono = NULL;         -- ¡incorrecto! NULL nunca es igual ni siquiera a sí mismo

NULL propaga: 5 + NULL = NULL. NULL = NULL da NULL (no TRUE). En WHERE, NULL se trata como falso.

Cuándo usar NULL: valor genuinamente desconocido o no aplicable. Si "vacío" tiene significado (ej: balance = 0), usá ese valor en lugar de NULL.

📐 Fundamento

INSERT:

INSERT INTO producto (codigo, nombre, precio, stock)
VALUES ('Q', 'Pupusa de queso', 0.50, 100);

Múltiples filas:

INSERT INTO producto (codigo, nombre, precio, stock) VALUES
    ('Q', 'Pupusa de queso',  0.50, 100),
    ('R', 'Pupusa revuelta',  0.60, 80),
    ('F', 'Pupusa de frijol', 0.55, 60);

UPDATE:

UPDATE producto
SET precio = 0.55
WHERE codigo = 'Q';

WHERE es CRÍTICO. Sin él, actualizás TODAS las filas. Es uno de los errores más caros en bases reales.

DELETE:

DELETE FROM producto
WHERE stock = 0;

Misma advertencia. DELETE FROM producto; borra todo.

Buena costumbre: primero hacé el SELECT con tu WHERE para confirmar qué afectarías, después convertí a UPDATE o DELETE.

📐 Fundamento

Hay alternativas modernas: NoSQL (MongoDB, Redis, Cassandra), NewSQL (Spanner, CockroachDB), grafos (Neo4j). Sin embargo, las relacionales siguen siendo dominantes. Por qué:

Ventajas:

1. ACID. Atomicidad, Consistencia, Aislamiento, Durabilidad. Tus datos no se corrompen.
2. Lenguaje universal. SQL: 50 años de estandarización. Aprendés una vez, usás en cualquier DBMS.
3. Consultas declarativas. Vos decís qué querés, el DBMS decide cómo. El optimizador ha tenido 50 años de mejoras.
4. Restricciones formales. Tus datos tienen forma garantizada.
5. Madurez. PostgreSQL, MySQL, Oracle — décadas de uso, miles de horas de pruebas.

Cuándo NoSQL gana:

• Datos sin esquema fijo (logs, eventos, JSON variable).
• Escala horizontal masiva (millones de operaciones/seg distribuidas).
• Patrones de acceso muy específicos (cache, contador, cola).

Conclusión pragmática: empieza con relacional. Migrá a NoSQL solo cuando una métrica concreta lo justifique (latencia, throughput, escalabilidad). 90% de los proyectos no llegan a esa frontera.