Projektowanie bazy danych zaczyna się od określenia celu (jakie informacje mają być przechowywane i do czego będą używane). Bez tego nie da się sensownie dobrać encji/obiektów świata rzeczywistego ani atrybutów.
Kolejny krok to zaprojektowanie tabel (w praktyce: wstępny schemat relacyjny), czyli decyzja, jakie zbiory danych będą osobnymi tabelami, jakie pola znajdą się w każdej z nich oraz jaki będzie klucz główny. Na tym etapie powstaje "szkielet" struktury danych.
Następnie ustala się relacje między tabelami, co w relacyjnych bazach danych oznacza m.in. dobranie kluczy obcych oraz typu powiązań (1:1, 1:N, N:M realizowane tabelą pośrednią). To etap krytyczny dla integralności danych i poprawnego działania zapytań oraz aplikacji internetowej korzystającej z bazy.
Na końcu wykonuje się normalizację jako uporządkowanie i dopracowanie projektu: eliminowanie redundancji i typowych anomalii (wstawiania, usuwania, aktualizacji) przez odpowiedni podział danych na tabele oraz poprawę zależności funkcyjnych. W wielu ujęciach teoretycznych normalizacja jest częścią projektu logicznego i bywa opisywana wcześniej niż "fizyczne" tworzenie tabel w SQL, ale w praktyce szkolnej spotyka się podejście iteracyjne: najpierw szkic tabel i relacji, potem normalizacja jako etap rafinacji.
Pozostałe propozycje są błędne, bo umieszczają normalizację przed zdefiniowaniem sensownego układu tabel lub relacji, albo sugerują tworzenie relacji przed ustaleniem tabel, co jest nielogiczne (relacja musi łączyć konkretne tabele/klucze). Częsty błąd uczniów polega na traktowaniu normalizacji jak całkowicie niezależnego, "magicznego" kroku, zamiast procesu, który wynika z projektu i zależności między danymi.
