baze podataka biljeske 02

Baze podataka i SQL – bilješke s predavanja

Veleučilište u Varaždinu

5. Relacijska algebra (nastavak)– operatori nad skupovima

Relacije su skupovi n-torki, pa se na njih mogu primijeniti uobičajeni operatori nad skupovima. Dakle, ako su R i S dvije relacije, tada se može definirati:

• R unija S (ili R U S) skup svih n-torki koje su ili u R ili u S ili u obje relacije.

• R presjek S (ili R ∩ S) skup svih n-torki koje su i u R i u S.

• R razlika S (ili R \ S) skup svih n-torki koje su u R i nisu u S.

Da bi se operacije mogle primjenjivati, relacije R i S moraju biti kompatibilne, to znači, imati isti stupanj i iste atribute (imena i tipove). Primjer: Kao primjer, služiti ćemo se izmišljenom bazom podataka o nekom „Fakultetu“ ,koja u sebi sadrži podatke o studentima, profesorima, kolegijima i ispitima.



Primjeri: (unija, presjek, razlika) Neka postoji relacija NOVI STUDENT, građena kao i relacija STUDENT:

Selekcija

Selekcija je unarni operator koji izvlači iz relacije one n-torke koje zadovoljavaju zadani Booleov (logički) uvjet.

George Boole (02.11.1815 – 08.12.1864)

(engleski matematičar i filozof)



(U standardni SQL,Booleovi operatori su definirani tek 1999. godine) Primjer u PHP-u: $var = true; $var = false; Selekciju na relaciju R za Booleov uvjet B označavati ćemo s: R where B (R gdje vrijedi B). Uvjet B je formula koja se sastoji od:

i) operanda koji su ili konstante ili atributi ii) operatora za uspoređivanje: =, <, > ,≤, ≥ iii) logičkih operatora AND, OR, NOT, XOR, . . .

Primjeri:

Upit 1: »Pronađi sve studente prve godine«

REZULTAT := STUDENT where godina=1 indeks student godina F-6453 Bakula 1 Upit 2: »Pronađi sve kolegije s naslovom ’Baze podataka’«

REZULTAT := KOLEGIJ where naslov=’Baze podataka’ kolegij naslov nastavnik 5671 Baze podataka Netković Upit 3: »Pronađi sve studente koji su iz kolegija 5671 dobili ocjenu veću od 3«

REZULTAT := ISPIT where ((kolegij=5671) AND (ocjena>3))

indeks kolegij ocjena F-7654 5671 5



Projekcija • Projekcija je unarni operator koji izvlači zadane atribute, a iz

rezultirajuće relacije eliminira iste n-torke (duplikate i ostale multiplikate).

• Projekciju relacije R na njene atribute A1, A2, A3, . . .An,

označavat ćemo sa R [ A1, A2, . . .An ]

• Operacije projekcije ima veći prioritet od ostalih operacija! Primjeri:

Upit 1: »Pronađi brojeve soba svih nastavnika«

REZULTAT := NASTAVNIK [soba]

SOBA 105 203 310 208

Upit 2: »Pronađi ime nastavnika koji predaje kolegij 6322«

REZULTAT := (KOLEGIJ where kolegij=6322) [nastavnik]

NASTAVNIK Horvatić

Kartezijev produkt

Neka su R i S relacije stupnja n1 i n2. Tada je algebarski izraz R X S (ili R times S, R produkt S, R puta S), odnosno Kartezijev produkt relacija R i S, skup svih (n1+n2)-torki čijih prvih n1 komponenti čine n1-torke iz R, a zadnjih n2 komponentičine n2-torke iz S.



• Za svaku n1-torku iz R i svaku n2-torku iz S postoji (n1+n2) - torka u R X S.

• Atributi u R X S imaju ista imena kao i odgovarajući atributi u R, odnosno S, s tim da se po potrebi to ime proširuje imenom polazne relacije, (slično pisanju komponenti zapisa u Pascalu, C-u, …)

Primjeri: Upit 1: »Nađi za svakog studenta kolegije koje on nije položio«

SVE KOMBINACIJE := STUDENT[indeks]oKOLEGIJ [kolegij] REZULTAT = SVE KOMBINACIJE \ ISPIT [indeks,kolegij]

Upit 2: »Nađi sve parove studenata koji su na istoj godini« Ovdje je potrebno napraviti Kartezijev produkt relacije STUDENT sa samom sobom. Da ne bi došlo do pomutnje oko imena atributa, uvodi se posebni operator aliases (alias, pseudonim, drugo ime, nadimak) za relaciju STUDENT. TEMP aliases STUDENT



REZULTAT := ((TEMP o STUDENT) where ((TEMP.godina = STUDENT.godina) AND(TEMP.indeks < STUDENT.indeks))) [TEMP.student, STUDENT.student]

REZULTAT TEMP.student STUDENT.student Tomić Horvat

Prirodni spoj Neka su R i S relacije koje imaju bar jedan zajednički atribut. Tada je algebarski izraz R join S skup svih n-torki dobivenih spajanjem n-torki iz R i n-torki iz S, a koje imaju iste vrijednosti za zajedničke atribute. U konačnom rezultatu zajednički atributi se pojavljuju samo jednom.

Primjer:

R

A B C a1 b1 c1 a2 b1 c1 a3 b2 c2 a4 b2 c3

S B C D b1 c1 d1 b1 c1 d2 b2 c3 d3



R join S A B C D a1 b1 c1 d1 a1 b1 c1 d2 a2 b1 c1 d1 a2 b1 c1 d2 a4 b2 c3 d3



• Prirodni spoj omogućuje da se iz jednostavnih relacija rekonstruiraju one složene relacije koje smo imali na početku prije procedure njihovog dovođenja na normalnu formu!

• Prirodni spoj omogućuje i puno više od toga: konstruiranje

relacija koje prije nismo niti imali - relacije koje sadrže neke nove veze među podacima.

• Prirodni spoj je jedno od sredstava koje daje prednost

relacijskom modelu nad mrežnim ili hijerarhijskim.



6. Skladišta podataka (Data Warehouse)

U današnje doba opće i informatičke globalizacije, opstanak i konkurentnost na tržištu je direktno ovisna o dostupu do pravih informacija u što kraćem vremenu. Skladišta podataka i poslovna inteligencija čine danas temelje na kojima poslovni ljudi grade svoje strateške i taktičke poslovne odluke.

Skladište podataka je baza podataka koja sadrži povijesne nepromjenjive podatke koji se prikupljaju i obrađuju radi potpore poslovnom odlučivanju. Podaci se izvlače iz raznovrsnih izvora te se u skladu s definiranim modelom podataka učitavaju u skladište podataka i integriraju s postojećim podacima. [Skočir, Matasić,Vrdoljak] Glavni izvor podataka za skladište podataka su operacijske transakcijske baze podataka, koje služe za svakodnevno vođenje poslovnih procesa. U samim počecima razvoja informacijskih sustava je prepoznata važnost i značaj pohrane povijesnih podataka. Nemogućnost klasičnih operativnih sustava da prikažu ponašanje promatranog modela u prošlosti je bio jedan od pokretača razvoja skladišta podataka. Mogućnost da analiziramo snimke stanja promatranog subjekta u prošlosti i da tražimo sličnosti i razlike u ponašanju u određenom vremenskom periodu, čini jednu od najvećih prednosti skladišta podataka nad dotadašnjim transakcijskim sustavima. Za skladište podataka kažemo da je dugi vremenski slijed snimaka stanja transakcijskih baza podataka.



Budući je skladište podataka dugi vremenski slijed pohranjenih podataka o poslovanju ili ponašanju nekog subjekta, svaki podatak u skladištu mora imati jasno naznačeno i određeno vrijeme važenja, odnosno vremenski početak i kraj važenja neke činjenice. Ukoliko se neki od opisa entiteta u skladištu podataka promijeni u vremenu, mora se osigurati način da se sačuvaju opisi entiteta koji su važili tada u tom određenom vremenskom intervalu. Analizom slijeda slojeva pohranjenih podataka, skladište treba omogućiti pronalaženje pojedinih događaja, omogućiti generiranje periodičkih izvještaja i uvid u zadnje stanje odnosno status promatranog subjekta. Praksa je pokazala da dimenzijski model najbolje zadovoljava sve te nametnute zahtjeve na skladište podataka.

Dimenzijski model Uobičajeni OLTP (eng: Online Transaction Processing) sustavi, koji zahtjevaju normalizirani skup podataka za minimizaciju zalihosti, su dizajnirani za postizanje visokih brzina obrade u slučaju dohvata ograničenog broja zapisa. U slučaju dohvata velike količine slogova istovremeno, što je uobičajeno u skladištima podataka, taj relacijski model je neprihvatljiv. Zbog toga se u skladištima podataka uvodi dimenzijski model podataka.

Dimenzijski model je konceptualni i logički model, dizajniran sa svrhom da omogući brzi pristup podacima. U dimenzijskom modelu se poslovni procesi opisuju preko dimenzija koje su hijerarhijski organizirane.



Najčešći način prikazivanja dimenzijskog modela je kocka (trodimenzionalni model), gdje se na presjeku dimenzija nalazi traženi podatak. Slijedeća slika prikazuje dimenzijski model podataka u obliku kocke.

Slika : Prikaz dimenzijskog modela podataka u obliku kocke

U praksi taj broj dimenzija može biti i veći od tri, pa u tom slučaju govorimo o „višedimenzijskoj kocki“ ili o „hiperkocki“.

Najčešći način implementacije dimenzijskog modela je u zvjezdastu strukturu (eng:star shema). Zvjezdasta struktura se sastoji od jedne tablice činjenica (eng: fact table) i okolnih dimenzijskih tablica (eng: dimensional tables).

KUPAC

VRIJEME

PROIZVOD



Primjer zvjezdaste strukture:

• tablica činjenica: ORDERS • dimenzijske tablice: TIME, PRODUCT, CUSTOMER

Slika: Zvjezdasta struktura

Tablice činjenica su mjesta za spremanje brojčanih pokazatelja promatranog subjekta, a svaka je činjenica središte interesa u procesu donošenja neke poslovne odluke.

Dimenzije koje opisuju pojedinu činjenicu mogu biti: • potpuno zbrojive • poluzbrojive • nezbrojive

customerKey

timeKey

productKey

unitPrice

quantityproductKey

productName

productDesc

date

month

customerKey

name

address

TIME

CUSTOMER

PRODUCT city

country

income

type

dayOfWeek

timeKey

ORDERS



Potpuno zbrojive činjenice se mogu zbrajati (agregirati) po svim dimenzijama koje ju opisuju, dok je to kod poluzbrojivih ili nezbrojivih činjenica, tek djelomično moguće ili potpuno nemoguće.

Kod oblikovanja kvalitetnih skladišta podataka, uvijek treba težiti da imamo što veći broj zbrojivih dimenzija. U tablici činjenica se nalaze sve mjere odgovarajuće činjenice, te po jedan strani ključ na svaku od dimenzija koje opisuju činjenicu. Svi strani ključevi zajedno čine složeni primarni ključ tablice činjenica. Na taj način je jedan redak činjenične tablice određen kombinacijom svih primarnih ključeva dimenzijskih tablica i predstavlja jednu kockicu višedimenzionalnog prostora. Dimenzijske tablice sadrže atribute vezane uz pojedine činjenice te ih grupiraju i odvajaju u logičke cjeline, kao što su: vrijeme, prostor, proizvodi, … Dobro oblikovana skladišta podataka sadrže dimenzijske tablice s velikim brojem takvih atributa, čime se krajnjim korisnicima povećava i količina dostupnih informacija. Zbog učinkovitog i jednostavnog izvođenja upita, dimenzijske tablice su obično normalizirane. Budući da su puno manje od tablica činjenica, normalizacija nema nikakav mjerljiv učinak na diskovni prostor.

Dimenzija vremena Vremenska dimenzija je uvijek prisutna u skladištu podataka, jer svako skladište podataka predstavlja vremenski niz stanja neke organizacije. Svaki događaj u skladištu se pojavljuje u određenom vremenu, te su podaci često sumirani i grupirani po određenim vremenskim intervalima.



Gotovo svaka tablica činjenica ima jedan ili više stranih vremenskih ključeva, jer su podaci uzorkovani u određenom vremenu u prošlosti ili se to uzorkovanje periodički ponavlja. Iako su datum i vrijeme neke poslovne činjenice obično zapisani u izvornoj transakcijskoj bazi, kreiranje posebnih dimenzija vremena olakšava i čini efikasnijim vremenski orjentirane analize nad podacima unutar skladišta. U dimenzijsku tablicu vremena često se na osnovnoj razini pohranjuju zapisi koji predstavljaju datume koji pokrivaju nekoliko proteklih i nekoliko idućih godina. U slučaju potrebe pohranjivanja podataka po satima ili minutama, kreiraju se posebne dimenzijske tablice za sate i minute. Najčešće vremenska dimenzija sadrži slijedeće atribute:

• datum • dan u tjednu • broj tjedna • mjesec • trimestar • semestar • godina • sezona • indikator praznika • indikator radnog dana • ...

Neki od navedenih atributa mogu biti izvedeni iz funkcija koje manipuliraju s datumima i uključene su u DBMS (eng: database management system).



Problemi uzrokovani promjenama dimenzija Jedna od glavnih razlika razlika između transakcijskih sustava i skladišta podataka je u načinu i mogućnosti opisivanja prošlosti. OLTP sustavi su prilično loši u opisu poslovnih procesa koji su se dogodili prije više mjeseci ili godina. Razlog leži u činjenici da transakcijski sustavi po svojoj prirodi moraju pratiti promjene realnog svijeta. Svakodnevno se mijenjaju opisi nekih proizvoda, podaci o narudžbama ili dobavljačima, te se stari podaci prepisuju s novim definicijama. Zbog toga se velika količina podataka u tipičnom OLTP sustavu izmjeni u periodu od tri do šest mjeseci, te je, gotovo nemoguće, da OLTP sustav korektno opiše prošlost. Od skladišta podataka se očekuje da preuzme odgovornost za korektno prikazivanje prošlog stanja. Skladište podataka treba ispravno pratiti promjene te u svakom trenutku znati stanje određenog zapisa u prošlosti. U dimenzijskim bazama podataka, korektno prikazivanje prošlosti nas dovodi do analize i rješavanja problema sporo promjenjivih dimenzija (eng: slowly changing dimensions - SCD). Sporo promjenjive dimenzije su dimenzije kod kojih se članstvo i atributi podataka mogu mijenjati u ograničenom obimu i u nepravilnim vremenskim intervalima. Obično ih dijelimo na tri kategorije:

• Sporo promjenjive dimenzije Tipa 1 • Sporo promjenjive dimenzije Tipa 2 • Sporo promjenjive dimenzije Tipa 3

U Tipu 1 sporo promjenjivih dimenzija, povijest nije sačuvana, nego se podaci prepisuju jedni preko drugih. To je najlakši način rješavanja problema promjene dimenzija. Da na taj način ne bi izgubili smisao skladišta podataka, koje mora sačuvati povijest za



potrebe donošenja poslovnih odluka, to se koristi samo za ispravljanje pogrešaka kod punjenja skladišta. Uobičajeni analitički alati i procesi tretiraju regularne dimenzije jednako kao i Tip 1 SCD-a. Tip 2 je najčešći oblik sporo promjenjivih dimenzija. Kod tog tipa SCD-a povijest se čuva kreiranjem novih slogova, s novom vrijednošću primarnog ključa, za svaki član čiji se atribut promijenio. Nadalje, i stari i novi slogovi sadrže (uz primarni ključ) i stalni identifikator, za nekog komitenta koji je promijenio adresu ili za nekog osobnog bankara koji je promijenio poslovnu jedinicu u kojoj radi. Prednost korištenja Tipa 2 SCD-a je da za svaki član dimenzijskih tablica možemo precizno odrediti aktualni vremenski okvir (vrijedi_od, vrijedi_do). Jedini problem može nastupiti ako su promjene dimenzija relativno česte, jer tada broj slogova u bazi može značajno porasti. Tip 1 i Tip 2 SCD-a pokriva najveći broj situacija koje se pojavljuju u aplikacijama poslovne inteligencije vezano uz promjenu dimenzija. U oba slučaja nivo praćenja povijesnih promjena uključuje sve atribute svakog sloga u dimenzijskim tablicama. Postoje i situacije kada se treba analizirati istovremeno originalna vrijednost i sadašnja vrijednost nekog atributa u određenom vremenskom intervalu. U tom slučaju ne pamtimo među stanja nekog atributa, nego samo prvo i zadnje stanje. U tom slučaju govorimo o Tipu 3 sporo promjenjivih dimenzija. Kod tog tipa SCD-a se ne dodaju novi slogovi kada dođe do nekih promjena dimenzija, već se dodaju novi stupci s zastavicama koje govore o originalnoj vrijednosti i aktualnoj vrijednosti nekog atributa. Već smo govorili o problemima koji nastupaju kada ima mnogi promjena dimenzija i kada se one događaju relativno brzo. Takve se situacije opisuju pojmovima i rješavaju metodama brzo promjenjivih dimenzija (eng: Rapidly Changing Dimensions – RCD).



Takve se dimenzije najčešće opisuju s odvojenim dimenzijama koje su povezane s regularnim ili sporo promjenjivim dimenzijama. Sadržaj takvih RCD-a se ažurira puno češće (tjedno, dnevno, ….) nego regularne dimenzije s kojima su povezane. U svrhu kontrole veličine brzo promjenjivih dimenzija, često se neki atributi dijele u minidimenzije. Korištenje minidimenzija rezultira jednim novim stranim ključem (eng: Foreign Key - FK) u tablici činjenica. Novokreirane minidimenzije imaju nižu kardinalnost nego orginalne dimenzije. Primjer kreiranja minidemenzije je prikazan na slijedećoj slici

Slika: Kreiranje minidimenzije

Customer key Demographics key Other keys facts

Demographics key Age Gender Income level

Customer key Last name First name …

Demografska minidimenzija

Tablica činjenica

Dimenzije

Primjer dodavanja stranog ključa u tablicu činjenica za kreiranje minidimenzije



ETL proces i skladište podataka s minimalnim kašnjenjem Većina skladišta podataka puni svoje tablice činjenica i dimenzijske tablice iz različitih izvora. Vrlo je važno da su ti podaci prije učitavanja očišćeni i transformirani, da se osigura konzistentnost baze i olakša donošenje kvalitetnih poslovnih odluka. Podaci se ETL procesima (eng: Extracting, Transforming, Loading) izvlače, transformiraju i čiste, te pune u bazu koja je strukturalno organizirana na način koji je pogodan za daljnje analize.

• U postupku ekstrakcije, podaci se iz višestrukih izvora identificiraju u operacijskom sustavu, izvlače i objedinjuju u zajedničku bazu, kako bi se što lakše integrirali u skladište podataka.

• U procesu transformacije se ti podaci pročišćavaju i

prilagođavaju standardnoj shemi atributa. Budući da je posebno važna vremenska dimenzija pristupa podacima, podaci se prilikom prijenosa uobliče tako, da se sumiraju (agregiraju) u pojedina stanja za određeni vremenski period. Ta vremenska zrnatost najčešće ide do nivoa jednog dana.

Nakon toga se pune u skladište podataka. Punjenje skladišta podataka se radi u batch obradama izvan uredovnog vremena ( najčešće noću) . Na slijedećoj slici je prikazan ETL proces.

Slika: ETL proces



Globalna ekonomija današnjice naglašava sve veću važnost pravih i pravovremenih informacija. Ključ uspjeha leži u razumijevanju ponašanja komitenata i sposobnošću brzog prilagođavanja dinamici promjene njihovih potreba. Tradicionalni ETL procesi, koji traju satima ili danima sigurno ne mogu zadovoljiti tu potrebu jer kreiraju skladišta koja su tjednima ili mjesecima iza svojih izvornih sustava. To kašnjenje u prošlosti nije smatrano nekim problemom jer se skladišta podataka nisu smatrala operacijskim i poslovno kritičnim aplikacijama. Popularnost koju su skladišta podataka doživjela među svojim korisnicima je izmjenilo način njihovog korištenja. Analitičari su shvatili da im skladišta omogućuju cjeloviti pogled na njihovo poslovanje, ponašanje i trendove među korisnicima njihovih proizvoda. Bilo bi idealno da se te informacije približe onima koji su u direktnom kontaktu s komitentima, čime se uvećava mogućnost ostvarenja dobrih (ili još boljih) poslovnih odnosa. Takve informacije moraju stizati sa što kraćim kašnjenjem. Današnja tehnologija je omogućila da se na tržištu pojavi mnogo skladišta podataka koja rade u stvarnom ili skoro stvarnom vremenu (eng: Real-time or Near-real-time Data Warehousing). Na slici u nastavku je prikazano jedno skladište koje radi u stvarnom vremenu.



Slika: Skladište podataka u stvarnom vremenu

Skladište podataka u stvarnom vremenu sadrži potpuno aktualne podatke (eng: up-to-date) i sinkronizirano je s izvornim sustavom, dok kod skladišta koja rade u skoro stvarnom vremenu, postoji minimalno kašnjenje od trenutka kada su podaci nastali i trenutka kada su se pojavili u skladištu. Ukoliko želimo da naše skladište sadrži što aktualnije podatke, moramo postići slijedeće:

• smanjiti vrijeme identifikacije novih podataka u izvornom sustavu

• smanjiti na najmanju moguću mjeru trajanje ETL procesa • reducirati vrijeme za osvježavanje agregacija

Jedan od najtežih zadataka kod oblikovanja takvog skladišta podataka je osigurati izvođenje ETL procesa u stvarnom ili skoro stvarnom vremenu.



Većina tradicionalnih ETL alata i sustava je koncipirana na periodičkom izvođenju batch poslova, na dnevnom, tjednom ili mjesečnom nivou. Za vrijeme ETL procesa, skladište je nedostupno krajnjim korisnicima. Što je skladište veće, više vremena treba da se ponovno napuni, ali to ne predstavlja veliki problem ako se uspije završiti izvan radnog vremena, najčešće noću. Ukoliko želimo podatke puniti u skladište u stvarnom vremenu, ne možemo si dozvoliti da skladište bude nedostupno u nekom trenutku. Danas raspolažemo alatima i tehnikama, koje nam omogućavaju da izvedemo ETL u stvarnom vremenu ili da modificiramo postojeći ETL sustav da funkcionira u stvarnom ili skoro stvarnom vremenu. Neke od tih tehnika će ukratko biti opisane u nastavku. • ETL proces u skoro stvarnom vremenu Najjednostavnije rješenje (i vjerojatno najjeftinije) je povećati frekvenciju punjenja skladišta podataka. Ne traže svi poslovni procesi dostup do skladišta podataka koje radi u stvarnom vremenu. Za takve poslove je dovoljno ETL koji se izvodio jednom mjesečno, ponavljati jednom tjedno, a onaj koji se izvodio tjedno, ponavljati svakodnevno ili čak nekoliko puta dnevno. Ovakav pristup omogućuje korisnicima raspolaganje sa svježijim podacima nego inače, bez nekih velikih i skupih modifikacija sustava. • Direktno punjenje podataka Pretpostavimo da poslovni proces zahtjeva pristup do skladišta u stvarnom vremenu. U tom slučaju se skladište može kontinuirano dopunjavati s podacima iz izvornog sustava. To se može ostvariti direktnim ažuriranjem tablice činjenica ili direktnim ažuriranjem odvojenih segmenata tablice činjenica.



Danas na tržištu postoji mnogo alata koji osiguravaju prenošenje podataka od izvora do skladišta u stvarnom vremenu. Neki su bazirani na Java tehnologiji i koriste JMS (eng: Java Messaging Service), dok se podaci koji stižu putem Interneta prebacuju u XML (eng: Extensible Markup Language) preko HTTP protokola (eng: Hypertext Transfer Protocol) i pune u skladište podataka. Nedostaci takvog pristupa su u degradaciji performansi upita koji se izvode nad skladištima koja se kontinuirano nadopunjavaju. Za vrijeme velikih opterećenja, skladišta mogu privremeno blokirati transakcijski sustav za punjenje podataka, pa se mogu dogoditi pogreške u prijenosu novih podataka u skladište.

• Koncept „ Trickle and Flip“ Ovim konceptom se pokušao riješiti problem pada performansi upita, koji je neminovan kod metode direktnog nadopunjavanja podataka u skladište. Umjesto da se podaci direktno pune u skladište podataka, oni se pune u privremene tablice koje su vjerna kopija tablica činjenica. Novi slogovi se jednostavno dodaju na kopiju tablice činjenica, a može ih biti i nekoliko tisuća u sekundi. Nakon određenog vremena, recimo svakih 10 minuta, stvarna tablica činjenica se izbriše, a njena kopija preimenuje u originalnu tablicu činjenica. U slučaju malih tablica činjenica, to se može ponavljati i svaku minutu. Ukoliko postupak kopiranja i reindeksiranje ne traje dugo, ta metoda je sasvim zadovoljavajuća, ali ju je potrebno temeljito testirati prije puštanja u rad, da bi se pronašao optimalni vremenski period između kopiranja tablica.



• Korištenje vanjske memorije Dosad nabrojene metode su podložne manjem ili većem padu performansi upita. Zbog toga se tražilo rješenje koje neće postojeće skladište opteretiti punjenjem podataka u stvarnom vremenu. Najboljim rješenjem, u mnogim slučajevima, se pokazalo pohraniti podatke koji stižu, u vanjsku memoriju (eng: Real time data cashe - RTDC), izvan skladišta podataka, čime se izbjegava pad performansi postojećih upita. RTDC može biti neki drugi server baze podataka koji obrađuje podatke u stvarnom vremenu. Svi oni „kritični“ upiti se usmjeravaju na RTDC, dok se ostali procesiraju na tradicionalan način iz postojećeg skladišta. Tako se ujedno postiže i da upiti koji posežu u RTDC budu iznimno brzi. Prema potrebi se RTDC može preslikati u skladište podataka, čime se osigurava aktualnost podataka u skladištu. Jedini nedostatak te metode je što ona uključuje korištenje dodatne baze koja mora biti instalirana i održavana.

Zaključak Ovisnost o vremenu je jedna od ključnih karakteristika skladišta podataka, jer skladišta djeluju, i oblikovana su, kao vremenski ovisne aplikacije. U prvim generacijama skladišta podataka nije se poklanjala dovoljna pažnja predstavljanju vremena. U dimenzijskom modelu se vrijeme analiziralo i uglavnom predstavljalo kroz vremenske dimenzije. Iako su dimenzijske tablice vremena jedne od najjednostavnijih u svim skladištima podataka, oblikovanje njihovog okruženja i pravovremeno punjenje s podacima je vrlo kompleksno.



U prvim generacijama skladišta podataka, glavna briga analitičara i dizajnera je bila kako efikasno tretirati svakodnevne promjene kroz koje prolazi izvorni OLTP sustav. Razvile su se brojne metode za rješavanje problema sporo i brzo promjenjivih dimenzija. U današnje vrijeme, sve veća potreba pravovremenog prilagođavanja potrebama svojih komitenta, kao garancija opstanka i uspjeha na tržištu, dovela je do sistematskog praćenja posljedica koje vrijeme ima na oblikovanje skladišta podataka. Trend je u sve većem razvoju skladišta koja se pune u stvarnom ili skoro stvarnom vremenu. Tehnologija novijeg doba je omogućila razvoj ETL aplikacija s minimalnim kašnjenjem , a time i pojavu skladišta podataka koja rade u stvarnom ili skoro stvarnom vremenu. Pred analitičarima i poslovnim ljudima je izazov, kako te informacije pretvoriti u zadovoljstvo svojih komitenata, u svrhu ostvarenja većih i boljih poslovnih rezultata. Korištena literatura:

W.H. Inmon. Building the Data Warehouse (Fourth Edition). Wiley Publishing, Inc.,2005. R. Kimball, The Soul of the Data Warehouse, Part 3: Handling Time , www.intelligententerprise.com, 2003. R. Kimball, M. Ross. The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling (Second Edition). John Wiley & Sons, Inc., 2002. R. Kimball, It's Time for Time. Data Warehouse Architect, DBMS online, 1997. C. Todman. Designing A Data Warehouse (First Edition). Prentice Hall PTR, 2000. C. Adamson. Mastering Data Warehouse Aggregates. Wiley Publishing, Inc., 2006. Z. Skočir, I. Matasić, B. Vrdoljak. Organizacija obrade podataka. Merkur A. B. D., 2007.



7. SQL (Structured Query Language)

Razvoj SQL-a počinje 1974. godine kada se pojavljuje članak autora D.D.Chamberlaina i R.F.Boycea u kojem oni opisuju strukturni upitni jezik za pretraživanje podataka nazvan SEQUEL. Iako je Donald Chamberlain poznat kao kreator SQL-a, on je nedavno stvorio još jedan upitni jezik, pod nazivom XQuery. Taj jezik je prvenstveno zamišljen da uz mogućnost jednostavnog programiranja služi za upite nad XML (Extensible Markup Language) podacima. Semantički je dosta sličan SQL-u. Raymond „Ray“ Boyce je kompjuterski znanstvenik, koji je doktorirao 1971, te nakon toga počeo raditi u IBM-u u New Yorku, na projektu relacijskih baza podataka.

• Godine 1975. Boyce, Chamberlain i M.Hammer predstavljaju koncept jezika SQUARE koji je koristio matematičke izraze, za razliku od engleskih termina koje je koristio SEQUEL.

• SQUARE mijenja ime u SEQUEL2 i taj jezik je korišten u

razvoju prvog prototipa relacijskog sustava za upravljanje bazama podataka, nazvanog “System R” razvijenog u laboratorijima IBM-a.

• Kasnije jezik mijenja ime u SQL.

• Standardni SQL je relacijski potpun jer za svih pet

osnovnih relacijskih operator (SPAJANJE, RAZLIKA, MNOŽENJE, RESTRIKCIJA i PROJEKCIJA) postoje semantički ekvivalentne SQL naredbe.



SQL standard SQL je sredinom 80-tih godina standardiziran od strane ISO (International Standardization Organisation) i ANSI instituta (American National Standards Institute). Danas se koristi u većini relacijskih sustava baza podataka. Iako su proizvođači davno prihvatili standard, tj. jezgru oko koje mogu (i smiju) graditi „svoju verziju“, taj proces još nije završen. Svakodnevna razvojna istraživanja dovode do novih implementacija i proširenja jezika. Kratki pregled razvoja standarda je prikazan u slijedećoj tablici:

Godina Ime Alias Komentar

1986 SQL-86 SQL-87 Prvi puta objavljen od ANSI. Potvrđen od ISO , 1987.

1989 SQL-89 FIPS 127-1 Manja revizija, prihvaćen pod imenom FIPS 127-1.

1992 SQL-92 SQL2, FIPS 127-2 Veća revizija (ISO 9075), Ulazni nivo SQL-92 prihvaćen pod imenom FIPS 127-2.

1999 SQL:1999 SQL3 Dodavanje regularnih izraza, rekurzivni upiti, trigeri, podrška za procedure i naredbe za kontrolu toka, objektno-orijentirane mogućnosti

2003 SQL:2003 Dodavanje XML-a, manipulacija s prozorima, dodavanje stupaca s automatskim popunjavanjem .

2006 SQL:2006 ISO/IEC 9075-14:2006 definiranje načina povezivanja SQL-a i XML-a . Definiranje povezivanja s XQuery jezikom, koji je objavljen od W3C konzorcija (World Wide Web Consortium)

http://en.wikipedia.org/wiki/1989�

http://en.wikipedia.org/wiki/Federal_Information_Processing_Standard�


http://en.wikipedia.org/wiki/SQL-92�


http://en.wikipedia.org/wiki/SQL:1999�







• SQL spada u neproceduralne jezike, što znači da korisnik pomoću njega definira što želi dobiti, a ne kao će to dobiti.

• Za razliku od proceduralnih programskih jezika, SQL nema

If...Then...Else konstrukciju za ispitivanje uvjeta, niti ima konstrukciju za logičku strukturu petlje Do...While ili For...Next.

• On sadrži konstrukcije slične relacijskoj algebri ili računu

(koje su osnove jezika za rukovanje podacima), naredbe opisa baze podataka (jezik za opis podataka), naredbe za povezivanje SQL-a s nekim standardnim programskim jezikom (CURSOR operacije), kao i naredbe za definiranje zaštite i integriteta baze podataka, upravljanje konkurentnim obradama i oporavak baze podataka.

• SQL izraz predstavlja skup odgovarajućih SQL riječi koje

zajedno tvore funkcionalnu cjelinu. Kao osnovne osobine SQL-a mogu se izdvojiti sljedeće: • English-like jezik. Koristi riječi kao što su: select (odaberi),

insert (dodaj), delete (obriši) kao dio naredbe. • Ne-proceduralni jezik • U jednom trenutku češće obrađuje skup slogova nego jedan

slog tablice • Mogu ga koristiti korisnici različitog profila: administratori baze

podataka, aplikativni programeri, neprofesionalni korisnici. • Osigurava naredbe za različite zadaće uključujući :

• upite nad podacima, • dodavanje, mijenjanje i brisanje redaka u tablicama, • kreiranje, mijenjanje i brisanje objekata sheme, • kontrolu pristupa bazi podataka i objektima sheme, • konzistentnost baze podataka.



Grupiranje SQL naredbi SQL izrazi mogu se razvrstati u nekoliko skupina : a) izrazi za upravljanje podacima (engl. Data Manipulation

Language Statements - DML) b) izrazi za definiranje podataka (engl. Data Definition Language

Statements - DDL) c) izrazi za kontrolu transakcija (engl. Transaction Control

Statements -TCL) d) izrazi za kontrolu sesije (engl. Session Control Statements) e) izrazi za kontrolu sustava (engl. System Control Statements) f) ugrađeni SQL izrazi (engl. Embedded SQL Statements). a) DML izrazi se koriste za izvođenje slijedećih akcija nad

podacima :

• brisanje redaka iz tablica ili indeksa (naredba: DELETE) • upisivanje redaka u tablicu ili indeks (naredba: INSERT)

• omogućavanje pregleda izvođenja SQL izraza (naredba:

EXPLAIN PLAN)

• zaključavanje tablica i pogleda (naredba: LOCK TABLE)

• pretraživanje redaka iz tablica ili pogleda (naredba: SELECT)

• promjena vrijednosti u stupcima tablica ili pogleda (naredba: UPDATE).



b) DDL izrazi kreiraju, mijenjaju i brišu objekte sheme.

Omogućavaju sljedeće :

• kreiranje, mijenjanje i brisanje objekata sheme i drugih struktura baze podataka (same baze, korisnika nad bazom, tablica..) - CREATE, ALTER i DROP naredbe

• mijenjanje imena objekata shema (naredba: RENAME)

• praćenje statistike o objektima sheme, validiranje strukture

objekata (naredba: ANALYSE)

• davanje i oduzimanje privilegija i uloga (role) nad bazom (naredbe: GRANT i REVOKE)

• uključivanje i isključivanje kontrole nad bazom (naredbe:

AUDIT, NOAUDIT)

• dodavanje komentara u rječnik podataka. c) TCL izrazi za kontrolu transakcije upravljaju promjenama

uzrokovanim DML izrazima. Oni omogućuju:

• trajno potvrđivanje transakcije (naredba: COMMIT) • vraćanje baze u stanje prije izvođenja transakcije (naredba:

ROLLBACK)

• definiranje točke od koje se može povratiti stanje baze (naredba: SAVEPOINT)

• definiranje svojstva transakcije (naredba: SET

TRANSACTION).



d) Izrazi za kontrolu sesija omogućuju upravljanje svojstvima sesije određenog korisnika:

• mijenjanje važeće sesije izvođenjem određene naredbe

(naredba: ALTER SESSION) • aktiviranje i deaktiviranje uloga za važeću sesiju (naredba:

SET ROLE). e) Izrazi za kontrolu sustava mijenjaju svojstva instance baze

podataka. Jedina naredba je ALTER SYSTEM a omogućuje mijenjanje minimalnog broja dijeljenih servera i deaktiviranje sesije.

f) Ugrađeni SQL izrazi spajaju DDL, DML i izraze za kontrolu

transakcija u proceduralni program. Oni se koriste sa pre-prevodiocima baze podataka, a omogućavaju:

• definiranje, alociranje i otpuštanje kursora (Kursori su

“držači” ili imena područja u memoriji u kojima se drže rastavljeni izrazi i ostale informacije za procesiranje izraza) – naredbe: DECLARE CURSOR, OPEN, CLOSE

• deklariranje imena baze podataka i spajanje na istu –

naredbe: DECLARE DATABASE, CONNECT

• dodjeljivanje imena varijablama, specificiranje događaja i pogrešaka – naredbe: DECLARE STATEMENT, DESCRIBE, WHENEVER

• rastavljanje i izvođenje SQL izraza, pretraživanje podataka iz

baze – naredbe: PREPARE, EXECUTE, EXECUTE IMMEDIATE, FETCH.



Osnovne naredbe SQL-a U daljnjem tekstu detaljnije su pojašnjene sljedeće osnovne naredbe SQL-a: • kreiranje tablice (relacije) • unos podataka u tablice (relacije) • dohvaćanje podataka iz tablice (pretraživanje) • izmjena podataka u tablicama (relacijama) • brisanje podataka iz tablica (relacija) Kreiranje tablice Opći oblik SQL naredbe za kreiranje tablica u relacijskom modelu je:

• CREATE TABLE <ime-tablice> <definicija atributa>

Definicija atributa ima oblik:

<ime stupca tip podatka > < [NOT NULL]>

gdje se pod tipom podatka podrazumijevaju standardni SQL tipovi podataka putem kojih se određuje kakvi se podaci mogu pohraniti u konkretnu tablicu tj. polje tablice (znakovni, isključivo numerički, datumski i sl.), dok se s NOT NULL definira obveznost unosa podatka u tablicu na način da NOT NULL znači da se taj podatak obvezno mora unijeti (u suprotnom se ne može napraviti pohranjivanje podataka iz tog retka tablice u bazu podataka), odnosno NULL znači da podataka nije obvezan. Naredbom CREATE formira se prazna tablica s određenim imenom, imenima i tipovima stupaca (atributa). Primjer: CREATE TABLE Proizvodi

(Šifra INTEGER(5) NOT NULL, Naziv VARCHAR(50), Jedinica_mjere VARCHAR(10), Količina NUMBER(15,2), Cijena NUMBER(15,2))



Unos podataka u tablice Opći je oblik naredbe SQL-a za unos podataka, odnosno dodavanje novih redaka u tablicu jeste:

• INSERT INTO ime-tablice (lista_atributa) VALUES (lista_vrijednosti) ili

• INSERT INTO ime-tablice (lista_vrijednosti) SELECT ... FROM ... WHERE ...

U drugom slučaju, kombiniranjem naredbi INSERT i SELECT preuzimaju se vrijednosti iz neke druge tablice. Primjer: INSERT INTO Proizvodi (Šifra, Naziv, Jedinica_mjere, Količina,Cijena) VALUES (342,'Kruh','komad',32,4); Dohvaćanje podataka iz tablica Veoma je česta uporaba SQL-a za pretraživanje (dohvaćanje) podataka u tablicama. Najčešće se rabi sljedeći oblik, tj. naredba SELECT:

SELECT [All/DISTINCT] <lista atributa> FROM <lista tablica> WHERE <uvjet>;

gdje je: <Lista atributa > - stupci (atributi) tablica (relacija) koji se žele u rezultatu. (SELECT odgovara operaciji projekcije u relacijskoj algebri.) <Lista tablica> - tablice (relacije) koje se rabe u pretraživanju, pa je FROM ekvivalentan operaciji Kartezijeva produkta u relacijskoj algebri.



<Uvjet> - predikat koji zadovoljavaju selektirane n-torke u rezultatu, pa je WHERE ekvivalentan operaciji selekcije u relacijskoj algebri. Primjeri: Dana je relacija Proizvodi:

• Uporabom naredbe SELECT, treba prikazati nazive proizvoda

koji se nalaze na zalihi. SELECT Naziv FROM Proizvodi;

To je jednostavan upit koji ne rabi parametar WHERE (parametar operacije selekcije u relacijskoj algebri) pa je rezultat tog upita projekcija relacije Proizvodi na atribut Naziv (Naziv je ime atributa koji označuje naziv proizvoda). Rezultat upita je:

Rezultat nije prava projekcija jer postoje n-torke koje se ponavljaju. Ako se želi prava projekcija, onda upit treba imati slijedeći oblik:

SELECT DISTINCT Naziv FROM Proizvodi;

Proizvodi Šifra Naziv Jedinica_mjere Količina Cijena 342 Kruh komad 32 4 456 Pivo litra 452 6 122 Cigarete komad 45 10 121 Cigarete komad 523 7 768 Ulje litra 34 8

Naziv Kruh Pivo Cigarete Cigarete Ulje



Rezultat je: Prava projekcija je restriktivna jer smanjuje broj redaka. Rezultat upita je relacija jer su eliminirana ponavljanja istih n-torki. Njezina uporaba se preporuča samo ako je to nužno.

• Prikazati šifre proizvoda i nazive proizvoda čija je cijena veća od 5, a količina veća od 30 jedinica.

SELECT Šifra, Naziv FROM Proizvodi WHERE Cijena >= 5 AND Količina > 30 ;

Rezultat:

Ako se žele prikazati svi atributi relacije, tada se ne moraju navoditi. Može se jednostavno napisati SELECT *. Veoma je korisno uz ime atributa navesti i ime relacije (zapisati atribut u obliku: ime_relacije.ime_atributa) kojoj pripada jer je moguće postojanje istih imena atributa u više relacija. Npr. relacija Dobavljaci sadrži atribut Naziv, a i relacija Proizvodi sadrži atribut s istim imenom - Naziv. Zato je dobro u nazivu atributa pisati i ime relacije, tj. Dobavljaci.Naziv, odnosno Proizvodi.Naziv. Ako se želi odrediti redoslijed n-torki (sortirati) u relaciji rezultata, rabi se klauzula

ORDER BY ime_atributa [redoslijed] [,ime_atributa [redoslijed]] ...

Naziv Kruh Pivo Cigarete Ulje

Proizvodi Šifra Naziv 122 Cigarete 121 Cigarete 768 Ulje



Primjer: Prikazati šifre proizvoda i nazive proizvoda čija je cijena veća od 7, a kupljena količina veća od 10 jedinica po rastućem redoslijedu šifre proizvoda.

SELECT Šifra, Naziv FROM Proizvodi WHERE Cijena >= 7 AND Količina > 30 ORDER BY ŠifraP ASC;

Često se primjenjuje i klauzula LIKE kojom se mogu pretraživati vrijednosti atributa kao niz karaktera (znakova) s vrijednosti koja je djelomično poznata (zadana). Rabi se sljedeća oznaka:

% predstavlja (zamjenjuje) niz od 0 ili više znakova.

Primjer: Prikazati nazive proizvoda koji počinju s K.

SELECT Naziv FROM Proizvodi WHERE Naziv LIKE 'K%';

Testiranje nula vrijednosti omogućuju klauzule IS NULL i IS NOT NULL. Primjer: Prikazati šifre proizvoda čije cijene nisu poznate.

SELECT Šifra FROM Proizvodi WHERE Cijena IS NULL;

SQL omogućava kreiranje upita (pretraživanje) nad više tablica (relacija) istovremeno. Upiti nad više relacija postavljaju se "ugnježđivanjem" jednog u drugi upit ili uporabom upita spajanja (join queries). Ugnježđivanje upita primjenjuje se kada se pretražuje više relacija, a prikazuju atributi samo jedne relacije. Upit koji se nalazi unutar jednog upita (ugniježđeni upit), naziva se podupit (subquery).



Primjeri: • Prikazati šifre i nazive proizvoda koji se nalaze u skladištu čiji

je naziv Glavno skladište. Za zadovoljenje tog upita trebaju se uzeti podaci iz dviju tablica: iz tablice Proizvodi i tablice Skladišta. Upit bi mogao izgledati ovako:

SELECT Šifra, Naziv FROM Proizvodi WHERE Šifra_skladišta= (SELECT Šifra FROM Skladišta

WHERE Naziv = 'Glavno skladište')

Podupit daje rezultat, npr. Šifra_skladišta=1, i taj rezultat se primjenjuje u WHERE dijelu osnovnog upita (upita u kojem je drugi SELECT ugniježđen).

• Prikazati imena radnika u skladištima u kojima postoje zalihe proizvoda čija je količina veća od 5000 jedinica.

SELECT Ime FROM Radnici WHERE Šifra_skladišta IN (SELECT Šifra FROM Skladišta

WHERE Šifra_proizvoda IN (SELECT Šifra FROM Proizvodi WHERE Količina>=5000));

• Prikazati nazive proizvoda i imena radnika u skladištima gdje postoje proizvodi čija je količina na zalihi > 5000 jedinica. Taj upit je sličan prethodnom, ali traži još prikazivanje atributa iz dviju relacija (osim atributa Ime iz relacije Radnici i atributa Naziv iz relacije Proizvodi). Takav upit ne može se zadovoljiti umetanjem upita, nego pomoću spajanja dviju relacija:

SELECT Radnici.Ime, Proizvodi.Naziv FROM Radnici, Skladišta, Proizvodi WHERE Radnici.Šifra_skladišta= Skladišta.Šifra AND Proizvodi.Šifra_skladišta= Skladišta.Šifra AND Proizvodi.Količina > 5000;



Operacija spajanja je vremenski najzahtjevnija pa treba biti oprezan prilikom njene primjene! Međutim u sustavu za upravljanje bazom podataka koji ima dobre optimizatore upita, vrijeme odgovora na upit može biti jednako bez obzira piše li se neki upit kao upit spajanja ili ugnježđivanja (naravno, svaki upit napisan kao ugnježđivanje može se napisati pomoću upita spajanja).

• Spajanje relacije sa samom sobom. Prikazati nazive proizvoda koji imaju na zalihi jednake količine.

SELECT Proizvod1.Naziv, Proizvod2.Naziv, Proizvod1.Količina FROM Proizvodi Proizvod1, Proizvodi Proizvod2 WHERE Proizvod1.Količina =Proizvod2.Količina

Relacija Proizvodi pojavljuje se u dijelu From naredbe Select s dva naziva kao Proizvod1 i Proizvod2. Ti sinonimi se primjenjuju u dijelu Select i Where. Naime, vrši se spajanje tih dviju relacija Proizvod1 i Proizvod2 u dijelovima Select i Where upita. Izmjena podataka u tablicama Izmjena vrijednosti podataka (ažuriranje) u tablici postiže se uporabom naredbe UPDATE. Opći oblik te naredbe može se prikazati kao:

UPDATE <ime-tablice> SET <atribut = izraz> WHERE <uvjet> U svim n-torkama u relaciji koje zadovoljavaju uvjet mijenja se (ažurira) vrijednost navedenih atributa. Primjer:

• U tablici Proizvodi, za šifru proizvoda 456 (Pivo) promijeniti cijenu s 6 na 5.

UPDATE Proizvodi SET Cijena=5 WHERE Šifra=456;



Brisanje podataka iz tablica Za brisanje podataka iz tablice koristi se SQL naredba DELETE (brisanje). Opći je oblik te naredbe je:

DELETE FROM <ime-tablice> WHERE <uvjet>

Ona briše sve n-torke koje zadovoljavaju uvjet. Primjer: Iz tablice Proizvodi izbrisati Cigarete. DELETE FROM Proizvodi WHERE Naziv LIKE 'Cigarete%'; Kao što je već rečeno, ovdje su pojašnjene samo neke od naredbi SQL-a, kako bi se barem donekle stekao uvid u mogućnosti tog jezika, koji i pored svoje neproceduralne orijentacije, a zahvaljujući čvrstoj utemeljenosti na relacijskoj algebri, omogućava korisnicima potpuno manipuliranje podacima u relacijskoj bazi podataka.

baze podataka biljeske 02

Documents