Firmy gromadzą i przechowują dużą ilość danych zawierających informacje o profilu biznesowym np. sprzedaż, współpraca z kontrahentami, zasoby w magazynach, podaż i ceny produktów. Oczywistym faktem jest to, że dane nie mogą być dowolnie zlokalizowane w systemach baz danych. W tej sytuacji konieczne jest prawidłowe zaprojektowanie relacyjnej bazy danych. Dobrze zaprojektowana relacyjna baza danych charakteryzuje się tym, że wszystkie niezbędne informacje w segmentach biznesowych firmy są jasno i czytelnie udokumentowane oraz łatwe w regularnym użyciu.
Jednym ze sposobów intuicyjnego skonstruowania relacyjnej bazy danych jest normalizacja. Jest to proces organizowania danych w bazie danych, który polega na tworzeniu tabel, które reprezentują unikalny segment działalności firmy (taki jak dostawcy lub klienci) oraz ustalanie relacji między tymi tabelami poprzez wyeliminowanie redundancji i niespójnej zależności. Jednocześnie normalizację można traktować jako cel w fazie projektowania relacyjnej bazy danych.
Czasami jednak zdarzają się sytuacje, w których konieczne jest odejście od tej reguły i może zaistnieć potrzeba przeprowadzenia tzw. denormalizacji bazy danych.
Co to jest denormalizacja bazy danych?
Krótko mówiąc, denormalizacja bazy danych to połączenie znormalizowanych tabel w jedną. Jest to wdrożenie kontrolowanej redundancji do bazy danych w celu przyspieszenia jej działania. W wyniku posiadania dużej ilości danych w tabelach relacyjnych łączenie tych tabel w celu uzyskania informacji potrzebnych dla Twojej firmy może stać się zbyt kosztowne. Dlatego jednym z rozwiązań jest krzyżowanie klawiszy lub kolumn między tabelami, które są dość często łączone.
W związku z tym tabela docelowa zawiera nie tylko istotne dla niej dane, ale także informacje z innych tabel. Oczywiście to rozwiązanie wiąże się z możliwością nadmiarowości danych w tabelach, co z kolei prowadzi do szybkiego wzrostu ich wielkości. Częstym objawem jest możliwość duplikacji danych.
Z tego punktu widzenia denormalizacja bazy danych wydaje się być rodzajem kompromisu. Podczas gdy w przypadku normalizacji bazy danych celem jest uproszczenie jej do maksymalnej formy tabel, które są niezależnie odpowiedzialne za każdy obszar podmiotu danych, denormalizacja jest przypisana do specyfiki przeglądania tych danych i nie można tego uniwersalnie zdefiniować dla każdego przypadku. Jego efektywne funkcjonowanie musi być zdefiniowane w oparciu o potrzeby biznesowe. Jeśli chcesz wiedzieć, jak prawidłowo go wdrożyć odwiedź naszą Doradztwo w zakresie inżynierii danych strony
Denormalizacja bazy danych — zalety i wady.
W przypadku szybkiego wzrostu ilości danych w bazie danych denormalizacja przynosi wymierne korzyści, ale ma kilka wad. Przedstawimy kilka z nich:
Zalety denormalizacji bazy danych:
- Zwiększona szybkość wykonywania zapytań.
Ponieważ nie ma potrzeby używania połączeń między tabelami, możliwe jest wyodrębnienie niezbędnych informacji z jednej tabeli, co automatycznie zwiększa szybkość wykonywania zapytań. Dodatkowo to rozwiązanie oszczędza pamięć.
- Pisanie zapytań jest znacznie łatwiejsze.
Jeśli tabela jest odpowiednio zreorganizowana dla najczęstszych potrzeb, możesz wyodrębnić dane tylko z jednej tabeli i nie tracić czasu na szukanie kluczy połączenia. Należy jednak pamiętać o nadmiarowości danych i odpowiednio zaktualizować zapytanie.
- Nie ma potrzeby pozyskiwania danych z tabel słownikowych, w których wartości są stałe w czasie.
Tabele ze słownikami krajowymi są dobrymi przykładami. Jeśli firma działa na określonej liczbie rynków światowych, niepotrzebne wydaje się ciągłe łączenie się z tabelą słownika z krajami. W takim przypadku warto dodać kolumnę z nazwą kraju do, na przykład, tabeli sprzedaży.
- Możliwość dodawania danych zagregowanych, które można wykorzystać do bardziej wydajnego raportowania.
Pewne statystyki, takie jak liczba działań sprzedażowych, średnia sprzedaż itp., Są bardzo potrzebne do analizy różnych obszarów działalności firmy. Dlatego łatwiej jest zdefiniować kluczowe statystyki i uwzględnić je w jednej tabeli niż pobierać je poprzez łączenie wielu tabel.
- Zmniejszenie liczby tabel w relacyjnej bazie danych.
W przypadku złożonej architektury relacyjnej bazy danych uzyskanie danych z wielu tabel może być trudne. Jeśli baza danych jest odpowiednio denormalizowana, liczba tych tabel może zostać skutecznie zmniejszona, a co za tym idzie, można uprościć architekturę bazy danych.
Wady denormalizacji bazy danych:
- Zwiększony rozmiar cenowy.
Ze względu na nadmiarowość danych i ewentualne powielanie danych zwiększa się wielkość przetwarzania zapytań.
- Zwiększone rozmiary stołów.
W wyniku denormalizacji bazy danych tabela może znacznie zwiększyć swój rozmiar, co może być związane z obciążeniem przestrzeni dyskowej.
- Zwiększone koszty aktualizacji tabel i wkładek.
W tabeli, w której dane przeszły redundancję z powodu denormalizacji bazy danych, aktualizacja danych może stanowić problem. Załóżmy na przykład, że dodana została dodatkowa kolumna zawierająca dane o adresie klienta. Aktualizacja tych danych może być uciążliwa i kosztowna, jeśli klient zmieni adres. Jeśli baza danych jest znormalizowana, aktualizacja może odbywać się tylko w tabeli słownika po znacznie niższych kosztach. Podobnie jest z wkładkami. Ze względu na nadmiarowość danych w wyniku łączenia wielu tabel, uzyskanie wielu danych dla jednej tabeli może być uciążliwe.
- Dane mogą być niespójne.
Przed wykonaniem zapytania należy dokładnie zapoznać się z tabelą i wziąć pod uwagę powielanie danych. Zapytanie, które wydostanie niezbędne dane bez ryzyka niespójności danych, powinno być kompleksowo przygotowane.
Denormalizacja bazy danych - przykłady.
- Kolumny ze zagregowanymi danymi.
Załóżmy, że baza danych zawiera tabele reklamodawców, sprzedaży i kampanii. Do celów raportowania wyników reklamodawców istnieje potrzeba policzenia kampanii i kolumny sprzedaży dla każdego reklamodawcy. Możliwe jest dodanie do dodatkowych kolumn w tabeli reklamodawców, które liczą liczbę kampanii i wielkość sprzedaży. W wyniku tej transformacji nie ma potrzeby pobierania tych danych z tabel sprzedaży i kampanii za każdym razem za pomocą funkcji liczenia.
- 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.
Jeśli chcesz wiedzieć, w jaki sposób te rozwiązania mogą pomóc Twojej firmie, skontaktuj się z nami.Sprawdź nasz blog, aby uzyskać więcej informacji na temat inżynierii danych:
