Profil UML i meta-model typów doku­men­tów jako sys­tem orga­ni­za­cji danych. Dokument jako kon­tek­sto­wa struk­tu­ra informacyjna. 

Streszczenie: Opisano spraw­dzo­na w prak­ty­ce meto­dę skła­do­wa­nia danych zor­ga­ni­zo­wa­nych w doku­men­ty. Opisana meto­da nie ma wad rela­cyj­ne­go mode­lu orga­ni­za­cji danych, jakim jest utra­ta kon­tek­stu danych i kom­pli­ka­cje wywo­ła­ne bra­kiem redun­dan­cji danych. W pra­cy tej przed­sta­wio­no meto­dę orga­ni­za­cji danych w doku­men­ty jako skla­sy­fi­ko­wa­ne agre­ga­ty, meto­dę ich kla­sy­fi­ka­cji oraz meta­mo­del ich budo­wy. Opisany meta­mo­del zakła­da, że doku­men­ty jako struk­tu­ry danych to zwar­te agre­ga­ty, kla­sy­fi­ko­wa­ne jako opi­sy obiek­tów (object) lub wyda­rzeń (events) co nada­je im zawsze okre­ślo­ny i jed­no­znacz­ny kon­tekst. Opisano tak­że meto­dę pro­jek­to­wa­nia doku­men­tów jako agre­ga­tów kon­tek­sto­wych, co pozwa­la zni­we­lo­wać wska­za­ne wady mode­lu rela­cyj­ne­go oraz zagwa­ran­to­wać sku­tecz­ność zarzą­dza­nia infor­ma­cją. Dodatkowo opi­sa­ny model roz­wią­zu­je pro­ble­my zarzą­dza­nia dostę­pem do danych poprzez okre­śla­nie dostę­pu do całe­go kon­tek­sto­we­go doku­men­tu, a nie do poszcze­gól­nych pól. Dzięki temu zarzą­dza­nie dostę­pem do danych sta­je się znacz­nie prostsze.

Słowa klu­czo­we: sys­te­my infor­ma­cyj­ne, inży­nie­ria opro­gra­mo­wa­nia, bazy danych, BCE, agre­gat, meto­dy obiek­to­we, para­dyg­mat obiek­to­wy, inży­nie­ria sys­te­mów, DDD, aggregate

1. Wprowadzenie

W wie­lu pro­jek­tach, któ­rych celem jest zarzą­dza­nie infor­ma­cją i prze­twa­rza­nie jej, poja­wia się pro­blem z opra­co­wa­niem mode­lu danych. Często a prio­ri przyj­mu­je się, że doku­men­ty to infor­ma­cja orga­ni­zo­wa­na w posta­ci for­mu­la­rzy zło­żo­nych z okre­ślo­nych pól, a te będą prze­cho­wy­wa­ne w mode­lu rela­cyj­nym [Shimura, T., Yoshikawa, M., Uemura, S., 1999]. Model ten pro­wa­dzi do sytu­acji gdzie: <doku­ment> = <zbiór danych w mode­lu rela­cyj­nym> + <zapy­ta­nie SQL do tego zbio­ru>. Innymi sło­wy doku­men­ty to dyna­micz­nie gene­ro­wa­ne tre­ści, nie ist­nie­ją­ce jako trwa­łe byty. Dla roz­bu­do­wa­nych mode­li danych pro­ce­du­ry nazwa­ne <zapy­ta­nie SQL do tego zbio­ru> są bar­dzo zło­żo­ne i ich wyko­na­nie gene­ru­je duże zapo­trze­bo­wa­nie na czas i moc pro­ce­so­ra. Ich opra­co­wa­nie i testo­wa­nie jest kosz­tow­ne, bo zaj­mu­je wie­le cza­su spe­cja­li­stów, któ­rzy je two­rzą. Nie mniej kosz­tow­ne jest wpro­wa­dza­nie do nich zmian w cyklu życia oprogramowania.

Dokumenty bar­dzo czę­sto zawie­ra­ją bar­dzo wie­le róż­nych infor­ma­cji sta­no­wią­cych sobą zło­żo­ne wie­lo­kon­tek­sto­we zesta­wy (agre­ga­ty) danych. Zastosowanie mode­lu rela­cyj­ne­go do orga­ni­zo­wa­nia takich infor­ma­cji, pro­wa­dzi do powsta­nia zło­żo­ne­go sys­te­mu powią­za­nych rela­cyj­nie tabel a usu­wa­nie redun­dan­cji pro­wa­dzi czę­sto utra­ty kon­tek­stu tre­ści poszcze­gól­nych pól w tabe­lach. W kon­se­kwen­cji poja­wia się koniecz­ność sto­so­wa­nia bar­dzo zło­żo­nych zapy­tań w języ­ku SQL, by doku­men­ty te zapi­sy­wać w takiej bazie i odtwa­rzać z niej. W samej bazie są to tyl­ko pozba­wio­ne kon­tek­stu dane w tabe­lach a nie dokumenty.

Wielu auto­rów zwra­ca uwa­gę na pro­blem zło­żo­no­ści i utra­ty kon­tek­stu jed­no­li­tych mode­li rela­cyj­nych, zale­ca­jąc sepa­ro­wa­nie kon­tek­stów w dużych rela­cyj­nych mode­lach danych, jed­nak poprze­sta­ją oni tyl­ko na reko­men­da­cji by te kon­tek­sty sepa­ro­wać [EVANS 2003, M.Fowler 2014] pozo­sta­jąc nadal przy mode­lu rela­cyj­nym, co nie roz­wią­zu­je pro­ble­mu cał­ko­wi­cie [Awang, M.K., Labadu, N.L., Campus, G.B., 2012].

Zmiana kon­tek­stu czę­sto zmie­nia zna­cze­nie danych [Danesi, M., 2004]. Próby zacho­wa­nia tego zna­cze­nia pro­wa­dzą czę­sto do powsta­wa­nia roz­bu­do­wy­wa­nia rela­cyj­nych mode­li danych, co z kolei powo­du­je dodat­ko­wy koszt. W kon­se­kwen­cji sto­so­wa­nie jed­ne­go mode­lu rela­cyj­ne­go danych do zapi­su tre­ści wie­lu róż­nych doku­men­tów powo­du­je, że sys­tem taki sta­je się wiel­kim i nie­po­dziel­nym mono­li­tem, kosz­tow­nym w opra­co­wa­niu i utrzymaniu.

Stosowane jest też podej­ście, w któ­rym opro­gra­mo­wa­nie prze­twa­rza doku­ment (jego treść) trak­tu­jąc go jako samo­dziel­ny obiekt zapi­su­jąc jed­nak jego treść (poszcze­gól­ne pola) w mode­lu rela­cyj­nym [O?Neil, E. J. (2008)] co powo­du­je dodat­ko­wy nakład pra­cy w toku pro­jek­to­wa­nia takie­go sys­te­mu oraz duże zapo­trze­bo­wa­nie na moc pro­ce­so­ra w trak­cie odczy­tu i zapi­su doku­men­tów z pomo­cą dodat­ko­wej war­stwy apli­ka­cji, jaką jest tu mapo­wa­nie obiek­to­wo-rela­cy­ju­ne (ORM, Object-Relational Mapping). Problem ten jest czę­sto nazy­wa­ny nie­do­pa­so­wa­niem opo­ru mode­lu rela­cyj­ne­go i obiek­to­we­go (object-rela­tio­nal impe­dan­ce mismatch) [Ireland, C., Bowers, D., 2015].

Celem badań było zna­le­zie­nie odpo­wie­dzi na pyta­nie dla­cze­go tyl­ko ok. 10% wdro­żeń sys­te­mów infor­ma­cyj­nych koń­czy się suk­ce­sem [The Standish Group International, Inc. (2015)] i czy inny niż, nie raz kry­ty­ko­wa­ny za nie­sku­tecz­ność [Cook, S., & Daniels, J. (1994)] rela­cyj­ny kor­po­ra­cyj­ny model orga­ni­za­cji danych, pomo­że zwięk­szyć sku­tecz­ność tych pro­jek­tów. Obszar badań auto­ra to mode­le jako meto­dy ana­li­zy i pro­jek­to­wa­nia a meta­mo­de­le jako narzę­dzie budo­wy teo­rii (patrz tak­że Gray, J., & Rumpe, B. (2019)).

2. Użyte metody i narzędzia

Materiałem źró­dło­wym do ana­liz poję­cio­wych i struk­tur danych były doku­men­ty w bada­nych fir­mach, w szcze­gól­no­ści w obsza­rze finan­se i księ­go­wość, zarzą­dza­nie pro­duk­ta­mi, reje­stry nie­ru­cho­mo­ści a tak­że archi­wa pli­ków mul­ti­me­dial­nych. Były to dane dostęp­ne dla auto­ra w toku pra­cy zawodowej. 

Opisane tu meto­dy pro­jek­to­wa­nia doku­men­to­wych struk­tur danych zosta­ły zasto­so­wa­ne przez auto­ra w kil­ku pro­jek­tach. Uzyskane efek­ty poka­za­ły prze­wa­gę tej for­my ana­li­zy i pro­jek­to­wa­nia struk­tur danych do celów zarzą­dza­nia wie­dzą, w porów­na­niu do metod opar­tych na rela­cyj­nym mode­lu danych. 

Jako pod­sta­wo­we narzę­dzia wyko­rzy­sta­no w pra­cy ana­li­zę poję­cio­wą i obiek­to­wą oraz mode­lo­wa­nie obiek­to­we. Do udo­ku­men­to­wa­nia wyni­ków wyko­rzy­sta­no sys­te­my nota­cyj­ne: Semantic Business Vocabulary and Rules [SBVR 2017] oraz Unified Modeling Language [UML 2017]. Wykorzystano tak­że wie­dzę z zakre­su seman­ty­ki [seman­tic trian­gle Sowa, J.F., 2000] oraz poję­cia kla­sy, kla­sy­fi­ka­to­ra i obiek­tu [UML 2017]. Celem tej publi­ka­cji jest pre­zen­ta­cje opra­co­wa­nej meto­dy a nie prze­gląd sys­te­mów pro­jek­to­wa­nych i wdra­ża­nych przez autora.

3. Wyniki

Opracowano sys­tem stan­da­ry­za­cji orga­ni­zo­wa­nia infor­ma­cji, jej prze­cho­wy­wa­nia i prze­twa­rza­nia. W wyni­ku tych prac opra­co­wa­no meta­mo­del i pro­fil UML, dla archi­tek­tu­ry mode­lo­wa­nia danych meto­dą orga­ni­za­cji ich w doku­men­ty. Opracowano meto­dy pro­jek­to­wa­nia struk­tur doku­men­tów gro­ma­dzą­cych infor­ma­cje. Opiera się ona na zało­że­niu, że doku­men­ty sta­no­wią agre­ga­ty danych George Papamarkos, Lucas Zamboulis, Alexandra Poulovassilis, 2015]). 

3.1. Przetwarzanie informacji

Informacje zawsze są o czymś, inny­mi sło­wy opi­su­ją coś co ist­nie­je lub mogło­by zaist­nieć. Jeżeli mówi­my, że sys­tem infor­ma­tycz­ny prze­twa­rza infor­ma­cje, to zna­czy, że prze­twa­rza dane, któ­re są zapi­sa­ny­mi infor­ma­cja­mi (dane oczy­wi­ście mogą nie nieść żad­nej infor­ma­cji, ale w tej publi­ka­cji się tym nie zajmuję). 

Rysunek 1. Przetwarzanie infor­ma­cji o tym co jest i co zaszło

Na dia­gra­mie Rysunek 1. Przetwarzanie infor­ma­cji o tym co jest i co zaszło poka­za­no sche­ma­tycz­nie zwią­zek mię­dzy świa­tem rze­czy­wi­stym (Świat opi­sy­wa­ny dany­mi), dany­mi zapi­sa­ny­mi meto­da­mi tra­dy­cyj­ny­mi (Dokumenty papie­ro­we (nośni­ki danych) i dany­mi zapi­sa­ny­mi i prze­twa­rza­ny­mi z uży­ciem opro­gra­mo­wa­nia, tu: Aplikacja zarzą­dza­ją­ca danymi.

Innymi sło­wy Dokumenty papie­ro­we (nośni­ki danych) ​„nio­są” dane sta­no­wią­ce okre­ślo­ne infor­ma­cje o świe­cie rze­czy­wi­stym. Stanowią więc sobą infor­ma­cje o histo­rii, czy­li infor­ma­cje o sta­nie ​„świa­ta rze­czy­wi­ste­go” w cza­sie prze­szłym. Mogą to być tak­że infor­ma­cje o cza­sie przy­szłym, są to np. pla­ny lub prognozy.

Celem two­rze­nia opro­gra­mo­wa­nia jest prze­twa­rza­nie danych, sta­no­wią­cych okre­ślo­ne infor­ma­cje, któ­re opi­su­ją okre­ślo­ne ele­men­ty świa­ta rze­czy­wi­ste­go. Struktura tych danych, powin­na odpo­wia­dać struk­tu­rze rze­czy, któ­re są opi­sy­wa­ne (o któ­rych infor­ma­cje prze­twa­rza­my) [Mountriver 2011,Smith 1985]. Wynalezienie kom­pu­te­ra otwo­rzy­ło nowe moż­li­wo­ści prze­twa­rza­nia (wdro­że­nie opro­gra­mo­wa­nia – kie­ru­nek zmian), ale nie zmie­nia rze­czy­wi­sto­ści opi­sy­wa­nej dany­mi prze­twa­rza­ny­mi w nim, gdzie same doku­men­ty jako takie, tak­że są ele­men­tem tej rzeczywistości.

Zgodnie z tym co już napi­sa­no, infor­ma­cje opi­su­ją albo zda­rze­nie albo obiekt. Złożone doku­men­ty mogą zawie­rać wie­le infor­ma­cji, jed­nak powin­no być moż­li­we przy­po­rząd­ko­wa­nie dane­go doku­men­tu do jed­ne­go z typów: opis obiek­tu lub opis zda­rze­nia, gdyż jak już napi­sa­no, jeden doku­ment może (powi­nien) mieć jeden kon­tekst, z uwa­gi na wyma­ga­ną jed­no­znacz­ność jego tre­ści (kon­tekst). W dal­szej czę­ści opi­sa­no dlaczego. 

Rysunek 2. Obiekt i jego historia

W sytu­acji przed­sta­wio­nej na dia­gra­mie Rysunek 2. Obiekt i jego histo­ria, mamy jeden obiekt i trzy zwią­za­ne z nim zda­rze­nia. To zna­czy, że powin­ny tu ist­nieć – co postu­lu­ję – czte­ry nie­za­leż­ne opi­sy (doku­men­ty): jeden to wer­sjo­no­wa­ny opis obiek­tu, pozo­sta­łe trzy to opi­sy fak­tów do jakich doszło w związ­ku z tym obiek­tem. Kluczowe jest przy­ję­cie zasa­dy: doku­ment może mieć jeden z dwóch moż­li­wych kon­tek­stów: infor­ma­cje o obiek­cie lub infor­ma­cje o zdarzeniu.

Pojęcie przed­miot (sub­ject), zobra­zo­wa­no i opi­sa­no w dal­szej czę­ści na dia­gra­mie Rozszerzony model poję­cio­wy. Ma ono tyl­ko dwa typy: zda­rze­nie oraz obiekt („Data are sym­bols that repre­sent the pro­per­ties of objects and events” [Ackoff, R.L., 1999. ]). Taksonomia ta ma klu­czo­we zna­cze­nie w opra­co­wa­nym meta­mo­de­lu. Źródłem tego podzia­łu jest kon­tekst opi­su, co poka­za­no na dia­gra­mie Rysunek 2. Obiekt i jego histo­ria. Obiekt nie­zmien­nie trwa w cza­sie. Może on ule­gać zmia­nom: ma cykl życia, ale co do zasa­dy trwa, zmia­ny są (mogą być) skut­kiem okre­ślo­nych zda­rzeń, powią­za­nych z tym obiek­tem. Zdarzenia jed­nak nie muszą zmie­niać przed­mio­tu, mogą go jedy­nie ​„doty­czyć”. Obiekty (object) i zda­rze­nia (events) defi­nio­wa­ne są przez ich cechy (pro­per­ties).

To co łączy zda­rze­nia z obiek­ta­mi to okre­ślo­ne czas i miej­sce zda­rze­nia. Obiekt, któ­re­go zda­rze­nie doty­czy, jest ele­men­tem jego opi­su. Obiekt nie­zmien­nie trwa w cza­sie, więc wią­że się z nim tak­że poję­cie jego cyklu życia: jest to jego histo­ria. Historia obiek­tu to zbiór powią­za­nych z nim zda­rzeń (któ­rych dany obiekt był uczest­ni­kiem). Zdarzenia i obiek­ty opi­su­je­my z uży­ciem cech. Zdarzenie i obiek­ty muszą być uni­kal­ne (odróż­nia­my je od sie­bie), jed­nak war­to­ści poszcze­gól­nych cech nie muszą już być uni­kal­ne, np. ta sama data wie­lu róż­nych zda­rzeń, to samo miej­sce wystą­pie­nia róż­nych zda­rzeń. Wartości (value) cech (pro­per­ties) nie są ani zda­rze­niem ani obiek­tem, choć mogą mieć zło­żo­ną struk­tu­rę (np. peł­ny adres pocz­to­wy jest war­to­ścią cechy poło­że­nie, ale nie jest ani zda­rze­niem ani obiek­tem). To dla­te­go nie są one typem tema­tu. Temat opi­su to albo obiekt albo zda­rze­nie. Jeżeli przyj­mie­my zało­że­nie, że kon­tekst okre­śla zna­cze­nie pojęć, opis zaś skła­da sie z pojęć, to w kon­se­kwen­cji okre­ślo­ny doku­ment, by jego treść była jed­no­znacz­na, może mieć tyl­ko jeden kontekst.

Z per­spek­ty­wy prze­twa­rza­nia danych nie ma zna­cze­nia czy zda­rze­nie (event) jest z prze­szło­ści czy przy­szło­ści bo oba maja iden­tycz­ne cechy (dane opi­su­ją­ce: atry­bu­ty). Pojęcie cza­su ma zna­cze­nie dla czło­wie­ka któ­ry inter­pre­tu­je dane (patrz A‑theory and B‑theory, [Mountriver 2011]). Dlatego sys­tem infor­ma­tycz­ny posor­tu­je chro­no­lo­gicz­nie zda­rze­nia, ale okre­śle­nie czy dane zda­rze­nie było czy będzie, wyma­ga sko­re­lo­wa­nia daty tego zda­rze­nia (jego cecha) z datą dnia gdy pyta­nie takie jest zada­ne. Innymi sło­wy pyta­nie o ​„zda­rze­nia wczo­raj­sze” każ­de­go dnia da inny wynik mimo, że dane o zda­rze­niach nie ule­ga­ją zmianie.

Kluczowe reguły: dokument jest klasyfikowany albo jako opis obiektu albo faktu, opis faktu nie może być modyfikowany, opis obiektu może być (aktualizacja stanu faktycznego). Modyfikacja opisu obiektu jest faktem (który należy udokumentować), fakt musi dotyczyć co najmniej jednego obiektu.

(kom­plet­ny tekst ma 26 stron, zawie­ra kom­plet­ny opis meto­dy i meta­mo­del infor­ma­cji orga­ni­zo­wa­nych w doku­men­ty, przy­kła­dy uży­cia meto­dy; data i miej­sce publi­ka­cji będą tu poda­ne w komen­ta­rzach, któ­re moż­na sub­skry­bo­wać, publi­ka­cja uka­za­ła sie w 2021 roku )

Uzupełnienie

[Marzec 2023] Zarządzanie zesta­wem powią­za­nych danych jako agre­ga­tem jest bar­dzo efek­tyw­ne. Traktowanie doku­men­tów jako agre­ga­tów to spo­sób na budo­wa­nie bar­dzo efek­tyw­nej archi­tek­tu­ry. Niedawno uka­za­ła się bar­dzo cie­ka­wa pre­zen­ta­cja na temat agre­ga­tów w DDD. Autor poka­zu­je jakim ogrom­nym pro­ble­mem są zapy­ta­nia do rela­cyj­nych baz danych już w sys­te­mach mają­cych kil­ka­dzie­siąt tabel i jakim ​„dobro­dziej­stwem” jest ope­ro­wa­nie poję­cia­mi Aggregate i Value Object. 

Struktura i treść doku­men­tu (for­mu­larz jako agre­gat) może być zapi­sa­na i potem odzy­ska­na w bazie danych o rela­cyj­nym mode­lu danych, poni­żej struk­tu­ra zapy­ta­nia SQL do tej bazy (kil­ka­set tablic):

Po obej­rze­niu całej powyż­szej pre­zen­ta­cji pomyśl, że struk­tu­ra i treść doku­men­tu (for­mu­larz jako agre­gat) może być wyra­żo­na tak­że w posta­ci jed­ne­go cią­gu zna­ków XML (lub JSON, itp.) jako war­tość jed­ne­go pola dowol­nej bazy danych (szcze­gól­nie bazy NoSQL) a zapy­ta­nie do takiej bazy danych to pole­ce­nie na kil­ka słów. Wtedy obiekt nio­są­cy taki XML jest wła­śnie tym «enti­ty», korze­niem i toż­sa­mo­ścią całe­go agre­ga­tu, tyle, że powyż­sze mon­stru­al­ne zapy­ta­nia SQL do rela­cyj­nej bazy nie są już potrzebne.

Agregat – kontekst treści formularza

[Grudzień 2023] Jako ludzie zapi­su­je­my infor­ma­cje z zasa­dy w okre­ślo­nym kon­tek­ście. To co dla nas jest infor­ma­cją, dla papie­ru (i każ­de­go inne­go nośni­ka) jest zna­kiem (zna­ka­mi). Znaki do dane, któ­rych nie rozu­mie ani nośnik ani stos reguł (pro­ce­du­ra). Czyli kom­pu­ter też nie rozumie!

Standardową ​„ludz­ką” for­mą zapi­su są doku­men­ty i for­mu­la­rze. Dokument ma kon­tekst, każ­da część doku­men­tu tak­że. Poniższy for­mu­larz to dwa iden­tycz­ne zesta­wy danych o dwóch oso­bach, peł­nią­cych jed­nak róż­ne role. Ten doku­ment to: kon­tekst doku­men­tu oraz zagnież­dżo­ne dwa kon­tek­sty osób (ich role).

Wyobraźmy sobie, że mamy kil­ka­dzie­siąt takich róż­nych doku­men­tów, każ­dy ma swój wła­sny inny kon­tekst, i na każ­dym powta­rza­ją się pew­ne dane (w innym kon­tek­ście). Żadna z tych danych nie jest licz­bą, na któ­rej moż­na wyko­nać ope­ra­cję matematyczną.

Jaki sens ma łado­wa­nie danych z wie­lu róż­nych for­mu­la­rzy (pól i ich war­to­ści) do jed­ne­go sys­te­mu rela­cyj­nych tabel i pozba­wia­nie ich kon­tek­stu i redun­dan­cji? Ile pra­cy nale­ży wło­żyć w każ­do­ra­zo­wy zapis i odtwo­rze­nie każ­de­go z tych formularzy?

Źródła