Normalisation · Normalização
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 que normalizar?
Imagine armazenar cada reserva de clube em uma tabela, com o treinador repetido em cada linha: cada reserva do clube de Xadrez carregaria "Mr Ng" uma e outra vez.
Essa repetição causa problemas. Se Mr Ng sair, você deve atualizar muitas linhas; se perder uma, os dados tornam-se inconsistentes. A Normalização organiza tabelas para remover esse tipo de redundância.
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.
As formas normais
Você normaliza em etapas:
- 1NF — cada célula contém um único valor (sem listas ou grupos repetidos), e a tabela tem uma chave primária.
- 2NF — já é 1NF, e nenhuma coluna não-chave depende apenas de parte de uma chave composta.
- 3NF — já é 2NF, e nenhuma coluna não-chave depende de outra coluna não-chave (nenhuma dependência transitiva).
Na versão de uma tabela, coach depende da club, não da reserva — uma dependência transitiva, portanto não está em 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.
O projeto normalizado
Dividimos os dados em duas tabelas (as carregadas aqui):
club(club_id, name, coach)— cada clube e seu treinador, armazenados uma única vez.booking(booking_id, student, club_id)— cada reserva, ligada pela chave estrangeiraclub_id.
Agora um treinador é armazenado uma única vez. Um JOIN junta as informações de volta sempre que você precisar — escreva aquele join abaixo.
Common mistakes
- Split repeating groups into their own table instead of many similar columns.
- Each table should describe one kind of thing.
Erros comuns
- Divida grupos repetidos em sua própria tabela em vez de muitas colunas similares.
- Cada tabela deve descrever um tipo de coisa.
Reassemble the data: list each booking's student next to their club's coach, by joining booking to · até club on club_id, ordered by booking.booking_id. · Reassemble os dados: liste a student de cada reserva ao lado do clube da sua coach, juntando booking a club em club_id, ordenado por booking.booking_id.
Click Run to see the output here. · Clique em Executar para ver a saída aqui.
The split tables still answer questions together. Count how many bookings each club has: join booking to · até club, show club.name and · e COUNT(*) AS bookings, group by the club, and order by club.name. · As tabelas divididas ainda respondem a perguntas juntas. Conte quantas inscrições cada clube tem: junte booking a club, exiba club.name e COUNT(*) AS bookings, agrupe pelo clube e ordene por club.name.
Click Run to see the output here. · Clique em Executar para ver a saída aqui.