Tym razem zno­wu obiek­to­we ana­li­za i pro­jek­to­wa­nie. Na stro­nie SQL albo NoSQL, oto jest pyta­nie poja­wi­ła się cie­ka­wa wypo­wiedź. Jako, że oso­bi­ście ​„idę w kie­run­ku” obiek­to­wych sys­te­mów gdzie dane są indy­wi­du­al­ną cechą obiek­tów a nie super-cen­tral­nym skła­do­wi­skiem pozwo­lę sobie na dywa­ga­cje. Proszę ich nie trak­to­wać jako ​„praw­dę w moim wyda­niu”, jest to raczej moje obec­ne postrze­ga­nie tego zagad­nie­nia. Wypowiedzi auto­ra wska­za­ne­go tek­stu wcięte.

No dobra, korzy­sta­jąc z baz NoSQL zysku­je­my lep­szą ska­lo­wal­ność, brak sztyw­ne­go sche­ma­tu bazy danych, spo­rą ela­stycz­ność, mniej pro­ble­mów z mapo­wa­niem danych w bazie do obiek­tów zde­fi­nio­wa­nych w kodzie i pew­nie jesz­cze kil­ka rze­czy, o któ­rych nie mam poję­cia. Ale poja­wia­ją się ogra­ni­cze­nia. Czasem bar­dzo istot­ne. Po pierw­sze bazy NoSQL nie są rela­cyj­ne. Może i jest to oczy­wi­ste, ale chy­ba nie wszy­scy tak do koń­ca zda­ją sobie spra­wę, co to tak na praw­dę ozna­cza. Całą obsłu­gę rela­cyj­no­ści pomię­dzy dany­mi (jeśli jest nam potrzeb­na) trze­ba emu­lo­wać w kodzie apli­ka­cji, na wbu­do­wa­ne w bazę danych roz­wią­za­nia nie ma co liczyć.

Zarzut, że bazy NoSQL nie są rela­cyj­ne jest dla tych baz raczej kom­ple­men­tem. Kluczowym tu stwier­dze­niem tor­pe­du­ją­cym w moich oczach wywód jest uzna­nie fak­tu, że rela­cyj­ność może nie być potrzeb­na. Owszem, dodam nawet, że nie raz po pro­stu cią­ży. Po dru­gie moim zda­niem błęd­ne jest stwier­dze­nie, że rela­cyj­ność nale­ży emu­lo­wać w kodzie. Otóż nie, bo może być po pro­stu niepotrzebna!.

Po dru­gie czę­sto brak JOINów. […] Potrafi to bar­dzo utrud­nić pisa­nie wydaj­nych zapy­tań, a prze­cież roz­li­cza­ny jestem z każ­dej mili­se­kun­dy pra­cy procesora.

Kolejny moim zda­niem błąd w myśle­niu: dłu­gie, wyma­ga­ją­ce opty­ma­li­za­cji, skom­pli­ko­wa­ne zapy­ta­nia są wła­śnie cechą zapy­tań do baz rela­cyj­nych. Bazy rela­cyj­ne, po doko­na­niu nor­ma­li­za­cji, w zasa­dzie żad­nej infor­ma­cji nie trzy­ma­ją w jed­nym kawał­ku, wszyst­ko wyma­ga poskle­ja­nia przed uży­ciem. Pozyskanie tre­ści zwy­kłej fak­tu­ry z takiej bazy, wyma­ga poskle­ja­nia jej z dzie­sią­tek skła­do­wych tablic i słow­ni­ków, wyma­ga to fak­tycz­nie nie lada sztu­ki w napi­sa­niu zapy­ta­nia do bazy a co dopie­ro taki raport fak­tur sprze­da­ży z poprzed­nich okresów.

Dlaczego o tym piszę? Otóż jed­nym z więk­szych, w moich oczach, pro­ble­mów jest wykształ­ce­nie pro­jek­tan­tów i pro­gra­mi­stów. Nie, nie. Nie twier­dze że jest złe, po pro­tu nadal na wyż­szych uczel­niach na kie­run­kach infor­ma­ty­ki przed­mio­ty takie jak ana­li­za i mode­lo­wa­nie obiek­to­we w rela­cji do kla­sycz­nych zajęć w rodza­ju pro­gra­mo­wa­nie w Pascalu, C++ i mode­lo­wa­nie rela­cyj­nych baz danych to pyłek w pro­gra­mie nauczania.

Troszkę wyjaśnień

Relacyjne bazy danych (RDBMS) to w ogól­nym sen­sie, po ludz­ku, dane upo­rząd­ko­wa­ne w powta­rza­ją­ce się struk­tu­ry trwa­le z sobą powią­za­ne. Jedna z defi­ni­cji spo­ty­ka­nych w sieci:

W naj­prost­szym uję­ciu w mode­lu rela­cyj­nym dane gru­po­wa­ne są w rela­cje, któ­re repre­zen­to­wa­ne są przez tabli­ce. Relacje są pew­nym zbio­rem rekor­dów o iden­tycz­nej struk­tu­rze wewnętrz­nie powią­za­nych za pomo­cą związ­ków zacho­dzą­cych pomię­dzy dany­mi. Relacje zgru­po­wa­ne są w tzw. sche­ma­ty bazy danych. Relacją może być tabe­la zawie­ra­ją­ca dane tele­adre­so­we pra­cow­ni­ków, zaś sche­mat może zawie­rać wszyst­kie dane doty­czą­ce fir­my. Takie podej­ście w porów­na­niu do innych mode­li danych uła­twia wpro­wa­dza­nia zmian, zmniej­sze­nie moż­li­wość pomy­łek, ale dzie­je się to kosz­tem wydaj­no­ści. (źr. http://​pl​.wiki​pe​dia​.org/​w​i​k​i​/​M​o​d​e​l​_​r​e​l​a​c​y​jny)

Jak to wyglą­da w prak­ty­ce. Postaram się to poka­zać na nas samych. Wyobraźmy sobie struk­tu­rę orga­ni­za­cyj­ną fir­my i jej pra­cow­ni­ków. Normalną rze­czą jest, że każ­dy z nas zna Nazwisko prze­ło­żo­ne­go, wie jakich ma (jeśli ma) pod­wład­nych, zna nazwę swo­je­go sta­no­wi­ska, zna nazwę dzia­łu, w któ­rym pra­cu­je i pamię­ta nazwę fir­my, któ­ra go zatrud­nia. Ogólnie mamy te dane w gło­wie (prę­dzej czy póź­niej się tego nauczy­li­śmy). Niewątpliwie jeże­li ktoś ma dzie­się­cio­ro pod­wład­nych, to każ­dy z nich ma w gło­wie (w pamię­ci) kom­plet tych danych, zosta­ły więc powie­lo­ne 10-krot­nie. Marnotrawstwo kory mózgo­wej zespo­łu?!. Nie, po pro­stu ewo­lu­cja daw­no temu odkry­ła, że pew­ne dane nale­ży mieć do uży­cia ad-hoc u sie­bie bo w natu­rze liczy się natych­mia­sto­wy dostęp do tych danych (infor­ma­cji) a nie oszczęd­ność sza­rych komó­rek danej populacji.

Tak więc nazwi­sko pod­wład­ne­go znam na pamięć, a co gdy potrze­bu­je jego adres? Czy muszę wku­wać to wszyst­ko na pamięć? Nie, bo rzad­ko z tego korzy­stam! Muszę tyl­ko wie­dzieć tyl­ko gdzie jest dział kadr, tam są kar­to­te­ki pra­cow­ni­ków. Idę do Pani/Pana i pro­szę o tecz­kę per­so­nal­ną oso­by XXX i dosta­ję, a tam mam wszyst­ko. Przepisuje (powie­lam!) na koper­tę adres do kore­spon­den­cji, odda­ję tecz­kę per­so­nal­ną i wra­cam do swo­je­go biur­ka, pisze list, zakle­jam koper­tę i wysy­łam. To model obiek­to­wy świa­ta, dane – wyłącz­nie nie­zbęd­ne – są prze­cho­wy­wa­ne w naszych gło­wach nie­re­la­cyj­nie, resz­ta ma swo­je miej­sca, wystar­czy że wiem gdzie są, w razie potrze­by o nie poproszę.

A teraz inny model. Jedyne co wie­my o sobie to to, że jeste­śmy na tym świe­cie (zna­my tyl­ko swo­je nazwi­sko i imię), wszyst­ko inne: nasi pod­wład­ni, prze­ło­że­ni, nazwy depar­ta­men­tów, itp. to tyl­ko nitecz­ki pro­wa­dzą­ce do zapi­sów o nich. Nie wiem nic o sobie, jak ktoś zapy­ta kto jest moim sze­fem muszę zła­pać za nitecz­kę o nazwie prze­ło­żo­ny i zoba­czyć co jest na jej koń­cu. Jak mnie ktoś zapy­ta kto jest moim pre­ze­sem, po tych nitecz­kach, jak domi­no, będą brnę­li moi prze­ło­że­ni aż na szczyt hie­rar­chii zatrud­nie­nia i powie­dzą mi, dopie­ro kto jest moim pre­ze­sem. Jeżeli jestem sze­fem, to mam dodat­ko­wo tyle nite­czek do paska ilu mam pod­wład­nych, nie znam żad­ne­go z nich, za każ­dym razem by wska­zać któ­re­go­kol­wiek muszę pocią­gnąć za wszyst­kie nitecz­ki, wybrać jed­ne­go z nich i dopie­ro dać mu robo­tę. Tak wyglą­da model rela­cyj­ny. Tak zwa­na nor­ma­li­za­cja danych pole­ga na tym, że jeże­li jaka­kol­wiek infor­ma­cja mia­ła by się powtó­rzyć w czy­jejś gło­wie, to odbie­ra­my mu te infor­ma­cję, two­rzy­my kar­tecz­kę, na któ­rej ją zapi­su­je­my i nitecz­ka­mi te kar­tecz­kę pod­pi­na­my do każ­de­go komu te infor­ma­cje ode­bra­li­śmy. Każda taka kar­tecz­ka to pro­sty słow­ni­czek gdzie każ­dy zapis jest powią­za­ny nitecz­ką ze wszyst­kim cze­go doty­czy. Tak więc jak mnie ktoś zapy­ta gdzie pra­cu­ję to zamiast z gło­wy natych­miast odpo­wie­dzieć muszę pocią­gnąć za nitecz­kę Pracodawca i zoba­czyć co tam jest napi­sa­ne przy mojej nitecz­ce (a jest ich tam nie mało). Owszem, nazwa pra­co­daw­cy będzie tyl­ko raz zapi­sa­na, praw­do­po­dob­nie uzy­ska­my ogrom­ne oszczęd­no­ści miej­sca na zapi­sy ale też ogrom­nie skom­pli­ku­je­my i wydłu­ży­my dostęp do informacji.

Jak widać, pozy­ska­nie jakiej­kol­wiek infor­ma­cji z rela­cyj­ne­go repo­zy­to­rium to dość kar­ko­łom­ny zabieg. Do tego taki sys­tem ma jesz­cze jed­ną wadę: jak już raz wymy­śli­my jakie to mają być kar­tecz­ki, jak je ze sobą pospi­na­my nitecz­ka­mi, zapi­sze­my je, i nazbie­ra się nam tego, to sys­tem sta­je w zasa­dzie już nie­mo­dy­fi­ko­wal­ny. Jak się przy­tra­fi sytu­acja, w któ­rej dosta­nie­my jakieś infor­ma­cje ze źró­dła, w któ­rym te kar­tecz­ki choć trosz­kę ina­czej zosta­ły wymy­ślo­ne (co jest pra­wie pew­ne) to mamy poważ­ny pro­blem. Nie da się tego zapi­sać w naszym sys­te­mie wprost, musi­my poskle­jać tę cudza wie­dzę i na nowo roze­brać na małe kar­tecz­ki ale już po naszemu.

Po co więc wymy­ślo­no te rela­cyj­ne bazy? To były cza­sy gdy pamięć była naj­kosz­tow­niej­szym zaso­bem kom­pu­te­ra zaś dane mię­dzy sys­te­ma­mi w zasa­dzie nie były wymie­nia­ne! Było kil­ka zalet, np. brak błę­dów nazew­nic­twa itp. wię­cej o nich w sie­ci moż­na poczy­tać, jed­nak moim zda­niem baza danych będą­ca imple­men­ta­cją tak zwa­nych związ­ków poję­cio­wych (tym są rela­cyj­ne mode­le danych) nie spraw­dza się bo nie mode­lu­je obiek­tów świa­ta rze­czy­wi­ste­go a jedy­nie ich nazwy i powią­za­nia mię­dzy nimi a to ogrom­na różnica.

A co dzisiaj mamy

Dzisiaj mamy: wie­le róż­nych sys­te­mów w każ­dej fir­mie, powszech­ną wymia­nę danych wewnątrz fir­my i mię­dzy fir­ma­mi oraz naj­gor­sze czy­li zmien­ność śro­do­wi­ska biz­ne­so­we­go. Co mogę poradzić?

Jeżeli pla­nu­jesz wdro­że­nie goto­we­go sys­te­mu opar­te­go na rela­cyj­nej bazie pamię­taj, że:

- etap jego wdra­ża­nia i para­me­try­za­cji to ostat­ni moment na decy­zje o struk­tu­rze infor­ma­cji, potem prak­tycz­nie już nie da się tego zmienić

- jeże­li w trak­cie ana­li­zy wykry­jesz w swo­jej fir­mie jakieś szyb­ko­zmien­ne obsza­ry, zamiast inwe­sto­wać w kolej­ny moduł duże­go sys­te­mu ERP, zleć napi­sa­nie dedy­ko­wa­ne­go pod­sys­te­mu w now­szej tech­no­lo­gii i zin­te­gruj go z tym ERP

- jeże­li dostaw­ca ERP powie Ci, że inte­gra­cja cze­go­kol­wiek z tym sys­tem wyma­ga dużej i kosz­tow­nej pra­cy nie kupuj tego systemu.

Tak wiec zanim wybie­rze­my sys­tem ERP wyobraź­my sobie, że wdro­że­nie zmu­si nas do prze­nie­sie­nia naszej wie­dzy z głów na małe kar­tecz­ki, zmu­si nas do powią­za­nia tego wszyst­kie­go set­ka­mi nite­czek, pogo­dze­nia się z tym, że dopó­ki będzie­my mie­li ten sys­tem nie­wie­le będzie­my mogli póź­niej w tym wszyst­kim cokol­wiek zmie­nić. Jedną z poważ­niej­szych wad sys­te­mów zin­te­gro­wa­nych jest to, że są zin­te­gro­wa­ne gdyż nadal więk­szość z nich to inte­gra­cja poprzez współ­dzie­le­nie danych.

Co robić? Moim zda­niem war­to po pro­stu dobrze się nad tym wszyst­kim zasta­no­wić, oce­nić róż­ne warian­ty i na koń­cu dopie­ro wybrać sys­tem ERP i jego dostaw­cę. Raczej złą kolej­no­ścią jest kolej­ność odwrotna.

[2012]

Na kon­fe­ren­cji GOTO wystą­pił Martin Fowler, któ­ry tak widzi wpo­wyż­sze problemy:

[2022]

Niedawno mia­łem oka­zję obej­rzeć pre­zen­ta­cję opi­su­ją­cą jak mode­lo­wać dane dla sys­te­mów doku­men­to­wych NoSQL na przy­kła­dzie bazy MongoDB. Polecam (bazy doku­men­to­we są dostęp­ne w każ­dej chmu­rze: AWS, AZURE, IBM Cloude, .….….…, swe­go cza­su opi­sy­wa­łem mode­lo­wa­nie w UML).