Tym razem znowu obiektowe analiza i projektowanie. Na stronie SQL albo NoSQL, oto jest pytanie pojawiła się ciekawa wypowiedź. Jako, że osobiście „idę w kierunku” obiektowych systemów gdzie dane są indywidualną cechą obiektów a nie super-centralnym składowiskiem  pozwolę sobie na dywagacje. Proszę ich nie traktować jako „prawdę w moim wydaniu”, jest to raczej moje obecne postrzeganie tego zagadnienia. Wypowiedzi autora wskazanego tekstu wcięte.

No dobra, korzystając z baz NoSQL zyskujemy lepszą skalowalność, brak sztywnego schematu bazy danych, sporą elastyczność, mniej problemów z mapowaniem danych w bazie do obiektów zdefiniowanych w kodzie i pewnie jeszcze kilka rzeczy, o których nie mam pojęcia. Ale pojawiają się ograniczenia. Czasem bardzo istotne. Po pierwsze bazy NoSQL nie są relacyjne. Może i jest to oczywiste, ale chyba nie wszyscy tak do końca zdają sobie sprawę, co to tak na prawdę oznacza. Całą obsługę relacyjności pomiędzy danymi (jeśli jest nam potrzebna) trzeba emulować w kodzie aplikacji, na wbudowane w bazę danych rozwiązania nie ma co liczyć.

Zarzut, że bazy NoSQL nie są relacyjne jest dla tych baz raczej komplementem. Kluczowym tu stwierdzeniem torpedującym w moich oczach wywód jest uznanie faktu, że relacyjność może nie być potrzebna. Owszem, dodam nawet, że nie raz po prostu ciąży. Po drugie moim zdaniem błędne jest stwierdzenie, że relacyjność należy emulować w kodzie. Otóż nie, bo może być po prostu niepotrzebna!.

Po drugie często brak JOINów. […] Potrafi to bardzo utrudnić pisanie wydajnych zapytań, a przecież rozliczany jestem z każdej milisekundy pracy procesora.

Kolejny moim zdaniem błąd w myśleniu: długie, wymagające optymalizacji, skomplikowane zapytania są właśnie cechą zapytań do baz relacyjnych. Bazy relacyjne, po dokonaniu normalizacji, w zasadzie żadnej informacji nie trzymają w jednym kawałku, wszystko wymaga posklejania przed użyciem. Pozyskanie treści zwykłej faktury z takiej bazy, wymaga posklejania jej z dziesiątek składowych tablic i słowników,  wymaga to faktycznie nie lada sztuki w napisaniu zapytania do bazy a co dopiero taki raport faktur sprzedaży z poprzednich okresów.

Dlaczego o tym piszę? Otóż jednym z większych, w moich oczach, problemów jest wykształcenie projektantów i programistów. Nie, nie. Nie twierdze że jest złe, po protu nadal na wyższych uczelniach na kierunkach informatyki przedmioty takie jak analiza i modelowanie obiektowe w relacji do klasycznych zajęć w rodzaju programowanie w Pascalu, C++ i modelowanie relacyjnych baz danych to pyłek w programie nauczania.

Troszkę wyjaśnień

Relacyjne bazy danych (RDBMS) to w ogólnym sensie, po ludzku, dane uporządkowane w powtarzające się struktury trwale z sobą powiązane. Jedna z definicji spotykanych w sieci:

W najprostszym ujęciu w modelu relacyjnym dane grupowane są w relacje, które reprezentowane są przez tablice. Relacje są pewnym zbiorem rekordów o identycznej strukturze wewnętrznie powiązanych za pomocą związków zachodzących pomiędzy danymi. Relacje zgrupowane są w tzw. schematy bazy danych. Relacją może być tabela zawierająca dane teleadresowe pracowników, zaś schemat może zawierać wszystkie dane dotyczące firmy. Takie podejście w porównaniu do innych modeli danych ułatwia wprowadzania zmian, zmniejszenie możliwość pomyłek, ale dzieje się to kosztem wydajności. (źr. http://pl.wikipedia.org/wiki/Model_relacyjny)

Jak to wygląda w praktyce. Postaram się to pokazać na nas samych. Wyobraźmy sobie strukturę organizacyjną firmy i jej pracowników. Normalną rzeczą jest, że każdy z nas zna Nazwisko przełożonego, wie jakich ma (jeśli ma) podwładnych, zna nazwę swojego stanowiska, zna nazwę działu, w którym pracuje i pamięta nazwę firmy, która go zatrudnia. Ogólnie mamy te dane w głowie (prędzej czy później się tego nauczyliśmy). Niewątpliwie jeżeli ktoś ma dziesięcioro podwładnych, to każdy z nich ma w głowie (w pamięci) komplet tych danych, zostały więc powielone 10-krotnie. Marnotrawstwo kory mózgowej zespołu?!. Nie, po prostu ewolucja dawno temu odkryła, że pewne dane należy mieć do użycia ad-hoc u siebie bo w naturze liczy się natychmiastowy dostęp do tych danych (informacji) a nie oszczędność szarych komórek danej populacji.

Tak więc nazwisko podwładnego znam na pamięć, a co gdy potrzebuje jego adres? Czy muszę wkuwać to wszystko na pamięć? Nie, bo rzadko z tego korzystam! Muszę tylko wiedzieć tylko gdzie jest dział kadr, tam są kartoteki pracowników. Idę do Pani/Pana i proszę o teczkę personalną osoby XXX i dostaję, a tam mam wszystko. Przepisuje (powielam!) na kopertę adres do korespondencji, oddaję teczkę personalną i wracam do swojego biurka, pisze list, zaklejam kopertę i wysyłam. To model obiektowy świata, dane – wyłącznie niezbędne – są przechowywane w naszych głowach nierelacyjnie, reszta ma swoje miejsca, wystarczy że wiem gdzie są, w razie potrzeby o nie poproszę.

A teraz inny model. Jedyne co wiemy o sobie to to, że jesteśmy na tym świecie (znamy tylko swoje nazwisko i imię), wszystko inne: nasi podwładni, przełożeni, nazwy departamentów, itp. to tylko niteczki prowadzące do zapisów o nich. Nie wiem nic o sobie, jak ktoś zapyta kto jest moim szefem muszę złapać za niteczkę o nazwie przełożony i zobaczyć co jest na jej końcu. Jak mnie ktoś zapyta kto jest moim prezesem, po tych niteczkach, jak domino, będą brnęli moi przełożeni aż na szczyt hierarchii zatrudnienia i powiedzą mi, dopiero kto jest moim prezesem. Jeżeli jestem szefem, to mam dodatkowo tyle niteczek do paska ilu mam podwładnych, nie znam żadnego z nich, za każdym razem by wskazać któregokolwiek muszę pociągnąć za wszystkie niteczki, wybrać jednego z nich i dopiero dać mu robotę. Tak wygląda model relacyjny. Tak zwana normalizacja danych polega na tym, że jeżeli jakakolwiek informacja miała by się powtórzyć w czyjejś głowie, to odbieramy mu te informację, tworzymy karteczkę, na której ją zapisujemy i niteczkami te karteczkę podpinamy do każdego komu te informacje odebraliśmy. Każda taka karteczka to prosty słowniczek gdzie każdy zapis jest powiązany niteczką ze wszystkim czego dotyczy. Tak więc jak mnie ktoś zapyta gdzie pracuję to zamiast z głowy natychmiast odpowiedzieć muszę pociągnąć za niteczkę Pracodawca i zobaczyć co tam jest napisane przy mojej niteczce (a jest ich tam nie mało). Owszem, nazwa pracodawcy będzie tylko raz zapisana, prawdopodobnie uzyskamy ogromne oszczędności miejsca na zapisy ale też ogromnie skomplikujemy i wydłużymy dostęp do informacji.

Jak widać, pozyskanie jakiejkolwiek informacji z relacyjnego repozytorium to dość karkołomny zabieg. Do tego taki system ma jeszcze jedną wadę: jak już raz wymyślimy jakie to mają być karteczki, jak je ze sobą pospinamy niteczkami, zapiszemy je, i nazbiera się nam tego, to system staje w zasadzie już niemodyfikowalny. Jak się przytrafi sytuacja, w której dostaniemy jakieś informacje ze źródła, w którym te karteczki choć troszkę inaczej zostały wymyślone (co jest prawie pewne) to mamy poważny problem. Nie da się tego zapisać w naszym systemie wprost, musimy posklejać tę cudza wiedzę i na nowo rozebrać na małe karteczki ale już po naszemu.

Po co więc wymyślono te relacyjne bazy? To były czasy gdy pamięć była najkosztowniejszym zasobem komputera zaś dane między systemami w zasadzie nie były wymieniane! Było kilka zalet, np. brak błędów nazewnictwa itp. więcej o nich w sieci można poczytać, jednak moim zdaniem baza danych będąca implementacją tak zwanych związków pojęciowych (tym są relacyjne modele danych) nie sprawdza się bo nie modeluje obiektów świata rzeczywistego a jedynie ich nazwy i powiązania między nimi a to ogromna różnica.

A co dzisiaj mamy

Dzisiaj mamy: wiele różnych systemów w każdej firmie, powszechną wymianę danych wewnątrz firmy i między firmami oraz najgorsze czyli zmienność środowiska biznesowego. Co mogę poradzić?

Jeżeli planujesz wdrożenie gotowego systemu opartego na relacyjnej bazie pamiętaj, że:

– etap jego wdrażania i parametryzacji to ostatni moment na decyzje  o strukturze informacji, potem praktycznie już nie da się tego zmienić

– jeżeli w trakcie analizy wykryjesz w swojej firmie jakieś szybkozmienne obszary, zamiast inwestować w kolejny moduł dużego systemu ERP, zleć napisanie dedykowanego podsystemu w nowszej technologii i zintegruj go z tym ERP

– jeżeli dostawca ERP powie Ci, że integracja czegokolwiek z tym system wymaga dużej i kosztownej pracy nie kupuj tego systemu.

Tak wiec zanim wybierzemy system ERP wyobraźmy sobie, że wdrożenie zmusi nas do przeniesienia naszej wiedzy z głów na małe karteczki, zmusi nas do powiązania tego wszystkiego setkami niteczek, pogodzenia się z tym, że dopóki będziemy mieli ten system niewiele będziemy mogli później w tym wszystkim cokolwiek zmienić. Jedną z poważniejszych wad systemów zintegrowanych jest to, że są zintegrowane gdyż nadal większość z nich to integracja poprzez współdzielenie danych.

Co robić? Moim zdaniem warto po prostu dobrze się nad tym wszystkim zastanowić, ocenić różne warianty i na końcu dopiero wybrać system ERP i jego dostawcę. Raczej złą kolejnością jest kolejność odwrotna.

[2012]

Na konferencji GOTO wystąpił Martin Fowler, który tak widzi wpowyższe problemy:

[2022]

Niedawno miałem okazję obejrzeć prezentację opisującą jak modelować dane dla systemów dokumentowych NoSQL na przykładzie bazy MongoDB. Polecam (bazy dokumentowe są dostępne w każdej chmurze: AWS, AZURE, IBM Cloude, …………, swego czasu opisywałem modelowanie w UML).