Informacijski sistemi

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:

1. 
   katera vhodna sporočila morajo biti dana, da se izvajanje postopka lahko začne
   
2. 
   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:

1. 
   izhodna sporočila, ki morajo nastati kot rezultat izvedbe postopka
   
2. 
   razmerja med vrednostmi atributov entitet, ki jih vsebujejo izhodna sporočila
   
3. 
   vrednosti atributov entitet, shranjenih v bazi podatkov po izvedbi postopka
   
4. 
   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:

1. 
   postopkov
   
2. 
   tokov podatkov
   
3. 
   zbirk podatkov
   
4. 
   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:

1. 
   pravila njegovega izvajanja (algoritem)
   
2. 
   dogodek, ki sproži izvajanje procesa
   
3. 
   začetne pogoje
   
4. 
   končne pogoje
   
5. 
   specifikacijo vhodno izhodnih/sporočil
   

Razvoj postopkovnega modela

Primer:

Vpis na univerzo:

1. 
   VUŠ na podlagi prostih mest in na podlagi študijskih programov objavi predvpis v medijih.
   
2. 
   Kandidati pošljejo na predvpis osebne podatke. Šola pošlje seznam kandidatov na Univerzo.
   
3. 
   Univerza izdela izbor, ki ga pošlje šoli. Šola obvesti kandidate o izboru.
   
4. 
   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

1. 
   Občan se vpiše v knjižnico tako, da poda svoje osebne podatke. Prejme izkaznico.
   
2. 
   Člani pregledujejo sezname knjig. Iščejo po avtorju, naslovu, zvrsti
   
3. 
   Izbrane knjige si izposojajo in vračajo. Knjižnica vodi evidenco izposoje in vračil.
   
4. 
   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:

1. 
   (prva informacijska potreba) – Osebni podatki: ime, priimek, pošta, rojstni datum, EMŠO
   
2. 
   Evidenca članov: osebni podatki, št. izkaznice, datum vpisa, datum plačila članarine
   
3. 
   Plačilo: št. izkaznice, znesek, namen, datum plačila, način plačila
   
4. 
   Evidenca knjig: avtor, naslov, zvrst, leto izdaje, založba, št. strani, format, št. knjige, čas izposoje
   
5. 
   Evidenca izposoje: št. knjige, št. izkaznice, datum izposoje
   
6. 
   Izkaznica: št. izkaznice, ime, priimek, datum izdaje
   
7. 
   Želja: avtor, zvrst, naslov
   
8. 
   Seznam: št. knjige, avtor, naslov, nahajališče knjige
   
9. 
   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:

1. 
   predstavitev sistema
   
2. 
   Informacijske potrebe (popis dokumentov in kaj vsebujejo)
   
3. 
   Hierarhični diagram (direktor, pomočnik direktorja …)
   
4. 
   E/R model
   
5. 
   slovar entitet, povezav in atributov
   
6. 
   strukturni diagram
   
7. 
   diagram toka podatkov
   

primer:

Predstavitev sistema nesreče s pobegom

1. 
   policijski laboratorij preko analize ostankov nesreče ugotovi barvo, tip in letnik vozila
   
2. 
   informacijski sistem poda seznam vozil te vrste
   
3. 
   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:

1. 
   DTP ni organizacijska struktura
   
2. 
   procesi morajo biti imenovani z glagolom, tokovi pa s samostalnikom
   
3. 
   zunanje entitete ne smejo biti medsebojno povezane, enako velja za zbirko podatkov in procese
   
4. 
   znanja entiteta mora biti povezana s procesom
   
5. 
   vsak proces mora vsebovati vhodne in izhodne tokove
   
6. 
   diagram ne sme biti prekinjen
   
7. 
   zunanje entitete niso izvajalci samega postopka
   

strukturni graf:

1. 
   je namenjen modeliranju postopkovnega dela IS
   
2. 
   ne prikazuje dinamičnosti IS, temveč le hierarhično strukturo postopkov
   
3. 
   vozlišča predstavljajo postopki obravnavanega IS
   
4. 
   loki prikazujejo strukturo postopkov IS
   
5. 
   do grafa pridemo s pomočjo funkcijske dekompozicije
   
6. 
   dekompozicija pripelje do razmerja sestoji_iz med nadrejenim vozliščem in podrejenimi vozlišči
   
7. 
   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:

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