Bazy NoSQL jako implementacje wzorców struktur informacji

Dane nie­struk­tu­ral­ne sta­no­wią ponad 80% skła­do­wa­nych danych, to ozna­cza, że model rela­cyj­ny pozwa­la opi­sać i prze­twa­rzać tyl­ko uła­mek posia­da­nej infor­ma­cji (UNSTRUCTURED DATA AND THE 80 PERCENT RULE)

Wstęp

W pod­su­mo­wa­niu nie­daw­ne­go arty­ku­łu o NoSQL w chmu­rze, napisałem: 

Problem pro­jek­to­wa­nia struk­tur doku­men­tów, tak­że w bazach doku­men­to­wych, to osob­ne i trud­ne zagad­nie­nie. Opisałem go w naj­now­szym arty­ku­le, któ­ry uka­że się za nie­dłu­go w wydaw­nic­twie IGI Global: Emerging Challenges, Solutions, and Best Practices for Digital Enterprise Transformation. (Repozytorium w chmu­rze – NoSQL – Jarosław Żeliński IT-Consulting – Systemy Informacyjne)

Artykuł sie wła­śnie uka­zał. We wstę­pie napisałem:

Dokumenty czę­sto zawie­ra­ją dużą ilość róż­nych danych two­rzą­cych wspól­nie wie­le kon­tek­sto­wych zbio­rów danych (agre­ga­tów). Zastosowanie mode­lu rela­cyj­ne­go do orga­ni­za­cji takich danych pro­wa­dzi do wyge­ne­ro­wa­nia roz­bu­do­wa­ne­go sys­te­mu powią­za­nych rela­cyj­nie tabel, przy czym usu­nię­cie redun­dan­cji czę­sto powo­du­je utra­tę kon­tek­stu tre­ści poszcze­gól­nych pól w tabe­lach. Rodzi to koniecz­ność sto­so­wa­nia wyso­ce zło­żo­nych zapy­tań SQL, aby doku­men­ty te mogły być zapi­sy­wa­ne w tej bazie danych i z niej pobie­ra­ne. W ten spo­sób sama baza danych zawie­ra wyłącz­nie dane pozba­wio­ne kon­tek­stu obec­ne­go w tabe­lach, a nie dokumenty.

Wielu auto­rów zwra­ca­ło uwa­gę na pro­blem zło­żo­no­ści i utra­ty jed­no­li­te­go kon­tek­stu mode­lu rela­cyj­ne­go (Ślęzak i in., 2018). Autorzy ci suge­ro­wa­li, że kon­tek­sty powin­ny być sepa­ro­wa­ne w dużych rela­cyj­nych mode­lach danych. Jednak zale­ce­nie sepa­ra­cji kon­tek­stów (Evans, 2003; Fowler, 1997; Fowler & Rice, 2005), przy zacho­wa­niu mode­lu rela­cyj­ne­go, nie poma­ga w cał­ko­wi­tym roz­wią­za­niu pro­ble­mu (Awang et al., 2012, 2012, 2012).

Zmiana kon­tek­stu czę­sto zmie­nia zna­cze­nie danych (Danesi, 2004). Podejmowane pró­by zacho­wa­nia zna­cze­nia danych czę­sto pro­wa­dzą do two­rze­nia roz­bu­do­wa­nych rela­cyj­nych mode­li danych, gene­ru­jąc tym samym dodat­ko­we kosz­ty. Dlatego też wyko­rzy­sta­nie jed­ne­go rela­cyj­ne­go mode­lu danych do zapi­su zawar­to­ści wie­lu róż­nych doku­men­tów może uczy­nić z takie­go sys­te­mu ogrom­ny i nie­po­dziel­ny mono­lit, któ­ry jest kosz­tow­ny zarów­no w roz­wo­ju, jak i w utrzy­ma­niu. (Digital Documents as Data Carriers and a Method of Data Management Guaranteeing the Unambiguity of the Recorded Information: Ontology-Oriented Data Management and Document Databases)

Rodzaje baz danych NoSQL na rynku

Praktyka poka­zu­je, że bazy te to odpo­wiedź na stan­dar­do­we obec­nie wyma­ga­nia wobec sys­te­mów infor­ma­cyj­nych, jaki­mi są zmien­ność struk­tur danych, ich ogra­ni­czo­na struk­tu­ra­li­za­cja lub nawet jej cał­ko­wi­ty brak .

Akronim NoSQL został po raz pierw­szy uży­ty w 1998 roku przez Carlo Strozzi’ego jako nazwa jego lek­kiej, open­so­ur­ce rela­cyj­nej” bazy danych, któ­ra nie uży­wa­ła SQL. Nazwa ta poja­wi­ła się ponow­nie w 2009 roku, kie­dy Eric Evans i Johan Oskarsson uży­li jej do opi­sa­nia nie­re­la­cyj­nych baz danych. Relacyjne bazy danych są czę­sto okre­śla­ne jako sys­te­my SQL. Termin NoSQL może ozna­czać zarów­no Nierelacyjna SQL” lub bar­dziej popu­lar­ne tłu­ma­cze­nie Nie tyl­ko SQL” (Not only SQL), aby pod­kre­ślić fakt, że nie­któ­re sys­te­my mogą obsłu­gi­wać języ­ki zapy­tań podob­ne do SQL. (źr.: A Brief History of Non-Relational Databases – DATAVERSITY)

Jeden z moim zda­niem cie­kaw­szych arty­ku­łów o NoSQL napi­sał Fowler 10 lat temu .

Bazy danych «key-value».

Bazy te są naj­prost­szym typem bazy NoSQL. Każdy ele­ment (wiersz) w takiej bazie to para klucz i war­tość (dane prze­cho­wy­wa­ne), tu zawar­tość (dane prze­cho­wy­wa­ne) to zawsze jakiś plik” (podob­nie jak pole typu BLOB: Binary Large OBject). Zawartość ta może być pobra­na wyłącz­nie poprzez odwo­ła­nie się do jej iden­ty­fi­ka­to­ra (klu­cza) . Bazy te są dosko­na­łe do prze­cho­wy­wa­nia dużych ilo­ści róż­no­rod­nych danych, gdzie nie trze­ba prze­twa­rzać tre­ści tych danych w samej bazie (np. wyszu­ki­wa­nie zawar­to­ści na pod­sta­wie jej okre­ślo­nych cech). Służą one wyłącz­nie do zacho­wy­wa­nia i odzy­ski­wa­nia pli­ków. Praktycznie jest to pła­ski sys­tem plików. 

model repo­zy­to­rium key-value (opra­co­wa­nie wła­sne autora) 
meto­da zapi­su w repo­zy­to­rium key-value (opra­co­wa­nie wła­sne autora) 

Dokumentowe bazy danych. 

To odmia­na bazy key-value. Przechowuje dane w posta­ci okre­ślo­nej struk­tu­ral­nej tre­ści: doku­men­tów (np. JSON czy XML). Struktury te mają swo­je defi­ni­cje, a ich typów może być dowol­na licz­ba . Jedna baza może więc zawie­rać doku­men­ty o dowol­nie wybra­nej, okre­ślo­nej struk­tu­rze. Dostępne na ryn­ku bazy tego typu maja tak­że bar­dzo dobre i szyb­kie moto­ry zapy­tań, są coraz czę­ściej sto­so­wa­ne jako bazy danych ogól­ne­go przeznaczenia. 

Baza doku­men­to­wa. Dokument to czy­tel­na dla czło­wie­ka treść, w bazach doku­men­to­wych ma on okre­ślo­na ale nie sztyw­ną struk­tu­rę: może to być JSON, XML. Dokument (jego treść) jest prze­twa­rza­ny poza bazą danych (kom­po­nent Logika biz­ne­so­wa). (opra­co­wa­nie wła­sne autora) 

Bazy zmieno-kolumnowe.

Przechowują dane w posta­ci agre­ga­tów o zmien­nych liściach”. Bazy tego typu zapew­nia­ją dużą ela­stycz­ność w sto­sun­ku do rela­cyj­nych baz danych, ponie­waż nie jest wyma­ga­ne, aby każ­dy wiersz agre­gat posia­dał tyle samo i te same ele­men­ty (kolum­ny) . Bazy tego typu są powszech­nie sto­so­wa­ne do prze­cho­wy­wa­nia danych np. danych pro­fi­lo­wych użyt­kow­ni­ków. Są czę­sto opi­sy­wa­ne w poniż­szy sposób:

Diagram of a column family in a wide column store database.
Model archi­tek­tu­ry kom­po­nen­tu z bazą zmien­no-kolum­no­wą (powyż­sze wyra­żo­ne jako model dzie­dzi­ny kom­po­nen­tu z uży­ciem UML)

Jak widać, bazy te prze­cho­wu­ją agre­ga­ty. Nazwanie agre­ga­tu wier­szem” jest nie­for­tun­ne bo to jed­nak nie są pła­skie tabe­le, jed­nak poję­cia wier­szy i kolumn zrzu­cam tu jed­nak na karb ste­reo­ty­pu zaczerp­nię­te­go z mode­lu relacyjnego.

Grafowe bazy danych. 

Przechowują dane w posta­ci węzłów i kra­wę­dzi (aso­cja­cje mię­dzy węzła­mi). Węzły zazwy­czaj prze­cho­wu­ją infor­ma­cje o obiek­tach (ludzie, miej­sca, przed­mio­ty) kra­wę­dzie zaś prze­cho­wu­ją infor­ma­cje o moż­li­wych związ­kach mię­dzy węzła­mi . Grafowe bazy danych dosko­na­le spraw­dza­ją się w przy­pad­kach gdy trze­ba zapi­sy­wać i śle­dzić związ­ki mię­dzy obiek­ta­mi i ana­li­zo­wać je, np. sie­ci spo­łecz­no­ścio­we czy wykry­wa­nie oszustw. Tak są naj­czę­ściej opi­sy­wa­ne gra­fo­we bazy danych, a przed­sta­wia­ne są np. tak:

Uważam, że powyż­sze to try­wial­na i naiw­na meto­da przed­sta­wia­nia baz tego typu. Istotą sys­te­mu prze­twa­rza­nia infor­ma­cji jest tu (w takim mode­lu) jest prze­cho­wy­wa­nie infor­ma­cji o obiek­tach i o fak­tach je łączą­cych takich jak zda­rze­nia doty­czą­ce pary obiek­tów . Mogą to być typo­we fak­ty, np. Samochód miał koli­zje w Mieście, gdzie Samochód i Miasto to węzły, a koli­zja to zda­rze­nie. Ważne jest to, że Samochód i Miasto moż­na opi­sać okre­ślo­nym cech, sama koli­zje tak­że, waż­ne jest to, że fak­tów łączą­cych dwa obiek­ty może być wie­le (w czasie). 

Związki mię­dzy obiek­ta­mi opi­sy­wa­ne są też meto­dą RDF (Resource Description Framework) jako zda­nia: Subject – Predicate – Object .

O każ­dym obiek­cie będzie jeden rekord w bazie danych, o każ­dym fak­cie też, ale róż­nych fak­tów, któ­rych cecha­mi są te obiek­ty może być wie­le (cechą stłucz­ki jest mię­dzy inny­mi miej­sce stłucz­ki i samo­chód, któ­ry miał tę stłucz­kę). Cechami obiek­tów są nazwa, data powsta­nia i ewen­tu­al­na data usu­nię­cia (znisz­cze­nia), tak­że cechy defi­niu­ją­ce takie jak np. kolor, typ czy wyda­wa­ne dźwię­ki. Cechami fak­ty są czas zaist­nie­nia oraz obiek­ty (ich nazwy), któ­rych okre­ślo­ny fakt doty­czy. Ważne jest to, że poło­że­nie obiek­tu nie jest jego cechą defi­niu­ją­cą. Graf jest defi­nio­wa­ny jako nazwa­ne związ­ki mię­dzy obiek­ta­mi, są nimi wła­śnie fak­ty (a sze­rzej: pre­dy­ka­ty). Warto też zazna­czyć, że w kon­tek­ście np. zda­rzeń gospo­dar­czych, fak­tem jest fak­tu­ra opi­su­ją­ca trans­ak­cje do jakiej doszło. Jednak w archi­wum doku­men­tów fak­tu­ra jest obiek­tem archi­wal­nym .

Tak więc bar­dziej sfor­ma­li­zo­wa­na struk­tu­ra danych w bazie gra­fo­wej mogła by wyglą­dać tak:

Struktura infor­ma­cyj­na gra­fo­wej bazy danych: obiek­ty (nie­bie­skie) i związ­ki (żół­te) (opra­co­wa­nie wła­sne autora)

Diagram powyż­szy jest kolo­ro­wa­ny dla popra­wy czy­tel­no­ści. W tej posta­ci widać obiek­ty i łączą­ce je fak­ty: w bazach gra­fo­wych są to for­mal­nie tak zwa­ne związ­ki seman­tycz­ne (zna­cze­nio­we), ale jest to jed­nak duże uprosz­cze­nie. Systemy zapi­su infor­ma­cji w posta­ci tró­jek: poję­cie-pre­dy­kat-poję­cie mają szer­sze uza­sad­nie­nie (pla­nu­ję publi­ka­cję z wyni­ka­mi szer­szych badań). Metamodel sys­te­mu zapi­su infor­ma­cji o obiek­tach i związ­kach mię­dzy nimi wyglą­da tak:

Metamodel gra­fo­wej bazy danych (opra­co­wa­nie wła­sne autora) 

Warto zauwa­żyć, że zarów­no Obiekt jak i Związek seman­tycz­ny mogą być prze­cho­wy­wa­ne w bazie doku­men­to­wej lub kolumnowej…

Podsumowanie

To co dzi­siaj nazy­wa­my baza­mi danych NoSQL to tyl­ko natu­ral­ne mode­le infor­ma­cyj­ne. Kiedy odkry­te? Nie wiem, ale wiem, że w tym wszyst­kim naj­bar­dziej nie­na­tu­ral­ny jest model rela­cyj­ny. Dlaczego? Bo nie wystę­pu­je w natu­rze i spra­wia same pro­ble­my. Celowo zapre­zen­to­wa­łem sfor­ma­li­zo­wa­ne dia­gra­my UML dla każ­de­go typu, by poka­zać, że NoSQL to tyl­ko i aż mode­le infor­ma­cyj­ne spo­ty­ka­ne w rze­czy­wi­sto­ści życia czło­wie­ka. Konstrukcje jak te wyżej opi­sa­ne, to tak na praw­dę mode­le infor­ma­cji wyni­ka­ją­ce z dzie­dzi­ny pro­ble­mu, nie jest tak że są uży­wa­ne z powo­du wyna­le­zie­nia” baz NoSQL, jest dokład­nie odwrotnie. 

Obecne bazy NoSQL rozu­mia­ne jako moto­ry baz danych”, to imple­men­ta­cje infor­ma­cyj­nych wzor­ców pro­jek­to­wych. Diagramy UML powy­żej to meta­mo­de­le tych wzorców. 

Na temat baz danych i baz NoSQL pole­cam kom­plek­so­we opra­co­wa­nie Joe Celko: Complete guide to NoSQL: what eve­ry SQL pro­fes­sio­nal needs to know abo­ut non­re­la­tio­nal data­ba­ses .

Podsumowanie 2

Pojawiają się tezy że to się nie nada­je do ERP, że nikt tak nie robi… Otóż:

Systemy ERP budo­wa­ne w opar­ciu o cen­tral­ne bazy danych RDBMS ewo­lu­ują­ce do chmu­ry są nie­ja­ko ska­za­ne na bazy NoSQL (zna­ko­mi­ta więk­szość chmu­ro­wych repo­zy­to­riów chmu­ro­wych to bazy NoSQL).

Ewolucja Architektury tak zwa­nych stan­dar­do­wych ERP 

Podstawowym pro­ble­mem sys­te­mów zbu­do­wa­nych w opar­ciu o bazy RDBMS/SQL jest to, że nie ma w nich doku­men­tów, a jedy­nie dane roz­ło­żo­ne w tabe­lach. Uzyskanie doku­men­tu (np. fak­tu­ry) wyma­ga każ­do­ra­zo­wo dyna­micz­ne­go zebra­nia danych z wie­lu tabel, ich złą­cze­nia i sfor­ma­to­wa­nia, czy­li uży­cia języ­ka SQL. Dlatego ewo­lu­cja nowo­cze­snych sys­te­mów ERP idzie w kie­run­ku sys­te­mów, w któ­rych funk­cje kal­ku­la­cyj­ne oraz doku­men­ty są roz­dzie­lo­ne, a doku­men­ty są prze­cho­wy­wa­ne w posta­ci zmaterializowanej: 

Zarządzanie doku­men­ta­mi w sys­te­mach ERP 

Podsumowanie 3

Od dłuż­sze­go cza­su sto­su­je w pro­jek­tach struk­tu­ry infor­ma­cyj­ne nazy­wa­ne NoSQL. Sa to prak­tycz­nie wszyst­kie opi­sa­ne wyżej struk­tu­ry. Projekt dla agen­cji foto­gra­ficz­nej BE&W (archi­wum zdjęć), pro­jekt dla Biura Polonii Kancelarii Senatu (obsłu­ga wnio­sków o dofi­nan­so­wa­nie o zmien­nej struk­tu­rze), pro­jekt dla Żandarmerii Wojskowej (zarzą­dza­nie spra­wa­mi docho­dze­nio­wo-śled­czy­mi w całej Polsce), pro­jekt dla KGHM (stan­da­ry­za­cja sys­te­mu utrzy­ma­nia ruchu, zarzą­dza­nie infra­struk­tu­rą produkcyjną).

Więcej już nie­dłu­go… Zachęcam do zada­wa­nia pytań o NoSQL pod tym wpisem. 

Źródła

Bouhali, R., & Laurent, A. (2015). Exploiting RDF Open Data Using NoSQL Graph Databases. In R. Chbeir, Y. Manolopoulos, I. Maglogiannis, & R. Alhajj (Eds.), Artificial Intelligence Applications and Innovations (Vol. 458, pp. 177 – 190). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑319 – 23868-5_13
Besta, M., Peter, E., Gerstenberger, R., Fischer, M., Podstawski, M., Barthels, C., Alonso, G., & Hoefler, T. (2020). Demystifying Graph Databases: Analysis and Taxonomy of Data Organization, System Designs, and Graph Queries. ArXiv:1910.09017 [Cs]. http://​arxiv​.org/​a​b​s​/​1​9​1​0​.​0​9​017
Harley Vera, Wagner Boaventura, Maristela Holanda, Valeria Guimaraes, & Fernanda Hondo. (2015). Data Modeling for NoSQL Document-Oriented Databases. CEUR Workshop Proceedings, 1478, 129 – 135.
Celko, J. (2014). Joe Celko’s Complete guide to NoSQL: what eve­ry SQL pro­fes­sio­nal needs to know abo­ut non­re­la­tio­nal data­ba­ses. Elsevier/Morgan Kaufmann.
Garba, M. (2020). A Comparison of NoSQL and Relational Database Management Systems (RDBMS). 1(2), 9.
Karnitis, G., & Arnicans, G. (2015). Migration of Relational Database to Document-Oriented Database: Structure Denormalization and Data Transformation. 2015 7th International Conference on Computational Intelligence, Communication Systems and Networks, 113 – 118. https://​doi​.org/​1​0​.​1​1​0​9​/​C​I​C​S​y​N​.​2​0​1​5​.30
Gyorödi, C., Gyorödi, R., & Sotoc, R. (2015). A Comparative Study of Relational and Non-Relational Database Models in a Web- Based Application. International Journal of Advanced Computer Science and Applications, 6(11). https://​doi​.org/​1​0​.​1​4​5​6​9​/​I​J​A​C​S​A​.​2​0​1​5​.​0​6​1​111
Guimaraes, V., Hondo, F., Almeida, R., Vera, H., Holanda, M., Araujo, A., Walter, M. E., & Lifschitz, S. (2015). A stu­dy of geno­mic data pro­ve­nan­ce in NoSQL docu­ment-orien­ted data­ba­se sys­tems. 2015 IEEE International Conference on Bioinformatics and Biomedicine (BIBM), 1525 – 1531. https://​doi​.org/​1​0​.​1​1​0​9​/​B​I​B​M​.​2​0​1​5​.​7​3​5​9​902

Dane są nieważne bo liczy się przede wszystkim mechanizm działania

Tym prze­wrot­nym tytu­łem chcę dziś zwró­cić uwa­gę na dwa waż­ne i bar­dzo pomoc­ne wzor­ce ana­li­tycz­ne (sło­wo ana­li­tycz­ne ode mnie, w książ­kach na temat wzor­ców bar­dzo rzad­ko uży­wa­na jest nazwa wzor­ce ana­li­tycz­ne”) opi­sa­ne w książ­ce M.Fowlera. Wzorcami ana­li­tycz­ny­mi nazy­wam te wzor­ce pro­jek­to­we, któ­re poma­ga­ją w ana­li­zie i pro­jek­to­wa­niu mode­lu dzie­dzi­ny sys­te­mu (biz­ne­so­wy model obiektowy).

MFowlerWzorceProjektowePolecam oczy­wi­ście lek­tu­rę całej książ­ki Martina Fowlera Architektura Systemów Zarządzania Przedsiębiorstwem Wzorce Projektowe.[1] Opisuje on w niej wła­snie wzor­ce pro­jek­to­we bar­dzo przy­dat­ne już na eta­pie pro­jek­to­wa­nia. Fowler nie uży­wa poję­cia wzor­ca ana­li­tycz­ne­go” ale książ­ka jest podzie­lo­na na obsza­ry zasto­so­wa­nia wzor­ców, wśród nich znaj­dzie­cie więc wzor­ce logi­ki dzie­dzi­ny, wzor­ce pre­zen­ta­cji inter­ne­to­wych czy omó­wio­ne tu wzor­ce dys­try­bu­cji a tak­że bar­dzo przy­dat­ne wzor­ce okre­ślo­ne jako pod­sta­wo­we”.

Poza wzor­ca­mi typo­wy­mi dla sys­te­mów obiek­to­wych w ogó­le, war­to zwró­cić uwa­gę na dwa. Opiszę krót­ko dwa bar­dzo przy­dat­ne na eta­pie ana­li­zy wzor­ce pro­jek­to­we (odno­śni­ki do stro­ny M.Fowlera): Transfer Object oraz Value Object.

Przykład użycia Value Object i Transfer Object

Na eta­pie ana­li­zy pro­ble­mu (ana­li­zy i mode­lo­wa­niu dzie­dzi­ny sys­te­mu) powin­no nas inte­re­so­wać przede wszyst­kim co i po co się dzie­je. Wielu ana­li­ty­ków o rodo­wo­dzie pro­gra­mi­stycz­nym zaczy­na pra­cę od pytań w rodza­ju ile nazwi­sko ma zna­ków, czy mogą to być tyl­ko lite­ry czy coś jesz­cze”, itd. Jest to moim zda­niem kom­plet­ne nie­po­ro­zu­mie­nie. Zabieranie się za opra­co­wa­nie mode­lu od tej stro­ny (mode­lo­wa­nie danych) cał­ko­wi­cie przy­ćmi roz­wią­zy­wa­ny pro­blem. Np. sta­ra­jąc się zro­zu­mieć sys­tem sprze­da­ży bile­tów na samo­lot istot­ne jest na począt­ku nie to, ile zna­ków może mieć nazwi­sko a to, że bar­dzo istot­na jest iden­ty­fi­ka­cja pasa­że­rów i miejsc jakie mają zająć w samo­lo­cie. To nie jest to samo, bo iden­ty­fi­ka­cja pasa­że­rów ma za cel kon­tro­lę, kogo wpusz­cza­my na pokład samo­lo­tu, a nazwi­sko to jed­na z cech pasa­że­ra i na eta­pie ana­li­zy nie nale­ży zakła­dać, że to jedy­ny i naj­lep­szy spo­sób na to roz­róż­nie­nie. Brzmi jak here­zja? Zapewne, bo więk­szość” ana­li­ty­ków zaczy­na wła­śnie od bada­nia np. nazwiska.

A kie­dy zając się nazwi­skiem? Dopiero wte­dy gdy zro­zu­mie­my pro­blem i opra­cu­je­my sys­te­mo­we jego roz­wią­za­nie. Po pierw­sze dla­te­go, że na począt­ku nie mamy wie­dzy (za wcze­śnie na taką decy­zję) by usta­lić na jakich kon­kret­nie danych będzie opie­ra­ła się iden­ty­fi­ka­cja pasa­że­rów (a nuż poja­wi się [[bio­me­tria]]), po dru­gie nie­po­trzeb­nie skom­pli­ku­je­my doku­men­ta­cję zamu­la­jąc ją od same­go począt­ku dużą ilo­ścią zbęd­nych atry­bu­tów”.

Druga istot­na rzecz, to komu­ni­ka­cja. Wiemy, że fir­ma sprze­da­ją­ca bile­ty lot­ni­cze ope­ru­je róż­ny­mi dany­mi (lokal­ny model biz­ne­so­wy tej fir­my) na temat rezer­wo­wa­nych bile­tów. Wiemy, że te dane – o sprze­da­nych bile­tach – muszą być prze­ka­za­ne linii lot­ni­czej, ta zaś wcze­śniej musi jakoś prze­ka­zać infor­ma­cje o tym, na jakie loty i jakie bile­ty oferuje.

Co cie­ka­we, dosko­na­le to pasu­je to opi­sów wyko­ny­wa­nych przez zama­wia­ją­ce­go (albo jak kto woli user sto­ry). Normalny czło­wiek raczej powie nam, że zapi­su­je dane pasa­że­ra”, ale raczej nie powie nam, że reje­stru­je 25 zna­ków nazwi­ska, 20 zna­ków imie­nia i cza­sem 20 zna­ków dru­gie­go imie­nia.….”. Ten sam czło­wiek powie następ­nie, że prze­ka­zu­je dane o sprze­da­nych bile­tach do odpo­wied­nich linii lot­ni­czych a nie, że doko­nu­je trans­fe­ru kolek­cji danych zawierających.….”.

Analiza i projektowanie

Na bazie wywia­dów, doku­men­tów itp. sta­ra­my się zro­zu­mieć co jest gra­ne”, jak ten sys­tem funk­cjo­nu­je. Powstaje np. taki dia­gram. Tu zakła­dam już, że mode­lu­je­my sys­tem sprze­da­ży bile­tów, ale sys­tem ozna­cza wszyst­ko to, co bie­rze w tym udział” a nie kon­kret­ne oprogramowanie”:

Transfer biletów do linii lotniczej

Mamy model cze­goś co ma się wyda­rzyć. Na tym eta­pie kom­plet­nie nie ma sen­su zaj­mo­wa­nie się tym ile zna­ków ma nazwi­sko. To może się zmie­nić w toku ana­li­zy a nawet imple­men­ta­cji, ale nie powin­na ulec zmia­nie logi­ka tej operacji.

Jak już opa­nu­je­my logi­kę (zro­zu­mie­my co i jak ma dzia­łać i zapro­jek­tu­je­my jak to zre­ali­zo­wać) zabie­ra­my się za szcze­gó­ły. Model dzie­dzi­ny (frag­ment):

Model dziedziny

Jak widać, np. danePasażera jako zawar­tość to daneOsoby a nie pola i typy danych”. Czym są DaneOsoby znaj­dzie­my tu:

ValueObject

Zamiast pro­stych typów danych (np. zna­ko­we) sto­su­je­my obiekt jako typ danych. To zna­ko­mi­cie uła­twia póź­niej­sze roz­sze­rze­nia i zmia­ny (nie musi­my nic zmie­niać w mode­lu dzie­dzi­ny by np. dodać dru­gie imię do danych oso­by, mody­fi­ku­je­my w jed­nym miej­scu jedy­nie dekla­ra­cję kla­sy DaneOsoby).

Wywołanie ope­ra­cji podajDaneBiletu zwra­ca obiekt DaneBiletuLitniczego (lub agre­gat zawie­ra­ją­cy wszyst­kie bilety):

Transfer ObjectNie jest to ten sam obiekt co wcze­śniej, ValueObject to typ danych, Transfer Object to seria­li­za­cja, któ­rej celem jest jedy­nie prze­nie­sie­nie w moż­li­wie naj­prost­szy do odczy­ta­nia spo­sób okre­ślo­nych infor­ma­cji (oba te obiek­ty nie mają jed­nak toż­sa­mo­ści). Nie nale­ży tych wzor­ców mylić ani utoż­sa­miać, gdyż Value Object to typ danych” zaś Transfer Object to jedy­nie para­metr wywo­łań, Value Object powi­nien mieć ope­ra­cje sparw­dza­ja­ce jego popraw­ność (wali­da­cja), Transfer Object słu­ży wyłącz­nie do prze­ka­zy­wa­nia infor­ma­cji jako para­metr wywo­łań i odpo­wie­dzi (w pew­nym sen­sie defi­niu­je pro­to­kół wymia­ny danych).

Korzyści ze sto­so­wa­nia tych wzor­ców to mię­dzy innymi:

  1. szcze­gó­ły danych odkła­da­my na koniec pro­jek­tu co jest bez­piecz­ne (nie musi­my mody­fi­ko­wać pro­jek­tu w mia­rę postę­pu pozy­ski­wa­nia wie­dzy o szczegółach),
  2. zmia­na tych szcze­gó­łów nie spo­wo­du­je potrze­by zmia­ny szkie­le­tu mode­lu dziedziny,
  3. może­my pro­wa­dzić spo­koj­ną upo­rząd­ko­wa­ną ana­li­zę top-down” (od ogó­łu do szczegółu),
  4. może­my się umó­wić z deve­lo­pe­rem, że jako ana­li­ty­cy nie będzie­my wni­ka­li w szcze­gó­ły danych, nadal może­my ope­ro­wać kla­sa­mi ValueObject i TransferObject (kla­sy te będą w począt­ko­wej fazie pro­jek­tu bez atrybutów),
  5. mimo to może­my umie­ścić w kla­sach ValueObject warun­ki wali­da­cji (ope­ra­cje klas, któ­rych tu nie poka­zy­wa­łem) i do tego one mię­dzy inny­mi słu­żą (to się nazy­wa okre­śla­nie wyma­gań poprzez testy czy­li TDD),
  6. już na samym począt­ku może­my uzgod­nić postać danych wymie­nia­nych na inter­fej­sach (np. zdal­na komu­ni­ka­cja) i korzy­stać z tej umowy.

Tak zapro­jek­to­wa­ny sys­tem speł­nia tak­że jed­ną z klu­czo­wych zasad pro­jek­to­wa­nia obiek­to­we­go: sys­tem jest zamknię­ty na zmia­ny i otwar­ty na rozszerzenia”.

Na zakończenie

Często sły­szę, że to trud­ne i pra­co­chłon­ne (dodat­ko­we kla­sy w mode­lu), nie­ste­ty zbyt pro­sty pro­jekt potra­fi być kosz­tow­niej­szy w roz­bu­do­wie w porów­na­niu z pier­wot­nym wytwo­rze­niem, dla­te­go jak klient w ramach wyma­gań wpi­su­je (a wpi­su­je coraz czę­ściej): sys­tem ma umoż­li­wiać łatwe roz­sze­rze­nia funk­cjo­nal­no­ści, to nale­ży go tak pro­jek­to­wać, w prze­ciw­nym wypad­ku wyma­ga­nie to nie jest spełnione…

Druga uwa­ga: czę­sto sami klien­ci zabi­ja­ją swo­je pro­jek­ty żąda­jąc na samym począt­ku udo­ku­men­to­wa­nia wszyst­kich szcze­gó­łów jakie im do gło­wy przyj­dą nie potra­fiąc jed­no­cze­śnie opi­sać mecha­ni­zmu dzia­ła­nia ich orga­ni­za­cji (lub nowe­go pomy­słu). To nie­ste­ty czę­sto spo­ty­ka­ne zja­wi­sko, z któ­rym moim zda­niem nale­ży wal­czyć. Paradoksalnie zło­żo­ność sys­te­mów biz­ne­so­wych tkwi w mecha­ni­zmie ich funk­cjo­no­wa­nia a nie w danych, któ­re zbie­ra­ją (któ­rych nie raz jest po pro­stu za dużo…).

Dane to fak­ty jakie chce­my znać, te fak­ty są kon­se­kwen­cją dzia­ła­nia a nie odwrotnie. 

Na ryn­ku w Polsce są jesz­cze mię­dzy inny­mi książ­ki o wzorcach:

Moim zda­niem jed­nak nie przy­dat­ne ana­li­ty­kom. Pierwsza to wzor­ce tech­nicz­ne”, sto­so­wa­ne głów­nie z kom­po­nen­tach Controller i View (archi­tek­tu­ra MVC). Druga to w zasa­dzie doku­men­ta­cja [[J2EE]]. Tak więc obie raczej dla pro­gra­mi­stów i archi­tek­tów. Książkę Fowlera pole­cam ana­li­ty­kom i archi­tek­tom tak­że. Wszystkim pole­cam tak­że UML i Wzorce pro­jek­to­we Larmana.

(UWAGA! Pokazano pro­jekt poglą­do­wy, wyssa­ny z pal­ca, nie ujaw­ni­łem tre­ści żad­ne­go z moich real­nych projektów).

Footnotes
[1]M. Fowler, Architektura sys­te­mów zarzą­dza­nia przed­się­bior­stwem. Wzorce pro­jek­to­we [na:] ?helion​.pl?, http://​helion​.pl/​k​s​i​a​z​k​i​/​a​r​c​h​i​t​e​k​t​u​r​a​-​s​y​s​t​e​m​o​w​-​z​a​r​z​a​d​z​a​n​i​a​-​p​r​z​e​d​s​i​e​b​i​o​r​s​t​w​e​m​-​w​z​o​r​c​e​-​p​r​o​j​e​k​t​o​w​e​-​m​a​r​t​i​n​-​f​o​w​l​e​r​,​s​z​a​b​k​o​.​htm, udo­stęp­nio­no 16 lipiec 2017.
[2]H. SA, J2EE. Wzorce pro­jek­to­we. Wydanie 2 [na:] ?helion​.pl?, http://​helion​.pl/​k​s​i​a​z​k​i​/​j​2​e​e​-​w​z​o​r​c​e​-​p​r​o​j​e​k​t​o​w​e​-​w​y​d​a​n​i​e​-​2​-​d​e​e​p​a​k​-​a​l​u​r​-​j​o​h​n​-​c​r​u​p​i​-​d​a​n​-​m​a​l​k​s​,​j​2​e​e​w​2​.​htm, udo­stęp­nio­no 16 lipiec 2017.