Co to jest baza danych i dlaczego ma być normalna?

Czytamy sobie dokument, w którym napisane jest, że system będzie posiadał 3 bazy danych: jedną OLTP i dwie OLAP. Myślimy sobie od razu, że pewnie to jakiś wielki system za grube miliony. Jakież jest nasze zdziwienie, gdy okazuje się, że to mały “systemik”, a każda baza ma tak naprawdę po 3 tabele. Nasuwa się od razu pytanie — po co ta cała komplikacja? Czyż nie uczono nas na studiach, że baza ma być jedna i to w 3. postaci normalnej i dzięki temu wszyscy będą żyli długo i szczęśliwie?

Otóż nie. Błąd (mój w tym wypadku) polegał na użyciu terminu “baza danych”, w miejsce prawidłowego “magazyn danych”. Baza danych kojarzy się jednoznacznie z bardzo konkretnym fizycznym bytem żyjącym na serwerze RDBMS: ma przypisane pliki, w których przechowywane są dane, swój log transakcyjny itp.

Magazyn danych jest natomiast tworem czysto logicznym. Jest on dla mnie tak bardzo użyteczny, ponieważ definiując architekturę systemu dbam właśnie o logiczną organizację danych:

• granice między obszarami o transakcyjnej (ACID) integralności danych
• sposób reprezentacji danych

Mogę także umieścić dowolnie wiele logicznych magazynów danych na jednym serwerze bazodanowym, a nawet w jednej fizycznej bazie. Czemu nie! Przynajmniej na początku, kiedy nie wiadomo, czy system będzie potrzebował dodatkowej wydajności.

Dane, które nie muszą być aktualizowane w sposób transakcyjny mogą zostać przypisane do różnych logicznych obszarów integralności. W granicach tych obszarów wszelkie operacje zachowują charakterystykę ACID. Pomiędzy obszarami semantyka ACID nie jest zachowana. Możemy liczyć jedynie na możliwość przesyłania komunikatów. Dzięki temu, w razie potrzeby, możemy poszczególne obszary ulokować na różnych fizycznych maszynach i cała operacja będzie przeźroczysta dla systemu.

Czy konieczność przesyłania komunikatów jest dla mnie bolesna? W żadnym razie! Pierwsza wersja może być po prostu wyposażona w “zaślepkę”, która realizuje asynchroniczne przesyłanie komunikatów synchronicznie. Takie rozwiązanie znalazło się m.in. w projekcie DDDSample (zarówno oryginalnym, jak i moim porcie).

W ramach poszczególnych obszarów dane mogą mieć różną organizację. Moim drugim błędem było użycie terminu “OLAP” w odniesieniu do dwóch z proponowanych “baz”. Termin ten jednoznacznie kojarzy się z hurtowniami danych. Tak naprawdę chodziło mi jedynie o sposób reprezentacji danych relacyjnych specyficzny dla zastosowań OLAP — denormalizację oraz schematy gwiazdowe (śnieżynkowe). Nie trzeba wcale w oparciu o te dane budować wielowymiarowej kostki — wystarczy, że będę potrzebował zrobić kilka bardziej skomplikowanych zapytań i już trud włożony w budowę osobnej struktury raportowej zwróci się z nawiązką.

Z drugiej strony reprezentacja danych transakcyjnych także nie jest kwestią banalną. Bardzo wiele można zyskać jeszcze na poziomie modelowania, gdzie, poprzez odpowiednie przekształcenia, możemy np. wyeliminować potrzebę aktualizacji istniejących danych (na korzyść dodawania nowych).

Podsumowując:

• wiele logicznych magazynów danych nikomu nie szkodzi
• podobnie asynchroniczna komunikacja
• rozwiązania rodem z OLAP (denormalizacja i schemat gwiazdy) są przydatne także w prostszych zastosowaniach
• największą poprawę wydajności systemu bazodanowego można uzyskać na poziomie modelu, a nie samej bazy danych

Co o tym sądzicie?