Dlaczego wiele projektów ignoruje normalizację w RDBMS?

Widziałem wiele projektów, w których normalizacja nie była pierwszym czynnikiem branym pod uwagę na etapie podejmowania decyzji.

W wielu przypadkach projekty te zawierały ponad 30 kolumn, a głównym podejściem było „umieszczenie wszystkiego w tym samym miejscu”

Według tego, co pamiętam, normalizacja jest jedną z pierwszych, najważniejszych rzeczy, więc dlaczego czasami tak łatwo ją upuszcza?

Edytować:

Czy to prawda, że ​​dobrzy architekci i eksperci wybierają projekt zdenormalizowany, a niedoświadczeni programiści wybierają coś przeciwnego? Jakie są argumenty przeciwko rozpoczęciu projektowania z myślą o normalizacji?

Interesujące w tym wątku pytania i odpowiedzi jest to, że w rzeczywistości są 3 pytania. Każdy odpowiedział na inny i prawie nikt nie odpowiedział na pierwszy:

1. Dlaczego nie są niektóre bazy danych w środowisku naturalnym znormalizowane?
2. Dlaczego / kiedy powinna być znormalizowana w bazie nieznormalizowana ?
3. W jakich sytuacjach normalizacja jest szkodliwa lub niepotrzebna?

Alert czytelnicy zauważą, że są to bardzo różne pytania, i postaram się odpowiedzieć na każde z nich osobno, unikając zbyt wielu szczegółów. Przez „zbyt wiele” mam na myśli to, że nie uważam, aby był to odpowiedni kontekst, w którym należy prowadzić dłuższą debatę na temat zalet różnych argumentów za lub przeciw normalizacji; Po prostu wyjaśnię, jakie są te argumenty, może wymienię kilka zastrzeżeń i zachowam filozofię na bardziej szczegółowe pytania, jeśli kiedykolwiek się pojawią.

Ponadto w tej odpowiedzi zakładam , że „normalizacja” implikuje „BCNF, 3NF lub co najmniej 2NF” , ponieważ taki poziom normalizacji zwykle zamierzają osiągnąć projektanci. Rzadziej można zobaczyć konstrukcje 4NF lub 5NF; chociaż z pewnością nie są celami niemożliwymi, zajmują się semantyką relacji, a nie tylko ich reprezentacją , co wymaga znacznie większej wiedzy na temat dziedziny.

A więc dalej i wyżej:

1. Dlaczego niektóre bazy danych na wolności nie są znormalizowane?

Odpowiedź na to może być „ponieważ nie powinny”, ale przyjęcie tego założenia od samego początku jest dość kiepską pracą detektywistyczną. Jako społeczeństwo nie osiągnęlibyśmy wielkiego postępu, gdybyśmy zawsze działali w oparciu o założenie, że cokolwiek jest, powinno być.

Rzeczywiste powody, dla których bazy danych nie podlegają normalizacji, są bardziej skomplikowane. Oto top 5, z którymi się spotkałem:

• Programiści, którzy go zaprojektowali, nie wiedzieli lub nie rozumieli, jak normalizować. Mocnym dowodem na to jest wiele innych towarzyszących złych wyborów projektowych, takich jak stosowanie kolumn varchar do wszystkiego lub spaghetti bałaganu o bezsensownych nazwach tabel i kolumn . Zapewniam cię, że widziałem „prawdziwe” bazy danych, które są tak samo złe, jak te w artykułach TDWTF.

• Deweloperzy, którzy go zaprojektowali, nie dbali o to lub zasadniczo czynnie sprzeciwiali się normalizacji . Uwaga: tutaj nie mówię o przypadkach, w których podjęto świadomą decyzję, aby nie normalizować na podstawie analizy kontekstowej, ale raczej zespoły lub firmy, w których normalizacja jest mniej lub bardziej rozumiana, ale po prostu ignorowana lub odrzucana z przyzwyczajenia. Znowu zaskakująco powszechne.

• Oprogramowanie zostało / zostało wykonane jako projekt Brownfield . Wielu purystów ignoruje ten całkowicie uzasadniony biznes, a nie techniczną przyczynę braku normalizacji. Czasami tak naprawdę nie możesz zaprojektować nowej bazy danych od zera, musisz skorzystać z istniejącego starszego schematu, a próba normalizacji w tym momencie wymagałaby zbyt dużego bólu. 3NF został wynaleziony dopiero w 1971 r., A niektóre systemy - zwłaszcza systemy finansowo-księgowe - mają swoje korzenie jeszcze dalej!

• Baza danych była pierwotnie znormalizowana , ale nagromadzenie małych zmian w długim okresie czasu i / lub szeroko rozpowszechniony zespół wprowadził subtelne formy powielania i inne naruszenia jakiejkolwiek normalnej formy, która pierwotnie istniała. Innymi słowy, utrata normalizacji była przypadkowa i zbyt mało czasu poświęcono na refaktoryzację.

• Podjęto świadomą decyzję biznesową, aby nie tracić czasu na analizę biznesową lub projektowanie baz danych i po prostu „zrobić to”. Jest to często fałszywa ekonomia i ostatecznie staje się rosnącą formą długu technicznego , ale czasami jest racjonalną decyzją, przynajmniej opartą na informacjach, które były wówczas znane - na przykład baza danych mogła być zaprojektowana jako prototyp, ale ostatecznie awans do wykorzystania produkcyjnego z powodu ograniczeń czasowych lub zmian w otoczeniu biznesowym.

2. Dlaczego / kiedy należy znormalizować znormalizowaną bazę danych?

Ta dyskusja często pojawia się, gdy baza danych jest normalizowana na początek. Albo wydajność jest niska, albo jest dużo powielania zapytań (dołączeń), a zespół czuje, słusznie lub niesłusznie, że posunął się tak daleko, jak to możliwe przy obecnym projekcie. Ważne jest, aby pamiętać, że normalizacja poprawia wydajność przez większość czasu i istnieje kilka opcji, aby wyeliminować nadmierne sprzężenia, gdy normalizacja wydaje się działać przeciwko tobie, z których wiele jest mniej inwazyjnych i ryzykownych niż zwykła zmiana na model zdormalizowany:

• Utwórz indeksowane widoki zawierające najczęstsze obszary problemów. Nowoczesne systemy DBMS umożliwiają ich wstawianie lub aktualizowanie (np. INSTEAD OFWyzwalacze programu SQL Server ). Wynika to z niewielkim kosztem instrukcji DML w bazowych tabelach / indeksach, ale ogólnie jest pierwszą opcją, którą powinieneś wypróbować, ponieważ jest prawie niemożliwe, aby zepsuć i prawie nic nie kosztuje. Oczywiście nie każde zapytanie można przekształcić w widok indeksowany - zapytania zagregowane są najbardziej kłopotliwe. Co prowadzi nas do następnego elementu ...

• Utwórz zdenormalizowane tabele agregatów, które są automatycznie aktualizowane przez wyzwalacze. Tabele te istnieją oprócz tabel znormalizowanych i stanowią rodzaj modelu CQRS . Innym popularniejszym obecnie modelem CQRS jest użycie pub / sub do aktualizacji modeli zapytań, co daje korzyść asynchronii, chociaż może to nie być odpowiednie w bardzo rzadkich przypadkach, w których dane nie mogą być nieaktualne.

• Czasami widoki indeksowane nie są możliwe, stawki transakcji i woluminy danych są zbyt wysokie, aby dopuszczać wyzwalacze o akceptowalnej wydajności, a zapytania zawsze muszą zwracać dane w czasie rzeczywistym. Te sytuacje są rzadkie - zaryzykuję przypuszczenie, że mogą dotyczyć takich transakcji jak transakcje o wysokiej częstotliwości lub bazy danych organów ścigania / wywiadu - ale mogą istnieć. W takich przypadkach naprawdę nie masz innej opcji, jak denormalizować oryginalne tabele.

3. W jakich sytuacjach normalizacja jest szkodliwa lub niepotrzebna?

Istnieje tutaj kilka dobrych przykładów:

• Jeśli baza danych jest używana tylko do raportowania / analizy. Zazwyczaj oznacza to , że dla OLTP używana jest dodatkowa , znormalizowana baza danych, która jest okresowo synchronizowana z bazą danych analizy za pośrednictwem ETL lub wiadomości.

• Egzekwowanie znormalizowanego modelu wymagałoby niepotrzebnie złożonej analizy przychodzących danych. Przykładem może być system, który musi przechowywać numery telefonów zebrane z kilku systemów zewnętrznych lub bazy danych. Państwo mogłoby denormalize kod wywoławczy i numeru kierunkowego, ale trzeba by uwagę wszystkich różnych możliwych formatach, nieprawidłowych numerów telefonów, numerów vanity (1-800-GET-stuff), nie wspominając o różnych lokalizacjach. Zwykle jest to więcej kłopotów niż jest to warte, a numery telefonów są zwykle po prostu umieszczane w jednym polu, chyba że potrzebujesz konkretnej potrzeby biznesowej, aby samodzielnie wybrać numer kierunkowy.

• Gdy relacyjna baza danych jest przede wszystkim w celu zapewnienia obsługi transakcji dla dodatkowej, nierelacyjnej bazy danych. Na przykład możesz używać relacyjnej bazy danych jako kolejki komunikatów lub do śledzenia statusu transakcji lub sagi, gdy podstawowe dane są przechowywane w Redis, MongoDB lub czymkolwiek. Innymi słowy, dane to „dane kontrolne”. Normalizacja danych, które nie są danymi biznesowymi , zwykle nie ma sensu .

• Architektury zorientowane na usługi, które współużytkują fizyczną bazę danych. Jest to trochę dziwne, ale w prawdziwym SOA czasami będziesz musiał fizycznie zduplikować dane, ponieważ usługi nie mogą bezpośrednio nawiązywać zapytań o dane. Jeśli zdarzy się, że współużytkują tę samą fizyczną bazę danych, wydaje się , że dane nie są znormalizowane - ale ogólnie dane posiadane przez poszczególne usługi są nadal znormalizowane, chyba że istnieje jeden z innych czynników łagodzących. Na przykład usługa fakturowania może być właścicielem podmiotu wystawiającego rachunek, ale usługa rachunkowości musi otrzymać i przechowywać datę i kwotę rachunku, aby uwzględnić ją w przychodach za dany rok.

Jestem pewien, że jest więcej powodów, których nie wymieniłem; W gruncie rzeczy mam na myśli to, że są one dość specyficzne i będą dość oczywiste, kiedy pojawią się w praktyce. Baz danych OLAP są niby do schematów użycie gwiezdnych, SOA są powinien mieć jakąś powielania itd Jeśli pracujesz z dobrze znanego modelu architektury, które po prostu nie działa z normalizacją, wtedy nie normalizować; ogólnie rzecz biorąc, model architektury ma pierwszeństwo przed modelem danych.

I aby odpowiedzieć na ostatnie pytanie:

Czy to prawda, że ​​dobrzy architekci i eksperci wybierają projekt zdenormalizowany, a niedoświadczeni programiści wybierają coś przeciwnego? Jakie są argumenty przeciwko rozpoczęciu projektowania z myślą o normalizacji?

Nie, to kompletne i kompletne BS To również BS, że eksperci zawsze wybierają znormalizowany projekt. Eksperci nie tylko przestrzegają mantry. Badają, analizują, dyskutują, wyjaśniają i iterują, a następnie wybierają takie podejście, które najbardziej odpowiada ich konkretnej sytuacji.

Baza danych 3NF lub BCNF jest zwykle dobrym punktem wyjścia do analizy, ponieważ została wypróbowana i udowodniona, że ​​odnosi sukcesy w dziesiątkach tysięcy projektów na całym świecie, ale z drugiej strony, podobnie jak C., to nie znaczy, że automatycznie używamy C w każdym nowy projekt. Rzeczywiste sytuacje mogą wymagać pewnych modyfikacji modelu lub zastosowania innego modelu. Nie wiesz, dopóki nie znajdziesz się w takiej sytuacji.

Założeniem wbudowanym w pytanie i w niektórych odpowiedziach jest to, że normalizacja jest synonimem dobrego projektu bazy danych. W rzeczywistości często tak nie jest. Normalizacja jest jednym ze sposobów osiągnięcia określonego zestawu celów projektowych i wymogiem, jeśli polegasz w dużej mierze na bazie danych w celu egzekwowania „reguł biznesowych” dotyczących relacji między elementami danych.

Normalizacja daje kilka kluczowych korzyści:

1. Minimalizuje ilość nadmiarowych danych.
2. Maksymalizuje zakres, w jakim wbudowane mechanizmy integralności bazy danych (ograniczenia klucza obcego, ograniczenia unikatowości) mogą być wykorzystane do zapewnienia integralności danych.
3. Zmniejsza liczbę kolumn na wiersz, zwiększając w niektórych przypadkach wydajność IO. Pobieranie szerokich rzędów trwa dłużej.

To powiedziawszy, istnieje wiele ważnych powodów do denormalizacji:

1. Wydajność, szczególnie w przypadku analiz, może zostać osłabiona przez normalizację. W przypadku analizy z relacyjnymi bazami danych normalne są modele zdenormalizowane .
2. Korzyści z wymuszania integralności danych w bazie danych zaczynają maleć. Ponieważ coraz więcej prac rozwojowych koncentruje się na obiektowej warstwie pośredniej, która często egzekwuje reguły biznesowe, poleganie na relacyjnych ograniczeniach w bazie danych jest mniej ważne.
3. Jak wspomnieli inni, normalizacja skomplikuje zapytania wymagane do odzyskania odpowiednich danych.

Nie jest jasne, czy normalizacja jest oznaką dobrego projektu. W niektórych przypadkach normalizacja jest artefaktem czasu, w którym przestrzeń dyskowa była na wagę złota, a duża część odpowiedzialności za kodowanie reguł biznesowych spoczywała w bazie danych (pomyśl o dwuwarstwowych aplikacjach klient-serwer z większością, jeśli nie całą logiką biznesową) procedury przechowywane). Może się zdarzyć, że wiele projektów odwróci się od normalizacji w oparciu o dobre decyzje architektoniczne zamiast słabego zrozumienia zasad projektowania baz danych.

Artykuł Jeffa Atwooda, do którego odwołują się powyższe komentarze, zapewnia dobrą szczegółową dyskusję - „Może normalizacja nie jest normalna” .

1. Wielu programistów nie wie ani nie dba o normalizację, modelowanie danych czy bazę danych.
2. W przypadku niektórych prac nie jest to naprawdę ważne.
3. Czasami istnieje naprawdę dobry powód do znormalizowania, na przykład aby sprawić, by szczególnie trudne obciążenie działało dobrze.
4. Koncepcje relacyjnych baz danych są ostatnio mniej modne niż w latach 90. i 2000. Deweloperzy wydają się być pod wpływem mody, nawet jeśli twierdzą, że są bardzo racjonalni. Nie ma sensu kłócić się o smak.

Normalizacja jest również historycznie obszarem dla prawie religijnych sporów, więc waham się powiedzieć coś więcej.

W dużych projektach, a zwłaszcza w komputerach mainframe, tak nie jest. W rzeczywistości, jeśli przeszukujesz witryny z ofertami pracy, zobaczysz kilka stanowisk dla projektantów danych. Ponadto posiadanie wielu kolumn w jednej tabeli nie jest sprzeczne z normalizacją. Niemniej twoja obserwacja dotyczy niektórych projektów.

Projektowanie baz danych jest jedną z umiejętności wymaganych do budowania systemów jakości. To powiedziawszy, niektórzy programiści nie wiedzą wystarczająco dużo o projektowaniu baz danych i nadal przypisują się do zadań związanych z modelowaniem danych i projektowaniem baz danych. Niektóre projekty pomijają nawet modelowanie danych. Wiele projektów koncentruje się głównie na kodowaniu i projektowaniu front-end.

Innym czynnikiem słabego projektu bazy danych jest fakt, że Normalizacja nie jest trywialnym tematem, szczególnie jeśli chodzi o 4. NF, 5. NF itp. Większość książek, które widziałem, nie potrafiła dobrze wyjaśnić tych form. Zwykle są złe przykłady i zbyt dużo teorii. To sprawia, że ​​temat jest mniej popularny niż powinien.

Błędy w projekcie bazy danych są trudne do znalezienia, chyba że ich szukasz lub napotkasz je podczas testowania. Brak standardu jakości projektowania baz danych pozwala na bardziej prawdopodobne błędy.

Dodaj do tego fakt, że niektóre projekty nie przestrzegają rygorystycznej metodologii programistycznej (takiej, która promuje projektowanie baz danych), w wyniku czego obowiązki mieszają się, a zadania giną między analitykiem biznesowym, programistami i DBA. Programiści mówią w OO i UML, podczas gdy DBA mówią w DD, a niektórzy w ERD i prawdopodobnie wielu nie dostaje UML lub OO. Krótko mówiąc, winą jest brak wiedzy, brak dobrych, przejrzystych zasobów, brak jednolitego języka do opisu danych oraz brak metodologii.