Wzorce projektowe to bardzo ważna część ??zawodu? analityka i architekta oprogramowania. […] Generalnie wzorce są to skatalogowane standardy i dobre praktyki . (Obiektowe wzorce projektowe )
Szkolenia dla analityków poprzedzam ankietami przed szkoleniowymi, jak do tej pory żadna nie zawierała pytań o wzorce projektowe: ani tego że są używane ani tego, że są celem szkolenia, niemalże każdy deklaruje albo, że używa UML lub, że chce zacząć używać UML, nawet gdy są to programiści. Zauważyłem, że wzorce projektowe w świadomości analizy biznesowej i projektowania (OOAD) „nie istnieją”. Wśród programistów, jeżeli jest spotykana, to wiedza o wzorcach przydatnych w tworzeniu bibliotek i narzędzi, często też powielane są wyuczone stare i złe praktyki programistyczne rodem z lat 60-tych (np. praktyki SmallTalk, patrz dalej).
Z drugiej strony od wielu lat znane są techniki MDA (Model Driven Architecture) czy MBSE (Model Based System Engineering), które w różnych formach, ale jednak wskazują, że najskuteczniejsza forma wyrażania wymagań wobec rozwiązania to projekt architektury i logiki dziedzinowej (model) działania aplikacji . O projektowaniu poprzedzającym implementację pisze sie od dość dawna, metody obiektowe i dobre praktyki znane są od lat .
Autorzy BABoK praktycznie od początku istnienia tego wydawnictwa, zwracają uwagę na tak zwaną „białą skrzynkę”, czyli wymagania wyrażone w postaci wewnętrznej struktury produktu, wskazując, że to znacznie skuteczniejsza metoda definiowania wymagań wobec rozwiązania, niż tak zwana „czarna skrzynka”, czyli tradycyjne, i jednak mniej skuteczne, wymagania wyrażone tylko jako cechy funkcjonalne i poza-funkcjonalne. Pamiętajmy, że adresatem wymagań jest zawsze dostawca produktu!
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
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 prace nad wzorcem BCE. Podstawowy powód to bogata literatura i utrwalone znaczenia pojęć opisujących ten wzorzec. Co do zasady redefiniowanie utrwalonych pojęć nie wnosi niczego do nauki. Moja publikacja zawierająca także opis tego wzorca bazowała na pierwotnych znaczeniach pojęć Boundary, Control, Entity. Sprawiły one jednak nieco problemu w kolejnej publikacji na temat dokumentów . Dlatego w modelu pojęciowym opisującym role komponentów przyjąłem następujące bazowe stwierdzenie:
Implementacja usługi aplikacyjnej wymaga wymiany danych z otoczeniem (?Interface?), przetwarzania danych (?Processing?) i ich przechowywania (?Storage?) danych. Działania te to role komponentów (ich typy). Dane, dla ułatwienia zarządzania nimi, są organizowane w dokumenty (?Document?). Całość może wymagać zarządzania (?Management?).
BCE powstał w czasach świetności metod RUP (Rational Unified Process) i ICONIX . 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 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 .
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 . Trudna do przetłumaczenia na język polski nazwa dziedziny nauki: information science , 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ą , otrzymamy trzy kluczowe role komponentów: przetwarzanie, zarządzanie przetwarzaniem, przechowywanie. To ostatnie to przechowanie danych w „paczkach” zorganizowanych kontekstowo jako dokumenty . 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):
Struktura kluczowych komponentów aplikacji (robocza nasza MPS: Management, Processing, Storage) jako PIM (Platform Independent Model)
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:
Struktura architektury usługi aplikacji na bazie wzorca BCE
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) , można wstępnie tak zobrazować abstrakcyjną architekturę aplikacji:
Abstrakcja architektury 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.
Hjùrland, B. (2001). Domain analysis in information science.
Borko, H. (1968). Information science: 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/10.1109/Innovate-Data.2017.13
Rosenberg, D., & Scott, K. (1999). Use case driven object modeling 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/10.1109/CICSyN.2015.30
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Dane niestrukturalne stanowią ponad 80% składowanych danych, to oznacza, że model relacyjny pozwala opisać i przetwarzać tylko ułamek posiadanej informacji (UNSTRUCTURED DATA AND THE 80 PERCENT RULE)
Wstęp
W podsumowaniu niedawnego artykułu o NoSQL w chmurze, napisałem:
Problem projektowania struktur dokumentów, także w bazach dokumentowych, to osobne i trudne zagadnienie. Opisałem go w najnowszym artykule, który ukaże się za niedługo w wydawnictwie IGI Global: Emerging Challenges, Solutions, and Best Practices for Digital Enterprise Transformation. (Repozytorium w chmurze – NoSQL – Jarosław Żeliński IT-Consulting – Systemy Informacyjne)
Artykuł sie właśnie ukazał. We wstępie napisałem:
Dokumenty często zawierają dużą ilość różnych danych tworzących wspólnie wiele kontekstowych zbiorów danych (agregatów). Zastosowanie modelu relacyjnego do organizacji takich danych prowadzi do wygenerowania rozbudowanego systemu powiązanych relacyjnie tabel, przy czym usunięcie redundancji często powoduje utratę kontekstu treści poszczególnych pól w tabelach. Rodzi to konieczność stosowania wysoce złożonych zapytań SQL, aby dokumenty te mogły być zapisywane w tej bazie danych i z niej pobierane. W ten sposób sama baza danych zawiera wyłącznie dane pozbawione kontekstu obecnego w tabelach, a nie dokumenty.
Wielu autorów zwracało uwagę na problem złożoności i utraty jednolitego kontekstu modelu relacyjnego (Ślęzak i in., 2018). Autorzy ci sugerowali, że konteksty powinny być separowane w dużych relacyjnych modelach danych. Jednak zalecenie separacji kontekstów (Evans, 2003; Fowler, 1997; Fowler & Rice, 2005), przy zachowaniu modelu relacyjnego, nie pomaga w całkowitym rozwiązaniu problemu (Awang et al., 2012, 2012, 2012).
Praktyka pokazuje, że bazy te to odpowiedź na standardowe obecnie wymagania wobec systemów informacyjnych, jakimi są zmienność struktur danych, ich ograniczona strukturalizacja lub nawet jej całkowity brak .
Akronim NoSQL został po raz pierwszy użyty w 1998 roku przez Carlo Strozzi’ego jako nazwa jego lekkiej, opensource „relacyjnej” bazy danych, która nie używała SQL. Nazwa ta pojawiła się ponownie w 2009 roku, kiedy Eric Evans i Johan Oskarsson użyli jej do opisania nierelacyjnych baz danych. Relacyjne bazy danych są często określane jako systemy SQL. Termin NoSQL może oznaczać zarówno „Nierelacyjna SQL” lub bardziej popularne tłumaczenie „Nie tylko SQL” (Not only SQL), aby podkreślić fakt, że niektóre systemy mogą obsługiwać języki zapytań podobne do SQL. (źr.: A Brief History of Non-Relational Databases – DATAVERSITY)
Jeden z moim zdaniem ciekawszych artykułów o NoSQL napisał Fowler 10 lat temu .
Bazy danych «key-value».
Bazy te są najprostszym typem bazy NoSQL. Każdy element (wiersz) w takiej bazie to para klucz i wartość (dane przechowywane), tu zawartość (dane przechowywane) to zawsze „jakiś plik” (podobnie jak pole typu BLOB: Binary Large OBject). Zawartość ta może być pobrana wyłącznie poprzez odwołanie się do jej identyfikatora (klucza) . Bazy te są doskonałe do przechowywania dużych ilości różnorodnych danych, gdzie nie trzeba przetwarzać treści tych danych w samej bazie (np. wyszukiwanie zawartości na podstawie jej określonych cech). Służą one wyłącznie do zachowywania i odzyskiwania plików. Praktycznie jest to płaski system plików.
model repozytorium key-value (opracowanie własne autora)
metoda zapisu w repozytorium key-value (opracowanie własne autora)
Dokumentowe bazy danych.
To odmiana bazy key-value. Przechowuje dane w postaci określonej strukturalnej treści: dokumentów (np. JSON czy XML). Struktury te mają swoje definicje, a ich typów może być dowolna liczba . Jedna baza może więc zawierać dokumenty o dowolnie wybranej, określonej strukturze. Dostępne na rynku bazy tego typu maja także bardzo dobre i szybkie motory zapytań, są coraz częściej stosowane jako bazy danych ogólnego przeznaczenia.
Baza dokumentowa. Dokument to czytelna dla człowieka treść, w bazach dokumentowych ma on określona ale nie sztywną strukturę: może to być JSON, XML. Dokument (jego treść) jest przetwarzany poza bazą danych (komponent Logika biznesowa). (opracowanie własne autora)
Bazy zmieno-kolumnowe.
Przechowują dane w postaci agregatów o zmiennych „liściach”. Bazy tego typu zapewniają dużą elastyczność w stosunku do relacyjnych baz danych, ponieważ nie jest wymagane, aby każdy wiersz agregat posiadał tyle samo i te same elementy (kolumny) . Bazy tego typu są powszechnie stosowane do przechowywania danych np. danych profilowych użytkowników. Są często opisywane w poniższy sposób:
Model architektury komponentu z bazą zmienno-kolumnową (powyższe wyrażone jako model dziedziny komponentu z użyciem UML)
Jak widać, bazy te przechowują agregaty. Nazwanie agregatu „wierszem” jest niefortunne bo to jednak nie są płaskie tabele, jednak pojęcia wierszy i kolumn zrzucam tu jednak na karb stereotypu zaczerpniętego z modelu relacyjnego.
Grafowe bazy danych.
Przechowują dane w postaci węzłów i krawędzi (asocjacje między węzłami). Węzły zazwyczaj przechowują informacje o obiektach (ludzie, miejsca, przedmioty) krawędzie zaś przechowują informacje o możliwych związkach między węzłami . Grafowe bazy danych doskonale sprawdzają się w przypadkach gdy trzeba zapisywać i śledzić związki między obiektami i analizować je, np. sieci społecznościowe czy wykrywanie oszustw. Tak są najczęściej opisywane grafowe bazy danych, a przedstawiane są np. tak:
Uważam, że powyższe to trywialna i naiwna metoda przedstawiania baz tego typu. Istotą systemu przetwarzania informacji jest tu (w takim modelu) jest przechowywanie informacji o obiektach i o faktach je łączących takich jak zdarzenia dotyczące pary obiektów . Mogą to być typowe fakty, np. Samochód miał kolizje w Mieście, gdzie Samochód i Miasto to węzły, a kolizja to zdarzenie. Ważne jest to, że Samochód i Miasto można opisać określonym cech, sama kolizje także, ważne jest to, że faktów łączących dwa obiekty może być wiele (w czasie).
Związki między obiektami opisywane są też metodą RDF (Resource Description Framework) jako zdania: Subject – Predicate – Object .
O każdym obiekcie będzie jeden rekord w bazie danych, o każdym fakcie też, ale różnych faktów, których cechami są te obiekty może być wiele (cechą stłuczki jest między innymi miejsce stłuczki i samochód, który miał tę stłuczkę). Cechami obiektów są nazwa, data powstania i ewentualna data usunięcia (zniszczenia), także cechy definiujące takie jak np. kolor, typ czy wydawane dźwięki. Cechami fakty są czas zaistnienia oraz obiekty (ich nazwy), których określony fakt dotyczy. Ważne jest to, że położenie obiektu nie jest jego cechą definiującą. Graf jest definiowany jako nazwane związki między obiektami, są nimi właśnie fakty (a szerzej: predykaty). Warto też zaznaczyć, że w kontekście np. zdarzeń gospodarczych, faktem jest faktura opisująca transakcje do jakiej doszło. Jednak w archiwum dokumentów faktura jest obiektem archiwalnym .
Tak więc bardziej sformalizowana struktura danych w bazie grafowej mogła by wyglądać tak:
Struktura informacyjna grafowej bazy danych: obiekty (niebieskie) i związki (żółte) (opracowanie własne autora)
Diagram powyższy jest kolorowany dla poprawy czytelności. W tej postaci widać obiekty i łączące je fakty: w bazach grafowych są to formalnie tak zwane związki semantyczne (znaczeniowe), ale jest to jednak duże uproszczenie. Systemy zapisu informacji w postaci trójek: pojęcie-predykat-pojęcie mają szersze uzasadnienie (planuję publikację z wynikami szerszych badań). Metamodel systemu zapisu informacji o obiektach i związkach między nimi wygląda tak:
Metamodel grafowej bazy danych (opracowanie własne autora)
Warto zauważyć, że zarówno Obiekt jak i Związek semantyczny mogą być przechowywane w bazie dokumentowej lub kolumnowej…
Podsumowanie
To co dzisiaj nazywamy bazami danych NoSQL to tylko naturalne modele informacyjne. Kiedy odkryte? Nie wiem, ale wiem, że w tym wszystkim najbardziej nienaturalny jest model relacyjny. Dlaczego? Bo nie występuje w naturze i sprawia same problemy. Celowo zaprezentowałem sformalizowane diagramy UML dla każdego typu, by pokazać, że NoSQL to tylko i aż modele informacyjne spotykane w rzeczywistości życia człowieka. Konstrukcje jak te wyżej opisane, to tak na prawdę modele informacji wynikające z dziedziny problemu, nie jest tak że są używane z powodu „wynalezienia” baz NoSQL, jest dokładnie odwrotnie.
Obecne bazy NoSQL rozumiane jako „motory baz danych”, to implementacje informacyjnych wzorców projektowych. Diagramy UML powyżej to metamodele tych wzorców.
Na temat baz danych i baz NoSQL polecam kompleksowe opracowanie Joe Celko: Complete guide to NoSQL: what every SQL professional needs to know about nonrelational databases .
Podsumowanie 2
Pojawiają się tezy że to się nie nadaje do ERP, że nikt tak nie robi… Otóż:
Systemy ERP budowane w oparciu o centralne bazy danych RDBMS ewoluujące do chmury są niejako skazane na bazy NoSQL (znakomita większość chmurowych repozytoriów chmurowych to bazy NoSQL).
Ewolucja Architektury tak zwanych standardowych ERP
Podstawowym problemem systemów zbudowanych w oparciu o bazy RDBMS/SQL jest to, że nie ma w nich dokumentów, a jedynie dane rozłożone w tabelach. Uzyskanie dokumentu (np. faktury) wymaga każdorazowo dynamicznego zebrania danych z wielu tabel, ich złączenia i sformatowania, czyli użycia języka SQL. Dlatego ewolucja nowoczesnych systemów ERP idzie w kierunku systemów, w których funkcje kalkulacyjne oraz dokumenty są rozdzielone, a dokumenty są przechowywane w postaci zmaterializowanej:
Zarządzanie dokumentami w systemach ERP
Podsumowanie 3
Od dłuższego czasu stosuje w projektach struktury informacyjne nazywane NoSQL. Sa to praktycznie wszystkie opisane wyżej struktury. Projekt dla agencji fotograficznej BE&W (archiwum zdjęć), projekt dla Biura Polonii Kancelarii Senatu (obsługa wniosków o dofinansowanie o zmiennej strukturze), projekt dla Żandarmerii Wojskowej (zarządzanie sprawami dochodzeniowo-śledczymi w całej Polsce), projekt dla KGHM (standaryzacja systemu utrzymania ruchu, zarządzanie infrastrukturą produkcyjną).
Więcej już niedługo… Zachęcam do zadawania pytań o NoSQL pod tym wpisem.
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/10.1007/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/abs/1910.09017
Celko, J. (2014). Joe Celko’s Complete guide to NoSQL: what every SQL professional needs to know about nonrelational databases. Elsevier/Morgan Kaufmann.
Garba, M. (2020). A Comparison of NoSQL and Relational Database Management Systems (RDBMS). 1(2), 9.
Karnitis, G., & Arnicans, G. (2015). Migration of Relational Database to Document-Oriented Database: Structure Denormalization and Data Transformation. 2015 7th International Conference on Computational Intelligence, Communication Systems and Networks, 113 – 118. https://doi.org/10.1109/CICSyN.2015.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/10.14569/IJACSA.2015.061111
Guimaraes, V., Hondo, F., Almeida, R., Vera, H., Holanda, M., Araujo, A., Walter, M. E., & Lifschitz, S. (2015). A study of genomic data provenance in NoSQL document-oriented database systems. 2015 IEEE International Conference on Bioinformatics and Biomedicine (BIBM), 1525 – 1531. https://doi.org/10.1109/BIBM.2015.7359902
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Coraz częściej czytamy o środowiskach „chmurowych” (nadal nie mogę się przekonać do pisania tego bez cudzysłowu). Nawet tak zaawansowane jak Amazon WS czy AZURE, są nadal bardzo często wykorzystywane tylko jako hosting aplikacji. Oba te serwisy można wykorzystywać jako sieciowy dysk, środowisko systemowe (Windows, Linux), bazę danych SQL, ale także jako bazy NoSQL.
Jednym z najistotniejszych elementów systemów informacyjnych (patrz: information science) jest utrwalanie danych (pamiętajmy, że dane to zapisy, a informacja to to, co rozumie człowiek, który je czyta). Niedawno nawiązywałem do problemu utrwalania danych.
Poprawna obiektowa architektura i kompletny projekt techniczny aplikacji (model PIM) opisuje precyzyjnie jak wykonać implementacje i nie zawiera projektu żadnej bazy danych, ani tym bardziej zapytań SQL. Implementacja utrwalania nie może mieć wpływu na logikę biznesową systemu ani nawet zawierać jej! (źr.: Dokument a kumulacja faktów: OOAD i model dziedziny systemu) Prosty diagram po lewej stronie pokazuje problem opisany przez Smith’a jako „Computers, Models, and the Embedding World, The Limits of Correctness.”
Komputer (rozumiany jako procesor, pamięć i program) stanowi dla człowieka narzędzie pracy.
Cechą komputera jest w ogromnej większości przypadków odwzorowywanie tego co zastępujemy komputerem, a tak zwane systemy biznesowe, zastępują papierowe formy przetwarzania i przechowywania informacji. Systemy ERP, CRM, Workflow, Sklepy internetowe, Archiwa, i wiele innych to tak na prawdę dokumenty i ich treść.
Istota problemu polega na tym, że określone, dostępne technologie same z siebie często stwarzają ograniczenia tego co mogą (potrafią) odwzorować, i mimo upływu czasu i postępu technologii, analiza i projektowanie zarządzania informacją nadal jest jednym z największych problemów wdrożeń systemów.
SQL vs. NoSQL
SQL
Skrót NoSQL jest intepretowany jako „nie SQL” lub „nie tylko SQL” (Not only SQL). SQL (Structured Query Language) to język zapytań do baz danych o relacyjnym modelu danych (ang. RDBMS: Relational Data Base Management System). Cechą tego modelu danych jest usuwanie redundancji i podział danych na tabele i słowniki pól tych tabel, oraz związki między nimi (relacje). W efekcie otrzymujemy schematy tabel i relacji między nimi np. takie:
A nawet takie:
(model danych pewnego systemu ERP)
Odtworzenie dokumentu (formularza) będącego np. fakturą lub deklaracją podatkową, wymaga wykonania szeregu bardzo skomplikowanych operacji łączenia danych z tych tabel i odwzorowania ich pierwotnej postaci np. faktury. W tego typu bazach danych fizycznie nie ma żadnych dokumentów.
Drugim problemem jaki stwarza model relacyjny, jest konieczność jego przebudowy praktycznie zawsze, gdy zmieni się struktura przechowywanych w nim dokumentów (opracowanie nowego modelu, migracja danych do nowego modelu – bywa że niemożliwa w 100%, aktualizacja zapytań SQL do nowej struktury bazy danych).
Biorąc pod uwagę fakt, że realny świat to ciągłe zmiany, model relacyjny jest w tym przypadku po prostu nieadekwatny.
Koszty utrzymania i rozwoju systemów zarzadzania danymi (i aplikacjami, które je wykorzystują) w modelu relacyjnym, są wielokrotnie wyższe niż pierwotne ich wdrożenie .
Po co więc wymyślono te relacyjne bazy? To były czasy gdy pamięć była najkosztowniejszym zasobem komputera zaś dane między systemami w zasadzie nie były wymieniane! Było kilka zalet, np. brak błędów nazewnictwa itp. więcej o nich w sieci można poczytać, jednak moim zdaniem baza danych będąca implementacją tak zwanych związków pojęciowych (tym są relacyjne modele danych) nie sprawdza się bo nie modeluje obiektów świata rzeczywistego a jedynie ich nazwy i powiązania między nimi a to ogromna różnica. (źr.: SQL albo NoSQL, oto jest pytanie – 2011 r.)
NoSQL
Jednym z typowych przykładów bazy danych typu NoSQL są bazy typu key-value i ich odmiany . Z uwagi na ich cechy i powszechność skupię się na tego typu bazach.
Wśród tego typu baz są tak zwane bazy dokumentowe. Idea tego typu baz danych realizuje jedno podstawowych założeń obiektowego paradygmatu (role obiektów): repozytorium nie służy do przetwarzania treści a jedynie do jej utrwalania i szybkiego przywoływania (dostępu). Przetwarzaniem danych (treści) zajmują komponenty odpowiedzialne wyłącznie za realizację logiki aplikacji. Skoro repozytorium nie przetwarza treści, jest ono – przechowywana treść i jej struktura – neutralnym elementem. Dlatego operujemy tu często pojęciem plik, którym zależnie od typu bazy, może być np. ciąg znaków XML lub JSON albo po prostu ciąg binarny (czyli „cokolwiek”). Taka baza to hipotetyczne dwie kolumny: pierwsza zawiera identyfikatory wierszy a druga przechowywaną treść. I teraz zależnie od typu bazy i logiki aplikacji, która ją wykorzystuje, tą treścią może by ciąg znaków (np. XML, JSON) lub dowolny ciąg znaków binarny (czyli XML także, ale także np. zdjęcie lub plik edytora tekstów).
Przykładem bazy dokumentowej jest Amazon DynamoDB. Poniższy diagram pokazuje w uproszczeniu idee tej bazy i porównanie z typową modelem relacyjnym: odtworzenie dokumentu z bazy relacyjnej (po lewej) wymaga skomplikowanych operacji łączenia tabel, po prawej stronie mamy zaś zestaw ciągów znaków, każdy stanowi sobą kompletny już dokument, mogą one mieć różną strukturę. Pobranie dokumentu z bazy po prawej odbywa się zawsze prostym zapytaniem, takim samym„ bez względu na strukturę tych danych.
Dzięki temu osiągamy dwie kluczowe korzyści: zmieniająca się w czasie struktura dokumentów nie wpływa na bazę danych, czas pobrania dokumentu jest bardzo krótki i nie zależy od struktury dokumentu . Różnicę efektywności pokazano poniżej:
Dokument jako struktura danych
Opisane bazy NoSQL mają szereg zalet w stosunku do baz danych w modelu relacyjnym. Jednak problem tworzenia modeli relacyjnych jest zastępowany problemem modelowania struktur dokumentów . Nie jest to jednak problem budowania znormalizowanych relacyjnych struktur danych. Jest to problem natury czysto semantycznej: rzecz w tym czym jest dokument i czym są pola, z których on się składa. Jest wiele podejść do tego zagadnienia, uważam, że kluczowe jest odkrycie i zrozumienie co opisuje dany dokument. Po drugie istotne jest umiejętne zaprojektowanie logiki aplikacji. Dlatego repozytoria NoSQL z zasady nie biorą udziału w logice biznesowej ale struktura dokumentów determinuje logikę ich przetwarzania. Rolą repozytorium jest wyłącznie utrwalanie i udostępnianie. Poniżej przykład dość typowy: faktury i opisy produktów (opis produktu jako Karta Produktu): mimo tego, że oba te typy dokumentów mają inną strukturę, mogą być przechowywane w jednej i tej samej bazie danych NoSQL.
Rejestry separujące dokumentową bazę danych od logiki aplikacyjnej, diagram pochodzi z wydanej właśnie publikacji, w której dokładnie opisano zasady projektowania systemów informacyjnych i tego typu repozytoriów: .
Baza dokumentowa służy wyłącznie do przechowywania danych. Kontekstowy i semantyczny dostęp do danych zapewniają dziedzinowe rejestry: dodatkowe proste tabele umieszczone przez repozytorium, w części aplikacyjnej. Z uwagi na to, że bazy dokumentowe nie nadają się do realizacji wyrafinowanych zbiorowych obliczeń na treści dokumentów, wykorzystuje się do tego typowe hurtownie danych.
[uzupełnienie miesiąc później] Z tego względu bardzo przydatny jest tu dobrze znany wzorzec projektowy Repozytorium (Repository). Istotą tego wzorca jest separacja kolekcji obiektów (np. nośników dokumentów) od logiki aplikacji za pomocą klasy realizującej interfejs do tej kolekcji. Poniżej wersja adresowana do chmury:
Realizacja utrwalania (zapis danych) to obiekty przechowujące («Storage» Repozytorium danych) oraz dane («document» Zestaw danych) przechowywane jako dokumenty (XML, JSON) lub pliki (baza key value). Dostęp do tej kolekcji zapewnia klasa «Management» Kontrola dostępu do danych, stanowiąca zarazem interfejs do tej kolekcji. Interfejsów do jednego repozytorium może być więcej, realizują one wtedy kontekstowe udostępnianie danych z tej samej kolekcji. Tak więc Realizacja usługi to dziedzinowy kod aplikacji, zaś Realizacja utrwalania to chmurowa usługa taka jak bazy NoSQL dostępne w chmurze.
Chmury Amazon i AZURE
Ciekawym przykładem bazy dokumentowej jest DynamoDB. Jest to partycjonowana baza NoSQL mająca dwie kolumny z kluczem: jeden to standardowy dla tego typu bazy identyfikator, drugi to klucz wskazujący na strukturę definiującą format danych w trzeciej kolumnie przechowującej dane (dokumenty). Jest to baza przechowująca dane w formacie JSON, więc ich interpretacja wymaga definicji konkretnej struktury danych. dodatkowa kolumna (SortKey) pełni rolę definicji typu (identyfikator struktury). Jest to wygodne bo w systemach obiektowych łatwo definiuje się typy złożone, nadając każdemu rekordowi dodatkowy identyfikator, można intepretować pobrane dane.
Więcej informacji o repozytoriach Amazon, także Amazon S3 (bardzo szybka baza plików) znajdziecie w książce wydawnictwa Helion: Amazon Web Services . Analogiczne rozwiązanie oferuje AZURE.
Na zakończenie
Osobiście polecam rozważenie opisanych tu rozwiązań w swoich projektach. W obszarze dokumentów i zarządzania ich treścią są wręcz doskonałe. Model relacyjny, doskonały do obliczeń, niestety przegrywa z kretesem w aplikacjach biznesowych, gdzie zaczyna się liczyć przede wszystkim szybkość dostępu do ogromnej ilości danych oraz odporność na szybko zmieniające się wymagania co do struktury danych.
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/10.14569/IJACSA.2015.061111
Wilkins, M. (2020). Amazon Web Services: podstawy korzystania z chmury 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 study of genomic data provenance in NoSQL document-oriented database systems. 2015 IEEE International Conference on Bioinformatics and Biomedicine (BIBM), 1525 – 1531. https://doi.org/10.1109/BIBM.2015.7359902
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Tym razem znowu obiektowe analiza i projektowanie. Na stronie SQL albo NoSQL, oto jest pytanie pojawiła się ciekawa wypowiedź. Jako, że osobiście „idę w kierunku” obiektowych systemów gdzie dane są indywidualną cechą obiektów a nie super-centralnym składowiskiem pozwolę sobie na dywagacje. Proszę ich nie traktować jako „prawdę w moim wydaniu”, jest to raczej moje obecne postrzeganie tego zagadnienia. Wypowiedzi autora wskazanego tekstu wcięte.
No dobra, korzystając z baz NoSQL zyskujemy lepszą skalowalność, brak sztywnego schematu bazy danych, sporą elastyczność, mniej problemów z mapowaniem danych w bazie do obiektów zdefiniowanych w kodzie i pewnie jeszcze kilka rzeczy, o których nie mam pojęcia. Ale pojawiają się ograniczenia. Czasem bardzo istotne. Po pierwsze bazy NoSQL nie są relacyjne. Może i jest to oczywiste, ale chyba nie wszyscy tak do końca zdają sobie sprawę, co to tak na prawdę oznacza. Całą obsługę relacyjności pomiędzy danymi (jeśli jest nam potrzebna) trzeba emulować w kodzie aplikacji, na wbudowane w bazę danych rozwiązania nie ma co liczyć.
Zarzut, że bazy NoSQL nie są relacyjne jest dla tych baz raczej komplementem. Kluczowym tu stwierdzeniem torpedującym w moich oczach wywód jest uznanie faktu, że relacyjność może nie być potrzebna. Owszem, dodam nawet, że nie raz po prostu ciąży. Po drugie moim zdaniem błędne jest stwierdzenie, że relacyjność należy emulować w kodzie. Otóż nie, bo może być po prostu niepotrzebna!.
Po drugie często brak JOINów. […] Potrafi to bardzo utrudnić pisanie wydajnych zapytań, a przecież rozliczany jestem z każdej milisekundy pracy procesora.
Kolejny moim zdaniem błąd w myśleniu: długie, wymagające optymalizacji, skomplikowane zapytania są właśnie cechą zapytań do baz relacyjnych. Bazy relacyjne, po dokonaniu normalizacji, w zasadzie żadnej informacji nie trzymają w jednym kawałku, wszystko wymaga posklejania przed użyciem. Pozyskanie treści zwykłej faktury z takiej bazy, wymaga posklejania jej z dziesiątek składowych tablic i słowników, wymaga to faktycznie nie lada sztuki w napisaniu zapytania do bazy a co dopiero taki raport faktur sprzedaży z poprzednich okresów.
Dlaczego o tym piszę? Otóż jednym z większych, w moich oczach, problemów jest wykształcenie projektantów i programistów. Nie, nie. Nie twierdze że jest złe, po protu nadal na wyższych uczelniach na kierunkach informatyki przedmioty takie jak analiza i modelowanie obiektowe w relacji do klasycznych zajęć w rodzaju programowanie w Pascalu, C++ i modelowanie relacyjnych baz danych to pyłek w programie nauczania.
Troszkę wyjaśnień
Relacyjne bazy danych (RDBMS) to w ogólnym sensie, po ludzku, dane uporządkowane w powtarzające się struktury trwale z sobą powiązane. Jedna z definicji spotykanych w sieci:
W najprostszym ujęciu w modelu relacyjnym dane grupowane są w relacje, które reprezentowane są przez tablice. Relacje są pewnym zbiorem rekordów o identycznej strukturze wewnętrznie powiązanych za pomocą związków zachodzących pomiędzy danymi. Relacje zgrupowane są w tzw. schematy bazy danych. Relacją może być tabela zawierająca dane teleadresowe pracowników, zaś schemat może zawierać wszystkie dane dotyczące firmy. Takie podejście w porównaniu do innych modeli danych ułatwia wprowadzania zmian, zmniejszenie możliwość pomyłek, ale dzieje się to kosztem wydajności. (źr. http://pl.wikipedia.org/wiki/Model_relacyjny)
Jak to wygląda w praktyce. Postaram się to pokazać na nas samych. Wyobraźmy sobie strukturę organizacyjną firmy i jej pracowników. Normalną rzeczą jest, że każdy z nas zna Nazwisko przełożonego, wie jakich ma (jeśli ma) podwładnych, zna nazwę swojego stanowiska, zna nazwę działu, w którym pracuje i pamięta nazwę firmy, która go zatrudnia. Ogólnie mamy te dane w głowie (prędzej czy później się tego nauczyliśmy). Niewątpliwie jeżeli ktoś ma dziesięcioro podwładnych, to każdy z nich ma w głowie (w pamięci) komplet tych danych, zostały więc powielone 10-krotnie. Marnotrawstwo kory mózgowej zespołu?!. Nie, po prostu ewolucja dawno temu odkryła, że pewne dane należy mieć do użycia ad-hoc u siebie bo w naturze liczy się natychmiastowy dostęp do tych danych (informacji) a nie oszczędność szarych komórek danej populacji.
Tak więc nazwisko podwładnego znam na pamięć, a co gdy potrzebuje jego adres? Czy muszę wkuwać to wszystko na pamięć? Nie, bo rzadko z tego korzystam! Muszę tylko wiedzieć tylko gdzie jest dział kadr, tam są kartoteki pracowników. Idę do Pani/Pana i proszę o teczkę personalną osoby XXX i dostaję, a tam mam wszystko. Przepisuje (powielam!) na kopertę adres do korespondencji, oddaję teczkę personalną i wracam do swojego biurka, pisze list, zaklejam kopertę i wysyłam. To model obiektowy świata, dane – wyłącznie niezbędne – są przechowywane w naszych głowach nierelacyjnie, reszta ma swoje miejsca, wystarczy że wiem gdzie są, w razie potrzeby o nie poproszę.
A teraz inny model. Jedyne co wiemy o sobie to to, że jesteśmy na tym świecie (znamy tylko swoje nazwisko i imię), wszystko inne: nasi podwładni, przełożeni, nazwy departamentów, itp. to tylko niteczki prowadzące do zapisów o nich. Nie wiem nic o sobie, jak ktoś zapyta kto jest moim szefem muszę złapać za niteczkę o nazwie przełożony i zobaczyć co jest na jej końcu. Jak mnie ktoś zapyta kto jest moim prezesem, po tych niteczkach, jak domino, będą brnęli moi przełożeni aż na szczyt hierarchii zatrudnienia i powiedzą mi, dopiero kto jest moim prezesem. Jeżeli jestem szefem, to mam dodatkowo tyle niteczek do paska ilu mam podwładnych, nie znam żadnego z nich, za każdym razem by wskazać któregokolwiek muszę pociągnąć za wszystkie niteczki, wybrać jednego z nich i dopiero dać mu robotę. Tak wygląda model relacyjny. Tak zwana normalizacja danych polega na tym, że jeżeli jakakolwiek informacja miała by się powtórzyć w czyjejś głowie, to odbieramy mu te informację, tworzymy karteczkę, na której ją zapisujemy i niteczkami te karteczkę podpinamy do każdego komu te informacje odebraliśmy. Każda taka karteczka to prosty słowniczek gdzie każdy zapis jest powiązany niteczką ze wszystkim czego dotyczy. Tak więc jak mnie ktoś zapyta gdzie pracuję to zamiast z głowy natychmiast odpowiedzieć muszę pociągnąć za niteczkę Pracodawca i zobaczyć co tam jest napisane przy mojej niteczce (a jest ich tam nie mało). Owszem, nazwa pracodawcy będzie tylko raz zapisana, prawdopodobnie uzyskamy ogromne oszczędności miejsca na zapisy ale też ogromnie skomplikujemy i wydłużymy dostęp do informacji.
Jak widać, pozyskanie jakiejkolwiek informacji z relacyjnego repozytorium to dość karkołomny zabieg. Do tego taki system ma jeszcze jedną wadę: jak już raz wymyślimy jakie to mają być karteczki, jak je ze sobą pospinamy niteczkami, zapiszemy je, i nazbiera się nam tego, to system staje w zasadzie już niemodyfikowalny. Jak się przytrafi sytuacja, w której dostaniemy jakieś informacje ze źródła, w którym te karteczki choć troszkę inaczej zostały wymyślone (co jest prawie pewne) to mamy poważny problem. Nie da się tego zapisać w naszym systemie wprost, musimy posklejać tę cudza wiedzę i na nowo rozebrać na małe karteczki ale już po naszemu.
Po co więc wymyślono te relacyjne bazy? To były czasy gdy pamięć była najkosztowniejszym zasobem komputera zaś dane między systemami w zasadzie nie były wymieniane! Było kilka zalet, np. brak błędów nazewnictwa itp. więcej o nich w sieci można poczytać, jednak moim zdaniem baza danych będąca implementacją tak zwanych związków pojęciowych (tym są relacyjne modele danych) nie sprawdza się bo nie modeluje obiektów świata rzeczywistego a jedynie ich nazwy i powiązania między nimi a to ogromna różnica.
A co dzisiaj mamy
Dzisiaj mamy: wiele różnych systemów w każdej firmie, powszechną wymianę danych wewnątrz firmy i między firmami oraz najgorsze czyli zmienność środowiska biznesowego. Co mogę poradzić?
Jeżeli planujesz wdrożenie gotowego systemu opartego na relacyjnej bazie pamiętaj, że:
- etap jego wdrażania i parametryzacji to ostatni moment na decyzje o strukturze informacji, potem praktycznie już nie da się tego zmienić
- jeżeli w trakcie analizy wykryjesz w swojej firmie jakieś szybkozmienne obszary, zamiast inwestować w kolejny moduł dużego systemu ERP, zleć napisanie dedykowanego podsystemu w nowszej technologii i zintegruj go z tym ERP
- jeżeli dostawca ERP powie Ci, że integracja czegokolwiek z tym system wymaga dużej i kosztownej pracy nie kupuj tego systemu.
Tak wiec zanim wybierzemy system ERP wyobraźmy sobie, że wdrożenie zmusi nas do przeniesienia naszej wiedzy z głów na małe karteczki, zmusi nas do powiązania tego wszystkiego setkami niteczek, pogodzenia się z tym, że dopóki będziemy mieli ten system niewiele będziemy mogli później w tym wszystkim cokolwiek zmienić. Jedną z poważniejszych wad systemów zintegrowanych jest to, że są zintegrowane gdyż nadal większość z nich to integracja poprzez współdzielenie danych.
Co robić? Moim zdaniem warto po prostu dobrze się nad tym wszystkim zastanowić, ocenić różne warianty i na końcu dopiero wybrać system ERP i jego dostawcę. Raczej złą kolejnością jest kolejność odwrotna.
[2012]
Na konferencji GOTO wystąpił Martin Fowler, który tak widzi wpowyższe problemy:
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.