1. Zasada pojedynczej odpowiedzialności encji

Każda tabela powinna reprezentować jeden, jasno zdefiniowany byt (encję) w modelu danych.
(Jedna tabela = jeden typ rzeczy, np. klienci osobno, produkty osobno)

2. Zasada eliminacji redundancji danych

Dane nie powinny być przechowywane wielokrotnie w różnych miejscach, o ile nie jest to uzasadnione wydajnością.
(Nie kopiuj tych samych danych w wielu miejscach – to się później rozjeżdża)

3. Zasada normalizacji (co najmniej do 3NF)

Struktura bazy powinna spełniać wymagania trzeciej postaci normalnej, eliminując zależności przechodnie i częściowe.
(Podziel dane tak, żeby nie było bałaganu i ukrytych powiązań)

• 1NF – Pierwsza postać normalna
  Każde pole = jedna konkretna wartość, żadnych list w komórkach
• 2NF – Druga postać normalna
  Jeśli klucz jest złożony, to wszystkie dane muszą zależeć od CAŁEGO klucza, a nie tylko jego części
• 3NF – Trzecia postać normalna (najważniejsza)
  Kolumny nie mogą zależeć od innych kolumn – tylko od klucza głównego

4. Zasada atomowości atrybutów

Każda kolumna powinna przechowywać wartości niepodzielne (atomowe), a nie złożone struktury.
(Nie wrzucaj list typu „a,b,c” do jednej kolumny)

5. Zasada jednoznacznej identyfikacji

Każda tabela powinna posiadać klucz główny jednoznacznie identyfikujący każdy rekord.
(Każdy wiersz musi mieć swoje unikalne ID)

6. Zasada integralności referencyjnej

Relacje między tabelami powinny być wymuszane poprzez klucze obce.
(Powiązania między tabelami mają być pilnowane przez bazę, nie „na słowo”)

7. Zasada jawnego modelowania relacji

Relacje typu wiele-do-wielu powinny być realizowane poprzez tabelę pośrednią.
(Jeśli coś łączy się z wieloma rzeczami – robisz dodatkową tabelę)

8. Zasada minimalizacji NULL

Kolumny powinny dopuszczać wartości NULL tylko wtedy, gdy jest to semantycznie uzasadnione.
(Nie zostawiaj pustych pól bez powodu)

9. Zasada spójności typów danych

Typy danych powinny być dobrane adekwatnie do przechowywanej informacji.
(Nie zapisuj liczb jako tekst – to proszenie się o problemy)

10. Zasada niezależności danych od logiki aplikacji

Struktura bazy danych powinna być projektowana niezależnie od konkretnej implementacji aplikacyjnej.
(Baza ma mieć sens sama w sobie, nie tylko „bo tak działa kod”)

11. Zasada przewidywania rozszerzalności

Projekt powinien umożliwiać przyszłą rozbudowę bez konieczności gruntownych zmian struktury.
(Myśl do przodu – system prawie na pewno się rozrośnie)

12. Zasada separacji danych operacyjnych i wyliczanych

Dane wyliczalne nie powinny być przechowywane, jeśli mogą być obliczone na podstawie innych danych.
(Nie zapisuj czegoś, co możesz policzyć)

13. Zasada spójności nazewnictwa

Nazwy tabel i kolumn powinny być jednoznaczne, konsekwentne i zgodne z przyjętą konwencją.
(Nazwy mają być czytelne i spójne – nie „x1”, „dane2”)

Najważniejsza meta-zasada

Model danych powinien odzwierciedlać rzeczywistość biznesową, a nie przypadkową strukturę techniczną.
(Baza ma odzwierciedlać prawdziwy świat, nie być „jakimś zbiorem tabel”)

Zadanie

Na kolejnych stronach są błędne struktury. Popraw je.