Bases de datos: claves, relaciones y SQL que puntúa

Diego Salazar

Welcome to the show. Lucía, te tiro una escena de examen: el estudiante ve una captura con tres tablas, dos flechitas, y dice “ah sí, base de datos”. Y ahí mismo ya se metió el pie. Porque una base de datos NO es solo las tablas; es el modelo, el diseño, las reglas, las consultas... todo mezclado. Y cuando confundes esas capas, el examen te castiga rapidísimo.

Lucía Navarro

Sí, y ese castigo suele verse en respuestas como “una tabla guarda información”. Suena aceptable, pero para IB se queda corta. Dato no es lo mismo que información. Un dato puede ser “9780141182803”, un número aislado. Información es cuando ese dato ya tiene contexto: “ese ISBN corresponde a un libro específico de la biblioteca”. El contexto convierte datos en algo útil.

Diego Salazar

A ver, agarremos la biblioteca porque ahí se ve clarito. Si tengo una tabla Libros, un registro sería UNA fila completa, ¿no? O sea: libro 102, título, autor, ISBN, categoría.

Lucía Navarro

Exacto. Y un campo es cada atributo individual dentro del registro: título, autor, ISBN. La tabla agrupa registros del mismo tipo. Entonces: tabla Libros, tabla Socios, tabla Préstamos. Eso ya nos prepara para dos claves que el examen ama. La clave primaria identifica de manera única cada registro. “LibroID = 102” funciona mejor que usar el título, porque puedes tener dos libros con títulos parecidos o incluso iguales.

Diego Salazar

Y aquí está la trampa clásica. El estudiante dice: “mi clave primaria será Nombre”. No. En una cafetería puedes tener dos clientes llamados Ana. Dos Anas, mismo día, mismo café... caos total. Nombre describe; ID identifica.

Lucía Navarro

“Nombre describe; ID identifica”, esa sí se queda. Y luego viene la clave foránea, que es la que enlaza tablas. Si en la tabla Préstamos aparece SocioID, ese campo apunta a la clave primaria de la tabla Socios. No identifica el préstamo por sí solo; conecta el préstamo con la persona correcta. Eso es relación, no repetición.

Diego Salazar

Voy a explicarlo como cafetería, porque mi cerebro siempre se va ahí. Tienes Clientes, Productos y Pedidos. PedidoID es la clave primaria de Pedidos. ClienteID dentro de Pedidos es clave foránea porque te dice quién hizo ese pedido. Si en vez de guardar ClienteID repites nombre, teléfono y correo del cliente en cada pedido... uff.

Lucía Navarro

...creas duplicación. Y esa es la primera tensión importante: por fuera se ve “simple”. Solo son filas. Pero un mal diseño vuelve todo torpe. Las consultas se hacen más lentas porque estás repitiendo datos; más inconsistentes porque cambias un teléfono en una fila y en otra no; y más difíciles de mantener porque cada ajuste toca demasiados lugares.

Diego Salazar

Y en mark scheme eso aparece con palabras muy concretas: redundancia, inconsistencia, mantenimiento, integridad. Si te piden justificar un diseño, no digas “para que sea más ordenado”. Di “para reducir duplicación y evitar anomalías de actualización”. Esa frase sí puntúa.

Lucía Navarro

Y nota algo más: una base de datos bien hecha no solo guarda cosas. Representa una situación real de manera coherente. Si no entiendes el mundo real —biblioteca, cafetería, club escolar— el modelo sale débil, y después ni SQL te salva.

Lucía Navarro

El corazón del tema es el modelo relacional. Ahí pensamos en entidades, atributos y relaciones. Entidad es algo sobre lo que guardas datos: Libro, Socio, Pedido, Estudiante. Atributos son sus propiedades: nombre, fecha, precio. Y relaciones describen cómo se conectan esas entidades. Un socio pide prestado un libro. Un cliente hace un pedido. Un estudiante se inscribe en una clase.

Diego Salazar

Y la cardinalidad es la parte que muchos medio ven, pero no TERMINAN de agarrar. Uno a uno, uno a muchos, muchos a muchos. Dame una imagen rápida de examen.

Lucía Navarro

Una biblioteca. Un socio puede tener muchos préstamos: uno a muchos. Un préstamo, en un diseño simple, corresponde a un solo socio: muchos a uno visto desde la otra tabla. Y muchos a muchos aparece cuando una entidad puede relacionarse con muchas de la otra y viceversa; por ejemplo, estudiantes y clubes. Un estudiante puede estar en varios clubes y un club tiene varios estudiantes. Ahí normalmente necesitas una tabla intermedia, como Membresías.

Diego Salazar

Membresías. Ese nombre vale oro. Porque si intentas meter una lista de clubes dentro de la tabla Estudiantes —“ajedrez, debate, música”— ya rompiste la lógica relacional. Eso no es un campo limpio; eso es una mini hoja de cálculo escondida adentro.

Lucía Navarro

Sí, y el diagrama E-R existe justamente para evitar eso. No es decoración. Es la traducción visual del problema real. Si el problema dice “un pedido contiene varios productos”, el diagrama debe mostrar esa relación. Si no lo muestra, luego en SQL vas a inventar conexiones que el diseño nunca resolvió.

Diego Salazar

Y ahí entramos a SQL, que es donde muchos sienten alivio porque ya “pueden escribir algo”. Pero escribir algo no basta. SELECT muestra columnas. FROM dice de dónde salen. WHERE filtra. ORDER BY ordena. Hasta ahí, bien. El problema es que el estudiante ve una pregunta tipo “mostrar los nombres de los clientes de Madrid ordenados por apellido” y escribe SELECT * FROM Clientes; gracias por participar.

Lucía Navarro

Exacto. Mejor: SELECT Nombre, Apellido FROM Clientes WHERE Ciudad = 'Madrid' ORDER BY Apellido; Fíjate en la precisión. No seleccionas todo si no te lo piden. Filtras con WHERE. Ordenas con ORDER BY. En examen, la precisión importa tanto como la sintaxis.

Diego Salazar

Y cuando te piden contar, COUNT. Si te piden total de ventas, SUM. Si te piden total por categoría, ahí ya no basta con mostrar filas: necesitas GROUP BY. Esa es una diferencia importante. Leer datos es una cosa; extraer significado es otra. “Muéstrame todos los pedidos” no responde “¿qué producto se vendió más?”

Lucía Navarro

Esa frase —“mostrar filas” versus “responder una pregunta”— es central. Si la pregunta dice “¿cuántos préstamos tiene cada socio?”, una consulta posible sería: SELECT SocioID, COUNT(*) FROM Prestamos GROUP BY SocioID; Y si además solo quieres quienes tienen más de tres, bueno, ahí ya entras a filtrar agregados... aunque en muchos cursos introductorios basta con entender que GROUP BY agrupa antes de contar.

Diego Salazar

Y JOIN. Tenemos que hablar de JOIN porque ahí se descarrila medio mundo. Si quiero nombres de socios junto con fechas de préstamo, no saco eso de una sola tabla si el diseño está normalizado. Uno Socios con Préstamos usando la clave. Algo tipo: SELECT Socios.Nombre, Prestamos.Fecha FROM Socios JOIN Prestamos ON Socios.SocioID = Prestamos.SocioID;

Lucía Navarro

Sí. Y el error frecuente no es solo sintáctico. Es conceptual. Escriben el JOIN, pero unen campos que no corresponden: Nombre con Título, o dos IDs de tablas distintas que no representan la misma cosa. La regla mental es: une clave primaria con su clave foránea relacionada, no “columnas que se parecen”.

Diego Salazar

“No columnas que se parecen.” Eso debería estar pegado en cada cuaderno de IB. Porque NombreID suena parecido a ClienteID y ya creen que va. No. Tienes que saber qué representa cada campo en el modelo, si no el SQL es puro maquillaje.

Diego Salazar

Ahora, la palabra que asusta: normalización. Mucha gente la memoriza como 1FN, 2FN, 3FN y ya. Pero si no la conectas con problemas reales, se te borra en dos días. Yo la veo como limpieza con propósito. ¿Qué error estamos evitando?

Lucía Navarro

Tres errores clásicos: anomalía de inserción, de actualización y de borrado. Inserción: no puedes agregar un dato sin inventarte otro. Por ejemplo, si guardas datos del curso y del profesor en la misma tabla, tal vez no puedes registrar un profesor nuevo hasta que tenga curso asignado. Actualización: cambias el correo del profesor en una fila, pero se repite en cinco más y olvidas cuatro. Borrado: eliminas el último curso y accidentalmente borras también toda la información del profesor.

Diego Salazar

El de borrado siempre me pega. Es como tirar el último ticket de una cafetería y, por haberlo diseñado mal, desaparece también el proveedor de leche. O sea, borraste una transacción y te llevaste una entidad entera. Eso es una base frágil.

Lucía Navarro

Primera forma normal: campos atómicos. Sin listas dentro de una celda, sin valores múltiples en un mismo campo. Si en “Teléfonos” guardas “5551, 5552”, ya tienes problema. Segunda forma normal: en tablas con clave compuesta, cada atributo no clave debe depender de TODA la clave, no solo de una parte. Tercera forma normal: los atributos no clave deben depender solo de la clave primaria, no de otro atributo no clave. Dicho así suena abstracto; veámoslo aterrizado.

Diego Salazar

Sí, porque “depender de toda la clave” es donde varios se quedan mirando al techo. Dame un caso.

Lucía Navarro

Tabla Inscripciones con clave compuesta EstudianteID + AsignaturaID. Si además guardas NombreEstudiante, ese nombre depende solo de EstudianteID, no de la combinación completa. Entonces conviene moverlo a la tabla Estudiantes. Y para 3FN: si en una tabla guardas CódigoPostal y Ciudad, pero Ciudad depende de CódigoPostal, no directamente de la clave primaria de esa tabla, tienes dependencia transitiva. Separar esas dependencias reduce redundancia.

Diego Salazar

“CódigoPostal y Ciudad” es de esas parejas que se recuerdan fácil. Me la guardo. Y aquí viene mi lado práctico: normalizar no es por elegancia. Es para que cuando el negocio cambie una sola cosa, no tengas que perseguir ese cambio por veinte filas.

Lucía Navarro

Exactamente. Y cierro con trampas muy IB. Una: escoger una clave primaria poco estable, como nombre o correo si puede cambiar. Dos: interpretar mal una relación muchos a muchos y no crear tabla intermedia. Tres: usar JOIN sin entender la relación, lo que produce datos incorrectos aunque la consulta “corra”. Cuatro: responder de forma genérica cuando piden justificar. Si el examen pregunta por qué separar Clientes y Pedidos, no digas “para organizar mejor”. Di “para reducir redundancia, mejorar integridad y evitar anomalías de actualización”.

Diego Salazar

Y cinco, que para mí es la más silenciosa: contestar la consulta correcta para la pregunta equivocada. Te piden “cliente con mayor gasto” y tú muestras todas las compras ordenadas. Eso es trabajar de más y responder de menos. En bases de datos, como en examen, no gana quien escribe más. Gana quien modela bien, une bien, y justifica EXACTAMENTE por qué.

Lucía Navarro

Porque al final esa es la tensión de fondo: si entiendes la estructura, SQL se vuelve una herramienta. Si no la entiendes, hasta una consulta aparentemente perfecta puede estar respondiendo un mundo que diseñaste mal.