Kiedy należy denormalizować?

Myślę, że wszyscy znamy normalizację baz danych .

Moje pytanie brzmi: z jakich wskazówek korzystasz, kiedy chcesz denormalizować tabele?

Denormalizuj, gdy są to operacje OLAP, normalizuj, kiedy OLTP (z połączonego artykułu w sekcji Denormalizacja)

Bazy danych przeznaczone do przetwarzania transakcji online (OLTP) są zwykle bardziej znormalizowane niż bazy danych przeznaczone do przetwarzania transakcji online (OLAP). Aplikacje OLTP charakteryzują się dużą liczbą małych transakcji, takich jak aktualizacja rejestru sprzedaży w kasie w supermarkecie. Oczekuje się, że każda transakcja pozostawi bazę danych w spójnym stanie. Natomiast bazy danych przeznaczone do operacji OLAP są przede wszystkim bazami „głównie do odczytu”. Aplikacje OLAP mają tendencję do wydobywania danych historycznych, które gromadziły się przez długi czas. W przypadku takich baz danych nadmiarowe lub „zdenormalizowane” dane mogą ułatwiać aplikacjom analizy biznesowej. W szczególności tabele wymiarowe w schemacie gwiazdy często zawierają dane zdenormalizowane. Zdenormalizowane lub nadmiarowe dane muszą być dokładnie kontrolowane podczas przetwarzania, ekstrakcji, transformacji, ładowania (ETL), a użytkownicy nie powinni mieć dostępu do danych, dopóki nie będą w spójnym stanie. Znormalizowaną alternatywą dla schematu gwiazdy jest schemat płatka śniegu. W wielu przypadkach potrzeba denormalizacji zmniejszyła się, gdy komputery i oprogramowanie RDBMS stały się bardziej wydajne, ale ponieważ wolumeny danych ogólnie wzrosły wraz z wydajnością sprzętu i oprogramowania, bazy danych OLAP często nadal używają zdormalizowanych schematów.

Denormalizacja służy również do poprawy wydajności na mniejszych komputerach, takich jak w komputerowych kasach fiskalnych i urządzeniach mobilnych, ponieważ mogą one wykorzystywać dane tylko do wyszukiwania (np. Wyszukiwania cen). Denormalizacji można również użyć, gdy nie ma RDBMS dla platformy (takiej jak Palm) lub nie ma potrzeby wprowadzania żadnych zmian w danych, a szybka reakcja ma kluczowe znaczenie.

Normalizuj, aż boli, denormalizuj, aż działa (tj .: wydajność staje się akceptowalna) :)

Jednym z potencjalnie rozsądnych powodów zastosowania kontrolowanej denormalizacji jest to, że pozwala ona zastosować pewne ograniczenie integralności do danych, które w innym przypadku nie byłoby możliwe. Większość SQL DBMS ma bardzo ograniczone wsparcie dla ograniczeń wielu tabel. W SQL czasami jedynym skutecznym sposobem implementacji pewnych ograniczeń jest upewnienie się, że atrybuty związane z ograniczeniem są obecne w tej samej tabeli - nawet jeśli normalizacja dyktuje, że należą one do oddzielnych tabel.

Kontrolowana denormalizacja oznacza, że ​​mechanizmy są wdrażane w celu zapewnienia, że ​​niekonsekwencje nie mogą powstać z powodu nadmiarowych danych. Przy podejmowaniu decyzji, czy denormalizacja jest opłacalna, należy wziąć pod uwagę koszt tych dodatkowych kontroli i ryzyko niespójności danych.

Innym częstym powodem denormalizacji jest dopuszczenie pewnych zmian w strukturach pamięci lub innej fizycznej optymalizacji, na którą DBMS inaczej nie pozwoliłby. Zgodnie z zasadą niezależności danych fizycznych DBMS powinien dysponować środkami do konfiguracji wewnętrznych struktur pamięci bez niepotrzebnej zmiany logicznej reprezentacji danych w bazie danych. Niestety wiele DBMS bardzo ogranicza możliwości fizycznej implementacji dostępne dla dowolnego schematu bazy danych. Zwykle zagrażają niezależności fizycznej bazy danych, obsługując jedynie nieoptymalną implementację pożądanego modelu logicznego.

Powinno to być oczywiste, ale nadal trzeba powiedzieć: we wszystkich przypadkach zmiany w fizycznych funkcjach implementacyjnych mogą decydować o wydajności - takich jak wewnętrzne struktury danych, pliki, indeksowanie, sprzęt i tak dalej. Normalizacja i denormalizacja nie mają nic wspólnego z optymalizacją wydajności lub pamięci masowej.

Wykonaj normalizację, jeśli często uzyskujesz dostęp do danych obliczeniowych, jak sugerują odpowiedzi na to pytanie . Koszt przechowywania i utrzymywania obliczonych danych będzie często niższy niż koszt ponownego ich obliczania w kółko, jeśli Twój profil obciążenia jest obciążony odczytem.

Rutynowo denormalizuję, aby móc egzekwować integralność danych z ograniczeniami. Jednym z przykładów jest ostatnie pytanie na tej stronie - replikuję kolumnę w innej tabeli, dzięki czemu mogę użyć ograniczenia CHECK, aby porównać ją z inną kolumną. Innym przykładem tej techniki jest mój post na blogu .

Nie można używać wiązań CHECK do porównywania kolumn w różnych wierszach lub w różnych tabelach, chyba że zawinie się taką funkcjonalność w skalarnych UDF wywoływanych z ograniczenia CHECK. Co zrobić, jeśli faktycznie chcesz porównać kolumny w różnych wierszach lub w różnych tabelach, aby wymusić regułę biznesową? Załóżmy na przykład, że znasz godziny pracy lekarza i chcesz się upewnić, że wszystkie spotkania mieszczą się w godzinach pracy? Oczywiście możesz użyć wyzwalacza lub procedury przechowywanej do wdrożenia tej reguły biznesowej, ale ani wyzwalacz, ani procedura przechowywana nie dają 100% gwarancji, że wszystkie twoje dane są czyste - ktoś może wyłączyć lub upuścić twój wyzwalacz, wprowadzić niektóre brudne dane i ponownie włącz lub ponownie uruchom wyzwalacz. Również ktoś może bezpośrednio zmodyfikować tabelę, omijając procedury składowane.

Pokażę, jak wdrożyć tę regułę biznesową przy użyciu tylko ograniczeń FK i CHECK - to zagwarantuje, że wszystkie dane spełniają regułę biznesową, o ile wszystkie ograniczenia są zaufane.

Jeszcze innym przykładem jest sposób egzekwowania, aby okresy nie miały luk ani nakładania się .