Kiedy normalizacja nie ma sensu ?

Cześć wszystkim,
Zagłębiam się ostatnio w temacie optymalizacji baz danych na etapie projektowania. Na uczelni cała nauka skupiała się na normalizacji do 3. postaci... Tymczasem z tego co czytam w internecie w przypadku większości baz często denormalizuje się niektóre tabele żeby uniknąć nadmiaru join'ów itp.

Pierwszy przykład jaki mi przyszedł do głowy to np schemat bazy prezentującej zależności między sezonami i rozgrywkami w piłce nożnej.
Przykładowo w encji sezon nazwa to 2000/2001, w encji rozgrywka będziemy mieli rekordy Ekstraklasa, Puchar Polski, a w encji relacja_część będą rekordy typu 1.kolejka, 1/16 finału itd

Poniżej widać schemacik moim zdaniem znormalizowany :P 2 tabele słownikowe (rozgrywka i rozgrywka_czesc) i 2 tabele asocjacyjne. Unikniemy w ten sposób redundancji itp...

Pytanie tylko, czy do tak prostego rozwiązania potrzebne jest tyle tabel ?
Zakładam że w żadnej z tych tabel nie będę miał więcej niż 500 rekordów. W poniższym schemacie usunąłem jedną tabele asocjacyjną. Z nowego połączenia będzie wynikać mały problem, polegający na tym że co sezon będę musiał dodawać rozgrywkę np: ekstraklasa więc dane się powtórzą, ale uniknę kilka joinów. W starym rozwiązaniu jeśli korzystałbym z encji sezon_rozgrywki potrzebował bym dwóch joinów, a po usunięciu tabeli asocjacyjnej i dodatkowej zmianie atrybutu nazwa w sezonie na pk mogę otrzymać praktycznie te same dane bez żadnego joina. Do tabeli rozgrywka będzie w tej sytuacji przybywać powiedzmy 10 rekordów rocznie więc to żaden ciężar.

Podsumowując, jest jakaś złota reguła jeśli chodzi o denormalizację, kiedy warto ją stosować ?

Pozdrawiam i z góry dzięki za pomoc ;)

Teoria sobie a praktyka sobie. Często spłaszcza się strukturę po to żeby uzyskać lepszą wydajność. Zmniejsza to ilość złączeń co przy dużej ilości danych ma znaczenie.

Trzy najpopularniejsze przypadki gdy używamy denormalizacji:

1. uproszczenie modelu - w przypadku gdy normalizacja wprowadza np. niepotrzebne tabele łączące.
2. wydajność - gdy chcemy uniknąć wielu operacji JOIN po kolumnach bez indeksu albo jawnych powiązań (JOIN po kolumnie nie będącej kluczem obcym)
3. raportowanie i tworzenie widoków zmaterializowanych - w momencie gdy docelowy model będzie przetwarzany w określony sposób można pokusić się o stworzenie widoku zmaterializowanego, który z natury jest zdenormalizowany, by później móc w łatwy sposób przetwarzać dane.