Dokument jako nośnik danych i metoda zarządzania danymi [preprint]

Profil UML i meta-model typów doku­men­tów jako sys­tem orga­ni­za­cji danychDokument 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 systemów

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ę). 

Przetwarzanie informacji o tym co jest i co zaszło

Na diagramie Przetwarzanie informacji o tym co jest i co zaszło pokazano schematycznie związek między światem rzeczywistym (Świat opisywany danymi), danymi zapisanymi metodami tradycyjnymi (Dokumenty papierowe (nośniki danych)  i danymi zapisanymi i przetwarzanymi z użyciem oprogramowania, tu: Aplikacja zarządzająca danymi.
        Innymi słowy Dokumenty papierowe (nośniki danych) "niosą" dane stanowiące określone informacje o świecie rzeczywistym. Stanowią więc sobą informacje o historii, czyli informacje o stanie "świata rzeczywistego" w czasie przeszłym. Mogą to być także informacje o czasie przyszłym, są to np. plany lub prognozy.
        Celem tworzenia oprogramowania jest przetwarzanie danych, stanowiących określone informacje, które opisują określone elementy świata rzeczywistego. Struktura tych danych, powinna odpowiadać strukturze rzeczy, które są opisywane (o których informacje przetwarzamy) [Mountriver 2011,Smith 1985]. Wynalezienie komputera otworzyło nowe możliwości przetwarzania (wdrożenie oprogramowania - kierunek zmian), ale nie zmienia rzeczywistości opisywanej danymi przetwarzanymi w nim, gdzie same dokumenty jako takie, także są elementem tej rzeczywistości.
        Zgodnie z tym co już napisano, informacje opisują albo zdarzenie albo obiekt. Złożone dokumenty mogą zawierać wiele informacji, jednak powinno być możliwe przyporządkowanie danego dokumentu do jednego z typów: opis obiektu lub opis zdarzenia, gdyż jak już napisano, jeden dokument może (powinien) mieć jeden kontekst, z uwagi na wymaganą jednoznaczność jego treści (kontekst). W dalszej części opisano dlaczego.

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. 

Obiekt i jego historia

W sytuacji przedstawionej na diagramie Obiekt i jego historia mamy jeden obiekt  i trzy związane z nim zdarzenia. To znaczy, że mogły by istnieć - co postuluję - cztery niezależne opisy (dokumenty): jeden opisujący obiekt i trzy opisujące zaszłe zdarzenia. Te cztery opisy to hipotetyczne cztery dokumenty, jednak każdy z nich byłby opisem albo zdarzenia albo obiektu. Kluczowe jest przyjęcie zasady, że dokument może mieć jeden z dwóch możliwych kontekstów: informacje o obiekcie lub informacje o zdarzeniu.
         Pojęcie przedmiot (subject), zobrazowano i opisano w dalszej części na diagramie Rozszerzony model pojęciowy. Ma ono tylko dwa typy: zdarzenie oraz obiekt ("Data are symbols that represent the properties of objects and events" [Ackoff, R.L., 1999. ]). Taksonomia ta ma kluczowe znaczenie w opracowanym metamodelu. Źródłem tego podziału jest kontekst opisu, co pokazano na diagramie Obiekt i jego historia. Obiekt niezmiennie trwa w czasie. Może on ulegać zmianom: ma cykl życia, ale co do zasady trwa, zmiany są (mogą być) skutkiem określonych zdarzeń, powiązanych z tym obiektem. Zdarzenia jednak nie muszą zmieniać przedmiotu, mogą go jedynie "dotyczyć". Obiekty (object) i zdarzenia (events) definiowane są przez ich cechy (properties).
       To co łączy zdarzenia z obiektami to określone czas i miejsce zdarzenia. Obiekt, którego zdarzenie dotyczy, jest elementem jego opisu. Obiekt niezmiennie trwa w czasie, więc wiąże się z nim także pojęcie jego cyklu życia: jest to jego historia. Historia obiektu to zbiór powiązanych z nim zdarzeń (których dany obiekt był uczestnikiem). Zdarzenia i obiekty opisujemy z użyciem cech. Zdarzenie i obiekty muszą być unikalne (odróżniamy je od siebie), jednak wartości poszczególnych cech nie muszą już być unikalne, np. ta sama data wielu różnych zdarzeń, to samo miejsce wystąpienia różnych zdarzeń. Wartości (value) cech (properties) nie są ani zdarzeniem ani obiektem, choć mogą mieć złożoną strukturę (np. pełny adres pocztowy jest wartością cechy położenie, ale nie jest ani zdarzeniem ani obiektem). To dlatego nie są one typem tematu. Temat opisu to albo obiekt albo zdarzenie. Jeżeli przyjmiemy założenie, że kontekst określa znaczenie pojęć, opis zaś składa sie z pojęć, to w konsekwencji określony dokument, by jego treść była jednoznaczna, może mieć tylko jeden kontekst.
        Z perspektywy przetwarzania danych nie ma znaczenia czy zdarzenie (event) jest z przeszłości czy przyszłości bo oba maja identyczne cechy (dane opisujące: atrybuty). Pojecie czasu ma znaczenie dla człowieka który interpretuje dane (patrz A-theory and B-theory, [Mountriver 2011]). Dlatego system informatyczny posortuje chronologicznie zdarzenia, ale określenie czy dane zdarzenie było czy będzie, wymaga skorelowania daty tego zdarzenia (jego cecha) z datą dnia gdy pytanie takie jest zadane. Innymi słowy pytanie o "zdarzenia wczorajsze" każdego dnia da inny wynik mimo, że dane o zdarzeniach nie ulegają zmianie.

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 mogły by ist­nieć – co postu­lu­ję – czte­ry nie­za­leż­ne opi­sy (doku­men­ty): jeden opi­su­ją­cy obiekt i trzy opi­su­ją­ce zaszłe zda­rze­nia. Te czte­ry opi­sy to hipo­te­tycz­ne czte­ry doku­men­ty, jed­nak każ­dy z nich był­by opi­sem albo zda­rze­nia albo obiek­tu. Kluczowe jest przy­ję­cie zasa­dy, że 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.

Opis obiek­tu vs. opis Faktu
Kluczowe reguły: dokument jest klasyfikowany albo jako opis obiektu albo faktu, opis faktu nie może być modyfikowany a obiektu tak (aktualizacja stanu faktycznego), modyfikacja opisu obiektu jest faktem (który można dokumentować), 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 )

Źródła

Inne artykuły na podobny temat

Komentarze

  1. Jarosław Żeliński 12 grudnia 2020 at 13:09

    Padają pyta­nia o wydaj­ność, tu testy: 

    Győrödi, C., Győrödi, R., Pecherle, G., & Olah, A. (2015). A com­pa­ra­ti­ve stu­dy: MongoDB vs. MySQL. 2015 13th International Conference on Engineering of Modern Electric Systems (EMES), 1?6. https://​doi​.org/​1​0​.​1​1​0​9​/​E​M​E​S​.​2​0​1​5​.​7​1​5​8​433

  2. Jarosław Żeliński 12 grudnia 2020 at 13:12

    oraz tu w innej formie:

    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

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.