Normalisation · Normalización
Why normalise?
Imagine storing every club booking in one table, with the coach repeated on every row: each booking of the Chess club would carry "Mr Ng" again and again.
That repetition causes problems. If Mr Ng leaves, you must update many rows; miss one and the data becomes inconsistent. Normalisation organises tables to remove this kind of redundancy.
¿Por qué normalizar?
Imagina almacenar cada reserva de un club en una sola tabla, con el nombre del entrenador repetido en cada fila: cada reserva del club de ajedrez llevaría "Sr. Ng" una y otra vez.
Esa repetición causa problemas. Si el Sr. Ng se va, debes actualizar muchas filas; si te saltas una, los datos quedan inconsistentes. La normalización organiza las tablas para eliminar este tipo de redundancia.
The normal forms
You normalise in steps:
- 1NF — every cell holds a single value (no lists or repeating groups), and the table has a primary key.
- 2NF — already 1NF, and no non-key column depends on only part of a composite key.
- 3NF — already 2NF, and no non-key column depends on another non-key column (no transitive dependency).
In the one-table version, coach depends on the club, not on the booking — a transitive dependency, so it is not in 3NF.
Las formas normales
Normalizas paso a paso:
- 1NF — cada celda contiene un solo valor (sin listas ni grupos repetitivos), y la tabla tiene una clave primaria.
- 2NF — ya es 1NF, y ninguna columna que no sea clave depende de solo parte de una clave compuesta.
- 3NF — ya es 2NF, y ninguna columna que no sea clave depende de otra columna que no sea clave (no hay dependencia transitiva).
En la versión de una sola tabla, coach depende de club, no de la reserva — una dependencia transitiva, por lo tanto no está en 3NF.
The normalised design
We split the data into two tables (the ones loaded here):
club(club_id, name, coach)— each club and its coach, stored once.booking(booking_id, student, club_id)— each booking, linked by the foreign keyclub_id.
Now a coach is stored once. A JOIN puts the information back together whenever you need it — write that join below.
El diseño normalizado
Dividimos los datos en dos tablas (las que se cargan aquí):
club(club_id, name, coach)— cada club y su entrenador, almacenados una sola vez.booking(booking_id, student, club_id)— cada reserva, vinculada mediante la clave foráneaclub_id.
Ahora un entrenador se almacena una sola vez. Un JOIN vuelve a unir la información siempre que la necesites — escribe ese join a continuación.
Common mistakes
- Split repeating groups into their own table instead of many similar columns.
- Each table should describe one kind of thing.
Errores comunes
- Dividir los grupos repetitivos en su propia tabla en lugar de tener muchas columnas similares.
- Cada tabla debe describir un solo tipo de cosa.
Reassemble the data: list each booking's student next to their club's coach, by joining booking to · hasta club on club_id, ordered by booking.booking_id. · Reensamblar los datos: listar el student de cada reserva junto con el coach de su club, uniendo booking a club en club_id, ordenado por booking.booking_id.
Click Run to see the output here. · Haz clic en Ejecutar para ver la salida aquí.
The split tables still answer questions together. Count how many bookings each club has: join booking to · hasta club, show club.name and · y COUNT(*) AS bookings, group by the club, and order by club.name. · Las tablas divididas aún responden preguntas juntas. Contar cuántas reservas tiene cada club: unir booking a club, mostrar club.name y COUNT(*) AS bookings, agrupar por el club, y ordenar por club.name.
Click Run to see the output here. · Haz clic en Ejecutar para ver la salida aquí.