Projektowanie relacyjnej bazy danych to proces przejścia od potrzeb użytkownika do poprawnego schematu tabel. Logiczna kolejność działań wynika z zależności między elementami modelu.
Najpierw określa się zbiór danych, czyli identyfikuje, jakie obiekty (encje) i cechy (atrybuty) mają być przechowywane. Bez tego nie wiadomo, jakie tabele i kolumny są w ogóle potrzebne.
Kolejny krok to selekcja/wybór informacji istotnych z punktu widzenia wymagań (np. odrzucenie danych zbędnych lub zdublowanych na etapie analizy). Ten etap można rozumieć jako doprecyzowanie zakresu danych, zanim zacznie się je formalnie modelować.
Następnie wyznacza się klucze podstawowe tabel, czyli atrybuty (lub zestawy atrybutów) jednoznacznie identyfikujące rekord. Jest to kluczowe dla spójności danych i późniejszego wiązania tabel.
Dopiero potem określa się relacje między tabelami (1:1, 1:N, N:M). W praktyce relacje w modelu relacyjnym realizuje się przez klucze obce oraz (dla N:M) tabele pośrednie. Gdyby próbować definiować relacje przed kluczami, łatwo popełnić błąd: nie ma stabilnej podstawy do wskazania, które atrybuty mają pełnić rolę identyfikatorów i odwołań.
Dlaczego pozostałe kolejności są problematyczne? Ustawianie relacji na samym początku pomija etap ustalenia, jakie dane w ogóle istnieją. Z kolei dobór kluczy podstawowych przed identyfikacją zbioru danych oznacza wybór identyfikatorów dla tabel, których struktura nie jest jeszcze ustalona. Rozpoczynanie od selekcji lub relacji bez kontekstu analizy wymagań sprzyja projektowi niepełnemu, redundantnemu lub niespójnemu pod względem integralności referencyjnej.
