Tag: NoSQL

Wzorce projektowe Książki

Wzorce projektowe w analizie i projektowaniu modelu dziedziny systemu

Dodaj komentarz

Analiza biz­ne­so­wa i projektowanie

Wstęp

W arty­ku­le o apli­ka­cjach webo­wych, ponad rok temu, pisałem:

Generalnie klu­czo­wą cechą micro-ser­wi­­sów, czy­nią­cą z nich tak zwa­ną zwin­ną archi­tek­tu­rę, jest cał­ko­wi­ta wza­jem­na nie­za­leż­ność imple­men­ta­cji poszcze­gól­nych usług apli­ka­cyj­nych. (źr.: Aplikacje webo­we i mikro­ser­wi­sy czy­li archi­tek­tu­ra sys­te­mów webo­wych).

Przy innej oka­zji pisa­łem o wzorcach:

Wzorce pro­jek­to­we to bar­dzo waż­na część ??zawo­du? ana­li­ty­ka i archi­tek­ta opro­gra­mo­wa­nia. […] Generalnie wzor­ce są to ska­ta­lo­go­wa­ne stan­dar­dy i dobre prak­ty­ki . (Obiektowe wzor­ce projektowe ) 

Szkolenia dla ana­li­ty­ków poprze­dzam ankie­ta­mi przed szko­le­nio­wy­mi, jak do tej pory żad­na nie zawie­ra­ła pytań o wzor­ce pro­jek­to­we: ani tego że są uży­wa­ne ani tego, że są celem szko­le­nia, nie­mal­że każ­dy dekla­ru­je albo, że uży­wa UML lub, że chce zacząć uży­wać UML, nawet gdy są to pro­gra­mi­ści. Zauważyłem, że wzor­ce pro­jek­to­we w świa­do­mo­ści ana­li­zy biz­ne­so­wej i pro­jek­to­wa­nia (OOAD) ​„nie ist­nie­ją”. Wśród pro­gra­mi­stów, jeże­li jest spo­ty­ka­na, to wie­dza o wzor­cach przy­dat­nych w two­rze­niu biblio­tek i narzę­dzi, czę­sto też powie­la­ne są wyuczo­ne sta­re i złe prak­ty­ki pro­gra­mi­stycz­ne rodem z lat 60-tych (np. prak­ty­ki SmallTalk, patrz dalej). 

Z dru­giej stro­ny od wie­lu lat zna­ne są tech­ni­ki MDA (Model Driven Architecture) czy MBSE (Model Based System Engineering), któ­re w róż­nych for­mach, ale jed­nak wska­zu­ją, że naj­sku­tecz­niej­sza for­ma wyra­ża­nia wyma­gań wobec roz­wią­za­nia to pro­jekt archi­tek­tu­ry i logi­ki dzie­dzi­no­wej (model) dzia­ła­nia apli­ka­cji . O pro­jek­to­wa­niu poprze­dza­ją­cym imple­men­ta­cję pisze sie od dość daw­na, meto­dy obiek­to­we i dobre prak­ty­ki zna­ne są od lat .

Autorzy BABoK prak­tycz­nie od począt­ku ist­nie­nia tego wydaw­nic­twa, zwra­ca­ją uwa­gę na tak zwa­ną ​„bia­łą skrzyn­kę”, czy­li wyma­ga­nia wyra­żo­ne w posta­ci wewnętrz­nej struk­tu­ry pro­duk­tu, wska­zu­jąc, że to znacz­nie sku­tecz­niej­sza meto­da defi­nio­wa­nia wyma­gań wobec roz­wią­za­nia, niż tak zwa­na ​„czar­na skrzyn­ka”, czy­li tra­dy­cyj­ne, i jed­nak mniej sku­tecz­ne, wyma­ga­nia wyra­żo­ne tyl­ko jako cechy funk­cjo­nal­ne i poza-funk­cjo­nal­ne. Pamiętajmy, że adre­sa­tem wyma­gań jest zawsze dostaw­ca produktu!

Czytaj dalej… ​„Wzorce pro­jek­to­we w ana­li­zie i pro­jek­to­wa­niu mode­lu dzie­dzi­ny sys­te­mu” →
(źr. Martin Fowler, Analysis Patterns, 1997)

Koncepcja wzorca projektowego dla systemów w chmurze

2 komentarze

Wprowadzenie

W 2019 opi­sa­łem swo­istą pró­bę rewi­ta­li­za­cji wzor­ca BCE (Boundary, Control, Entity). Po wie­lu latach uży­wa­nia tego wzor­ca i dwóch latach prób jego rewi­ta­li­za­cji uzna­łem jed­nak, że 

Zarzucam pra­ce nad wzor­cem BCE. Podstawowy powód to boga­ta lite­ra­tu­ra i utrwa­lo­ne zna­cze­nia pojęć opi­su­ją­cych ten wzo­rzec. Co do zasa­dy rede­fi­nio­wa­nie utrwa­lo­nych pojęć nie wno­si nicze­go do nauki. Moja publi­ka­cja zawie­ra­ją­ca tak­że opis tego wzor­ca bazo­wa­ła na pier­wot­nych zna­cze­niach pojęć Boundary, Control, Entity. Sprawiły one jed­nak nie­co pro­ble­mu w kolej­nej publi­ka­cji na temat doku­men­tów . Dlatego w mode­lu poję­cio­wym opi­su­ją­cym role kom­po­nen­tów przy­ją­łem nastę­pu­ją­ce bazo­we stwierdzenie: 

Implementacja usłu­gi apli­ka­cyj­nej wyma­ga wymia­ny danych z oto­cze­niem (?Interface?), prze­twa­rza­nia danych (?Processing?) i ich prze­cho­wy­wa­nia (?Storage?) danych. Działania te to role kom­po­nen­tów (ich typy). Dane, dla uła­twie­nia zarzą­dza­nia nimi, są orga­ni­zo­wa­ne w doku­men­ty (?Document?). Całość może wyma­gać zarzą­dza­nia (?Management?).

Dalsze pra­ce pój­dą więc w kie­run­ku nowe­go wzor­ca a nie roz­sze­rza­nia wzor­ca BCE. (Koncepcja roz­sze­rze­nia wzor­ca pro­jek­to­we­go BCE)

BCE powstał w cza­sach świet­no­ści metod RUP (Rational Unified Process) i ICONIX . Metody te dosko­na­le paso­wa­ły do imple­men­ta­cji reali­zo­wa­nych w śro­do­wi­sku EJB (Enterprise JavaBeans). Pojęcia Boundary, Control, Entity (BCE) przy­lgnę­ły do trój­war­stwo­we­go poj­mo­wa­nia archi­tek­tu­ry apli­ka­cji (inter­fejs użyt­kow­ni­ka, logi­ka, bada danych) a poję­cie ​„robust­ness dia­gram” tak­że ma utrwa­lo­ne zna­cze­nie w lite­ra­tu­rze. Początkowo wyda­wa­ło się, że prze­nie­sie­nie tych pojęć na grunt metod obiek­to­wych i odpo­wie­dzial­no­ści klas uda sie bez koli­zji z wcze­śniej­szym sto­so­wa­niem wzor­ca BCE, jed­nak pra­ce badaw­cze i prak­ty­ka (szcze­gól­nie komu­ni­ka­cja tych mode­li) poka­za­ły, że poję­cia te, i ich zna­cze­nia, są tak moc­no ugrun­to­wa­ne w lite­ra­tu­rze, że pozo­sta­je jedy­nie uży­wa­nie ich w pier­wot­nych zna­cze­niach, jakie nada­no im pra­wie 20 lat temu (Philippe Kruchten, Rational Unified Process). Więcej na ten temat w arty­ku­le: ICONIX and Use Case Driven Object Modeling with UML.

Dużym pro­ble­mem jest tak­że migra­cja ist­nie­ją­cych apli­ka­cji z lokal­nych baz danych w mode­lu rela­cyj­nym do chmu­ry NoSQL .

Metody

Wszystkie moje pro­jek­ty badaw­cze są poprze­dza­ne ana­li­zą poję­cio­wą i meta­mo­de­lo­wa­niem. Dzięki temu każ­dy pro­jekt ana­li­tycz­ny jest obiek­ty­wi­zo­wa­ny w mak­sy­mal­nie moż­li­wy spo­sób, zaś pro­duk­ty pro­jek­to­wa­nia odpor­ne na zmien­ność śro­do­wi­ska. Ta odpor­ność, bie­rze się stad, że pra­wi­dło­wo opi­sa­ne dane to okre­ślo­ne zamknię­te struk­tu­ry danych wraz z ich kon­tek­stem: doku­men­ty (for­mu­la­rze). Jeżeli uzna­my, że nasz język (np. pol­ski) się nie zmie­nia, a zmie­nia sie jedy­nie to co z jego uży­ciem opi­su­je­my, to zna­czy, że moż­li­we jest zapi­sa­nie i prze­twa­rza­nie infor­ma­cji o świe­cie, i że nie opis ten (jego struk­tu­ra) nie będzie wyma­gał zmian w przy­szło­ści. Dane opi­su­ją­ce świat to zbio­ry pojęć sta­no­wią­ce okre­ślo­ne struk­tu­ry (zda­nia, aka­pi­ty, doku­men­ty) a nie poje­dyn­cze sło­wa połą­czo­ne rela­cja­mi . Trudna do prze­tłu­ma­cze­nia na język pol­ski nazwa dzie­dzi­ny nauki: infor­ma­tion scien­ce , to obszar wie­dzy zaj­mu­ją­cy się infor­ma­cją i jej prze­twa­rza­niem, co nie jest toż­sa­me z prze­twa­rza­niem danych (w języ­ku pol­skim nazy­wa­ne infor­ma­ty­ka). Korzystam tu tak­że z dorob­ku tej dzie­dzi­ny nauki: są nią mode­le poję­cio­we, onto­lo­gie i rachu­nek zdań (ana­li­za i budo­wa­nie struk­tur dokumentów). 

Rezultat

Ten opis to wstęp­na wer­sja, gene­ra­li­za­cja doświad­cze­nia zakoń­czo­nych suk­ce­sem imple­men­ta­cji i wdro­żeń. Praktyka poka­za­ła, że kla­sy­fi­ku­jąc kom­po­nen­ty apli­ka­cji, kie­ru­jąc się ich odpo­wie­dzial­no­ścią , otrzy­ma­my trzy klu­czo­we role kom­po­nen­tów: prze­twa­rza­nie, zarzą­dza­nie prze­twa­rza­niem, prze­cho­wy­wa­nie. To ostat­nie to prze­cho­wa­nie danych w ​„pacz­kach” zor­ga­ni­zo­wa­nych kon­tek­sto­wo jako doku­men­ty . Z uwa­gi na to, że ini­cja­to­rem uży­cia usłu­gi jest aktor ​„użyt­kow­nik”, obli­ga­to­ryj­nym ele­men­tem apli­ka­cji jest inter­fejs użyt­kow­ni­ka (GUI, Graphical User Interface). Opis ten moż­na zobra­zo­wać tak (UML):

Struktura klu­czo­wych kom­po­nen­tów apli­ka­cji (robo­cza nasza MPS: Management, Processing, Storage) jako PIM (Platform Independent Model)

Tym co róż­ni ten model od wzor­ca BCE jest rezy­gna­cja z war­stwo­wo­ści (narzu­co­nej kolej­no­ści wywo­ły­wa­nia kom­po­nen­tów). Wzorzec BCE (poni­żej) jest zor­ga­ni­zo­wa­ny w ​„linię pro­duk­cyj­ną” z zaka­zem omi­ja­nia jej elementów:

Diagram: Wzorzec architektoniczny BCE Wzorzec BCE (Boundary, Control, Entity) w swojej pierwotnej wersji (Rosenberg 2005) zakłada, że komponenty aplikacyjne mają (realizują) jedną z trzech odpowiedzialności: Boundary to interfejs komponentu, Control to logika biznesowa, Entity to utrwalanie. Początkowo był interpretowany jako trójwarstwowe podejście do aplikacji (odpowiednio: interfejs, logika, dane) zgodnie z podejściem "aplikacja to funkcje i dane". Później rozszerzono zastosowanie wraz ze wzorcem MVC (Rosenberg 2007). Wzorzec ten jednak jest bardzo ogólny i nie pozwala na precyzyjniejsze modelowanie ról. Z tego powodu bardzo szybko projektanci przechodzili do modelowania detali takich jak operacje i atrybuty klas i do implementacji, co w dużych projektach często prowadzi do szybkiego "zalania" projektu szczegółami. Ikony na diagramie Wzorzec architektoniczny BCE to graficzne reprezentacje stereotypów, klasy notacji UML.
Struktura archi­tek­tu­ry usłu­gi apli­ka­cji na bazie wzor­ca BCE

Wzorzec, któ­ry wstęp­nie nazwa­łem MPS, to przede wszyst­kim spe­cja­li­zo­wa­ne kom­po­nen­ty prze­twa­rza­ją­ce, któ­rych uży­cie jest zarzą­dza­ne. Utrwalanie zosta­ło cał­ko­wi­cie pozba­wio­ne prze­twa­rza­nia: logi­ka biz­ne­so­wa jest w 100% reali­zo­wa­na w kom­po­nen­tach «pro­ces­sing». To klu­czo­wa zale­ta takie­go podej­ścia: nie­za­leż­ność od imple­men­ta­cji prze­cho­wy­wa­nia. Z tego powo­du w tytu­le doda­łem sło­wo ​„chmu­ra”, gdyż to czy jest to chmu­ra pry­wat­na czy publicz­na nie powin­no mieć tu zna­cze­nia, i nie ma.

Wieloletnie doświad­cze­nie pro­jek­to­we nauczy­ło mnie tak­że, że zna­ne od lat podej­ście zna­ne jako mikro­ser­wi­sy, zakła­da­ją­ce w usłu­gach ​„wła­sność lokal­nej bazy danych”, sta­no­wi takie samo ogra­ni­cze­nie jak ​„wła­sne baza danych” w sys­te­mach mono­li­tycz­nych, tyle że na nie­co mniej­szą skalę.

Opisane tu kom­po­nen­ty są czę­ścią archi­tek­tu­ry całej apli­ka­cji. Opierając się na zało­że­niach MDA (Model Driven Architecture) oraz wzor­cu archi­tek­to­nicz­nym MVC (Model, View, Controller) , moż­na wstęp­nie tak zobra­zo­wać abs­trak­cyj­ną archi­tek­tu­rę aplikacji:

Abstrakcja archi­tek­tu­ry aplikacji.

Dolna część dia­gra­mu to pre­zen­to­wa­ny na począt­ku arty­ku­łu model PIM. Jednak po uzu­peł­nie­niu go o struk­tu­rę wzor­ca MVC mozna uznać, że: 1. GUI to reali­za­cja kom­po­nen­tu View, 2. Model jest reali­zo­wa­ny przez logi­kę repre­zen­to­wa­ną przez kom­po­nen­ty «Management» oraz «Processing», ele­ment «Document» to nazwa­na struk­tu­ra danych (for­mu­larz) sta­no­wią­cy zawsze argu­ment wywo­łań (peł­ni tu DTO: Data Transfer Object). Komponent «Storage» to albo wła­sny sys­tem utrwa­la­nia apli­ka­cji (jej śro­do­wi­ska), albo API sys­te­mu utrwa­la­nia w chmu­rze pry­wat­nej lub publicz­nej (patrz arty­kuł Repozytorium w chmu­rze). To dzię­ki temu migra­cja z lokal­nej do publicz­nej chmu­ry sta­no­wi wyłącz­nie prze­adre­so­wa­nie wywo­łań i jed­no­ra­zo­we prze­nie­sie­nie danych. Dość powszech­nie sto­so­wa­ny wzo­rzec pro­jek­to­wy ​„repo­si­to­ry” tu jest podzie­lo­ny na dwie czę­ści: «Management» Kontrola dostę­pu do danych oraz «Storage» jako Repozytorium danych. To ostat­nie to wła­śnie opi­sa­ne wcze­śniej chmu­ro­we repo­zy­to­ria. 3. Controller to śro­do­wi­sko wyko­naw­cze odpo­wia­da­ją­ce za komu­ni­ka­cję z oto­cze­niem apli­ka­cji, np. inte­gra­cję z inny­mi apli­ka­cja­mi: Aktor «appli­ca­tion».

Model PIM: to co nale­ży zapro­jek­to­wać, two­rząc nową apli­ka­cję, jako wyma­ga­nie na eta­pie poprze­dza­ją­cym imple­men­ta­cję (czy­li wybór tech­no­lo­gii tak­że), wyglą­da tu tak:

Uproszczona struk­tu­ra wzor­ca archi­tek­to­nicz­ne­go MPS

Oczywiście licz­ba poszcze­gól­nych typów kom­po­nen­tów zale­ży od kon­kret­ne­go przypadku. 

Po co nam takie wzor­ce? Przed wszyst­kim by mieć od cze­go zacząć, coś co u wie­lu auto­rów nazy­wa jest ​„star­ting point” (punkt wyj­ścia). Po dru­gie narzu­ca pewien porzą­dek, oraz pozwa­la uzy­skać pod­sta­wo­wą cechę dobre­go opro­gra­mo­wa­nia: apli­ka­cja (jej archi­tek­tu­ra) jest otwar­ta na roz­sze­rze­nia i zamknię­ta na mody­fi­ka­cje (patrz Open Closed Principle). No i po trze­cie, sto­so­wa­nie regu­ły mówią­cej, że jeden kom­po­nent ma jed­ną dedy­ko­wa­ną rolę w sys­te­mie, bar­dzo uła­twia sto­so­wa­nie dostęp­nych na ryn­ku, goto­wych kom­po­nen­tów (zarów­no płat­nych i open­so­ur­ce). Uzyskujemy tak­że łatwość zarzą­dza­nia licen­cja­mi (odse­pa­ro­wa­ne kom­po­nen­ty to odse­pa­ro­wa­ne pra­wa do nich, łatwo nimi zarzą­dzać, a w razie koniecz­no­ści zastą­pić inny­mi). Warto tu pod­kre­ślić, że z per­spek­ty­wy kosz­tów: od kosz­tów wytwo­rze­nia apli­ka­cji, znacz­nie waż­niej­sze są kosz­ty jej utrzy­ma­nie i rozwoju. 

Podsumowanie i dalsze prace

Opisany tu wzo­rzec archi­tek­to­nicz­ny to wstęp­na pro­po­zy­cja upo­rząd­ko­wa­nia archi­tek­tu­ry apli­ka­cji. Wprowadzony tu ele­ment «Management» to uogól­nie­nie wzor­ca zna­ne­go jako ​„saga”. Jest to roz­wią­za­nie pro­ble­mu trans­ak­cyj­no­ści w sys­te­mach opar­tych na mikro­ser­wi­sach i tak­że sys­te­mach NoSQL, gdzie repo­zy­to­ria nie reali­zu­ją żad­nej logi­ki, nawet tej odpo­wie­dzial­nej za spój­ność danych (co czę­sto jest wska­zy­wa­ne jako wada tych repozytoriów).

Dalsze pra­ce są obec­nie ukie­run­ko­wa­ne na testy sku­tecz­no­ści tego wzor­ca w roz­wią­zy­wa­niu pro­ble­mów sys­te­mów, prze­trzy­mu­ją­cych dane w chmu­rach. Celem auto­ra jest opra­co­wa­nie meta­mo­de­lu sta­no­wią­ce­go roz­wią­za­nie pro­ble­mów zarzą­dza­nia duży­mi, wie­lo­dzie­dzi­no­wy­mi zbio­ra­mi danych.

Źródła

OMG​.org. (2014, June 18). Model Driven Architecture (MDA). https://​www​.omg​.org/​m​da/
Zelinski, J. (2020). Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns. In Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities (pp. 78 – 89). IGI Global. https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​a​p​p​l​i​c​a​t​i​o​n​s​-​a​p​p​r​o​a​c​h​e​s​-​o​b​j​e​c​t​-​o​r​i​e​n​t​e​d​-​s​o​f​t​w​a​r​e​/​2​3​5​699
Zelinski, J. (2021). Digital docu­ments as data car­riers and a method of data mana­ge­ment guaran­te­eing the unam­bi­gu­ity of the recor­ded infor­ma­tion. In Management and Strategies for Digital Enterprise Transformation (Vol. 1). IGI Global. https://​www​.igi​-glo​bal​.com/​c​h​a​p​t​e​r​/​d​i​g​i​t​a​l​-​d​o​c​u​m​e​n​t​s​-​a​s​-​d​a​t​a​-​c​a​r​r​i​e​r​s​-​a​n​d​-​a​-​m​e​t​h​o​d​-​o​f​-​d​a​t​a​-​m​a​n​a​g​e​m​e​n​t​-​g​u​a​r​a​n​t​e​e​i​n​g​-​t​h​e​-​u​n​a​m​b​i​g​u​i​t​y​-​o​f​-​t​h​e​-​r​e​c​o​r​d​e​d​-​i​n​f​o​r​m​a​t​i​o​n​/​2​7​5​700
Hjørland, B. (2021). Information Retrieval and Knowledge Organization: A Perspective from the Philosophy of Science. Information, 12(3), 135. https://​doi​.org/​1​0​.​3​3​9​0​/​i​n​f​o​1​2​0​3​0​135
Hjùrland, B. (2001). Domain ana­ly­sis in infor­ma­tion scien­ce.
Borko, H. (1968). Information scien­ce: what is it? American Documentation, 19(1), 3 – 5.
Hamouda, S., & Zainol, Z. (2017). Document-Oriented Data Schema for Relational Database Migration to NoSQL. https://​doi​.org/​1​0​.​1​1​0​9​/​I​n​n​o​v​a​t​e​-​D​a​t​a​.​2​0​1​7​.13
Rosenberg, D., & Scott, K. (1999). Use case dri­ven object mode­ling with UML. Springer.
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
Steve Burbeck. (2012, July 29). How to use Model-View-Controller (MVC). https://web.archive.org/web/20120729161926/http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html
Wirfs-Brock, R., & McKean, A. (2009). Object design: roles, respon­si­bi­li­ties, and col­la­bo­ra­tions. Addison-Wesley.
Rosenberg, D., Stephens, M., & Collins-Cope, M. (2005). Agile deve­lop­ment with ICONIX pro­cess: people, pro­cess, and prag­ma­tism. Apress.

Bazy NoSQL jako implementacje wzorców struktur informacji

4 komentarze

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.
Diagram of rows and columns in a wide column store database.
(źr. https://​data​ba​se​.guide/​w​h​a​t​-​i​s​-​a​-​c​o​l​u​m​n​-​s​t​o​r​e​-​d​a​t​a​b​a​se/)
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:

(źr.: https://​neo​4j​.com/​d​e​v​e​l​o​p​e​r​/​g​r​a​p​h​-​d​a​t​a​b​a​se/)

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
Zelinski, J. (2021). Digital docu­ments as data car­riers and a method of data mana­ge­ment guaran­te­eing the unam­bi­gu­ity of the recor­ded infor­ma­tion. In Management and Strategies for Digital Enterprise Transformation (Vol. 1). IGI Global. https://​www​.igi​-glo​bal​.com/​c​h​a​p​t​e​r​/​d​i​g​i​t​a​l​-​d​o​c​u​m​e​n​t​s​-​a​s​-​d​a​t​a​-​c​a​r​r​i​e​r​s​-​a​n​d​-​a​-​m​e​t​h​o​d​-​o​f​-​d​a​t​a​-​m​a​n​a​g​e​m​e​n​t​-​g​u​a​r​a​n​t​e​e​i​n​g​-​t​h​e​-​u​n​a​m​b​i​g​u​i​t​y​-​o​f​-​t​h​e​-​r​e​c​o​r​d​e​d​-​i​n​f​o​r​m​a​t​i​o​n​/​2​7​5​700
Robinson, I., Webber, J., & Eifrem, E. (2015). Graph data­ba­ses (Second edi­tion). O’Reilly. http://​ore​il​ly​.com/​c​a​t​a​l​o​g​/​e​r​r​a​t​a​.​c​s​p​?​i​s​b​n​=​9​7​8​1​4​9​1​9​3​0​892
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.
Martin Fowler. (2012, January 9). bli­ki: NosqlDefinition. Martinfowler​.Com. https://​mar​tin​fow​ler​.com/​b​l​i​k​i​/​N​o​s​q​l​D​e​f​i​n​i​t​i​o​n​.​h​tml
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

Repozytorium w chmurze – NoSQL

8 komentarzy

Wprowadzenie

Coraz czę­ściej czy­ta­my o śro­do­wi­skach ​„chmu­ro­wych” (nadal nie mogę się prze­ko­nać do pisa­nia tego bez cudzy­sło­wu). Nawet tak zaawan­so­wa­ne jak Amazon WS czy AZURE, są nadal bar­dzo czę­sto wyko­rzy­sty­wa­ne tyl­ko jako hosting apli­ka­cji. Oba te ser­wi­sy moż­na wyko­rzy­sty­wać jako sie­cio­wy dysk, śro­do­wi­sko sys­te­mo­we (Windows, Linux), bazę danych SQL, ale tak­że jako bazy NoSQL. 

Jednym z naj­istot­niej­szych ele­men­tów sys­te­mów infor­ma­cyj­nych (patrz: infor­ma­tion scien­ce) jest utrwa­la­nie danych (pamię­taj­my, że dane to zapi­sy, a infor­ma­cja to to, co rozu­mie czło­wiek, któ­ry je czy­ta). Niedawno nawią­zy­wa­łem do pro­ble­mu utrwa­la­nia danych.

Poprawna obiek­to­wa archi­tek­tu­ra i kom­plet­ny pro­jekt tech­nicz­ny apli­ka­cji (model PIM) opi­su­je pre­cy­zyj­nie jak wyko­nać imple­men­ta­cje i nie zawie­ra pro­jek­tu żad­nej bazy danych, ani tym bar­dziej zapy­tań SQL. Implementacja utrwa­la­nia nie może mieć wpły­wu na logi­kę biz­ne­so­wą sys­te­mu ani nawet zawie­rać jej! (źr.: Dokument a kumu­la­cja fak­tów: OOAD i model dzie­dzi­ny sys­te­mu) Prosty dia­gram po lewej stro­nie poka­zu­je pro­blem opi­sa­ny przez Smith’a jako ​„Computers, Models, and the Embedding World, The Limits of Correctness.” 

Komputer (rozu­mia­ny jako pro­ce­sor, pamięć i pro­gram) sta­no­wi dla czło­wie­ka narzę­dzie pracy. 

Cechą kom­pu­te­ra jest w ogrom­nej więk­szo­ści przy­pad­ków odwzo­ro­wy­wa­nie tego co zastę­pu­je­my kom­pu­te­rem, a tak zwa­ne sys­te­my biz­ne­so­we, zastę­pu­ją papie­ro­we for­my prze­twa­rza­nia i prze­cho­wy­wa­nia infor­ma­cji. Systemy ERP, CRM, Workflow, Sklepy inter­ne­to­we, Archiwa, i wie­le innych to tak na praw­dę doku­men­ty i ich treść. 

Istota pro­ble­mu pole­ga na tym, że okre­ślo­ne, dostęp­ne tech­no­lo­gie same z sie­bie czę­sto stwa­rza­ją ogra­ni­cze­nia tego co mogą (potra­fią) odwzo­ro­wać, i mimo upły­wu cza­su i postę­pu tech­no­lo­gii, ana­li­za i pro­jek­to­wa­nie zarzą­dza­nia infor­ma­cją nadal jest jed­nym z naj­więk­szych pro­ble­mów wdro­żeń systemów. 

SQL vs. NoSQL

SQL

Skrót NoSQL jest inte­pre­to­wa­ny jako ​„nie SQL” lub ​„nie tyl­ko SQL” (Not only SQL). SQL (Structured Query Language) to język zapy­tań do baz danych o rela­cyj­nym mode­lu danych (ang. RDBMS: Relational Data Base Management System). Cechą tego mode­lu danych jest usu­wa­nie redun­dan­cji i podział danych na tabe­le i słow­ni­ki pól tych tabel, oraz związ­ki mię­dzy nimi (rela­cje). W efek­cie otrzy­mu­je­my sche­ma­ty tabel i rela­cji mię­dzy nimi np. takie:

A nawet takie:

(model danych pew­ne­go sys­te­mu ERP)

Odtworzenie doku­men­tu (for­mu­la­rza) będą­ce­go np. fak­tu­rą lub dekla­ra­cją podat­ko­wą, wyma­ga wyko­na­nia sze­re­gu bar­dzo skom­pli­ko­wa­nych ope­ra­cji łącze­nia danych z tych tabel i odwzo­ro­wa­nia ich pier­wot­nej posta­ci np. fak­tu­ry. W tego typu bazach danych fizycz­nie nie ma żad­nych dokumentów. 

Drugim pro­ble­mem jaki stwa­rza model rela­cyj­ny, jest koniecz­ność jego prze­bu­do­wy prak­tycz­nie zawsze, gdy zmie­ni się struk­tu­ra prze­cho­wy­wa­nych w nim doku­men­tów (opra­co­wa­nie nowe­go mode­lu, migra­cja danych do nowe­go mode­lu – bywa że nie­moż­li­wa w 100%, aktu­ali­za­cja zapy­tań SQL do nowej struk­tu­ry bazy danych). 

Biorąc pod uwa­gę fakt, że real­ny świat to cią­głe zmia­ny, model rela­cyj­ny jest w tym przy­pad­ku po pro­stu nieadekwatny. 

Koszty utrzy­ma­nia i roz­wo­ju sys­te­mów zarza­dza­nia dany­mi (i apli­ka­cja­mi, któ­re je wyko­rzy­stu­ją) w mode­lu rela­cyj­nym, są wie­lo­krot­nie wyż­sze niż pier­wot­ne ich wdro­że­nie .

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óż­ni­ca. (źr.: SQL albo NoSQL, oto jest pyta­nie – 2011 r.)

NoSQL

Jednym z typo­wych przy­kła­dów bazy danych typu NoSQL są bazy typu key-value i ich odmia­ny . Z uwa­gi na ich cechy i powszech­ność sku­pię się na tego typu bazach. 

Wśród tego typu baz są tak zwa­ne bazy doku­men­to­we. Idea tego typu baz danych reali­zu­je jed­no pod­sta­wo­wych zało­żeń obiek­to­we­go para­dyg­ma­tu (role obiek­tów): repo­zy­to­rium nie słu­ży do prze­twa­rza­nia tre­ści a jedy­nie do jej utrwa­la­nia i szyb­kie­go przy­wo­ły­wa­nia (dostę­pu). Przetwarzaniem danych (tre­ści) zaj­mu­ją kom­po­nen­ty odpo­wie­dzial­ne wyłącz­nie za reali­za­cję logi­ki apli­ka­cji. Skoro repo­zy­to­rium nie prze­twa­rza tre­ści, jest ono – prze­cho­wy­wa­na treść i jej struk­tu­ra – neu­tral­nym ele­men­tem. Dlatego ope­ru­je­my tu czę­sto poję­ciem plik, któ­rym zależ­nie od typu bazy, może być np. ciąg zna­ków XML lub JSON albo po pro­stu ciąg binar­ny (czy­li ​„cokol­wiek”). Taka baza to hipo­te­tycz­ne dwie kolum­ny: pierw­sza zawie­ra iden­ty­fi­ka­to­ry wier­szy a dru­ga prze­cho­wy­wa­ną treść. I teraz zależ­nie od typu bazy i logi­ki apli­ka­cji, któ­ra ją wyko­rzy­stu­je, tą tre­ścią może by ciąg zna­ków (np. XML, JSON) lub dowol­ny ciąg zna­ków binar­ny (czy­li XML tak­że, ale tak­że np. zdję­cie lub plik edy­to­ra tekstów). 

Przykładem bazy doku­men­to­wej jest Amazon DynamoDB. Poniższy dia­gram poka­zu­je w uprosz­cze­niu idee tej bazy i porów­na­nie z typo­wą mode­lem rela­cyj­nym: odtwo­rze­nie doku­men­tu z bazy rela­cyj­nej (po lewej) wyma­ga skom­pli­ko­wa­nych ope­ra­cji łącze­nia tabel, po pra­wej stro­nie mamy zaś zestaw cią­gów zna­ków, każ­dy sta­no­wi sobą kom­plet­ny już doku­ment, mogą one mieć róż­ną struk­tu­rę. Pobranie doku­men­tu z bazy po pra­wej odby­wa się zawsze pro­stym zapy­ta­niem, takim samym„ bez wzglę­du na struk­tu­rę tych danych. 

Dzięki temu osią­ga­my dwie klu­czo­we korzy­ści: zmie­nia­ją­ca się w cza­sie struk­tu­ra doku­men­tów nie wpły­wa na bazę danych, czas pobra­nia doku­men­tu jest bar­dzo krót­ki i nie zale­ży od struk­tu­ry doku­men­tu . Różnicę efek­tyw­no­ści poka­za­no poniżej:



Dokument jako struktura danych

Opisane bazy NoSQL mają sze­reg zalet w sto­sun­ku do baz danych w mode­lu rela­cyj­nym. Jednak pro­blem two­rze­nia mode­li rela­cyj­nych jest zastę­po­wa­ny pro­ble­mem mode­lo­wa­nia struk­tur doku­men­tów . Nie jest to jed­nak pro­blem budo­wa­nia znor­ma­li­zo­wa­nych rela­cyj­nych struk­tur danych. Jest to pro­blem natu­ry czy­sto seman­tycz­nej: rzecz w tym czym jest doku­ment i czym są pola, z któ­rych on się skła­da. Jest wie­le podejść do tego zagad­nie­nia, uwa­żam, że klu­czo­we jest odkry­cie i zro­zu­mie­nie co opi­su­je dany doku­ment. Po dru­gie istot­ne jest umie­jęt­ne zapro­jek­to­wa­nie logi­ki apli­ka­cji. Dlatego repo­zy­to­ria NoSQL z zasa­dy nie bio­rą udzia­łu w logi­ce biz­ne­so­wej ale struk­tu­ra doku­men­tów deter­mi­nu­je logi­kę ich prze­twa­rza­nia. Rolą repo­zy­to­rium jest wyłącz­nie utrwa­la­nie i udo­stęp­nia­nie. Poniżej przy­kład dość typo­wy: fak­tu­ry i opi­sy pro­duk­tów (opis pro­duk­tu jako Karta Produktu): mimo tego, że oba te typy doku­men­tów mają inną struk­tu­rę, mogą być prze­cho­wy­wa­ne w jed­nej i tej samej bazie danych NoSQL. 

Rejestry sepa­ru­ją­ce doku­men­to­wą bazę danych od logi­ki apli­ka­cyj­nej, dia­gram pocho­dzi z wyda­nej wła­śnie publi­ka­cji, w któ­rej dokład­nie opi­sa­no zasa­dy pro­jek­to­wa­nia sys­te­mów infor­ma­cyj­nych i tego typu repo­zy­to­riów: .

Baza doku­men­to­wa słu­ży wyłącz­nie do prze­cho­wy­wa­nia danych. Kontekstowy i seman­tycz­ny dostęp do danych zapew­nia­ją dzie­dzi­no­we reje­stry: dodat­ko­we pro­ste tabe­le umiesz­czo­ne przez repo­zy­to­rium, w czę­ści apli­ka­cyj­nej. Z uwa­gi na to, że bazy doku­men­to­we nie nada­ją się do reali­za­cji wyra­fi­no­wa­nych zbio­ro­wych obli­czeń na tre­ści doku­men­tów, wyko­rzy­stu­je się do tego typo­we hur­tow­nie danych. 

[uzu­peł­nie­nie mie­siąc póź­niej] Z tego wzglę­du bar­dzo przy­dat­ny jest tu dobrze zna­ny wzo­rzec pro­jek­to­wy Repozytorium (Repository). Istotą tego wzor­ca jest sepa­ra­cja kolek­cji obiek­tów (np. nośni­ków doku­men­tów) od logi­ki apli­ka­cji za pomo­cą kla­sy reali­zu­ją­cej inter­fejs do tej kolek­cji. Poniżej wer­sja adre­so­wa­na do chmury:

Wzorzec kon­cep­cyj­ny sys­te­mu (źr: Koncepcja wzor­ca pro­jek­to­we­go dla sys­te­mów w chmu­rze)

Realizacja utrwa­la­nia (zapis danych) to obiek­ty prze­cho­wu­ją­ce («Storage» Repozytorium danych) oraz dane («docu­ment» Zestaw danych) prze­cho­wy­wa­ne jako doku­men­ty (XML, JSON) lub pli­ki (baza key value). Dostęp do tej kolek­cji zapew­nia kla­sa «Management» Kontrola dostę­pu do danych, sta­no­wią­ca zara­zem inter­fejs do tej kolek­cji. Interfejsów do jed­ne­go repo­zy­to­rium może być wię­cej, reali­zu­ją one wte­dy kon­tek­sto­we udo­stęp­nia­nie danych z tej samej kolek­cji. Tak więc Realizacja usłu­gi to dzie­dzi­no­wy kod apli­ka­cji, zaś Realizacja utrwa­la­nia to chmu­ro­wa usłu­ga taka jak bazy NoSQL dostęp­ne w chmurze. 

Chmury Amazon i AZURE

Ciekawym przy­kła­dem bazy doku­men­to­wej jest DynamoDB. Jest to par­ty­cjo­no­wa­na baza NoSQL mają­ca dwie kolum­ny z klu­czem: jeden to stan­dar­do­wy dla tego typu bazy iden­ty­fi­ka­tor, dru­gi to klucz wska­zu­ją­cy na struk­tu­rę defi­niu­ją­cą for­mat danych w trze­ciej kolum­nie prze­cho­wu­ją­cej dane (doku­men­ty). Jest to baza prze­cho­wu­ją­ca dane w for­ma­cie JSON, więc ich inter­pre­ta­cja wyma­ga defi­ni­cji kon­kret­nej struk­tu­ry danych. dodat­ko­wa kolum­na (SortKey) peł­ni rolę defi­ni­cji typu (iden­ty­fi­ka­tor struk­tu­ry). Jest to wygod­ne bo w sys­te­mach obiek­to­wych łatwo defi­niu­je się typy zło­żo­ne, nada­jąc każ­de­mu rekor­do­wi dodat­ko­wy iden­ty­fi­ka­tor, moż­na inte­pre­to­wać pobra­ne dane. 

(https://​aws​.ama​zon​.com/​b​l​o​g​s​/​d​a​t​a​b​a​s​e​/​c​h​o​o​s​i​n​g​-​t​h​e​-​r​i​g​h​t​-​d​y​n​a​m​o​d​b​-​p​a​r​t​i​t​i​o​n​-​k​ey/)

Więcej infor­ma­cji o repo­zy­to­riach Amazon, tak­że Amazon S3 (bar­dzo szyb­ka baza pli­ków) znaj­dzie­cie w książ­ce wydaw­nic­twa Helion: Amazon Web Services . Analogiczne roz­wią­za­nie ofe­ru­je AZURE.

Na zakończenie

Osobiście pole­cam roz­wa­że­nie opi­sa­nych tu roz­wią­zań w swo­ich pro­jek­tach. W obsza­rze doku­men­tów i zarzą­dza­nia ich tre­ścią są wręcz dosko­na­łe. Model rela­cyj­ny, dosko­na­ły do obli­czeń, nie­ste­ty prze­gry­wa z kre­te­sem w apli­ka­cjach biz­ne­so­wych, gdzie zaczy­na się liczyć przede wszyst­kim szyb­kość dostę­pu do ogrom­nej ilo­ści danych oraz odpor­ność na szyb­ko zmie­nia­ją­ce się wyma­ga­nia co do struk­tu­ry danych.

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.

C.d. czy­taj Bazy NoSQL jako imple­men­ta­cje wzor­ców struk­tur infor­ma­cji.

Źródła

Zelinski, J. (2021). Digital docu­ments as data car­riers and a method of data mana­ge­ment guaran­te­eing the unam­bi­gu­ity of the recor­ded infor­ma­tion. In Management and Strategies for Digital Enterprise Transformation (Vol. 1). IGI Global. https://​www​.igi​-glo​bal​.com/​c​h​a​p​t​e​r​/​d​i​g​i​t​a​l​-​d​o​c​u​m​e​n​t​s​-​a​s​-​d​a​t​a​-​c​a​r​r​i​e​r​s​-​a​n​d​-​a​-​m​e​t​h​o​d​-​o​f​-​d​a​t​a​-​m​a​n​a​g​e​m​e​n​t​-​g​u​a​r​a​n​t​e​e​i​n​g​-​t​h​e​-​u​n​a​m​b​i​g​u​i​t​y​-​o​f​-​t​h​e​-​r​e​c​o​r​d​e​d​-​i​n​f​o​r​m​a​t​i​o​n​/​2​7​5​700
Harley Vera, Wagner Boaventura, Maristela Holanda, Valeria Guimaraes, & Fernanda Hondo. (2015). Data Modeling for NoSQL Document-Oriented Databases. CEUR Workshop Proceedings, 1478, 129 – 135.
Garba, M. (2020). A Comparison of NoSQL and Relational Database Management Systems (RDBMS). 1(2), 9.
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
Wilkins, M. (2020). Amazon Web Services: pod­sta­wy korzy­sta­nia z chmu­ry AWS (J. Zatorska, Trans.). Helion SA.
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
Smith, B. C. (1985). The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18 – 26. https://​doi​.org/​1​0​.​1​1​4​5​/​3​7​9​4​8​6​.​3​7​9​512

SQL albo NoSQL, oto jest pytanie

Dodaj komentarz

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: