Seminarski Maturski Diplomski Rad

Pretraga Zabava O nama Kontakt
 
Pra PDF Štampa

Poslovanje u digitalnoj ekonomiji

  1. Digitalna ekonomija je ekonomija zasnovana na digitalnim tehnologijama uključujući komunikacione mreže (Internet, Intranet i extranet), računare, softvere i drugu tehnologiju.

  1. Sinonimi za digitalnu ekonomiju (digital economy) su Internet ekonomija (Internet economy), nova ekonomija (new economy) ili Web ekonomija (Web economy).

  1. E-business/e-commerce – elektronsko upravljanje poslovnim funkcijama (npr., kupovina i prodaja roba i usluga, opsluživanje klijenata, saradnja sa poslovnim partnerima).

  1. Infrastruktura za e-business je tzv. Network Computing, koji povezuje računare i druge elektronske uređaje putem telekomunikaiconih mreža.

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

  1. Internet je globalna kolekcija mreža koje povezuju računare korisnika širom sveta.

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

  1. Internet obezbeđuje univerzalnu vezu sa računarima, nezavisno od toga na koju pojedinačnu mrežu su oni priključeni.

  1. TCP/IP protokol omogućava komunikaciju između računara na kojima su instalirani različiti operativni sistemi.

Intranet i extranet

  1. Kada kompanija želi da deli svoje poslovne informacije za svojim dobavljačima, klijentima i drugim partnerima onda im ona dozvoljava ograničeni pristup svom Intranetu.

  1. Intranet koji je parcijalno dostupan autorizovanim korisnicima putem Interneta ili drugim sredstvima naziva se Extranet.

  1. Postavljanjem extraneta kroz Internet je mnogo lakše i ekonomičnije nego postavljanje iznajmljenog komunikacionog linka između dve kompanije.

  1. Međutim, extranet je manje bezbedan neko privatni Intranet zato što dozvoljava mogući pristup neautorizovanim korisnicima.

Nova ekonomija vs. stara ekonomija

Primer

Stara

Nova

Kupovina i prodaja knjiga

Poseta knjižari

Poseta web site-a izdavača i prodavaca

Prijavljivanje ispita na fakultetu

Šetnja kroz odelenja, čekanje ispred studentske službe itd.

On-line pristup fakultetu i prijavi ispita.

Fotografisanje

Kupovina filma, slikanje, davanje na razvijanje.

Upotreba digitalne kamere

Plaćanje robe

Odlazak u prodavnicu, plaćanje i otpremanje robe.

Korišćenje samouslužnih kioska

Plaćanje prevoza

Plaćanje u gotovom

Elektronske karte

  1. Internet dovodi do promena u ekonomiji, društvu i tehnološkim osnovama stare ekonomije.
  2. Organizacije razvijaju nove modele poslovanja, ekonomije i vlade.

“Pritisci” na poslovanje organizacije

  1. Poslovno okruženje je kombinacija socijalnih, pravnih, ekonomskih, fizičkih i političkih faktora koji utiču na aktivnosti poslovanja.

  1. Značajne promene u bilo kojim od ovih faktora dovodi do stvaranja poslovnog “pritiska” na organizaciju.

  1. 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:

  1. Globalna ekonomija i jaka konkurencija
  2. Promena prirode radne snage
  3. Moćni klijenti...

Tehnološki pritisak:

  1. Tehnološke inovacije i zastarelost
  2. Suviše informacija...

Socijalni pritisak:

  1. Regulacija (Statuti, uređenje, propisi) Vlade
  2. Trošenje na socijalne programe
  3. Zaštita od terorističkih napada
  4. Etnička pitanja...

IT podrška organizaciji

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

  1. Š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.

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

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

  1. Izvršavaju veoma brzo velika numerička izračunavanja.

  1. Obezbeđuju brzu, tačnu i jevtinu komunikaciju unutar i između organizacija.

  1. Automatizuju poluautomatske poslovne procese i manuelne zadatke.

  1. Skladište ogromnu količinu informacija u jednom lako pristupačnom i malom prostoru.

  1. Omogućavaju brz i jevtin pristup rasprostranjenim informacijama, worldwide.

  1. Olakšavaju interpretaciju ogromnih količina podataka.

  1. Omogućavaju komunikaciju i saradnju bilo gde i bilo kada.

  1. Povećavaju efektivnost i efikasnost ljudi koji rade u grupama na jednom mestu ili na nekoliko lokacija, bilo gde.

  1. Olakšavaju rad u rizičnom (hazardnom) okruženju.

IT arhitektura e-business-a

Infrastruktura informacione tehnologije

  1. Informaciona tehnologija – uključuje skup informacionih resursa, korisnika i menadžmenta koji ih nadgledaju, IT infrastrukturu i sve druge informacione sisteme u organizaciji.

  1. IT infrastruktura - podrazumeva fizičku opremu, IT komponente, IT usluge i IT menadžment koji podržava čitavu organizaciju.

  1. IT komponente su hardver, softver i komunikacione tehnologije koje koristi IT osoblje da bi proizvelo IT usluge.

  1. IT usluge uključuju razvoj sistema za upravljanje podacima i brigu o bezbednosti.

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

  • Zahtev u kompanijama – zaposleni treba da učestvuju u razvoju informacionog sistema i aplikacija.

Sistem

Informacioni sistem

  • Sistem u kome se veze između objekata i veze sistema sa okolinom ostvaruju razmenom informacija.

  • Organizovan skup komponenti za prikupljanje, prenos, skladištenje i obradu podataka u cilju dobijanja informacija potrebnih za pokretanje neke akcije ili donošenje neke odluke.
  • Uređeni i integrisani skup ljudi, podataka, procesa, interfejsa, mreža i tehnologija koja su u međusobnoj korelaciji u cilju podrške i poboljšanja svakodnevnih poslovnih operacija, a takođe i u cilju podrške menadžmentu u rešavanju poslovnih problema i donošenja odluka.

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.

  • Obavlja sistemsku analizu i projektovanje IS i računarskih aplikacija.

Sistemska analiza

  • Sistemska analiza podrazumeva:

– proučavanje domena poslovnih problema kako bi se predložila poboljšanja i

– Definisanje poslovnih zahteva koje treba da ispuni novo rešenje.

Projektovanje sistema

Projektovanje sistema podrazumeva definisanje i konstruisanje tehnički i računarski zasnovanih rešenja za identifikovane poslovne zahteve u sistemskoj analizi.

Informaciona tehnologija

Opisuje kombinaciju računarske tehnologije (hardvera i softvera) sa telekomunikacionom tehnologijom (mreža podataka, slika i glasa).

Klase informacionih sistema

  • Sistemi obrade transakcija
  • Menadžment informacioni sistemi
  • Sistemi za podršku odlučivanju
  • Ekspertni sistemi
  • Kancelarijski informacioni sistemi

Sistemi obrade transakcija

  • engl. Transaction Processing Systems – TPS

  • Aplikacije IS koje prikupljaju i obrađuju podatke o poslovnim transakcijama.

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

  • Aplikacije IS koje obezbeđuju menadžerski orjentisane izveštaje u predodređenom formatu obično zasnovane na matematičkim ili statističkim modelima.

Sistemi za podršku odlučivanju

  • engl. Decision Support Systems – DSS

  • Aplikacije IS koje pomažu korisnicima u procesu donošenja odluka.

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

  • Implementirani su sa tehnologijom veštačke inteligencije.

  • 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

Arhitektura informacionih sistema

  • Obezbeđuje jedinstveni kostur po kome će različiti ljudi sa različitim perspektivama (pogledima) organizovati i videti fundamentalne blokove razvoja informacionih sistema.

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.

  • PROCESI – aktivnosti koje izvršavaju misiju poslovanja.

  • INTERFEJSI – pokazuju kakav je međusoban uticaj sistema na ljude i druge sisteme.

  • GEOGRAFIJA – pokazuje gde su podaci uskladišteni i gde se odvijaju procesi i interfejsi.

Fundamentalni blokovi informacionog sistema

  • Preseci perspektiva (redova) i svakog fokusa (kolona) definišu fundamentalne blokove ili ćelije informacionog sistema.

  • Blokovi informacionog sistema ne egzistiraju izolovano, već moraju biti sinhronizovani kako bi se izbegle nedoslednosti i nekompatibilnosti unutar sistema.

Fundamentalni blokovi podataka

  • Pogled vlasnika sistema na sistem podataka

– zainteresovan za resurse poslovanja, kojih čine kupci, proizvodi, oprema, zgrade, porudžbine ili plaćanja. Njegov domen jeste da za svaki objekat i relacije između objekata identifikuje eventualne probleme, mogućnosti, ciljeve i ograničenja.

  • Pogled korisnika sistema na sistem podataka

– Korisnici svakodnevno prikupljaju, skladište, obrađuju, uređuju i koriste te podatke. Za njih su podaci smešteni po fasciklama, knjigama, organizovani po spreadsheets datotekama ili uskladišteni unutar baza podataka itd.

  • Pogled projektanta sistema na sistem podataka

– Projektanti sistema prevode zahteve korisnika u računarske datoteke i baze podataka. Pogled projektanta sistema na sistem podataka je u obliku šeme baze podataka.

  • Pogled graditelja sistema na sistem podataka

– Graditelji sistema su najbliži korisnici tehnologije baze podataka. Oni moraju da predstavljaju podatke u veoma preciznoj jezičkoj formi. Najkorišćeniji standardni upitni jezik koji omogućava komunikaciju sa bazom podataka jeste SQL (od početnih slova engleskih reči: Structured Query Language).

Fundamentalni blokovi procesa

  • Pogled vlasnika sistema na procese sistema

– Vlasnici sistema su zainteresovani za grupe procesa visokog nivoa nazvanih poslovne funkcije. Tipične poslovne funkcije su proizvodnja, špedicija, prodaja, usluge, računovodstvo i druge.

– Vlasnici sistema će pružiti informacije o zapaženim problemima, mogućnostima, ciljevima i ograničenjima funkcija. Takođe će želeti da diskutuju o troškovima i koristima oko projektovanja informacionog sistema.

  • Pogled korisnika sistema na procese sistema

– Korisnici vide odvojene poslovne procese.

– Poslovni procesi su odvojene aktivnosti koje imaju svoje ulaze i izlaze, kao i vremena početka i završetka.

– Reprojektovanje poslovnih procesa (Business Process Redesign - BPR) podrazumeva proučavanje, analizu i reprojektovanje osnovnih poslovnih procesa u cilju smanjenja troškova i poboljšanja vrednosti poslovanja.

– Izazov u sistemskoj analizi jeste da se identifikujuju, izraze i analiziraju zahtevi poslovnih procesa. Jedna od metoda sistemske analize, koja to omogućava, je model procesa.

  • Pogled projektanta sistema na procese sistema

– Na osnovu datih poslovnih procesa od strane korisnika sistema, projektant mora prvo da odredi koje procese treba automatizovati i kako ih automatizovati na najbolji mogući način.

– Aplikaciona šema je model koji govori o tome kako su i kako će biti implementirani poslovni procesi upotrebom računara i programa.

  • Pogled graditelja sistema na procese sistema

– Graditelji sistema prikazuju procese pomoću programskih jezika koji opisuju ulaze, izlaze, logiku i kontrolu.

– Neki primeri programskih jezika su C++, Visual BASIC, Java i dr.

– Aplikacioni programi su jezički-zasnovani, mašinski-čitljivi prikazi o tome šta bi računarski proces trebao da radi ili kako bi računarski proces trebao da ostvari svoje zadatke.

Fundamentalni blokovi interfejsa

  • Pogled vlasnika sistema na interfejs sistema

Model konteksta, dati sistem predstavlja kao jedini proces (koji se grafički nalazi na sredini stranice) i prikazuje sve ulazne i izlazne tokove procesa sa korisnicima, poslovnim jedinicama, kupcima i dr.

  • Pogled korisnika sistema na interfejs sistema

Korisnički interfejs definiše kako korisnici sistema pristupaju informacionom sistemu da bi uneli podatke, pravili upite, dobili izveštaje i koristili help (pomoć).

– Jedan od standarda korisničkog interfejsa jeste grafičko korisnički interfejs (GUI – Graphical User Interface) koji se ogleda u tome što se svi elementi, odnosno objekti GUI-a doslovno crtaju u grafičkom obliku, pri čemu programer ne mora da razmišlja o kodu koji se brine za njihovo kreiranje. Svim nacrtanim objektima mogu se podešavati razne osobine, koje određuju njihovo pojavljivanje i ponašanje na ekranu.

  • Pogled projektanta sistema na interfejs sistema

Korisnički dijalog u interakciji sa aplikacionim programom, opisuje kako se korisnik pomera sa ekrana na ekran kako bi obavio zadatak.

– Projektant sistema crta interfejs šemu, koja definiše osobine interfejsa, stanja sistema, događaje koji menjaju stanje sistema i odzive na događaje.

  • Pogled graditelja sistema na interfejs sistema

– Graditelji sistema izgrađuju, instaliraju, testiraju i implementiraju korisničke i sistemske interfejse.

– Jedna od interfejs tehnologija koja je danas dosta popularna je middleware (midlweæ(r)).

Middleware je koristan softverski sloj koji se nalazi između aplikacionog i sistemskog softvera, a služi da transparentno integriše različite tehnologije kako bi one mogle da funkcionišu.

– Jedan primer middleware jeste povezanost otvorenih baza podataka (Open Database Connectivity – ODBC). ODBC alati dozvoljavaju aplikacionim programima da rade sa različitim sistemima za upravljanje bazama podataka (Database Management Systems – DBMS) bez potrebe da budu prerađeni usled nijansi i različitosti sistema za upravljanje bazama podataka.

Fundamentalni blokovi geografije

  • Informacioni sistem geografije opisuje (1) distribuciju podataka, procesa i interfejsa na određene poslovne lokacije i (2) kretanje podataka i informacija između ovih lokacija.

  • Pogled vlasnika sistema na geografiju sistema

– Vlasnik sistema određuje operativne lokacije i određuje da li će sistem biti centralizovan, distribuiran ili dupliciran, dok sistem analitičar mora da zna koje poslovne funkcije se odvijaju na svakoj od lokacija, da li su neke funkcije duplicirane, da li ih obezbeđuje jedna ili više lokacija, koje lokacije mora da opsluži informacioni sistem itd.

– Sistem analitičar će zajedno sa vlasnikom sistema utvrditi mape, planove prostora i matrice koje pokazuju koje se poslovne funkcije obavljaju na određenoj lokaciji.

  • Pogled korisnika sistema na geografiju sistema

– Korisnika sistema će zanimati individualne kancelarije ili druge prostorije unutar zgrade.

Komunikacioni zahtevi definišu zahteve operativnih lokacija za informacionim resursima i definišu način njihovog međusobnog komuniciranja.

– Informacioni resursi operativnih lokacija uključuju ljude, podatke, procese i interfejse koji su neophodni na svakoj od lokacija. Sistem analitičar prikazuje mrežu jednog informacionog sistema koristeći dijagram toka podataka između lokacija.

  • Pogled projektanta sistema na geografiju sistema

Šema mreže (mrežna konfiguracija ili topologija) je tehnički model koji identifikuje sve računske centre, računare i mrežni hardver koji će biti uključeni u računarsku aplikaciju.

– Zadatak projektanta jeste da odredi optimalnu distribuciju podataka, procesa i interfejsa kroz mrežu.

  • Pogled graditelja sistema na geografiju sistema

– Graditelji sistema koriste telekomunikacione jezike i standarde za pisanje mrežnih programa.

Mrežni programi su mašinski-čitljive specifikacije računarski komunikacionih parametara kao što su adrese čvora, protokoli, brzine linija, kontrola tokova, bezbednost, privilegije i drugi kompleksni mrežni parametri.

– Obično je osnovna softver tehnologija za mreže već kupljena i instalirana, ali ona mora biti instalirana, konfigurisana i podešena prema zadatim performansama. Primeri komunikacionih softvera koji uključuju mrežne operativne sisteme su Netware, OS/2 LAN Manager, Windows/NT Server itd.

SISTEMSKI INŽENJERING POMOĆU RAČUNARA - CASE

Šta su CASE alati?

  1. Sistemski inženjering pomoću računara (CASE) je jedna aplikacija informacione tehnologije koja je okrenuta ka sistemskom razvoju aktivnosti, tehnika i metodologija.

  1. CASE alati su programi (softveri) koji automatizuju i podržavaju jednu ili više faza životnog ciklusa razvoja sistema.

  1. Namera ove tehnologije jeste da ubrza procese razvijanja sistema i poboljša njegov kvalitet.

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

  1. CASE nije metodologija niti bilo kakva njena alternativa.

  1. CASE je tehnologija koja podržava metodologije naročito strategije, tehnike i standarde.

  1. CASE tehnologija automatizuje celokupnu metodologiju razvoja sistema.

Koristi od primene CASE alata

  1. Poboljšana produktivnost (kroz automatizaciju zadataka i ubrzan razvoj aplikacija).

  1. Poboljšani kvalitet (CASE alati proveravaju kompletnost, konzistentnost i kontradiktornost).

  1. Bolja dokumentacija (alati olakšavaju kreiranje i sakupljanje konzistentne, visoko-kvalitetne dokumentacije).

  1. Smanjeno vreme održavanja (prethodno spomenuta poboljšanja kvaliteta sistema se kombinuju sa boljom dokumentacijom).

  1. Metodologije koje stvarno rade (kroz primenu pravila i ugrađene ekspertize).

METODE SISTEMSKE ANALIZE

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.

  • Sistemska analiza je metodološki postupak dekompozicije nekog sistema na podsisteme (komponente) sa ciljem da se prouči njihov međusobni uticaj i rad.

  • 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 podataka je najpopularnija tehnika za izražavanje poslovnih zahteva za podacima koji će biti uskladišteni u bazu podataka sistema.

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

– GEOGRAFIJA – Usled činjenice da današnji poslovni i informacioni sistemi imaju veću geografsku širinu, sistem analitičari pronalaze načine da modeliraju geografske lokacije. Modeli mreže služe kao polazna tačka za dizajniranje komunikacionih sistema za distribuiranje podataka, procesa i interfejsa do različitih geografskih lokacija.

MODELI PODATAKA

Osnovni pojmovi modela podataka

  • Objekat je klasa osoba, mesta, objekata, događaja ili koncepata o kojima treba da prikupljamo i skladištimo podatke.

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

  • Atribut je osobina ili karakteristika objekta.

  • Tip podatka definiše koja klasa podataka može biti skladištena u taj atribut.

  • Domen definiše koje vrednosti može da ima jedan 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.

  • Grupa atributa koja jedinstveno identifikuju objekat se zovu složeni ključ.

ŠIFRA_KASETE (PRIMARY KEY)

. ŠIFRA_NASLOVA

. BROJ_KOPIJE

  • 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

Uvod u modeliranje procesa

  • Modeliranje procesa je tehnika koja organizuje i dokumentuje procese sistema i/ili implementira logiku, politike i procedure sistema.

  • 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

Hijerarhijska dekompozicija dijagrama toka podataka

  • Dekompozicija je način razlaganja sistema na njegove komponente podsisteme, procese i podprocese.

  • Pri dekompoziciji DTP-a moraju se poštovati sledeća pravila:

– Dijagram najvišeg nivoa, koji po pravilu sadrži samo jedan proces koji predstavlja ceo IS, zatim spoljne objekte sa kojima IS komunicira i odgovarajuće tokove podataka naziva se dijagram konteksta.

– Dijagram prvog nivoa predstavlja dekompoziciju dijagrama konteksta. Procesi se označavaju brojevima 1,2,3, ....

– Svaki proces sa dijagrama prvog nivoa se dalje dekomponuje do nivoa primitivnih procesa Procesi na dijagramima nižih nivoa, povlače sa sobom brojnu oznaku nadređenog procesa.

– Uobičajeno je da se zatim celokupan sistem predstavi dijagramom dekompozicije. Dijagram dekompozicije prikazuje top-down (sa vrha na dole) funkcionalnu dekomoziciju i strukturu sistema.

– Pored procesa, mogu se dekomponovati i tokovi i skladišta. Njihov opis se detaljno daje u rečniku podataka.

– Najvažnije pravilo koje se mora poštovati pri dekompoziciji procesa je pravilo balansa tokova.

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.

PROJEKTOVANJE INFORMACIONIH SISTEMA

Faze projektovanja IS

  • Faza konfiguracije:

– identifikuje alternativna rešenja, analizira njihova izvodljivost i preporučuje globalno rešenje sistema.

– Za svako alternativno rešenje treba da se odrede zahtevani hardver i softver.

– Kod analize izvodljivosti mnogi analitičari imaju u vidu sledeće kriterijume:

  • Tehnička izvodljivost. Da li je rešenje tehnički praktično? Da li je osoblje tehnički osposobljeno da projektuje i izgrađuje to rešenje?
  • Operaciona izvodljivost. Da li će rešenje ispuniti korisničke zahteve? Do kog stepena? Kako će rešenje promeniti korisničko radno okruženje? Šta korisnici misle o takvom rešenju?
  • Ekonomska izvodljivost. Da li je rešenje troškovno efektivno?
  • Izvodljivost programa. Da li rešenje može biti projektovano i implementirano u toku prihvatljivog vremenskog perioda?

– Analiza troškova i koristi se diskutuje sa vlasnicima i korisnicima rešenja.

– Rangiraju se sva alternativna rešenja prema kriterijumu izvodljivosti.

– Pismeni izveštaj koji sadrži analize i preporuke najboljeg rešenja.

  • U toku faze nabavke vrši se izbor odgovarajućeg hardvera i/ili softvera za novi sistem. Osnovni ciljevi ove faze su:

– Identifikovati i ispitati hardver i softver koji može da podrži preporučeno rešenje.

– Potražiti, proceniti i rangirati ponude dobavljača.

– Izabrati i preporučiti najbolju ponudu dobavljača.

– Odrediti zahteve za integracijom dodeljenih proizvoda dobavljača sa drugim proizvodima sistema.

  • U okviru faze projektovanja i integracije razvija se tehničko rešenje sa kojim će moći da se konstruiše sistem. Projektant sistema mora da obavi sledeće aktivnosti:

– Analizira i distribuira podatke.

– Analizira i distribuira procese.

– Projektuje bazu podataka.

– Dizajnira računarske inpute (ulaze) i autpute (izlaze).

– Dizajnira korisničke interfejse.

– Prezentuje dizajn.

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

  • Sistem za upravljanje bazom podataka (kraće DBMS, od početnih slova engleskih reči Database Management Systems) je softverski sistem koji kreira, pristupa, upravlja i kontroliše podacima (bazama podataka) i služi kao veza (interfejs) između podataka i aplikativnih programa.

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

  • Danas, sistemi za upravljanje bazom podataka se zasnivaju na relacionoj tehnologiji.

  • Relaciona baza podataka implementira podatke u seriji dvodimenzionalnih tabela koje su u međusobnoj relaciji preko spoljnih ključeva.

Primer logičkog i fizičkog modela podataka

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:

  • Dekartov proizvod od n skupova D1 x D2 x...Dn je skup svih mogućih uređenih n-torki tako da je d1 Î D1, d2 Î D2 ...dn Î Dn.

Na primer data su dva skupa brojeva:

D1 = {1,2,3,4} i D2 = {4,6}

D1 x D2 = {,,,,,,,}.

  • 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/2}

R = {, }.

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.

  • Operacije nad relacijama mogu da se grupišu u:

– Konvencionalne skupovne operacije (unija, presek, razlika i Dekartov proizvod),

– Specijalne relacione operacije (projekcija, selekcija, spajanje i deljenje),

– Dodatne operacije relacione algebre (operacije koje su se kasnije dodavale originalnoj relacionoj algebri da bi se povećala njena moć kao upitnog jezika),

– Operacije ažuriranja baze,

– Operacije sa null vrednostima.

Operacije relacione algebre

  • Unija

– Ako su date relacije R1 i R2 koje zadovoljavaju uslove kompatibilnosti, onda je rezultat operacije unije R3 = R1 U R2 relacija R3 koja sadrži sve n-torke koje se pojavljuju bilo u R1, bilo u R2.

– 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

– Ako su date relacije R1 i R2 koje zadovoljavaju uslov kompatibilnosti, onda je rezultat operacije preseka R3 = R1 ∩ R2 relacija R3 koja sadrži n-torke koje se pojavljuju u obe relacije R1 i R2.

– Operacije unije i diferencije su pogodne za ažuriranje baze podataka.

– 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 A B

a b

a ?

  • RR = S[Starost>24 AND MestoRodj = ‘Beograd’] RADNIK

RadnikID MLB Ime Starost MestoRodj OdelID

110 11971717... Mika 33 Beograd odel1

111 22975718... Pera 29 Beograd odel1

  • Spajanje

– 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

Pr2= Građanin [Građanin.MLB=Student.MLB] Student

Pr2 (MLB, Ime, Starost, MestoRođ, MLB, BrInd, Smer)

1111 Ana 19 Beograd 1111 155/01 Kompjuterski

2222 Mirko 21 Valjevo 2222 255/02 Izvršno upravljanje

3333 Zoran 20 Beograd 3333 322/01 Međunarodno poslovanje

  • Deljenje

– pogodna za upite u kojima se javlja reč "svi".

– Primer:

  • Iz relacija Predmet i Prijava prikazati brojeve indeksa studenata koji su položili sve predmete.

  • Predmet (PredmetID, NazivPredmeta) Prijava (BrInd, PredmetID)

p1 Matematika 155/01 p1

p2 Marketing 155/01 p3

p3 Informatika 255/01 p2

322/01 p1

155/01 p2

  • Prijava [Prijava.PredmetID ÷ Predmet.PredmetID] Predmet

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.

  • Dobra je ona struktura baze podataka u kojoj je logička redundansa minimalna.

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

OCENA®BI, ŠIFRA_PREDMETA

OCENA®¾BI

OCENA®¾ŠIFRA_PREDMETA

Atribut OCENA je potpuno funkcionalno zavisan od složenog atributa BI, ŠIFRA_PREDMETA.

NAZIV_PREDMETA®BI, ŠIFRA_PREDMETA

NAZIV_PREDMETA®¾BI

NAZIV_PREDMETA®¾ŠIFRA_PREDMETA

Tranzitivna funkcionalna zavisnost

  • Atribut C je tranzitivno funkcionalno zavisan od atributa A, ako je funkcionalno zavisan od A i ako je funkcionalno zavisan od nekog atributa B koji je i sam funkcionalno zavisan od A.

  • Tranzitivna zavisnost dovodi do veće redundanse.

  • STUDENT(BI, IME, SEM, ŠIFRA_SMERA, IME_RUK).

Prva normalna forma

  • Proces normalizacije predstavlja transformaciju početne tabele u jednu ili više korektnih tabela (relacija) u kojima su svi atributi potpuno funkcijski zavisni od ključa, a međusobno funkcijski nezavisni.

  • Cilj normalizacije je da eliminiše redudansu u atributima i sa time omogući lakše održavanje integriteta podataka i jednostavniju manipulaciju.

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

  • Ova relacija ima sledeće anomaliije u održavanju baze podataka:

anomalije u dodavanju: ukoliko je po novom nastavnom planu definisan novi predmet, ne mogu se ubaciti podaci o tom predmetu dok ga neki student ne položi.

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:

STUDENT1 (BI, IME_STUDENTA, SEMESTAR, ŠIFRA_SMERA, IME_RUK)

PRIJAVA (BI, ŠIFRA_PREDMETA, NAZIV_PREDMETA, OCENA)

  • 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že®Relacija 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.

PRIJAVA (BI, ŠIFRA_PRED, NAZ_PRED, OCENA),

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

PRIJAVA1(BI, ŠIFRA_PREDMETA, OCENA)

PREDMET(ŠIFRA_PREDMETA, NAZIV_PREDMETA)

Treća normalna forma

  • Relacija R je u Trećoj normalnoj formi (3NF) ako i samo ako je u 2NF i ako svi njeni neključni atributi netranzitivno funkcionalno zavise od primarnog ključa.

STUDENT1 (BI, IME, SEM, ŠIFRA_SMERA, IME_RUK)

  • 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:

STUDENT2 (BI, IME, SEM, ŠIFRA_SMERA)

SMER (ŠIFRA_SMERA, IME_RUK)

Boyce-Codd-ova normalna forma (BCNF)

PRIJAVA (BI, ŠIFRA_PREDMETA, NAZIV_PREDMETA, OCENA)

  • Pretpostavimo da važe sledeće funkcionalne zavisnosti:

NAZIV_PREDMETA®BI, ŠIFRA_PREDMETA

OCENA®BI, ŠIFRA_PREDMETA

NAZIV_PREDMETA®ŠIFRA_PREDMETA

ŠIFRA_PREDMETA®NAZIV_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, OCENA®BI, ŠIFRA_PREDMETA (D) (KK)

ŠIFRA_PREDMETA, OCENA®BI, NAZIV_PREDMETA (D) (KK)

NAZIV_PREDMETA®ŠIFRA_PREDMETA (D)

ŠIFRA_PREDMETA®NAZIV_PREDMETA (D),

sve determinante nisu kandidati za ključ pa relacija nije u BCNF.

  • Dekompozicijom, pri kojoj se iz relacije izvlače projekcije sa onim determinantama koje nisu kandidati za ključ, relacije se svodi na BCNF.

PRIJAVA1 (BI, ŠIFRA_PREDMETA, OCENA)

PREDMET (ŠIFRA_PREDMETA, NAZIV_PREDMETA)

Dekomozicija na zavisne i nezavisne projekcije

STUDENT1 (BI, IME, SEM, ŠIFRA_SMERA, IME_RUK)

se može svesti na 3NF na sledeća dva načina:

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

Četvrta normalna forma

PROGRAM (PREDMET, NASTAVNIK, KNJIGA)

  • 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:

NASTAVNIK®®PREDMET KNJIGA®®PREDMET

  • 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 A®®R1(A,B) i R2 (A,C) ako i samo ako važi A C).®® B, tada postoji i višeznačna zavisnost A®®postoji višeznačna zavisnost A

RASPORED (PREDMET, NASTAVNIK)

UDŽBENIK (PREDMET, KNJIGA)

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

Peta normalna forma

  • U relaciji R(X,Y, ... Z) postoji zavisnost spajanja ako i samo ako relacija R rezultuje iz prirodnog spajanja njenih projekcija po X, Y, ..., Z, gde su X,Y, .. Z podskupovi atributa relacije R.

  • Relacija R je u Petoj normalnoj formi (5NF) ako i samo ako se svaka zavisnost spajanja može pripisati kandidatu za ključ.

STUDENT2 (BI, IME, SEM, ŠIFRA_SMERA)

R1 (BI, IME)

R2 (BI, SEM)

R3 (BI, ŠIFRA_SMERA)

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

PRIJAVA(BI, ŠIFRA_PREDMETA, NAZIV_PREDMETA, OCENA)

  • 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

Zaštita baze podataka

  • Termin integritet podataka označava tačnost, korektnost ili konzistentnost.

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

  • Zaštitu baze podataka tretiramo kroz dva aspekta i to:

Integritet – zaštita od slučajnog pogrešnog ažuriranja i

Sigurnost – zaštita od neovlašćenog ažuriranja i korišćenja podataka.

Pravila integriteta

  • Pravila integriteta definišu koje uslove podaci u BP treba da zadovolje, kada se vrši provera i koje akcije treba preduzeti kada definisani uslovi nisu zadovoljeni.

  • Pravila integriteta se dele u dve klase:

Pravila integriteta domena – definišu se za vrednosti pojedinih atributa nezavisno od vrednosti ostalih atributa u BP (karakterističan primer je integritet objekta), i

Pravila integriteta relacija – odnose se na relaciju kao celinu, odnosno definišu kada neka n-torka može da se ubaci u relaciju ili kako n-torke jedne relacije zavise od n-torki druge relacije (karakterističan primer je referencijalni integritet).

Pravila integriteta domena

  • Definišimo domen STAR, nad kojim je definisan atribut STAROST relacije RADNIK:

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.

Pravila integriteta relacije

  • Najznačajnija pravila integriteta relacija su referencijalni integriteti.

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

  • Akcije koje se preduzimaju ako uslov integriteta nije zadovoljen su sledeće:

– RESTRICTED – Kada se uslov ispituje pre operacije održavanja i ako nije zadovoljen, operacija se odbija, uz odgovarajuću poruku.

– NULLIFIES – Spoljni ključ dobija nula vrednost, ako je nula vrednost dozvoljena.

– DEFAULT – Spoljni ključ dobija neku difoltnu vrednost koju treba unapred predvideti u definiciji odgovarajućeg domena.

– CASCADES – Operacija se prenosi na relaciju koju referiše spoljni ključ, da bi se u njoj izvršile promene koje će zadovoljiti uslov integriteta.

Pravila integriteta relacija kod povezivanja objekata

  • Ukoliko posmatramo dva objekta koja su u vezi (prvi objekat nazvaćemo domen, a drugi objekat koji je sa njim u vezi nazvaćemo kodomen), i želimo da ih povežemo (connect). Akcije koje se mogu preduzeti su sledeće:

– RESTRICTED – operacija se odbija jer ne postoji objekat kodomen.

– NULLIFIES – umesto sa navedenim objektom kodomena, ako to pojavljivanje ne postoji, povezivanje se izvršava sa specijalnim pojavljivanjem kodomena, tzv «nula objektom», čije je značenje «nepoznati objekat».

– DEFAULT – umesto sa navedenim objektom kodomena, ako to pojavljivanje ne postoji, povezivanje se izvršava sa «default» objektom kodomena. Pretpostavlja se da se difolt objekat kodomena definisan.

– CASCADES – ako objekat kodomena sa kojim dati objekat domena treba da se poveže ne postoji moguće ga je prvo kreirati operacijom insert (ubaci), pa zatim izrvšiti odgovarajuće povezivanje.

Pravila integriteta relacija kod razvezivanja objekata

  • Operacija disconnect (razveži) raskida vezu objekta domena sa nekim kodomenom i na taj način, ako je posmatrano preslikavanje obavezno, narušava odgovarajuće strukturno ograničenje.

– RESTRICTED – odbija se operacija.

– NULLIFIES – razvezuje se pojavljivanje objekta domena od navedenog pojavljivanja objekta kodomena i vezuje za «nula objekat» kodomena.

– DEFAULT – razvezuje se pojavljivanje objekta domena od navedenog pojavljivanja objekta kodomena i vezuje za «default» objekat kodomena.

– CASCADES – izbacuje se pojavljivanje objekta domena koji posle operacije disconnect ostaje da «visi».

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

SQL naredbe za dodelu ovlašćenja pristupa bazi podataka

  • Ovlašćenje korisnicima, prema SQL standardu, se daje pomoću naredbe GRANT.

GRANT privilegije [ON objekat] TO subjekat [WITH GRANT OPTION]

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

Structured Query Language (SQL)

Osnovne SQL naredbe

  • Naredba SELECT - Izbor podataka iz tabela

SELECT SIFRA_PRED, NAZIV, MESTO

FROM PREDUZECE;

SELECT *

FROM RADNICI;

  • Naredba CREATE TABLE - kreiranje tabela

CREATE TABLE PREDUZEĆE

(SIFRA_PRED NUMBER (2) NOT NULL,

NAZIV CHAR (14),

MESTO CHAR (13))

CREATE TABLE RADNICI

(STFRA_RADN NUMBER (4) NOT NULL,

PREZIME CHAR (10),

RADNO_MESTO CHAR (10),

RUKOV NUMBER (4),

DATUM_ZAPOSL DATE,

PLATA NUMBER (7,2),

STIMUL NUMBER (7,2),

SIFRA_PRED NUMBER (2))

  • Naredba INSERT - Ubacivanje redova u tabelu

INSERT INTO PREDUZEĆE

VALUES (30, ‘PRODAJA’, ‘BEOGRAD’);

  • Klauzula WHERE - Izbor određenih redova

SELECT *

FROM RADNICI

WHERE SIFRA_PRED = 30;

  • Konektor AND - višestruki uslovi pretraživanja

SELECT PREZIME, RADNO_MESTO, PLATA

FROM RADNICI

WHERE RADNO_MESTO = ‘DIREKTOR’

AND PLATA > 22000;

  • Konektor OR - alternativni uslovi pretraživanja

SELECT PREZIME, RADNO_MESTO, PLATA

FROM RADNICI

WHERE RADNO_MESTO = ‘DIREKTOR’

OR PLATA > 22000

SELECT PREZIME, RADNO_MESTO, ŠIFRA_PRED

FROM RADNICI

WHERE RADNO_MESTO =‘DIREKTOR’

AND ŠIFRA_PRED != 30;

  • Operator BETWEEN - Pretraživanje raspona podataka

SELECT PREZIME, PLATA

FROM RADNICI

WHERE PLATA BETWEEN 12000 AND 15000;

  • Operator IN - Pretraživanje vrednosti u listi

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.

  • Klauzula ORDER BY - Redosled slogova

.

– Ako želimo da prikažemo listu zaposlenih u odeljenju 30, ali da odgovarajući slogovi budu prikazani po stavci plate, u rastućem redosledu napisaćemo:

SELECT PLATA, RADNO_MESTO, PREZIME

FROM RADNICI

WHERE ŠIFRA_PRED = 10

ORDER BY PLATA;

ORDER BY klauzula sortira redove u rastućem nizu, tako da je najmanja plata na prvom mestu liste.

  • Klauzula DESC - Opadajući niz

SELECT RADNO_MESTO, PLATA, PREZIME

FROM RADNICI

ORDER BY RADNO_MESTO, PLATA DESC;

  • Klauzula DISTINCT - Eliminacija duplih slogova

SELECT DISTINCT RADNO_MESTO

FROM RADNICI;

  • Upit JOIN - Povezivanje više tabela

SELECT NAZIV, PREZIME, RADNO_MESTO, PLATA

FROM RADNICI, PREDUZEĆE

WHERE RADNICI.ŠIFRA_PRED = PREDUZEĆE.ŠIFRA_PRED

ORDER BY NAZIV, PLATA DESC;

  • Klauzula GROUP BY - Grupna funkcija

– Grupna funkcija dozvoljava da izaberete sumarne informacije iz grupe redova (slogova). Na primer, radnike iz istog odeljenja stavljamo u jednu grupu kako bi pronašli maksimalnu platu u svakoj od tih grupa.

SELECT ŠIFRA_PRED, MAX (PLATA)

FROM RADNICI

GROUP BY ŠIFRA_PRED;

SELECT NAZIV, RADNO_MESTO, SUM (PLATA),COUNT (*), AVG (PLATA)

FROM RADNICI, PREDUZEĆE

WHERE RADNICI.ŠIFRA_PRED = PREDUZEĆE.ŠIFRA_PRED

GROUP BY NAZIV, RADNO_MESTO;

– SUM - Sabira vrednosti polja definisanih u GROUP BY klauzuli.

– COUNT - Brojač broja redova koji pripadaju svakoj od ovih grupa.

– AVG - Nalazi prosečnu vrednost određenih polja.

  • PODUPITI - Upit unutar postojećih upita

SELECT PREZIME, RADNO_MESTO

FROM RADNICI

WHERE RADNO_MESTO =

(SELECT RADNO_MESTO

FROM RADNICI

WHERE PREZIME = ‘JOVIĆ’);

SELECT PREZIME, PLATA

FROM RADNICI

WHERE PLATA >

(SELECT AVG (PLATA)

FROM RADNICI);

  • Naredba UPDATE - Izmena vrednosti u poljima

UPDATE RADNICI

SET PLATA = PLATA + 100

WHERE RADNO_MESTO = ‘PROJEKTANT’;

  • Naredba INSERT - Dodavanje novih slogova

INSERT INTO STIMULACIJA (PREZIME, RADNO_MESTO, PLATA, STIMUL)

SELECT PREZIME, RADNO_MESTO, PLATA, STIMUL

FROM RADNICI

WHERE STIMUL > 0.25 * PLATA;

  • Naredba DELETE - Brisanje slogova iz tabele

DELETE FROM PREDUZEĆE

WHERE ŠIFRA_PRED = 40 ;

  • CREATE VIEW - Kreiranje pogleda

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

– Ciljevi pogleda su:

  • pojednostavljenje pristupa podacima,
  • obezbeđenje nezavisnosti podataka i
  • obezbeđenje trajnosti podataka.

CREATE VIEW PRED10 AS

SELECT ŠIFRA_PRED, PREZIME, RADNO_MESTO

FROM PREDUZEĆE

WHERE ŠIFRA_PRED = 10;

Aritmetrički izrazi u okviru SQL-a

  • Aritmetički operatori

SELECT PREZIME, PLATA, STIMUL, PLATA + STIMUL

FROM RADNICI

WHERE RADNO_MESTO = ‘REFERENT’;

Oporavak baze podataka i upravljanje izvršenjem transakcija

  1. Baza podataka je zajednički resurs koga konkurentno (istovremeno) koriste veći broj programa.

  1. Kod istovremenog korišćenja može doći do mnogih neželjenih efekata, kao na primer:
    1. 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).
    2. 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).
    3. 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).

  1. Osnovni cilj baze podataka je da omogući efikasnu obradu transakcija (jedno izvršenje neke logičke jedinice posla ili programa).

Transakcije

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

  1. Osnovni cilj baze podataka je da omogući efikasnu obradu transakcija.

  1. Transakcija mora da poseduje sledeći skup osobina:
    1. Atomnost – skup aktivnosti nad bazom podataka koje se izvršavaju po principu “sve ili ništa” (ili su sve aktivnosti uspešno obavljene ili je BP ostala nepromenjena) je atomski skup aktivnosti.
    2. Konzistentnost – izvršenje transakcije treba da prevede BP iz jednog u drugo konzistentno stanje.
    3. Izolacija – Transakcija ne treba da svoje promene BP učini vidljivim drugim transakcijama pre nego što se ona okonča.
    4. Trajnost – Kada su u BP potvrđene promene koje je izvršila neka transakcija, ove promene se više ne mogu izgubiti.

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

  1. U savremenim DBMS transakcije mogu biti “ugnježdene”, odnosno dozvoljeno je da se jedna transakcija smesti u drugu. Naredba COMMIT ugnježdene transakcije stvarno ne potvrđuje promene u bazi dok se uspešno ne okonča i transakcija na najvišem nivou ugnježdenja.

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

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

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

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

  1. Kada se izda instrukcija ROLLBACK sistem, koristeći vrednosti pre za datu transakciju, ažurira odgovarajuće objekte baze podataka.

Konkurentna obrada transakcija

  1. Transakcija se u sistemima zasnovanim na bazi podataka ne obavlja u izolaciji, već konkuretno (uporedo) sa drugim transakcijama u sistemu.

  1. Više transakcija mogu istovremeno zahtevati iste resurse, isti rekord baze podataka.

  1. Nekontrolisana međusobna interferencija transakcija može da dovede bazu u nekonzistentno stanje.

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

  1. Komponenta koja upravlja celokupnim izvršenjem transakcija naziva se Menadžer transakcije.

Protokoli zaključavanja

  1. Za razliku od konkuretnog , serijsko izvršenje transakcija je izvršenje u kome se transakcije ne prepliću, već se prvo potpuno izvrši jedna, pa onda druga transakcija.

  1. Velika je verovatnoća da ničim ograničeno izvršenje jednog skupa transakcija neće biti serijabilno.

  1. Zadatak planera izvršenja je da proveri serijabilnost nekim i da spreči da neserijabilna izvršenja naruše integritet baze podataka.

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

  1. Ovaj mehanizam upravljanja izvršenjem skupa transakcija omogućava da transakcija “zaključa” (postavi lokot) na objekat baze kome je pristupila, da bi onemogućila da druge transakcije nekorektno operišu sa istim objektom.
  2. Postoje više različitih vrsta zaključavanja, neke od njih su:
    1. Ekskluzivno zaključavanje (exclusive (XL) lock ili write lock) – ako neka transakcija postavi ekskluzivni lokot na objekat baze, nijedna druga transakcija ne može da taj objekat postavi bilo koji drugi lokot.
    2. Deljivo zaključavanje (shared (SL) lock ili read lock) – ukoliko neka transakcija postavi deljivi lokot na objekat baze, neka druga transakcija takođe može da postavi deljivi lokot na isti objekat baze, ali nijedna druga ne može da postavi eksluzivni lokot na taj objekat.

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

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

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

  1. Problem “živog lokota” se jednostavno rešava uvođenjem nekog redosleda zaključavanja objekta (na primer FIFO).

  1. Za razrešavanje problema mrtvih lokota koriste se tri tehnike:
    1. Prekidanje transakcije posle isteka intervala vremena – koristi se parametar timeout koji menadžer lokota dodeljuje transakciji pri pokušaju zaključavanja nekog objekta. Ukoliko istekne vreme transakcija se poništava i ponovo startuje;
    2. Prevencija lokota – definisanje različitih protokola koji će sprečiti da dođe do mrtvog čvora. Na primer uređenje elemenata baze, gde se blokovi uređuju po njihovim adresama na spoljnoj memoriji (A1
    3. Detekcija “mrtvog čvora” – dozvoljava se da dođe do mrtvog lokota, ali transakcija koja ga je izazvala se ubija i njeni efekti na bazu se poništavaju.

Dugačke transakcije

  1. Postoje aplikacije u kojima su transakcije mnogo duže, reda desetine minuta, sati ili čak nekoliko dana. Prikazani mehanizmi zaključavanja u kome bi neka transakcija ovako dugo ekskluzivno zaključala elemente baze koje koristi je neprihvatljivo.

  1. Primeri aplikativnih sistema sa dugim transakcijama su:
    1. Neke transakcije u poslovnim aplikacijama – na primer ispitivanje svih računa u nekoj banci kako bi se proverilo ukupno stanje računa banke.
    2. Projektni sistemi – CAE, CAD, CASE i dr preko kojih se projektuju različiti inženjerski sistemi. Pretpostavlja se da više projektanata radi na istom projektu i da postoji zajednička baza projekta. Jedan projektant može da preuzme jedan deo podataka iz baze i da sa njim radi svoj deo projekta i nekoliko dana. Očigledno postoji potreba za istim podacima od strane i drugih projektanata.
    3. Workflow sistemi – sistemi u kojima se jedna logička jedinica posla za korisnika, obavlja preko sekvence aktivnosti od kojih neke mogu biti programi, neke interaktivne aplikacije dok su neke realizovane i potpuno ručno.

Koncept “saga”

  1. Standardni skup čvorova u UML-u je proširen za čvor “Neuspešan kraj aktivnosti – abort” da bi se uveo osnovni koncept u teoriji upravljanja dugačkom transakcijama – koncept “sage”.

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

  1. Konkurentno upravljanje sagama se obavlja na sledeći način:

  1. Svaka aktivnost se može tretirati kao posebna “kratka” transakcija koja se izvršava pod kontrolom konvencionalnih mehanizama za upravljanje transakcijama.
  2. 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

  1. Oporavak baze podataka je vraćanje baze podataka u korektno stanje posle nekog otkaza.

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

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

  1. Tipična strategija za oporavak baze podataka je:
    1. Ukoliko su oštećenje memorijske lokacije (na primer, pad glave diska) koristi se poslednja arhivska kopija cele baze za njen oporavak.
    2. Kada baza nije fizički oštećena, oporavak se vrši korišćenjem loga, preko posebno definisanih protokola oporavka. U ovom slučaju DBMS vodi računa o sledećim otkazima:
      1. Softverski ili hardverski otkaz koji ne oštećuje bazu (nestanak napajanja);
      2. Otkaz u samoj transakciji, na primer zbog deljenja sa nulom;
      3. Akcije sistema za konkurentnu obradu transakcija, ubijanje transakcije koja je izazvala mrtvi lokot ili neserijabilnost izvršenja skupa transakcija i sl.

Projektovanje korisničkog interfejsa

Koraci projektovanja korisničkog interfejsa

  • Korak 1: Grafički prikazati dijalog

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

  • Korak 2: Napraviti prototip dijaloga i korisnički interfejs

  • Na osnovu dijagrama prelaznog stanja prave se prototipovi za svaki od procesa.

  • Korak 3: Obezbediti povratnu vezu od korisnika

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

Uvod u Data Warehousing i OLAP

Pregled sadržaja

  1. Uvod u Data Warehousing

¡ Razumevanje data warehouse sistema je veoma bitno kada se projektuju i implementiraju sistemi za podršku odlučivanju.

  1. Projektovanje Data Warehouse

¡ Pre nego što se kreira OLAP baza podataka, neophodno je razumeti komponente data warehouse-a koje se koriste pri izgradnji OLAP baze podataka.

  1. Definisanje OLAP rešenja

¡ OLAP tehnologija predstavlja jednu alternativu tehnologiji relacione baze podataka. OLAP nudi brzi i fleksibilan pregled podataka, analizu i navigaciju.

  1. Razumevanje OLAP modela i primena OLAP kocke

¡ Kako primeniti koncepte projektovanja Data Warehouse-a da bi se projektovali i kreirali OLAP modeli.

¡ Opisuju se osnove OLAP kocke demonstriranjem metoda za vizuelizaciju multidimenzionalnih baza podataka.

Sirovi podaci vs. poslovne informacije

  1. Kompanija svakodnevno prikuplja velike količine podataka. Ti podaci su često sirove činjenice koje odražavaju tekuće stanje poslovanja.

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

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

  1. OLTP (on-line transaction processing) sistemi su operacioni sistemi koji prikupljaju poslovne transakcije i snabdevaju podacima data warehouse ili data mart.

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

  1. Primeri OLTP operacionih sistema: aplikacije praćenja porudžbina, aplikacije usluga klijenata (npr., otvaranje računa klijentima), bankarske funkcije (npr, depoziti) itd.

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

Data Warehousing (DW)

  1. Skladištenje podataka - DW je proces integracije podataka u jedan repozitorijum iz kojeg krajnji korisnici mogu sprovoditi ad-hock analize podataka i praviti izveštaje.

  1. Skladište podataka je baza podataka za procese podrške odlučivanju u kojoj su podaci:

¡ Subjektno-orjentisani – odslikavaju poslovne procese,

¡ integrisani – baza podataka konsoliduje podatke iz različitih sistema koji koriste razne vrste kodovanja, mernih jedinica itd. i obezbeđuje konzistentnost podataka,

¡ vremenski zavisni – svi podaci su u vezi sa nekim vremenskim trenutkom na osnovu kojeg se podaci mogu i porediti,

¡ nepromenljivi – podaci se, najčešće, pridodaju već postojećim umesto da ih zamenjuju.

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

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

  1. 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".

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

  1. Warehousing omogućava donošenje strateških odluka – Strateške odluke zahtevaju predviđanje, statistike, simultane funkcije i analizu vremenskih serija. Warehousing pristup omogućava brzu manipulaciju, lokalne proračune za analize trendova, kreiranje tabela i grafika u cilju izrade i slanja izveštaja korišćenjem Internet servisa.

  1. Multidimenzionalna struktura - Da bi se ovakav rad skladišta podataka ostvario koristi se multidimenzioni model, koji reflektuje način na koji korisnik misli o svojim poslovnim podacima i pritom pravi kondenzovane izveštaje, koji prikazuju tekst, slike i multimediju kao dodatak izveštajima i grafikonima.

Karakteristike Data Warehouse-a

  1. Organizacija. Podaci su organizovani po predmetu i sadrže relevantne informacije za podršku odlučivanju.

  1. Konzistentnost. Podaci u različitim operacionim bazama podataka se drugačije šifriraju. U DW ti podaci će biti šifrovani na konzistentan način.

  1. Vremenski. Podaci se čuvaju mnogo godina kako bi se iskoristili za praćenje trendova, prognoze i vremensko poređenje.

  1. Multidimenzionalni. Obično data warehouse koristi multidimenzionalnu strukturu.

  1. Web-zasnovani. Danas je DW dizajniran tako da obezbedi jedno efikasno okruženje za web zasnovane aplikacije.

Komponente DW sistema

  1. DW sistem sadrži mnoge komponente koje prenose podatke sa izvornih sistema do korisnika koji izvršavaju analizu podataka:

¡ 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

  1. Pri izgradnji skladišta podataka najbitniji su sami podaci, a ne poslovni procesi i funkcije, kao što je to slučaj sa transakcionim sistemima.

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

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

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

  1. Analiza izvora podataka prolazi kroz sledeće faze:

1.1. Prikupljanje zahteva,

1.2. Planiranje skladišta podataka,

1.3. Izbor tehnike analize podataka.

1.1. Prikupljanje zahteva

  1. U ovoj fazi razvoja skladišta podataka, razmatraju se poslovne potrebe i zahtevi budućih korisnika sistema.

Prikupljanje izvornih (source-driven) zahteva

  1. Metoda bazirana na definisanju zahteva korišćenjem izvornih podataka u proizvodno-operativnim sistemima. Ovo se radi analiziranjem ER-modela izvornih podataka.

  1. Glavna prednost:

¡ podržavanje svih podataka,

¡ svođenje na minimum vreme potrebno korisniku u ranim fazama (stanjima) projekta.

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

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

  1. Glavna prednost ovog pristupa je što se koncentriše na ono što je potrebno, a ne na ono što je dostupno.

  1. Ovaj pristup proizvodi upotrebljivo skladište podataka u kraćem vremenskom periodu.

  1. Postupak prikupljanja zahteva:

¡ Intervjuisanje ključnih ljudi u organizaciji, npr: analitičari, menadžeri i izvršioci.

¡ Utvrditi protok informacija u i iz svakog odelenja (koji izveštaji i dokumentacija pristižu u odelenje, kako se koriste, ko ih koristi, koliko često pristižu itd.

¡ Dobijene podatke organizovati u nekoliko sekcija, kao što su:

  1. Podaci o analizi (podaci o svim vrstama analiza koje se trentuno koriste) i
  2. Zahtevi vezani za podatke (opis svih polja podataka koja se koriste, novi detalja, izvori).

¡ Organizovane podatke proslediti svim učesnicima intervjua radi mišljenja i eventualnih korekcija.

1.2. Planiranje skladišta podataka

  • Planiranje skladišta podataka sastoji se od sledećih zadataka:
  • Definisanje obima projekta,
  • Kreiranje projektnog plana,
  • Definisanje tehničkih uslova,
  • Definisanje resursa, zadataka i vremenskih rokova.

  • Pre početka razvoja projekta treba da se razmotri arhitektura i infrastruktura skladišta podataka:

  • Tehnička infrastruktura – podrazumeva razne tehnologije, platforme, baze podataka i ostale komponente koje podržavaju izabranu arhitekturu skladišta podataka. Tehnička infrastruktura uključuje i izbor instalacije baze podataka, podešavanje mrežnog okruženja, kao i izbor i instalaciju alata za rad sa bazom podataka.

1.3. Izbor tehnike analize podataka

  • Skladište podataka se gradi da bi se obezbedio lako pristupačan izvor podataka visokog kvaliteta.

  • Postoji nekoliko tehnika analize podataka:

a. Upiti i izveštaji,

b. Višedimenzionalne analize i

c. Data mining.

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

b. Višedimezionalna analiza - je način da se prošire mogućnosti upita i izveštaja. Ovo znači da se umesto izvršavanja višestrukih upita podaci struktuiraju da bi se omogućio brz i lak pristup odgovorima na pitanja koja se tipično postavljaju.

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

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

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

c. Tehnika analize podataka – Data mining

  1. Data mining je relativno nova tehnika analize podataka.

  1. Tehnika otkrivanja - Veoma je različita od upita i izveštaja, kao i od višedimenzionalnih analiza, po tome što koristi tehniku otkrivanja. Ovo znači da ne pitate određeno pitanje već koristite određene algoritme koji analiziraju podatke i izveštavaju šta su otkrili.

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

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

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

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

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

  1. Ova faza se sastoji od sledećih zadataka:

a. razvoj procedura za ekstrakciju podataka,

b. razvoj procedura za čišćenje podataka.

a. Razvoj procedura za ekstrakciju podataka

¡ Podaci koji će se koristiti u skladištu podataka moraju se ekstrahovati iz transakcionih sistema (baza podataka u okviru nekog sistema) koji sadrže te podatke.

¡ Podaci se inicijalno ekstrahuju u procesu kreiranja skladišta podataka, a kasnije se na osnovu određnih procedura vrši dodavanje novih podataka u skladište podataka.

¡ Ekstrakcija podataka je vrlo jednostavna operacija, ako se potrebni podaci nalaze u jednoj relacionoj bazi, ali može da bude i veoma kompleksna operacija, ako su podaci smešteni u višestrukim heterogenim transakcionim sistemima. Cilj procesa ekstrakcije podataka je da sve potrebne podatke, u pogodnom i konzistentnom formatu, pripremi za učitavanje u skladište podataka.

b. Razvoj procedura za čišćenje podataka

  1. Zbog problema koji se prilikom ekstrakcije podataka javljaju, podaci dobijeni ekstrakcijom se moraju "čistiti". Čišćenje podataka podrazumeva: proveru postojanja logičkih grešaka, "poboljšanje" podataka i eliminisanje ostalih grešaka.

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

¡ Eliminisanje ostalih grešaka je proces u kome se odlučuje o sudbini podataka koji su nepotpuni ili nemaju veliko značenje. Ovi podaci se mogu odbaciti, privremeno smestiti i popraviti ili smestiti u skladište podataka sa tim svojim nesavršenostima.

2.2. Transformacija podataka

  1. U ovoj fazi potrebno je:

¡ definisati izvore podataka i tipove transformacija koje treba izvršiti nad podacima i

¡ ostvariti mapiranje podataka iz izvorišta u odredišta.

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

  1. Faza mapiranja i transformacije podataka sastoji se od sledećih zadataka:
    1. kreiranje plana transformacije podataka,
    2. razvoj procedura za transformaciju podataka,
    3. razvoj procedura za učitavanje podataka,
    4. testiranje procedura,
    5. generisanje meta podataka.

a. Kreiranje plana transformacije podataka

  1. Planom je potrebno odrediti najbolji put migracije izvornih podataka do skladišta podataka. Analiziraju se raspoloživi resursi, količina izvornih podataka, različite izvorne šeme, različiti načini pristupanja podacima, struktura skladišta podataka i potreban broj agregacija. Planom se dokumentuju sve izvorne platforme, metode pristupa i programski jezik koji je potreban za ekstrakciju podataka.

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

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

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

  1. Transformacija podataka je kritičan korak u razvoju skladišta podataka. U okviru procesa transformacije vrši se poslednja priprema podataka pre učitavanja.

  1. Tipična transformacija podataka uključuje:

¡ prevođenje polja sa više imena u jedno polje,

¡ razbijanje polja sa datumom u posebna polja za godinu, mesec i dan,

¡ prevođenje polja sa jednom reprezentacijom u drugu (npr. sa 1 i 0 u DA i NE),

¡ kreiranje i dodavanje ključeva za tabele dimenzija.

c. Razvoj procedura za učitavanje podataka

  1. Procedure za učitavanje podataka treba da izvršavaju sledeće aktivnosti:

¡ Kreiranje formata podataka. Za sve podatke iz starijih sistema moraju se obezbediti formati pogodni za smeštanje u skladište podataka.

¡ Prenošenje podataka iz starijih sistema u skladište podataka. Vrši se raspakivanje podataka, njihovo poređenje, kombinovanje i transformacija u oblik pogodan za skladište podataka.

¡ Kreiranje agregacija. Kreiranje agregacija je postupak sortiranja podataka po određenim atributima na osnovu kojih se, zatim, vrši sumiranje. Tako sumirani podaci se smeštaju 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.

¡ Indeksiranje podataka. Po završenom procesu smeštanja podataka u skladište podataka, svi indeksi se moraju ažurirati.

d. Testiranje procedura

  1. Da bi se utvrdila ispravnost rada procedura za ekstrakciju i učitavanje podataka, mora se izvršiti njihovo testiranje.

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

  1. Po završenoj transformaciji, postoje svi uslovi da se pristupi generisanju meta podataka.

e. Izrada meta baze podataka

  1. Meta baza podataka, odnosno rečnika podataka je baza podataka o bazi podataka.

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

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

3. Izgradnja skladišta podataka

  1. Prvi korak je identifikacija dimenzija i atributa koja podseća na klasično projektovanje upotrebom ER modela i zove se dimenziono modeliranje.

  1. Dimenziono modeliranje je tehnika logičkog dizajna čiji je cilj prezentacija podataka u obliku koji obezbeđuje visoke performanse sistema radi vršenja analize podataka.

  1. U dimenzionom modeliranju, strukture podataka su tako organizovane da opisuju mere i dimenzije.

¡ Mere su numerički podaci smešteni u centralnoj, takozvanoj tabeli činjenica (fakt tabela).

¡ Dimenzije su standardni poslovni parametri koji definišu svaku transakciju.

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

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

  1. Tabele činjenica sadrže podatke koji su, najčešće, numeričkog tipa i mogu sadržati veliki broj zapisa.

Dimenzioni modeli

  1. Dimenzioni modeli su standardnog oblika te se mogu predvideti interfejsi koji će biti od koristi korisnicima skladišta podataka.

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

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

  1. Fizička arhitektura dimenzionog modela je šema zvezde.

Primeri dvodimenzionih i trodimenzionih modela podataka

  1. Podaci o prodaji za svaku oblast se nalaze u različitim tabelama
  2. Svi podaci smešteni su u trodimenzioni niz

Zadaci izgradnje skladišta podataka

  1. Izgradnja skladišta podataka se sastoji od sledećih zadataka:

  1. denormalizacija podataka,
  2. definisanje hijerarhija,
  3. kreiranje agregacija,
  4. kreiranje fizičkog modela,
  5. generisanje baze podataka,
  6. učitavanje podataka.

a) Denormalizacija podataka

  1. Kod denormalizovanog modela dimenzije su organizovane u šemu zvezde, a kod normalizovaog u šemu snežne pahuljice.

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

  1. Ovi problemi se mogu rešiti normalizacijom dimenzija, čime se šema zvezde prevodi u šemu pahulje.

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

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

  1. Š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

Arhitektura dimenzionog modela – šema zvezde

  1. Fizička arhitektura dimenzionog modela opisana je pomoću šeme zvezde definisane sa dve vrste tabela – dimenzione tabele (dimension table) i tabele činjenica (fact table).

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

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

  1. Velika mana šeme zvezde je što se povećava redundantnost podataka.

  1. b) Definisanje hijerarhija
  2. Dimenzione tabele memorišu sledeće elemente:

¡ traženje hijerarhijskih relacija u svakoj dimenziji,

¡ definisanje opisnih atributa svake dimenzije.

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

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

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

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

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

Agregacije zasnovane na SQL naredbama

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

Agregacije koje nisu zasnovane na SQL naredbama

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

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

  1. d) Kreiranje fizičkog modela
  2. U okviru kreiranja fizičkog modela baze podataka, izvodi se postupak prevođenja logičkog modela u fizički model prikazan preko dijagrama entiteti – veze koji fokusira podatke.

  1. Neposredno pre kreiranja modela treba izabrati sistem za upravljanje bazama podataka na kome će biti implementirana baza podataka.

  1. Generisanje fizičkog modela treba da reši probleme:

¡ Multiplikativnosti - definiše broj instanci jednog entiteta (buduća tabela u bazi) u relaciji sa jednom instancom drugog entiteta.

¡ Referencijalnog integriteta - zahteva da unesena vrednost atributa odgovara vrednosti atributa koji je primarni ključ druge tabele. Referenacijalni integritet se definiše za operacije ubacivanja, brisanja i ažuriranja.

¡ Kreiranja indeksa - je izvršeno automatski za sve primarne ključeve u entitetima i za prenesene ključeve u entitetu Ispit. Ovo se radi iz razloga što će se buduća pretraživanja u okviru skladišta podataka vršiti na osnovu ovih polja.

  1. e) Generisanje baze podataka
  2. Aktivnost generisanja baze podataka vrši se korišćenjem SQL jezika. Naime, alat u kome je izvršeno kreiranje fizičkog modela (npr. ERWin) omogućava automatsko generisanje koda preko takozvanih DDL (Data Definition Language) datoteka.

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

  1. Kada se svi ovi poslovi uspešno urade, baza (skladište) podataka je generisana.

f) Učitavanje podataka

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

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

  1. OLAP rešenja omogućavaju korisnicima brz i fleksibilan pristup podacima i predstavljaju nadgradnju skladišta podataka.

  1. Interaktivno analitičko procesiranje (On line Analytical Processing – OLAP) namenjeno je on-line analizama i izveštavanjima.

  1. Krajnjem korisniku je neophodno sledeće:

¡ da može da postavi bilo koje poslovno pitanje,

¡ da bilo koji podatak iz preduzeća koristi za analizu,

¡ mogućnost neograničenog izveštavanja.

  1. U tu svrhu se koriste analitički OLAP sistemi koji obezbeđuju informacije koje se koriste za analizu problema ili situacija.

  1. 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.
  2. OLAP sistemi omogućavaju jednostavnu sintezu, analizu i konsolidaciju (agregacija podataka po zadatom kriterijumu) podataka.

  1. Koriste se za intuitivnu, brzu i fleksibilnu manipulaciju transakcionim podacima.

  1. OLAP sistemi podržavaju kompleksne analize koje sprovode analitičari i omogućavaju analizu podataka iz različitih perspektiva (poslovnih dimenzija).

  1. OLAP sistemi kao skladišta podataka koriste multidimenzionalnost i denormalizaciju.

  1. Osnovni elementi OLAP sistema su:

¡ baza podataka, koja služi kao osnova za analizu,

¡ OLAP server, za upravljanje i manipulaciju podacima,

¡ interfejs sistem, prema korisniku i prema drugim aplikacijama,

¡ alati za administriranje.

Poređenje OLTP, DW i OLAP.

OLAP serveri

  1. OLAP pristup mora od hardvera da poseduje poseban računar, tzv. OLAP server, na koji se povezuju relacione BP, eksterni izvori podataka i ostali interni podaci, koji su podržani grafičkim interfejsima, radnim tabelama i ostalim PC alatima.

  1. OLAP serveri koriste višedimenzione strukture za čuvanje podataka i veza između njih.

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

  1. OLAP serveri podržavaju tipične analitičke operacije:

¡ konsolidacija – ovom operacijom se vrši agregacija podataka po zadatom kriterijumu,

¡ drill down/up – ove operacije omogućavaju prikazivanje više ili manje detalja podataka,

¡ isecanje (slice & dice) – ove operacije obezbeđuju prikazivanje podataka iz različitih perspektiva, pri čemu se isecanje najčešće vrši po vremenskoj dimenziji da bi se analizirali trendovi (na primer, jedan isečak kocke može prikazivati sve podatke o prodaji za zadati tip proizvoda za sve regione, a drugi isečak može prikazivati sve podatke o prodaji po kanalima za svaki tip proizvoda).

Zahtevi OLAP sistema

  1. Interfejs OLAP sistema treba da omogući korisniku komforan rad, samostalno izvođenje analitičkih operacija i dobijanje pregleda i poslovne grafike, bez znanja programiranja i strukture baze podataka.

  1. Zahtevi koje OLAP mora da ispuni su:

¡ mogućnost rada sa velikim skupom podataka i velikim brojem korisnika,

¡ kratko vreme odziva na upit,

¡ mogućnost rada sa podacima sa različitim nivoima detalja,

¡ sposobnost proračuna složenih matematičkih funkcija,

¡ podrška za šta-ako analizu, modelovanje i planiranje,

¡ jednostavnost uvođenja i održavanja sistema,

¡ zaštita podataka,

¡ mogućnost rada sa velikim brojema alata pomoću kojih će se pristupati podacima, vršiti analiza i prikazivati podaci.

Komponente OLAP baze podataka

  1. OLAP baza podataka je definisana sledećim komponentama:

¡ Numeričke mere – Mere su vrednosti podataka ili činjenice koje korisnici analiziraju. Primeri mera su Prodaja, Jedinice, Troškovi prodate robe itd.

¡ Dimenzije – dimenzije predstavljaju poslovne kategorije koje obezbeđuju kontekst numeričkim merama. Dimenzijama OLAP je lakše navigirati nego dimenzijama šeme zvezde..

¡ Kocke – Kocke kombinuju sve dimenzije i sve mere u jedan konceptualni model.

OLAP dimenzije vs. Relacione dimenzije

Definisanje kocke

  1. Kocka je logička struktura skladištenja OLAP baze podataka.

  1. Kocka kombinuje dimenzije i mere kako bi korisnici mogli da prave upite.

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

  1. Mere su numeričke vrednosti koje korisnici analiziraju.

  1. Svaka kocka mora da sadrži barem jednu meru, ali ne može da ima više od 1024 mera.

  1. Karakteristike mere su:

¡ Mere su numeričke;

¡ Mere odgovaraju činjenicama u tabeli činjenica. Samo jedna tabela činjenica se može koristiti za kreiranje kocke;

¡ Mere su preseci svih dimenzija i nivoa ...

  1. Kocka skladišti vrednosti prodaje za svaki proizvod, svako tržište i za svaki period vremena.
  2. Da bi dobili ukupnu godišnju vrednost, korisnici biraju proizvod i tržište i sumiraju ćelije iz sva četiri kvartala.

Pravljenje upita nad kockom

¡ Kocka “Prodaja” sadrži tri dimenzije: Vreme, Proizvodi i Tržišta. Činjenice o prodaji su skladištene u presecima svih dimenzija u kocki. Korisnik koji nadgleda prodaju jabuka u Atlanti želi upit za Q4 prodajne vrednosti.

Definisanje “kriške” (engl. slice) ili podskupa kocke

Menadžer distribucije trešnji želi da pregleda podatke o trešnji po svim periodima i za sva tržišta.

Rad sa dimenzijama i hijerarhijama

  1. Glavna svrha OLAP baza podataka je da obezbede fleksibilne modele za pronalaženje podataka. Dimenzije i hijerarhije omogućavaju tu fleksibilnost.

  1. Dimenzije omogućavaju slice i dice:

¡ Slice - izbor jednog člana iz dimenzije. Na primer: ukoliko želite da se fokusirate na samo jedan proizvod, slice vam omogućava da ignorišete sve osim željenog proizvoda.

¡ Dice – kada primenjujete dice na kocki, onda postavljate više članova iz jedne dimenzije na jednu osu i više članova druge dimenzije na drugu osu. Ovakav način vam omogućava da sagledate među odnose članova različitih dimenzija.

  1. Hijerarhija vam omogućava drill down i drill up:

¡ Drill Down - Sve dimenzije sadrže hijerarhiju i za većinu dimenzija hijerarhija se sastoji od više nivoa. Više nivoa hijerarhije omogućava drill down po jednom članu hijerarhije. Drill down omogućava da se fokusirate samo na određene podatke ili oblast problema.

¡ Drill Up – Vide se samo zbirne informacije članova. Omogućava da se sagleda opšta slika.

  1. Dimenzije vam dozvoljavaju

¡ Slice

¡ Dice

  1. Hijerarhije vam dozvoljavaju
    1. Drill Down
    2. Drill Up

Arhitekture OLAP sistema

  1. Postoje sledeće arhitekture OLAP sistema:
  2. višedimenzioni OLAP (MOLAP),
  3. relacioni OLAP (ROLAP),
  4. hibridni OLAP (HOLAP).

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

  1. MOLAP baze podataka imaju sledeća ograničenja:

¡ ograničenje fizičke veličine skupa podataka sa kojima mogu da barataju.

¡ ograničenje na broj dimenzija koje još uvek obezbeđuju dobre performanse sistema.

¡ Da bi se vršila bilo kakva analiza, potrebno je prvo učitati podatke u višedimenzione strukture. Pri tome se vrše razni proračuni da bi se kreirale agregacije i popunili podaci, što vremenski može trajati relativno dugo. Po završenom procesu, korisnik može započeti analizu.

  1. Prednost MOLAP sistema je što obezbeđuju odlične performanse sistema kada se radi sa već sračunatim podacima (agregacijama).

  1. Nedostatak MOLAP sistema je teškoća dodavanja novih dimenzija

Arhitektura MOLAP sistema

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)

  1. ROLAP sistemi pristupaju podacima direktno iz skladišta podataka i rade sa relacionim bazama podataka.

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

  1. Kod ROLAP sistema ne postoje ograničenja po pitanju broja dimenzija koja postoje u slučaju MOLAP sistema.

Karakteristike ROLAP i MOLAP sistema

  1. Neke karakteristike MOLAP i ROLAP sistema:

¡ ROLAP sistemi su optimizovani za pristupanje podacima, dok su MOLAP sistemi optimizovani za prikupljanje podataka.

¡ Prednost ROLAP sistema je što su sumarne tabele kreirane direktno u RSUBP-u, čime se obezbeđuje kratko vreme odziva sistema na upit, i što su tabele veoma čitljive.

¡ Višedimenziona analiza moguća je korišćenjem ROLAP i MOLAP sistema,

¡ Za manje količine podataka ROLAP sistemi imaju skoro iste performanse kao i MOLAP sistemi,

¡ MOLAP sistemi nisu pogodni za rad sa velikim skupom podataka,

¡ MOLAP sistemi su manji od ROLAP sistema, te je potrebno manje U/I operacija pri pribavljanju podataka, što uslovljava da su MOLAP sistemi brži.

c. Hibridni OLAP (HOLAP)

  1. HOLAP alati mogu pristupati i relacionim i višedimenzionim bazama podataka.

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

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

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

  1. Potrebe korisnika su:

¡ višedimenzioni pogled na podatke – ovu mogućnost poseduju i MOLAP i ROLAP alati,

¡ odlične performanse sistema – ovu mogućnost poseduju MOLAP alati,

¡ analitička fleksibilnost (za potrebe simulacija) – ovu mogućnost poseduju MOLAP alati,

¡ pristup podacima u realnom vremenu – ovu mogućnost poseduju ROLAP alati,

¡ veliki kapacitet podataka – ovu mogućnost poseduju ROLAP alati.

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.

    1. Koja je svrha OLAP-a?

Da obezbedi brz, fleksibilan pristup multidimenzionalnim podacima kako bi korisnici mogli da vrše analize i prave izveštaje.

    1. Definišite glavne relacione komponente od kojih se gradi OLAP kocka.

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.

Uvod u Data mining

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

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

  1. 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".

  1. Data mining je proces otkrivanja znanja (Knowledge Discovery in Databases - KDD). koji omogućuje korisnicima da shvate sisteme i veze između njihovih podataka.

  1. Data mining otkriva oblike i trendove u sadržaju ove informacije.

  1. Data mining otkriva relacije našeg svakodnevnog komuniciranja sa podacima.

Definisanje Data mininga

  1. Osnovna poruka data mininga jeste da je potrebno da iz ogromne količine operativnih podataka i veza koje se ne mogu odmah sagledati definišu odgovarajuće relacije, obrasci ponašanja, što u krajnjem slučaju treba da od podataka da potrebne informacije.

  1. Data mining se može definisati kao proces podrške odlučivanju u kojem se traže šabloni infomacija u podacima.

  1. Osnovni cilj data mininga jeste otkrivanje skrivenih veza, predvidivih sekvenci i tačnih klasifikacija.

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

  1. 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”.

  1. Upravljanje kreditnim rizikom

¡ 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

  1. Nekoliko tehnika data mininga vam omogućava identifikovanje obrazaca u ogromnim broju podataka.

  1. Modeli Analysis Services SQL Servera su

¡ Clustering – tehnika klasteringa omogućava grupisanje zapisa podataka koji su slični. Na primer, sa klasteringom možete segmentirati klijente sa sličnim karakteristikama u grupe.

¡ Drvo odlučivanja – popularan metod za klasifikaciju i predviđanje. Korišćenjem serije pitanja i pravila za kategorizaciju podataka, mogu se predvideti da će izvesni tipovi imati specifične ishode.

¡ Neuronske mreže – kao što čovek uči na osnovu iskustva tako može i računar. Neuronske mreže modeluju neuronske veze u ljudskom mozgu i na taj način simuliraju učenje. Ukoliko sastavljate podatke gde su ulazne i izlazne činjenice poznate, računar može da nauči iz tih obrazaca i postavi pravila i matematičke faktore kako bi npr., pomogao izračunavanje ili predvideo izlaznu vrednost. Pretpostavimo da želite da prodate kola, nekoliko faktora utiče na prodajnu cenu kao što su godine, stanje, proizvođač, model itd. Analizirajući cene kola, neuronske mreže mogu da kreiraju seriju ulaznih i izlaznih faktora kako bi predvideli cenu prodaje.

¡ Memorijsko zasnovano prosuđivanje – Memory-based reasoning (MBR) je tehnika data mininga koja se koristi za predviđanje i klasifikaciju. Na primer, ukoliko pacijent ima nekoliko simptoma, doktor će na osnovu iskustva sa sličnim pacijentima dati dijagnozu. Doktor izvršava dijagnozu koristeći oblik MBR-a.

¡ Analiza pijačne torbe – Market Basket Analysis se često zove i grupisanje po sličnosti (affinity grouping) se koristi za pronalaženje grupe artikla koji se najčešće zajedno događaju u jednoj transakciji.

Uvodni primer

  1. Koji je ključni atribut za predviđanje da li će svršeni srednjoškolci upisati fakultet ili ne?

  1. Postavljana su im sledeća pitanja:

¡ Kog su pola?

¡ Koliki je prihod njihovih roditelja?

¡ Koliki im je IQ?

¡ Da li ih roditelji ohrabruju da nastave studiranje ili ne?

¡ Da li planiraju da upišu fakultet?

  1. Da bi na osnovu prikupljenih podataka utvrdili koliko studenata će nastaviti školovanje, neophodno je da se postavi upit koji broji zapise studenata koji žele i onih koji ne žele da nastave školovanje.

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

  1. Primenjujući algoritam drveta odlučivanja otkrivene su sledeće relacije:

¡ Najuticajniji atribut je ohrabrivanje njihovih roditelja da upišu fakultet. Oni studenti koje roditelji ohrabruju da upišu fakultet, 60 % planira da upiše fakultet i to uglavnom oni sa visokim IQ..

Koraci kod izgradnje DM modela

  1. Izbor tehnike data mininga
  2. Identifikovanje slučaja (case)
  3. Izbor entiteta koji treba da se predvidi
  4. Identifikovanje podataka za analizu
  5. Opciono kreiranje dimenzije i virtuelne kocke iz rezultujućeg modela
  6. Obrada modela i prikupljanje rezultata.

Metodologija kreiranja Data Mining modela

Da bi kreirali model morate da prikupite skup podatka, gde su atributi koji treba da se predvide unapred poznati.

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.

Slučaj (case) je element koji se koristi za klasifikaciju i grupisanje podataka.

DM engine procenjuje slučajeve i kreira model koji se zasniva na izabranom algoritmu.

Integracija data mininga sa skladištem podataka

  1. Danas se radi na integraciji data mining alata sa skladištem podataka. Postoji više razloga za ovu integraciju.

¡ Prvo, data mining alati zahtevaju postojanje "prečišćenih" i integrisanih podataka. Tradicionalni data mining alati bi iz tih razloga prvo izvršili transfer podataka (možda i stotine gigabajta) putem mreže. Nakon završenog rada često se javlja potreba za novim podacima, što bi značilo da bi se ceo proces transfera morao ponoviti. Pri ovome se neprestano moralo voditi računa o zaštiti podataka i greškama pri prenosu.

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

¡ Treći razlog za integraciju su performanse sistema i mogućnost proširivanja koje obezbeđuje skladište podataka, a koje su potrebne za data mining alate.

Tradicionalni i 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

  1. OLAP i data mining ne bi trebalo razmatrati kao odvojene procese već da ih treba u potpunosti spojiti.

  1. Komponente OLAP data mininga su:

¡ relaciona baza podataka koja sadrži granularne podatke (ne mora biti skladište podataka),

¡ OLAP koji obezbeđuje brz pristup sumarnim podacima između više dimenzija,

¡ višedimenzioni proces otkrivanja koji će vršiti otkrivanje između dimenzija i spajati rezultate.

  1. Bez upotrebe OLAP data mininga, moguće je izostaviti ključne informacije ili se mogu dobiti netačni rezultati.

Izgradnja Data Mining modela sa OLAP podacima

  1. Uvod u scenario Članske kartice
  2. Izbor Data Mining tehnike
  3. Izbor slučaja (case)
  4. Selekcija entiteta za predviđanje
  5. Selekcija podataka za analizu (training data)
  6. Kreiranje dimenzije i virtuelne kocke
  7. Ispitivanje Data Mining modela

Uvod u scenario Članske kartice

  1. Direktor marketinga želi da oceni trenutni program članskih kartica. Da bi zadržao postojeće klijente i ispunio njihova očekivanja, želi da identifikuje mogućnosti kako bi povećao nivo usluga kod svih kartica: zlatna, srebrna, bronzana i obična.
  2. Raspoložive informacije od klijenata su pol, bračni status, godišnji prihodi, nivo obrazovanja.
  3. Da bi predvideli faktore koji utiču na izbor odgovarajuće kartice koristićemo Data mining:

¡ Koristićemo tehniku drveta odlučivanja da bi pronašli obrazac za izbor članske kartice.

¡ Odabraćemo Klijente kao dimenziju slučaja (case dimension).

¡ Odabraćemo Člansku kartu kao informaciju koju će koristiti algoritam DM da bi identifikovao obrasce.

¡ Iskoristiće se raspoložive informacije o klijentima kako bi se pronašao obrazac.

¡ Ispitati drvo odlučivanja.

UVOD U ACESS

Multifunkcionalni program; sastoji se od mnoštva povezanih alata za generisanje, organizovanje, izdvajanje, prikazivanje, štampanje i objavljivanje podataka.

  1. 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:

  1. Organizacija podataka – obuhvata izradu i rukovanje tabelama koje sadrže podatke u konvencionalnom tabelarnom formatu koju Access naziva pogled (Datasheet).
  2. Povezivanje tabela i izdvajanje podataka – povezuje više tabela prema relacijama između podataka radi izrade privremenih tabela, koje sadrže izabrane podatke. Access koristi upite da bi povezao tabele i izabrao podatke koji će se čuvati u privremenoj tabeli, koja se naziva objekat Recordset. Objekti Recordset nazivaju se virtuelne tabele, jer se čuvaju u memoriji računara umesto u datotekama baze podataka
  3. . Unos i uređivanje podataka – zahteva projektovanje i implementaciju obrazaca za pregled, unos i uređivanje podataka kao alternativu tabelarnom prikazu. Obrasci su ti koji umesto aplikacije omogućavaju da kontrolišete prikazivanje podataka.
  4. Prikazivanje podataka – zahteva izradu izveštaja koji mogu da sumiraju podatke u skupovima zapisa (Recordset). Njih možete da pregledate, štampate ili objavljujete na internetu ili intranetu.

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

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

  1. Štampanje dopušta da odštampate praktično sve što možete da pregledate u radnom režimu programa Accessa.
  2. 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

Access ima tri osnovna radna režima:

  1. Režim za pokretanje (Startup mode) omogućava da konvertujete, šifrujete, dešifrujete i popravite podatke iz baze, izborom komandi iz podmenija Database Utilities i Security, menija Tools, pre otvaranja baze podataka. Ove komande su dostupne samo ako baza podataka nije otvorena.
  2. Režim projektovanja (Design mode) omogućava da napravite i modifikujete strukturu tabela i upita, razvijate obrasce za prikaz i uređivanje podataka, kao i da formatirate izveštaje za štampanje.
  3. Režim izvršavanja (Run mode) prikazuje dizajn tabela, obrasca i izveštaja u posebnim prozorima za dokument. Makroe izvršavate tako što jedan od njih izaberete, a zatim izaberete režim izvršavanja. Ovaj režim se ne primenjuje na VBA module, jer se funkcije izvršavaju kada se pojave kao elementi upita, obrazaca ili izveštaja. Režim izvršenja za tabele i upite naziva se pogled Datasheet, za obrasce pogled Form, za strane za pristup podacima (DAP), pogled Page, a za izveštaje pogled Print Preview.

Termin aplikacija u Accessu označava bazu podataka sa sledećim karakteristikama:

  • 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:

  • Imena korisnika i grupa korisnika, koji mogu da otvore Access.

  • Lozinke i jedinstveni binarni kod korisnika, koji se naziva System ID (SID) i koji identifikuje korisnika koji trenutno koristi Access.

  • Operativna podešavanja, koje uspostavljate izborom stavki Tools, Options iz menija.

  • Definicije prilagođenih paleta alatki u Accessu 2000, koje pravi svaki korisnik.

BIBLIOTEČKE BAZE PODATAKA PROGRAMA ACCESS

  1. Još jedna kategorija datoteka, kod baza podataka u Accessu, pojavljuju se dopunski programi, koji se nazivaju i biblioteke.

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

  1. 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:

  1. Zadovoljenje potreba organizacije za informacijama na pravovremen, dosledan i ekonomičan način.

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

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

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

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

  1. Dozvoliti pristup samo onim informacijama baze podataka koje su pojedinim korisnicima ili grupama korisnika neophodne prema vrsti njihovog posla.

  1. 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:

  1. Identifikujte objekte (izvori podataka) koje sistem baze podataka predstavlja.
  2. Otkrijte veze između objekata.
  3. Odredite značajna svojstva (atribute) i ponašanja objekata.
  4. Ustanovite kako svojstva objekata utiču jedna na druge.
  5. Izradite uvodni rečnik podataka da biste definisali tabele koje čine osnovu baze podataka.
  6. Naznačite relacije između tabela baze podataka na osnovu veza između objekata koje se nalaze u njima i ove informacije uključite u rečnik podataka.
  7. Uspostavite tipove ažuriranja i transakcija koji prave i menjaju podatke u tabelama, uključujući sve neophodne zahteve u vezi sa integritetom podataka.
  8. Odredite način korišćenja indeksa kako biste ubrzali upite, s tim, da izrazito ne usporite dodavanja podataka u tabele ili da dodatno zauzimate velik prostor na disku.
  9. Ako je potrebno da se obezbedi zaštita podataka, odredite ko može da pristupi i menja podatke u svakoj tabeli (zaštita podataka) i da promeni strukturu tabela.
  10. Dokumentujte dizajn baze podataka, kao jedne celine, a i za tabele koje ona sadrži, napišite procedure za održavanje baze podataka, uključujući i one za izradu rezervne kopije datoteke i restauraciju.

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.

RELACIJA TIPA JEDAN-PREMA-VIŠE

Povezuju jedan red iz jedne tabele sa više redova druge tabele preko relacije između primarnog ključa bazne tabele i odgovarajućeg spoljnjeg ključa u povezanoj tabeli.

RELACIJE TIPA VIŠE-PREMA-JEDAN

Povezuju više redova jedne tabele sa jednim redom druge tabele.

RELACIJE TIPA VIŠE-PREMA-VIŠE I ČETVRTA NORMALNA FORMA

Ne mogu da se izraze kao jednostavne relacije između dva sudelujuća entiteta. Njih ostvarujete tako što pravite tabelu koja ima relacije tipa više-prema-jedan sa dve bazne tabele.

NORMALIZACIJA PODATAKA U RELACIONI MODEL

PRAVILA NORMALIZACIJE

Normalizacija je formalizovani postupak za grupisanje atributa podataka u tabele i tabela u baze podataka.

Ciljevi normalizacije:

  1. Eliminisanje dupliranih informacija u tabelama.
  2. Prilagođavanje budućim izmenama u strukturi tabela.
  3. Umanjivanje uticaja strukturnih izmena baze podataka na korisničke aplikacije koje pristupaju podacima.

PRVA NORMALNA FORMA

Zahteva da tabele budu ravne i da ne sadrže duplirane grupe.

DRUGA NORMALNA FORMA

Zahteva da podaci u svim kolonama koje nisu deo ključa budu potpuno zavisni od primarnog ključa i svakog elementa (kolone) primarnog ključa kada je on složeni primarni ključ. Potpuno zavisni znači da je vrednost podatka u svakoj koloni koja nije deo ključa zapisa, na jedinstven način određena vrednošću primarnog ključa. Druga normalna forma uklanja veći deo nepotrebnih (redudantnih) podataka.

TREĆA NORMALNA FORMA

Zahteva da sve kolone koje nisu deo ključa tabele budu zavisne od primarnog ključa tabele i nezavisne jedna od druge. Tabele moraju da odgovaraju prvoj i drugoj formi da bi bile sposobne za treću normalnu formu.

ČETVRTA NORMALNA FORMA

Zahteva da se nezavisni entiteti podatka ne čuvaju u istoj tabeli, kada između njih postoje relacije tipa više-prema-više.

PETA NORMALNA FORMA

Zahteva da mora postojati mogućnost da se tačno rekonstruiše originalna tabela pomoću tabela u koje je ona rastavjlena. Peta normalna forma zahteva da tabele poštuju pravila treće normalne forme, a kada postoje relacije tipa više-prema-više i pravilo četvrte normalne forme.

UPITI

Access omogućava pravljenje četiri osnovna tipa upita, za postizanje različitih ciljeva:

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

OBEZBEĐIVANJE INTEGRITETA BAZE PODATAKA

Integritet baze podataka sastoji se od dva elementa:

  1. Integriteta entiteta i
  2. Referencijalnog integriteta.

  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.

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

PRINCIPI BEZBEDNOSTI BAZE PODATAKA U LOKALNOJ MREŽI

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.

UPRAVLJANJE GRUPAMA I KORISNICIMA

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.

Access ima dva nivoa bezbednosti:

  1. na nivou aplikacije (zahteva da svaki korisnik Accessa unese korisničko ime i lozinku da bi mogao da pokrene Access) i
  2. na nivou datoteke (uspostavio je mrežni operativni sistem, kao što je Windows NT Server i ona određenim korisnicima dozvoljava ili ne dozvoljava pristup zajedničkim omotnicama i/ili pojedinačnim datotekama).

U mreži ravnopravnih članova, mere za bezbednost mreže su odgovornost svake osobe koja deli svoje resurse sa drugima. Ostalih pet principa bezbednosti baze podataka određeno je bezbednosnim mogućnostima sistema za upravljanje bazom podataka i aplikacijama koje pomoću njega pravite.

  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.

Komentari (0)Add Comment

Napišite komentar

busy