Introducción a bases de datos relacionales y SQL

En los capítulos anteriores trabajamos con datos en memoria, luego con archivos JSON y después conectamos una interfaz con una API usando fetch(). Esa ruta fue intencional: primero entendimos cómo se mueven los datos dentro de la aplicación. Ahora toca entender dónde conviene guardarlos cuando el proyecto necesita crecer.

Un archivo JSON puede servir para aprender y prototipar, pero una aplicación real necesita ordenar mejor la información. Si queremos registrar proyectos, estudiantes, cursos, entregas, usuarios o productos, necesitamos una estructura más confiable. Ahí entran las bases de datos relacionales y el lenguaje SQL.

Qué aprenderás hoy

• Entender qué es una base de datos relacional.
• Diferenciar tablas, columnas, filas y registros.
• Comprender para qué sirve una clave primaria.
• Reconocer tipos de datos frecuentes en MySQL.
• Leer la lógica básica de SELECT, INSERT, UPDATE y DELETE.
• Preparar el modelo que luego llevaremos a MySQL.

Por qué una base de datos

Imagina una interfaz para administrar proyectos de clase. Al comienzo podríamos tener un arreglo de objetos en JavaScript. Luego podríamos guardar esos objetos en un archivo JSON. Pero si el sistema crece, aparecen nuevas preguntas: ¿cómo buscamos proyectos por curso?, ¿cómo evitamos repetir el nombre del docente en cada registro?, ¿cómo conectamos estudiantes con entregas?, ¿cómo mantenemos los datos consistentes?

Una base de datos relacional ayuda a resolver ese tipo de problemas. No solo guarda información; también permite organizarla, consultarla, relacionarla y protegerla mejor.

Qué es una base de datos relacional

Una base de datos relacional organiza la información en tablas. Cada tabla representa una entidad o concepto del sistema. Por ejemplo, en un proyecto académico podríamos tener tablas para cursos, estudiantes, proyectos y entregas.

Una tabla se parece a una hoja ordenada: tiene columnas y filas. Las columnas definen los campos. Las filas representan registros concretos.

projects

id | name                 | course_id | status
1  | Portafolio personal  | 2         | published
2  | Landing de producto  | 2         | draft

En este ejemplo, projects es la tabla. id, name, course_id y status son columnas. Cada línea es un proyecto registrado.

La clave primaria

La columna id suele funcionar como clave primaria. Su trabajo es identificar cada registro de forma única. Aunque dos proyectos tengan el mismo nombre, su id será diferente.

Esto es más importante de lo que parece. Cuando una interfaz edita, elimina o consulta un registro, necesita apuntar a una fila exacta. No basta con decir “el proyecto llamado Portafolio”. Puede haber varios. El identificador evita ambigüedades.

Tipos de datos frecuentes

Cuando creamos una tabla, no solo indicamos el nombre de cada columna. También declaramos qué tipo de dato aceptará. MySQL ofrece muchos tipos, pero para empezar nos bastan algunos muy usados.

• INT: números enteros, útil para identificadores o cantidades.
• VARCHAR: textos cortos con longitud máxima, como nombres o títulos.
• TEXT: textos largos, como descripciones o contenido.
• DATE: fechas sin hora.
• DATETIME: fecha y hora.
• TINYINT: puede servir para valores booleanos como publicado/no publicado.

La elección del tipo ayuda a mantener los datos limpios. Si una columna debe guardar una fecha, no conviene tratarla como texto. Si un campo será un título corto, no necesitamos un campo pensado para textos enormes.

Un primer diseño de tabla

Pensemos en una tabla para proyectos de estudiantes. Todavía no estamos creando la base de datos definitiva; estamos diseñando su forma.

CREATE TABLE projects (
  id INT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(120) NOT NULL,
  team VARCHAR(120) NOT NULL,
  course VARCHAR(80) NOT NULL,
  status VARCHAR(30) NOT NULL,
  created_at DATETIME NOT NULL
);

Esta sentencia dice: “crea una tabla llamada projects con estos campos”. AUTO_INCREMENT permite que MySQL genere el siguiente identificador. PRIMARY KEY marca el campo principal. NOT NULL indica que ese dato no debería quedar vacío.

SQL: el lenguaje para conversar con la base de datos

SQL es el lenguaje que usamos para crear estructuras, insertar información, consultarla, actualizarla y eliminarla. En un CRUD, las operaciones principales tienen una traducción bastante directa.

Leer registros con SELECT

SELECT id, name, team, status
FROM projects
ORDER BY created_at DESC;

SELECT permite pedir datos. Podemos elegir columnas específicas, filtrar resultados y ordenar la respuesta.

Crear registros con INSERT

INSERT INTO projects (name, team, course, status, created_at)
VALUES ('Portafolio personal', 'Lucía y Mateo', 'Desarrollo de Interfaces', 'draft', NOW());

INSERT agrega una nueva fila. Observa que no enviamos id; dejamos que la base de datos lo genere.

Actualizar registros con UPDATE

UPDATE projects
SET status = 'published'
WHERE id = 1;

UPDATE modifica registros existentes. La parte crítica es WHERE. Sin una condición clara, podríamos afectar más filas de las esperadas.

Eliminar registros con DELETE

DELETE FROM projects
WHERE id = 1;

DELETE elimina filas. Igual que con UPDATE, la condición es fundamental. En clase conviene practicar primero con datos de prueba para perderle miedo sin poner en riesgo información importante.

Relaciones entre tablas

El verdadero poder del modelo relacional aparece cuando dejamos de guardar todo en una sola tabla. En lugar de repetir el nombre del curso en cada proyecto, podríamos tener una tabla courses y conectar cada proyecto con su curso mediante course_id.

courses
id | name
1  | Desarrollo de Interfaces 1
2  | Desarrollo de Aplicaciones Web

projects
id | name                 | course_id
1  | Portafolio personal  | 1
2  | API de tareas        | 2

Ese campo course_id funciona como referencia. Más adelante podremos convertirlo en una clave foránea para que la base de datos ayude a mantener la relación.

No normalizar por deporte

Normalizar significa organizar los datos para evitar repeticiones innecesarias y dependencias confusas. Pero tampoco se trata de dividir todo en veinte tablas desde el primer día. En proyectos educativos, lo ideal es avanzar por capas: primero entender la entidad principal, luego detectar repeticiones reales y recién entonces separar tablas.

Si estamos aprendiendo, una tabla projects simple está bien. Cuando veamos que curso, estudiante o equipo se repiten mucho, será momento de crear nuevas tablas y relaciones.

Errores comunes

• Crear una sola tabla gigante para todo el sistema.
• No usar una clave primaria estable.
• Guardar fechas como texto sin necesidad.
• Repetir datos que deberían vivir en otra tabla.
• Usar nombres de columnas poco claros como dato1 o info.
• Ejecutar UPDATE o DELETE sin revisar el WHERE.

Reto práctico

Variante extra: crea también una tabla courses y decide cómo se relacionaría con projects. No escribas todavía el código Node.js; concéntrate en pensar correctamente los datos.

Conclusión

Una base de datos relacional no es solo un lugar para guardar información. Es una forma de ordenar el pensamiento de una aplicación. Cuando diseñamos tablas, campos y relaciones, estamos definiendo qué entiende nuestro sistema sobre el mundo que quiere representar.

Para Desarrollo de Interfaces, esto es clave. Una buena interfaz necesita datos confiables. Si los datos están mal estructurados, la pantalla termina mostrando inconsistencias, repeticiones o estados confusos. Por eso este capítulo hace una pausa antes de programar: primero modelamos, luego implementamos.

En el siguiente capítulo crearemos una base de datos y tablas en MySQL. Ahí pasaremos de la idea al entorno real: base, tabla, tipos, claves y primeros registros.

Fuentes consultadas

• MySQL 8.4 Reference Manual: CREATE TABLE Statement
• MySQL 8.4 Reference Manual: Data Types
• MySQL 8.4 Reference Manual: SELECT Statement
• MySQL 8.4 Reference Manual: INSERT Statement
• MySQL 8.4 Reference Manual: UPDATE Statement
• MySQL 8.4 Reference Manual: DELETE Statement