Dokument i jego struktura jako metoda zarządzania danymi

Wprowadzenie

Bardzo wie­le pro­ble­mów w toku wdro­żeń IT rodzą wadli­wie zapro­jek­to­wa­ne struk­tu­ry doku­men­tów. Dotyczy to w szcze­gól­no­ści zarzą­dza­nia dostę­pem do tre­ści, a patrząc sze­rzej: do infor­ma­cji. Ostatnie lata to mię­dzy inny­mi pro­ble­my urzę­dów z udzie­la­niem dostę­pu do infor­ma­cji publicz­nej, od dwóch lat dodat­ko­wo pro­ble­my stwa­rza RODO. Źródłem pro­ble­mów jest treść doku­men­tów, rozu­mia­na jako pyta­nie: Czy te infor­ma­cje muszą być zawar­te w tym doku­men­cie”. Najpierw opi­szę mecha­nizm powsta­wa­nia przy­czyn pro­ble­mów i spo­sób ich roz­wią­za­nia. W pod­su­mo­wa­niu wska­żę jak i gdzie sobie z tym radzić. 

Czytaj dalej… Dokument i jego struk­tu­ra jako meto­da zarzą­dza­nia dany­mi”

Projekt aplikacji – przykład

Wstęp

Napisałem o orien­ta­cji na doku­men­ty w toku analiz:

Często jestem i ja pyta­ny o to ??Jak wyja­śnić zło­żo­ne roz­wią­za­nie tech­nicz­ne inte­re­sa­riu­szom nie­tech­nicz­nym?? Jak wie­lu mi podob­nych odpo­wia­dam: roz­ma­wiaj doku­men­ta­mi. Sponsor pro­jek­tu, przy­szli użyt­kow­ni­cy, postrze­ga­ją swo­ją pra­cę poprzez doku­men­ty: ich treść i układ. (Wymagania na for­mu­la­rze czy­li dia­gra­my struk­tur zło­żo­nych i XML)

Dzisiaj pój­dzie­my dalej, omó­wi­my to gdzie i jak zacho­wać tę infor­ma­cję. Posłużę się pro­stym przy­kła­dem przy­chod­ni wete­ry­na­ryj­nej. Artykuł będzie opi­sem meto­dy podej­ścia do ana­li­zy zorien­to­wa­nej na pro­ce­sy i dokumenty. 

Tekst ma dwie czę­ści: pierw­sza jest opi­sem dro­gi jaka pro­wa­dzi nas do zde­fi­nio­wa­nia tego jakie doku­men­ty, jaką mają (mieć) zawar­tość i struk­tu­rę. Praktycznie jest to opis ana­li­zy i pro­jek­to­wa­nia. Druga – krót­ka – to przy­kła­do­wa archi­tek­tu­ra logi­ki reali­za­cji apli­ka­cji, poka­zu­ją­ca miej­sce doku­men­to­wej bazy danych w archi­tek­tu­rze i pro­jek­cie, czy­li tak­że projektowanie. 

Celem tego wpi­su jest poka­za­nie czym może być ana­li­za oraz jej pro­dukt jakim jest Techniczny Projekt Oprogramowania.

Czytaj dalej… Projekt apli­ka­cji – przy­kład”

Biznesowy model danych – nie chcemy

Nadal obser­wu­ję to, że model rela­cyj­ny i two­rze­nie mode­li danych na eta­pie ana­li­zy wyma­gań” trzy­ma­ją się twar­do mimo tego, że nie wie­le wno­szą do pro­jek­tu a narzu­ca­ją (suge­ru­ją) kiep­ską archi­tek­tu­rę apli­ka­cji z jed­ną rela­cyj­na bazą danych. Co cie­ka­we zaczy­na­nie od bazy danych jest wręcz zaprze­cze­niem zwin­no­ści (koniecz­ność ukoń­cze­nia pro­jek­tu doce­lo­wej bazy danych przed roz­po­czę­ciem kodo­wa­nia czy­li kla­sy­ka water­fall, w efek­cie beto­no­wa­nie sta­nu z dnia roz­po­czę­cia) mimo, że autor­ki arty­ku­łu piszą o sobie że są agile…

Popatrzmy na to co pro­po­nu­ją w tym 2017 roku.:

If the­re are spe­ci­fic busi­ness rules in the sys­tem that set maxi­mums on the 0..n or 1..n rela­tion­ships, the­se can be inc­lu­ded in the bounds for con­text. For exam­ple, the PO for SeiSounds might want to spe­ci­fy that each acco­unt can only be asso­cia­ted with a maxi­mum of five users or liste­ners to avo­id friends buy­ing one paid sub­scrip­tion and sha­ring with eve­ry­one else. See the exam­ple below:

[…] CONCLUSION Business Data Diagrams are one of tho­se MUST HAVE models for any pro­duct that is dealing with data. The exer­ci­se of cre­ating the model itself cre­ates a power­ful, sha­red under­stan­ding of the under­ly­ing data con­structs as users under­stand it. Instrumental in hel­ping to iden­ti­fy addi­tio­nal, more deta­iled models that might be needed, the BDD can also help you get to a com­ple­te set of user sto­ries aro­und users inte­rac­ting with the data fol­lo­wing the cre­ate, use, edit, dele­te, move and copy actions. (Źródło: Deep Dive Models in Agile Series: Business Data Diagram

Powyższy model:

  1. dekla­ru­je kon­kret­ną zna­ną na teraz”, war­tość limi­tu licz­by użyt­kow­ni­ków Konta,
  2. pomię­dzy auto­rem, utwo­rem i sta­cją jest nic nie­mó­wią­ca (każ­de z każ­dym bez żad­nych ogra­ni­czeń) zależność,
  3. pozo­sta­łe ele­men­ty nie wno­szą war­to­ści doda­nej (utwór jest cechą arty­sty czy może arty­sta jest cechą utworu…).

Zaryzykuję tezę, że powyż­sze w zasa­dzie nie poma­ga deve­lo­pe­ro­wi w niczym. Czy wno­si coś do pro­jek­tu? W moich oczach sta­no­wi pro­ste zapi­sa­nie” tego co zezna­li inda­go­wa­ni zama­wia­ją­cy (arty­kuł zawie­ra opis histo­ry­jek użyt­kow­ni­ka i ich koja­rze­nia z tym mode­lem danych). Stwierdzenie zaś, że …spe­ci­fic busi­ness rules in the sys­tem that set maxi­mums on the 0..n or 1..n rela­tion­ships…, (np. mak­si­mum pię­cio­ro użyt­kow­ni­ków może jed­no­cze­śnie słu­chać), to nie regu­ła biz­ne­so­wa a kry­te­rium decy­zyj­ne (wię­cej o regu­łach biz­ne­so­wych w lite­ra­tu­rze). 

Trzeba sobie tu jasno powie­dzieć, że induk­cyj­ne podej­ście do ana­li­zy (zbie­ra­nie i zapi­sy­wa­nie obser­wa­cji w celu iden­ty­fi­ka­cji tren­du lub powtó­rzeń) przy­po­mi­na pró­by zro­zu­mie­nia gry w sza­chy meto­dą wie­lo­krot­nej obser­wa­cji roz­gry­wek. Im wier­niej­szy opis gry ma powstać, tym wię­cej obser­wa­cji nale­ży udo­ku­men­to­wać, co nie zmie­nia fak­tu, że taki doku­ment nie mówi abso­lut­nie nic o przy­szłych roz­gryw­kach. Alternatywą jest deduk­cyj­ne podej­ście, pole­ga­ją­ce na zro­zu­mie­niu i opra­co­wa­niu, moż­li­wie naj­mniej­szym nakła­dem pra­cy, reguł gry w sza­chy, cze­go udo­ku­men­to­wa­nie wyma­ga naj­wy­żej dwóch stron papie­ru A4, taki doku­ment opi­su­je tak­że w 100% wszyst­kie przy­szłe roz­gryw­ki… 

Jak inaczej podejść do tego? 

Na począ­tek nale­ży zro­zu­mieć dzie­dzi­nę pro­ble­mu i opi­sać ją słownikiem:

Powyższy model poję­cio­wy (dia­gram nota­cji SBVR, dia­gram klas nota­cji UML) to słow­nik pojęć a nie model danych. To dia­gram obra­zu­ją­cy poję­cia i kon­tek­sto­we związ­ki mię­dzy nimi (tym kon­tek­stem są fak­ty z dzie­dzi­ny ana­li­zo­wa­ne­go pro­ble­mu). Nie są to ani dane ani regu­ły biz­ne­so­we. Są to nazwy, a nie byty sys­te­mo­we”. Poza takim dia­gra­mem, nale­ży tak­że stwo­rzyć słow­nik pojęć biz­ne­so­wych w posta­ci tabe­li zawie­ra­ją­cej pre­cy­zyj­ne, dzie­dzi­no­we defi­ni­cje tych pojęć. Dla wygo­dy i pre­zen­ta­cji ich tre­ści nanio­słem dwie regu­ły na dia­gram, są sko­ja­rzo­ne z Kontem gdyż jego doty­czą. Co do zasa­dy regu­ły biz­ne­so­we są koja­rzo­ne z ele­men­ta­mi na innych dia­gra­mach poprzez sło­wa zdefiniowane.

Cała ana­li­za powin­na się zaczy­nać od udo­ku­men­to­wa­nia mode­li pro­ce­sów. Tu pomi­ną­łem te mode­le bo ich opi­sów jest na moim blo­gu wie­le, a chcę się sku­pić na dzie­dzi­nie dla jakiej powsta­je apli­ka­cja. Analiza i zro­zu­mie­nie pro­ble­mu pro­wa­dzi do stwo­rze­nia mode­lu dzie­dzi­ny apli­ka­cji. Taki model powsta­je na pod­sta­wie tre­ści doku­men­tów wewnętrz­nych i zewnętrz­nych (tu np. Ustawa o pra­wach autor­skich), poma­ga­ją co naj­wy­żej bie­żą­ce wyja­śnie­nia. Do jego powsta­nia nie są potrzeb­ne żad­ne warsz­ta­ty ani cało­dzien­ne spotkania.

Celem mode­lo­wa­nia dzie­dzi­ny sys­te­mu (tu apli­ka­cji) jest udo­ku­men­to­wa­nie wewnętrz­nej logi­ki apli­ka­cji, czy­li mecha­ni­zmu jej dzia­ła­nia. Absolutnie nie jest to model danych. Powyższy model nie jest mode­lem ukoń­czo­nym”, wyma­ga na pew­no dopra­co­wa­nia, jed­nak moim celem jest jedy­nie poka­za­nie idei jego two­rze­nia. Nazwy klas, atry­bu­tów, ope­ra­cji zawie­ra­ją poję­cia zawar­te w słow­ni­ku pojęć. Zapewnia to jed­no­znacz­ność i zro­zu­mie­nie. Dodam, że dopie­ro ten model poka­zu­je bar­dzo waż­ną rzecz, to że autor jest cechą utwo­ru a nie odwrotnie. 

Tak więc:

  1. uru­cho­mie­nie i korzy­sta­nie z emi­sji kon­tro­lo­wa­ne jest przez Zarządzanie emi­sją, tu spraw­dza­ne są i egze­kwo­wa­ne, regu­ły biznesowe, 
  2. kom­po­nent Zarządzanie emi­sją korzy­sta tak­że z infor­ma­cji zawar­tych w Koncie użyt­kow­ni­ka i Playlisty, deta­le utwo­rów pobie­ra z Repozytorium utworów. 

Tu waż­ne jest pod­kre­śle­nie, że regu­ła doty­czą­ca ogra­ni­cze­nia licz­by jed­no­cze­śnie słu­cha­ją­cych, jest oddzie­lo­na od Kont użyt­kow­ni­ków i (nie poka­za­nych tu) Subskrypcji. Dzięki temu para­metr ten jest łatwo mody­fi­ko­wal­ny z pozio­mu apli­ka­cji (para­me­try­zo­wa­ne kry­te­rium decy­zyj­ne) bez potrze­by jakich­kol­wiek inge­ren­cji w model danych”. Umieszczanie jakich­kol­wiek reguł w bazie danych (czy­li na pozio­mie imple­men­ta­cji utrwa­la­nia) jest nie­ste­ty ich beto­no­wa­niem”.

Zmienność, nie tyl­ko ryn­ku ale i samych reguł w orga­ni­za­cjach, to sta­ły ele­ment śro­do­wi­ska apli­ka­cji. Dlatego dobrą prak­ty­ką jest, by utrwa­la­nie danych (wszel­kie bazy danych, pli­ki itp..) nie słu­ży­ło do nicze­go poza utrwa­la­niem. Logika biz­ne­so­wa powin­na być w w 100% w apli­ka­cji a nie podzie­lo­na pomię­dzy apli­ka­cję i dane (żad­na baza danych nie jest w sta­nie prze­cho­wy­wać innych reguł biz­ne­so­wych niż bez­po­śred­nie związ­ki ilo­ścio­we). Na eta­pie imple­men­ta­cji, sto­su­je­my zasa­dę her­me­ty­za­cji, czy­li nie współ­dzie­li­my, na żad­nym pozio­mie, danych pomię­dzy repo­zy­to­ria­mi i nie usu­wa­my redun­dan­cji. Dzięki temu nie odci­na­my sobie dro­gi do zmian sys­te­mu takich jak np. zastą­pie­nie kla­sy Dane oso­bo­we inter­fej­sem do zewnętrz­ne­go sys­te­mu, dys­po­nu­ją­ce­go taki­mi infor­ma­cja­mi (kla­sa ta zosta­nie zmie­nio­na, sta­nie się wte­dy mostem do API zewnętrz­ne­go sys­te­mu co nie pocią­gnie za sobą jakich­kol­wiek zmian, bo inter­fejs tej kla­sy i jej nazwa pozo­sta­ną nie­zmie­nio­ne, patrz zasa­da open-clo­se prin­ci­pia oraz polimorfizm).

Poniżej klu­czo­we związ­ki w UML i ilu­stra­cja związ­ku pomię­dzy mode­lem poję­cio­wym a mode­lem struk­tu­ry (archi­tek­tu­ry, to model dziedziny):

Na zakoń­cze­nie war­to zauwa­żyć, że zmien­ność śro­do­wi­ska biz­ne­so­we­go powo­du­je, że żad­ne decy­zje o logi­ce biz­ne­so­wej nie są osta­tecz­ne, jed­nak są ele­men­ty nie­zmien­ne takie jak np. nasze dane oso­bo­we. Tak więc to, co powszech­nie nazy­wa­ne jest mode­lem danych” (busi­ness data dia­gram) w rozu­mie­niu opi­sa­nym przez autor­ki arty­ku­łu, nie ma dzi­siaj racji bytu. Ma sens zacho­wa­nie zamó­wie­nia i osob­no fak­tu­ry, ale to czy regu­łą jest jed­no zamó­wie­nie do jed­nej fak­tu­ry, pod­le­ga zmia­nom wyni­ka­ją­cym i ze zmien­no­ści pra­wa i ze zmien­no­ści mode­li biz­ne­so­wych. Nie widzę żad­ne­go powo­du dekla­ro­wa­nia już na począt­ku pro­jek­tu, tego by nie wię­cej niż 5 osób mogło korzy­stać z jed­ne­go kon­ta i sub­skryp­cji. W szcze­gól­no­ści nie widzę powo­du by taka zasa­da była zawar­ta w samym kodzie aplikacji.

Warto tak­że mieć na uwa­dze to, że opro­gra­mo­wa­nie może być two­rzo­ne z uży­ciem zewnętrz­nych kom­po­nen­tów dostęp­nych na ryn­ku. Założenie więc na samym począt­ku pro­jek­tu, że dane są w jed­no­li­ty spo­sób prze­cho­wy­wa­ne i współ­dzie­lo­ne w jed­nej cen­tral­nej i współ­dzie­lo­nej bazie danych, wraz z logi­ką ich uży­cia, jest tu nie tyl­ko nie­uza­sad­nio­ne ale wręcz szkodliwe. 

I na koniec grat­ka: dokład­nie ta powsta­ła, i nadal tak wyglą­da, znacz­na więk­szość obec­nych na ryn­ku sys­te­mów ERP, CRM itp.… 

oraz cytat z literatury

z 1994 roku:

(źr. Designing Objects Systems, Steve Cook, John Daniels, 1994 rok.)

Dokumenty czy niedokumenty.… czyli zarządzanie informacją i jej standaryzacja

Nie raz tu już pisa­łem, że ana­li­zy i pro­jek­ty zwią­za­ne bez­po­śred­nio z wyma­ga­nia­mi na opro­gra­mo­wa­nie to tyl­ko” ok. 3/4 moich pro­jek­tów. Jednak nawet, jeże­li pro­jekt nie jest nazwa­ny” infor­ma­tycz­nym, to zawsze jest infor­ma­cyj­ny” w rozu­mie­niu zarzą­dza­nia infor­ma­cją (tak­że zarzą­dza­nie wie­dzą). Tym razem kil­ka słów na temat doku­men­tów. Stanowią one pod­sta­wo­wą jed­nost­kę infor­ma­cji (i danych) w każ­dym sys­te­mie biz­ne­so­wym. Są tak­że źró­dłem danych dla hur­tow­ni danych.

Wstęp

Wiele pro­jek­tów zwią­za­nych z doku­men­ta­mi jest spro­wa­dza­nych do problemu:

jakie mamy doku­men­ty i co z nimi robimy?”

Zaniedbuje się bar­dzo waż­ny ele­ment: odpo­wiedź na pytanie:

czy nasze obec­ne doku­men­ty, ich ilość i treść, są właściwe?”

Otóż prak­ty­ka poka­zu­je, że dość czę­sto pro­ble­mem są doku­men­ty opra­co­wa­ne kie­dyś tam”. Inicjuje się pro­jekt z róż­ny­mi wyma­ga­nia­mi ale niko­mu nie przy­cho­dzi do gło­wy by zasta­no­wić się nad tym czy obec­ne doku­men­ty, w ich obec­nej posta­ci, są dobrym pomy­słem i powin­ny takie pozostać.

Czy doku­men­ty są nie­zmie­nial­nym bytem? Nie, nie są.

Każda orga­ni­za­cja obra­ca skoń­czo­ną licz­bą doku­men­tów, są to róż­ne­go rodza­ju for­mu­la­rze, w naj­ogól­niej­szym przy­pad­ku doku­men­tem jest po pro­stu każ­da treść, tak­że zwy­kła pro­za” np. notat­ka. Warto jed­nak zwró­cić uwa­gę na to, że nawet ona ma pew­ną struk­tu­rę: np. auto­ra, adre­sa­ta, temat, datę i treść. Dokumenty to okre­ślo­na kon­kret­na treść utrwa­lo­na z okre­ślo­ne­go powo­du (w prze­ciw­nym wypad­ku doku­ment nie by powstał). Osiem lat temu opi­sy­wa­łem kwe­stie róż­ni­cy mię­dzy doku­men­tem, wie­dzą, infor­ma­cją a danymi:

Czy baza danych to wie­dza?[?] Model jaw­nie poka­zu­je, że bez­po­śred­ni zwią­zek z Bazą Danych mają Dane. Dalej już są wyłącz­nie nie­ma­te­rial­ne poję­cia czym więc jest Zarządzanie Wiedzą (mil­czą­co zakła­dam, że zarzą­dzać moż­na czymś mate­rial­nym)? Jest to ?prze­cho­wy­wa­nie danych jed­no­znacz­nie zro­zu­mia­łych, opi­su­ją­cych okre­ślo­ne i ogra­ni­czo­ne licz­bą fak­ty inter­pre­to­wa­ne jako poj­mo­wal­na przez adre­sa­ta infor­ma­cja?. (Źródło: Potrzeby infor­ma­cyj­ne fir­my ? Zarządzanie wie­dzą | Jarosław Żeliński IT-Consulting)

Dzisiaj co nie­co o tym, dla­cze­go od cza­su do cza­su war­to się pochy­lić nad wzo­ra­mi doku­men­tów i czy cza­sem nie zmie­nić nie­co podej­ścia do nich.

Dokumenty w organizacji

Swego cza­su u jed­ne­go z moich klien­tów odkry­łem” cie­ka­wy doku­ment. Była to fak­tu­ra z doda­nym zesta­wem danych odpo­wia­da­ją­cym doku­men­tom WZ oraz ana­lo­gicz­nym zesta­wie­niem doty­czą­cym opa­ko­wań zwrot­nych. Ten super doku­ment był pomy­słem z przed wie­lu lat oso­by odpo­wie­dzial­nej za wyda­wa­nie i zarzą­dza­nie opa­ko­wa­nia­mi zwrot­ny­mi w maga­zy­nie. Uzasadnienie brzmia­ło: na jed­nym doku­men­cie będą wszyst­kie infor­ma­cje zwią­za­ne z kon­kret­ną sprze­da­żą i dosta­wą. Brzmi ład­nie jed­nak: prak­tycz­nie każ­dy kto miał z tym doku­men­tem do czy­nie­nia, w toku obsłu­gi zamó­wie­nia, dosta­wał nad­mia­ro­we dane, nie raz nie­jaw­ne (nie­któ­re) ceny, szcze­gó­ły zawar­to­ści paczek, war­tość towa­ru (po co ta wie­dza kie­row­com), ilo­ści i sal­da (tak) opa­ko­wań zwrot­nych (jak się oka­za­ło doku­ment nie raz poma­gał w nad­uży­ciach, nie­któ­rzy pra­cow­ni­cy zaś zama­zy­wa­li cza­sa­mi część danych prze­ka­zu­jąc doku­ment dalej, by ich nie ujaw­niać). Ale naj­więk­szym pro­ble­mem było to, że ta oso­ba uczy­ni­ła z tego wzo­ru doku­men­tu wyma­ga­nie wobec opro­gra­mo­wa­nia ERP. Jak się nie trud­no domy­śleć, żaden ryn­ko­wy sys­tem nie ma takie­go doku­men­tu stan­dar­do­wo, dostaw­ca ERP uznał to wyma­ga­nie bez zastrze­żeń, co przy­czy­ni­ło się do wie­lu mody­fi­ka­cji opro­gra­mo­wa­nia tak­że w innych miej­scach, znacz­ne­go wzro­stu budże­tu (współ­dzie­lo­na baza danych pro­pa­gu­je zmia­ny prak­tycz­nie na całą apli­ka­cję). Nie będę tu opi­sy­wał dal­szych losów tego wzo­ru doku­men­tu bo celem moim było jedy­nie poka­za­nie pro­ble­mu na real­nym przykładzie.

Każdy pro­jekt, czy to wdro­że­nie nowych zasad zarzą­dza­nia czy nowe­go opro­gra­mo­wa­nia, zwią­za­ny z zarzą­dza­niem orga­ni­za­cją, to (powi­nien być) tak­że co naj­mniej prze­gląd doku­men­tów i ich obie­gu. Kluczowym ele­men­tem tego prze­glą­du powin­na być ana­li­za tre­ści tych doku­men­tów, ich opty­mal­ność, nie tyl­ko obie­gu ale tak­że tre­ści i jej struk­tu­ry. Owszem, wie­le doku­men­tów ma narzu­co­ną struk­tu­rę np. w odpo­wied­niej usta­wie, jed­nak są to mini­mal­ne zawar­to­ści (np. fak­tu­ra) nie ma zaka­zu uzu­peł­nie­nia tej struk­tu­ry i np. doda­nia do fak­tu­ry nume­ru zamó­wie­nia, z któ­rym jest związana.

Ogólnie moż­na okre­ślić pew­ne pra­wi­dło­wo­ści: jeże­li doku­men­ty są prze­cią­ża­ne tre­ścią, czy­li idzie­my w kie­run­ku małej ilo­ści doku­men­tów zawie­ra­ją­cych dużo danych, rośnie zło­żo­ność reguł pra­cy z takim doku­men­tem. Jeżeli zaś idzie­my w kie­run­ku doku­men­tów bar­dzo pro­stych”, rośnie ilość ich typów i rośnie licz­ba reguł koja­rzą­cych te doku­men­ty ze sobą w celu ich uży­cia. Ogólnie obra­zu­je to poniż­szy diagram:

Liczba dokumentów vs ilośc treści na nich

Tak więc skraj­nym roz­wią­za­niem będzie stwo­rze­nie jed­ne­go doku­men­tu, na któ­rym będą wszyst­kie infor­ma­cje np. zwią­za­ne z danym zamó­wie­niem. Drugą skraj­no­ścią jest podzie­le­nie infor­ma­cji na odręb­ne małe nie­po­dziel­ne już grup­ki, jak to ma miej­sce w znor­ma­li­zo­wa­nych rela­cyj­nych bazach danych. Jeżeli mega­do­ku­men­ty to raczej bar­dzo rzad­kie zja­wi­sko, to przy­pa­dek dru­gi jest dość powszech­ny. To co nazy­wa­my czę­sto doku­men­tem to tu tak na praw­dę nie­ist­nie­ją­cy byt w rela­cyj­nej bazie danych, gene­ro­wa­ny ad-hoc w locie” z sze­re­gu roz­drob­nio­nych tablic danych. Innymi sło­wy nie są to sta­łe struk­tu­ry” a pew­na okre­ślo­na zło­żo­na logi­ka, two­rzą­ca z pro­stych danych pobie­ra­nych z tablic, kon­kret­ne zesta­wy infor­ma­cji np. fak­tu­ry (to dla­te­go czę­sto w języ­ku dostaw­cy” fak­tu­ra to raport a nie doku­ment!). Ta zło­żo­na logi­ka reali­zo­wa­na jest (wyko­ny­wa­na w pamię­ci kom­pu­te­ra) za każ­dym razem gdy odwo­ła­my się do takie­go dokumentu.

Optymalna sytu­acja to rodzaj kom­pro­mi­su pomię­dzy zło­żo­no­ścią logi­ki two­rze­nia i korzy­sta­nia z doku­men­tu a jego zawar­to­ścią. Na powyż­szym dia­gra­mie jest to obszar sta­no­wią­cy oko­li­ce mini­mum krzy­wej opi­su­ją­cej zależ­ność pomię­dzy licz­bą doku­men­tów a zło­żo­no­ścią ope­ro­wa­nia nimi. Nie ma pro­stej regu­ły na opra­co­wy­wa­nie i opty­ma­li­za­cje tre­ści i licz­by doku­men­tów jed­nak są pew­ne spraw­dzo­ne dobre prak­ty­ki, a mia­no­wi­cie jeden doku­ment, o okre­ślo­nej struk­tu­rze, powi­nien zawie­rać dane o okre­ślo­nym zda­rze­niu w okre­ślo­nym kon­tek­ście [powsta­je teraz publi­ka­cja na ten temat, wyda­je się moż­na to jed­nak zde­fi­nio­wać, przyp auto­ra 2019]. Dokumenty te, podob­nie jak fak­ty któ­re doku­men­tu­ją, mogą mieć każ­dy wła­sny i róż­ny od innych cykl życia, dla­te­go czę­sto bywa bar­dzo szko­dli­we roz­dzie­la­nie” ich na pola bazy danych i pozby­cie się redundancji.

Przykładem mogą być: zamó­wie­nie jako udo­ku­men­to­wa­nie fak­tu zawar­cia umo­wy na dosta­wę, fak­tu­ra jako udo­ku­men­to­wa­nie fak­tu sprze­da­ży (prze­nie­sie­nia wła­sno­ści) oraz doku­ment WZ doku­men­tu­ją­cy fakt wyda­nia z maga­zy­nu okre­ślo­nych pro­duk­tów. Bardzo czę­sto spe­cy­fi­ka­cja tego co wyda­no z maga­zy­nu nie jest toż­sa­ma z tre­ścią fak­tu­ry (sprze­da­no odku­rzacz a wyda­no odku­rzacz i zapa­so­we wor­ki), na zamó­wie­niu mógł być wyszcze­gól­nio­ny odku­rzacz, wor­ki oraz wyma­ga­ne koń­ców­ki (któ­re są np. u pro­du­cen­ta pako­wa­ne w stan­dar­dzie więc nie ma ich ani na fak­tu­rze ani na WZ). Dlatego ma głę­bo­ki sens by te doku­men­ty były jed­nak osob­ny­mi doku­men­ta­mi” a nie zacho­wy­wa­ny­mi w bazie danych dany­mi jako odręb­ne pola pozba­wio­ne redun­dan­cji, wyma­ga­ją­ce skom­pli­ko­wa­nej logi­ki (pole­ce­nia SQL) by je (te doku­men­ty”) poka­zać na ekra­nie czy wydrukować.

To dość try­wial­ny przy­kład, bo opi­sa­ne doku­men­ty są wyma­ga­ne prze­pi­sa­mi jako dowo­dy księ­go­we, jed­nak każ­da więk­sza orga­ni­za­cja ma swo­je wewnętrz­ne doku­men­ty, na któ­rych ilość i treść ma peł­ny wpływ. Po dru­gie nawet te doku­men­ty są czę­sto wła­śnie zapi­sy­wa­ne w rela­cyj­nych bazach danych jako roz­pro­szo­ne po małych tabe­lach dane, wyma­ga­ją­ce skom­pli­ko­wa­nych ope­ra­cji łącze­nia w jeden doku­ment”, każ­do­ra­zo­wo przy pró­bie jego uży­cia. Tu zacho­dzi bar­dzo duże ryzy­ko, że postać i treść takie­go doku­men­tu ule­gnie zmia­nie np. po reor­ga­ni­za­cji bazy danych. Takich doku­men­tów” nie da się (w tej posta­ci) pod­pi­sać elek­tro­nicz­nie, bo one po pro­tu fizycz­nie na praw­dę nie istnieją.

A jak ina­czej? Nie ma żad­ne­go pro­ble­mu by dowol­ny doku­ment sta­no­wił sobą jed­no­li­ty byt np. zestaw danych w for­ma­cie XML, sko­ja­rzo­ny ewen­tu­al­nie ze swo­ją posta­cią goto­wą do dru­ku albo np. plik PDF sko­ja­rzo­ny z meta­da­ny­mi opi­su­ją­cy­mi go (wybór jest na praw­dę duży). Nie nale­ży zapo­mi­nać, że poza doku­men­ta­mi, któ­re są two­rzo­ne w orga­ni­za­cji ope­ru­je­my doku­men­ta­mi obcy­mi, otrzy­ma­ny­mi z zewnątrz i wypa­da­ło by mieć taki doku­ment w posta­ci takiej jaką prze­słał nam ich twór­ca. Owszem poja­wia się redun­dan­cja danych ale ona nie sta­no­wi sobą nic złe­go. Ogromną korzy­ścią takie­go podej­ścia jest roz­wią­za­nie pro­ble­mu pole­ga­ją­ce­go na nie­moż­no­ści roz­dzie­le­nia doku­men­tów” i logi­ki ope­ro­wa­nia nimi jeże­li są zapi­sa­ne w posta­ci odręb­nych pól w rela­cyj­nej bazie danych. Np. sta­je się nie­moż­li­we pozo­sta­wie­nie fak­tur i wynie­sie­nie doku­men­tów maga­zy­no­wych do odręb­ne­go sys­te­mu (w tym zmia­na ich struk­tu­ry) co ma miej­sce nie raz przy wdra­ża­niu sys­te­mów WMS (sys­te­my logi­stycz­no-maga­zy­no­we). Takie ope­ra­cji pra­wie żaden duży zin­te­gro­wa­ny ERP nie wytrzy­ma (usły­szy­my raczej, że my dosto­su­je­my do Państwa potrzeb nas moduł magazynowy…).

Podejście takie ma tak­że inna cie­ka­wą zale­tę: jeże­li udo­ku­men­tu­je­my osob­no struk­tu­ry doku­men­tów i logi­kę ope­ro­wa­nia nimi (tak­że ich two­rze­nia), to otrzy­ma­my obiek­to­wy model orga­ni­za­cji: model poka­zu­ją­cy wza­jem­ną współ­pra­cę obiek­tów biz­ne­so­wych (doku­men­tów) odpo­wie­dzial­nych za prze­cho­wy­wa­nie infor­ma­cji, obiek­tów odpo­wie­dzial­nych za reje­stro­wa­nie tych infor­ma­cji, obiek­tów mają­cych wie­dzę jak ope­ro­wać tymi infor­ma­cja­mi, obiek­tów udo­stęp­nia­ją­cych to wszyst­ko zgod­nie z okre­ślo­ną logi­ką. Poniżej obiek­to­wy model na któ­rym od pra­wej mamy: doku­men­ty z ich tre­ścią oraz logi­kę ich two­rze­nia i udo­stęp­nia­nia (repo­zy­to­ria czy­li kuwet­ki na doku­men­ty), logi­kę korzy­sta­nia z infor­ma­cji w repo­zy­to­riach, tak­że ich wza­jem­ne­go koja­rze­nia (samo­dziel­ne usłu­gi) oraz logi­kę dostę­pu do tego sys­te­mu (reali­za­cja sce­na­riu­szy przy­pad­ków uży­cia). Jeżeli w toku ana­li­zy uzna­my, że jakieś ele­men­ty tej logi­ki to zada­nia pod­da­ją­ce się w 100% algo­ryt­mi­za­cji, to poniż­szy model jest jed­no­cze­śnie mode­lem logi­ki apli­ka­cji i nazy­wa­my go Modelem Dziedziny Systemu. Nie jest to abso­lut­nie żad­na baza danych, poniż­sze repo­zy­to­ria nicze­go nie współ­dzie­lą (moż­na je w dowol­nym momen­cie zamie­niać na inne bez kon­se­kwen­cji dla resz­ty systemu).

Obiektowy model dziedziny Zasada SOLID

Model ten powstał z uży­ciem blo­ków funk­cjo­nal­nych wzor­ca BCE (opi­sa­łem go tu: Wzorzec ana­li­tycz­ny Boundary Control Entity). Dla wyja­śnie­nia: powyż­szy dia­gram to w peł­ni popraw­ny Model dzie­dzi­ny wyko­na­ny z uży­ciem dia­gra­mu klas UML, kla­sy mają ste­reo­ty­py boun­da­ry, con­trol i enti­ty (powy­żej od lewej do pra­wej), ste­reo­ty­py te są repre­zen­to­wa­ne sym­bo­la­mi opi­sa­ny­mi (iko­na­mi) w BCE. (Źródło: Krzywe i kosz­ty? archi­tek­tu­ry | | Jarosław Żeliński IT-Consulting

Prawie zawsze obser­wu­ję, że pod­sta­wo­wym domyśl­nym zało­że­niem wdro­żeń sys­te­mów wspo­ma­ga­ją­cych zarzą­dza­nie, jest uzna­nie a prio­ri nie­zmien­no­ści struk­tu­ry i wzo­rów dokumentów. 

Z doświad­cze­nia mogę powie­dzieć, że ana­li­za i opty­ma­li­za­cja tre­ści doku­men­tów wewnętrz­nych może przy­nieść bar­dzo duże korzy­ści prze­kła­da­ją­ce się na duży wzrost wewnętrz­nej efek­tyw­no­ści i jako­ści pra­cy, a w przy­pad­ku wdro­żeń opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go zarzą­dza­nie, pozwa­la nie raz cał­ko­wi­cie unik­nąć bar­dzo kosz­tow­nych i ryzy­kow­nych kasto­mi­za­cji. Zaryzykuje tezę, że kil­ka pro­jek­tów w ten spo­sób wręcz uratowałem… 

Architekt danych ? czy na pewno zawód przyszłości?

Rola archi­tek­tu­ry danych zna­la­zła tak­że odzwier­cie­dle­nie w zarob­kach archi­tek­tów danych. Diagram 3 przed­sta­wia śred­nie zarob­ki rocz­ne archi­tek­tów róż­nych spe­cjal­no­ści w tysią­cach USD (dla porów­na­nia doda­no tak­że inne spe­cjal­no­ści z obsza­ru IT). Widać wyraź­nie, że archi­tek­ci danych są wśród naj­wy­żej opła­ca­nych spe­cja­li­stów. (źr. Architekt danych ? zawód przyszłości?).

ja obser­wu­je coś obok”, otóż dane są wtór­ne w sto­sun­ku do fak­tów, obec­ne sys­te­my raczej odcho­dzą od jed­no­li­tych współ­dzie­lo­nych baz danych”, i nie dla­te­go, że RDBMS są nie­mod­ne”, a dla­te­go, że same dane pozba­wio­ne kon­tek­stu, są mało war­to­ścio­we (do tego nor­ma­li­za­cja mode­li danych to pro­ces strat­ny), w moich oczach ma war­tość np. fak­tu­ra jako zapis fak­tu do jakiej trans­ak­cji doszło, zaś roz­dzie­le­nie danych z fak­tu­ry na kil­ka tabel, czy­ni każ­dą z nich z osob­na mało war­to­ścio­wą albo i bez­war­to­ścio­wą… To, że archi­tek­tu­ra danych ma dziś naj­niż­szy słu­pek nie koniecz­nie zna­czy, że ktoś to będzie nad­ra­biał (słyn­ne dywa­ga­cje o tym, czy cho­dzą­cy boso miesz­kań­cy Afryki wró­żą mega rynek na obu­wie), war­to pamię­tać o tym, że inte­gra­cja pomię­dzy sys­te­ma­mi coraz czę­ściej odby­wa się na pozio­mie logi­ki biz­ne­so­wej, poprzez wymia­nę obiek­tów opi­su­ją­cych zda­rze­nia i byty rze­czy­wi­ste, a nie poprzez współ­dzie­le­nie (baz) danych, cze­go się zresz­tą nie da robić w sie­ciach roz­pro­szo­nych takich jak chmu­ry… Osobiście wró­żę karie­rę ana­li­ty­kom, potra­fią­cym cało­ścio­wo (holi­stycz­nie ;)) patrzeć na orga­ni­za­cje, rośnie zło­żo­ność orga­ni­za­cji, co w toku ana­liz i mode­lo­wa­nia, zmu­sza do abs­tra­ho­wa­nia od pew­nych szcze­gó­łów, tu wra­ca do łask ana­li­za sys­te­mo­wa … (nie mylić z ana­li­za sys­te­mów IT). Pamiętajmy, że:

(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994 by Steve Cook (Author), John Daniels (Author))
Cook, S., & Daniels, J. (1994). Designing object sys­tems: object-orien­ted model­ling with Syntropy. New York: Prentice Hall. 

[2021 – 09-07]

No cóż, mamy już BigData, bazy NoSQL, i ogrom­ne roz­pro­sze­nie danych. pro­gno­zy zda­ją sie potwier­dzać: co opi­sa­łem w arty­ku­le Bazy NoSQL jako imple­men­ta­cje wzor­ców struk­tur infor­ma­cji.

Konferencja DATA CENTER & STORAGE GigaCon ? Systemy baz danych oraz pamięci masowe dla przedsiębiorstw

Opis wydarzenia

Zapraszamy Państwa ser­decz­nie do udzia­łu w bez­płat­nej kon­fe­ren­cji poświę­co­nej tech­no­lo­giom, śro­do­wi­skom i narzę­dziom gwa­ran­tu­ją­cym nie­za­wod­ny i bez­piecz­ny dostęp do baz danych oraz zagad­nie­niom teo­re­tycz­nym i prak­tycz­nym zwią­za­nym z archi­tek­tu­rą i funk­cją pamię­ci masowych.

Proponowane sesje tematyczne:

- Usługi DataCenters
– Serwery baz danych dla DataCenter
– Systemy ope­ra­cyj­ne dla DataCenters
– Zarządzanie DataCenters
– Integracja baz danych, trans­fer danych
– Wydajne ser­we­ry i kla­stry dla DataCenters
– Bezpieczeństwo DataCenters
– Hurtownie danych
– Datamining
– Wirtualizacja serwerów
– Zalety i zasto­so­wa­nie archi­tek­tur sto­ra­ge: SAN i NAS
– Macierze dys­ko­we, stre­ame­ry, biblio­te­ki taśmo­we, autoloadery
– Składowanie, repli­ka­cja i inte­gral­ność sys­te­mów storage?owych
– Rozwiązania klastrowe
– Analiza potrzeb storage
– Ciągłość pro­wa­dze­nia biz­ne­su. disa­ster recovery
– Mobilne sys­te­my storage?owe
– Bezpieczeństwo, wydaj­ność, ska­lo­wal­ność i odpor­ność na kata­stro­fy sys­te­mów storage?owych
– Zarządzanie sprzę­tem i opro­gra­mo­wa­niem storage
– Backup i archi­wi­za­cja danych
– Nowe tren­dy na ryn­ku pamię­ci masowych

Konferencja skie­ro­wa­na jest do sze­ro­kie­go krę­gu odbior­ców wyko­rzy­stu­ją­cych lub zamie­rza­ją­cych wdra­żać oma­wia­ne tech­no­lo­gie i narzę­dzia. Osoby, któ­re zapra­sza­my do udzia­łu to oso­by z bran­ży infor­ma­tycz­nej, ban­ko­wej i finan­so­wej, prze­my­słu, tele­ko­mu­ni­ka­cji, ubez­pie­czeń, han­dlu oraz administracji.

Dodatkowe infor­ma­cje na stronie 

agen­da: