začetni pogoj dogodek Slika procesa: POSTOPEK (ALGORITEM) vhodno izhodno sporočilo sporočilo končni pogoj
PROCES je strukturna množica aktivnosti, katerih rezultat je nek proizvod ali storitev s tržno vrednostjo. Zajema vhode in izhode, ki predstavljajo neko dodano vrednost za uporabnike. Praviloma se sestoji iz več postopkov in posega na več funkcijskih področij.
POSTOPEK predstavlja smiselno zaključeno množico operacij na podatkih, s katerimi se sistem pripelje iz enega v drugo stanje. Opredeljen je z algoritmom in vhodno-izhodnimi podatki.
Postopek je temeljni koncept, s katerim modeliramo dinamiko IS. Postopki so lahko elementarni ali kompleksni (sestavljeni postopki). Kompleksni postopki nastopajo praviloma na višjih hierarhičnih ravneh delovnega sistema. Izvedba postopka povzroči, da sistem preide iz enega stanja v drugo, hkrati pa pomeni tudi uresničitev neke naloge, ki je sestavni del določene poslovne funkcije. Naloga je opredeljena z algoritmom, to je množico logično povezanih pravil, ki opredeljujejo operacije po podatkih.
OPERACIJA je poseg na primerku entitete, s katerim se primerki čitajo, kreirajo, spreminjajo in brišejo, ali na vrednostih njegovih atributov, s katerim se te vrednosti spreminjajo. Operacije delimo na elementarne - nanašajo se na primerke entitet (kreiranje, čitanje, spreminjanje, brisanje) in procesne – nanašajo se na vrednosti atributov entitet. Operacije se izvajajo samo v okviru postopkov.
DOGODEK je neke vrste impulz, do katerega pride bodisi zaradi sprememb ali posegov iz okolice IS ali zaradi notranjega stanja IS. Povzroči izvedbo enega ali več postopkov, s katerimi se spreminja stanje sistema.
2 vrsti dogodkov:
-
tisti, ki nastopajo od zunaj (eksterni); povzroča jih okolica
-
tisti, ki so rezultat nečesa, kar se je zgodilo znotraj sistema (interni)
Dogodek sproži nek postopek, proces. Noben postopek se ne sproži sam od sebe. Za vsakim postopkom stoji računalniški program, ki se ne bo sprožil, če ne bo nekega impulza. Vedeti moramo zakaj in kdaj se bo nek postopek izvedel.
Eksterni dogodki – kažejo nek impulz od zunaj.
Interni dogodki – npr. prekoračenje limita – sproži se postopek o prekoračenem limitu – izpisa opomina. To je notranji dogodek, ki je nastal kot posledica stanja v katerem se je sistem znašel.
ZAČETNI POGOJ opredeljuje vse pogoje, ki morajo biti izpolnjeni, da je zagotovljen pravilen potek izvajanja postopka. Začetni pogoj opredeljuje vse pogoje, ki morajo biti izpolnjeni, da se nek postopek začne in da je zagotovljeno pravilno izvajanje postopka.
Z začetnimi pogoji se opredeli naslednje:
-
katera vhodna sporočila morajo biti dana, da se izvajanje postopka lahko začne
-
vrednost atributov entitet, ki jih vsebujejo vhodna sporočila, ali ujemanje med temi vrednostmi in vrednostmi, shranjenimi v podatkovni bazi.
Funkcija opredelitve začetnega pogoja: da zagotavlja vse pogoje, da se bo nek postopek normalno odvijal in normalno končal – to lahko ugotovi končni pogoj, s katerim preverjamo ali se je postopek normalno zaključil.
KONČNI POGOJ, z njim ugotavljamo ali je bil nek postopek izvršen do konca in izvršen po pravilih tako, da ga štejemo za veljavnega. Funkcija je tudi v tem, če ugotovimo, da nek postopek ni bil izveden v skladu s pravili, ga lahko razveljavimo in ga vrnemo na začetek izvajanja postopka. Končni pogoj opredeli vse pogoje, ki morajo biti izpolnjeni po izvedbi procesa, da se lahko šteje, da je bil proces pravilno izvršen in normalno zaključen ter, da je zagotovljena integriteta IS.
Je varovalni mehanizem, ki pokaže ali je bil postopek izvršen na pravilen način.
Funkcija končnega pogoja: je v tem, da preprečuje nekonsistenco v podatkih – zagotavlja integriteto podatkov.
S končnimi pogoji se najpogosteje opredeli naslednje:
-
izhodna sporočila, ki morajo nastati kot rezultat izvedbe postopka
-
razmerja med vrednostmi atributov entitet, ki jih vsebujejo izhodna sporočila
-
vrednosti atributov entitet, shranjenih v bazi podatkov po izvedbi postopka
-
stanje baze podatkov po izvedbi postopka
SPOROČILO je zaključena celota informacij, ki vstopa v postopek ali izstopa iz njega. Je predmet obdelave v postopku in je potrebno za njegovo izvedbo, ali pa je rezultat njegove izvedbe.
Sporočilo je koncept, ki omogoča modeliranje informacijskih tokov med:
-
postopki IS,
-
IS in njegovo okolico.
Glede na postopke so sporočila lahko vhodna ali izhodna. S stališča IS kot celote pa lahko ločimo sporočila še na interna in eksterna. Interna sporočila omogočajo komunikacijo med postopki IS, eksterna pa med IS in njegovo okolico.
ELEMENTARNI IN SESTAVLJENI POSTOPKI
Postopke lahko obravnavamo na različnih ravneh kompleksnosti. Večinoma so sestavljeni iz podpostopkov ali elementarnih postopkov. Postopke razstavljamo s pomočjo funkcijske dekompozicije, dokler ne pridemo do elementarnih postopkov.
elementarni postopek je najmanjša za uporabnika smiselna aktivnost, katere izvedba predstavlja zaključeno celoto in je opredeljena z vhodno/izhodnimi podatki ter izvedbenimi pravili (algoritmi). Do elementarnih postopkov pridemo tako, da jih razstavljamo s pomočjo funkcijske dekompozicije.
Elemetarni postopek je tisti postopek, ki predstavlja smiselno celoto in ga ni smiselno razstavljati naprej. Elementarne postopke moramo smiselno analizirati, da lahko v naslednjih fazah gradnje IS avtomatiziramo postopke.
3.3.2 METODE IN TEHNIKE MODELIRANJA POSTOPKOV
Za modeliranje postopkov uporabljamo različne grafične tehnike.
Metode in tehnike, ki jih podpira večina sodobnih CASE orodij so:
-
strukturni graf (structure chart)
-
diagram toka podatkov (data flow diagram)
-
prehodni graf (state transition diagram).
Za podrobnejši opis postopkov pa je potrebno še dvoje:
-
sistemska knjižnica,
-
specifikacija postopkov.
Dekompozicija sistema
Reševanje kompleksnih problemov je možno le tako, da jih postopoma razstavimo na manjše in manjše ter s tem tudi na preglednejše in obvladljivejše celote. Zaporedna uporaba te metode se imenuje funkcijska dekompozicija in nas pripelje do hierarhične strukture sistema, katerega zaključki vej predstavljajo elementarne dle sistema, ki jih je mogoče podrobno obravnavati.
Osnovni cilj je razstaviti sistem na elementarne postopke, ki predstavljajo logično zaključene celote, ki jim je mogoče določiti vhode, izhode in pravila njihovega izvajanja.
STRUKTURNI GRAF je drevesni (hierharični) graf. je temeljna tehnika s katero predstavimo strukturo posameznih procesov iz katere so razvidni vsi postopki, ki na nekem področju nastopajo in njihova medsebojna hierarhija. Strukturni graf nam predstavlja vse postopke, ki nam nastopajo na področju za katerega načrtujemo IS, ter njihove medsebojne povezave, strukturo oziroma njihovo hierarhijo. Do hierarhičnega grafa pridemo po metodi funkcijske dekompozicije.
funkcijska dekompozicija - je proces, postopek, pristop povečanja obravnavanega poslovnega sistema, pri čemer začnemo od zgoraj navzdol pri čemer razstavljamo celoten poslovni sistem (proces) na manjše in manjše dele, dokler ne pridemo do celot, ki jih ni več mogoče naprej sestaviti torej do elementarnih postopkov.
S
študijski informacijski
sistem 0.0
trukturni graf:
vpis študentov 1.0
spremljanje opravljenih
študijskih obveznosti
2.0
posredovanje
informacij 3.0
vpis študentov 2.1
objava rezultatov 2.2
evidentiranje opravljene
študijske obveznosti
2.3
ELEMENTARNI POSTOPKI – postopki, s katerimi se IS vzdržuje. Elementarni postopki so tisti, ki so na koncu posameznih vej strukturnega grafa. Predstavljajo zaključeno celoto medsebojno povezanih aktivnosti oziroma operacij, ki je ni mogoče in ki je ni smiselno razstavljati na manjše dele. Vsi postopki znotraj strukturnega grafa morajo biti enolično označeni. Ena od možnosti je, da postopek, ki je na vrhu označeno z 0.0 in potem naprej označujemo z: 1.0, 2.0, 3.0, .... Vsi postopki na koncu vej so elementarni.
DIAGRAM TOKA PODATKOV – je druga temeljna tehnika, s katero skušamo čimbolj podrobno predstaviti podatkovne oziroma informacijske tokove v okviru posameznega postopka oziroma procesa in pa med njimi. Je zelo razširjena tehnika, ki ni standardizirana. Gre za karakteristične simbole iz katerih se diagram sestoji.
Diagram toka podatkov omogoča prestavitev naslednjih elementov sistema:
-
postopkov
-
tokov podatkov
-
zbirk podatkov
-
zunanjih entitet
Postopek: Osnovna komponenta diagrama toka podatkov (DTP) je postopek, ki je običajno predstavljen s krogom ali ovalom. Pod postopkom razumemo del modeliranega sistema, ki izvaja neko aktivnost, s katero se transformira vhode v izhode. Vsak postopek ima svoje ime.
Višje v hierarhiji so postopki bolj sestavljeni (kompleksni) kot nižji v hierarhiji.
Vsi postopki, ki nastopajo na koncu vej so elementarni postopki, ki se bodo kasneje avtomatizirali (postopek, ki ni nadaljnje razstavljen je elementarni postopek). Vsi postopki so oštevilčeni.
Če želimo postopek razstaviti, ga moramo razstaviti na najmanj dva postopka.
Zbirka podatkov se uporablja za modeliranje podatkovnih zbirk, ki nam nastajajo v okviru modeliranega IS. Zbirka podatkov je preko podatkovnih tokov vedno povezana s procesi. Podatkovni tokovi, ki vodijo v zbirke podatkov, izstopajo iz postopkov. Tokovi ki vodijo iz zbirke podatkov pa vodijo v postopke. Torej iz tega sledi, da postopki niso povezani med seboj ampak so povezani preko zbirk podatkov. Zbirka podatkov je v diagramu toka podatkov predstavljena z dvema vzporednima črtama.
Zunanja entiteta: koncept zunanje entitete se bistveno razlikuje od koncepta entitete, ki smo ga doslej poznali. Z zunanjo entiteto skušamo predstaviti vse zunanje akterje, tako fizične kot pravne osebe, s katerimi naš načrtovani sistem komunicira. Pogosto so zunanje entitete s katerimi povzročajo dogodke, ki sprožijo postopke.
Od zunanjih entitet prihajajo vhodni podatki/dokumenti, vanje se pa stekajo izhodni podatki oziroma rezultati sistema. Zunanje entitete so ponavadi fizične ali pravne osebe s katerimi naš sistem komunicira in ki pogosto povzročijo izvajanje postopkov.
!!!! zunanje entitete ne smemo zamenjati z entiteto pri podatkovnem modelu!!!!!!
Tok podatkov: Podatkovni tokovi so v DTP predstavljeni s puščicami, ki so usmerjene v postopke ali pa iz njih. Pod tokom podatkov razumemo prenos oziroma potovanje podatkov/dokumentov med različnimi deli sistema. Mora imeti puščico, da se vidi smer v katerega dokumenti potujejo; če ima obe puščici podatki tečejo v obe smeri. Puščice torej predstavljajo sporočila, ki potekajo med postopki oziroma med postopkom in zunanjim svetom.
Informacijski tokovi med procesom in zunanjo entiteto so poimenovani, med procesom in zbirko podatkov pa niso poimenovani.
Slika osnovnih simbolov diagrama tokov podatkov:
Postopek,proces, aktivnost (ki se odvija v okviru IS katerega modeliramo)
Zunanja entiteta
Zbirka podatkov
Tok podatkov (kaže s puščicami kako so simboli povezani)
Slika diagrama tokov podatkov:
objava konference A1 referat
Javni mediji aktivnosti progr. recenzija Recenzent
odbora
prijava,
referat
podatki o Podatki o Podatki o
vabilo povabljencih referatih sekcijah
za
prijavo
zbirke podatkov
Potencialni prijava udeležbe A2
udeleženec vabilo za udeležbo Aktivnosti org. odbora
elementarni postopki
informacijski zunanje
tokovi entitete
PREHODNI DIAGRAM – se ne uporabljajo tako pogosto kot diagram toka podatkov. Prav nam pride kadar je pomembno vedeti v katerih obravnavanih sistemih se lahko sistem znajde. Predstavlja nam možna stanja OS in zaporedja njihovih postopkov. Medtem ko nam DTP omogoča modeliranje postopkov oziroma podatkovnih tokov med njimi, pa nam prehodni diagrami omogočajo modelirati obnašanje sistema v odvisnosti od časa in prikaz dovoljenih stanj, v katerih se sistem lahko znajde.
Prehodni diagrami postanejo zelo pomembni kadar želimo s pomočjo načrtovanega IS zagotavljati ne le vse potrebne informacije ampak želimo tudi vpeljati upravljanje postopkov.
Prehodni diagram kaže vsa možna stanja v katerih se lahko znajde določen sistem in prehode med temi stanji.
Slika prehodnega diagrama za sistem elektronske tajnice:
brez dela
čakanje na klic beleženje sporočil previjanje predvajanje sporočil
odgovarjanje
na klic
SISTEMSKA KNJIŽNICA je relativno nov pripomoček, ki se uvaja na področje zasnove in gradnje IS in predstavlja pravzaprav nadgradnjo že dolgo uveljavljenih podatkovnih slovarjev. Za razliko od slovarja podatkov, ki po definiciji vsebuje formalne opise podatkov, ki nastopajo v bazi podatkov IS, so funkcije sistemske knjižnice naslednje:
Funkcije sistemske knjižnice:
-
vzdrževanje vseh opisov podatkov, ki sestavljajo bazo podatkov sistema (katalog podatkov);
-
vzdrževanje vseh tekstovnih in grafičnih opisov poslovnih funkcij, sestavljenih in elementarnih postopkov, itd (opisi grafov);
-
vzdrževanje vseh opisov povezav med postopki in podatki;
-
vzdrževanje opisov vhodno-izhodnih mask in poročil.
-
Podrobno opredeljeni postopki (algoritem,dogodek, začetni in končni pogoj (slika spodaj)
Grafične tehnike predstavijo procese do neke mere, dokumentiramo pa te procese v sistemski knjižnici. Sistemska knjižnica naj bi omogočala sistematično vzdrževanje in vodenje vseh podatkov o IS.
Sistemska knjižnica ni samo orodje za podporo modeliranju postopkov, temveč univerzalno orodje za podporo celotnemu razvojnemu procesu IS.
začetni pogoj dogodek POSTOPEK (ALGORITEM) vhodno izhodno sporočilo sporočilo končni pogoj
Opredelitev postopkov:
Za podrobno opredelitev elementarnega postopka je potrebno opredeliti naslednje:
-
pravila njegovega izvajanja (algoritem)
-
dogodek, ki sproži izvajanje procesa
-
začetne pogoje
-
končne pogoje
-
specifikacijo vhodno izhodnih/sporočil
Razvoj postopkovnega modela
Primer:
Vpis na univerzo: -
VUŠ na podlagi prostih mest in na podlagi študijskih programov objavi predvpis v medijih.
-
Kandidati pošljejo na predvpis osebne podatke. Šola pošlje seznam kandidatov na Univerzo.
-
Univerza izdela izbor, ki ga pošlje šoli. Šola obvesti kandidate o izboru.
-
Kandidati pri vpisu predložijo obvestilo o izboru in zadnje spričevalo. Seznam vpisanih pošlje šola na Univerzo in Zavod za statistiko.
razpis Objava prosta študijska
MEDIJI predvpisa mesta
1.1
študijski programi
os. podatki predvpis KANDIDAT 1.2 evidenca kandidatov
seznam kandidatov
UNIVERZA
seznam izbranih obveščanje evidenca izbranih
kandidatov
obvestilo 1.3
evidenca zavrnjenih
seznam vpisanih
vpisovanje
obvestilo o izboru 1.4
zadnje srednješolsko spričevalo študentska evidenca
indeks
seznam vpisanih
STAT. URAD
Primer:
Poslovanje knjižnice
-
Občan se vpiše v knjižnico tako, da poda svoje osebne podatke. Prejme izkaznico.
-
Člani pregledujejo sezname knjig. Iščejo po avtorju, naslovu, zvrsti
-
Izbrane knjige si izposojajo in vračajo. Knjižnica vodi evidenco izposoje in vračil.
-
Knjižnica pošilja članom opomine.
osebni podatki vpisovanje v evidenca članov
OBČAN knjižnico
izkaznica 1.0
želja
seznam pregledovanje
evidence knjig evidenca knjig
izkaznica 2.0
seznam izposojanje evidenca in vračanje izposojenih knjig
3.0
opominjanje
opomin 4.0
poslovanje knjižnice
0.0
opominjanje 4.0
izposojanje/vračanje 3.0
pregledovanje evidence
knjig 2.0
vpis v knjižnico 1.0
vpisovanje os. podatkov 1.1
izdelovanje izkaznic 1.2
določanje datuma
4.1
tiskanje opominov 4.3
pošiljanje opominov 4.4
Analiza informacijskih potreb:
Tu opredelimo podatke, ki so potrebni za delovanje sistema.
Primer za knjižnico:
-
(prva informacijska potreba) – Osebni podatki: ime, priimek, pošta, rojstni datum, EMŠO
-
Evidenca članov: osebni podatki, št. izkaznice, datum vpisa, datum plačila članarine
-
Plačilo: št. izkaznice, znesek, namen, datum plačila, način plačila
-
Evidenca knjig: avtor, naslov, zvrst, leto izdaje, založba, št. strani, format, št. knjige, čas izposoje
-
Evidenca izposoje: št. knjige, št. izkaznice, datum izposoje
-
Izkaznica: št. izkaznice, ime, priimek, datum izdaje
-
Želja: avtor, zvrst, naslov
-
Seznam: št. knjige, avtor, naslov, nahajališče knjige
-
Opomin: znesek, rok. plačila, ime, priimek, naslov, razlog za plačilo, naslov knjige, avtor, datum izposoje, rok vrnitve
SEMINARSKA NALOGA (primer)
Namen:
-
praktična uporaba teorije
-
sposobnost sodelovanja z informatiki
-
osnovne gradnje in načrtovanja informacijskih sistemov
-
materializacija teorije organizacije, reinženiring
Trije pogledi na organizacijo:
-
hierarhični diagram
-
procesna razgradnja
-
strukturni diagram
-
diagram pretoka podatkov
-
podatkovna razgradnja
-
E/R diagram
-
slovar entitet, povezav
-
slovar atributov
Oblika seminarske naloge:
-
predstavitev sistema
-
Informacijske potrebe (popis dokumentov in kaj vsebujejo)
-
Hierarhični diagram (direktor, pomočnik direktorja …)
-
E/R model
-
slovar entitet, povezav in atributov
-
strukturni diagram
-
diagram toka podatkov
primer:
Predstavitev sistema nesreče s pobegom
-
policijski laboratorij preko analize ostankov nesreče ugotovi barvo, tip in letnik vozila
-
informacijski sistem poda seznam vozil te vrste
-
s preiskavo na terenu odkriti osumljenca
Organigram (diagram)
Narišeš strukturo MNZ
diagram toka podatkov:
-
je namenjen modeliranju postopkovnega dela IS
-
prikazuje dinamičnost IS in zaporedje izvajanja postopkov
-
o
glagol
mogoča predstavitev štirih elementov sistema:
-
postopek
-
zbirka podatkov
-
zunanja entiteta
-
tok podatkov
LABORATORIJ rezultati analize izdelovanje register vozil
seznama
1
samostalnik seznam potencialnih
vozil
preiskovanje
2
ORGANI PREGONA ovadba arhiv
Pogoste napake v DTP:
-
DTP ni organizacijska struktura
-
procesi morajo biti imenovani z glagolom, tokovi pa s samostalnikom
-
zunanje entitete ne smejo biti medsebojno povezane, enako velja za zbirko podatkov in procese
-
znanja entiteta mora biti povezana s procesom
-
vsak proces mora vsebovati vhodne in izhodne tokove
-
diagram ne sme biti prekinjen
-
zunanje entitete niso izvajalci samega postopka
strukturni graf:
-
je namenjen modeliranju postopkovnega dela IS
-
ne prikazuje dinamičnosti IS, temveč le hierarhično strukturo postopkov
-
vozlišča predstavljajo postopki obravnavanega IS
-
loki prikazujejo strukturo postopkov IS
-
do grafa pridemo s pomočjo funkcijske dekompozicije
-
dekompozicija pripelje do razmerja sestoji_iz med nadrejenim vozliščem in podrejenimi vozlišči
-
zaključki vej so elementarni postopki
obdelava nesreče
iskanje osumljenca
2.0
izdelovanje seznama
1.0
ogledovanje vozil
2.1
izdelava ovadbe
2.2
arhiviranje
2.3
3.4 PROBLEMI PREHODA IZ LOGIČNE NA FIZIČNO RAVEN MODELIRANJA IS
Najpomembnejša šibka točka pravzaprav vseh doslej znanih modelov je njihova omejena uporabnost skozi različne faze razvoja IS. Najostrejša je meja med logično ter fizično ravnijo modeliranja podatkov.
Modeli ki jih uporabljamo na logični ravni (danes je to predvsem model entiteta – povezava), niso direktno uporabni na izvedbeni ravni, saj trenutno še nimamo krmilnega sistema baze podatkov (KSBP), ki bi temeljil na E-R modelu. Velja pa tudi obratno, da modeli na katerih temeljijo današnji najbolj razširjeni komercialni produkti krmilnega sistema baze podatkov (relacijski, hierarhični ...), niso prikladni za modeliranje podatkov na logični ravni, saj ne omogočajo dovolj jasnega vpogleda v semantiko podatkov, ki nam nastopajo v okviru obravnavanega sistema.
Model ki ga naredimo v drugi fazi (slika stran 11.) to je logični model, je potrebno v nadaljevanju pretvoriti v fizični model. E-R model moramo pretvoriti v relacijski model in razviti bazo podatkov.
Pri razvoju konkretne baze podatkov smo zato običajno prej ali slej prisiljeni zapustiti udobje E-R modela in ta model pretvoriti v model, ki ga podpira izbrani krmilni sistem baze podatkov. Pri tem smo soočeni z dvema načeloma:
-
model podatkov, ki ga bomo dejansko izvedli s pomočjo izbranega krmilnega sistema baz podatkov, naj bi bil tak, da bo zagotavljal dolgoročno zadovoljevanje vseh informacijskih potreb uporabnikov in da ga bo potrebno čim manj spreminjati ne glede na vrsto uporabljene strojne in programske opreme (kriterij stabilnosti).
-
model podatkov, na osnovi katerega zgradimo konkretno bazo podatkov obravnavanega informacijskega sistema, mora zagotavljati čim bolj učinkovito delovanje baze podatkov (dodajanje novih podatkov, spreminjanje, iskanje ...); tu gre za kriterij učinkovitosti ali performančni kriterij
Prvo načelo upoštevamo tako, da postopno transformiramo naš logični model podatkov v fizični, to je izvedbeni model, na način, ki nas bo pripeljal do optimalnih ter čim bolj stabilnih podatkovnih struktur za izvedbeni model, ki ga podpira izbrani krmilni sistem baze podatkov. Temu postopku pravimo normalizacija.
NORMALIZACIJA
so postopki pretvorbe iz logične na fizično raven. Normalizacija poteka v treh korakih, od katerih nas vsak privede do normalne forme. Ko so podatki v tretji normalni formi, so direktno izvedljivi v relacijskem modelu. Problem pretvorbe iz logične na fizično raven je kardinalnost M:N, ki na logični ravni ni problematična, na fizični ravni pa moramo povezavo M:N spremeniti v povezavo 1:N.
Postopek normalizacije nas torej vodi skozi tako imenovane normalne forme.
Nenormalizirani podatki
Ko začnemo normalizirati podatke v okviru obravnavanega informacijskega sistema, nas v začetni fazi zanima predvsem opredelitev vseh pomembnejših tipov entitet in njihovih medsebojnih povezav. Ko govorimo o nenormaliziranih podatkih govorimo o podatkih v logičnem modelu, torej so podatki v logičnem modelu nenormalizirani podatki.
E-R model, ki je na logični ravni povsem sprejemljiv in razumljiv razvijalcem in uporabnikom, pa običajno direktno ni uporaben za konkretno izvedbo, denimo relacijske baze podatkov. Zato ga je potrebno normalizirati.
Normalizacijo podatkov lahko obravnavamo kot večfazni postopek, skozi katerega postopoma razstavljamo ter odpravljamo slabe relacije v enostavnejše, ki ustrezajo kriterijem normalizacije, dokler ne dobimo vseh relacij, ki ustrezajo pogojem tretje normalne forme. Osnovne korake postopka normalizacije prikazuje spodnja slika.
Shema postopka normalizacije
NENORMALIZIRANI PODATKI
1. izločitev vseh ponavljajočih se skupin atributov v samostojne relacije. (ko to opravimo pridemo v prvo normalno formo)
PRVA NORMALNA FORMA
2. V relacijah s sestavljenimi ključi je potrebno zagotoviti, da so vsi ostali atributi odvisni od celotnega ključa. (ko to opravimo pridemo v drugo normalno formo)
DRUGA NORMALNA FORMA
3. Odstraniti vse prehodne odvisnosti med atributi ter po potrebi oblikovati nove relacije. (ko to opravimo pridemo v tretjo formo)
TRETJA NORMALNA FORMA
Opis slike:
Izhajamo iz E-R modela, ki je nastal v fazi logičnega modeliranja podatkov in ki je običajno nenormaliziran. Vsak ti entitete nam v tej fazi predstavlja eno nenormalizirano relacijo.
V prvem koraku, ki nas pripelje do modela v prvi normalni formi (1NF), moramo odstraniti iz relacij tako imenovane ponavljajoče se skupine atributov ter z njimi tvoriti nove relacije.
V drugem koraku se osredotočimo na tiste relacije, katerih ključi so sestavljeni iz več atributov, in iz njih izločimo vse tiste atribute, ki niso odvisni od celotnega sestavljenega ključa relacije in z njimi ponovno oblikujemo nove relacije in s tem pripeljemo model v drugo normalno formo. (2NF)
V tretjem koraku pa odstranimo še tako imenovane prehodne ali tranzitivne odvisnosti med atributi in tudi tu po potrebi oblikujemo nove relacije in s tem pripeljemo model v tretjo normalno formo (3NF).
Funkcionalne odvisnosti
Za lažjo predstavitev druge in tretje normalne forme moramo na spregovoriti še o tako imenovanih funkcionalnih odvisnostih.
Funkcionalne odvisnosti se nanašajo na odvisnosti med vrednostmi posameznih atributov v relaciji, kar lahko opredelimo takole:
Vrednost atributa B v relaciji R je funkcionalno odvisna od vrednosti atributa A, če v vsakem trenutku pripada vsaki vrednosti atributa A ena sama vrednost atributa B. Rečemo lahko tudi, da A identificira B, kar pomeni, da če poznamo vrednost atributa A lahko vedno najdemo tudi pripadajočo vrednost atributa B. V slikah 3.37 – 3.39 so funkcionalne odvisnosti med atributi prikazane s puščicami. V relaciji NAROČILO je atribut Datum funkcionalno odvisen od atributa Šifra_naročila. Datum naročila bomo običajno iskali prek Šifre_naročila. Z vsako vrednostjo Šifre_naročila je povezana ena sama vrednost Datum_NAROČILA. Obratno pa seveda ne drži, saj preko vrednosti atributa Datum ni mogoče zanesljivo določiti vrednosti atributa Šifra_naročila, saj imamo lahko celo množico naročil, ki smo jih prejeli na isti datum. To pomeni da atribut Šifra_naročila ni funkcionalno odvisen od atributa Datum.
V normaliziranih relacijah zahtevamo, da so vsi atributi relacije funkcionalno odvisni od primarnega ključa.
Stvar se zaplete, kadar je primarni ključ sestavljen iz več atributov, to je primeru spetih ključev, zato sta v strokovni literaturi vpeljani tako imenovana popolna funkcionalna odvisnost in delna funkcionalna odvisnost. Popolna funkcionalna odvisnost pomeni, da so vrednosti atributa B v relaciji R popolno funkcionalno odvisne od sestavljenega ključa, ki se sestoji iz množice atributov A, niso pa popolno odvisne od podmnožice množice A.
Prva normalna forma:
Prva normalna forma prepoveduje večvrednostne atribute, sestavljene atribute ali njihove kombinacije. 1NF torej zahteva, da smejo domene atributov vsebovati samo atomarne vrednosti in da so vsi atributi v relaciji enovrednostni, to pomeni, da lahko zavzemajo eno samo vrednost.
Ponavljajočo se skupino atributov izločimo in dobimo novo relacijo, ki ima sestavljen ključ da je ohranjena povezava.
Primer:
Relacija NAROČILO (slika 3.37a) vsebuje skupino večvrednostnih atributov, kot so: Šifra_artikla, Naziv_artikla, Količina, Cena_artikla in Vrednost_artikla, saj lahko kupec z enim naročilom naroči veliko število različnih artiklov. Relacija NAROČILO ni v prvi normalni formi. Da bo ta relacija izponjevala kriterije prve normalne forme, je potrebno vse večvrednostne atribute izločiti in jih oblikovati v samostojne relacije, kar prikazuje slika 3.37b, kjer so izločeni atributi oblikovani v novo relacijo NAROČILO-ARTIKEL.
Primer je relacija NAROČILO-ARTIKEL na sliki 3.37b.
Atribut Vrednost_artikla je polno funkcionalno odvisen od sestavljenega ključa Šifra_naročila + Šifra_artikla, saj lahko iz vrednosti sestavljenega ključa vedno določimo tudi vrednost atributa Vrednost_artikla, delni ključ pa za to ne zadošča.
Za atribut Cena_artikla pa velja le delna funkcionalna odvisnost, saj za določitev njegovih vrednost zadošča že delni ključ, to je Šifra_artikla.
slika 3.37
a. Nenormalizirana relacija
NAROČILO
Šifra
naroč.
|
Datum
|
Šifra kupca
|
Naziv kupca
|
Naslov kupca
|
Šifra artikla
|
Naziv artikla
|
Količina
|
Cena artikla
|
Vrednost artikla
|
Vrednost naročila
|
b. pretvorba v prvo normalno formo
N
funkcionalne odvisnosti
AROČILO
Šifra naročila.
|
Datum
|
Šifra kupca
|
Naziv kupca
|
Naslov kupca
|
Vrednost naročila
|
1. Ponavljajoče skupine atributov so odstranjene ter oblikovane v samostojne relacije
ključ
NAROČILO-ARTIKEL
Šifra naročila
|
Šifra artikla
|
Naziv artikla
|
Cena artikla
|
Količina
|
Vrednost artikla
|
sestavljen ključ
Druga normalna forma:
zahteva, da so vsi atributi relacije R (ki niso ključi) popolnoma funkcionalno odvisni od celotnega primarnega ključa relacije, ne glede na to , ali je le ta sestavljen iz enega ali več atributov.
Pretvorbo opravimo tako, da so vsi atributi odvisni le od celotnega primarnega ključa.
Primer:
Glede na to zahtevo relacija NAROČILO-ARTIKEL na sliki 3.37b ni v drugi normalni formi in jo je potrebno razstaviti na dve relaciji NAROČILO-ARTIKEL in ARTIKEL, kakor je to prikazano na sliki 3.38. Relacije na sliki 3.38 so torej v drugi normalni formi, saj so atributi v vseh relacijah funkcionalno odvisni od celotnega ključa relacije.
slika 3.38
pretvorba v drugo normalno formo
NAROČILO
Šifra naročila.
|
Datum
|
Šifra kupca
|
Naziv kupca
|
Naslov kupca
|
Vrednost naročila
|
NAROČILO-ARTIKEL
Šifra naročila
|
Šifra artikla
|
Naziv artikla
|
Vrednost artikla
|
A
2. Vsi atributi, ki niso bili odvisni od celotnega ključa, kot je bil primer pri relaciji NAROČILO-ARTIKEL so bili preneseni v samostojno relacijo artikel
RTIKEL
Šifra artikla
Naziv artikla
Cena artikla
Tretja normalna forma:
temelji na konceptu prehodnih ali tranzitivnih odvisnosti. Relacije, ki so v 3NF imajo lahko še vedno določene anomalije. Lahko vsebujejo atribute, ki niso ključi ali njihovi deli, pa vendar sami zase identificirajo druge atribute, kar imenujemo prehodna ali tranzitivna odvisnost. Tranzitivne odvisnosti lahko povzročajo probleme pri uporabi baze podatkov, zato jih je potrebno odstraniti iz relacij.
Pri pretvorbi v tretjo normalno formo na koncu med atributi ne sme biti medsebojne odvisnosti. Atribut mora biti odvisen le od primarnega ključa in ne od drugega atributa.
Primer:
Pri relaciji NAROČILO iz slike 3.39 si podrobneje oglejmo funkcionalne odvisnosti. Atributa Naziv_kupca in Naslov_kupca sta funkcionalno odvisna od Šifre_kupca in tranzitivno odvisna od primarnega ključa Šifra_naročila. Tej tranzitivni odvisnosti se izognemo tako, da skupino atributov izločimo in oblikujemo novo relacijo KUPEC.
Rezultat celotnega procesa normalizacije je torej model, prikazan na sliki 3.40, kjer so vse relacije v tretji normalni formi. Tak model je mogoče direktno izvesti s poljubnim krmilnim sistemom baz podatkov, ki temelji na relacijskem modelu.
slika 3.39
PRETVORBA V TRETJO NORMALNO FORMO
NAROČILO
Šifra naročila
Vrednost naročila
Šifra kupca
Datum
KUPEC
Naslov kupca
Naziv kupca
Šifra kupca
NAROČILO-ARTIKEL
Vrednost artikla
Količina
Šifra artikla
Šifra naročila
3. Vsi atributi, ki so bili odvisni od drugih atributov (ki niso ključi), kot je bil to primer pri relaciji NAROČILO, so odstranjeni ter oblikovani v samostojne relacije
ARTIKEL
Cena artikla
Naziv artikla
Šifra artikla
TEHNOLOŠKA, ORGANIZACIJSKA IN KADROVSKA IZHODIŠČA (5. Poglavje)
Dostları ilə paylaş: |