Professional Documents
Culture Documents
Sinonimi za digitalnu ekonomiju (digital economy) su Internet ekonomija (Internet economy), nova
ekonomija (new economy) ili Web ekonomija (Web economy).
Infrastruktura za e-business je tzv. Network Computing, koji povezuje računare i druge elektronske
uređaje putem telekomunikaiconih mreža.
Ovi računari mogu biti povezani na globalno mrežno okruženje, poznato kao Internet, ili povezani
lokalno unutar organizacije, tzv. Intranet. Mnoge kompanije povezuju svoj Intranet sa nekim od
poslovnih partnera putem mreže koja se zove Extranet.
Internet koncept
Internet je globalna kolekcija mreža koje povezuju računare korisnika širom sveta.
Internet je globalna mreža računara/računarskih mreža koji komuniciraju i razmenjuju podatke putem
TCP/IP protokola obezbeđujući nekoliko usluga tzv. Web servisa.
Internet obezbeđuje univerzalnu vezu sa računarima, nezavisno od toga na koju pojedinačnu mrežu su
oni priključeni.
Intranet koji je parcijalno dostupan autorizovanim korisnicima putem Interneta ili drugim sredstvima
naziva se Extranet.
Postavljanjem extraneta kroz Internet je mnogo lakše i ekonomičnije nego postavljanje iznajmljenog
komunikacionog linka između dve kompanije.
Međutim, extranet je manje bezbedan neko privatni Intranet zato što dozvoljava mogući pristup
neautorizovanim korisnicima.
Nova ekonomija vs. stara ekonomija
Značajne promene u bilo kojim od ovih faktora dovodi do stvaranja poslovnog “pritiska” na
organizaciju.
Postoje tri tipa poslovnog pritiska sa kojima se organizacija suočava i to pritisci tržišta, tehnologije i
društva:
Tržišni pritisak:
Globalna ekonomija i jaka konkurencija
Promena prirode radne snage
Moćni klijenti...
Tehnološki pritisak:
Tehnološke inovacije i zastarelost
Suviše informacija...
Socijalni pritisak:
Regulacija (Statuti, uređenje, propisi) Vlade
Trošenje na socijalne programe
Zaštita od terorističkih napada
Etnička pitanja...
IT podrška organizaciji
Organizacija čini veliki napor kako bi stekla nove i sačuvala postojeće klijente, a to čini najčešće
koristeći informacione tehnologije.
Strategijski informacioni sistemi
Šta podrazumevamo pod strategijskim korišćenjem informacionih sistema? Informacioni sistemi su
strategijski ukoliko ispunjavaju ciljeve i strategiju poslovanja i ukoliko imaju uticaja na celokupno
poslovanje preduzeća.
Strategic Information Systems (SISs) – sistemi koji pomažu organizaciji da stekne konkurentnu
prednost kroz doprinos strategijskim ciljevima organizacije i/ili njenoj sposobnosti da znatno poveća
svoje performanse i produktivnost.
Konkurentna prednost je prednost u odnosu na konkurenciju u pogledu troškova, kvaliteta ili brzine
koja vodi ka kontroli tržišta i povećanju profita.
Glavne osobine informacionog sistema
Izvršavaju veoma brzo velika numerička izračunavanja.
Povećavaju efektivnost i efikasnost ljudi koji rade u grupama na jednom mestu ili na nekoliko
lokacija, bilo gde.
IT infrastruktura uključuje ove resurse kao i njihovu integraciju, operaciju, dokumentaciju, održavanje
i menadžment.
Životni ciklus razvoja sistema
(system development life cycle - SDLC)
SDLC - struktuirani okvir koji se koristi za velike IT projekte koji se sastoje od sekvencionalnih procesa po
kojima se razvijaju informacioni sistemi
INFORMACIONI SISTEMI
Uvod:
• Informacija je postala upravljački resurs, pored sirovina, energije, rada i kapitala.
Informacioni sistem
• Sistem u kome se veze između objekata i veze sistema sa okolinom ostvaruju razmenom informacija.
Računarska aplikacija
• Računarski zasnovano rešenje jednog ili više poslovnih problema i donošenja odluka.
• Jedan informacioni sistem u sebi sadrži jednu ili više računarskih aplikacija.
Uloga sistem analitičara
• Proučavaju poslovne probleme i mogućnosti, prevode poslovne i informacione zahteve u računarski
zasnovane IS i rač. aplikacije koje potom bivaju implementirane od strane tehničkih stručnjaka.
• Može odgovoriti na poslovnu transakciju (porudžbina, plaćanje i dr.) i/ili inicirati transakciju (računi,
čekovi, potvrde o uplati i dr.)
Menadžment IS
• Dopunjuju TPS sa menadžerskim izveštajima neophodnih za planiranje, nadgledanje i upravljanje
poslovnim operacijama.
• DSS podržava nestruktuirane odluke, odnosno situacije koje se ne mogu unapred predvideti i
strukturalno postaviti.
Ekspertni sistemi
• Aplikacija IS koja prikuplja znanje i stručnost onih koji se bave rešavanjem problema ili donošenjem
odluka, a zatim simulira razmišljanje tog eksperta.
• ES zahteva podatke i informacije kao i svaki IS, ali su jedinstveni u svojim zahtevima za pravilima
koje simuliraju zaključivanje eksperta koji koristi podatke i informacije.
Kancelarijski IS
• engl. Office Information Systems
• Podržavaju veliki obim poslovnih kancelarijskih aktivnosti koji poboljšavaju posao i komunikaciju
između radnika
Nosioci IS - Stakeholders
• Vlasnici sistema (System Owners) – finansiraju razvoj i održavanje informacionog sistema. Oni
poseduju sistem, postavljaju prioritete u sistemu i određuju politiku za njegovo korišćenje. U nekim
slučajevima, vlasnici sistema mogu biti i korisnici sistema.
• Korisnici sistema (System Users) su ljudi koji za obavljanje svojih poslova, koriste informacioni
sistem. Danas korisnici sistema rade rame uz rame sa projektantima sistema.
• Projektanti sistema (System Designers) projektuju sistem kako bi izašli u susret zahtevima korisnika.
Oni projektuju baze podataka, ekrane, mreže i programe. U nekim slučajevima, projektanti sistema
mogu biti i graditelji sistema.
• Graditelji sistema (System Builders) su tehnička lica koja konstruišu, testiraju i isporučuju sistem.
Fokusi sistema
• PODACI – sirov materijal koji se koristi za kreiranje informacija.
• Blokovi informacionog sistema ne egzistiraju izolovano, već moraju biti sinhronizovani kako bi se
izbegle nedoslednosti i nekompatibilnosti unutar sistema.
CASE alati su programi (softveri) koji automatizuju i podržavaju jednu ili više faza životnog ciklusa
razvoja sistema.
Namera ove tehnologije jeste da ubrza procese razvijanja sistema i poboljša njegov kvalitet.
Neki ovu tehnologiju nazivaju kao softverski inženjering pomoću računara (computer-aided software
engineering), međutim treba imati u vidu da je softver samo jedna komponenta informacionog
sistema, pa se stoga ovde koristi širi pojam sistem.
Sistemska analiza
• Sistemska analiza je najkritičnija faza jednog projekta.
• Tokom sistemske analize treba da se shvate problemi konkretnog poslovnog sistema, definišu ciljevi
za njegovo poboljšanje i definišu detaljni poslovni zahtevi, koje mora da ispuni bilo koje tehničko
rešenje.
• U okviru sistemske analize obavlja se (1) pregled sistema i planiranje projekta, (2) proučavanje i
analiza postojećih poslovnih i informacionih sistema i (3) definisanje poslovnih zahteva i prioriteta za
novi ili poboljšani sistem.
Faze sistemske analize
• Sagledavanja projekta
– "Da li je projekat vredan pažnje?".
– Definisati cilj projekta, probleme, mogućnosti i direktive koje aktiviraju projekat.
– Određuje se projektni tim, učesnici, budžet projekta i raspored projekta.
– Sistem analitičar zajedno sa vlasnicima i korisnicima sistema, menadžerom za IS i drugim
osobljem IS (1) sagledavaju probleme, mogućnosti i rešenja, (b) ugovoraju oblast projekta, (c)
planiraju projekat i (d) prezentiraju projekat. Upravni odbor utvrđuje prioritete projekata IS.
• Faze proučavanja
– Sistem analitičar i odgovarajući učesnici će: (a) modelirati tekući sistem, (b) analizirati
poslovne procese, (c) analizirati probleme i mogućnosti, (d) utvrditi ciljeve i ograničenja
poboljšanja sistema, (e) modifikovati oblast projekta i plana i (f) prezentirati zaključke i
preporuke.
• Faza definisanja
– identifikuje šta novi sistem treba da radi ne uzimajući u obzir potrebnu tehnologiju, drugim
rećima, cilj je da se definišu poslovni zahtevi novog sistema.
– U okviru ove faze, sistem analitičar i odgovarajući učesnici će (a) grubo nacrtati poslovne
zahteve, (b) modelirati zahteve poslovnog sistema, (c) izgraditi prototipove, (d) dati prioritete
zahtevima poslovnog sistema i (e) modifikovati plan i oblast projekta.
Model
• Model je prikaz stvarnosti. Kao što slika vredi hiljadu reči, tako i većina sistemskih modela
predstavljaju slikovite predstave stvarnosti.
• Modeli služe da bolje razumemo sisteme ili je to način da dokumentujemo poslovne zahteve ili da
postavimo tehnički dizajn.
• Logički modeli pokazuju šta je sistem i šta on radi. Oni opisuju sistem nezavisno od bilo koje
tehničke implementacije.
• Fizički modeli pokazuju ne samo šta je sistem i šta on radi, već i kako je sistem fizički i tehnički
implementiran.
Modeliranje i tehnike
• Modeliranje je projektovanje softverskih aplikacija pre njihovog kodiranja odnosno programiranja.
• Modeliranje procesa je tehnika koja se dosta praktikuje za izražavanje zahteva poslovnih procesa,
tokova procesa, ulaza i izlaza.
• Modeliranje mreže je tehnika koja pomaže kompaniji da izrazi geografiju poslovanja koja će biti
podržana od strane sistema.
Sistemski modeli
• Kostur informacionih sistema identifikuje potrebu za četiri sistemska modela:
– PODACI – Svi sistemi sakupljaju i skladište podatke. Modeli podataka (npr. dijagram
objekti-veze) se koriste da modeliraju neophodne podatke za nove sisteme. Ovi modeli
podataka su polazna tačka za projektovanje baze podataka.
– PROCESI – Modeli procesa (npr. Dijagram toka podataka) se često koriste da modeliraju
tokove procesa kroz poslovne sisteme. Ovi modeli procesa služe kao polazna tačka za
projektovanje računarskih aplikacija i programa.
– INTERFEJSI – Nijedan sistem ne ekzistira izolovano od drugih ljudi, drugih sistema ili drugih
kompanija. Interfejs modeli se crtaju u fazi proučavanja, ali detaljnije se moraju prikazati u
fazi definisanja. Interfejs modeli opisuju ulaze (inpute) u sistem, njihove izvore, izlaze
(autpute) iz sistema, njihove destinacije i deljene baze podataka. Ovi interfejs modeli služe
kao osnova za dizajniranje korisničkih i sistemskih interfejsa.
MODELI PODATAKA
• Objekat je nešto što se može videti, dodirnuti ili drugačije osetiti, koji ima svoja svojstva i ponašanja
i o kome korisnici mogu da skladište podatke.
• Tipovi objekata se mogu klasifikovati u osobe, mesta, stvari ili događaje. U okviru tipa objekta osobe
mogu se svrstati radnici, klijenti, prodavci, studenti i dr. Skladišta, zgrade, sobe su primeri tipa
objekata mesta. Primeri tipa objekata stvari uključuju proizvod, vozilo, opremu, videotraku i dr. Na
kraju objekti događaja uključuju porudžbinu, plaćanje, račun, aplikaciju, registraciju ili rezervaciju.
• Tip podatka definiše koja klasa podataka može biti skladištena u taj atribut.
• Difoltna vrednost je ona vrednost koja će biti uskladištena za dati atribut ukoliko je korisnik ne
promeni.
• Svaki objekat mora da ima jedinstveni ključ po kome će se pretraživati u bazi podataka. Osnovna
svrha ključa jeste da jedinstveno identifikuje svaki objekat.
• Objekat može imati više od jednog ključa. Na primer, objekat RADNIK se može jedinstveno
identifikovati preko matičnog ličnog broja ili preko šifre zaposlenog ili preko e-mail adrese. Svaki od
ovih atributa se nazivaju kandidati za ključ. Kandidati za ključ su kandidati za primarni ključ.
• Primarni ključ (PRIMARY KEY) je kandidat za ključ koji će se najčešće koristiti da jedinstveno
identifikuje dati objekat. Svi drugi kandidati za ključ koji nisu izabrani za primarni ključ se zovu
alternativni ključevi.
• Difoltna vrednost primarnog ključa je NOT NULL, odnosno ključ ne sme da bude prazno polje, jer
onda neće moći da jedinstveno identifikuje dati objekat.
• Objekti ne ekzistiraju sami već moraju biti u nekoj relaciji ili vezi sa drugim objektima.
• Agregacija istovremeno predstavlja i objekat i vezu, odnosno udruženi objekat (associative entity),
između dva ili više objekta.
• Kardinalnost definiše minimalni i maksimalni broj događaja jednog objekta koji se nalazi u
konkretnoj relaciji sa drugim objektom. Pošto su sve relacije dvosmerne, kardinalnost se mora
definisati za oba smera.
• Postoje nekoliko notacija modela podataka. Neka su imenovana po njihovim pronalazačima, kao što
su Chen, Martin, Bachman, Merise ili po objavljenom standardu IDEF1X, UML i dr.
• Generalizacija je tehnika gde se objekti sa zajedničkim atributima, vezama i/ili operacijama, grupišu
(generalizuju) u jedan objekat koji se zove nadtip. Inverzni postupak, gde se za neki tip objekta,
definišu njegovi podtipovi, koji imaju neke njima specifične atribute, veze i/ili operacije, je
specijalizacija.
MODELIRANJE PROCESA
• Dijagram toka podataka (DTP) je alat koji opisuje tokove podataka kroz sistem i procese koji se
izvršavaju u sistemu. Sadrži četiri osnovne komponente:
– procese (processes) obrade podataka, koji predstavljaju aktivne komponente sistema (grafički
simbol: krug);
– spoljne objekte ili spoljne agente (external agents) sa kojima sistem komunicira (grafički
simbol: pravougaonik);
– skladišta podataka (data stores) koje procesi koriste i/ili ažuriraju (grafički simbol: dve
paralelne linije) i
– tokove podataka (data flows) koji povezuju ostale komponente sistema u celinu (grafički
simbol: usmerena linija).
Osnovne komponente DTP-a
CRUD matrice
• Kvalitet sinhronizacije podrazumeva da svaki objekat treba da ima najmanje jedno kreiranje (C –
create), jedno iščitavanje (R – read), jedno menjanje ili modifikovanje (U – update) i jedno brisanje
(D – delete) da bi sistem bio kompletan.
• CRUD matrice dokumentuju ove zahteve i sinhronizuju modele podataka, procesa i mreža.
Faze projektovanja IS
• Faza konfiguracije:
Baza podataka
• Baza podataka (BP) je kolekcija međusobno povezanih podataka, uskladištenih sa minimumom
redudanse, koje koriste, zajednički, svi procesi obrade u sistemu.
• Sistem za upravljanje bazom podataka je jedan složeni softverski sistem koji treba da omogući:
– Skladištenje podataka sa minimumom redudanse.
– Korišćenje zajedničkih podataka od strane svih ovlašćenih korisnika.
– Logičku i fizičku nezavisnost programa od podataka. Bez obzira što se podaci fizički pamte,
po pravilu, samo jednom, u jedinstvenoj fizičkog organizaciji, svaki korisnik dobija svoju
sopstvenu logičku sliku podataka kakva njemu najviše odgovara.
– Jednostavno komuniciranje sa bazom podataka preko jezika bliskih korisniku, kako bi se
neprofesionalni korisnici neposredno uključili u razvoj informacionog sistema, a
profesionalnim programerima značajno povećala produktivnost.
Jezici DBMS-a
• Data Definition Language (DDL) se koristi za izradu rečnika podataka, inicijalizaciju ili kreiranje
baze podataka, opisivanje logičkog pogleda za svakog individualnog korisnika ili programera i
specifiranje bilo kog ograničenja nad poljima ili tabelama baze podataka.
• Data Manipulation Language (DML) se koristi za održavanje podataka, koja uključuje takve
operacije koje ažuriraju, ubacuju i brišu delove baza podataka.
• Data Query Language (DQL) se koristi za ispitivanje baze podataka. S obzirom na činjenicu da se
DML koristi da menja sadržaj baze podataka, DQL samo sortira, uređuje, skladišti i predstavlja
podskupove baze podataka prema odzivu na korisničke upite.
• Mnogi DBMS takođe uključuju i jezik za pisanje izveštaja, koji pojednostavljuje kreiranje izveštaja.
Standardni upitni jezik koji omogućava komunikaciju sa bazom podataka jeste SQL (od početnih
slova engleskih reči: Structured Query Language).
Relacioni DBMS
• Postoji nekoliko tipova sistema za upravljanje bazom podataka. Ono se mogu klasifikovati prema
načinu struktuiranja zapisa. Prethodni sistemi za upravljanje bazom podataka su organizovali zapise u
hijerarhije i mreže implementiranih sa indeksima i povezanim listama.
Relacioni model
• Relacioni model poseduje semantički bogatije koncepte za opis strukture i znatno moćnije operacije.
• Tabela se može definisati kao matematička relacija i zatim iskoristiti bogata teorijska osnova
odgovarajućeg matematičkog aparata.
• Svaka relacija ima svojstva skupa. (Osnovno svojstvo svakog skupa je da se elementi koje on sadrži
međusobno razlikuju. Tako se i svi redovi tabele međusobno razlikuju.)
• Pošto je relacija skup, a svaka tabela nije, definišu se sledeći uslovi koje tabela mora da zadovolji da
bi bila relacija:
– Ne postoje duplikati vrsta tabele.
– Redosled vrsta i redosled kolona nije značajan.
– Nisu dozvoljni atributi ili grupe atributa sa ponavljanjem, odnosno nisu dozvoljene tabele u
tabeli.
Teoretske postavke relacionih modela
• Tabela se može definisati kao matematička relacija i nad njom razmatrati sledeće:
• Relacija se definiše kao podskup Dekartovog proizvoda nad n-skupova R D1 x D2 x ...x Dn, tj.
podskup sadrži one n-torke Dekartovog proizvoda koje zadovoljavaju zadatu relaciju.
Primer: Definisati za prethodni primer nad skupovima D1 i D2 relaciju:
R: D1 x D2 ={ <d1,d2> | d1 = d2/2}
R = {<2,4>, <3,6>}.
Ključevi
• Ključevi se definišu kao jedan ili više atributa čija vrednost jedinstveno identifikuje jednu n-torku u
relaciji, tj. jedan red u tabeli.
• Ako je ključ definisan samo jednim atributom, onda je to prost ključ, odnosno ukoliko je definisan sa
više atributa, onda je to složeni ključ.
• Ako se definiše relacija R, onda se može reći da ključ relacije R predstavlja kolekcija K njenih
atributa koja zadovoljava :
– osobinu jedinstvenosti i
– osobinu neredundantnosti.
• Osobina jedinstvenosti je vezana za ograničenje da ne postoje bilo koje dve n-torke sa istom
vrednošću K.
• Osobina neredundantnosti se odnosi na gubljenje osobina jedinstvenosti ako se bilo koji atribut
izostavi iz K.
• U jednoj relaciji može postojati više različitih kolekcija K atributa koje zadovoljavaju definiciju
ključa - sve se one nazivaju kandidati za ključ.
• Primarni ključ je jedan od izabranih kandidata za ključ koji služi za identifikaciju n-torke relacije.
Ostali kandidati za ključ postaju alternativni ključevi.
• Atributi koji učestvuju u ključevima nazivaju se ključni atributi, dok se ostali nazivaju opisni atributi.
• Spoljni ključ ili preneseni ključ je atribut ili grupa atributa u relaciji R, čija se vrednost koristi za
povezivanje sa vrednošću primarnog ključa u nekoj relaciji R2.
• Spoljni ključevi i njima odgovarajući primarni ključevi definisani su nad istim domenom.
• Spoljni ključevi služe da se uspostave veze između relacija u relacionoj bazi podataka. Na primer, u
relaciji RADNIK spoljni ključ SIFRAODEL vezuje sa relacijom ODELJENJE.
Operacije relacionog modela
• Postoje dva opšta načina iskazivanja operacija relacionog modela:
– Relaciona algebra u kojoj se definiše skup operacija pomoću kojih je moguće dobiti željenu
relaciju iz skupa datih relacija;
– Relacioni račun koji predstavlja neproceduralan način iskazivanja operacija, gde se pomoću
konstrukcija predikatskog računa prvog reda definišu osobine relacije koja se želi dobiti.
Relaciona algebra
• Relaciona algebra definiše skup operacija pomoću kojih se, na proceduralan način, može dobiti
željena relacija, tj.tabela iz skupa datih relacija.
• Relacija se definiše kao podskup Dekartovog proizvoda i može se tretirati kao skup n-torki.
• Za nivo relacione algebre operacije: unija, presek i diferencije nad relacijama R1 i R2 moraju
zadovoljiti uslov kompatibilnosti, tj. relacije R1 i R2 moraju imati isti broj atributa (isti stepen), a
odgovarajući atributi su definisani nad istim domenom.
– Primer:
• Definišimo relaciju NovoOdel (OdeID, NazivOdel)
Odel4, Razvoj
Odel5, Skladište
• Relacija RR=Odel U NovoOdel (OdeID, NazivOdel)
Odel1, Proizvodnja
Odel2, Računovodstvo
Odel3, Marketing
Odel4, Razvoj
Odel5, Skladište
• Diferencija
– Ako su date relacije R1 i R2 koje zadovoljavaju uslov kompatibilnosti, onda rezultat operacije
diferencije R3 = R1 - R2 predstavljaju n-torke relacije R1, koje nisu istovremeno i n-torke
relacije R2.
– Primer:
• RRR = RR – Odel (OdeID, NazivOdel)
Odel4, Razvoj
Odel5, Skladište
• Presek
– Operacijom unije se mogu u neku relaciju dodati nove n-torke, a operacijom diferencije se
mogu iz neke relacije izbaciti neželjene n-torke.
– Izmena vrednosti pojedinih atributa u nekoj relaciji vrši se uzastopnom primenom operacije
diferencije, pomoću koje se izbaci cela n-torka u kojoj se nalazi posmatrani atribut, a zatim se
operacijom unije "vraća" izbačena n-torka sa promenjenom vrednošću atributa.
• Dekartov proizvod
– Može se primeniti na bilo koje dve relacije.
– Rezultat operacije R3 = R1 x R2 je relacija R3 čije su n-torke svi "parovi" koje čine jedna n-
torka relacije R1 i jedna n-torka relacije R2.
• Projekcija
– Unarna operacija koja iz neke relacije selektuje skup navedenih atrubuta, odnosno "vadi"
vertikalni podskup iz odgovarajuće tabele.
– Operacijom projekcija eliminišu se duplikati n-torki.
– Primer:
• R1 A B Građanin (MLB, Ime, Starost, MestoRođ)
a b 1111 Ana 19 Beograd
a ? 2222 Mirko 21 Valjevo
? b 3333 Zoran 20 Beograd
? ? 4444 Ana 19 Niš
5555 Mirko 21 Beograd
• P[A]R1 A Pr1:=π Ime, Starost (Građanin)
a Ime Starost
? Ana 19
Mirko 21
Zoran 20
• Selekcija
– unarna operacija koja iz date relacije selektuje n-torke koje zadovoljavaju zadati uslov ( "vadi"
horizontalni podskup tabele).
– Primeri:
• S[A=a]R1 AB
ab
a?
– binarna operacija koja spaja dve relacije na taj način da se u rezultatu pojavljuju oni parovi n-
torki jedne i druge relacije koji zadovoljavaju uslov zadat nad njihovim atributima.
– Primer:
Student (BrInd, MLB, Smer)
155/01 1111 Kompjuterski
255/02 2222 Izvršno upravljanje
322/01 3333 Međunarodno poslovanje
– Primer:
• Iz relacija Predmet i Prijava prikazati brojeve indeksa studenata koji su položili sve
predmete.
BrInd
155/01
Normalizacija relacione baze podataka
• Normalizacija je postupak projektovanja logičke strukture baze podataka.
• Pravilno projektovana baza podataka mora imati strukturu koja osigurava da u radu sa njom ne može
biti neželjenih anomalija, kao što je na primer, uništavanje određenih podataka ili neusklađenost
između memorisanih podataka kao posledica ažuriranja baze podataka itd.
• E. F. Codd je 1969. god. definisao postupak koji dovodi projektanta relacione baze podataka do
željenog rezultata i nazvao ga “normalizacija” baze podataka.
• Codd je definisao tri nivoa normalizacije. Kasnije je Fagin dokazao da u nekim izuzetnim primerima
relacije, koje su u trećoj normalnoj formi, još uvek zadržavaju neke neželjene osobine i zato je
definisao četvrtu normalnu formu (4NF).
Funkcionalna zavisnost
• Ako je svakoj vrednosti atributa A u relaciji R priključena samo jedna vrednost atributa B u istoj
relaciji, onda je atribut B funkcionalno zavisan od atributa A.
• Funkcionalna zavisnost se može definisati između složenog ključa (više atributa) i jednostavnog
atributa.
• Ako je moguće svakom paru vrednost atributa A i B relacije R priključiti tačno jednu vrednost C iste
relacije, tada je atribut C funkcionalno zavisan o sastavljenom atributu A i B.
•
Potpuna funkcionalna zavisnost
Atribut B je potpuno funkcionalno zavisan od atributa A iste relacije, ako je funkcionalno zavisan od
atributa A, a ne od nekog sastavnog dela atributa A (u slučaju kada je atribut A sastavljen).
Potpuna funkcionalna zavisnost se posmatra kada je ključ tabele isključivo sastavljen od više atributa.
OCENABI, ŠIFRA_PREDMETA
OCENABI
OCENAŠIFRA_PREDMETA
NAZIV_PREDMETABI, ŠIFRA_PREDMETA
NAZIV_PREDMETABI
NAZIV_PREDMETAŠIFRA_PREDMETA
• Osnovne operacije održavanja baze podataka su: dodavanje nove n-torke u relaciju, izbacivanje neke
n-torke iz relacije i izmena (ažuriranje) vrednosti nekog atributa u relaciji.
• Problemi pri izvođenju ovih operacija kao što su ponavljanje ovih operacija više puta ili da se logičko
dodavanje ne može izvršiti, odnosno da izbacivanje jednog logičkog skupa podataka dovodi do
neželjenog izbacivanja drugih podataka, nazivaju se anomalije u održavanju baze podataka.
• Relacija je u Prvoj normalnoj formi ukoliko su sve vrednosti njenih atributa atomske ili drugim
rečima nisu dozvoljeni atributi ili grupe atributa «sa ponavljanjem», odnosno nisu dozvoljene
«tabele u tabeli».
Prva normalna forma
STUDENT1 (BI, IME_STUDENTA, SEMESTAR, ŠIFRA_SMERA, IME_RUK,
SIFRA_PREDMETA, NAZIV_PREDMETA, OCENA)
– Anomalije u izbacivanju: ukoliko je jedan predmet položio samo jedan student i ako se on
ispiše sa fakulteta, gube se i sve informacije o tom predmetu. Ako je bio jedini na smeru, gube
se sve informacije o tom smeru.
– Anomalije u ažuriranju: ukoliko se promeni naziv predmeta ili rukovodioc nekog smera, to se
mora učiniti na onoliko mesta koliko je studenata položilo taj predmet, odnosno koliko je
studenata upisano na dati smer.
– Problemi i u izveštavanju: zahtev tipa: «Prikaži listu predmeta, imena svh studenata koji su ga
položili i prosečnu ocenu na predmetu», bi zahtevao složeniji program ili bi trebalo samu
relaciju prestruktuirati i dobiti dve relacije sa istim skupom podataka za dva različita zahteva,
čime bi se redundansa podataka pa samim tim i problemi održavanja baze podataka umnožili.
• Da bi se smanjila redundansa do koje bi ovakva normalizacija dovela, možemo ovako dobijenu
relaciju, operacijom projekcije, dekomponovati na sledeće dve:
• Relacija R se dekomponuje u svoje projekcije bez gubljenja informacija ako prirodno spajanje tako
dobijenih projekcija dovodi do polazne relacije.
• Heath-ova teorema daje uslove pod kojima se može izvršiti dekompozicija relacije bez gubljenja
informacija:
R.B možeRelacija R(A,B,C) gde su A,B i C podskupovi atributa, u kojoj važi R.A se uvek
dekomponovati u svoje projekcije R1(A,B) i R2(A,C) bez gubljenja informacija.
Druga normalna forma
• Relacija R je u Drugoj normalnoj formi (2NF) ako i samo ako je u 1NF i svi njeni neključni
atributi potpuno funkcionalno zavise od primarnog ključa.
• Neključni atributi su atributi koji nisu kandidati za ključ, niti deo kandidata za ključ.
• Svođenje na 2NF vrši se dekompozicijom na taj način što se u jednoj projekciji ostavlja primarni ključ
i svi atributi koji su potpuno funkcionalno zavisni od njega, a u drugim projekcijama se realizuju one
funkcionalne zavisnosti koje su prouzrokovale nepotpune funkcionalne zavisnosti.
– Redundansa podataka: naziv predmeta se pojavljuje onoliko puta koliko je studenata položilo
taj predmet. Ponovo postoje sve iste anomalije u održavanju baze podataka:
– Ne mogu se dodati podaci o novom predmetu, ako ga neki student nije položio.
– Ako se iz baze podataka izbaci n-torka studenta koji je jedini položio neki predmet, tada se
gube sve informacije i o tom predmetu.
– Ako se promeni naziv predmeta, to se mora učiniti na onoliko mesta koliko je studenata
položilo taj predmet itd.
• S obzirom da je relacija R u 2NF, ukoliko svi njeni atributi daju jednoznačne činjenice samo o celom
ključu, onda relacija PRIJAVA nije u 2NF, jer NAZIV_PREDMETA daje jednoznačnu informaciju o
delu ključa i to ŠIFRA_PREDMETA.
• Svaka relacija sa prostim primarnim ključem je u 2NF, jer prosti ključ nema semantički moguć pravi
podskup.
• Svođenje na 2NF vrši se dekompozicijom na taj način što se u jednoj projekciji ostavlja primarni ključ
i svi atributi koji su potpuno funkcionalno zavisni od njega, a u drugim projekcijama se realizuju one
funkcionalne zavisnosti koje su prouzrokovale nepotupune funkcionalne zavisnosti.
• Da bi smo datu relaciju sveli na 3 NF, vršimo dekompoziciju (bez gubljenja informacija) relacije u
njene projekcije, na taj način što u jednoj projekciji ostavljamo primarni ključ i sve netranzitivno
zavisne atribute, a u drugim projekcijama se realizuju funkcionalne zavisnosti koje su dovele do
tranzitivnih zavisnosti:
NAZIV_PREDMETABI, ŠIFRA_PREDMETA
OCENABI, ŠIFRA_PREDMETA
NAZIV_PREDMETAŠIFRA_PREDMETA
ŠIFRA_PREDMETANAZIV_PREDMETA
• U ovom slučaju postoje dva složena i "preklapajuća" kandidata za ključ: BI, ŠIFRA_PREDMETA i
BI, NAZIV_PREDMETA. Jedini neključni atribut je OCENA, pa pošto on potpuno funkcionalno
zavisi od primarnog ključa, relacija je u 2 NF.
• Relacija je u Boyce-Codd-ovoj normalnoj formi (BCNF) ako i samo ako su sve determinante u
relaciji i kandidati za ključ.
• Determinanta relacije R je bilo koji atribut, prost ili složen, od koga neki drugi atribut u relaciji
potpuno funkcionalno zavisi.
• Ukoliko označimo sve determinante (D) i sve kandidate za ključ (KK) u relaciji PRIJAVA:
NAZIV_PREDMETA, OCENABI, ŠIFRA_PREDMETA (D) (KK)
ŠIFRA_PREDMETA, OCENABI, NAZIV_PREDMETA (D) (KK)
NAZIV_PREDMETAŠIFRA_PREDMETA (D)
ŠIFRA_PREDMETANAZIV_PREDMETA (D),
• Dekompozicijom, pri kojoj se iz relacije izvlače projekcije sa onim determinantama koje nisu
kandidati za ključ, relacije se svodi na BCNF.
(a) (b)
STUDENT2a (BI, IME, SEM, ŠIFRA_SMERA) STUDENT2 (BI, IME, SEM, ŠIFRA_SMERA)
STUDSMER (BI, IME_RUK) SMER (ŠIFRA_SMERA, IME_RUK)
• Projekcije (a) pokazuju izvesne anomalije u održavanju, jer da bi se dodali ili izbacili podaci o
jednom studentu, to se mora uraditi u obe projekcije, ili da bi ažurirali atribut IME_RUK, za svaku
vrednost BI koja odgovara datoj vrednosti ŠIFRA_SMERA iz relacije STUDENT2a, mora se u
relaciji STUDSMER izvršiti ažuriranje atributa IME_RUK.
• Rissansen-ova teorema daje sledeće uslove pod kojima se neka relacija može dekomponovati na
nezavisne projekcije:
– Projekcije R1 i R2 relacije R su nezavisne tada i samo tada ukoliko se:
• Svaka funkcionalna zavisnost u R može logički dedukovati iz funkcionalnih zavisnosti
u R1 i R2.
• Zajednički atribut relacija R1 i R2 je KK barem u jednoj od njih.
• ukoliko pretpostavimo da jedan predmet predaje više nastavnika, i da se za jedan predmet koristi više
knjiga, odnosno postoje sledeće višeznačne zavisnosti:
NASTAVNIKPREDMET KNJIGAPREDMET
• i pretpostavimo da ne postoji veza između nastavnika i knjiga odnosno da se ne zna koji nastavnik
koristi koje knjige i da li koristi jednu ili više.
• Data relacija PROGRAM je u BCNF, ali anomalije u ažuriranju su očigledne, jer da bi ubacili knjigu
za jedan predmet, to bi trebalo da uradimo na onoliko mesta koliko profesora drži taj predmet. Razlog
anomalijama jeste postojanje dve nezavisne višeznačne činjenice.
• U relaciji R(A,B,C) postoji višeznačna zavisnost B, ako za datu vrednost A,A postoji skup od
nula, jedne ili više vrednosti B, a taj skup vrednosti ni na koji način ne zavisi od vrednosti atributa C.
Atributi A, B i C mogu biti složeni.
• Relacija R je u četvrtoj normalnoj formi (4NF) ukoliko u njoj nisu date dve ili više nezavisne
višeznačne činjenice.
• Fagin navodi:
Relacija R (A,B,C) može se dekomponovati bez gubljenja informacija na projekcije C, jer ako u
relaciji B (što uključuje i AR1(A,B) i R2 (A,C) ako i samo ako važi A C). B, tada postoji i
višeznačna zavisnost Apostoji višeznačna zavisnost A
• Relacije RASPORED i UDŽBENIK su u 4NF jer u njima ne postoje višeznačne zavisnosti samim tim
što su obe binarne relacije, odnosno obe sadrže samo po jednu višeznačnu činjenicu.
• Relacija R je u Petoj normalnoj formi (5NF) ako i samo ako se svaka zavisnost spajanja može
pripisati kandidatu za ključ.
• Relacija STUDENT2 se može rekonstruisati prirodnim spajanjem preko BI, koji je njen ključ, pa je
stoga relacija STUDENT2 u 5 NF.
Normalna forma ključeva i domena (DK/NF)
• 1981. - R. Fagin je dao najopštiju definiciju normalne forme ključeva i domena i pokazao da je
relacija koja je u DK/NF ne prouzrokuje anomalije u održavanju.
• Relacija je u DK/NF:
– Ako su sve zavisnosti u njoj posledica definicije ključeva i domena.
– Ako svaki atribut daje informaciju isključivo o ključu, o celom ključu i njegovim delovima.
• Nije u DK/NF jer je definisano ograničenje da jedan predmet ima jedan naziv (ŠIF_PREDMETA
NAZIV_PREDMETA), a to nije posledica definicije ključa ove relacije.
• Direktna primena ove definicije nije moguća, jer otkrivanje ograničenja u relacijama zahteva
otkrivanje funkcionalnih, višeznačnih i zavisnosti spajanja, a to praktično znači primenu svih
navedenih definicija.
INTEGRITET BAZE PODATAKA
• Integritet baze podataka podrazumeva problem zaštite baze podataka od pogrešnog ažuriranja,
odnosno od pogrešnih ulaznih podataka, greški operatera i programera, sistemskih otkaza i dr.
Domen: STAR
Skup od INTEGER
Operacije:
Proveri-domen-STAR
Ulaz: vrednost_atributa
Izlaz: Boolean
Post: if vrednost_atributa between 15 and 65
then izlaz = true else izlaz = false.
• Za svaki spoljni ključ u relaciji mora se definisati jedno pravilo integriteta koje se sastoji od uslova,
trenutka kada se uslov ispituje i akcija koje se preduzimaju kada uslov nije zadovoljen.
• Pravila integriteta treba da budu definisana u okviru opisa baze podataka, a ne u okviru aplikacionih
programa. U opisu svake relacije, za svaki spoljni ključ, treba navesti odgovarajuće pravilo
integriteta.
Sigurnost baze podataka
• Termin sigurnost podataka podrazumeva mehanizme zaštite baze podataka od neovlašćenog
korišćenja.
• Opšti model zaštite podataka treba da definiše koji subjekat zaštite, može nad kojim objektom zaštite
da izvrši neku operaciju i pod kojim uslovima.
• Primer:
GRANT SELECT, INSERT ON RADNIK TO Ana
GRANT SELECT, INSERT, DELETE ON RASPORED TO Branko WITH GRANT OPTION
GRANT DBA TO Pera.
• Opis privilegija:
– SELECT - selektovanje
– UPDATE - promeniti
– INSERT - ubaciti
– DELETE – obrisati
– DBA – za administratora baze podataka kome su dozvoljene sve operacije nad njegovom
bazom.
– WITH GRANT OPTION – znači da autorizovani subjekt može da prenosi svoju autorizaciju i
drugim subjektima.
SELECT *
FROM RADNICI;
SELECT *
FROM RADNICI
WHERE SIFRA_PRED = 30;
SELECT *
FROM PREDUZEĆE
WHERE ŠIFRA_PRED IN (10, 30);
• Operator LIKE
– Možete izabrati redove koji sadrže navedeno slovo ili broj. U primeru je dat spisak svih
radnika koji imaju “U” kao drugo slovo u prezimenu.
SELECT PREZIME
FROM RADNICI
WHERE PREZIME LIKE ‘_U%’;
Kod (‘_U%’), crtica (_) označava poziciju jednog karaktera, a znak % označava bilo koji niz znakova.
ORDER BY klauzula sortira redove u rastućem nizu, tako da je najmanja plata na prvom mestu liste.
UPDATE RADNICI
SET PLATA = PLATA + 100
WHERE RADNO_MESTO = ‘PROJEKTANT’;
– Pogledi su virtualne tabele koje se ponašaju kao prozori kroz koje se vide podaci memorisani
u našim stvarnim tabelama.
– Pogledi ne sadrže vlastite podatke, ali se sa njima može raditi kao da su stvarne tabele.
Kod istovremenog korišćenja može doći do mnogih neželjenih efekata, kao na primer:
Otkaz sistema u toku izvršavanja nekog programa ili obrade neke transakcije (na primer
skinute su pare sa računa nekog komitenta, ali usled otkaza u tom trenutku se nije izvršio
prenos na drugi račun).
Gubljenje rezultata ažuriranja (na primer, ukoliko se izvršavaju dve transakcije istovremeno,
transakcija A podiže, dok transakcije B ulaže novac na isti račun. Ažuriranje koje transakcija
A obavlja je izgubljeno, odnosno prebrisano ažuriranjem koje je izvršila transakcija B u istom
trenutku).
Problem nekorektne analize podataka (na primer, za vreme nekog sračunavanja koje se
obavlja u jednoj transakciji, druga promeni vrednost argument koji je prva već obradila).
Osnovni cilj baze podataka je da omogući efikasnu obradu transakcija (jedno izvršenje neke logičke
jedinice posla ili programa).
Transakcije
Transakcija je operacija kojom se izvodi serija izmena nad jednom ili više tabela, tj. transakcija je
izvršenje neke logičke jedinice rada korisnika baze podataka.
Da bi se obezbedile ove osobine, skup instrukcija koje predstavlja transakciju počinje sa specijalnom
instrukcijom BEGIN TRANSACTION, a završava se bilo sa instrukcijom COMMIT (potvrđuju se
promene u BP) ili ROLLBACK (poništavaju se promene u bazi).
Ukoliko se u bilo kojoj transakciji ugnježdene strukture pokrene instrukcija ROLLBACK, poništavaju
se promene koje su proizvele sve ostale transakcije strukture.
Problem nepotvrđenih promena (čitanja)
Ovaj problem se javlja kada se jednoj transakciji dozvoli da čita ili da menja rekord koji druga
transakcija ažurira, a promene koje je ona učinila još nisu potvrđene naredbom COMMIT.
Da bi se mogle poništiti promene koje je transakcija izvršila nad BP, DBMS poseduje i održava
specijalnu memorijsku lokaciju (na nekoj spoljnoj memoriji) koja se naziva log ili žurnal.
Na ovoj memorijskoj lokaciji, za svaku transakciju i svaki objekat baze koji je ona ažurirala čuvaju se
vrednosti pre (before-image) i vrednosti posle ažuriranja (after-image).
Kada se izda instrukcija ROLLBACK sistem, koristeći vrednosti pre za datu transakciju, ažurira
odgovarajuće objekte baze podataka.
Konkurentna obrada transakcija
Transakcija se u sistemima zasnovanim na bazi podataka ne obavlja u izolaciji, već konkuretno
(uporedo) sa drugim transakcijama u sistemu.
Više transakcija mogu istovremeno zahtevati iste resurse, isti rekord baze podataka.
Komponenta DBMS-a koja vodi računa o redosledu izvršavanja akcija nad bazom u skupu transakcija
koje se konkuretno izvršavaju se zove Planer.
Velika je verovatnoća da ničim ograničeno izvršenje jednog skupa transakcija neće biti serijabilno.
Zadatak planera izvršenja je da proveri serijabilnost nekim i da spreči da neserijabilna izvršenja
naruše integritet baze podataka.
S obzirom da proveru serijabilnosti i preduzimanje odgovarajućih akcija planer izvršenja teško može
da obavi u realnom vremenu primenjuje se mehanizam zaključavanja (locking).
Protokol zaključavanja koji bi mogao da reši prikazane probleme može se iskazati na sledeći način:
1. Transakcija koja želi da pročita neki objekat baze mora prvo da postavi deljivi lokot na taj
objekat;
2. Transakcija koja želi da ažurira neki objekat baze mora prvo da postavi eksluzivni lokot na taj
objekat. Ako je ta transakcija ranije postavila S lokot, ona treba da taj lokot transformiše u X
lokot;
3. Ako transakcija nije uspela da postavi lokot na željeni objekat baze, tada ona prelazi u stanje
čekanja;
4. Transakcija oslobađa E lokot obavezno, a po pravilu i S lokot na kraju, sa COMMIT i
ROLLBACK naredbom.
“Živi” i “mrtvi” lokoti
U toku izvršenja skupa transakcija, moguće je da dve ili više transakcija formiraju “mrtvi lokot”,
odnosno da lokoti koje su one postavile na objekte baze sve njih dovode u stanje čekanja.
Pojam “živog lokota” se definiše kada je neka transakcija stalno u stanju čekanja na neki objekat baze
zbog toga što druge transakcije uvek pre nje postave lokot na taj objekat.
Problem “živog lokota” se jednostavno rešava uvođenjem nekog redosleda zaključavanja objekta (na
primer FIFO).
Saga se može definisati kao graf koji ima, standardom UML-a, definisane tipove čvorova. Putanja od
početnog čvora do bilo kog terminalnog čvora predstavlja moguću sekvencu akcija.
Svaka aktivnost se može tretirati kao posebna “kratka” transakcija koja se izvršava pod
kontrolom konvencionalnih mehanizama za upravljanje transakcijama.
Celokupna dugačka transakcija, jedna od putanja od početnog čvora do uspešnog ili
neuspešnog završetka, se obavlja na taj način što se u slučaju uspeštnog kraja zadržavaju sve
promene koje su učinile pojedine aktivnosti, a u slučaju neuspešnog koristi se mehanizam
kompenzacionih transakcija da bi se baza vratila u isto stanje u kome je bila pre otpočinjanja
sage.
Oporavak baze podataka
Oporavak baze podataka je vraćanje baze podataka u korektno stanje posle nekog otkaza.
Da bi se oporavak baze mogao uspešno izvršiti neophodno je da DBMS obezbedi redundante podatke.
Jedan skup redundantnih podataka se čuva u logu, a drugi skup u arhivskoj memoriji u koju se
povremeno prenosi sadržaj cele baze.
Log se koristi za otkaze koji fizički ne oštećuju memorijske jedinice (diskove) na kojima se čuva
baza, dok arhivska memorija služi za oporavak posle ovakvih otkaza.
• Dijagram prelaznog stanja (State Transition Diagram) se koristi da opiše niz i varijaciju
ekrana koji se dešavaju kada korisnik sistema sedne za terminal.
• U okviru ovog koraka, korisnici sistema koriste prototipove interfejsa, kako bi ih testirali i
eksperimentisali nad njima.
• Neki CASE proizvodi, pored toga što mogu da dizajniraju ekrane, vrše i njihova testiranja
kroz simulacije.
Sirov podatak:
Maloprodajni lanac prodavnica internacionalne muzičke kuće prikuplja podatke o prodaji za
svaki kupljeni proizvod, podatke o obrtu kapitala i dr. Sirov podatak opisuje na primer, da
lanac prodavnica u Beogradu prodaje 10000 evra vrednosti prodate robe u Junu 2003.
Finansijska institucija prikuplja podatke o svim računima i ušteđevinama klijenata. Sirov
podatak na primer, može pokazati da je Sefan M. podigao 50 evra sa svog računa jutros u
Amsterdamu.
Izvedene informacije:
S obzirom da je vrednost prodate robe u 2002. godini iznosio 15.000 evra, a postavljen cilj za
2003. godinu je bio 20.000 evra, očigledno je da lanac prodavnica u Beogradu nije ispunio
željeni cilj. Analiza poslovanja treba da odredi posledice pada prodaje. Pitanja koja se
postavljaju su: Koji se proizvodi prodaju, a koji ne?, Koji je efekat promocije proizvoda?.
Stefan živi u Beogradu, ali u proteklih pet meseci, Stefan je podizao novac u Londonu, Oslo-u,
Stockolm-u, što dovodi do zaključka da on često putuje po Evropi. S toga bi možda on bio
zainteresovan za specijalnu kreditnu karticu koji mu omogućava neograničen pristup svom
računu u 16 različitih zemalja uz odgovarajuću godišnju članarinu. Pitanja koja se postavljaju
nakon ove analize su: Koji je prosečan dnevni bilans njegovog računa?, Za koje proizvode bi
bio zainteresovan?
OLTP sistemi
OLTP (on-line transaction processing) sistemi su operacioni sistemi koji prikupljaju poslovne
transakcije i snabdevaju podacima data warehouse ili data mart.
Skladište podataka (Data Warehouse – DW) je analitička baza podataka namenjena samo za čitanje i
koristi se kao osnova sistema za podršku odlučivanju.
Primeri OLTP operacionih sistema: aplikacije praćenja porudžbina, aplikacije usluga klijenata (npr.,
otvaranje računa klijentima), bankarske funkcije (npr, depoziti) itd.
Jedna od karakteristika koja razdvaja transakcione sisteme od analitičkih jeste dizajn baze podataka:
Transakcioni sistemi su dizajnirani tako da preuzimaju podatke, vrše izmene nad postojećim
podacima, daju izveštaje, održavaju integritet podataka i upravljaju transakcijama što je brže
moguće.
Analitički sistemi nisu predviđeni da obavljaju ove poslove. Oni se dizajniraju za veliki broj
podataka namenjenih samo za čitanje, obezbeđujući informacije koje se koriste za donošenje
odluka.
OLTP vs. analitičke baze podataka
U tabeli su date neke od razlika između transakcionih sistema i skladišta podataka.
Skladište podataka je informaciona baza podataka dizajnirana za podršku jedne ili više klasa
analitičkih zadataka, kao što su nadgledanje i izveštavanje, analiza i dijagnoza i simulacija i
planiranje.
Koncept Warehousing
Warehousing koncept je skladištenje agregiranih, ekstrahovanih i filtriranih podataka u meta baze,
koje omogućavaju slojevit, multidimenzionalni pristup podacima, kakav je potreban za donošenje
odluka najvišeg strateškog nivoa.
Osnovni cilj skladištenja podataka je prikupljanje i distribucija informacija kroz preduzeće, tj.
korišćenje bilo koje informacije, sa bilo kog mesta, u bilo koje vreme, tačnije – ostvarenje principa
"Biti uvek na usluzi korisniku informacija".
Menadžeri samostalno vrše analize - donosioci odluka su pod velikim pritiskom jer moraju da
zasnivaju svoje analize na osnovu tekućih činjenica koje se dobijaju iz raznih poslovnih situacija. Te
činjenice se čuvaju u on-line transakcionim (OLTP) sistemima i nije im lako pristupiti. Korisnici
skladišta podataka mogu da postavljaju raznovrsna analitička pitanja na bazi poređenja u vremenu,
nalaženja relativnih vrednosti i kreiranja šta-ako scenarija.
Vremenski. Podaci se čuvaju mnogo godina kako bi se iskoristili za praćenje trendova, prognoze i
vremensko poređenje.
Izvori podataka – Izvorni sistemi su operacioni sistemi, npr. OLTP sistemi koji mogu biti
relacioni.
Oblast za pripremu podataka – skup procesa koji čisti, transformiše, kombinuje i priprema
izvorne podatke za korišćenje u DW. Podaci se transformišu u konzistente formate. Oblast za
pripremu podataka se nalazi na jednom ili nekoliko kompjutera, ne mora da bude zasnovana
na relacionoj tehnologiji, ne podržava koristničke izveštaje.
Data Mart – je podskup DW koji sadrži podatke specifične za određenu poslovnu aktivnost
kao što su finansije ili analiza klijenata. Data martovi mogu biti uključeni u DW, mogu se
izgraditi u relacionim ili OLAP bazama podataka i mogu detaljne ili sumarne podatke koje se
mogu ili ne deliti kroz data mart-ove.
Data Warehouse – može se definisati i kao virtuelna unija data mart-ova sa integrisanim
informacijama koje su deljive kroz data mart-ove ili kao centralizovano, integrisano skladište
podataka koje obezbeđuje podatke data mart-ovima.
Razvoj skladišta podataka
Pri izgradnji skladišta podataka najbitniji su sami podaci, a ne poslovni procesi i funkcije, kao što je
to slučaj sa transakcionim sistemima.
Za razvoj skladišta podataka potrebno je:
1. izvršiti analizu izvora podataka,
2. pripremiti podatake,
3. izgraditi skladište podataka.
1. Analiza izvora podataka
Osnovni izvori podataka za koncept skladišta podataka su operativni (transakcioni), tzv. OLTP (On-
Line Transaction Processing) podaci, kao i spoljne informacije nastale kao istorija poslovanja ili
industrijski i demografski podaci uzeti iz velikih javnih baza podataka.
Analiza izvornih podataka se smatra ključnim elementom i oduzima 80% vremena, jer je potrebno
definisati odgovarajuća pravila za preuzimanje podataka iz izvornih podataka. Znanja vezana za ovu
oblast su najčešće u glavama onih koji treba da koriste skladište podataka.
Glavna prednost:
podržavanje svih podataka,
svođenje na minimum vreme potrebno korisniku u ranim fazama (stanjima) projekta.
Nedostaci:
umanjivanjem kosrisnikovog učešća povećava se rizik od promašaja ispunjenja zahteva
korisnika,
oduzima dosta vremena.
Prikupljanje korisničkih (User-Driven) zahteva
Prikupljanje korisničkih zahteva je metoda koja se bazira na definisanju zahteva istraživanjem
funkcija kojima korisnik teži, odnosno koje korisnik izvršava. Ovo se obično postiže kroz seriju
sastanaka i/ili intervjua sa korisnikom.
Glavna prednost ovog pristupa je što se koncentriše na ono što je potrebno, a ne na ono što je
dostupno.
Pre početka razvoja projekta treba da se razmotri arhitektura i infrastruktura skladišta podataka:
a. Upiti i izveštaji - Tehnike analize podataka mogu uticati na tip odabranog modela podataka i njegov
sadržaj. Na primer, ako je namera da se obezbedi jednostavna mogućnost upita i izveštaja, model podataka
koji struktuira podatke na normalizovani način verovatno će obezbediti najbrži i nalakši pristup podacima.
Mogućnost upita i izveštavanja se primarno sastoji od biranja povezanih elemenata podataka, eventualnog
njihovog sumiranja i grupisanja u neku kategoriju i prezentovanja rezultata
Na primer, interesuje vas koliko je određenih proizvoda prodato određenog dana, u određenoj
prodavnici i u određenom rasponu cena. Onda za dalju analizu želite da znate koliko
prodavnica je prodalo određeni proizvod, u određenom rasponu cena, određenog dana. Ova
dva pitanja zahtevaju slične informacije, ali jedna posmatrane iz ugla proizvoda, a druga iz
ugla prodavnice.
Višedimenzionalna analiza zahteva model podataka koji će omogućiti da se podaci lako i brzo mogu
pogledati iz bilo koje moguće perspektive ili dimenzije.
Pošto se koristi više dimenzija, model mora da obezbedi način da se podacima brzo pristupa (ako se
koriste visoko normalizovane strukture podataka, biće potrebno mnogo grupisanja između tabela koje
sadrže različite dimenzije podataka i mogu značajno uticati na performanse).
Za razliku od upita, izveštaja i višedimenzionalnih analiza, gde je korisnik morao da kreira i izvršava
upite zasnovane na hipotezama, data mining traži odgovore na pitanja koja ne moraju biti prethodno
postavljana.
Otkrivanje može imati formu pronalaženja značaja u vezama između određenih elemenata podataka,
klasterisanja određenih elemenata podataka ili neki drugi obrazac u korišćenju određenih skupova
elemenata podataka. Nakon iznalaženja ovih obrazaca, algoritmi mogu da iz njih izvedu pravila. Ova
pravila tada mogu biti korišćena da se generiše model koji ima željeno ponašanje, identifikuje veze
među podacima, otkriva obrasce i grupiše klastere zapisa sa sličnim atributima.
2. Priprema podataka
U procesu razvoja skladišta podataka priprema podataka je jedna od najbitnijih aktivnosti. Dalji
proces razvoja skladišta podataka biće uspešan samo ako je ova aktivnost uspešno završena.
Priprema podataka se vrši na osnovu ranije određenog izvora podataka, pravila za preuzimanje tih
podataka, procedure pripreme i zahteva korisnika. Priprema se vrši određenim ekstrakciono-
transformacionim alatima kroz sledeće korake:
Ekstrakcija i čišćenje podataka,
Transformacija podataka.
Rezultat ovih aktivnosti treba da budu podaci koji će nam omogućiti generisanje meta podataka, na
osnovu kojih se može pristupiti dizajnu skladišta podataka
2.1. Ekstrakcija i čišćenje podataka
Ova faza se sastoji od sledećih zadataka:
a. razvoj procedura za ekstrakciju podataka,
b. razvoj procedura za čišćenje podataka.
Provera logičkih grešaka uključuje proveru vrednosti atributa usled različitog označavanja
pojmova, proveru atributa u kontekstu ostalih podataka u redu, proveru atributa u kontekstu
redova druge tabele koja je povezana, proveru veza između redova iste ili povezanih tabela
(provera prenesenih ključeva).
"Poboljšanje" podataka je proces čišćenja kojim se teži da podaci dobiju puno značenje.
Primer za ovo su podaci o imenima i adresama.
Pre početka procesa transformacije podataka, tim stručnjaka koji radi na projektu dizajniranja
skladišta podataka definiše fizički model podataka za skladište podataka i generiše šeme.
Prelazne šeme - Obično se izvorni podaci prvo smeštaju u prelazne šeme. Prelazne šeme su
zajednički interfejs za sve izvorne sisteme. One se ne podudaraju u potpunosti ni sa izvornim ni sa
odredišnim šemama. Koriste se da bi se poboljšali procesi "čišćenja" i transformacije podataka.
Analiza izvora podataka - Nakon kreiranja plana transformacije podataka, prelazi se na analizu
izvora podataka. Potrebno je odrediti koji će se podaci mapirati u odredišni sistem i koja je to logika
potrebna da bi se izvršila migracija podataka.
b. Razvoj procedura za transformaciju podataka
Pod transformacijom podataka se podrazumeva proces kojim se usklađuju različiti načini prikazivanja
podataka različitih sistema u jedinstveni oblik.
Na primer, neki sistemi mogu označavati pol ljudi sa 1 za muški pol i 2 za ženski pol. Ako se
u skladištu podataka ovo označavanje vrši sa M i Z, onda mora postojati proces koji će
transformisati 1 u M i 2 u Z.
Kreiranje formata podataka. Za sve podatke iz starijih sistema moraju se obezbediti formati
pogodni za smeštanje u skladište podataka.
Kreiranje ključeva za agregacione zapise. Svi zapisi u tabelama, a samim tim i agregacije,
moraju imati ključeve. Ovaj korak se razlikuje od prethodnog jer su ključevi za agregacione
zapise u potpunosti veštački i ne smeju biti identični primarnim ključevima tabele činjenica.
Prema tome, stručni tim mora dizajnirati aplikaciju koja će generisati takve ključeve.
Obrada neučitanih podataka. Pri procesu smeštanja podataka u skladište podataka često se
dešava da se neki podaci ipak ne učitaju, najčešće zbog referencijalnog integriteta. Takvi
podaci se moraju obraditi u posebnoj aplikaciji, koja će obezbeđivati referencijalni integritet
podataka.
Provera kvaliteta podataka - Testiranje procedura se, najčešće, ostvaruje proverom kvaliteta
podataka, tako što se zadaju upiti nad skladištem podataka koji prebrojavaju podatke ili ih prikazuju u
vidu grafikona sa kojih se može utvrditi da li su podaci u rasponu koji je očekivan.
Meta baza podataka čuva sve podatke o podacima mapirajući izvorni u ciljni sistem i uspostavlja vezu
između podataka sa izvora i cilja. Oni čuvaju informacije o transakcionim podacima, definiciju
podataka u ciljnoj bazi i transformaciono-integracionu logiku.
Tek po postavci meta baze podataka može se krenuti dalje u izdvajanje podataka iz transakcione baze
podataka, pa potom sumiranje, sortiranje i organizovanje pre punjenja DW.
Osnovu za izradu dimenzionog modela predstavljaju meta podaci, na osnovu kojih se vrši definisanje
hijerarhija, elemenata i atributa, normalizacija i denormalizacija i definisanje agregacija.
Svaka dimenziona tabela ima svoj primarni ključ, a svi oni učestvuju u stvaranju primarnog ključa
tabele činjenica. Ovakvi modeli se nazivaju šemama zvezde.
Tabele činjenica sadrže podatke koji su, najčešće, numeričkog tipa i mogu sadržati veliki broj zapisa.
Dimenzioni modeli
Dimenzioni modeli su standardnog oblika te se mogu predvideti interfejsi koji će biti od koristi
korisnicima skladišta podataka.
Dimenzioni modeli se jednostavno proširuju dodavanjem novih dimenzija i njihovih atributa i pri
tome se nijedan alat za izveštavanje ili upite ne mora menjati. Sve je više pomoćnih programa i alata
koji upravljaju i rade sa agregacijama i na taj način još više poboljšavaju performanse sistema.
Izgradnja skladišta podataka je iterativni postupak. Čim se određena količina podataka smesti u
skladište podataka, korisnici mogu da im pristupaju i da zaključe koje su im koristi od toga. Nakon
toga, oni mogu da zadaju nove zahteve zbog kojih će morati da se unesu neke izmene u modelu.
a) denormalizacija podataka,
b) definisanje hijerarhija,
c) kreiranje agregacija,
d) kreiranje fizičkog modela,
e) generisanje baze podataka,
f) učitavanje podataka.
a) Denormalizacija podataka
Kod denormalizovanog modela dimenzije su organizovane u šemu zvezde, a kod normalizovaog u
šemu snežne pahuljice.
Postoje situacije u kojima šema zvezde nije pogodna za skladištenje podataka. Osnovni razlozi za to
su:
denormalizovana šema zvezde može zahtevati previše memorijskog kapaciteta,
veoma velike dimenzione tabele mogu uticati na pad performansi sistema.
Ovi problemi se mogu rešiti normalizacijom dimenzija, čime se šema zvezde prevodi u šemu pahulje.
Glavni nedostatak šeme pahulje je njena složenost u odnosu na šemu zvezde, čime se otežava
održavanje skladišta podataka. Zato je potrebno vršiti normalizaciju samo onih dimenzija koje sadrže
mnogo redova podataka i koje imaju mnogo atributa.
Najčešće se postižu najbolji rezultati ako se izvrši normalizacija samo par dimenzija, a da se ostale
ostave onakve kakve su i bile. Na taj način se dolazi do delimične šeme pahulje.
Šema galaksije predstavlja kolekciju šema zvezda, tj. ako se ne može kreirati model koji bi imao samo
jednu činjeničnu tabelu, tada je potrebno povezati dve šeme zvezde da bi se zadovoljile potrebe
korisnika.
Šema zvezde, pahulje i galaksije
Šema zvezde Šema pahulje Galaksija
Tabela činjenica sadrži kvantitativne podatke o poslovima koji opisuju specifične događaje u
poslovanju, kao što su bankarske transakcije ili prodaja proizvoda, a koje korisnici analiziraju.
Može sadržati i agregirane podatke, kao što je npr., mesečna prodaja. Ovi podaci su najčešće
numeričkog tipa i mogu se sastojati i od nekoliko miliona redova i kolona.
Dimenzione tabele su znatno manje i sadrže podatke koji opisuju dati posao, tj. one podatke po
kojima se vrši analiziranje. Ti podaci se nazivaju atributi. Na primer, kod maloprodaje
dimenzione tabele opisuju kako se izračunavaju podaci o prodaji.
Osnovne prednosti šeme zvezde su što omogućava definisanje složenih višedimenzionih podataka u
vidu jednostavnog modela, smanjuje broj fizičkih veza koje se moraju procesirati pri zadavanju upita,
čime se postiže poboljšanje performansi sistema i omogućava proširenje skladišta podataka uz
relativno jednostavno održavanje.
b) Definisanje hijerarhija
Dimenzione tabele memorišu sledeće elemente:
traženje hijerarhijskih relacija u svakoj dimenziji,
definisanje opisnih atributa svake dimenzije.
Dimenzije veoma često mogu biti organizovane u hijerarhiji. Na primer, kod dimenzije proizvod,
mogu postojati tri dimenziona elementa: prozvod, grupa i vrsta proizvoda. U ovom modelu možemo
reći da dimenzioni element "proizvod" predstavlja najniži hijerarhijski nivo u dimenziji proizvod, dok
vrsta proizvoda predstavlja najviši nivo.
Posmatranje podataka iz različitih, ali blisko povezanih perspektiva omogućava da korisnik analizira
podatke na različitim nivoima detalja.
Drill-down - Postupak prelaska sa nivoa sa manjim brojem detalja na nivo sa većim brojem
detalja naziva se spuštanje u dubinu (drill down) i predstavlja zahtev korisnika da mu se
prikaže više detalja. Na primer, Pošto se pronađe podatak o prodaji nekog regiona, spušta se
naniže da bi se saznalo kako se prodaja odvija po opštinama. Geografski podaci vezani za
prodaju mogli bi se organizovati u sledeću hijerarhiju: SVET –> KONTINENT –> DRŽAVA
–> OBLAST –> GRAD
Drill-up - Postupak prelaska sa nivoa sa većim brojem detalja na nivo sa manjim brojem
detalja, na tzv. sumarne podatke, naziva se dizanje naviše (drill up). Na primer, upit bi mogao
prezentovati prodaju u odnosu na neke regione.
Drill across – koristi se za povezivanje dve ili više činjeničnih tabela na istom nivou
hijerarhije.
Šema pahulje
Definiše hijerarhiju koristeći višedimenzione tabele - Šema pahulje je varijacija šeme zvezda u
kojoj su hijerarhija dimenzije skladištene u višedimenzione tabele. Na primer, dimenzija Proizvod je
skladištena u tri tabele: kategorija proizvoda, podkategorija proizvoda i proizvod.
Normalizovana je.
Podržana je unutar analitičkih usluga. (samo jedna dimenziona tabela se pridružuje tabeli činjenica,
dok su ostale dimenzione tabele povezane sa spoljnim ključem).
c) Kreiranje agregacija
Agregacijama se sumiraju detalji podataka i smeštaju u posebne tabele. Na primer, moguće je kreirati
sumarne podatke o prodaji po regionu i oblasti skupljajući ih iz svake prodavnice, tj. najnižeg nivoa
detalja.
Glavni razlozi kreiranja agregacija su da se poboljšaju performanse upita, tj. da se smanji vreme
odziva na upit, kao i da se smanji broj resursa potrebnih za izvršenje upita.
Jedan od načina na koji se mogu kreirati agregacije jeste korišćenje SQL naredbi. Iako ovaj način nije
najbolji po pitanju performansi sistema, on je najjednostavniji.
U slučaju kreiranja agregacija koje nisu zasnovane na SQL naredbama, potrebno je razviti
specijalizovane programe, što usložnjava procese razvoja i održavanja skladišta podataka.
Na primer, ako se izvrši sortiranje redova podataka po dimenziji Vreme, u tabeli će se prvo nalaziti
redovi podataka koji se odnose na Dan, iza njih će biti redovi podataka koji se odnose na Nedelju itd.
Zatim se na svakom mestu prelaza sa jednog nivoa dimenzije na drugi (na primer, sa Dana na
Nedelju) kreiraju podzbirovi za taj nivo dimenzije. Pri tome je moguće iskoristiti prednosti paralelnog
procesiranja jer su podaci podeljeni po grupama (jedan proces može računati podzbirove vezane za
nivo Dan, a drugi za nivo Nedelja). Tako dobijene podzbirove treba učitati i izvršiti agregaciju. Time
je proces agregacije podataka završen.
Neposredno pre kreiranja modela treba izabrati sistem za upravljanje bazama podataka na kome će
biti implementirana baza podataka.
U sledećem koraku se vrši izvršavanje DDL datoteka pomoću Query Analyzer-a, alata koji je sastavni
deo SQL Servera 2003. Ovaj alat omogućava direktno zadavanje SQL naredbi i njihovo izvršavanje u
cilju generisanja baze podataka.
Kada se svi ovi poslovi uspešno urade, baza (skladište) podataka je generisana.
f) Učitavanje podataka
U toku učitavanja se mogu eventalno izvršiti još neke transformacije, mada bi sa transformacijama
podataka trebalo završiti pre učitavanja zbog problema konzistentnosti baze.
Za učitavanje podataka može se koristiti alat MS SQL Server-a DTS (Data Transformation Servicess)
i njegova procedura učitavanja podataka pomoću takozvanih DTS paketa.
OLAP sistemi
OLAP rešenja omogućavaju korisnicima brz i fleksibilan pristup podacima i predstavljaju nadgradnju
skladišta podataka.
Interaktivno analitičko procesiranje (On line Analytical Processing – OLAP) namenjeno je on-line
analizama i izveštavanjima.
U tu svrhu se koriste analitički OLAP sistemi koji obezbeđuju informacije koje se koriste za analizu
problema ili situacija.
Analitičko procesiranje se primarno vrši korišćenjem poređenja ili analiziranjem šablona i trendova.
Na primer, analitički sistem bi mogao da prikaže kako se određena vrsta štampača prodaje u različitim
delovima zemlje. Takođe, mogao bi da prikaže i kako se jedna vrsta proizvoda trenutno prodaje u
odnosu na period kada se proizvod prvi put pojavio na tržištu.
OLAP sistemi omogućavaju jednostavnu sintezu, analizu i konsolidaciju (agregacija podataka po
zadatom kriterijumu) podataka.
OLAP sistemi podržavaju kompleksne analize koje sprovode analitičari i omogućavaju analizu
podataka iz različitih perspektiva (poslovnih dimenzija).
OLAP serveri koriste višedimenzione strukture za čuvanje podataka i veza između njih.
Višedimenzione strukture se najbolje vizuelizuju kao kocke podataka i kao kocke u kockama
podataka. Svaka strana kocke se naziva dimenzijom. Dimenzija predstavlja kategoriju podataka, kao
što su tip proizvoda, region, vreme itd. Svaka ćelija kocke sadrži agregirane podatke koji su u vezi sa
dimenzijama. Na primer, jedna ćelija može sadržati podatke o ukupnoj prodaji za dati proizvod i
region u toku jednog meseca.
Numeričke mere – Mere su vrednosti podataka ili činjenice koje korisnici analiziraju. Primeri
mera su Prodaja, Jedinice, Troškovi prodate robe itd.
Kocke – Kocke kombinuju sve dimenzije i sve mere u jedan konceptualni model.
Definisanje kocke
Kocka je logička struktura skladištenja OLAP baze podataka.
Kocka definiše skup povezanih dimenzija koje formiraju jednu n-dimenzionalnu mrežu:
Svaka ćelija kocke sadrži jednu vrednost;
Vrednost svake ćelije je presek dimenzije.
Svaka kocka mora da sadrži barem jednu meru, ali ne može da ima više od 1024 mera.
MOLAP i ROLAP se razlikuju po načinu fizičkog čuvanja podataka. Kod MOLAP sistema podaci se
čuvaju u višedimenzionoj strukturi, a u slučaju ROLAP sistema podaci se čuvaju u relacionim bazama
podataka.
a. Višedimenzioni OLAP (MOLAP)
MOLAP baze podataka imaju sledeća ograničenja:
Prednost MOLAP sistema je što obezbeđuju odlične performanse sistema kada se radi sa već
sračunatim podacima (agregacijama).
- tabele
- upiti - predviđanja - grafikoni
- heširanje - traženje - drill down
- indeksiranje izuzetaka - isecanje
- štampanje
Sloj baze
podataka Sloj aplikacije Sloj prezentacije
Podaci iz različitih transakcionih sistema učitavaju u višedimenzionu bazu podataka pomoću batch rutina.
Kada se završi sa učitavanjem podataka atomskog nivoa, prelazi se na kreiranje agregacija, nakon čega je
baza podataka spremna za rad. Korisnici zadaju svoje zahteve za OLAP izveštajima putem interfejsa.
b. Relacioni OLAP (ROLAP)
Transakcioni Skladište Relacioni OLAP
sistemi podataka OLAP interfejs
(RSUBP)
- transformacije
- dinamička
- paralelni upiti konsolidacija - tabele
- paralelno učitavanje - složeno filtriranje - grafikoni
- paralelno indeksiranje - predviđanja - mape
- bit-map indeksiranje - obrada izuzetaka - upozorenja
- heširanje - procesiranje u - drill down
- veze zvezde - isecanje
pozadini
- deljenje podataka - podela upita
- backup i recovery - raspoređivanje
- optimizacija troškova - upravljanje
- SMP i MPP podrška tokovima
- agregacije
ROLAP sistemi mogu da rade sa velikim skupovima podataka. Čim se odredi izvor podataka, korisnik
može započeti analizu. S obzirom da se radi direktno nad bazom podataka, korisniku su uvek na
raspolaganju tekući podaci.
Kod ROLAP sistema ne postoje ograničenja po pitanju broja dimenzija koja postoje u slučaju
MOLAP sistema.
Cilj korišćenja HOLAP alata jeste da se iskoriste prednosti MOLAP alata (kratko vreme odziva
sistema i analitičke mogućnosti) i ROLAP alata (dinamički pristup podacima).
Pri tome se ne može reći da je HOLAP prost zbir MOLAP-a i ROLAP-a. To je zapravo ROLAP koji
ima mogućnost izvršavanja vrlo složenih SQL naredbi.
Cilj je bio da se zadrže sve prednosti ROLAP-a, ali da se pri tome dodaju i neke nove mogućnosti za
rad sa višedimenzionim bazama podataka.
Evaluacija
1. Koja je svrha oblasti za pripremu podataka kod Data Warehouse-a?
Oblast za pripremu podataka je skup procesa koji čisti, transformiše, kombinuje i priprema
izvorne podatke za korišćenje u DW.
Tabela činjenica – Centralna tabela u Data Warehouse-u koja predstavlja numeričke podatke
u kontekstu koji opisuju određeni događaj u poslovanju.
Mere – kvantitativna, numerička kolona u tabeli činjenica. Mere obično predstavljaju
vrednosti koje korisnici analiziraju.
Dimenzija tabele – Tabela u Data Warehouse-u koja predstavlja jedan poslovni objekat ili
entitet.
Sadržaj
Otkrivanje znanja (Knowledge Discovering)
Definisanje Data mininga
Primene Data mininga
Data mining modeli
Koraci kod izgradnje DM modela
OLAP data mining
Data mining i otkrivanje znanja
Korisnici informacionih sistema s pravom zaključuju da su im uvođenjem automatizovanog
informacionog sistema obećavali sve i svašta, a dobili su samo gomilu podataka. Čak i najboljem
analitičaru je teško da identifikuje ključne informacije koje su relevantne za upravljanje poslovanjem.
Data mining je automatski ili poluautomatski proces koji izvodi značajna pravila ili obrasce iz
ogromne količine podataka. Data mining programi analiziraju delove podataka da bi identifikovali
veze između naizgled "nepovezanih podataka".
Data mining je proces otkrivanja znanja (Knowledge Discovery in Databases - KDD). koji omogućuje
korisnicima da shvate sisteme i veze između njihovih podataka.
Data mining se može definisati kao proces podrške odlučivanju u kojem se traže šabloni infomacija u
podacima.
Osnovni cilj data mininga jeste otkrivanje skrivenih veza, predvidivih sekvenci i tačnih klasifikacija.
Ovo pretraživanje može vršiti korisnik, na primer izvođenjem upita (tada je to zaista teško) ili ga
može vršiti neki "pametni" program koji automatski pretražuje bazu umesto korisnika i nalazi
značajne šablone. Kada se ona nađe, informacija treba da se prezentuje na odgovarajući način, sa
grafikonima, izveštajima itd.
Primene Data mininga
Reklamiranje na Internetu
Data mining se može koristiti za klasifikovanje grupa klijenata sa sličnim informacijama, kako
bi se ciljno reklamiralo.
Kada se korisnik na primer registruje na e-commerce Web sajt koji prodaje sportsku opremu
tada DBMS prikuplja informacije o klijentu, kao što su pol, godine, omiljeni sport i dr.
Korišćenjem tehnika data mininga, web sajt će prikazivati baner sa motivima golfa za
muškarce i dr.
Kada kupujete putem Interneta, ponekad vam se ponude i dodatni proizvodi za koje je Web
sajt predvideo da ćete možda biti zainteresovani. Takva preporuka se zasniva na tehnikama
data mininga koji pretražuje obrasce klijenata koji su na primer kupili istu knjigu koju vi sada
kupujete. Sistem preporučuje: “Ukoliko vam se dopada x knjiga, proverite i sledeće ponuđene
knjige”.
Kada uzimate kredit, banka prikuplja širok opseg informacija o vama, kao na primer prihodi,
godine staža, bračni status, kreditna sposobnost itd. Koriščenjem data mining tehnika, banka
može da predvidi da li ste dobar ili rizičan klijent za davanje kredita i takva informacija će
odlučivati o odobravanju kredita.
Data mining modeli
Nekoliko tehnika data mininga vam omogućava identifikovanje obrazaca u ogromnim broju podataka.
Uvodni primer
Koji je ključni atribut za predviđanje da li
će svršeni srednjoškolci upisati fakultet ili
ne?
Pretpostavimo da ste zainteresovani da odredite koji atribut ili kombinacija atributa imaju najveći
uticaj da predvidi verovatnoću studenata koji će upisati fakultet. Ovo je složeniji upit i zahteva
korišćenje tehnika data mininga.
Podaci se ubacuju u DM model koji ih analizira i traži pravila i obrasce koji bi se kasnije mogli iskoristiti za
predviđanje.
Podaci koji se analiziraju su obično:
Istorijski podaci
Statistički predstavnik slučajeva (cases) za koje gradite model.
Drugi razlog za integraciju data mining alata sa skladištem podataka jeste poboljšani
korisnički interfejs. Stariji data mining alati su zahtevali postojanje niza stručnjaka da bi se
postigli zadovoljavajući rezultati. Danas, svaki poznavalac SQL jezika može koristiti
mogućnosti data mininga.
ODBC
mreža
SQL
ograničeni i ODBC
specijalizovani
alati
data mining
alati
klijent strana
bilo koji alat
nestandardni
interfejsi
a) tradicionalni prilaz b) integrisani prilaz
Jedan od načina da se ostvari integracija jeste da se kreiraju modeli koji se u bazama podataka predstavljaju
tabelama. Na ovaj način se ovim modelima može pristupati upotrebom SQL naredbi. Nakon kreiranja ovih
tabela, u njih treba smestiti podatke koje će data mining alati da pretražuju. Obradom podataka, data mining
alati će kreirati nove tabele u kojima će smeštati rezultate i koji se mogu pregledati kao i sve ostale tabele
(korišćenjem SQL naredbi).
OLAP data mining
OLAP i data mining ne bi trebalo razmatrati kao odvojene procese već da ih treba u potpunosti spojiti.
Bez upotrebe OLAP data mininga, moguće je izostaviti ključne informacije ili se mogu dobiti netačni
rezultati.
UVOD U ACESS
Multifunkcionalni program; sastoji se od mnoštva povezanih alata za generisanje, organizovanje, izdvajanje,
prikazivanje, štampanje i objavljivanje podataka.
Da bi se okvalifikovala kao potpun sistem za upravljanje relacionom bazom podataka, aplikacija mora
da izvršava sledeće četiri osnovne funkcije, od kojih svaka ima sopstvenu prezentaciju za korisnika:
Makroi su sekvence aktivnosti, koje automatizuju operacije nad bazom podataka koje se ponavljaju.
Pri radu sa bazama podataka Access 2000, za automatizaciju se koristi Visual Basic for Application
(VBA).
Moduli su funkcije i procedure koje su napisane u programskom jeziku VBA. Funkcije VBA se
koriste da bi se izvršavala složenija izračunavanja od onih koja se mogu lako izložiti pomoću niza
konvencionalnih matematičkih simbola, ili za izračunavanja koja zahtevaju donošenje odluka. VBA
potprogrami napisani su za izvršavanje operacije koje prevazilaze mogućnosti standardnih aktivnosti
makroa što je jedan od razloga da se u Accessu napušta podrška makroima. VBA podprogrami se
izvršavaju tako što se pridružuju odgovarajućim događajima, kao što je pritisak na dugme pomoću
miša, koji se dešava kada je aktivni objekat neki obrazac ili izveštaj.
Bezbednost sačinjavaju funkcije koje su dostupne kao stavke menija i preko VBA potprograma.
Pomoću funkcija bezbednosti podataka može se dopustiti drugim osobama da koriste vašu bazu
podataka, u višekorisničkom okruženju. Pristup možete dodeliti grupi korisnika ili pojedincima, ali i
ograničite njihove mogućnosti za pregled ili modifikacije svih ili samo nekih tabela u bazi podataka.
Štampanje dopušta da odštampate praktično sve što možete da pregledate u radnom režimu programa
Accessa.
Mogućnost objavljivanja unapređuju distribuciju informacija preko intranet korporacije i javne
Internet mreže u obliku Word Wide Web strana. Access 2000 uvodi strane za pristup podacima (DAP
– Data Access Page). One vam dopuštaju da napravite aplikaciju za prikazivanje i ažuriranje podataka
na stranama, koje koriste prednosti jezika Dynamic HTML (DHTML) i Extensible Markup Language
(XML).
REŽIM RADA ACCESSA
• Sadrži upite, obrasce, izveštaje i makroe, koji su neophodni za prikaz podataka na razumljiv
način i za ažuriranje tih podataka ako je neophodno. (Objekti aplikacije).
• Od korisnika baze podataka ne zahteva se da znaju kako se projektuje bilo koji od elemenata
baze. Svi elementi baze podataka prethodno su u potpunosi definisani tokom projektovanja
aplikacije. U većini slučajeva, želite da onemogućite da drugi korisnici namerno ili slučajno
promene dizajn aplikacije.
• Automatizovana je pomoću VBA koda, tako da korisnici vrše izbor pomoću komandnih
dugmadi ili opcija iz namenski projektovanih menija, umesto iz lista u prozoru Database.
Access sadrži glavnu datoteku baze podataka koja se naziva datoteka radne grupe, pod nazivom
System.mdw. Ova datoteka sadrži sledeće informacije:
• Lozinke i jedinstveni binarni kod korisnika, koji se naziva System ID (SID) i koji identifikuje
korisnika koji trenutno koristi Access.
• Definicije prilagođenih paleta alatki u Accessu 2000, koje pravi svaki korisnik.
BIBLIOTEČKE BAZE PODATAKA PROGRAMA ACCESS
Još jedna kategorija datoteka, kod baza podataka u Accessu, pojavljuju se dopunski programi, koji se
nazivaju i biblioteke.
Dopunski programi predstavljaju bibliotečku bazu podataka Accessa, obično sa oznakama tipa .mde
ili .mda, da bi se razlikovali od korisničkih baza podataka, a sa Accessom možete da ih povežete
izborom alatke Add-In Manager (kojoj možete da pristupite izvorom opcije Tools, Add-Ins).
Kada povežete neku biblioteku Accessa, svi elementi te bibliotečke baze podataka biće vam dostupni
kada otvorite Access.
Strategija projektovanja baze podataka jeste da se ostvare sledeći ciljevi:
Eliminisanje ili smanjenje dupliranja sadržaja baze podataka unutar organizacije. U velikim
organizacijama, eliminisanje dupliranja može da zahteva distribuiranu bazu podataka. Distribuirane
baze podataka koriste više servera za čuvanje pojedinačnih baza podataka. Pojedinačne baze
podataka, jedna sa drugom povezane su preko lokalne mreže (LAN) ili regionalne mreže (WAN) tako
da ih korinik “vidi” kao jednu bazu podataka.
Obezbediti brz pristup određenim elementima baze podataka za sve kategorije korisnika. Brzina rada
zavisi od samog sistema za upravljanje relacionom bazom podataka, dizajna aplikacija, mogućnosti
računara servera i klijenta i karakteristika mreže.
Prilagoditi proširenje baze podataka za prihvatanje potreba organizacije koja se razvija, npr.
dodavanje novih proizvoda i procesa, ispunjavanje zakonskih regulativa i prihvatanje novih aplikacija
za obradu transakcija i podršku odlučivanju.
Očuvanje integriteta baze podataka tako da ona sadrži samo proverene informacije koje mogu da se
pregledaju. Većina klijent/server baza podataka nude ugrađene okidače za očuvanje integriteta baze
podataka i obavljanje drugih operacija. Okidači jesu skupovi pravila sadržani u bazi podataka.
Sprečavanje pristupa bazi podataka od strane neovlašćenih osoba. Access nudi bezbednosni sistem
koji od korisnika zahteva da unesu lozinke da bi otvorili određenu bazu podataka.
Dozvoliti pristup samo onim informacijama baze podataka koje su pojedinim korisnicima ili grupama
korisnika neophodne prema vrsti njihovog posla.
Olakšati izradu aplikacija za unos podataka, editovanje, prikazivanje i izradu izveštaja koje služe
korisnicima baze podataka.
Postupak projektovanja sistema relacione baze podataka sastoji se od 10 osnovnih
koraka:
TIPOVI RELACIJA
RELACIJA JEDAN-PREMA-JEDAN
Jednom redu u jednoj tabeli odgovara jedan red u drugoj tabeli. Ovakve tabele možete
kombinovati u jednu tabelu koja se sastoji od svih kolona obe tabele.
PRAVILA NORMALIZACIJE
Normalizacija je formalizovani postupak za grupisanje atributa podataka u tabele i tabela u
baze podataka.
Ciljevi normalizacije:
Eliminisanje dupliranih informacija u tabelama.
Prilagođavanje budućim izmenama u strukturi tabela.
Umanjivanje uticaja strukturnih izmena baze podataka na korisničke aplikacije koje pristupaju
podacima.
Upiti za izbor (Select Querys) izdvajaju podatke iz jedne ili više tabela i prikazuju te podatke u
tabelarnom obliku.
Upiti unakrsnih tabela (Crosstab queries) sumiraju podatke iz jedne ili više tabela u obliku radne
tabele. Ovakvi upiti su korisni za analiziranje podataka i izradu grafika ili dijagrama, na osnovu sume
vrednosti numeričkih polja većeg broja zapisa.
Akcioni upiti (Action queries) prave nove tabele iz tabela upita, ili prave velike izmene u nekoj tabeli.
Takvi upiti dopuštaju da dodate ili obrišete zapise iz tabele, ili napravite izmene u zapisima na osnovu
izraza koji unosite pri dizajnu upita.
Parametarski upiti (Parameter queries) čije se korišćenje ponavlja pri čemu se vrše samo jednostavne
izmene njihovih kriterijuma. Kad izvršavate parametarski upit, Access prikazuje okvir za dijalog koji
od vas zahteva da unesete novi kriterijum. Parametarski upiti zapravo nisu poseban tip upita, jer ove
parametarske funkcije možete da dodate u upite za izbor, upite unakrsnih tabela i u akcione upite.
1. Integritet entiteta zahteva da svi primarni ključevi moraju da imaju jedinstvene vrednosti unutar jedne
tabele. U Accessu su ugrađene dve metode za obezbeđivanje integriteta entiteta:
Polje ključa koristi AutoNumber tip podataka koji pravi jedinstvene vrednosti na
osnovu automatskog povećanja long celobrojne vrednosti.
Indeks na polju primarnog ključa sa svojstvom No Duplicates. Ako pokušate da
unesete dupliranu vrednost u polje ključa, Access javlja poruku o grešci.
2. Referencijalni integritet zahteva da za sve spoljne ključeve postoje vrednosti primarnog ključa bazne
tabele. Ovo pravilo zahteva da se spreče sledeći tipovi transakcija:
Dodavanje zapisa na strani “više” relacije tipa jedan-prema-više, a da ne postoji
odgovarajući zapis na strani “jedan” relacije.
Brisanje zapisa na strani “jedan” relacije tipa jedan-prema-više, a da se prvo ne obrišu
svi odgovarajući zapisi na strani “više” relacije.
Brisanje ili dodavanje zapisa tabeli koja je u relaciji tipa jedan-prema-jedan sa drugom
tabelom, a da se ne obriše ili doda odgovarajući zapis u povezanoj tabeli.
Menjanje vrednosti polja primarnog ključa bazne tabele od koje zavise zapisi u
povezanoj tabeli.
Menjanje vrednosti polja spoljnjeg ključa u relacionoj tabeli u vrednost koja ne postoji
u polju primarnog ključa bazne tabele.
ODRŽAVANJE BEZBEDNOSTI BAZE PODATAKA
Bezbednost baze podataka sprečava neovlašćene osobe da slučajno ili namerno pregledaju, menjaju,
brišu ili uništavaju podatke koji se u njoj nalaze.
Postoji deset osnovnih principa bezbednosti za baze podataka instalirane na lokalnoj mreži. Pet ovih
principa vezano je za mrežni operativni sistem (briga administratora mreže):
1. Svaki korisnik mreže mora biti ispravno identifikovan pre nego što dobije pristup mreži.
2. Svaki identifikovani korisnik mreže mora da bude ovlašćen za pristup određenim elementima mreže
kao što su omotnice na serverima, štampači i drugi zajednički resursi.
3. Aktivnosi korisnika mreže trebalo bi nadgledati da bi se utvrdilo da li korisnici pokušavaju da
pristupe elementima mreže za koje nemaju ovlašćenja. Korisnike koji više puta uzastopno pokušaju
da naruše bezbednost mreže trebalo bi isključiti iz mreže dok se ne preduzme odgovarajuća
administrativna akcija.
4. Mreža treba da je zaštićena od neovlašćenog korišćenja. To zahteva instaliranje bezbednosnog
sistema protiv hakerisanja i redovno testiranje prisustva virusa.
5. Podaci smešteni na mrežnim serverima moraju da budu zaštićeni od hardverskih kvarova i
katastrofalnih oštećenja (požari, zemljotresi itd.) odgovarajućim i pravovremenim pravljenjem
rezervnih kopija.
Većina klijent-server baza podataka prepoznaje sledeće tri grupe korisnika baze podataka:
1. Administratori (Admins) imaju ovlašćenja da pregledaju i ažuriraju postojeće tabele i dodaju ili obrišu
tabele i druge objekte baze podataka iz baze podataka. Članovi grupe Admins obično imaju dozvolu
da menjaju aplikacije sadržane u bazama podataka.
2. Obični članovi radnih grupa (Users) imaju dozvolu da otvore bazu podataka, a po potrebi im se
dodeljuje dozvola za pregledanje i menjanje baza podataka.
3. Povremenim korisnicima baza podataka (Guests) ćesto su dodeljena ograničena prava da koriste bazu
podataka i objekte koje ona sadrži, ali im se ne dodeljuje korisnički nalog.
1. Sadržaji tabela u bazi podataka trebalo bi da budu šifrovani kako bi se sprečilo pregledanje podataka
sa uslužnim programima za čitanje datoteka ili druga “njuškanja”.
2. Korisnici se moraju dodatno identifikovati pre nego što im se dozvoli da otvore datoteku baze
podataka.
3. Korisnicima mora da bude dodeljena posebna dozvola za korišćenje baze podataka i tabela koje ona
sadrži.
4. Podaci u tabelama trebalo bi da budu dostupni za pregledanje.