Firmy gromadzą i przechowują duże ilości danych, które zawierają informacje o profilu działalności, np. sprzedaż, współpraca z kontrahentami, zasoby w magazynach, ceny dostaw i produktów. Oczywistym faktem jest, że dane nie mogą być umieszczane w systemach bazodanowych w sposób arbitralny. W tej sytuacji konieczne jest odpowiednie zaprojektowanie relational database. Dobrze zaprojektowana relational database charakteryzuje się tym, że wszystkie niezbędne informacje w segmentach działalności firmy są jasno i czytelnie udokumentowane oraz łatwe w regularnym użytkowaniu.
Jednym ze sposobów intuicyjnego konstruowania relational database jest normalization. Jest to proces organizowania danych w bazie danych, który obejmuje tworzenie tables, które reprezentują unikalny segment działalności firmy (takie jak vendors lub customers) i ustawianie relationship między tymi tables poprzez eliminację redundancy i inconsistent dependency. Jednocześnie normalization może być traktowana jako cel w fazie projektowania relational database.
Czasami jednak zdarzają się sytuacje, w których konieczne jest odstąpienie od tej zasady i może zaistnieć potrzeba przeprowadzenia tzw. Database Denormalization.
Czym jest database denormalization?
W skrócie, database denormalization to połączenie znormalizowanych tables w jeden. Jest to implementacja kontrolowanej redundancy do bazy danych w celu przyspieszenia operacji na niej. W wyniku posiadania dużej ilości danych w relational tables, łączenie tych tables w celu uzyskania informacji potrzebnych do prowadzenia działalności może stać się zbyt kosztowne. Dlatego jednym z rozwiązań jest sprawdzanie krzyżowe keys lub columns między tables, które są łączone dość często.
W konsekwencji target table zawiera nie tylko dane do niej należące, ale także informacje z innych tables. Oczywiście, to rozwiązanie wiąże się z możliwością data redundancy w tables, co z kolei prowadzi do szybkiego wzrostu ich rozmiaru. Częstym objawem jest możliwość data duplications.
Z tego punktu widzenia database denormalization wydaje się być rodzajem kompromisu. O ile w przypadku database normalization celem jest uproszczenie jej do maksymalnej formy tables, które są niezależnie odpowiedzialne za każdy obszar danych, o tyle denormalization jest przypisana do specyfiki przeglądania tych danych i nie można jej zdefiniować uniwersalnie dla każdego przypadku. Jej sprawne funkcjonowanie musi być zdefiniowane w oparciu o business needs. Jeśli chcesz wiedzieć, jak to poprawnie wdrożyć, odwiedź naszą stronę Data Engineering Consultancy.
Database denormalization – zalety i wady
W przypadku gwałtownego wzrostu ilości danych w bazie danych, denormalization przynosi wymierne korzyści, ale ma też kilka wad. Przedstawmy kilka z nich:
Zalety Database denormalization:
- Increased query execution speed.
Ponieważ nie ma potrzeby używania joins między tables, możliwe jest wydobycie potrzebnych informacji z jednego table, co automatycznie zwiększa szybkość query execution. Dodatkowo to rozwiązanie oszczędza pamięć. - Writing queries is much easier.
Jeśli table jest odpowiednio zreorganizowany pod kątem najczęstszych potrzeb, można wydobywać dane tylko z jednego table i nie tracić czasu na szukanie join keys. Należy jednak pamiętać o data redundancy i odpowiednio aktualizować query. - No need to obtain data from dictionary tables, gdzie wartości są stałe w czasie.
Tables ze słownikami krajów są dobrym przykładem. Jeśli firma działa na stałej liczbie rynków światowych, wydaje się niepotrzebne ciągłe wykonywanie joins z dictionary table z krajami. W takim przypadku warto dodać column z nazwą kraju do, na przykład, sales table. - Ability to add aggregate data, które mogą być wykorzystywane do bardziej efficient reporting.
Pewne statystyki, takie jak liczba akcji sprzedażowych, średnia sprzedaż itp., są bardzo potrzebne do analizy różnych obszarów działalności firmy. Dlatego łatwiej może być zdefiniować key statistics i umieścić je w jednym table niż pobierać je poprzez łączenie wielu tables. - Reduction of the number of tables w relational database.
W przypadku złożonej relational database architecture, uzyskiwanie danych z wielu tables może być trudne. Jeśli database jest odpowiednio denormalizowana, liczba tych tables może być skutecznie zredukowana, a co za tym idzie, database architecture może być uproszczona.
Wady Database denormalization:
- Increased processing size.
Ze względu na data redundancy i możliwe data duplication, rozmiar query processing wzrasta. - Increased table sizes.
W wyniku denormalization database, table może znacznie zwiększyć swój rozmiar, co może wiązać się z obciążeniem przestrzeni dyskowej. - Increased costs of updating tables and inserts.
W table, w którym dane uległy redundancy w wyniku database denormalization, aktualizacja danych może stanowić problem. Załóżmy na przykład, że dodano dodatkowy column, który zawiera dane o adresie klienta. Aktualizacja tych danych może być uciążliwa i kosztowna, jeśli klient zmieni adres. Jeśli database jest znormalizowana, aktualizacja może być wykonana tylko w dictionary table przy znacznie niższych kosztach. Podobnie jest z inserts. Ze względu na redundancy danych w wyniku łączenia wielu tables, uzyskanie wielu danych dla jednego table może być uciążliwe. - Data may be inconsistent.
Przed wykonaniem query konieczne jest dokładne zapoznanie się z table i uwzględnienie data duplication. Query, które wydobędzie niezbędne dane bez ryzyka data inconsistency, powinno być kompleksowo przygotowane.
Database denormalization – przykłady
- Columns with aggregated data.
Załóżmy, że database ma tables advertisers, sales i campaigns. Do celów reporting advertiser results, istnieje potrzeba zliczenia campaigns i sales column dla każdego advertiser. Możliwe jest dodanie dodatkowych columns w advertisers table, które zliczają liczbę campaigns i sales volume. W wyniku tej transformacji nie ma potrzeby pobierania tych danych z sales i campaigns tables za każdym razem za pomocą count functions. - Dictionary tables.
W tym przykładzie w database znajdują się dwa tables: countries i customers. Jedną z potrzeb firmy jest badanie customers i countries z punktu widzenia sales effectiveness, dlatego joins są regularnie wykonywane między tables: customers i countries. Aby ograniczyć częste łączenie tych dwóch tables, można dodać dodatkowy column do customer table – country name. - Create a new table that meets business needs.
Załóżmy, że istnieje częsta potrzeba wydobywania danych z wielu tables. Przy odpowiednim zdefiniowaniu business needs, możliwe jest stworzenie table, które zredukuje processing size i time regularnych joins.
- Tabele słownikowe.
W tym przykładzie w bazie danych znajdują się dwie tabele: kraje i klienci. Jedną z potrzeb firmy jest badanie klientów i krajów z punktu widzenia efektywności sprzedaży, dlatego połączenia są bardzo cenione między tabelami: klientami i krajami. Aby ograniczyć częste łączenie tych dwóch tabel, do tabeli klientów można dodać dodatkową kolumnę — nazwę kraju.
- Utwórz nową tabelę, która spełnia potrzeby biznesowe.
Załóżmy, że często istnieje potrzeba wyodrębniania danych z wielu tabel. Przy odpowiedniej definicji potrzeb biznesowych możliwe jest stworzenie tabeli, która zmniejszy rozmiar przetwarzania i czas regularnych połączeń. Wróćmy do pierwszego przykładu. Załóżmy, że firma chce regularnie wyodrębniać dane dotyczące szczegółów sprzedaży, takie jak kampanie lub reklamodawcy z pełnymi nazwiskami. W tym celu możliwe jest utworzenie tabeli, która będzie zawierała wszystkie niezbędne dane w tabeli sprzedaży. W takich tabelach firma może pobierać niezbędne dane bez konieczności regularnego łączenia wielu tabel.
Wróćmy do pierwszego przykładu. Załóżmy, że firma chce regularnie wydobywać sales details data, takie jak campaigns lub advertisers z pełnymi nazwami. W tym celu można stworzyć table, które będzie zawierać wszystkie niezbędne dane w sales table. W takim table business może pobierać niezbędne dane bez konieczności regularnego łączenia wielu tables.
Jeśli chcesz wiedzieć, w jaki sposób te rozwiązania mogą pomóc Twojej firmie, skontaktuj się z nami.
Stream processing vs batch processing przewodnik
