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

Model pojęciowy, model danych, model dziedziny systemu

Niemalże każ­de spo­tka­nie pro­jek­to­we, na któ­rym oma­wia­ne są mode­le UML, na każ­dym szko­le­niu na temat UML, poja­wia się pro­blem o któ­rym pisze Ron Ross (wytłusz­cze­nia moje):

Another impli­ca­tion is that con­cept models and logi­cal data models are cle­ar­ly distinct. Unfortunately, many people blur the line betwe­en them. That?s wrong. A con­cept model is abo­ut the meaning of the words you use, and the busi­ness sta­te­ments you make assu­ming tho­se meanings. It?s abo­ut com­mu­ni­ca­tion. A logi­cal data model is abo­ut how you orga­ni­ze what you think you know abo­ut the world so it can be recor­ded and logi­cal­ly mani­pu­la­ted in a sys­te­ma­tic way.I star­ted my care­er in data. It took me as much as 15 years of inten­se work on busi­ness rule sta­te­ments (1990 – 2005) to ful­ly appre­cia­te the dif­fe­ren­ce. But now I am very cle­ar that con­cept models do need to be deve­lo­ped to excru­cia­ting level of deta­il in order to disam­bi­gu­ate the inten­ded busi­ness communication.Most busi­nesses don?t do that today. They jump in at data design (con­cep­tu­al, logi­cal or even phy­si­cal). And they unk­no­win­gly pay a big pri­ce for it. (Źródło: Concept Model vs. Data Model ? Ron Ross on Business Rules)

Generalnie model poję­cio­wy, model danych to skraj­nie róż­ne mode­le. Jeżeli do tego doda­my dys­ku­sje na temat obiek­to­we­go mode­lu dzie­dzi­ny, to na spo­tka­niu mamy nie­mal­że gwa­ran­cje ostre­go sporu.

Widzę dwa głów­ne źró­dła tych pro­ble­mów. Pierwsze to fakt, że w szko­łach wyż­szych nadal kró­lu­je ana­li­za struk­tu­ral­na, a po maco­sze­mu trak­to­wa­na ana­li­za sys­te­mo­wa i obiek­to­wa (obie bazu­ją na kon­cep­cji współ­pra­cu­ją­cych obiek­tów i ope­ru­ją poję­ciem obiekt zaś ter­min” to poję­cie słow­ni­ko­we). Teoria sys­te­mów i opar­ty na niej para­dyg­mat obiek­to­wy są nie­ste­ty trud­ne, bazu­ją w 100% na her­me­ty­za­cji i abs­tra­ho­wa­niu od szcze­gó­łów, a ode­rwa­nie się od szcze­gó­łów więk­szo­ści ludziom przy­cho­dzi z ogrom­nym tru­dem albo nie uda­je się w ogó­le. Drugie to powszech­ne myle­nie kon­tek­stów słów ter­min” (poję­cie) i kon­cep­cja” (pomysł, idea) w lite­ra­tu­rze anglojęzycznej:

con­cept {rzecz.} (też: notion, idea, con­cep­tion, term) poję­cie {n.} Same con­cept, but looking at com­mu­ni­ca­tion dyna­mics in a very dif­fe­rent sphe­re. To samo poję­cie, ale patrząc na dyna­mi­kę komu­ni­ka­cji w zupeł­nie odmien­nej sferze.

con­cept {rzecz.} (też: con­cep­tion, idea) kon­cep­cja {f.} However, we ought to be awa­re that the con­cept of vic­ti­mi­sa­tion requ­ires strong pro­of. Musimy jed­nak być świa­do­mi, że kon­cep­cja repre­sjo­no­wa­nia wyma­ga moc­nych dowodów.

term {rzecz.} (też: notion, idea, con­cep­tion, con­cept) poję­cie {n.} Really cool term: neo­te­ny – the reten­tion of play and juve­ni­le tra­its in adults. Świetne poję­cie – neo­te­nia, zacho­wa­nie u doro­słych mło­dzień­czych cech i chę­ci do zabawy.

(źr. http://​pl​.bab​.la/​s​l​o​w​n​i​k​/​a​n​g​i​e​l​s​k​i​-​p​o​l​s​k​i​/​c​o​n​c​ept)

Do tego docho­dzą nota­cje i cza­sa­mi wręcz nie zro­zu­mie­nie ich seman­ty­ki i zasto­so­wa­nia. W oma­wia­nym obsza­rze od lat są sto­so­wa­ne dwie, od nie­daw­na trzy notacje:

  1. dia­gram związ­ków encji (naj­po­pu­lar­niej­sze nota­cje to Crow?s Feet” czy­li kurze stop­ki 🙂 i jej wer­sja zwa­na, nota­cją bar­ke­ra (Barker’s nota­tion, ERD, ang. Entity Relationship Diagram)
  2. dia­gram klas nota­cji UML (ang. Unified Modeling Language)
  3. dia­gram fak­tów (ang. SBVR, Semantics Of Business Vocabulary And Rules)

Pierwszy słu­ży do two­rze­nia mode­li w para­dyg­ma­cie rela­cyj­nym na trzech pozio­mach ogól­no­ści, wszyst­kie trzy są mode­la­mi danych (a nie pojęć):

  1. Conceptual data model
  2. Logical data model
  3. Physical data model

Diagram klas w nota­cji UML słu­ży do two­rze­nia modeli:

  1. poję­cio­wych (wszyst­kie dia­gra­my klas w spe­cy­fi­ka­cjach OMG to mode­le poję­cio­we opi­su­ją­ce seman­ty­ką i syn­tak­ty­kę danej notacji),
  2. mode­li obiek­to­wych (dia­gram obiek­tów) i ich meta­mo­de­li (dia­gram klas), są to tak zwa­ne mode­le dzie­dzi­ny sys­te­mu (logi­ka, mecha­nizm dzia­ła­nia apli­ka­cji, przed­się­bior­stwa, każ­de­go sys­te­mu w rozu­mie­niu teo­rii systemów),
  3. mode­li struk­tu­ry kodu apli­ka­cji (dia­gram klas).

Od nie­daw­na mamy nota­cje SBVR a w niej dia­gram Fact dia­gram”. Jest to dia­gram (nie jest to dia­gram klas UML, ale dia­gra­mu klas UML moż­na użyć by go zastą­pić) repre­zen­tu­ją­cy w for­mie gra­ficz­nej słow­nik pojęć i jest to spe­cy­ficz­ny model poję­cio­wy, opar­ty na tak zwa­nych związ­kach opar­tych na fak­tach (aso­cja­cje repre­zen­tu­ją tu fak­ty, któ­re kon­tek­sto­wo koja­rzą dane dwa poję­cia np. doku­ment opi­su­je zda­rze­nie, pod­kre­śle­nia wska­zu­ją na poję­cia ze słow­ni­ka (są w nim zde­fi­nio­wa­ne) o sło­wo pisa­ne kur­sy­wą to fakt, któ­ry je kon­tek­sto­wo koja­rzy (mode­le fak­tów to nie są ontologie).

Modele danych (np. dia­gra­my ERD) to struk­tu­ry poka­zu­ją­ce orga­ni­za­cję danych (infor­ma­cji). Mogą być na dużym pozio­mie abs­trak­cji w posta­ci wstęp­ne­go pomy­słu”, mogą być wypra­co­wa­nym mode­lem i mogą być mniej lub bar­dziej kom­pro­mi­so­wym pla­nem implementacji.

Obiektowy para­dyg­mat oraz ogól­na teo­ria sys­te­mów zakła­da­ją, że wszyst­ko to co obser­wu­je­my to pew­na więk­sza lub mniej­sza zło­żo­ność opi­sa­na jako skoń­czo­na licz­ba współ­pra­cu­ją­cych ele­men­tów (lub ich klas). Każdy ele­ment ma okre­ślo­ne cechy, każ­dy w okre­ślo­ny spo­sób reagu­je na bodź­ce z oto­cze­nia. Całkowitą zło­żo­ność wyzna­cza licz­ba tych ele­men­tów i pro­sto­ta lub jej brak, reak­cji na bodź­ce. Doskonale tłu­ma­czy to meta­fo­ra K.Poppera o zega­rach i chmurach:

Generalnie pro­blem zło­żo­no­ści ład­nie opi­sał Karl Popper, w swo­im dzie­le Wiedza Obiektywna meta­fo­rą ?o chmu­rach i zega­rach?. To co obser­wu­je­my, sys­tem, może być tak zło­żo­ne, że ilość obiek­tów i ich wza­jem­nych oddzia­ły­wań będzie zbyt duża, by moż­li­we było stwo­rze­nie mode­lu (teo­ria wyja­śnia­ją­ca zacho­wa­nie) takie­go sys­te­mu, pozwa­la­ją­ce­go na prze­wi­dy­wa­nie zacho­wa­nia takiej zło­żo­no­ści. Są jed­nak sys­te­my, któ­rych natu­ra na to pozwa­la, ich model jest moż­li­wy do stwo­rze­nia, takie sys­te­my są prze­wi­dy­wal­ne w 100%. Metaforą sys­te­mu nie­prze­wi­dy­wal­ne­go jest chmu­ra, a prze­wi­dy­wal­ne­go zegar. Oczywiście jest nie­skoń­cze­nie wie­le sys­te­mów o natu­rze gdzieś pomię­dzy chmu­ra­mi i zega­ra­mi. (Źródło: Wszystkie dro­gi pro­wa­dzą do Rzymu | | Jarosław Żeliński IT-Consulting)

Elementy sys­te­mu mają swo­je cechy (ukry­te: her­me­ty­za­cja) a uze­wnętrz­nia­ją wyłącz­nie reak­cje na bodź­ce (żąda­nia). W efek­cie sys­tem żyje” ale nie jest bazą danych”. UML i dia­gram klas, w tym wypad­ku, mode­lu­je współ­pra­cu­ją­ce obiek­ty a nie bazę danych”. To, że taka baza (każ­da for­ma utrwa­la­nia danych) fizycz­nie ist­nie­je (jest two­rzo­na) to wyłącz­nie sku­tek potrze­by jaką jest zapa­mię­ta­nie sta­nu sys­te­mu (apli­ka­cji).

Niewątpliwie jed­nak dia­gram klas UML nie jest mode­lem danych, i nie słu­ży do mode­lo­wa­nia danych… 

Model kom­po­nen­tu sys­te­mu, opi­su­ją­cy mecha­nizm jego dzia­ła­nia (logi­kę) to tak zwa­ny model dzie­dzi­ny” czy­li obiek­to­wy model sys­te­mu opi­su­ją­cy (mode­lu­ją­cy) mecha­nizm jego dzia­ła­nia. Owszem, apli­ka­cja może słu­żyć do zarzą­dza­nia duży­mi i zor­ga­ni­zo­wa­ny­mi zbio­ra­mi danych ale to to samo co zespół ludzi – sys­tem współ­pra­cu­ją­cych obiek­tów mają­cych – każ­dy – wie­le cech – zarzą­dza­ją­cy biblio­te­ką: Ci ludzie i ich cechy to nie baza danych” a ukry­te do ich wia­do­mo­ści cechy i umie­jęt­no­ści, dostęp­ne dla innych wyłącz­nie pod warun­kiem zada­nia pyta­nia i woli odpo­wie­dzi na nie, ci ludzie mogą zarzą­dzać” jakimś zbio­rem danych. 

Dlatego ubo­le­wam, gdy oso­by będą­ce nauczy­cie­la­mi aka­de­mic­ki­mi, tre­ne­ra­mi pro­wa­dzą­cy­mi szko­le­nia czy auto­ra­mi wie­lu uczo­nych” blo­gów, publi­ku­ją pomy­sły o mode­lo­wa­niu danych z uży­ciem UML… co nie ma nic wspól­ne­go z UML.

O SBVR, mode­lach poję­cio­wych i dia­gra­mie fak­tów pisa­łem w arty­ku­le SBVR czy­li regu­ły biz­ne­so­we i słow­nik. Kwestie dia­gra­mów klas opi­sa­łem mię­dzy inny­mi w arty­ku­le Cholerny dia­gram klas i w Czym jest a czym nie jest model dzie­dzi­ny. Jeśli zaś cho­dzi o to czym nie jest dia­gram ERD pisa­łem przy oka­zji Wiedza po stu­diach? Zostaliście oszukani?

Czym jest a czym nie jest tak zwany model dziedziny systemu

UML 2.4.1. Superstructure - the taxonomy od structure and behavior diagram
Taksonomia dia­gra­mów UML

Ten arty­kuł to kon­ty­nu­acja wąt­ku roz­po­czę­te­go wpi­sem o mode­lu dzie­dzi­ny i dia­gra­mie klas, jed­nak inna jest inten­cja. Wśród wie­lu listów i pytań od stu­den­tów i pra­cu­ją­cych już ana­li­ty­ków, na temat UML, regu­lar­nie poja­wia się pyta­nie o dia­gram klas i mode­lo­wa­nie tak zwa­nej dzie­dzi­ny sys­te­mu. Gdy odpo­wia­dam czę­sto poja­wia się zarzut, a tam napi­sa­no, że…”.

Ten arty­kuł to mię­dzy inny­mi chęć zwró­ce­nia uwa­gi na to, że w sie­ci i wie­lu książ­kach nie­ste­ty mamy nie mało tak zwa­nej pseu­do­wie­dzy… Z zasa­dy nie oce­niam tre­ści innych stron, jed­nak trud­no zigno­ro­wać coś, co ktoś poda­je jako przy­kład w roz­mo­wie ze mną. Cytat, któ­ry przy­to­czy­łem w dal­szej czę­ści (jaw­nie poda­ne źró­dło), pocho­dzi z cyklu arty­ku­łów jakie uka­za­ły się w piśmie Software Developer Journal, umiesz­czo­ne­go na publicz­nej stro­nie WWW ich auto­ra, tre­ne­ra pro­wa­dzą­ce­go szko­le­nia z UML.

Artykuł ten dedy­ku­ję mię­dzy inny­mi każ­de­mu kto podej­mu­je decy­zję o szko­le­niu, w jakiej fir­mie i u jakie­go trenera.

Na pyta­nia o to, czym jest a czym nie jest tak zwa­ny model dzie­dzi­ny sys­te­mu” moż­na odpo­wie­dzieć pod warun­kiem wcze­śniej­sze­go zde­fi­nio­wa­nia poję­cia dzie­dzi­na sys­te­mu”. Bez tej defi­ni­cji wszel­kie dywa­ga­cje o mode­lo­wa­niu dzie­dzi­ny sys­te­mu” są nie­ste­ty bez­przed­mio­to­we (i bez sensu).

Pewien foru­mo­wicz, po lek­tu­rze kil­ku zna­le­zio­nych stron WWW zapytał:

Czy może­cie mi wytłu­ma­czyć co ozna­cza­ją poję­cia model dzie­dzi­ny” oraz model kon­cep­tu­al­ny”? Czy model dzie­dzi­ny zawie­ra tak­że dia­gram kon­cep­tu­al­ny klas?

Cóż, pro­blem defi­ni­cji pojęć. Uporządkujmy to co nie­co. Wpisanie hasła dzie­dzi­na sys­te­mu” do Google daje nie­ste­ty tak róż­ne infor­ma­cje, nie raz sprzecz­ne, że wyłu­ska­nie z tego praw­dy” dla począt­ku­ją­ce­go jest nie­mal­że nie­moż­li­we (nie­ste­ty tu uwi­dacz­nia się wada Internetu jako źró­dła wie­dzy”). Zróbmy to więc jak nale­ży ;), celo­wo uży­wam WIKI, bo to popu­lar­ne dar­mo­we źró­dło wie­dzy, ale zazna­czam, że cytu­je to co znam i wiem, że ma potwier­dze­nie w tra­dy­cyj­nej lite­ra­tu­rze naukowej.

Definicja poję­cia system:

System (stgr. ??????? sys­te­ma ? rzecz zło­żo­na) ? obiekt fizycz­ny lub abs­trak­cyj­ny, w któ­rym moż­na wyod­ręb­nić zespół lub zespo­ły ele­men­tów wza­jem­nie powią­za­nych w ukła­dy, reali­zu­ją­cych jako całość funk­cję nad­rzęd­ną lub zbiór takich funk­cji (funk­cjo­nal­ność) (System ? Wikipedia, wol­na ency­klo­pe­dia).

Myślę, że tej defi­ni­cji nie trze­ba komen­to­wać. Kilka słów o poję­ciu dzie­dzi­na”. To bar­dzo nie­for­tun­ne tłu­ma­cze­nie sło­wa doma­in, bo model dzie­dzi­ny to w ory­gi­na­le doma­in model. Tu cho­dzi o dome­nę a nie dzie­dzi­nę (te sło­wa w j.polskim mają jed­nak nie­co inne znaczenie).

Domena (domi­nium) ? kate­go­ria sys­te­ma­tycz­na wyż­sza od kró­le­stwa, sto­so­wa­na w kla­sy­fi­ka­cji bio­lo­gicz­nej (Domena (bio­lo­gia) ? Wikipedia, wol­na ency­klo­pe­dia).

Domena to poję­cie mają­ce rodo­wód w bio­lo­gii, podob­nie zresz­tą jak teo­ria sys­te­mów” 🙂 i odno­si się do sys­te­ma­ty­zo­wa­nia cze­goś (kla­sy­fi­ko­wa­nia, stąd tak­że poję­cie klasa).

Pojęcie dzie­dzi­ny: dzie­dzi­na rela­cji, log. zbiór wszyst­kich przed­mio­tów pozo­sta­ją­cych w danej rela­cji do co naj­mniej jed­ne­go przed­mio­tu. (Encyklopedia PWN) ma swo­je odzwier­cie­dle­nie w mode­lu rela­cyj­nym baz danych i ana­li­zie struk­tu­ral­nej. To, co w meto­dach struk­tu­ral­nych bywa nazy­wa­ne mode­lem dzie­dzi­ny, to wła­śnie rela­cje pomię­dzy przed­mio­ta­mi (byta­mi). Jest to tak zwa­ny model poję­cio­wy (ang. con­cep­tu­al model to model poję­cio­wy, tu bazy danych, a nie kon­cep­cyj­ny w rozu­mie­niu pomysł na…”) wyra­ża­ny dia­gra­mem ERD (ang. Entity Relationship Model) i opi­su­ją­cy struk­tu­ry danych.

W para­dyg­ma­cie obiektowym:

Object-orien­ted pro­gram­ming (OOP) is a pro­gram­ming para­digm that repre­sents con­cepts as objects” that have data fields (attri­bu­tes that descri­be the object) and asso­cia­ted pro­ce­du­res known as methods. […] An object-orien­ted pro­gram may be vie­wed as a col­lec­tion of inte­rac­ting objects, as oppo­sed to the conven­tio­nal model, in which a pro­gram is seen as a list of tasks (sub­ro­uti­nes) to per­form. (Object-orien­ted pro­gram­ming – Wikipedia, the free encyc­lo­pe­dia).

W wol­nym tłu­ma­cze­niu: obiek­to­wy para­dyg­mat pro­gra­mo­wa­nia to repre­zen­to­wa­nie pojęć w posta­ci obiek­tów”, mają­cych atry­bu­ty (dane opi­su­ją­ce obiekt) oraz powią­za­ne pro­ce­du­ry, nazy­wa­ne meto­da­mi. Program obiek­to­wy nale­ży postrze­gać jako kolek­cję współ­dzia­ła­ją­cych obiek­tów, w prze­ci­wień­stwie do kon­wen­cjo­nal­ne­go mode­lu pro­gra­mo­wa­nia, gdzie wyłącz­nie” pro­gram to lista pole­ceń (zadań, pod­pro­gra­mów) [przyp. mój] ope­ru­ją­cych na okre­ślo­nym zesta­wie danych (baza danych).

Tak więc w para­dyg­ma­cie obiek­to­wym doma­in model, czy­li model dzie­dzi­ny”, to kolek­cja obiek­tów repre­zen­tu­ją­cych mode­lo­wa­ny pro­blem. Innymi słowy:

obiek­to­wy model dzie­dzi­ny sys­te­mu to zestaw pojęć repre­zen­tu­ją­cych przed­mio­ty z dane­go obsza­ru poję­cio­we­go (np. han­del i sprze­daż, pro­duk­cja kabli, itp.), zawie­ra­ją­cy dla każ­de­go przed­mio­tu opis jego cech i pro­ce­dur jakie może wykonać.

Taka kolek­cja współ­pra­cu­ją­cych obiek­tów, to przede wszyst­kim owe obiek­ty i ich meto­dy (umie­jęt­no­ści). Ich cechy są ukry­te wewnątrz nich, nie są przed­mio­tem współ­dzia­ła­nia, bo współ­dzia­ła­nie pole­ga komu­ni­ko­wa­niu się obiek­tów mię­dzy sobą a nie prze­twa­rza­niu danych, któ­re jako takie nie wystę­pu­ją w tym paradygmacie.

Ale podob­no pro­gram kom­pu­te­ro­wy słu­ży do prze­twa­rza­nia danych! 

Hm… tyl­ko wte­dy, gdy patrzy­my na biz­nes jak na zbie­ra­nie danych. Sprzedaż moż­na postrze­gać jako prze­twa­rza­nie danych o trans­ak­cjach sprze­da­ży”, moż­na jed­nak też postrze­gać ją jako ope­ro­wa­nie na obiek­tach biz­ne­so­wych takich jak: pro­duk­ty, zamó­wie­nia i fak­tu­ry”. Jest to dia­me­tral­na róż­ni­ca. Tu inte­re­su­je nas przede wszyst­kim to, że obiek­ty takie jak Produkt, zmie­ni­ły wła­ści­cie­la, obiekt Zamówienie jest mate­ria­li­za­cją tego cze­go ocze­ku­je zama­wia­ją­cy, zaś Faktura mate­ria­li­za­cją fak­tu doko­na­nia tej sprze­da­ży. Dane takie jak, cena, ilość, poda­tek, to tyl­ko cechy tych obiek­tów, któ­re są nie­zbęd­ne by te trans­ak­cje zosta­ły prze­pro­wa­dzo­ne w spo­sób pra­wi­dło­wy i kon­tro­lo­wa­ny. Proszę zwró­cić uwa­gę na to, że celem kupu­ją­ce­go samo­chód jest ten­że samo­chód słu­żą­cy do swo­bod­ne­go podró­żo­wa­nia, a nie prze­two­rze­nie jego ceny, podat­ku, cię­ża­ru i nume­ru sil­ni­ka”. Użytkownikowi samo­cho­du potrzeb­ne są dwa obiek­ty: Samochód i jego DowódRejestracyjny.

Tyle teo­rii”. Jaki pro­blem miał ów foru­mo­wicz? Ano taki, że np. na stro­nie jed­nej z dość zna­nych firm szko­le­nio­wych, zna­lazł coś takie­go w arty­ku­le o UML i mode­lo­wa­niu obiektowym:

Zwróćmy uwa­gę, że na mode­lu dzie­dzi­ny nie umiesz­cza­my klas imple­men­tu­ją­cych logi­kę apli­ka­cji, jej inter­fejs użyt­kow­ni­ka czy war­stwę dostę­pu do danych. Nie war­to też na mode­lu dzie­dzi­ny umiesz­czać metod. Dzięki temu dia­gram jest pro­sty i powi­nien być zro­zu­mia­ły tak­że dla klien­ta nie mają­ce­go przy­go­to­wa­nia tech­nicz­ne­go i nie zain­te­re­so­wa­ne­go szcze­gó­ła­mi imple­men­ta­cji sys­te­mu. […] Model dzie­dzi­ny jest ele­men­tem ana­li­zy sys­te­mo­wej, uka­zu­ją­cym biz­ne­so­we struk­tu­ry danych i zależ­no­ści pomię­dzy nimi. W dużych pro­jek­tach może on obej­mo­wać kil­ka­set klas. Decydując się na jego stwo­rze­nie, nie pozwa­la­my, aby istot­ne decy­zje mery­to­rycz­ne były podej­mo­wa­ne ad-hoc w trak­cie imple­men­ta­cji. (Diagramy klas – model dzie­dzi­ny i pro­jekt apli­ka­cji).

Cały ten aka­pit, jego oce­nę, pozo­sta­wiam teraz czy­tel­ni­kom (nie­ste­ty ten cykl arty­ku­łów zawie­ra błęd­ne przy­kła­dy mode­li i błęd­ne opi­sy struk­tu­ry obiek­to­we­go kodu pro­gra­mu). To, co celo­wo wytłu­ści­łem to nie­ste­ty fun­da­men­tal­ny błąd w powyż­szym tek­ście: obiek­to­wy model dzie­dzi­ny to abso­lut­nie nie są struk­tu­ry danych i zależ­no­ści mię­dzy nimi.

Forumowicz: Coraz więk­szy mętlik w gło­wie. Wcześniej mia­łem do czy­nie­nia tyl­ko z dia­gra­mem związ­ków encji. Teraz nawet nie bar­dzo widzę róż­ni­cę pomię­dzy nim a dia­gra­mem klas.

No nie­ste­ty, mając za sobą tek­sty jak powyż­szy, nie dzi­wię się. Model w posta­ci dia­gra­mu ERD to wła­śnie owe struk­tu­ry danych i zależ­no­ści pomię­dzy nimi”, ale nie ma to abso­lut­nie nic wspól­ne­go ani z dia­gra­mem klas ani z obiek­to­wym para­dyg­ma­tem. Różnica jest fundamentalna:

- ERD to dia­gram opi­su­ją­cy dane i tyl­ko dane (tu nie wie­my nawet do cze­go one słu­żą bo ta wie­dza jest w funkcjach)

- obiek­to­wy model dzie­dzi­ny to dia­gram klas (UML) obra­zu­ją­cy wyłącz­nie role (obiek­ty mają cel ist­nie­nia, ich atry­bu­ty są ich pry­wat­ną wła­sno­ścią, nie widać ich)

Forumowicz: Piszesz, że dia­gram klas w mode­lu dzie­dzi­ny opi­su­ję logi­kę apli­ka­cji a jak to się ma do defi­ni­cji dia­gra­mu klas któ­ra mówi, że jest to sta­tycz­ny opis struk­tu­ry sys­te­mu. Skoro jest to model sta­tycz­ny to raczej nie poka­zu­je zachowania.

Logika sys­te­mu to nie dyna­mi­ka dzia­ła­nia a zestaw reguł dzia­ła­nia, są one zawar­te w meto­dach klas. Reguły są sta­tycz­ne, dyna­micz­ne są zacho­wa­nia czy­li odpo­wiedź na bodź­ce. Dynamika sys­te­mu to współ­dzia­ła­nie obiek­tów reali­zu­ją­cych jakieś zło­żo­ne zada­nie (to mode­lu­je­my dia­gra­mem sekwen­cji). Model sta­tycz­ny to kolek­cja obiek­tów wraz z opi­sem ich cech i metod jakie reali­zu­ją, czy­li wła­śnie model dzie­dzi­ny sys­te­mu wyra­żo­ny dia­gra­mem klas. Przywołując meta­fo­rę Fowlera, gra w sno­oke­ra to kule i fizy­ka ich ruchu oraz zasa­dy gry. Statyczny model sno­oke­ra moż­li­wy do poka­za­nia jako dia­gram klas to mię­dzy inny­mi kla­sa kula, któ­ra ma ope­ra­cje ude­rze­nie z para­me­tra­mi siła ude­rze­nia i kie­ru­nek oraz atry­bu­ty śred­ni­ca i masa. Czym jest tu dyna­mi­ka? Ona poja­wia się jako opis ude­rze­nia kijem w kulę… Czy model dzie­dzi­ny to jest model sta­tycz­ny struk­tu­ry opro­gra­mo­wa­nia? Tak, bo fun­da­men­tem para­dyg­ma­tu obiek­to­we­go two­rze­nia opro­gra­mo­wa­nia jest to, że pro­gram obiek­to­wy to imple­men­ta­cja (odwzo­ro­wa­nie w kodzie) obiek­to­we­go mode­lu dzie­dzi­ny sys­te­mu. Odpowiedziałem forumowiczowi:

Model sta­tycz­ny to coś jak Ty i Twoi kole­dzy dla otoczenia:

- masz kon­kret­ną rolę (np. murarz), po tym moż­na iden­ty­fi­ko­wać Twoje umie­jęt­no­ści i wie­dzę, wia­do­mo co potra­fisz i jak o to popro­sić (wyko­nu­jesz kon­kret­ne pole­ce­nia opi­sa­ne w Twojej umo­wie o pra­cę – to Twoje metody),

- nikt w pra­cy nie wie ile masz lat, jaki masz nastrój, itp. więc dane” (two­je cechy) nie mają zna­cze­nia (są chro­nio­ne, dostęp­ne są wyłącz­nie w dzia­le HR), zna­cze­nie mają tyl­ko Twoje umie­jęt­no­ści, i to, że jako kon­kret­ny murarz masz imię i nazwi­sko, po któ­rym moż­na Cię iden­ty­fi­ko­wać na budowie.

Gdzie logi­ka biz­ne­so­wa? Ty wiesz jak muro­wać, znasz zasa­dy bez­pie­czeń­stwa, w razie potrze­by dosta­niesz pro­ce­du­rę dzia­ła­nia reali­za­cji np. spe­cy­ficz­nej ścia­ny. Poprawny i kom­plet­ny Model dzie­dzi­ny (doku­men­to­wa­ny dia­gra­mem klas) to kla­sy repre­zen­tu­ją­ce zarów­no mura­rza zawie­ra­ją­ce – meto­dy – pro­ce­du­ry dzia­ła­nia czy­li logi­kę biznesową.

Wyobraź sobie Twoje CV, co jako Ty ofe­ru­jesz? Swoja metry­kę? Nie. To co potra­fisz bo zgod­nie z pra­wem nawet Twoja płeć nie ma zna­cze­nia. Nie zmie­nia to fak­tu, że tecz­ka CV pra­cow­ni­ków fir­my to jej model sta­tycz­ny orga­ni­za­cji… Gdyby dia­gram klas słu­żył do tego co ERD nie było by dia­gra­mu klas…;).

Skąd się bie­rze taka sku­tecz­ność metod obiek­to­wych (o ile są pra­wi­dło­wo sto­so­wa­ne)? Metody struk­tu­ral­ne to roz­kła­da­nie pro­ble­mu biz­ne­so­we­go na oddzie­lo­ne od sie­bie dane i pro­ce­du­ry ich prze­twa­rza­nia. Informacje o obiek­tach rze­czy­wi­stych są tra­co­ne w tych meto­dach. Model rela­cyj­ny danych to model, w któ­rym utra­co­no wie­le infor­ma­cji, np. nie da się z mode­lu rela­cyj­ne­go odtwo­rzyć np. fak­tu­ry nie wie­dząc jak ona wyglą­da. Do wydru­ku fak­tu­ry potrzeb­ne jest zapy­ta­nie, któ­re wycią­gnie z bazy danych wła­ści­we dane i pro­ce­du­ra któ­ra wła­ści­wie je sformatuje.

Metody obiek­to­we pole­ga­ją na mode­lo­wa­nia świa­ta rze­czy­wi­ste­go (dome­ny sys­te­mu), w efek­cie nie tra­ci­my żad­nej wie­dzy mode­lu­jąc (zapi­su­jąc) świat” w posta­ci mode­lu dzie­dzi­ny. Tu war­to zwró­cić uwa­gę, że wie­dzę o tym jak wyglą­da fak­tu­ra jako doku­ment, musi jakiś obiekt posia­dać: to obiekt fak­tu­ra, posia­da­ją­cy np. ope­ra­cję (meto­dę) dru­kuj”. Ale to temat na inny wpis :).

W kwe­stii obiek­to­we­go para­dyg­ma­tu pole­cam na począ­tek, poza stro­ną www​.omg​.org, książ­ki pre­kur­so­rów OOAP: Booch Grady, Rumbaugh James, Jacobson Ivar, oraz Eda Yourdona Analiza Obiektowa.

Potrzeby informacyjne firmy ? Zarządzanie wiedzą

Wprowadzenie

Problematyka infor­ma­cji w fir­mach, jej kolek­cjo­no­wa­nia i prze­twa­rza­nia jest czę­stym tema­tem arty­ku­łów w pra­sie spe­cja­li­stycz­nej jak i opi­sem zakre­sów pro­jek­tów IT. Termin ten jest jed­nak nie raz nad­uży­wa­ny. W pra­sie moż­na pozwo­lić sobie na pew­ną dowol­ność jego inter­pre­ta­cji jed­nak w opi­sie zakre­su pro­jek­tu ana­li­tycz­ne­go pozy­cja o nazwie ?Zdefiniowanie potrzeb infor­ma­cyj­nych fir­my? może rodzić poważ­ne kło­po­ty z odbio­rem tej czę­ści pro­jek­tu gdyż tu na dowol­ność inter­pre­ta­cji nie powin­no być miejsca.

Potrzeby informacyjne firmy

Czym są? Aby okre­ślić potrze­by infor­ma­cyj­ne fir­my musi­my wska­zać (opi­sać) to jaką wie­dzę chce­my posia­dać. To jest naj­trud­niej­sze. Potem, budu­je­my listę fak­tów, któ­rych reje­stra­cja jest wyma­ga­na do zgro­ma­dze­nia potrzeb­nej wie­dzy. Kolejnym kro­kiem jest okre­śle­nie jakie dane są wyma­ga­ne do opi­su tych fak­tów. Następnie budu­je­my model poję­cio­wy i struk­tu­rę danych opi­su­ją­cych te fak­ty. Na koniec imple­men­tu­je­my ten model danych two­rząc Bazę Danych.

Poniżej opi­sa­łem to w jaki spo­sób powsta­ła aku­rat taka kolej­ność i to, że Wiedza nie ist­nie­je, ist­nie­ją dane. Z mode­lem sta­je się to nie­co prostsze.

Definicje

Informacja – 1. ?wia­do­mość o czymś lub zako­mu­ni­ko­wa­nie cze­goś?, 2. ?dział infor­ma­cyj­ny urzę­du, insty­tu­cji?, 3. ?dane prze­twa­rza­ne przez kom­pu­ter? (źr. Słownik PWN)

Informacja – Informacja (łac. infor­ma­tio – wyobra­że­nie, poję­cie) to poję­cie o wie­lu defi­ni­cjach w róż­nych dzie­dzi­nach. Zasadniczo mamy dwa pod­sta­wo­we punk­ty widze­nia na infor­ma­cję. Pierwszy, któ­ry moż­na nazwać obiek­tyw­nym i wywo­dzi się z fizy­ki i mate­ma­ty­ki, gdzie infor­ma­cja ozna­cza pew­ną wła­sność fizycz­ną lub struk­tu­ral­ną obiek­tów, i dru­gi, subiek­tyw­ny (kogni­ty­wi­stycz­ny), gdzie infor­ma­cją jest to, co umysł jest w sta­nie prze­two­rzyć i wyko­rzy­stać do wła­snych celów. (źr. Wikipedia).

Dane – 1. ?fak­tylicz­by, na któ­rych moż­na się oprzeć w wywo­dach?, 2. ?infor­ma­cje prze­twa­rza­ne przez kom­pu­ter? (źr. Słownik PWN)

Dane (ang. data; z łac. datum – to, co jest dane) ? w infor­ma­ty­ce zbio­ry liczb i tek­stów o róż­nych for­mach. Są one uży­wa­ne przez kom­pu­te­ry do obli­czeń oraz są pre­zen­to­wa­ne, czy też prze­twa­rza­ne cyfro­wo. Takie tema­tycz­ne zbio­ry infor­ma­cji są nazwa­ne baza­mi danych. Bazy Danych są pod­sta­wo­wą czę­ścią sys­te­mów zarzą­dza­nia infor­ma­cją, sys­te­mów zarzą­dza­nia pro­jek­ta­mi czy kata­lo­gów pro­duk­tów. Układ danych przy­no­szą­cy kon­kret­ną infor­ma­cję to komu­ni­kat. (źr. Wikipedia).

Wiedza – 1. ?ogół wia­do­mo­ści zdo­by­tych dzię­ki bada­niom, ucze­niu się itp.; też: zasób infor­ma­cji z jakiejś dzie­dzi­ny?, 2. ?zna­jo­mość cze­goś? (źr. Słownik PWN)

Wiedza – ter­min uży­wa­ny powszech­nie, dotych­czas nie posia­da jesz­cze ogól­nie uzna­nej defi­ni­cji. Za kla­sycz­ną uzna­je się defi­ni­cję Platona z dia­lo­gu Teajtet, gdzie Sokrates w roz­mo­wie z Teajtetem docho­dzi do sfor­mu­ło­wa­nia defi­ni­cji, że wie­dza to praw­dzi­we, uza­sad­nio­ne prze­ko­na­nie. Nowa Encyklopedia Powszechna defi­niu­je wie­dzę jako ?ogół wia­ry­god­nych infor­ma­cji o rze­czy­wi­sto­ści wraz z umie­jęt­no­ścią ich wyko­rzy­sty­wa­nia?. (źr. Wikipedia)

Na bazie tych defi­ni­cji moż­na stwo­rzyć nastę­pu­ją­cy model pojęciowy:

? Fakty są komu­ni­ko­wa­ne przez wia­do­mo­ści, wia­do­mość komu­ni­ku­je fakt

? Fakty nio­są infor­ma­cje, infor­ma­cja to poj­mo­wa­nie faktów

? Informacja sta­no­wi widzę, wie­dza to zbiór informacji

Informacja a wiedza

Jak widać rela­cje te nie są skom­pli­ko­wa­ne jed­nak ich obraz poka­zu­je, że samo stwier­dze­nie ?baza wie­dzy? czy ?sys­tem infor­ma­cyj­ny? nabie­ra nie­co innej per­spek­ty­wy. Proszę zwró­cić uwa­gę na to, że nie ma tu bez­po­śred­nie­go powią­za­nia Wiadomości z Wiedzą. Można jed­nak powie­dzieć, że wia­do­mo­ści, jako opis fak­tów, nio­są infor­ma­cje, któ­re budu­ją naszą wie­dzę.

Czym są dane?

Otóż powyż­sze czte­ry poję­cia są tak na praw­dę nie­ma­te­rial­ne. Funkcjonują w naszych umy­słach. Dopiero ich utrwa­le­nia w posta­ci zapi­su na trwa­łym nośni­ku (ot choć­by pió­rem na papie­rze) czy­ni z fak­tów dane.

Mamy więc kolej­ny ele­ment tego mode­lu: Dane repre­zen­tu­ją Fakty, Fakty są doku­men­to­wa­ne przez Dane.

Jaki z tego wnio­sek? Pierwszy jaki się nasu­wa to to, że poję­cie Bazy Wiedzy jest trosz­kę ?nacią­ga­ne?. Dlaczego? Bo Wiedza to spo­sób inter­pre­ta­cji otrzy­my­wa­nych Wiadomości przez czło­wie­ka a pro­ces ten jest subiek­tyw­ny i zale­ży od kon­tek­stu prze­ka­za­nych wia­do­mo­ści. Kontekst zaś budu­ją wia­do­mo­ści poprze­dza­ją­ce. Podam przykład.

Wiadomość: ?w wyni­ku zde­rze­nia samo­cho­dów zgi­nę­ła jed­na oso­ba?. Na jej pod­sta­wie zbu­du­je­my sobie obraz koli­zji na dro­dze i ludz­kiej tra­ge­dii. Wiadomość ta jed­nak poprze­dzo­na (np. audy­cją radio­wą poda­ną godzi­nę wcze­śniej) prze­ka­zem o tre­ści ?Na dro­dze eks­pre­so­wej nr 48, w wyni­ku oblo­dze­nia, miał miej­sce wiel­ki karam­bol, zde­rzy­ło się 37 samo­cho­dów? wywo­ła nie­mal­że ulgę, że w takiej wiel­kiej kata­stro­fie zgi­nę­ła tyl­ko jed­na osoba.

Skoro więc nasza wie­dza bazu­je na wia­do­mo­ściach a ich inter­pre­ta­cja (poj­mo­wa­nie) bazu­je na kon­tek­ście to czym jest ta Wiedza? Kluczem tu są dane, to jak są maga­zy­no­wa­ne. Inaczej mówią to jak są repre­zen­to­wa­ne po ich utrwa­le­niu (rysu­nek powyżej).

Powoli nasu­wa się już chy­ba świa­do­mość tego, że dobra baza wie­dzy (czym by nie była) musi prze­cho­wy­wać dane opi­su­ją­ce i fak­ty i ich kon­tekst. Po dru­gie spo­sób repre­zen­ta­cji danych (ich zapi­su, utrwa­la­niu) powi­nien być jak naj­mniej podat­ny na ich subiek­tyw­ną inter­pre­ta­cję. Jak to osiągnąć?

Model pojęciowy jako model rzeczywistości

Dobrnęliśmy do poję­cia repre­zen­ta­cji danych. Najprostszą repre­zen­ta­cją danych jest nie­struk­tu­ral­ny tekst, popu­lar­nie zwa­ny pro­zą . Proszę zwró­cić uwa­gę na to, że nawet ten tekst to dane. Jaki z nim pro­blem? Ano trud­no jest w tej posta­ci wska­zać wia­do­mość, fakt, infor­ma­cję czy w koń­cu odpo­wie­dzieć na pyta­nie gdzie jest tu ta Wiedza. Wyobraźmy sobie dodat­ko­wo, że ten tekst (ten arty­kuł) pozba­wio­no ilu­stra­cji. Stałby się prak­tycz­nie tak nie­jed­no­znacz­ny, że każ­dy jego czy­tel­nik miał by pra­wo do jego wła­snej inter­pre­ta­cji (na szczę­ście są tu te dia­gra­my, dostęp­ne w wer­sji PDF, adres URL peł­nej wer­sji arty­ku­łu na koń­cu tekstu).

Powstaje potrze­ba takie­go zapi­su danych by były one zapi­sem fak­tów i nio­sły jed­nak ich kon­tekst, na tyle na ile to moż­li­we. Jaki to zapis?

Struktura informacji

Aby dane były moż­li­wie jed­no­znacz­ne i nio­sły kon­tekst muszą być zapi­sa­ne w spo­sób struk­tu­ral­ny i muszą mieć zde­fi­nio­wa­ną ich inter­pre­ta­cję czy­li tak zwa­ne meta­da­ne. Co to oznacza?

Za słow­ni­kiem języ­ka pol­skie­go: struk­tu­ra – 1. ?układ i wza­jem­ne rela­cje ele­men­tów sta­no­wią­cych całość?, 2. ?całość zbu­do­wa­na w pewien spo­sób z poszcze­gól­nych elementów?

Dodatkowo za WIKI: Metadane ? czy­li ?dane o danych?, [?]w przy­pad­ku bazy danych, meta­da­ny­mi są defi­ni­cje tabel, wido­ków, klu­czy itp. nato­miast dany­mi ? zawar­tość tych tabel, wido­ków (czy­li rekor­dy). W sys­te­mach zarzą­dza­nia doku­men­ta­mi meta­da­ne okre­śla się mia­nem metry­ki dokumentu.

Tak wiec mamy już wstęp­ną odpo­wiedź. Ale może przykład:

?Po jutrze, godzi­nę po Wiadomościach odbę­dzie spo­tka­nie człon­ków klu­bu twór­ców nie­jed­no­znacz­nych tek­stów w miej­scu tym samym co ostat­nio. Będziemy roz­ma­wia­li mię­dzy inny­mi o tym jak jesz­cze wydaj­niej zanu­dzać czy­tel­ni­ka, roz­wa­żać aspek­ty wpły­wu nud­nych tek­stów na sto­pień sen­no­ści adre­sa­ta prze­ka­zu oraz oce­ni­my wpływ naszych prac na tak zwa­ne zamu­la­nie sie­ci Internet.?.

Taki prze­kaz pozba­wio­ny kon­tek­stu jakim jest mię­dzy inny­mi dokład­ny czas nada­nia tej wia­do­mo­ści prak­tycz­nie nie nada­je się do jakiej­kol­wiek inter­pre­ta­cji (co nie zmie­nia fak­tu, że w takiej posta­ci czę­sto poda­wa­ne są zapo­wie­dzi spo­tkań w zapro­sze­niach prze­ka­zy­wa­nych pocz­tą elektroniczną)

Zapis struk­tu­ral­ny wyglą­dał by tak:

[Rodzaj zda­rze­nia]: Spotkanie

[Uczestnicy]: człon­ko­wie Klubu Twórców Niejednoznacznych Tekstów

[Termin]: 2008-10-06, godzi­na 20:00

[Miejsce]: klub Grafoman przy uli­cy Nudnej 24

[Treść]: Będziemy roz­ma­wia­li mię­dzy inny­mi o tym jak jesz­cze wydaj­niej zanu­dzać czy­tel­ni­ka, roz­wa­żać aspek­ty wpły­wu nud­nych tek­stów na sto­pień sen­no­ści adre­sa­ta prze­ka­zu oraz oce­ni­my wpływ naszych prac na tak zwa­ne zamu­la­nie sie­ci Internet.

Powyżej mamy struk­tu­ral­ny tekst (skła­da się z oddziel­nych powią­za­nych czę­ści), i meta­da­ne któ­ry­mi są nazwy (opi­sy) po lewej stro­nie dwu­krop­ków w kwa­dra­to­wych nawia­sach. Gdyby był to doku­ment (treść) w wer­sji ory­gi­nal­nej to pierw­sze czte­ry ele­men­ty tej struk­tu­ry mogły by sta­no­wić tak zwa­ną metry­kę całe­go doku­men­tu. Metryka doku­men­tu to nic inne­go na struk­tu­ral­ny opis zawar­to­ści (naj­czę­ściej skró­co­ny) nie­struk­tu­ral­ne­go tek­stu. Tak więc mamy opis tego co nazy­wa­my repre­zen­ta­cją danych.

Zaczynają się schody ? model dziedziny

Na począ­tek model danych. Model danych (bazy danych) to zbiór zasad (spe­cy­fi­ka­cji), opi­su­ją­cych struk­tu­rę danych w bazie danych. [?] Definiuje się tę struk­tu­rę danych poprzez spe­cy­fi­ka­cję repre­zen­ta­cji dozwo­lo­nych w mode­lu obiek­tów (encji) oraz ich związ­ków. (źr. WIKI)

Model danych to opis struk­tur, któ­re posłu­żą do kolek­cjo­no­wa­nia danych. Jest więc to nic inne­go jak struk­tu­ra obra­zu­ją­ca poję­cia i powią­za­nia mię­dzy nimi. Opisem takich struk­tur są mię­dzy inny­mi dia­gra­my takie jak te w tym arty­ku­le (co nie zmie­nia fak­tu, że są ludzie opi­su­ją­cy struk­tu­ry danych prozą).

[…] Jedyne co nam teraz pozo­sta­ło to imple­men­ta­cja mode­lu danych czy­li stwo­rze­nie bazy danych:

Obecnie coraz czę­ściej moż­na się spo­tkać z mode­la­mi obiektowymi.

Czy baza danych to wiedza?

[…]

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 informacja?.

Przemyślenia zwią­za­ne z tą ostat­nią defi­ni­cją pozo­sta­wiam Państwu. Ciąg dal­szy może nastąpi?

Pobierz kom­plet­ne opracowanie: