Antes de maquetar una web haces bocetos y wireframes. Antes de crear una base de datos se hace lo mismo con los datos: un modelo entidad-relación (E/R), un diagrama que describe qué cosas hay que guardar, qué datos tiene cada una y cómo se relacionan. Es diseño de información, y se te va a dar bien.

Truco para encontrarlas en un texto: los sustantivos importantes suelen ser entidades o atributos; los verbos, relaciones.

• 1:1 (uno a uno): cada persona tiene un DNI y cada DNI es de una persona. Es poco frecuente; a menudo se resuelve con una sola tabla.
• 1:N (uno a muchos): una autora diseña muchos carteles; cada cartel es de una autora. La más habitual.
• N:M (muchos a muchos): un cartel se expone en muchas exposiciones y en una exposición hay muchos carteles.

Pregúntate siempre en los dos sentidos: "¿un cartel puede tener varios autores?". La respuesta depende del caso real: si en tu archivo hay carteles hechos en grupo, la relación será N:M. Decidirlo es parte del diseño.

"La escuela quiere un archivo de los carteles del alumnado. De cada cartel se guarda el título, el año y la técnica. Cada cartel lo diseña una persona, de la que interesa su nombre, su promoción y su web. Los carteles se muestran en exposiciones, de las que se guarda el nombre, el lugar y la fecha de inicio. Un cartel puede estar en varias exposiciones."

 ┌─────────┐ 1          N ┌─────────┐ N                M ┌─────────────┐
 │  Autor  │──< diseña >──│ Cartel  │──< se expone en >──│ Exposición  │
 └─────────┘              └─────────┘                    └─────────────┘
  id (clave)               id (clave)                     id (clave)
  nombre                   titulo                         nombre
  promocion                anio                           lugar
  web                      tecnica                        fecha_inicio

Hay tres reglas que resuelven casi todos los casos:

1. Cada entidad es una tabla, con sus atributos como columnas y la clave como clave primaria.
2. Relación 1:N: la tabla del lado N recibe una clave foránea que apunta al lado 1. (El cartel guarda autor_id.)
3. Relación N:M: se crea una tabla intermedia con las claves de las dos entidades (y los datos propios de la relación, si los hay).

Aplicadas al ejemplo:

autores      (id, nombre, promocion, web)
carteles     (id, titulo, anio, tecnica, autor_id → autores.id)
exposiciones (id, nombre, lugar, fecha_inicio)
expone       (cartel_id → carteles.id, exposicion_id → exposiciones.id)

La tabla expone tiene una fila por cada "este cartel estuvo en esta exposición". Si interesa en qué sala se colgó, sala sería un campo de expone: es un dato de la relación, no del cartel ni de la exposición.

Normalizar es repasar el diseño para que ningún dato se repita sin necesidad. Señales de alarma:

• El mismo texto aparece en muchas filas (el nombre y la web de la autora en cada cartel) → otra tabla y una clave foránea.
• Un campo guarda varias cosas separadas por comas (tecnicas: "serigrafía, collage") → otra tabla o una tabla intermedia.
• Un campo que se puede calcular (la edad a partir de la fecha de nacimiento) → no se guarda.

• Papel y lápiz: perfecto para empezar.
• draw.io (diagrams.net): gratuito, en el navegador, con formas de E/R.
• Excalidraw: aspecto de boceto a mano, rápido.

Haz el modelo E/R y el paso a tablas de estos casos:

1. Una tienda de láminas: láminas (título, precio, tamaño), artistas y categorías. Una lámina tiene una artista y puede estar en varias categorías.
2. Un festival de diseño: charlas, ponentes y salas. Una charla puede tener varios ponentes y se da en una sala a una hora.
3. Tu portfolio: proyectos, clientes y herramientas.

• Confundir entidades con atributos: la técnica, ¿es un texto del cartel o una entidad con más datos (descripción, imagen)? Depende de si necesitas esos datos.
• Olvidar la tabla intermedia en las relaciones N:M.
• Poner la clave foránea en el lado equivocado de una 1:N (va en el lado N).
• Elegir como clave un dato que puede repetirse o cambiar (el nombre, el correo).
• Diseñar sin leer bien el enunciado: la cardinalidad sale del caso real.