Wprowadzenie

W 2019 opisałem swoistą próbę rewitalizacji wzorca BCE (Boundary, Control, Entity). Po wielu latach używania tego wzorca i dwóch latach prób jego rewitalizacji uznałem jednak, ż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 [zotpressInText item=”{5085975:TBT7B5D2}”] 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 dokumentów [zotpressInText item=”{5085975:9KMR85JV}”]. 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 rozszerzenia wzorca projektowego BCE)

BCE powstał w czasach świetności metod RUP (Rational Unified Process) i ICONIX [zotpressInText item=”{5085975:7NUD7FFT},{5085975:P7WIX63W}”]. Metody te doskonale pasowały do implementacji realizowanych w środowisku EJB (Enterprise JavaBeans). Pojęcia Boundary, Control, Entity (BCE) przylgnęły do trójwarstwowego pojmowania architektury aplikacji (interfejs użytkownika, logika, bada danych) a pojęcie “robustness diagram” także ma utrwalone znaczenie w literaturze. Początkowo wydawało się, że przeniesienie tych pojęć na grunt metod obiektowych i odpowiedzialności klas [zotpressInText item=”{5085975:CDZ44929}”] uda sie bez kolizji z wcześniejszym stosowaniem wzorca BCE, jednak prace badawcze i praktyka (szczególnie komunikacja tych modeli) pokazały, że pojęcia te, i ich znaczenia, są tak mocno ugruntowane w literaturze, że pozostaje jedynie używanie ich w pierwotnych znaczeniach, jakie nadano im prawie 20 lat temu (Philippe Kruchten, Rational Unified Process). Więcej na ten temat w artykule: ICONIX and Use Case Driven Object Modeling with UML.

Dużym problemem jest także migracja istniejących aplikacji z lokalnych baz danych w modelu relacyjnym do chmury NoSQL [zotpressInText item=”{5085975:WG8FBWQ9},{5085975:TLXPTGGP}”].

Metody

Wszystkie moje projekty badawcze są poprzedzane analizą pojęciową i metamodelowaniem. Dzięki temu każdy projekt analityczny jest obiektywizowany w maksymalnie możliwy sposób, zaś produkty projektowania odporne na zmienność środowiska. Ta odporność, bierze się stad, że prawidłowo opisane dane to określone zamknięte struktury danych wraz z ich kontekstem: dokumenty (formularze). Jeżeli uznamy, że nasz język (np. polski) się nie zmienia, a zmienia sie jedynie to co z jego użyciem opisujemy, to znaczy, że możliwe jest zapisanie i przetwarzanie informacji o świecie, i że nie opis ten (jego struktura) nie będzie wymagał zmian w przyszłości. Dane opisujące świat to zbiory pojęć stanowiące określone struktury (zdania, akapity, dokumenty) a nie pojedyncze słowa połączone relacjami [zotpressInText item=”{5085975:9KMR85JV}”]. Trudna do przetłumaczenia na język polski nazwa dziedziny nauki: information science [zotpressInText item=”{5085975:M5XF9L4L},{5085975:2H38RDA7},{5085975:FZX9ZH26}”], to obszar wiedzy zajmujący się informacją i jej przetwarzaniem, co nie jest tożsame z przetwarzaniem danych (w języku polskim nazywane informatyka). Korzystam tu także z dorobku tej dziedziny nauki: są nią modele pojęciowe, ontologie i rachunek zdań (analiza i budowanie struktur dokumentów).

Rezultat

Ten opis to wstępna wersja, generalizacja doświadczenia zakończonych sukcesem implementacji i wdrożeń. Praktyka pokazała, że klasyfikując komponenty aplikacji, kierując się ich odpowiedzialnością [zotpressInText item=”{5085975:CDZ44929}”], otrzymamy trzy kluczowe role komponentów: przetwarzanie, zarządzanie przetwarzaniem, przechowywanie. To ostatnie to przechowanie danych w “paczkach” zorganizowanych kontekstowo jako dokumenty [zotpressInText item=”{5085975:9KMR85JV}”]. Z uwagi na to, że inicjatorem użycia usługi jest aktor “użytkownik”, obligatoryjnym elementem aplikacji jest interfejs użytkownika (GUI, Graphical User Interface). Opis ten można zobrazować tak (UML):

Tym co różni ten model od wzorca BCE jest rezygnacja z warstwowości (narzuconej kolejności wywoływania komponentów). Wzorzec BCE (poniżej) jest zorganizowany w “linię produkcyjną” z zakazem omijania jej elementów:

Wzorzec, który wstępnie nazwałem MPS, to przede wszystkim specjalizowane komponenty przetwarzające, których użycie jest zarządzane. Utrwalanie zostało całkowicie pozbawione przetwarzania: logika biznesowa jest w 100% realizowana w komponentach ‘processing’. To kluczowa zaleta takiego podejścia: niezależność od implementacji przechowywania. Z tego powodu w tytule dodałem słowo “chmura”, gdyż to czy jest to chmura prywatna czy publiczna nie powinno mieć tu znaczenia, i nie ma.

Wieloletnie doświadczenie projektowe nauczyło mnie także, że znane od lat podejście znane jako mikroserwisy, zakładające w usługach “własność lokalnej bazy danych”, stanowi takie samo ograniczenie jak “własne baza danych” w systemach monolitycznych, tyle że na nieco mniejszą skalę.

Opisane tu komponenty są częścią architektury całej aplikacji. Opierając się na założeniach MDA (Model Driven Architecture) oraz wzorcu architektonicznym MVC (Model, View, Controller) [zotpressInText item=”{5085975:TBT7B5D2},{5085975:X7Z9RCAV},{5085975:UWH8D5UI}”], można wstępnie tak zobrazować abstrakcyjną architekturę aplikacji:

Dolna część diagramu to prezentowany na początku artykułu model PIM. Jednak po uzupełnieniu go o strukturę wzorca MVC mozna uznać, że: 1. GUI to realizacja komponentu View, 2. Model jest realizowany przez logikę reprezentowaną przez komponenty ‘Management’ oraz ‘Processing’, element ‘Document’ to nazwana struktura danych (formularz) stanowiący zawsze argument wywołań (pełni tu DTO: Data Transfer Object). Komponent ‘Storage’ to albo własny system utrwalania aplikacji (jej środowiska), albo API systemu utrwalania w chmurze prywatnej lub publicznej (patrz artykuł Repozytorium w chmurze). To dzięki temu migracja z lokalnej do publicznej chmury stanowi wyłącznie przeadresowanie wywołań i jednorazowe przeniesienie danych. Dość powszechnie stosowany wzorzec projektowy “repository” tu jest podzielony na dwie części: ‘Management’ Kontrola dostępu do danych oraz ‘Storage’ jako Repozytorium danych. To ostatnie to właśnie opisane wcześniej chmurowe repozytoria. 3. Controller to środowisko wykonawcze odpowiadające za komunikację z otoczeniem aplikacji, np. integrację z innymi aplikacjami: Aktor ‘application’.

Model PIM: to co należy zaprojektować, tworząc nową aplikację, jako wymaganie na etapie poprzedzającym implementację (czyli wybór technologii także), wygląda tu tak:

Oczywiście liczba poszczególnych typów komponentów zależy od konkretnego przypadku.

Po co nam takie wzorce? Przed wszystkim by mieć od czego zacząć, coś co u wielu autorów nazywa jest “starting point” (punkt wyjścia). Po drugie narzuca pewien porządek, oraz pozwala uzyskać podstawową cechę dobrego oprogramowania: aplikacja (jej architektura) jest otwarta na rozszerzenia i zamknięta na modyfikacje (patrz Open Closed Principle). No i po trzecie, stosowanie reguły mówiącej, że jeden komponent ma jedną dedykowaną rolę w systemie, bardzo ułatwia stosowanie dostępnych na rynku, gotowych komponentów (zarówno płatnych i opensource). Uzyskujemy także łatwość zarządzania licencjami (odseparowane komponenty to odseparowane prawa do nich, łatwo nimi zarządzać, a w razie konieczności zastąpić innymi). Warto tu podkreślić, że z perspektywy kosztów: od kosztów wytworzenia aplikacji, znacznie ważniejsze są koszty jej utrzymanie i rozwoju.

Podsumowanie i dalsze prace

Opisany tu wzorzec architektoniczny to wstępna propozycja uporządkowania architektury aplikacji. Wprowadzony tu element ‘Management’ to uogólnienie wzorca znanego jako “saga“. Jest to rozwiązanie problemu transakcyjności w systemach opartych na mikroserwisach i także systemach NoSQL, gdzie repozytoria nie realizują żadnej logiki, nawet tej odpowiedzialnej za spójność danych (co często jest wskazywane jako wada tych repozytoriów).

Dalsze prace są obecnie ukierunkowane na testy skuteczności tego wzorca w rozwiązywaniu problemów systemów, przetrzymujących dane w chmurach. Celem autora jest opracowanie metamodelu stanowiącego rozwiązanie problemów zarządzania dużymi, wielodziedzinowymi zbiorami danych.

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

Profil UML i meta-model typów dokumentów jako system organizacji danych. Dokument jako kontekstowa struktura informacyjna. 

Streszczenie: Opisano sprawdzona w praktyce metodę składowania danych zorganizowanych w dokumenty. Opisana metoda nie ma wad relacyjnego modelu organizacji danych, jakim jest utrata kontekstu danych i komplikacje wywołane brakiem redundancji danych. W pracy tej przedstawiono metodę organizacji danych w dokumenty jako sklasyfikowane agregaty, metodę ich klasyfikacji oraz metamodel ich budowy. Opisany metamodel zakłada, że dokumenty jako struktury danych to zwarte agregaty, klasyfikowane jako opisy obiektów (object) lub wydarzeń (events) co nadaje im zawsze określony i jednoznaczny kontekst. Opisano także metodę projektowania dokumentów jako agregatów kontekstowych, co pozwala zniwelować wskazane wady modelu relacyjnego oraz zagwarantować skuteczność zarządzania informacją. Dodatkowo opisany model rozwiązuje problemy zarządzania dostępem do danych poprzez określanie dostępu do całego kontekstowego dokumentu, a nie do poszczególnych pól. Dzięki temu zarządzanie dostępem do danych staje się znacznie prostsze.

Słowa kluczowe: systemy informacyjne, inżynieria oprogramowania, bazy danych, BCE, agregat, metody obiektowe, paradygmat obiektowy, inżynieria systemów, DDD, aggregate

1. Wprowadzenie

W wielu projektach, których celem jest zarządzanie informacją i przetwarzanie jej, pojawia się problem z opracowaniem modelu danych. Często a priori przyjmuje się, że dokumenty to informacja organizowana w postaci formularzy złożonych z określonych pól, a te będą przechowywane w modelu relacyjnym [Shimura, T., Yoshikawa, M., Uemura, S., 1999]. Model ten prowadzi do sytuacji gdzie: <dokument> = <zbiór danych w modelu relacyjnym> + <zapytanie SQL do tego zbioru>. Innymi słowy dokumenty to dynamicznie generowane treści, nie istniejące jako trwałe byty. Dla rozbudowanych modeli danych procedury nazwane <zapytanie SQL do tego zbioru> są bardzo złożone i ich wykonanie generuje duże zapotrzebowanie na czas i moc procesora. Ich opracowanie i testowanie jest kosztowne, bo zajmuje wiele czasu specjalistów, którzy je tworzą. Nie mniej kosztowne jest wprowadzanie do nich zmian w cyklu życia oprogramowania.

   Dokumenty bardzo często zawierają bardzo wiele różnych informacji stanowiących sobą złożone wielokontekstowe zestawy (agregaty) danych. Zastosowanie modelu relacyjnego do organizowania takich informacji, prowadzi do powstania złożonego systemu powiązanych relacyjnie tabel a usuwanie redundancji prowadzi często utraty kontekstu treści poszczególnych pól w tabelach. W konsekwencji pojawia się konieczność stosowania bardzo złożonych zapytań w języku SQL, by dokumenty te zapisywać w takiej bazie i odtwarzać z niej. W samej bazie są to tylko pozbawione kontekstu dane w tabelach a nie dokumenty.

  Wielu autorów zwraca uwagę na problem złożoności i utraty kontekstu jednolitych modeli relacyjnych, zalecając separowanie kontekstów w dużych relacyjnych modelach danych, jednak poprzestają oni tylko na rekomendacji by te konteksty separować [EVANS 2003, M.Fowler 2014] pozostając nadal przy modelu relacyjnym, co nie rozwiązuje problemu całkowicie [Awang, M.K., Labadu, N.L., Campus, G.B., 2012].

  Zmiana kontekstu często zmienia znaczenie danych [Danesi, M., 2004]. Próby zachowania tego znaczenia prowadzą często do powstawania rozbudowywania relacyjnych modeli danych, co z kolei powoduje dodatkowy koszt. W konsekwencji stosowanie jednego modelu relacyjnego danych do zapisu treści wielu różnych dokumentów powoduje, że system taki staje się wielkim i niepodzielnym monolitem, kosztownym w opracowaniu i utrzymaniu.

  Stosowane jest też podejście, w którym oprogramowanie przetwarza dokument (jego treść) traktując go jako samodzielny obiekt zapisując jednak jego treść (poszczególne pola) w modelu relacyjnym [O?Neil, E. J. (2008)] co powoduje dodatkowy nakład pracy w toku projektowania takiego systemu oraz duże zapotrzebowanie na moc procesora w trakcie odczytu i zapisu dokumentów z pomocą dodatkowej warstwy aplikacji, jaką jest tu mapowanie obiektowo-relacyjune (ORM, Object-Relational Mapping). Problem ten jest często nazywany niedopasowaniem oporu modelu relacyjnego i obiektowego (object-relational impedance mismatch) [Ireland, C., Bowers, D., 2015].

  Celem badań było znalezienie odpowiedzi na pytanie dlaczego tylko ok. 10% wdrożeń systemów informacyjnych kończy się sukcesem [The Standish Group International, Inc. (2015)] i czy inny niż, nie raz krytykowany za nieskuteczność [Cook, S., & Daniels, J. (1994)] relacyjny korporacyjny model organizacji danych, pomoże zwiększyć skuteczność tych projektów. Obszar badań autora to modele jako metody analizy i projektowania a metamodele jako narzędzie budowy teorii (patrz także Gray, J., & Rumpe, B. (2019)).

2. Użyte metody i narzędzia

Materiałem źródłowym do analiz pojęciowych i struktur danych były dokumenty w badanych firmach, w szczególności w obszarze finanse i księgowość, zarządzanie produktami, rejestry nieruchomości a także archiwa plików multimedialnych. Były to dane dostępne dla autora w toku pracy zawodowej. 

  Opisane tu metody projektowania dokumentowych struktur danych zostały zastosowane przez autora w kilku projektach. Uzyskane efekty pokazały przewagę tej formy analizy i projektowania struktur danych do celów zarządzania wiedzą, w porównaniu do metod opartych na relacyjnym modelu danych. 

  Jako podstawowe narzędzia wykorzystano w pracy analizę pojęciową i obiektową oraz modelowanie obiektowe. Do udokumentowania wyników wykorzystano systemy notacyjne: Semantic Business Vocabulary and Rules [SBVR 2017] oraz Unified Modeling Language [UML 2017]. Wykorzystano także wiedzę z zakresu semantyki [semantic triangle Sowa, J.F., 2000] oraz pojęcia klasy, klasyfikatora i obiektu [UML 2017]. Celem tej publikacji jest prezentacje opracowanej metody a nie przegląd systemów projektowanych i wdrażanych przez autora.

3. Wyniki

Opracowano system standaryzacji organizowania informacji, jej przechowywania i przetwarzania. W wyniku tych prac opracowano metamodel i profil UML, dla architektury modelowania danych metodą organizacji ich w dokumenty. Opracowano metody projektowania struktur dokumentów gromadzących informacje. Opiera się ona na założeniu, że dokumenty stanowią agregaty danych George Papamarkos, Lucas Zamboulis, Alexandra Poulovassilis, 2015]). 

3.1. Przetwarzanie informacji

Informacje zawsze są o czymś, innymi słowy opisują coś co istnieje lub mogłoby zaistnieć. Jeżeli mówimy, że system informatyczny przetwarza informacje, to znaczy, że przetwarza dane, które są zapisanymi informacjami (dane oczywiście mogą nie nieść żadnej informacji, ale w tej publikacji się tym nie zajmuję). 

Rysunek 1. Przetwarzanie informacji o tym co jest i co zaszło

Na diagramie Rysunek 1. 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 2. Obiekt i jego historia

W sytuacji przedstawionej na diagramie Rysunek 2. Obiekt i jego historia, mamy jeden obiekt  i trzy związane z nim zdarzenia. To znaczy, że powinny tu istnieć – co postuluję – cztery niezależne opisy (dokumenty): jeden to wersjonowany opis obiektu, pozostałe trzy to opisy faktów do jakich doszło w związku z tym obiektem. Kluczowe jest przyjęcie zasady: 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 Rysunek 2. 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). Pojęcie 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.

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.

(kompletny tekst ma 26 stron, zawiera kompletny opis metody i metamodel informacji organizowanych w dokumenty, przykłady użycia metody; data i miejsce publikacji będą tu podane w komentarzach, które można subskrybować, publikacja ukazała sie w 2021 roku [zotpressInText item=”{5085975:9KMR85JV}”])

Uzupełnienie

[Marzec 2023] Zarządzanie zestawem powiązanych danych jako agregatem jest bardzo efektywne. Traktowanie dokumentów jako agregatów to sposób na budowanie bardzo efektywnej architektury. Niedawno ukazała się bardzo ciekawa prezentacja na temat agregatów w DDD. Autor pokazuje jakim ogromnym problemem są zapytania do relacyjnych baz danych już w systemach mających kilkadziesiąt tabel i jakim “dobrodziejstwem” jest operowanie pojęciami Aggregate i Value Object.

Struktura i treść dokumentu (formularz jako agregat) może być zapisana i potem odzyskana w bazie danych o relacyjnym modelu danych, poniżej struktura zapytania SQL do tej bazy (kilkaset tablic):

Po obejrzeniu całej powyższej prezentacji pomyśl, że struktura i treść dokumentu (formularz jako agregat) może być wyrażona także w postaci jednego ciągu znaków XML (lub JSON, itp.) jako wartość jednego pola dowolnej bazy danych (szczególnie bazy NoSQL) a zapytanie do takiej bazy danych to polecenie na kilka słów. Wtedy obiekt niosący taki XML jest właśnie tym ‘entity’, korzeniem i tożsamością całego agregatu, tyle, że powyższe monstrualne zapytania SQL do relacyjnej bazy nie są już potrzebne.

Agregat – kontekst treści formularza

[Grudzień 2023] Jako ludzie zapisujemy informacje z zasady w określonym kontekście. To co dla nas jest informacją, dla papieru (i każdego innego nośnika) jest znakiem (znakami). Znaki do dane, których nie rozumie ani nośnik ani stos reguł (procedura). Czyli komputer też nie rozumie!

Standardową “ludzką” formą zapisu są dokumenty i formularze. Dokument ma kontekst, każda część dokumentu także. Poniższy formularz to dwa identyczne zestawy danych o dwóch osobach, pełniących jednak różne role. Ten dokument to: kontekst dokumentu oraz zagnieżdżone dwa konteksty osób (ich role).

Wyobraźmy sobie, że mamy kilkadziesiąt takich różnych dokumentów, każdy ma swój własny inny kontekst, i na każdym powtarzają się pewne dane (w innym kontekście). Żadna z tych danych nie jest liczbą, na której można wykonać operację matematyczną.

Jaki sens ma ładowanie danych z wielu różnych formularzy (pól i ich wartości) do jednego systemu relacyjnych tabel i pozbawianie ich kontekstu i redundancji? Ile pracy należy włożyć w każdorazowy zapis i odtworzenie każdego z tych formularzy?

O tym, że liczby nie są dobrym pomysłem na “bycie danymi” pisał także [zotpressInText item=”{5085975:IS7I7MFC}”]:

Why the number input is the worst input. Think that web form has got your number? If you used input type=”number”, you may be surprised to find that it doesn’t.

Źródła

[zotpressInTextBib style=”apa” sortby=”author” sort=”ASC”]