D E O

Teorija relacionih baza podataka

P O G L A V L J E

Osnovni pojmovi
Dakle, ta je to mitsko bie, poznato pod imenom relaciona baza podataka (engl. relational database)? Ukratko, baza podatka je alatka koja omoguava skladitee podataka i rad s ima, na efikasan i delotvoran nain. Efikasno i delotvorno znai da su podaci zatieni od nenamernog gubea ili oteea, da se za tu namenu ne koristi vie resursa (udskih ili raunarskih) nego to je zaista neophodno i da se podaci mogu uitavati u smislenim oblicima unutar prihvativih ograniea performansi. Da bi se mogla kvalifikovati kao relaciona, baza podataka mora da realizuje relacioni model, to je nain na koji se opisuje odreeni aspekt stvarnog sveta, u skladu s pravilima koje je definisao dr E. F. Codd kasnih ezdestih godina. Teorijski, softver za relacionu bazu podataka moe se napisati od nule, ali u praksi ete uvek koristiti usluge odreenog sistema za upravae bazama podataka (engl. database management system, DBMS). DBMS se ponekad naziva relacioni DBMS (RDBMS), ali tehniki gledano, da bi se jedan DBMS kvalifikovao kao relacioni, morao bi da ispuni nekih 300 uslova, a koliko ja znam, nijedan sistem koji postoji na tritu nije u potpunosti kvalifikovan. Dva sistema za upravae relacionim bazama podataka koje emo razmatrati u ovoj kizi, jesu Microsoftov Jet i Microsoftov SQL Server. Ve sam napomenula da je relaciona baza fizika realizacija relacionog modela (modela podataka); vano je da razlikujete ta dva pojma. Kao to ete saznati u drugom delu kige, dimenzionalni model moe se realizovati i na relacionom DBMS-u, a ako brkate pojmovno (konceptualno) s fizikim, biete potpuno zbueni. (Da, ba tako govori moje iskustvo.)

ta je to baza podataka?
Terminologija baza podataka gotovo je isto toliko neodreena koliko i izraz objektno orijentisano programirae. Izraz baza podataka koristi se za opisivae svaega, u opsegu od obine grupe podataka, do sloenog skupa alatki, kao to je SQL Server, a i svega izmeu. Taj maak preciznosti ne

Poglavlje 1

Osnovni pojmovi

mora obavezno da znai neto loe razlog je sama priroda jezika ali poto nije ni naroito koristan za nae namene, pokuau da ovde budem preciznija. Na slici 11 prikazane su veze izmeu izraza koje pomiemo u ovom poglavu. Te izraze definiemo u ovom poglavu, a detano emo ih razmotriti u preostalom delu kige.

Sistem koji radi s bazom podataka Aplikacija se sastoji od obrazaca i izvetaja s kojima radi korisnik aplikacije

Maina baze podataka nije sastavni deo baze podataka

Baza podataka sadri fiziki oblik eme i podataka

ema baze podataka opisuje model podataka koji se uvaju u bazi

Model podataka je konceptulani opis prostora problema

Prostor problema je neki dobro definisan deo stvarnog sveta

Slika 11 Terminologija relacionih baza podataka

ta je to baza podataka?

Iako se za relacione baze podataka ne mogu nai analogije u stvarnom svetu, svrha veine baza podataka je da modeluju odreeni aspekt iz stvarnog ivota. Taj deli stvarnog sveta nazvau prostor problema (engl. problem space). Po samoj svojoj prirodi, prostor problema je zbrkan i sloen kada ne bi bio takav, ne bi ni trebalo da pravite egov model. Meutim, za uspeh projekta od kune je vanosti da sistem za koji projektujete bazu podataka bude ogranien na tano definisan skup objekata i ihovih odnosa; jedino na taj nain moi ete da donosite pravilne odluke o opsegu koji sistem treba da obuhvati. Izraz model podataka (engl. data model) koristiu za pojmovni opis prostora problema. Rad s relacionim modelom obuhvata definicije entiteta, ihovih atributa (na primer, Kupac je entitet, koji moe imati atribute Prezime i Adresa) i ograniea koja vae za atribute (kao to je, na primer, pravilo da poe ImeKupca ne moe biti prazno). Kada radite s dimenzionalnim modelom, definicija modela podataka obuhvata ienice i dimenzije, ali time emo se baviti u drugom delu kige. Model podataka takoe obuhvata opis veza ili odnosa izmeu pojedinih entiteta, kao i ograniea koja vae za te veze. Na primer, rukovodilac grupe ne moe imati vie od pet podreenih koji mu podnose izvetaje. Model podataka nita ne govori o fizikoj strukturi sistema. Definicija fizike strukture tabela i prikaza koji e biti napraveni zove se ema baze podataka (engl. database schema) ili samo ema. To je preslikavae pojmovnog modela u fiziki oblik, koji se moe realizovati pomou nekog DBMS-a. Imajte u vidu da je ema takoe konceptualni pojam, a ne fiziki. ema nije nita drugo do model podataka izraen pomou elemenata koje maina baze podataka (engl. database engine) prepoznaje, kao to su tabele, okidai i slina bia. Jedna od prednosti upotrebe maine baze podataka jeste to to ne morate da se bavite fizikim oblikom baze podataka; moete slobodno zanemariti B-stabla, vorove na nivou listova stabla i druge fizike koncepte nieg nivoa. Poto maini baze podataka objasnite kako elite da podaci izgledaju, pomou SQL koda, ili u nekom interaktivnom okrueu, kao to je Microsoftov Access, ili SQL Server Enterprise Manager, maina baze podataka pravi nekoliko fizikih objekata (obino, ali ne uvek, negde na vrstom disku) u koje ete kasnije smestiti podatke. Tu kombinaciju strukture i podataka zvau baza podataka. Takva baza podataka sadri: fizike tabele u kojima se uvaju podaci; definisane prikaze, upite i uskladitene procedure koje omoguavaju uitavae podataka na razne naine; pravila ije potovae obezbeuje maina baze podataka i time titi podatke.

Poglavlje 1

Osnovni pojmovi

Izraz baza podataka ne odnosi se na aplikaciju koja se sastoji od obrazaca i izvetaja s kojima radi korisnik aplikacije, niti se odnosi na bilo koju drugu vrstu softvera kao to je posredniki sloj ili Internet Information Server ija je namena da povezuje eonu i pozadinsku komponentu sistema. Izraz baza podataka takoe iskuuje mainu baze podataka. Prema tome, Accessova .mdb datoteka je baza podataka, dok je Microsofov Jet maina baze podataka. U stvari, .mdb datoteka moe da sadri i objekte aplikacije na primer, obrasce i izvetaje ali to je tema koju emo razmotriti kasnije. Da bih obuhvatila sve navedene komponente aplikaciju, bazu podataka i mainu baze podataka, koristiu izraz sistem koji radi s bazom podataka (engl. database system). Sve softverske komponente i svi podaci koji su neophodni za rad produkcionog sistema, ine sistem koji radi s bazom podataka.

Alatke za rad s bazama podataka

Iako je glavna tema ove kige projektovae a ne izrada baza podataka, apstraktna teorija nije naroito korisna ako ne znate kako da je primenite; zato emo u ovoj kizi mnogo govoriti o izradi relacionih baza podataka pomou Microsoftovih alatki. Na raspolagau je veliki broj alatki te vrste, a izgleda da Microsoft svaki as nudi neku novu; zato emo posvetiti malo vremena razmatrau o emu se tu radi i gde sve to tano spada. Na slici 12 prikazane su alatke koje emo razmatrati. Najlake je da o ima razmiate imajui na umu ta nama kao projektantima treba da bismo sistem preslikali iz apstraktnog modela u ivi produkcioni sistem; tako su i alatke grupisane na slici.

Maine baza podataka

Na najniem nivou nalaze se maine baza podataka (engl. database engines). Ponekad se nazivaju i pozadinske komponente (engl. back ends), ali je to prilino loe, jer izraz pozadinska komponenta zapravo opisuje fiziku arhitekturu, kao to emo videti u poglavu 13. Zadatak tih alatki je fiziko manipulisae podacima smetae na disk i uitavae s ega na zahtev. Razmotriemo dve meu ima: Jet i SQL Server. Moda vas iznenauje to ovde ne pomiem Microsoftov Access. Tehniki gledano, Access je okruee za razvoj eonog dela aplikacije, koje za skladitee podataka standardno koristi Jet ili SQL Server, a moe da koristi i bilo koju drugu mainu baze podataka koja podrava standard ODBC. Access radi s podacima koji se uvaju u .mdb datotekama pomou maine Jet, a SQL Server (ili drugu ODBC mainu baze podataka) koristi kada radi s podacima u .adp datotekama. Access je oduvek koristio mainu Jet, koju Microsoft nije nudio kao zasebnu komponentu do izdavaa Visual Basic a 3.

Alatke za rad s bazama podataka

Okruee za definisae podataka Microsoft Access SQL Server Enterprise Manager

Razvoj eonih komponenata Microsoft Access Visual Studio .NET Analysis Manager

Objektni model za pristupae podacima ADO.NET ADO DAO

Maina baze podataka

Microsoft Jet

SQL Server MSDE

Slika 12 Alatke za rad s bazama podataka koje emo razmatrati u ovoj kizi

I Jet i SQL Server, mada veoma razliiti, izuzetne su alatke za skladitee podataka i rad s ima. Razlikuju se po arhitekturi i problemima za ije su reavanje projektovane. Microsoftov Jet je stona maina baze podataka, nameena sistemima koji se po veliini mogu svrstati u opseg od malih do sredih. (Molim vas da imate u vidu da to nikako ne znai da je maina baze podataka Jet pogodna samo za trivijalne sisteme.) S druge strane, SQL Server koristi arhitekturu klijent/server i nameen je sistemima u opsegu od sredih do ogromnih, koji se potencijalno mogu smanjiti ili poveati za hiade korisnika aplikacija od kune vanosti za kompaniju. MSDE (akronim za Microsoft Desktop Engine) funkcionalno je ograniena verzija SQL Servera nameena upotrebi u jednokorisnikom okrueu. Gledano iz ugla projektanta, razlika izmeu MSDE-a i pune verzije SQL Servera zanemariva je i neemo se baviti ome. U celoj ovoj kizi baviemo se razlikama izmeu dve navedene maine baze podataka, a u poglavu 13 razmotraemo kompromise izmeu ihove dve arhitekture.

Poglavlje 1

Osnovni pojmovi

NAPOMENA O YUKONU: U vreme pisaa ove kige (prolee 2004. godine), nova verzija SQL Servera, koja je imala radno ime Yukon, bila je u ranoj beta fazi. Bilo je poznato da e Yukon doneti znaajnu novu funkcionalnost, ali se nije znalo ta e to tano biti. Zbog te (razumive) nepoznanice, ograniila sam primarni deo gradiva na mogunosti SQL Servera 2000, koji se jo uvek iroko koristi. Mogunosti za koje se oekuju znaajne promene navela sam u napomenama kao to je ova.

Objektni modeli za pristupae podacima

Microsoftov Access, a u maoj meri i Visual Studio .NET, nude jednostavne mehanizme za povezivae kontrola na obrascima direktno sa izvorom podataka, ime se izbegava potreba da programer radi neposredno s mainom baze podataka. Meutim, iz raznih razloga koje emo razmotriti, to nije uvek ni mogue ni prikladno. U takvim sluajevima moraete da koristite objektni model za pristupae podacima (engl. data access object model) da biste s podacima radili pomou programskog koda. Objektni model za pristupae podacima vrsta je lepka izmeu okruea za programirae aplikacija i maine baze podataka; model stava na raspolagae skup objekata, sa njihovim svojstvima i metodama koji se mogu koristiti u programskom kodu. Budui da se ova kiga bavi projektovaem vie nego realizovaem, neemo detano razmatrati razlike izmeu tih modela, ali smatram da je korisno da ih ovde ukratko pomenemo. Microsoft (zasad) stava na raspolagae tri objektna modela za pristupae podacima: Data Access Objects (DAO), koji postoji u dve varijante (DAO/Jet i DAO/ODBCDirect), Microsoft ActiveX Data Objects (ADO) i ADO.NET. DAO, najstariji od svih, standardni je interfejs za mainu baze podataka Jet. Bez obzira na tvrde Microsoftove slube za marketing, to je najefikasniji objektni model za rad s Jetovim bazama podataka u Accessu. ADO koristi jednostavniju hijerarhiju objekata nego DAO jer se sastoji od samo etiri primarna objekta i donosi nekoliko znaajnih proirea osnovnog modela na primer, podrku za rad s nepovezanim i hijerarhijskim skupovima podataka. Koristi se u Microsoftovom Accessu i u drugim softverskim proizvodima koji podravaju upotrebu jezika VBA za rad sa svakom bazom podataka koja podrava ODBC interfejs, kao to su to i Jet i SQL Server. ADO.NET je, naravno, verzija modela ADO za rad unutar .NET Frameworka.

Relacioni model

Okruea za definisae podataka

Microsoftov Jet i SQL Server obavaju poslove fizikog manipulisaa podacima umesto nas, a nama treba nain da im opiemo kako da strukturiraju podatke. Microsoft nudi bezbroj metoda za tu namenu, ali ovde emo razmotriti samo tri: Access i SQL Server Enterprise Manager za relacione modele, i Analysis Manager za dimenzionalne modele. Postoje i druge alatke koje pruaju sline mogunosti, ali najradije koristim navedene tri. Kada savladate principe, izabraete alatku koja je najpogodnija za posao koji treba da obavite. Strukturu baze podataka moete definisati i pomou SQL koda; opisau kako se to radi, mada u uobiajenim okolnostima to ne preporuujem. Osim kada je iz nekog razloga neophodno da izmenite strukturu podataka aplikacije dok se ona izvrava (mada nisam pobornik te prakse ako ema baze podataka nije stabilna, verovatno niste dobro razumeli domen problema), interaktivne alatke su bre, lake i zabavnije za upotrebu.

Razvoj eone komponente aplikacije

Kada zavrite fiziku definiciju baze podataka, potrebne su vam alatke za izradu obrazaca i izvetaja s kojima e korisnici raditi. Razmotriemo primere upotrebe dve takve alatke: Access i Visual Studio .NET (konkretno, Visual Basic .NET). U ovoj kategoriji takoe postoji bezbroj alatki za izradu eonih komponenata, ali budui da su principi rada uvek isti, trebalo bi da budete u stau da ono to iz ove kige nauite primenite na alatku za koju se opredelite. U poglavu 10 ukratko emo razmotriti itae Weba, ali je sam HTML izvan opsega ove kige.

Relacioni model
Relacioni model se zasniva na grupi matematikih principa izvedenih iz teorije skupova i predikatne logike. Te principe je kasnih ezdesetih godina prvi primenio na oblast modelovaa podataka dr E. F. Codd, tada istraiva u kompaniji IBM, a egovi radovi prvi put su objaveni 1970. godine. 1 Pravila relacionog modela definiu oblik u kojem se podaci predstavaju (struktura podataka), nain na koji se podaci tite (integritet podataka) i operacije koje se mogu izvravati nad podacima (manipulisae podacima).

1. Codd, E. F. A Relational Model of Data for Large Shared Data Banks, Communications of the ACM, tom 13, broj. 6 (jun 1970).

10

Poglavlje 1

Osnovni pojmovi

Relacioni model nije jedini model koji postoji za skladitee podataka i rad s njima. Ostale mogunosti su hijerarhijski, mreni i objektni modeli podataka. Svaki ima svoje pristalice i prua neosporne prednosti za odreene vrste poslova. Meutim, zbog svoje efikasnosti i prilagodivosti, relacioni model je najpopularnija tehnika rada s bazama podataka i ega emo razmatrati u ovoj kizi. I Jet i SQL Server realizuju relacioni model. Razmotriemo i dimenzionalni model, to je specijalna vrsta relacione eme za skladitee arhivskih podataka. Dimenzionalni model i egove veze s relacionim modelom, detano emo obraditi u drugom delu kige. Uopteno govorei, sistemi relacionih baza podataka imaju sledee odlike:

Svi podaci se konceptualno predstavaju organizovani u redove i kolone; skup tako organizovanih podataka zove se relacija (engl. relation). Sve vrednosti su skalarne. To znai da se na svakom mestu koje je odreeno datim redom i kolonom, nalazi jedna i samo jedna vrednost. Sve operacije obavaju se nad celom relacijom, a rezultat je takoe cela relacija. Taj koncept je poznat kao celovitost (engl. closure).

Ako ste dosad radili s bazama Microsoftovog Accessa, prepoznali ste relaciju kao skup zapisa (engl. recordset) ili, u SQL Serverovoj terminologiji, kao skup rezultata (engl. result set). Kada je formulisao relacioni model, dr Codd je izabrao re relacija jer nije imala praktino nikakvo drugo znaee zavisno od konteksta, za razliku od, na primer, rei tabela. Uvreeno je pogreno miee da se relacioni model tako zove zbog veza (engl. relationships) koje uspostavamo izmeu tabela. Ime zapravo potie od relacija na kojima se model zasniva. Imajte u vidu to da model zahteva da podaci budu predstaveni u obliku relacija samo na konceptualnom nivou; model ne propisuje fiziki oblik u kojem se podaci uvaju. Razdvajae konceptualnog oblika od fizikog, mada sada izgleda oigledno, bilo je velika inovacija pre 30 godina kada je programirae baza podataka uglavnom znailo pisae mainskog koda za fiziko manipulisae ureajima za skladitee podataka. U stvari, relacijama nije ni potreban fiziki oblik. Odreena relacija moe se preslikati u stvarnu, fiziku tabelu koja se uva na vrstom disku, ali moe se sastojati i od kolona koje potiu iz gomile razliitih tabela, uz jo nekoliko izraunatih kolona koje fiziki nigde ne postoje dodatih tek da stvar bude sloenija. Relacija se moe nazvati relacijom ako su podaci organizovani u redove i kolone i ako su vrednosti podataka iskuivo skalarne. Postojae relacije potpuno je nezavisno od fizikog oblika podataka.

Relaciona terminologija

11

Uslov da svi podaci od kojih se relacija sastoji budu skalarni, ponekad moe navesti na pogrene zakuke. Pojam proste vrednosti subjektivan je sam po sebi i zavisi od semantike modela podataka. Na primer, Ime osobe moe biti prosta vrednost u jednom modelu, ali u nekom drugom okrueu ta vrednost e moda biti podeena na elemente kao to su Funkcija, Ime i Prezime, dok e tree okruee moda zahtevati i Oevo ime ili Titulu. Nijedno od navedenih reea nije ni boe ni gore od drugog u apsolutnom smislu; sve zavisi od svrhe za koju e se podaci koristiti. Princip celovitosti tj. da se i tabele i rezultati operacija nad ima predstavaju u obliku relacija omoguava da se rezultati jedne operacije upotrebe kao ulazni podaci za drugu operaciju. Zahvaujui tome, i Jet i SQL Server omoguavaju da rezultati jednog upita budu osnova za drugi upit. Ta ienica prua projektantima baza podataka mogunost da operacije koje su sloene ili se esto obavaju, izdvoje u zasebne celine koje se mogu ponovo izvriti gde god i kad god je to potrebno. Na primer, napravili ste upit koji ste nazvali UpitPunoIme; on nadovezuje sve elemente od kojih se sastoji ime osobe da bi dobio izraunato poe nazvano PunoIme. Moete zatim napraviti drugi upit iji je izvor podataka UpitPunoIme i u kojem se izraunato poe PunoIme koristi na isti nain kao da je u pitau poe koje postoji u izvornoj tabeli. Nema potrebe da ponovo sastavate elemente imena. Razume se, ovo je jednostavan primer i verovatno nije sasvim oigledna neka znaajna prednost koju bi pozivae upita UpitPunoIme prualo nad ponovnim sastavaem elemenata imena. Ali, kao to emo videti, jezik SQL omoguava sastavae izuzetno sloenih upita, a kako raste sloenost upita, tako postaju i sve vidljivije prednosti upotrebe postojeih upita kao ulaznih podataka za nove.

Relaciona terminologija
Na slici 13 prikazana je relacija na kojoj su oznaena formalna imena osnovnih komponenata. itaoci koji znaju neto o projektovau relacionih baza podataka, prepoznae da relacija nije u normalnoj formi. To je sasvim u redu; i dae se moe nazvati relacijom zato to su podaci razmeteni u redove i kolone, a sve vrednosti su skalarne. Kao to smo ve naveli, cela struktura je relacija. Svaki red podataka zove se torka (engl. tuple). Tehniki gledano, svaki red je zapravo n-torka (npr. petorka, estorka itd.), ali se n- obino izostava. Ukupan broj torki u relaciji odreuje kardinalitet (engl. cardinality) relacije. U primeru na

12

Poglavlje 1

Osnovni pojmovi

slici, kardinalitet je 18. Svaka kolona torke zove se atribut ili obeleje (engl. attribute). Ukupan broj atributa odreuje stepen (engl. degree) relacije. U primeru na slici, stepen relacije je 3.
Atributi Zaglave Torke

Slika 13 Komponente relacije

Relacija je podeena na dva odeka: zaglave i telo. Torke ine telo relacije dok se zaglave sastoji od ... zaglava. Obratite pau na to da se u relacionoj notaciji natpis u zaglavu svakog atributa sastoji od dva dela, razdvojena dvotakom na primer, UnitPrice:Currency. Prvi deo natpisa je ime atributa, dok je drugi domen atributa. Domen (engl. domain) atributa je vrsta podataka koje atribut predstava u ovom sluaju to su novani iznosi. Domen nije isto to i tip podataka. To pitae emo detano razmotriti u narednom odeku. Specifikacija domena esto se izostava iz natpisa u zaglavu. Telo relacije sastoji se od neureenog skupa jedne ili vie torki. Tu imamo nekoliko vanih koncepata. Prvo, relacija nije ureena. Zamislite relaciju kao papirnatu kesu (ili skupocenu kinesku vazu, ako ste pesniki raspoloeni) u kojoj su torke nagomilane bez ikakvog posebnog redosleda. Redni brojevi zapisa, uobiajen mehanizam za pristupae zapisima u nerelacionim bazama podataka, ne postoje u relacijama. Drugo, relacija bez ijedne torke (tzv. prazna relacija) takoe je relacija. Tree, relacija je skup. Svaki element skupa se, po definiciji, moe nedvosmisleno identifikovati. Prema tome, da bi se odreena tabela kvalifikovala kao relacija, svaki zapis mora da bude nedvosmisleno identifikovan i tabela ne sme da sadri duplirane zapise.

Telo

Model podataka

13

Ako ste itali Accessovu ili SQL Serverovu dokumentaciju, moda se sad pitate zato niste tamo nailazili na ove rei. To su formalni izrazi koji se koriste u tehnikoj literaturi, ali ih Microsoft ne koristi. Ovde sam ih navela samo zato da se ne biste obrukali na nekom prijemu (ili barem ne ako bude re o n-torkama treeg stepena). Naalost, Microsoftovi proizvodi ne samo to nisu usklaeni s formalnom terminologijom, nego nisu usklaeni ni meusobno. Izrazi koji se koriste u dva Microsoftova proizvoda prikazani su u tabeli 11. U ovoj kizi koristiu formalnu terminologiju.
Tabela 11 Relaciona terminologija koja se koristi u proizvodima razmotrenim u ovoj kizi Formalna terminologija Konceptualna relacija atribut torka Fizika tabela poe zapis Microsoft Access tabela ili skup zapisa poe zapis SQL Server tabela ili skup rezultata kolona red

Model podataka
Najapstraktniji nivo projektovanja baze podataka jeste model podataka, to je konceptualni opis prostora problema. Modeli podataka sastoje se od elemenata koji mogu biti entiteti, atributi, domeni i veze. U preostalom delu ovog poglava pojedinano razmatram te elemente.

Entiteti
Teko je osmisliti preciznu formalnu definiciju entiteta (engl. entity), ali je pojam relativno lako razumiv: entitet je sve o emu sistem treba da skladiti podatke. Kada ponete da projektujete model podataka, nee vam biti teko da sastavite poetnu listu entiteta. Kada vi (ili vai klijenti) govorite o prostoru problema, veina imenica i glagola kandidati su za entitete. Kupci kupuju robu. Prodavci prodaju robu. Dobavai nam prodaju robu. Imenice Kupci, Roba, Prodavci i Dobavai predstavljaju oigledne entitete. Dogaaji predstaveni glagolima kupiti i prodati takoe su entiteti, ali tu postoji nekoliko zamki. Prvo, glagol prodati predstava dva razliita

14

Poglavlje 1

Osnovni pojmovi

dogaaja: prodaju robe kupcu (ProdavacKupac) i nabavae robe za prodaju (DobavaKompanija). U ovom primeru, razlika je sasvim oigledna, ali je to zamka u koju se lako upada, naroito ako niste dobro prouili prostor problema. Druga zamka je suprotna prvoj: dva razliita glagola (kupuju u prvoj reenici i prodaju u drugoj) opisuju zapravo isti dogaaj, tj. da je kupac kupio odreenu robu. Ponavam, to nije uvek oigledno, osim kada dobro poznajete prostor problema. Ovaj problem se esto tee uoava od prvog. Ako klijent koristi razliite izraze da bi opisao neto to vama na prvi pogled izgleda kao isti dogaaj, on moda govori o razliitim vrstama dogaaja. Na primer, ako je va klijent proizvoa konfekcije, rezultat dogaaja kupac kupuje odelo i kupac naruuje odelo u oba sluaja je prodato odelo, ali u prvom sluaju to moe biti kupovina ve gotovog konfekcijskog odela, dok se u drugom sluaju radi o iveu odela po meri. To su dve vrlo razliite rade koje se moraju modelovati na razliite naine. Osim razgovora s klijentima na osnovu kojih ete sastaviti listu entiteta, korisno je i da prouite dokumente koji postoje u prostoru problema. Obrasci za unoee raznih podataka, izvetaji i pisana uputstva, dobri su izvori kandidata za entitete. Meutim, morate biti oprezni kada radite s dokumentima. Pisani dokumenti mogu biti prilino zastareli tampani obrasci za unoee podataka mogu biti poprilino skupi i esto ne prate promene poslovnih pravila i postupaka. Ako naiete na entitet koji se ne pomie ni u jednom razgovoru, nemojte pretpostaviti da je klijent zaboravio da ga pomene. Verovatnije je da taj entitet vie nije vaan organizaciji. Moraete sami da ispitate ta je tano posredi. Veina entiteta su modeli objekata ili dogaaja iz stvarnog ivota: kupci, roba, prodajne ponude. To su konkretni entiteti. Entiteti mogu biti i modeli apstraktnih koncepata. Najuobiajeniji primer apstraktnog entiteta jeste entitet koji modeluje vezu ili odnos (engl. relationship) izmeu drugih entiteta na primer, ienicu da je odreeni predstavnik kompanije odgovoran za odreenog klijenta, ili da odreeni student slua predavaa iz odreenog predmeta. Ponekad je dovono da modelujete samo ienicu da veza ili odnos postoji. U drugim sluajevima moe biti potrebno da o toj vezi evidentirate i dodatne podatke, kao to je datum uspostavanja veze, ili neku odliku te veze (ili odnosa). Na primer, odnos izmeu pume i kojota je konkurentski, dok je odnos izmeu pume i zeca takav da puma lovi zeca, to je korisno znati ako planirate da izgradite zooloki vrt bez kaveza. Postoje razliita miea o tome da li bi veze izmeu entiteta koje nemaju sopstvene atribute trebalo da se modeluju kao zasebni entiteti. Mislim da se time nita ne dobija, a komplikuje se postupak izvoea eme iz

Model podataka

15

modela podataka. Meutim, shvatae da su veze/odnosi izmeu entiteta podjednako vani kao i sami entiteti, kuno je za projektovae kvalitetnog modela podataka.

Atributi
Sistem koji projektujete morae da evidentira odreene ienice o svakom entitetu. Kao to smo ve videli, te ienice su atributi entiteta. Na primer, ako u svom sistemu imate entitet Kupac, verovatno e vam biti vano da znate imena i adrese kupaca, a moda i njihova zanimaa. Ako modelujete dogaaj kao to je ZahtevZaServisirae, verovatno ete hteti da znate koji je klijent u pitau, ko je zvao, kad je zvao i da li je problem reen. Svi navedeni elementi su atributi. Odreivae atributa koje ete ugraditi u svoj model jeste semantiki postupak, to znai da odluke morate donositi na osnovu znaea podataka i naina na koji e se oni koristiti. Pogledajmo est primer: adresu. Da li ete adresu modelovati kao jedan entitet (Adresa) ili kao grupu vie entiteta (Ulica, Broj, Grad, PotanskiBroj, Drava)? Veina projektanata (meu koje ubrajam i sebe) obino automatski razbija adresu na grupu atributa zbog opteg principa da se lake radi sa strukturiranim podacima, ali to nije uvek tano, a svakako nije oigledno. Kao primer, uzmimo lokalno udruee muziara amatera. Potrebno im je da evidentiraju adrese svojih lanova kako bi mogli da tampaju nalepnice za koverte. Poto je to jedina svrha za koje e se adrese koristiti, nema razloga da se adresa ikada tretira drugaije nego kao jedan blok od vie redova teksta, koji se tampa na zahtev. Ali ta je sa kompanijom koja se bavi prodajom robe u SAD putem Interneta? Zbog obrauna poreza, kompaniji je potrebno da zna u kojoj saveznoj dravi ivi svaki en kupac. Iako se podatak o saveznoj dravi moe izdvojiti iz tekstualnog poa koje odgovara udrueu muziara, to nije lako; prema tome, logino je da u ovom sluaju treba modelovati barem saveznu dravu kao zaseban atribut. ta je sa ostalim delom adrese? Da li bi trebalo da ga razbijemo na vie atributa i koji bi to atributi bili? Moda biste pomislili da bi odgovarao skup atributa {Kuni broj, Ulica, Grad, Savezna drava, Potanski broj}? Meutim, moe zatrebati i broj stana, broj potanskog pretinca i APO adresa. ta ete uraditi ako je u pitau usluna adresa koja pripada nekom drugom? Poto svet postaje sve mai, ali ne mae sloen, ta e se desiti kada dobijete prvog klijenta u inostranstvu? Domae adrese imaju prilino standardizovan format, ali to ne vai za porudbine iz inostranstva.

16

Poglavlje 1

Osnovni pojmovi

Ne samo to morate da znate cinu dravu i da tome prilagodite format potanskog broja, nego ete moda morati da meate i redosled atributa. Na primer, za razliku od SAD, u veem delu Evrope kuni broj se pie iza imena ulice. To nije tako loe, lako ete se setiti toga kada budete unosili podatke, ali koliko e vaih operatera znati da adresa 4/32 Griffen Avenue, Bondi Beach, Australija, znai stan broj 4, u zgradi na broju 32? Sutina u ovom sluaju nije to da je teko modelovati adresu (mada jeste), nego da ne moete unapred odreivati kako ete modelovati odreenu vrstu podataka. Sloen sistem koji razvijete za obradu meunarodnih porudbina, bie potpuno neprikladan za udruee muziara. Slikaru Matisu pripisuje se tvrda da je slika gotova tek kad joj se vie nita ne moe ni dodati ni oduzeti. Projektovae entiteta pomalo je slino tome. Kako znate da ste stigli u tu fazu? Naalost, odgovor glasi da u to nikad ne moete biti potpuno sigurni (a ak i ako mislite da jeste, s vremenom ete promeniti miee). Pri tekuem stau tehnologije, ne postoji nain da projektujete strukturu baze podataka za koju se moe dokazati da je potpuno ispravna. Moete dokazati da u odreenoj strukturi ima propusta i greaka, ali ne moete dokazati da ih u drugoj strukturi nema. To znai, otprilike, da ne moete dokazati svoju nevinost. Kako se moe reiti taj problem? Nema strogih pravila, ali postoji nekoliko strategija. Prva strategija: Krenite od rezultata i nemojte praviti sloeniju strukturu nego to je zaista potrebno. Na koja pitaa vaa baza podataka mora davati odgovore? Poto je u naem prvom primeru, udrueu muziara, jedino pitae bilo: Na koju adresu treba poslati pismo za tu i tu osobu?, model s jednim atributom za adresu bio je dovoan. U drugom primeru, kompaniji koja prodaje robu putem Interneta, bio je potreban i odgovor na pitae: U kojoj saveznoj dravi ivi ta i ta osoba?, pa nam je zato bila neophodna drugaija struktura adrese da bismo doli do zahtevanog rezultata. Razume se, morate voditi rauna i pokuati da obezbedite fleksibilnost koja e pruiti odgovore, i to ne samo na pitaa koja korisnici postavaju sada, ve i na ona koja moete predvideti da e se pojaviti u budunosti. Na primer, kladila bih se da e u roku od godinu dana nakon putaa sistema u redovnu upotrebu, udruee muziara zatraiti od vas da im sortirate adrese po potanskom broju da bi dobili koliinski popust. Trebalo bi takoe da oekujete i pitaa koja bi korisnici postavili kada bi znali da mogu da ih postave, naroito kada automatizujete postojei runi sistem. Zamislite da rukovodilac biblioteke eli da zna koliko je iz fonda od etiri miliona kiga bilo objaveno u Novom Sadu pre 1900. godine. On ili ona bi vam pokazali orman s kartotekom i poeleli vam dobru zabavu. Meutim, u dobro projektovanom sistemu koji radi s bazom podataka, ta vrsta zahteva smatra se trivijalnim.

Model podataka

17

Jedan od zatitnih znakova dobrih projektanata jeste temeitost i kreativnost s kojima podstiu potencijalna pitaa. Neiskusni analitiari esto tvrde da korisnici ne znaju ta tano hoe. Naravno da ne znaju; va posao je da im pomognete da otkriju ta zapravo ele. Meutim, pri tome morate biti oprezni. Cena fleksibilnosti esto je vei stepen sloenosti. Kao to smo videli na primeru adrese, to vie seckate i usitavate podatke, vie ete imati posebnih sluajeva za obradu, a to e vas dovesti do take kada predloeno reee poie da gubi smisao. Tako stiemo do strategije broj dva: Otkrijte izuzetke. Ova strategija ima dva aspekta. Prvo, morate identifikovati sve izuzetke, i drugo, sistem morate projektovati tako da obrauje to vei broj izuzetaka, ali da pri tome ne zbuuje korisnike. Kao ilustraciju ta tano znai ovaj princip, razmotriemo jo jedan primer: imena osoba. Ako e namena sistema koji projektujete biti korespondencija, od kune je vanosti da imena osoba budu tano navedena. (Prikladan primer: svu potu koju dobijam na kunu adresu, a primalac je gospodin R. M. Riordan, uopte i ne otvaram.) Veina imena osoba prilino je jasna sama po sebi. Ako je primalac gospoa Jelena K. Jovanovi, elementi imena su: Oslovavae, Ime, OevoIme i Prezime, zar ne? Pogreno. (Osetili ste da ima neka zakoica, a?) Sigurnije je (i pravilnije po bontonu) koristiti UobiajenoIme 2 i Prezime. Dae, ta ete uraditi kad je primalac Sir James Peddington Smythe, Lord Dunstable? Peddington Smythe je u tom sluaju Prezime, ili je to OevoIme? ta je onda Lord Dunstable? A peva Sting? Da li je to UobiajenoIme ili Prezime? A ta e se desiti Umetniku Ranije Poznatom Pod Imenom Prince? Da li vas to zaista zanima? Poslede pitae nije tako besmisleno kao to se ini. Pismo iji je primalac naveden kao Sir James Peddington Smythe, verovatno nee nikoga uvrediti. Ali ime pomenutog gospodina s plemikom titulom nije Sir Smythe; u javnosti ga oslovavaju sa Sir James ili moda Lord Dunstable. Meutim, budimo realni, koliko vaih klijenata ima titulu lorda? Lokalno udruee muziara sigurno vam nee zahvaivati ako im napravite ekran nalik na onaj sa slike 14. Imajte u vidu da morate napraviti kompromis izmeu fleksibilnosti i sloenosti. Mada je vano da obuhvatite to vei broj izuzetaka, potpuno je razumno da neke od ih zanemarite jer su suvie malo verovatno da bi opravdali cenu svog ukuivaa u sistem.

2. U nekim kulturama je uobiajeno da udi dobijaju dva, tri ili vie imena pri roeu. U krtenici se navode sva imena, ali se u praksi koristi samo jedno, koje se zove uobiajeno ime (engl. given name). (Prim. prev.)

18

Poglavlje 1

Osnovni pojmovi

Slika 14 Previe sloen ekran za unoee adresa

Razlikovae entiteta od atributa ponekad moe biti teko. Rei e vam opet da je adresa dobar primer kao i da vaa odluka zavisi od prostora problema. Neki projektanti predlau upotrebu samo jednog entiteta za adresu koji bi predstavao sve vrste adresa koje se uvaju u sistemu. Sa take gledita praktine realizacije, to reee prua nesporne prednosti u pogledu kapsuliraa i viekratne upotrebe koda. Meutim, sa take gledita strukture baze podataka, imam odreene rezerve. Na primer, malo je verovatno da e se adrese zaposlenih i kupaca koristiti na isti nain i za iste namene. Verovatnije je da e se cirkularne poruke zaposlenima slati putem interne e-pote nego putem klasine pote. Ako je tako, za drugi sluaj pravila i zahtevi su drugaiji. Grozan ekran za unoee podataka prikazan na slici 14, ili neto slino tome, moe biti sasvim prikladan za adrese kupaca. Meutim, ako imate samo jedan entitet za adrese, morate koristiti isti ekran i za adrese zaposlenih; malo je verovatno da je to potrebno, a jo mae da e se svideti korisnicima.

Domeni
Moda se seate s poetka ovog poglava da se u zaglavu relacija nalaze parovi ImeAtributa:ImeDomena za svaki atribut. Reeno je da definicija domena odreuje vrstu podataka koje predstava atribut. Tanije reeno, domen (engl. domain) je skup svih prihvativih vrednosti koje atribut moe imati.

Model podataka

19

Domeni se esto brkaju s tipovima podataka; to su dva razliita pojma. Tip podataka je fiziki pojam, dok je domen logiki pojam. Broj je tip podataka; Starost je domen. I Ulica i Prezime mogu biti predstaveni poima tekstualnog tipa, ali je oigledno da su u pitau razliite vrste tekstualnih poa, koja pripadaju razliitim domenima. Domen je ui pojam od tipa podataka jer definicija domena zahteva precizniji opis validnih podataka. Uzmite kao primer domen StrunaSprema, koji predstava strunu spremu osobe. U emi baze podataka, taj atribut se moe definisati kao Text, ali to ne moe biti bilo koji tekst, ve samo element iz skupa {nia, sreda, via, visoka, magistratura, doktorat}. Razume se, ne moete sve domene definisati pojedinanim navoeem prihvativih vrednosti. Starost, na primer, sadri otprilike stotinak vrednosti ako je u pitau starost osoba, ali to mogu biti desetine hiada razliitih vrednosti kada su u pitau muzejski eksponati. U takvim sluajevima, umesto u obliku liste vrednosti, lake je definisati domen u obliku pravila koja utvruju da li odreena vrednost pripada skupu prihvativih vrednosti. Na primer, StarostOsobe moe se definisati kao celobrojna vrednost u opsegu od 0 do 120, dok bi StarostEksponata bila celobrojna vrednost vea od 0. Moda ste sad pomislili da je domen kombinacija tipa podataka i pravila za ispravnost podataka. Ako tako mislite, neete daleko stii. Pravila ispravnosti podataka iskuivo su deo integriteta podataka, a ne opisa podataka. Na primer, pravilo ispravnosti za potanske brojeve odreuje da su prihvaivi samo odreeni brojevi, dok je domen za potanske brojeve petocifreni broj. Obratite pau na to da se u navedenim definicijama pomie vrsta podataka koji se evidentiraju (znakovni ili numeriki). To puno podsea na tip podataka, ali ipak nije tako. Tipovi podataka su, kao to je ve napomenuto, fiziki pojam; oni se definiu i zadaju u obliku koji prepoznaje maina baze podataka. Bilo bi pogreno definisati domen kao varchar(30) ili Long Integer jer su to opisi specifini za odreenu mainu baze podataka (SQL Server). Za svaka dva data domena, ako je mogue porediti atribute definisane u tim domenima (pa prema tome, obavati i relacione operacije kao to je spajae, to emo razmotriti u poglavu 5), kae se da su oni kompatibilni po tipu (engl. type compatible). Na primer, dve relacije prikazane na slici 15 mogu se povezati putem atributa EmployeeID = SalespersonID (ifra zaposlenog = ifra prodavca). To moete uraditi npr. da biste dobili spisak faktura koje je svaki zaposleni izdao. Domeni EmployeeID i SalespersonID kompatibilni su po tipu. Meutim, ako pokuate da kombinujete te dve relacije putem atributa EmployeeID = OrderID (ifra zaposlenog = broj porudbine), verovatno neete dobiti smislen rezultat, uprkos tome to su oba domena definisana sa istim tipom podataka.

20

Poglavlje 1

Osnovni pojmovi

Slika 15 Relacije Employees (zaposleni) i Orders (porudbine)

Naalost, ni maina baze podataka Jet, niti SQL Server ne pruaju ugraenu podrku za domene koja bi bila jaa od obine provere tipova podataka. ak i za tipove podataka, nijedna maina baze podataka ne obava striktnu proveru tipa: obe e mirno konvertovati podatke u pozadini. Na primer, ako koristite Microsoftov Access i u tabeli Employees definisali ste da je EmployeeID tipa Long Integer, a u tabeli Invoices (fakture) atribut InvoiceTotal (ukupan zbir) definisan je kao tip Currency, moete napraviti upit koji povezuje te dve tabele kao EmployeeID = InvoiceTotal. Microsoftov Jet e vam ubazno sastaviti spisak zaposlenih ije su ifre (EmployeeID) jednake ukupnim zbirovima odreenih faktura. Ta dva atributa nisu kompatibilna po tipu, ali to Jet ne zna ili zanemaruje. Zato biste se onda uopte petali s domenima? Zato to su oni, kao to emo videti u treem delu kige, izuzetno korisne alatke pri projektovau baza podataka. Da li su ta dva atributa meusobno zameivi? Postoje li pravila koja vae u jednom, a ne vae u drugom domenu? To su vana pitaa kada projektujete model podataka, a analiza domena vam pomae da naete odgovore.

Veze/odnosi izmeu entiteta

Osim atributa svakog entiteta, model podataka mora da definie i veze ili odnose koji postoje izmeu entiteta. Na pojmovnom nivou, veza ili odnos (engl. relationship) jeste asocijacija izmeu entiteta. Reenica kupci kupuju robu pokazuje da postoji veza izmeu entiteta Kupci i Roba. Entiteti izmeu kojih postoji veza ili odnos zovu se uesnici veze (engl. praticipants).

Model podataka

21

Broj uesnika odreuje stepen veze. (Stepen veze je slian, ali ne i jednak, stepenu relacije, to je ukupan broj atributa.) Velika veina veza izmeu entiteta je binarna, kao u primeru kupci kupuju robu, ali to nije pravilo. Uobiajene su i ternarne veze, tj. one s tri uesnika. Binarne veze zaposleni prodaju robu i kupci kupuju robu implicitno podrazumevaju postojae ternarne veze zaposleni prodaju robu kupcima. Meutim, navedene dve binarne veze ne omoguavaju nam da saznamo koji su zaposleni koju robu prodali kojim kupcima; to se moe saznati samo pomou ternarne veze. Specijalan sluaj binarne veze je entitet koju uestvuje u vezi sa samim sobom. To se esto zove veza tipa sastavnice (engl. bill of materials relationship) i najee se koristi za predstavae hijerarhijskih struktura. Uobiajen primer je odnos izmeu zaposlenih i nadreenih rukovodilaca. Svaki zaposleni moe istovremeno i biti rukovodilac i imati sebi nadreenog rukovodioca. Veza ili odnos izmeu dva entiteta moe biti tipa jedan prema jedan, jedan prema vie ili vie prema vie. Veze tipa jedan prema jedan su retke, ali mogu biti korisne u nekim okolnostima. Veze tipa jedan prema vie verovatno su najuobiajenija vrsta. Jedna faktura se sastoji od vie artikala. Jedan prodavac izdaje vie faktura. U oba primera imamo vezu tipa jedan prema vie. Iako nisu toliko este kao veze tipa jedan prema vie, veze tipa vie prema vie nisu neuobiajene i mogu se nai brojni primeri. Jedan kupac kupuje vie artikala, a isti artikal moe kupiti vie kupaca. Vie studenata slua predavaa jednog profesora, a isti student moe sluati predavaa vie profesora. Veze tipa vie prema vie ne mogu se direktno predstaviti u relacionom modelu, ali je ihov indirektan oblik vrlo jednostavan, kao to emo videti u poglavu 3. Uestvovae jednog entiteta u vezi moe biti delimino ili potpuno. Ako entitet ne moe da postoji ukoliko ne uestvuje u nekoj vezi, uestvovae je potpuno; u suprotnom, uestvovae je delimino. Na primer, podaci o odreenom Prodavcu ne mogu logiki da postoje ako ne postoji odgovarajui Zaposleni. Obrnuto nije tano. Poto zaposleni moe biti i neto drugo osim prodavca, moe postojati zapis o Zaposlenom bez odgovarajueg zapisa meu Prodavcima. Prema tome, uestvovae Zaposlenog u vezi je delimino, dok je uestvovae Prodavca potpuno. Trik je u tome da tvrda o deliminom ili potpunom uestvovau bude tana za sve instance (primerke) entiteta, u svim sluajevima. Na primer, nije neuobiajeno da kompanija promeni dobavaa za odreeni artikal. Ako je uestvovae entiteta Artikal u vezi dobavai dobavaju artikle definisano kao potpuno, tekueg dobavaa neete moi da izbriete ako ne izbriete i sve podatke o artiklima koje vam on dobava.

22

Poglavlje 1

Osnovni pojmovi

Dijagrami entiteta i veza

Model entiteta i veza, koji podatke opisuje izraene kao entitete, atribute i veze, uveo je Peter Pin Shan Chen 1976. godine.3 Istovremeno, predloio je metodu predstavaa pomou dijagrama nazvanih Entity Relationship (E/ R) dijagrami, koja je postala iroko prihvaena. E/R dijagrami se sastoje od pravougaonika, koji predstavaju entitete, elipsi, koje predstavaju atribute i rombova, koji predstavaju veze izmeu entiteta (slika 16).

Kupac BrojPorudbine

ifraProdavca DatumPorudbine

ifraZaposlenog

MestoNaKomeIgra

Porudbina

FudbalskiTim

Zaposleni evidentiraju porudbine

Zaposleni

Zaposleni igraju fudbal

ifraZaposlenog Funkcija

Prezime Ime

nula ili jedan nula ili vie

jedan vie

Slika 16 Primer E/R dijagrama

3. Peter Pin Shan Chen, The Entity Relationship Model Toward a Unified View of Data?, ACM TODS 1, broj 1 (mart 1976).

Saetak

23

Priroda veza izmeu entiteta (jedan prema jedan, jedan prema vie ili vie prema vie) predstava se na vie naina. Mnogi koriste simbole 1 i M ili 1 i (simbol za beskonanost). Ja koristim oblik vranina kanda, prikazan na slici 16, koji smatram izraajnijim. Velika prednost E/R dijagrama jeste to to se lako crtaju i razumeju. Ja obino crtam atribute na odvojenom dijagramu jer se mogu praviti dijagrami sa razliitim nivoima detaa. Uglavnom, na dijagramu razmatramo ili entitete koji ine model i veze izmeu ih, ili atribute datog entiteta, ali retko razmatramo oba aspekta istovremeno.

Saetak
U ovom poglavu razmotrili smo komponente sistema koji radi s bazom podataka i postavili osnovu za preostali deo gradiva u kizi. Poeli smo od opisa prostora problema kao odreenog, precizno definisanog dela stvarnog sveta. Konceptualni model podataka je opis prostora problema izraen pomou entiteta, atributa i domena u kojima su definisani. Fizika struktura modela podataka je ema baze podataka, koja se realizuje u bazi podataka. I najzad, maina baze podataka fiziki manipulie podacima na zahtev aplikacije sainjene od obrazaca i izvetaja s kojima korisnici rade. U narednom poglavu, detanije emo prouiti strukturu baze podataka dok budemo razmatrali principe normalizacije.