pb2
2.2 Osnove modeliranja podatkov
Razlogi za modeliranje podatkov so številni, a med njimi lahko navedem naslednje:13
za analizo poslovnih procesov
za IS: kreacija IS, dokumentacija in analiza
za ljudi: uporabniki, programerji ipd.
Koncepta modeliranja podatkov sta naslednja:
strukturni koncept, ki vključuje koncepte za prikaz atomarne informacije (njihove vrednosti in objekte – npr. semantična neodvisnost, identiteta objekta), za abstrakcijo podatkov v smeri strukturiranja informacij (npr. klasifikacija – sleherni objekt s podobnimi lastnostmi je možno razvrščati v razrede, agregacija – primerek obsega več lastnosti, dekompozija – dobimo vrednost atributa, generalizacija – označuje razred na široko / grobo, specializacija – označuje razred ožje / fino, asociacija – odnos z drugim razredom, identifikacija – vloga pooseblja primerek razreda in ključ – so atributi znotraj razreda) in strukturirano ortogonalnost (povečuje izrazno moč PM npr. knjiga / seznam poglavij).
Operacijski koncept, ki vključuje podatkovno vztrajnost (persistenca – življenjska doba podatkov) in neodvisnost podatkov s pomočjo arhitekturnih shem (zunanja, konceptualna in notranja shema – tri nivojska arhitektura).
Prav s tro- nivojsko arhitekturo (3NA) PM (imenovana tudi ANSI / SPARC architecture) se bom kot že prej obljubljeno nekoliko podrobneje ukvarjal. Glavna cilja 3NAPM sta:
omogočiti neodvisnost med podatki in uporabe
omogočiti podporo različnih uporabniških pogledov
Zunanji nivo oziroma zunanja shema opisuje poglede enega ali več uporabnikov na podatke. Podatki, ki za uporabnike niso pomembni so nevidni. Primera: podatki o informacijskem slogu registriranih uporabnikov v IS so skriti za uporabnike ali pa podatki o osebnih dohodkih zaposlencev za druge uporabnike niso vidni.
Globalni (konceptualni) nivo oziroma globalna shema združuje vse uporabnikove poglede v enoten pogled. Upoštevajo se entitete, vrsta podatkov, povezave in pogoji celovitosti, a prikrivajo se fizične strukture shranjevanja. Primer: v UDK MMIS se zbirajo pomembni podatki o strankah.
Notranji nivo oziroma notranja shema opisuje fizično strukturo pomnilnika PB. Pri uporabi FPM so opisane podrobnosti glede shranjevanja podatkov in njihovih dostopnih poti. Primer: ločena področja shranjevanja za različne vrste zaposlencev, strank ipd.
2.2.1 Slika 3: Tri- plastna arhitektura PB z vidika uporabnika/-ov
Slika 3 prikazuje tri- plastno arhitekturo z vidika uporabnika/-ov, kjer lahko vidimo zunanji nivo z zunanjo shemo, globalni nivo s prikazom globalne sheme in nenazadnje notranji nivo z notranjo shemo. Globalna shema se lahko brez posledic spreminja za zunanjo shemo kot npr. pri razširitvi PB z novim razredom (logična podatkovna neodvisnost) in notranjo shemo lahko neodvisno od globalne sheme spreminjamo kot npr. pri reorganizaciji podatkov (fizična podatkovna neodvisnost).
Koncepti relacijskega modeliranja so:14
konceptualni nivo – predstavlja celotno konceptualno strukturo PB in vsebuje vsebino o PB (je neodvisen od posamezne PB)
logični nivo – logični PM predstavlja podatkovno strukturo v takšni obliki, kot bo vgrajen v PB in ga izdelamo za določen SUPB
referencialna integriteta – je omejitev, ki zagotavlja celovitost podatkov pri brisanju ali ažuriranju in jo lahko določamo na logičnem nivoju
Konceptualni nivo zajema:
entitetni tip – je nekaj, o čemur shranjujemo informacije, ki mu določimo ime in atribute
podatkovni atribut – predstavlja elementarni del informacije, ki mu določimo ime in tip ter je lahko obvezen ali pa neobvezen
Entitetni identifikator – so vrednosti atributov
Razmerje – je poimenovana povezava med dvema entitetnima tipoma, ki sta nekako povezana. Lastnosti razmerja lahko določimo z imenom, vlogo, števnostjo, obveznostjo in odvisnostjo
Refleksivna razmerja – pomeni razmerje entitetnega tipa s samim seboj in pri tem lahko izraža neko nadrejenost oziroma podrejenost
Dedovanje – pomeni definiranje nove entitete s pomočjo specializacije obstoječe
Vzajemno izključevalno dedovanje – pomeni, da se izbere zgolj ena entiteta, medtem ko je druga izključena
vmesni entitetni tip – možno je pretvoriti razmerja v entitetne tipe, kadar pri razmerju potrebujemo dodatne atribute. Vmesni entitetni tip je odvisen od entitetnih tipov, saj so entitetni tipi preko njega povezani
Logični nivo dobimo na podlagi naslednjih postopkov:
preslikava med konceptualnim in logičnim nivojem
Tabela in stolpci
preslikava razmerij ena – mnogo
preslikava odvisnega razmerja
preslikava razmerja mnogo – mnogo
preslikava dedovanja
Logični model sestavljajo tabele, stolpci, reference, ključi (primarni, tuji), pogledi indeksi
Modeliranje sveta s PB je zelo odvisno od potreb in predstav uporabnikov. Propoziciji sta predikat (opisuje dogajanje ali stanje) in participanti (udeleženci v dogajanju). Participanti se še nadalje členijo na aktante (neposredni udeleženci v dogajanju) in na cirkumstante (opis okoliščin, v katerih poteka neko dogajanje).
Entiteta je najmanjši del, ki ga lahko ločimo od drugih delov podobe sveta. Entiteta pomeni predstavnik posamezne stvari, ki obstaja ali naj bi obstajala. Entitete delimo na konkretne (npr. osebe) in abstraktne (npr. zamisel). Druga delitev na participativne entitete (obstajanje – npr. udeleženec) in predikatne entitete (se dogaja – selekcija zamisli) se osredotoča na obstoj in na dogajanje. Entitetni tipi so klasificirane entitete, ki se delijo na naravne (oseba, pes, listina, dan ipd.) in glede na vlogo (voznik, študent, današnji dan, igralec ipd.). Ekstenzija entitetnega tipa pomeni, da entitetnemu tipu pripada entitetna množica, kjer velja pogoj časovne spremenljivosti. Entitetna imena predstavljajo entitete, ki jih poimenujemo s pomočjo črk oziroma besed.
Pravila opredelijo vse dogodke, ki pripadajo določeni dogodkovni vrsti in kjer veljajo določene zakonitosti (preslikovalna pravila – razmerja med entitetami in vrednostna pravila – ekstenzije imenskih tipov / npr. priimek, EMŠO).
Drugo poglavje, ki je bilo bolj kot ne zgolj preglednega značaja, sem s tem zaključil in se bom lahko v naslednjem poglavju lotil modeliranja podatkov s pomočjo tehnike entitetnega relacijskega diagrama (ERD – Entity relationship Diagram) za različne PB, ki naj bi bile sestavni del možne različice UDK MMIS.
3 Modeliranje podatkov za PB
ERD je diagramska tehnika za konceptualno in logično modeliranje podatkov.15 Osnovni koncepti so entiteta, atribut in povezava. Pri modeliranju podatkov bom uporabil Martinovo notacijo (J. Martinova notacija sledi konceptom razširjene tehnike entitetnega diagrama – pri označevanju povezav se uporabljajo grafični simboli, ki predstavljajo zgornjo in spodnjo mejo števnosti), ki se sicer uporablja pri strateškem planiranju IS. Pri risanju entitetnih diagramov sem uporabil programsko orodje Diagram Studio.
Možna različica UDK MMIS mora imeti za svoje osnovno delovanje vsaj naslednje podatke:
o strankah
za analizo obiskov (npr. poizvedbe, obiskovalci itd.)
o poslovnih družabnikih
o udeležencih (npr. zaposlenci)
o proizvodih in storitvah
o inventarju
o prodaji (elektronsko poslovanje, naročila, dobava, račune, plačila)
o financah (za poslovne analize)
za UDK področja
za multimedije (MM)
…
Ob posameznih slikovnih prikazih bom podal tudi opis.
3.1 Entiteta Stranka
3.1.1 Slika 4: Specializacija entitete “STRANKA” s povezavami
Slika 4 prikazuje entiteto “STRANKA” in njene podtipe posameznik, podjetje, zavod, obrtnik. Vse povezave so 1,1 : 1,N (ena proti ena ali več), kar pomeni, da vsakemu primerku leve entitete pripada eden ali več primerkov desne entitete, a vsakemu primerku desne entitete pripada en primerek leve entitete. Stranke so posamezniki, podjetja, zavodi in samostojni podjetniki (obrtniki).
S te slike lahko razberemo, o katerih strankah moramo zbirati podatke, vendar pa na podlagi tega grafičnega prikaza ne moremo vedeti, katere podatke bomo o različnih kategorijah strank zbirali.
Prav v ta namen bom na naslednji strani prikazal sliko, ki bo poleg entitete prikazala njene atribute. To pomeni lastnosti entitete, o kateri naj bi se prav tako zbirali in v PB shranjevali podatki.
3.1.2 Atributi
3.1.3 Slika 5: Entiteta “stranka” z atributi
O stranki naj bi se zbirali naslednji podatki:
osebni podatki – Priimek_Ime, Datum_Rojstva, spol, izobrazba, status (zaposlitev) ipd.
število nakupov – podatki o tem, kolikokrat stranka nakupuje in kakšne izdelke
kupna moč stranke – v primeru, da obstajajo dejanski podatki, sicer pa ocene
informacijski slog stranke – npr. katere strategije stranka pri pridobivanju informacij uporablja (npr. uporaba notranjega iskalnika, telefon, elektronsko pošto ipd.)
aktivnost – podatki o strankinih aktivnostih npr. je član gasilskega društva, se ukvarja s slikarstvom, stranka se nadalje izobražuje, veliko potuje itd.
zanimanje – po katerih informacijah z različnih področij znanosti, umetnosti, dejavnosti oziroma vsakdanjega življenja stranka največkrat poseže (izdelava miselnega modela strankinih zanimanj)
vpliv – ocena na lestvici od 0 do +5 o tem, kako je stranka v družbi vplivna. Na podlagi dejavnika vpliva, bi lahko sklepali o tem, ali je stranka naklonjena določenem podjetju, indiferentna ali pa celo manj naklonjena (npr. tekmec, subjektivna merila). Na podlagi tega dejavnika, bi se morda dalo sklepati zakaj je npr. prodaja knjig precej upadla. Na naslednji strani bom prikazal sociogram dejavnika vpliva
3.1.4 Slika 6: Sociogram vpliva stranke v družbi
Slika 6 prikazuje sociogram vpliva stranke v družbi, kjer je možno razbrati, da je od teh strank M {A, B, C, D, E, F} najbolj vplivna stranka A, kateri vpliv je bil ocenjen s številom 5, sledi stranka B z oceno 4, stranke C, D, E so bile ocenjene z 2, medtem ko je bila stranka F ocenjena kot najmanj vplivna z ˝. Na podlagi tovrstnih preučevanj, bi lahko sklepali, ali je stranka določenemu podjetju nenaklonjena. Kot primer bi navedel stranko A, ki ima visoko kupno moč, razvit informacijski slog, je zelo aktivna, ima širok spekter zanimanja, je stara okoli 35 let in je dokaj izobražena (npr. univerzitetna izobrazba), vendar pa je vrednost števila nakupov na leto zelo nizka in je usmerjen na poceni izdelke v vrednosti manj od 1000 SIT.
Diagramsko tehniko sociograma bom pozneje ponovno uporabil pri entiteti udeležencev (npr. zaposlenci, poslovni družabniki itd.)
3.2 Entiteti proizvod in storitev
Z obzirom na to, da bi bilo možno UDK MMIS uporabiti v številnih in raznovrstnih delovnih poslovnih sistemih, bom temu ustrezno tudi navedel različne proizvode in storitve. Vsekakor pa ne bom mogel vseh proizvodov in storitev, ki obstajajo v družbi navesti, zato bom naslednji slikovni diagram uvrstil v oglati oklepaj. Na spodnji desni strani ob oglatem zaklepaju bom dodal označbo “n”, kar pomeni, da je število proizvodov in storitev v družbi težko šteti oziroma vse to v diagramu prikazati. Šele ko bi se opredelil za določen delovni / poslovni sistem, bi bilo možno natančneje opredeliti podatke o proizvodih in storitvah, nakar bi šele lahko izdelal strateški načrt po EMRIS za UDK MMIS.
3.2.1 Slika 7: Specializacija entitete “Proizvodi in storitve” s povezavami
Slika 7 prikazuje zelo zapleteno specializacijo “Proizvodi in storitev” s povezavami. Če določimo, da se UDK MMIS uporablja na družbeni makroskopski skali, sledi iz tega, da je raznovrstnostni razpon tako proizvodov kot tudi storitev težko modelirati. Zaradi tega sem se pri modeliranju podatkov odločil za grafični dodatek (opozorilo: ta grafični dodatek nima konvecionalne podlage, ampak sem se zanj odločil, ker imam opraviti z zelo kompleksnim sistemom kot je “DRUŽBA”!). Grafični znak [ ]n pomeni, da imamo opraviti z velikim številom različnih proizvodov in storitev. Za povezavo 0,1,N : 0,1,N (nič, ena, ali več proti nič, ena ali več) med proizvodi in storitev sem se odločil, ker:
Zaradi svoje izrazite splošnosti najbolj odgovarja makroskopskemu vpogledu (UDK MMIS kot IS za celotno družbo)
Proizvodi in storitve so lahko med sabo zelo povezane, občasno povezane ali pa sploh niso povezane. Kot primer bi podal storitev PREVOZ, ki je lahko povezan s proizvodom HRANA ali pa ni. Prav tako je lahko storitev SVETOVANJE v zelo tesni povezavi s proizvodom KNJIGA, kar pa ni nujno itd. Povezava 0,1,N : 0,1,N sicer pomeni naslednje:
vsakemu primerku leve entitete pripada nič, eden ali več primerkov desne entitete
vsakemu primerku desne entitete pripada nič, eden ali več primerkov leve entitete
Vse ostale povezave med “Proizvod” ali “Storitev” in njihovimi podtipi so 1,1 : 1,N.
3.2.2 Atributi za proizvode in storitve
3.2.3 Slika 8: Entiteti “Proizvod in Storitev” z atributi
Slika 8 zopet prikazuje zelo kompleksno področje glede entiteti “Proizvod in Storitev” z atributi (gl. sliko 7). O proizvodu naj bi se zbirali naslednji podatki:
cena v SIT
kakovost (nižja, srednja, višja, visoka)
količina (npr. podatki o številu uspešno prodanih proizvodih, teža, volumen itd.)
izdelovalec (npr. pri knjigi je založnik A, pri obleki npr. podjetje MuraDesign itd.)
trajnost (življenjska doba proizvoda, npr. proizvodi za enkratno ali večkratno uporabo)
ponudba (npr. podatki o zalogi posameznih proizvodov, dostopnost, zahtevani napor prilagojevanja, iskalno obdobje itd.).
povpraševanje po proizvodih (veliko, srednje, nizko oziroma številčno izraženi podatki)
n (možni drugi podatki kot npr. o časovnih odvisnosti v zvezi s proizvodom)
Pri storitvah bi lahko zbiral naslednje podatke:
otipljivost, kjer gre za rangiranje oprijemljivih storitev (opomba: določene pravniške storitve so sicer navidezno težje izmerljive, vendar pa praksa kaže drugačno sliko?!!)
neotipljivost, kjer gre za rangiranje težko izmerljivih in brezplačnih storitev
cena (ceno lažje določimo pri otipljivih storitvah, tako da bi lahko glede neotipljivih storitvah zbirali podatke o številčnosti njihove uporabe na en mesec ipd.)
kakovost: zbirali bi se npr. podatki o urejenosti, zanesljivosti, odzivnosti, strokovnosti, ustrežljivosti, verodostojnosti, varnosti, dostopnosti, o kakovosti komuniciranja in morda podatki glede uspešnosti razumevanja strank itd.
…
3.3 Entiteta delovni / poslovni proces (DPP)
Če ponovno teoretično predpostavimo, da naj bi delovanje UDK MMIS pokrilo različne delovne / poslovne sisteme, se zopet nahajamo pred zelo kompleksnim problemskim področjem. Povrhu tega gre pri entiteti DPP za različne delovne / poslovne sisteme (DPS), kjer velja primarna zakonitost, da naj bi bili ti podatki internega značaja. To pomeni, da bi bil omejen dostop do teh podatkov in bi lahko do teh podatkov imele dostop zgolj izbrane vrste zaposlencev (npr. ravnatelji, finančniki itd.) in morda nekateri drugi udeleženci (npr. vlagatelji ipd.). V kontekst DPP bi uvrstil tudi interna poslovna pravila, ki bi določala politiko in strategijo poslovanja.
3.3.1 Slika 9: Specializacija entitete “DPP” s povezavami
Slika 9 prikazuje zelo zapleteno specializacijo “DPP” s povezavami. Če izhajamo iz družbene makroskopske skale, sledi iz tega, da je raznovrstnostni razpon DPP zopet težko modelirati ( [ ]n - podobno kot pri “Proizvod / Storitev gl. str. 28 in gl. tudi vrsto povezave). Kot podtipe entitete “DPP” sem izpostavil vzdrževanje (oddelek), nabava (oddelek), naročila, poslovna pravila, E- poslovanje (oddelek), Prodaja (oddelek), računovodstvo (oddelek), finančna služba in n 3 (druge možnosti).
3.3.2 Atributi za DPP
3.3.3 Slika 10: Entiteta DPP z atributi
V zvezi z entiteto DPP bi zbiral naslednje lastnosti:
Atribut A (oddelek vzdrževanje) – vrsta, vrednost, velikost, kakovost, sestava itd. delovnih sredstev (npr. cena strojne in programske opreme, količina, pogostost in vrsta popravil popravila npr. računalnika, zaloga rezervnih delov npr. čipi, aktualnost strojne opreme, posodabljanje spletnih strani in popravki v zvezi z njo, stroški vzdrževanja itd.
Atribut B (oddelek nabava) – nazivi in oznake delovnih predmetov, količine delovnih predmetov (npr. knjige), cene delovnih predmetov, seznami dobaviteljev in njihove pogoje dobave, seznami reklamacij, seznami nabavnih trgov ipd.
Atribut C (poslovna pravila) – seznam pravil v zvezi s poslovanjem npr. etika poslovanja, obveze do strank, način komuniciranja s strankami, razvrščanje strank na podlagi postavk (npr. v kategorijo dobre stranke se uvršča stranka, ki nakupuje za 100.000, 00 tolarjev letno).
Atribut D (E- poslovanje) – uspešnost notranjega E- poslovanja, število izvedenih transakcij znotraj DPS ipd.
Atribut E (E- poslovanje) – uspešnost zunanjega E- poslovanja, število izvedenih transakcij zunaj podjetja itd.
Atribut F (prodaja) – prihodki, seznami prodanih artiklov, seznami prodajnih trgov, tržni delež itd.
Atribut G (prodaja) – seznam prodajnih poti, poslovni učinki po posameznih regijah ipd.
Atribut H (računovodstvo) – stroškovno računovodstvo npr. seznami stroškovnih mest
Atribut I (računovodstvo) – finančno računovodstvo npr. razsežnosti preteklih denarnih transakcij
Atribut J (računovodstvo) – poslovodno računovodstvo npr. odločitveni primeri za prihodnje odločanje
Atribut K (finančna služba) – višina obratnih sredstev v DPS, terjatve, krediti, obseg trgovanja itd.
Atributi L, M, N, O (n 3) – število vhodov za različna področja, število izhodov za različna področja itd.
3.4 Entiteta udeleženec/-i
Udeleženci pri delovanju določenega DPS so lahko naslednji:
Zaposlenci – notranji (ravnatelji, uredniki, prodajalci, vzdrževalci, programerji, transportni delavci, finančniki, računovodje, pravniki itd. in zunanji (npr. honorarni, profesorji, sezonski delavci, monterji, sistemski analitiki itd.)
Poslovni družabniki – delničarji, sofinancerji, banke, borzne hiše, inovatorji itd.
Tudi v tem primeru velja glavna postavka, da bi bili tovrstni podatki dostopni zgolj za zaposlence (npr. ravnatelji idr.) in nekatere poslovne družabnike (npr. sofinancerji idr.). Za širši krog bi bili dostopni morda zgolj nekateri podatki v zvezi s profesionalno usmerjenostjo zaposlencev in poslovnih družabnikov ipd.
3.3.4 Slika 11: Specializacija entitete udeleženec s povezavama
Slika 11 prikazuje specializacijo entitete udeleženec s povezavama na dva podtipa entitete, ki sta zaposlenec in poslovni družabnik. Povezavi sta 1,1 : 1,N.
3.3.5 Slika 12: Entiteta udeleženec in atributi
Na sliki 12 lahko vidimo entiteto “Udeleženec” z njegovimi atributi. Na podlagi tega izbora bi zbiral naslednje lastnosti:
Zaposlenec – osebni podatki, višina osebnega dohodka, storilnost zaposlencev, socialna bližina med zaposlenci, aktivnosti zaposlencev, interesna področja zaposlencev, informacijski slog zaposlencev.
Poslovni družabnik – podatki o poslovnih družabnikih (priimek ime PD osebe / naziv podjetja idr., število / vrednost njihovih delnic, velikost kapitala ipd., solventnost PD, likvidnost PD, interesna področja PD, informacijski slog PD, aktivnosti ipd.
Na naslednji strani bom še kot zanimivost prikazal sociogram socialne bližine med nekaterimi zaposlenci. Sociogram je lahko zelo dober pripomoček za organizacijo zaposlencev.
3.3.6 Slika 13: Sociogram socialne bližine zaposlencev
Na sliki 13 lahko zagledamo zanimiv prikaz o naklonjenosti / nenaklonjenosti zaposlencev do drugih zaposlencev. Zelene številčne vrednosti izražajo število naklonjenih odnosov, medtem ko rdeče številke prikazujejo število nenaklonjenih odnosov. Zelene puščice pomenijo povezavo naklonjenosti, a rdeče nenaklonjenost. Največje število naklonjenih odnosov je nabrala tajnica t.j. osem naklonjenih odnosov (npr. ravnatelj, namestnik ravnatelja, zunanji sodelavec, programer, transportni delavec in prodajalec) in en nenaklonjen z upraviteljem PB.
Zbiranje teh podatkov bi lahko občutno izboljšalo pregled nad socialno klimo v podjetjih.
3.4 Entiteta UDK področje
3.4.1 Slika 14: Specializacija entitete “UDK področje” s povezavami
UDK področje (slika 14) se členi na posamezna UDK področja 0, 1, 2, 3, 4, 5, 6, 7, 8 in 9. To naj bi bila vsa področja človekovega znanja. UDK bom v naslednjem poglavju bolj podrobno opisal, zato bi zaenkrat izpostavil zgolj posebnost UDK področja 4, ki zaenkrat v tem klasifikacijskem sistemu nima uporabne vrednosti in je prazen. V UDK področje 4 bi po mojem mnenju lahko uvrstili interdisciplinarne znanosti in dejavnosti, vendar pa v Den Haagu morda mislijo drugače (ni še prave odločitve o tem, katero področje človekovega znanja bi pod UDK 4 uvrstili). V tem poglavju so moja prizadevanja usmerjena v modeliranje podatkov UDK področij, kajti prav na podlagi UDK naj bi bili razvrščeni vsi podatki (vse entitete in njihove lastnosti), ki sem jih do sedaj modeliral (stranka, proizvod, storitev, DPP, poslovni družabnik itd.). To pomeni, da bi bila UDK podatkovna baza ključnega značaja v smeri označevanja / razvrščanja vseh podatkov in bi pri tem odigrala vlogo povezovalke vseh ostalih PB (v primeru, da bi želeli zgraditi zelo velik in kompleksen IS). Prav to bi zahtevalo avtomatično UDK klasifikacijo vseh PB tako za entitete kot tudi za njihove atribute. Preden bom obrazložil možno rešitev za avtomatično klasifikacijo podatkov (s pomočjo sheme), bom najprej prikazal atribute entitete “UDK področje”, nakar bom prikazal celotni entitetni relacijski diagram v okrnjeni obliki za vse entitete.
3.4.2 Atributi entitete “UDK področje”
3.4.3 Slika 15: Entiteta “UDK področje” z atributi
Slika 15 kaže številne, skorajda neštevne lastnosti entitete “UDK področje”, kajti ta entiteta vsebuje vse lastnosti doslej obravnavanih entitet in še mnoge več (npr. kupna moč, kakovost, solventnost, tržni delež, število nakupov itd.). Prav entiteta “UDK področje” je ključnega in povezovalnega značaja za vse ostale entitete; je celota, kajti s pomočjo UDK je (teoretično) možno vse entitete in atribute klasificirati. Pravzaprav je potrebno vse ključne prvine, ki jih določen DPS potrebuje za svoje poslovanje spraviti v obliko nekakšnega UDK leksikona z obsežnim registrom (v našem primeru bi moral biti tovrsten UDK leksikon zelo obsežen, za manjše podjetje pa morda manj), kjer so vse prvine ustrezno označene. Takšen leksikon bi lahko služil tudi kot odlična izobraževalna baza znanja ipd. Register UDK leksikona pa bi lahko bil v vlogi podatkovnega slovarja. To bi bila zgolj ena rešitev od številnih drugih, kajti vse je odvisno od potreb, števila vpletenih, želja, finančnih sredstev, delovne sile, skratka od tega, kako velik IS se naj bi izgradil.
3.4.4 Možna različica entitetnega diagrama za vse entitete in atribute v skrajšani obliki
3.4.5 Slika 16: Entitetni diagram podatkov
Opis slike 16 (entitete in atributi):
Entiteti “UDK področje” sem določil število “n” atributov.
Entiteti “Stranka” sem določil sedem atributov.
Entiteti “Udeleženec” sem določil 12 atributov.
Entiteti “Storitev” sem določil število “n” atributov
Entiteti “Proizvod” sem določil število “n” atributov
Entiteti “DPP” sem določil število “n” atributov.
Uporabljal sem naslednje povezave (legenda):
1. Entiteta “UDK področje se povezuje z drugimi entitetami na naslednji način:
S stranko 1,1 : 1,N, kar pomeni, da lahko pripada entiteti UDK področje eden ali več primerkov entitete stranke (različne vrste strank) in entiteti “Stranka” obvezno pripada en primerek entitete “UDK področje” (entiteta stranka dobi svoj UDK vrstilec).
Z udeležencem 1,1 : 1,N – podoben pomen kot prej navedeno. Različni udeleženci obstajajo in entiteti “Udeleženec” se prav tako dodeli UDK vrstilec.
S storitvijo 1,1 : 1,N – storitev je več vrst, a entiteti “Storitev” se dodeli UDK vrstilec.
S proizvodom 1,1 : 1,N – več različnih proizvodov obstaja, entiteti “Proizvod” se dodeli UDK vrstilec.
DPP 1,1 : 1,N – več različnih DPP obstaja, entiteti “DPP” se dodeli UDK vrstilec.
2. Druge povezave:
Povezava med entiteto “Stranka” in entiteto “Storitev” je 0,1,N : 0,1,N, kar pomeni, da lahko stranka koristi nič storitev, eno storitev ali pa več storitev in obratno je lahko entiteta “Storitev” namenjena nič strankam, eni stranki ali pa večjim številom strank.
Povezava med entiteto “Stranka” in entiteto “Proivod” je prav tako 0,1,N : 0,1,N.
Povezava med entiteto “Stranka” in entiteto “Udeleženec” je 0,1,N : 0,1,N.
Povezava med entiteto “Stranka” in entiteto “DPP” je 0,1,N : 0,1,N.
Povezava med entiteto “Udeleženec” in entiteto “DPP” je 1,1 : 1,N. To pomeni, da sleherni entiteti “DPP” pripada eden ali več primerkov entitete “Udeleženec, medtem ko entiteti “Udeleženec” pripada vsaj en primerek entitete “DPP”.
Povezava med entiteto “Udeleženec” in entiteto “Proizvod” je 0,1,N : 0,1,N. Entiteti “Udeleženec” tako pripada nič, eden ali več primerkov entitete “Proizvod” in tej lahko pripada nič, ena ali več primerkov entitete “Udeleženec”. Npr. sofinancer določenega DPS lahko investira v nič, en ali več proizvodov in temu ustrezna je potem povratna povezava.
Povezava med entiteto “Udeleženec” in entiteto “Storitev” je prav tako 0,1,N : 0,1,N. Npr. poslovnemu družabniku A lahko pripada nič, ena ali več storitev in entiteta “Storitev” je lahko “soproizvod” nič, enemu ali pa večjemu številu poslovnih družabnikov.
Povezava med entiteto “Udeleženec” in entiteto “Stranka” je 0,1,N : 0,1,N, kajti možno je npr. naslednje: nihče od udeležencev ni stranka, en udeleženec je stranka ali pa večje število udeležencev so tudi stranke. Isto velja za povezavo med entiteto “Stranka” in entiteto “Udeleženec”.
Povezava med entiteto “DPP” in entiteto “Proizvod” je 1,1 : 1,N. Npr. v delovnem poslovnem procesu se npr. izdeluje en ali pa več proizvodov, vendar pa sleherni proizvod je plod vsaj enega DPP.
Povezava med entiteto “DPP” in entiteto “Storitev” je 1,1 : 1,N. Velja podobno kot pri prejšnjem odnosu.
Povezava med entiteto “DPP” in entiteto “Stranka” je 0,1,N : 0,1,N. Npr. v DPP ni vključena nobena stranka, vključena je ena stranka ali pa je več strank vključenih v DPP in obratno.
S pomočjo prikazanih oziroma modeliranih entitet in njihovimi atributi sem dobil vpogled v povezave in lastnosti tistih podatkov, ki bi jih lahko vključil v relacijsko PB (npr. objektno relacijsko PB, ki je primerna za shranjevanje multimedijskih podatkov npr. zvok, slike, filmi ipd.) za UDK MMIS. Ukvarjal sem se z zanimivo zamislijo, kako načrtovati PB, katera bi poskušala s pomočjo UDK-ja zajeti obsežen spekter človekovega znanja in dejavnosti. Končni izid pri modeliranju podatkov je bil takšen, da sem dobil abstrahirani slikovni osnutek o entitetah in atributih. V nadaljevanju nameravam kot prehod na naslednje poglavje prikazati še možno različico arhitekturne sheme PB v povezavi z drugimi prvinami, ki so za delovanje PB neobhodno potrebni (npr. SUPB, uporabniški programi, odjemalec strežnik itd.).
3.4.6 Možna različica arhitekturne sheme UDK PB
3.4.7 Slika 17: Okvirna arhitekturna shema UDK podatkovne baze
Slika 17 prikazuje arhitekturno shemo heterogene porazdeljene UDK podatkovne baze na spletu, kjer imamo opraviti z arhitekturo odjemalec / strežnik. Procesiranje odjemalec / strežnik je logični koncept razdelitve aplikacije v navadno dva procesa (možno tudi več), ki se odvijata vsak v svojem ali pa oba v istem računalniku.16 Strežnik v našem primeru nudi svoje storitve večjemu številu odjemalcev (strežniški proces je lahko tudi en sam). V kontekstu PB za to poskrbi SUPB, ki se odziva na zahteve, posredovane s strani odjemalčevega procesa (v tem primeru imamo opraviti s porazdeljenim procesiranjem zahtev, kjer se procesa odvijata vsak v svojem računalniškem sistemu).
V velikem družbenem sistemu lahko (npr. Slovenija, Nemčija, ZDA itd.) srečujemo različne računalniške sisteme, kjer so v uporabi celo različni PM in s tem različni SUPB. Slika 17 ponuja teoretično rešitev za usklajeno delovanje različnih sistemov na spletu. Zamislil sem si računalniški sistem, ki bi bil zmožen izvesti avtomatično klasifikacijo spletnih dokumentov (besedila, slike, zvok ipd.) s pomočjo UDK-ja in sistemom Harvest (sestavljen iz številnih podsistemov), ki komunicira z vrednostno atributno usmerjenim protokolom SOIF (angl. Summary Object Interchange Format – format za objektno izmenjavo povzetkov).17 Gramatika SOIF je naslednja:
SOIF ::= OBJECT SOIF | OBJECT
OBJECT ::= @ TEMPLATE-TYPE { URL ATTRIBUTE-LIST }
ATTRIBUTE-LIST ::= ATTRIBUTE ATTRIBUTE-LIST | ATTRIBUTE
ATTRIBUTE ::= IDENTIFIER {VALUE-SIZE} DELIMITER VALUE
TEMPLATE-TYPE ::= Alpha-Numeric-String
IDENTIFIER ::= Alpha-Numeric-String
VALUE ::= Arbitrary-Data
VALUE-SIZE ::= Number
DELIMITER ::= ":"
SOIF vsebuje tudi seznam atributov in objektov, na podlagi katerih zbira vsebine za sleherni objekt (če smo seveda objekte določili) posebej. Prav v ta namen bi bilo smiselno pripraviti nekakšen obsežen UDK leksikon in UDK podatkovni slovar (Podatkovni slovar - Data Dictionary – DD; vsebuje tekstovne opise vseh podatkov, ki nastopajo v različnih diagramih, in tvorijo model v njemu. V podatkovnem slovarju so vsi podatkovni tokovi in shrambe podatkov iz diagramov podatkovnega toka razčlenjeni na podatkovne prvine), s katerim bi lahko podatke organizirali v strukturirani obliki. Prav to bi bila osnova za avtomatično UDK klasifikacijo spletnih dokumentov. Na takšen način bi bilo možno poenotiti oziroma uskladiti vsebinske strukture porazdeljenih bolj ali manj heterogenih PB. Naj za lažje razumevanje snovi še narišem osnutek, na kakšen način naj bi avtomatična UDK klasifikacija (v nadaljevanju zgolj UDK) potekala. Tovrsten pristop bi bil še posebej zelo primeren za podatkovna skladišča in za sisteme pri podpori odločanja (npr. OLAP – Online Analitical Processing).
3.4.8 Slika 18: Avtomatična UDK spletnih listin s pomočjo SOIF
Slika 18 ponazarja avtomatično UDK spletnih listin s pomočjo protokola SOIF.
Na spletu se zbirajo heterogeni spletni dokumenti v relacijskem podatkovnem
sistemu Oracle, ki jim protokol SOIF na podlagi povzetka vsebin avtomatično
določi UDK vrstilec. Prav isti protokol je tudi odgovoren, za priklic teh že
klasificiranih podatkov v tem podatkovnem sistemu. Oraclov relacijski
podatkovni sistem, ki uporablja tudi ukazni vmesnik SQL*Plus, je tudi
objektno orientiran, kar pomeni, da je vanj možno shranjevati in priklicati
različne vrste formatov (Html, DOC, PDF, PNG, JPEG, GIF, AVI, MPEG itd.)
in podatkov tako besedilnih, zvočnih in vizualnih (slike, filmi, video).
Da se povrnem na sliko 17, ki prikazuje na levi in desni strani, da SUPB dostopa
do MPB in FPB s pomočjo operacijskega sistema (npr. Win XP, Linux ipd.).
S PB pa lahko SUPB upravlja s pomočjo uporabniških programov
(npr. sistem za podporo odločanja, Microsoft Office, Microsoft Excell, DTM Stakeout itd.).
Zgornji del slike nam kaže primere uporabe oziroma uporabniški vidik.
Uporabnik npr. izvede na spletu poizvedbo(vhod), na podlagi katere dobi povratno
informacijo (izhod – rešen problem).
Naj še za konec tega poglavja prikažem sliko o trendu PB v prihodnosti: 
3.4.9 Slika 19: PB v prihodnosti18
Slika 19 prikazuje razvoj PB. V preteklosti so prevladovali mrežni in
drevesni modeli PB. V današnjem času prevladujejo relacijski modeli
PB (npr. objektno relacijske PB za multimedije).
Prihodnji trend naj bi šel v smer inteligentnih PB – se
pravi v smer inteligentnih sistemov.
PB se ne polnijo samo od sebe, ampak so odvisne od človeka, ki upravlja
s podatki. Prav tako tudi ni človeka, ki bi s številnimi modrostmi
prišel na ta svet, a sleherni človek ima svoj potencial, ki mu biogenetiki
pravijo genska zasnova in povrhu tega je deležen bolj ali manj skrbne
vzgoje. Če zdaj navedeno pogojno prenesem na področje PB, lahko rečem,
da imajo tudi PB svojo t.i. “gensko zasnovo”, ki se kaže v obliki strojne in
programske opreme. To se pravi PB prihodnosti morajo vsebovati
določen potencial, ki je primeren npr. za (deloma?) samodejno
vsrkavanje znanja. Prav v tem pogledu bi predpostavil, da je pri tem
še zlasti pomemben operacijski sistem (tudi strojna oprema je pomembna),
ki mu je potrebno dodati določene potenciale, morda že samo znanje v
obliki nekakšnega polistrukturiranega leksikona?
V naslednjem poglavju bom nekoliko podrobneje opisal UDK MMIS, nakar
bom še predstavil možnosti njegove uporabe v različnih delovnih / poslovnih
sistemih.
--------------------------------------------------------------------------------
13 Gl. URL: http://www.sts.tu-harburg.de/teaching/ws-98.99/DBIS/entry.html (2003-08-13)
14 Podatke dobil: http://aris.fri.uni-lj.si/~damjan/RIS_vaje/RIS%20vaje%20skripta_2003.pdf (2003-08-14)
15 Definicijo sem povzel po delu: Silič, M., Colnar, M., Krisper, M. [etal …].(2000) EMRIS -
Enotna metodologija razvoja informacijskih sistemov. #Zv. #2, Objektni razvoj. Ljubljana : Vlada Republike Slovenije, Center za informatiko, na strani 315.
16 Opredelitev povzel po viru: Mohorič, T.(2002). Podatkovne baze. 2. popravljena izd. Ljubljana: BI- TIM na strani 32.
17 Informacije o SOIF-u sem dobil na URL: http://harvest.sourceforge.net/harvest/doc/html/manual-8.html#Example%201 (2003-08-21)in http://www.offis.uni-oldenburg.de/ueber/jahresbericht/jb1997/p9_3.php (2003-07-15)
18 Sliko sem prevzel po naslednjem spletnem viru: http://dbtlab.uni-mb.si/pb2/pb2a.pdf (2003-07-30)
Verantwortlich für den Inhalt dieser Seite ist ausschließlich der
Autor dieser Homepage, kontaktierbar über dieses Formular!