Pierwszą zasadą jest nawyk minimalizacji rozmiaru danych przechowywanych w bazie danych. Zrealizowanie tego punktu polega, najprościej mówiąc, na redukowaniu zbędnych danych oraz zapewnieniu ich integralności. Przechowywanie tych samych danych w jednym miejscu, w jednym rekordzie minimalizuje szanse, że jakaś wersja tej danej będzie niepoprawna. A jeśli nawet w trakcie jej użytkowania dojdzie do tego, że któraś wartość zostanie niepoprawnie wprowadzona, zostanie ona wyświetlona we wszystkich miejscach w ten sam sposób, przez co łatwiejsze będzie wychwycenie błędu.

Drugim aspektem, na który warto zwrócić uwagę, jest rozłożenie większych zbiorów danych na mniejsze, powiązane ze sobą elementy. Podział na mniejsze tabele, a następnie relacyjne ich połączenie sprawi, że nie usuniemy przez przypadek danej, którą uważaliśmy za niepotrzebną, a która – jak się okazuje – ma powiązania z innym elementem. Jeśli cała baza danych podzielona jest na mniejsze części, to jeśli zajdzie potrzeba przywrócenia jakiegoś jej elementu, nie trzeba będzie przywracać całej bazy danych, a wystarczy kawałek, w którym znajduje się ten element.  Dodatkowo, aby zapewnić lepszą integralność danych niezbędne jest zdefiniowanie, jaki typ danych chcemy przechowywać w danej kolumnie. Chodzi o to, żeby uniemożliwić wpisanie litery tam, gdzie jakaś wartość przyjmuje tylko liczbową postać, co uczyni już na starcie bazę danych bardziej poprawną, a to z kolei podniesie jej integralność.

Wiemy już, jakie cechy powinien posiadać dobry projekt, a więc zajmijmy się przez chwilę tabelami i określaniem pól, z których się ona składa. Zacznijmy od tego, że tabela jest zbiorem informacji na jeden określony temat. Dzięki tej cesze jesteśmy w stanie przetwarzać jedno zagadnienie niezależnie od danych dotyczących innych zagadnień. Na przykład, jeśli wyobrazimy sobie bazę danych sklepu, to adresy klientów przechowywalibyśmy w innej tabeli, niż informacje na temat zamówień. W ten sposób możliwe jest usunięcie konkretnego zamówienia, zachowując dane o kliencie nie zmienione. Jeśli właśnie w taki sposób określimy tabele, to w następnym kroku możemy zabrać się za określanie pól w tabeli. Pole zawiera więc jedną daną dotyczącą tego zagadnienia, któremu poświęcona jest tabela. Dobrym nawykiem podczas definiowania pól jest pamiętanie o tym, aby:

• przechowywać informacje w możliwie najmniejszych jednostkach logicznych (np. imię i nazwisko jako osobne pola, a nie jako jedno pole – nazwa użytkownika),
• nie należy tworzyć pól zawierających dane pośrednie lub obliczone (dane, które są wynikiem wyrażenia, uzyskuje się za pomocą kwerend, ale nie przechowuje się bezpośrednio w bazie danych – jest to zły nawyk),
• każde pole powinno być powiązane bezpośrednio z zagadnieniem, którego dotyczy tabela.

Po zakończeniu określania zawartości kolumn w każdej tabeli możemy przystąpić do wyboru klucza podstawowego.
Klucz podstawowy służy do powiązania informacji przechowywanych w różnych tabelach. Na przykład, aby powiązać klienta ze wszystkimi jego zamówieniami, każda tabela w bazie danych musi zawierać pole lub zbiór pól, które jednoznacznie określają każdy wiersz w tej tabeli (po to, żeby np. określić jednoznacznie danego klienta lub konkretne zamówienie). Kluczem podstawowym nie mogą być duplikujące się wartości, takie jak imiona czy nazwiska, ponieważ takie dane mogą się powtórzyć. Unikatowym natomiast może być numer produktu czy zamówienia. Zazwyczaj rolę klucza podstawowego odgrywa dowolny unikatowy numer, a służy on wyłącznie do identyfikowania danego produktu czy zamówienia. Numer ten zostaje określony raz i nigdy się nie zmienia dla danego produktu, co sprawia, że jednoznacznie go określa.

Kiedy wszystko wydaje się już praktycznie gotowe, oznacza to, że przyszedł czas na udoskonalanie projektu. W tym kroku będziemy sprawdzać, jak sprawują się jego poszczególne elementy. Uzupełniamy tabele o przykładowe dane, a na ich podstawie wykonujemy próbne operacje, tworzymy kwerendy, dodajemy nowe rekordy itp. Dzięki temu będziemy w stanie zlokalizować potencjalne problemy. Może okazać się, że w tabelach występują zduplikowane dane, że istnieje niepotrzebna tabela lub zastosowaliśmy złą relację do ich połączenia. Przed nami dokładne sprawdzenie projektu pod kątem wszelkich błędów. Warto stworzyć robocze wersje raportów czy formularzy i sprawdzić, czy generują one odpowiednie dane. Wychodząc z założenia, że nie myli się jedynie ten kto nic nie robi, prawdopodobnie w naszym projekcie nie unikniemy początkowych błędów. Ażeby zmaksymalizować funkcjonalność bazy danych, warto odpowiedzieć sobie na szereg pytań, które mogą wydać się trywialne, ale kto wie, czy nie zaoszczędzą nam wiele czasu przy wyszukiwaniu usterki, kiedy po wdrożeniu aplikacji okaże się, że jednak coś nie działa. Warto również wrócić do początkowego szkicu z kartki papieru i sprawdzić, na ile odpowiada on obecnemu projektowi. Przykładowe pytania mogą wyglądać np. tak:

• Czy nie zapomniałem jakiejś kolumny? Jeśli tak, to czy jestem w stanie ją wrzucić do już istniejącej tabeli? Jeśli tak, to świetnie, a jeśli nie – to trzeba będzie dodać nową tabelę i na nowo przeanalizować jej powiązania z innymi tabelami.
• A może któraś kolumna jest zbędna? Jeśli tak, to po jej usunięciu zaoszczędzimy trochę cennego miejsca.
• Czy przypadkiem informacji zawartych w tej kolumnie nie mogę obliczyć na podstawie innych tabel? Jeśli tak, po co je duplikować? Zazwyczaj lepiej jest obliczać te wartości, stosując np. kwerendy (jeśli to tylko możliwe), niż tworzyć nową kolumnę.
• Czy wszystkie informacje rozbiłem na najmniejsze, użyteczne części? Wiadomo przecież, że nie ma sensu rozbijać np. nazwy produktu „Wąż od pralki” na trzy kolumny: „Wąż” „od” „pralki” albo na węża i pralkę, bo to jedynie skomplikuje naszą bazę danych. Jeśli ten aspekt jest dopracowany, możemy śmiało tworzyć raporty, sortować i wyszukiwać.
• Czy wszystkie kolumny danej tabeli rzeczywiście zawierają informacje dotyczące dokładnie tematu tej tabeli? Jeśli nie, to dla porządku oraz uniknięcia problemów w przyszłości należy taką kolumnę przenieść do innej tabeli.

Ostatnim etapem weryfikacji poprawności projektu bazy danych jest sprawdzenie, czy umożliwia ona wszystkie podstawowe funkcje:

• projektowanie rekordów:
  • nazwa pola,
  • długość pola,
  • rodzaj pola (tekstowe, liczbowe, logiczne),
• edycja (dopisywanie, usuwanie, poprawianie rekordów),
• sortowanie,
• wyszukiwanie i selekcja danych,
• tworzenie zapytań,
• tworzenie raportów,
• drukowanie.