: : PROIZVODJAC (P#, NAZIV, GRAD) ARTIKL (A#, IME CENA) PONUDA (P#, A#, KOLICINA) 1 2 3

, ! 1: PROIZVODJAC P# 1 2 3 4 2: ARTIKL A# 1 2 3 4 5 3: PONUDA P# 1 2 3 4 5 A# 1 2 3 1 5 KOLICINA 200 1500 200 500 500 IME Sir Mleko Vino Hleb Kafa CENA 500 20 100 20 300 NAZIV Maxi Diskont C Market Srbijanka Drina - Jadar GRAD Beograd Beograd Valjevo Loznica

: 1. . . 2. . .

SQL : SELECT FROM WHEREATRIKL.IME, PROIZVODJAC.NAZIV, PONUDA.KOLICINA ARTIKL, PROIZVODJAC, PONUDA PROIZVODJAC.GRAD='Beograd' AND PROIZVODJAC.P#=PONUDA.P# AND ARTIKL.A#=PONUDA.A#

1. : 1 , 'NAZIV' 'P#'. , PROIZVODJAC. PR.

PR (P#, NAZIV) SELECT FROM WHEREP#, NAZIV PROIZVODJAC GRAD='Beograd'

1. : PR P# 1 2 NAZIV Maxi Diskont C Market

, . 2 IME A#. ARTIKL. AR.

AR (A#, IME) SELECT FROMA#, IME ARTIKL

2 : AR A# 1 2 3 4 5 IME Sir Mleko Vino Hleb Kafa

3: , PONUDA PO. PO P# 1 2 3 4 4 2. : 2: , 2 . SELECT FROM WHERE ANDPR.NAZIV, AR.IME, PO.KOLICINA PR, AR, PO PR.P#=PO.P# AR.A#=PO.A#

A# 1 2 3 1 5

KOLICINA 200 1500 200 500 500

: NAZIV Maxi Diskont C Market IME sir mleko KOLICINA 200 1500

ERwin modelovanje podataka

Sadraj1. 2. 3. Sadraj ............................................................................................................................................ 1 Uvod ............................................................................................................................................... 2 Modelovanje podataka ................................................................................................................... 3 3.1. Model objekti veze ............................................................................................................... 4 Identifikujue veze ......................................................................................................................... 5 Neidentifikujua veza .................................................................................................................... 6 Veza kategorije .............................................................................................................................. 6 Neodreena veza tipa vie prema vie ........................................................................................... 7 3.2. Atributi ER modela ................................................................................................................. 8 4. ERwin Data Modeler ..................................................................................................................... 9 4.1. Kreiranje novog modela .......................................................................................................... 9 5. BPWin .......................................................................................................................................... 14 6. Realizacija projekta DVD klub uz pomo ERwin-a i BPwin-a ....................................................... 18 7.Literatura: ......................................................................................................................................... 38

1. Uvod

Baze podataka danas predstavljaju veliku ulogu u informacionim tehnologijama. Skoro nikakav sistem, bilo da je poslovni, industrijski, proizvodni ne moe se danas zamisliti bez aplikacija koje pomau ili u voenju poslovanja ili u procesu odluivanja. Podloga svakog od tih sistema je baza podataka. to je kvalitetnije projektovana baza podataka, kvalitetnija je i aplikacija, a sve to dovodi do poboljanja poslovanja i ostvarivanja boljih rezultata.

Da bi se baza podataka izgradila, potrebno je izgraditi kvalitetan model, a to se postie softverskim alatima za modelovanje podataka, kreiranje dijagrama, izgradnje logikog i fizikog modela. Ovi alati eliminiu dvosmislenost, najvei problem kod opisivanja rada sistema prirodnim jezikom. Pomau nam da model podataka bude pregledan, sistematian, razumljiv kako onima koji na osnovu njega kreiraju bazu podataka, tako i drugima koji ele da shvate kako sistem radi i kako se njim upravlja. Proces modelovanja podataka eliminie detalje i veliku kompleksnost, sve prikazuje slikovito (pravougaonici, strelice) i uz pomo tekstualnih opisa model podatka dovodi na veoma razumljiv i pristupaan nivo.

2

2. Modelovanje podataka

Modelovanje podataka predstavlja prvi korak u procesu razvoja baze podataka. Uz pomo modelovanja podataka, vrimo predstavljanje realnog sistema uz pomo skupa objekata, entiteta i veza izmeu skupa objekata i atributa. Modelovanje podataka vrimo uz pomo tzv. CASE (engl. Computer Aided Software Engineering) alata. CASE alati predstavljaju softversku podrku uz pomo koje definiemo model podataka preuzetih iz realnog sistema. Model podataka nam omoguuje pregled meusobnih odnosa izmeu podataka u realnom sistemu, a koje emo koristiti prilikom kreiranja baze podataka. Da bi model podataka bio potpuno odreen, moraju biti definisane sljedee komponente: 1. Struktura podataka definie statike karakteristike sistema, najvie se odnosi na kreirenje modela entiteri relacije. 2. Ogranienja logika ogranienja na podatke, pravvila integriteta. 3. Operacije koje se sve operacije mogu izvoditi nad podacima Svaki model podataka mora da zadovolji dva bitna kriterija: 1. Da omogui modelovanje realnih sistema, na taj nain da posjeduje koncepte koji to omoguavaju. 2. Da se koncepti i struktura alata za modelovanje mogu jednostavno predstaviti i implementirati u raunaru. Kada se ispune prethodno navedena dva kriterija modeli podataka se mogu klasifikovati u tri generacije, a to su : prva generacija (konvencionalni programski jezici), druga generacija (baze podataka) i trea generacija koju predstavljaju semantiki bogati modeli podataka, tzv. model objekti- veze. Na osnovu ovoga, pravi metodoloki pristup modelovanju neke baze podataka bi bio takav da se prvo iskoristi neki model iz tree generacije modelovanja i na osnovu njega dobije semantiki bogat model realnog sistema i nakon toga da se pristupi izgradnji konkretnog rjeenja ili baze podataka koristei prvu ili drugu generaciju modela podataka. Modelovanje podataka predstavlja grafiki jezik uz pomo kojeg se predstavlja struktura podataka. Kada vrimo modelovanje podataka koristimo CASE alate, iji je izbor vie stvar formalnosti, meutim da mi se realni sistem to bolje predstavio kroz model podataka potrebno je znanje i iskustvo analitiara. Modelovanje podataka se najee vri u dva koraka, modelovanje pogleda i modelovanje zahtjeva. Modelovanje pogleda predstavlja definisanje dijagrama toka podataka, a do podataka koji su potrebni za dijagrame tokova najee dolazimo preko raznih vrsta razgovora i intervijua. Kada je modelovanje pogleda zavreno, pristupa se modeliranju zahtjeva. Modelovanjem zahtjeva precizno se definiu atributi na osnovu podataka koje smo dobili modeliranjem pogleda i ostalom dokumentacijom. Dakle, modelovanjem zahtjeva dobijamo odreenu irinu, a modelovanjem pogleda preciznost.

3

3.1.

Model objekti veze

Model objekti veze (engl. Entity relationship, ER) predstavlja se ER dijagramima. U ovom modelu, sistem se predstavlja kao skup objekata i njihovih veza. Objekat je neki element koji se razlikuje od ostalih objekata po svojim osobinama. U modelu, objekat moe da predstavlja fiziki objekat nekog realnog sistema (na primjer student), vremenski period ( semestar) i tako dalje. Svaki objekat moe da pripada nekom tipu objekata, dok je tip objekta opti predstavnik neke klase objekata. Kada predstavljamo neki konkretan objekat uz pomo njegovog tipa, to nazivamo generalizacijom, a obrnuti postupak, ako navodimo pojavljivanje, koritenje nekog tipa se naziva specijalizacija Da bi neki objekat opisali u sistemu, koristimo njegova svojstva ili atribute.Slika 1: Svojstva ili atributi objekta

Svaki atribut u jednom trenutku ima neku vrijednost, koju uzima iz skupa moguih vrijednosti. Skup moguih vrijednosti naziva se domen. Objekti mogu biti jaki i slabi. Slab objekat je zavisan od svog nadreenog (jakog) objekta i da bi bio identifikovan, prepoznat, mora biti u vezi sa svojim nadreenim, jakim objektom. Za meusobno povezivanje objekata koriste se veze, koje opisuju nain uzajamnog djelovanja izmeu objekata. Objekat od kojeg je uspostavljena veza se zove roditelj ( engl. parent) a objekat prema kojem ide veza od strane roditelja se naziva dijete (engl. child). Veze predstavljaju znanje o meusobnoj povezanosti objekata. Veze definiu zavisnost izmeu entiteta i opisuje nain povezivanja entiteta. Kada posmatramo realni svijet, vidimo da se on sastoji od objekata posmatranja, koji mogu biti ili realni( student, profesor, automobil), apstraktni ( fakultet, radno mjesto), dogaaji ( prevoz, prekraj) ili odnosi ( profesor student, direktor zaposlenik). Entitet moemo zamisliti kao skup individualnih objekata koji se nazivaju primjerci ( instance). Jedan primjerak je jedan pojavni oblik entiteta i svaki primjerak se mora razlikovati od ostalih primjeraka preko barem jednog identiteta. Dva su osnovna tipa entiteta, nezavisni i zavisni. Nezavisni entitet je objekat koji ima jednu osobinu koja ga moe jednoznano identifikovati. Grafiki ih prikazujemo pravougaonikom u okviru kojeg se upisuje naziv tipa entiteta. STUDENT Zavisni entiteti su oni koji zavise od drugih entiteta. Dijele se u etiri grupe: 1. Karakteristini ponavljaju se vie puta za odreeni, nezavisni entitet

Entitet ISPLATA je karakteristian entitet od entiteta OSOBA.

4

2. Asocijativni predstavlja vezu vie entiteta. Na primjer, ako je neki STUDENT zavrio FAKULTET i jedan FAKULTET je zavrilo vie STUDENATA, tada je asocijativni entitet DIPLOMA, koja opisuje vezu izmeu fakulteta i studenata.

3. Projektni slian je asocijativnom ali nema sopstvene atribute 4. Klasni predstavljaju podkategoriju entiteta Zavisni entiteti se grafiki predstavljaju kao zaobljeni pravougaonici u ijem okviru se upisuje naziv tipa entiteta u jednini. Da bi definisali vezu meu entitetima moramo zadovoljiti neke osnovne kriterije: 1. Interakcija izmeu entiteta ( STUDENT ------STUDIRA ------ NEKI FAKULTET) 2. Aktivnosti, procesi, zadaci ( AKTIVNOST NA PREDAVANJIMA, KORITENJE MENZE) 3. Opisne veze, neki tip entiteta opisuje drugi tip entiteta ( STUDENT----INDEKS--POLOENI ISPIT) 4. Veze pripadnosti za podtip i nadtip, odnosno da li se dva objekta mogu vezati iskazom JE ( STUDENT JE REDOVAN, VANREDAN, NA DALJINU) U literaturi se navodi da je bitno osigurati da kada itamo modele moemo formulisati valjane reenice, iskaze. Postoji nekoliko tipova veza: 1. 2. 3. 4. Identifikujue Neidentifikujue Veze prema podtipovima, odnosno veze kategorije Neodreene veze, veze vie prema vie

Identifikujue vezeObjekat dijete zavisi od objekta roditelj, odnosno kljuevi objekta roditelj predstavljaju dio identiteta objekta dijete i svaki objekat dijete mora biti povezan sa barem jednim objektom roditelj. Dakle, objekti roditelja se definiu nezavisno, dok objekti djece zavise od objekta roditelj. Vezu izmeu objekta roditelj i dijete moemo predstaviti na sljedei nain:Slika 2: Identifikujua veza

5

Neidentifikujua vezaNeidentifikujua veza je tip veze gdje se svaki objekat dijete moe jedinstveno identifikovati, nije uslovljen objektom roditelj. Ovaj tip veze je prikazan isprekidanom crtom koja povezuje roditelj i dijete, sa takom na kraju. Neidentifikujua veza se jo naziva i slaba veza, identifikacija dijeteta nee zavisiti od roditelja. Na slici 3 vidimo i romb (diamond) . Konkretno u programu ERwin, romb slui da naznai sluaj egzistencijalne zavisnosti. Egizistencijalna zavisnost nastaje kada je relaciona veza obavezna iz perspektive roditelja i tada je dijete egzistencijalno zavisno od roditelja.Slika 3: Neidentifikujua veza

Veza kategorijeVeza kategorije predstavlja onaj tip veze koji predstavlja hijerarhijsku vezu izmeu nadreenog, generalizovanog objekta koji sadri i zajednike osobine podreenih, specijalizovanih objekata.

Slika 4: Primjer veze kategorije

6

Neodreena veza tipa vie prema vieKod ovoga tipa veze primjerak jednog objekta moe da bude povezan sa nijednim, jednim ili vie primjeraka drugog objekta, i obratno, primjerak drugog objekta moe da bude povezan sa nijednim, jednim ili vie primjeraka drugog objekta.

Slika 5: Veza vie prema vie

Model objekti veze je definisan entitetnim dijagramom uz pomo kojeg se definiu tipovi entiteta i uspostavljaju veze. Entiteti mogu biti zavisni ( postojanje je zavisno od drugog entiteta) i nezavisni ( imaju vlastitu identifikaciju, ne zavise od drugog entiteta). Atributi se mogu nalaziti u oblasti kljueva ( primarni klju, sekundarni klju). Dakle entitetni dijagram se definie entitetima. Svaki entitet ima svoje osobine( atribute) i sve je povezano relacionim vezama ( engl. relationships). Svaki atribut ima svoj domen (engl. domain) koji predstavlja skup vrijednosti koje atribut moe da ima. Takoe postoje primjerci (engl. instance) koji predstavljaju pojedinane vrijednosti entiteta. Da bi prepoznali, identifikovali neki entitet on mora imati svoj primarni klju. Kada povezujemo dva entiteta, stvaramo relacionu vezu. Sekundarni klju definie relacionu vezu od roditelja prema djetetu. Jednostavan konkretan primjer za razumijevanje ER dijagrama je reenica, gdje su entiteti imenice, atributi pridjevi a veze glagoli. Entitet moemo definisati kao bilo ta to moemo ili elimo pojedinano posmatrati ( osoba, stvar, dogaaj). Atributi slue za opis objekata u sistemu. Svaki atribut mora u jednom trenutku da ima neku vrijednost. Prilikom modelovanja podataka moramo da definiemo entitete. Pojavljuju se razni kandidati za entitete ali postoje pravila koja omoguuju definiciju entiteta u sistemu. Najvanija pravila su: 1. Slinost atributa utvrujemo slinosti ili razlike meu objektima preko njihovih atributa 2. Nain identifikacije za svaki objekat mora da postoji atribut ili grupa atributa koji je jedinstven za odreeni entitet. 3. Uee u tipu veze pomae nam da utvrdimo da li je entitet zavisan ili nezavisan. 4. Fiziki objekti su najbolji za entitete u modelu. Na primjer vozilo, osobe, adrese, mjesta, tipovi proizvoda, studenti, paviljoni itd.

7

3.2.

Atributi ER modela

U realnom svijetu objekti imaju svoje osobine. Takav pristup se morao iskoristiti i u modelovanju podataka. Tako je svaki entitet opisan svojim atributima. Prilikom odabira atributa mora se definisati lista kandidata za atribute. Prilikom definisanja atributa potrebno je znati da svaki entitet moe imati proizvoljan broj atributa, odreeni atribut pripada samo jednom entitetu, svako pojavljivanje entiteta ima vrijednosti za sve atribute tog entiteta, svaki atribut predstavlja jednu odreenu injenicu. Kako je prethodno naglaeno, svaki entitet ima svoje atribute koji ga opisuju. Atributi imaju skupove vrijednosti ili intervale vrijednosti koje nazivamo modeli. Svaki entitet mora imati odreeni atribut koji ga jedinstveno identifikuje. To je tzv. primarni klju. Primarni klju moe biti prost i sloen. Ako ga ini samo jedan atribut, to je onda prosti klju, a u suprotnom je sloen. Na sljedeoj slici vidimo entitet OSOBA. Predstavljen je crtanjem pravougaonika sa imenom entiteta na vrhu i svim atributima unutar pravougaonika.Slika 6: Entitet sa svojim atributima

Vidimo da je unutar pravougaonika oblast kljueva od ostalih atributa vidljivo odvojena. U ovom sluaju imamo prosti klju. Ovaj atribut jo nazivamo i identifikator. Moemo definisati dvije vrste identifikatora, primarni klju i alternativni klju. Niti jedan kandidat za primarni klju ne smije imati omoguenu vrijednost NULL, odnosno da je omogueno da se vrijednost atributa ostane prazna. U ovom sluaju prvi kandidat za primarni klju je ifra osobe. Ostali kandidati mogu biti i matini broj, ali postoji mogunost da neke osobe nemaju matinog broja. Kao to je navedeno, primarni klju moe biti i sloen, to znai da se sastoji od skupa atributa. Kandidat za primarni klju bi mogla biti i kombinacija ime i prezime te datum roenja. Ime i prezime je lo kandidat za primarni klju zbog toga to je velika vjerovatnoa da se pojave dvije osobe sa istim imenom i prezimenom. Kada biramo primarni klju poeljno je nai neki atribut koji nikako ne bi trebao mijenjati svoju vrijednost. Nazivi kljueva ne bi smjeli da budu dugaki i sa mnogo karaktera. Svaki klju koji nije izabran za primarni klju, a bio je kandidat naziva se alternativni klju. Da bi nekom entitetu dodijelili atribute, prvo ih moramo definisati. Postoje tri osnovna koraka koji se koriste za definiciju atributa: 1. Identifikacija atributa se vri na osnovu zahtjeva korisnika, poslovne dokumentacije i dr. 2. Provjera atributa vri se eliminacija viestrukog ponavljanja atributa . 3. Definisanje atributa (domen, nula vrijednosti)

8

4. ERwin Data ModelerERwin Data Modeler je alat za modelovanje podataka na osnovu kojih se projektuju baze podataka. Omoguava pravljenje logikih i fizikih modela ali i sloenijih logiko fizikih modela. Osnovne karakteristike ovoga alata su: 1. Na osnovu modela brzo i lako se prave baze podataka. Program dozvoljava unos sinhronizacije izmeu baze i modela i to olakava proces odravanja. Neke od podranih baza su SQL Server, Oracle, DB2, Access itd. 2. Ugraeni su mehanizmi za detaljno poreenje baze i modela 3. Omogueno je definisanje dogovora, konvencija o dodjeljivanju naziva atributima, entitetima

4.1.

Kreiranje novog modela

Kada pokrenemo aplikaciju, pojavljuje se prozor koji omoguuje povezivanje parametara za konekciju sa bazom podataka. Naziva se Model Mart Connection Manager.

Ovaj prozor se koristi kada pravimo fiziki model baze podataka. Ako elimo da kreiramo samo logiku model potrebno je oznaiti Supress this dialog on startup. Ako ipak elimo da nakon kreiranja logikog modela napravimo i fiziki model, ovaj prozor moemo kasnije pozvati u programu. Nakon toga moramo odabrati da li elimo da napravimo novi model ili da ureujemo postojei:

9

Odabraemo opciju kreiranja novog modela. Otvori nam se sljedei prozor:

Nakon toga se otvara radna povrina gdje se unose elementi modela:

Prije poetka crtanja modela potrebno je odabrati tzv. notaciju. ERwin nam nudi dva tipa notacija: IDEF1X ( engl. Integration Definition for Information Modeling) i IE (engl. Information Engineering) notacija. Notacije mijenjamo u dijelu Model -> Model Properties -> Notation.

10

Elementima modela moemo mijenjati izgled ( font, boje, veliina slova...). Programski paket ERwin nam to omoguava u dijelu Format. U ERwin u je definisano preslikavanje modela entiteta veza (ER) odreenim pravilima. Nezavisni objekti nemaju nikakvih veza i oni su predstavljeni kao na sledeoj slici:Slika 7: Nezavisni objekti

Zavisni objekti ovise jedan o drugom i ERwin ne dozvoljava samostalan unos zavisnih objekata. Ako definiemo zavisnost veza, program automatski izvrava zaobljenje ivica pravougaonika, to oznaava zavisni entitet. Isprekidana linija oznaava zavisnost. Specijalizacija moe biti ekskluzivna i inkluzivna. Ekskluzivna specijalizacija znai da svaka instanca nadklase moe da specijalizuje samo jednu instancu podklase. Inkluzivna specijalizacija znai da svaka instanca nadklase moe da specijalizuje n instanci podklasa.Slika 8: Ekskluzivna i inkluzivna specijalizacija

ERwin je izgraen na konceptima koji su postavljeni IDEF1X (Integration DEFinition for information modeling) standardom i prvenstveno je namijenjen za modelovanje podataka ER metodom. Notacije koje se mogu ravnopravno koristiti su IDEF1X i IE. IDEF1X notacija je tehnika za modelovanje podataka koja omoguava izgradnju grafikog informacionog modela koji predstavlja podrku prilikom upravljanja podacima, integracije informacionih sistema i izgradnje baze podataka. Prilikom modelovanja podataka moramo voditi rauna o definisanju dva modela: logiko definisanje modela i fiziki dizajn baze. ERwin dozvoljava istovremeni razvoj logikog modela i fiziki dizajn. U logikom modelu osnovni elementi su objekti, atributi i veze, dok u fizikom modelu osnovu predstavljaju tabele, polja, ogranienja, pogledi. Kada definiemo logiki model, potrebno je odabrati server na kojem e baza biti realizovana. Ako odaberemo neki server, bitno je znati da on nije iskljuiv, odnosno moemo ga mijenjati u toku kreiranja modela, to znai da je model nezavisan od platforme. Kao to postoje logiki modeli i fiziki dizajn baze, u ERwin u su definisani logiki i fiziki tipovi podataka. 11

Logiki tip podataka je skup karakteristika atributa koji odreuje duinu polja, pripadnost domenu te naziv. ERwin sadri listu logikih tipova koje moemo dodjeljivati atributima. Sljedea tabela prikazuje predefinisane logike tipove:

TIP PODATKA AUDIO BINARY BOOLEAN CHAR DATE DECIMAL FLOAT HUGE INTEGER INTERVAL LARGE BINARY LONG LONG FLOAT MONEY NCHAR NUMBER NVARCHAR SHORT FLOAT SMALLINT TEXT TIME TIMESTAMP UNIQUEID VARCHAR VIDEO

DOMENA ERwin-a BLOB* BLOB NUMBER STRING DATETIME NUMBER NUMBER NUMBER NUMBER NUMBER BLOB NUMBER NUMBER NUMBER STRING NUMBER STRING NUMBER NUMBER STRING DATETIME DATETIME NUMBER STRING BLOB

DUINA NEODREENA OPCIONALNA NEODREENA OPCIONALNA NEODREENA OPCIONALNA NEODREENA NEODREENA NEODREENA OPCIONALNA OPCIONALNA NEODREENA NEODREENA OPCIONALNA OPCIONALNA OPCIONALNA OBAVEZAN NEODREENA OPCIONALNA OPCIONALNA OPCIONALNA OPCIONALNA OPCIONALNA OBAVEZAN NEODREENA

PRECIZNOST NEODREENA NEODREENA NEODREENA NEODREENA NEODREENA OPCIONALNA NEODREENA NEODREENA NEODREENA NEODREENA NEODREENA NEODREENA NEODREENA OPCIONALNA NEODREENA OPCIONALNA NEODREENA NEODREENA NEODREENA NEODREENA NEODREENA NEODREENA NEODREENA NEODREENA NEODREENA

*BLOB Akronim od Binary Large Object, binarni veliki objekat, je skup binarnih podataka, snimljen kao jedinstven entitet u bazama podataka. To su obino slike, zvuk i multimedijalni sadraji. Navedeni logiki tipovi podataka su nezavisni od sistema za upravljanje bazama podataka. Program ERwin ima takvu osobinu da prilikom kreiranja fizikog modela iz logikog automatski dodjeljuje fiziki tip podataka za svaki atribut na osnovu postojeeg logikog tipa. Takoe, ako iz starijeg fizikog modela kreiramo neki nov, ERwin automatski dodjeljuje odgovarajui fiziki tip podataka za sistem za upravljanje bazama podataka koji je naknadno odabran i za kojeg se vri kreiranje modela. Dakle, za svaki sistem za upravljanje bazama podataka koji podrava, ERwin sadri odgovarajuu emu za pretvaranje logikih u fizike tipove podataka te pretvaranje fizikih u fizike tipove. Konkretan primjer je migracija baze podataka kreirane u Microsoft Access-u u Oracle bazu podataka: 12

MS Access AutoNumber Byte Counter Currency Date / Time Double Integer Long integer Memo OLE object Replication ID Single Text

Oracle ROWID SMALLINT NUMBER NUMBER DATE FLOAT SMALLINT INTEGER LONG VARCHAR CLOB INTEGER FLOAT VARCHAR2

Jo jedna osobina ERwin-a je mogunost kreiranja tzv. generikog fizikog modela. Ovaj model je nezavisan od sistema za upravljanje bazom podataka i na osnovu njega mogue je kreirati vie fizikih modela za razliite SUBP.Slika 9:Konverzija iz logikog u generiki i neke konkretne modele

Postoji i mogunost povezivanja ERwin a i konkretne baze podataka. To omoguuje tzv. server FRE ( Forward and Reverse Engineering). Da bi se ostvarila konekcija, koristi se ODBC drajver. Interesantan je i modul povratnog inenjeringa(engl. Reverse Engineering, koji na osnovu postojee baze kreira ER dijagram po IDEF1X metodologiji.

13

5. BPWinSoftverski alat BPwin je CASE alat koji za modelovanje procesa najee koristi IDEF0 i DFD(Data Flow Diagram) dijagrame. U ovome programu su objedinjeni alati za funkcionalno modeliranje, modeliranje toka poslova i modeliranje toka podataka. Funkcionalno modeliranje se vri uz pomo IDEF0 metode. Omoguuje sistematinu analizu posla tj. za svaku poslovnu funkciju se obezbjeuje kontrola ispravnosti odvijanja, planiraju se potrebni resursi potrebni da se funkcija realizuje, ulazi u poslovnu funkciju, kao i izlazi koji nastaju kao rezultati na osnovu ulaza. IDEF0 je tehnika modeliranja aktivnosti bazirana na kombinaciji grafike i teksta koji su predstavljeni na organizovan i sistematian nain da bi se poveala razumljivost, koja podrava analizu, obezbeuje logiku za potencijalne izmene, specificira zahteve, ili reeno na drugi nain podrava analizu sistema po nivoima i integrie aktivnosti. IDEF0 model se sastoji od hijerarhijskog niza dijagrama koji postepeno prikazuju sve vie detalja o funkcijama i njihovoj vezi sa ostalim dijelovima sistema. IDEF0 omoguuje analizu osobina odreenog poslovnog procesa sa ciljem njegovog maksimalnog unapreenja. Postoje tri vrste dijagrama: 1. grafiki, 2. tekstualni i 3. rjenik (engl. glossary). Grafiki dijagram definie funkcije i veze funkcija preko pravougaonika i strelica i odgovarajue sintakse i semantike. Tekst i rjenik pruaju dodatne informacije i podravaju grafike dijagrame. IDEF0 omoguuje: 1. Izvrenje sistem analize i dizajna na svim nivoima, za sistem sastavljen od ljudi, maina, materijala, raunara i informacija; 2. Stvaranje dokumentacije paralelno sa razvojem sistema koja slui kao osnova za integraciju novih sistema ili za unapreenje postojeih sistema; 3. Bolju komunikaciju izmeu analitiara, dizajnera, korisnika i menadera; 4. Omoguuje upravlja velikim i sloenim projektima; 5. Obezbjeuje elemente potrebne za modeliranje podataka. Sintaksa grafikog jezika IDEF0 su pravougaonici i strelice (boxes and arrows) i pravila (rules). Pravougaonici prestavljaju neke aktivnosti. Svaki od pravougaonika ima ime i broj unutar granica pravougaonika. Ime treba da je aktivan glagol ili glagolska fraza koja opisuje funkciju. Svaki pravougaonik na dijagramu treba da sadri u svojoj unutranjosti broj u donjem desnom uglu. Broj pravougaonika se koristi da bi prepoznao predmet opis problema pravouganika u pridruenom tekstu.

NAZIV AKTIVNOSTI

14

Strelica se sastoji od jedne ili vie linija, sa vrhom na jednom kraju. Strelice mogu biti pravolinijski ili savijene pod uglom od 90 stepeni, i mogu se ravati ili spajati. Strelice predstavljaju podatke ili objekte vezane za aktivnosti i ne predstavljaju samo tok ili sekvencu kao u tradicionalnom modelu dijagrama toka podataka ve prenose podatke ili objekte vezane za posmatranu aktivnost. Svaka strelica ima i ime ali kao i kod imena aktivnosti ono je nedovoljno da bi se u potpunosti shvatilo znaenje pa je potrebno i tekstualno opisati svaki naziv strelice. Pravolinijska strelica

90 o

Zakrivljeni segment strelice, zakrenut je pod 90 stepeni

Ra~vanje

Udru`ivanje strelica (joining)

Pravilima definie se nain crtanja pravougaonika i strelica. Kada je u pitanju pravougaonik potrebno ga je crtati punom linijom sa kvadratnim uglovima i proiri dovoljno da bi mogao da se napie naziv aktivnosti, . Strelice se isto crtaju punom linijom , horizontalno i vertikalno, da dodiruju spoljanje strane pravougaonika(ne uglove) i ne treba da ulaze u unutranjost. Strelice sa lijeve strane pravougaonika definiu se kao ulazi (Input). Strelice koje ulaze u pravougaonik odozgo definiu se kao kontrole (Control). Strelice koje izlaze iz pravougaonika na desnoj strani predstavljaju izlaze (Output). Izlazi su podaci ili objekti proizvedeni od strane aktivnosti. Dakle, ulaz se preko aktivnosti transformie u odgovarajui izlaz (Output) dok kontrole odreuju uslove pod kojima aktivnost daje korektan izlaz. Strelice na donjoj strani pravougaonika predstavljaju mehanizme. Strelice okrenute prema gore identifikuju znaenje koje podravaju izvrenje aktivnosti. Strelice mehanizma koje su okrenute na dole definiu se kao strelice poziva (Call arrows). Dakle, strelice na dijagramima se nazivaju ICOM jer su skraenica od: 1. 2. 3. 4. I - Input, neto to se upotrebljava u procesu C - Control, kontrole ili uslovi na procesu, O - Output, rezultat procesa i M - Mechanism, neto to se koristi u procesu ali se samo ne upotrebljavaKontrola

Ulaz

NAZIV AKTIVNOSTI

Izlaz

Mehanizam

Pozi

15

Ulazna (Input) strelica predstavlja materijal ili informaciju koja se koristi ili transformie s ciljem definisanja izlaza(output). Neke aktivnosti ne moraju imati ulazne strelice. Kontrolne (Control) strelice reguliu odnosno kada i da li e se aktivnost izvesti, odnosno kakvi e biti izlazi. Svaka aktivnost mora imati najmanje jednu kontrolnu strelicu. Kontrole su esto u obliku pravila, politika, procedura, ili standarda. Oni utiu na aktivnost bez da budu transformisane ili upotrebljene. Izlazne (Output) strelice su materijali ili informacije stvorene aktivnou. Svaka aktivnost mora imati najmanje jednu izlaznu (output) strelicu. Strelice mehanizama su oni izvori koji izvode. Mehanizmi mogu biti ljudi, oprema i dr. Strelica poziv (Call) je specifini sluaj strelice mehanizma i ona oznaava da pozivajui pravougaonik nema svoj vlastiti detaljniji dijagram ali je detaljniji prikaz izveden na nekom drugom pravougaoniku u istom ili nekom drugom modelu. Vie pozivajuih pravougaonika mogu pozivati isti pravougaonik na nekom drugom ili istom modelu. Imenuju se sa brojem dekompozicionog dijagrama koji sadri pozvani pravougaonik zajedno sa brojem pozivnog pravougaonika. Dijagrami po IDEF0 metodologiji definiu se preko tri tipa: kontekstni dijagrami, dekompozicioni dijagrami i stablo aktivnosti. Svaki prikazuje razliite aspekte nivoa detaljnosti opisa poslovnih procesa vezanih za dubinu i irinu meusobnih odnosa aktivnosti u modelu. Kao prvi korak koji se preporuuje u kreiranju IDEF0 modelu procesa je kontekstni dijagram. Na ovaj nain definiu se okviri modela procesa. Sljedei korak je definisanje dekompozicionih dijagrama kojima se detaljno definiu po nivoima odgovarajue aktivnosti. Da bi se stekla slika postavljene dekompozicije kao i mogunost sagledavanja hijerarhije aktivnosti definie se stablo aktivnosti (engl. node tree). Kontekstni dijagram definisan je jednim pravougaonikom koji predstavlja granicu sistema koji se prouava. U i van ovog sistema teku informacije preko strelica. Kontekstni dijagram je najvii nivo apstrakcije koji se dekompozicionim dijagramima prevodi u nii nivo apstrakcije. Sledei elementi koji se definiu su ulaz koji se na specifian nain transformie(ili troi) u cilju stvaranja izlaza, mehanizam i kontrole. Dekompozicini dijagram se sastoji od aktivnosti definisanih pravougaonicima i odgovarajuim strelicama. Jedinstvena aktivnost na kontekstnom dijagramu na najviem nivou moe da se dekomponuje u svoje sitnije podaktivnosti kreiranjem child-dijagrama. Takoe, svaka od ovih podaktivnosti childdijagrama moe da se dekomponuje, svaka kreirajui svoj child-dijagram na niem nivou. Svaki od njih sadri pravougaonike i strelice koje pruaju dodatne detalje o roditeljskom pravougaoniku. Roditeljski dijagram sadri jedan ili vie roditeljskih pravougaonika. Svaki obian (non-context) dijagram je takoer child-dijagram poto po definiciji on prikazuje detalje roditeljskog pravougaonika. Takoe, dijagram moe biti i roditeljski dijagram (da sadri roditeljske pravougaonike i child-dijagram (prikazuje detalje sopstvenih roditeljskih pravougaonika). Stablo aktivnosti se definie primjenom metode rjeavanja problema odozgo na dole (top-down). Tako se sloena aktivnost rastavlja na vie podaktivnosti a zatim se pristupa rjeavanju jednostavnih podaktivnosti.

16

Drugim reima, polazna sloena aktivnost razvija se u hijerarhiju podaktivnosti ija je struktura tipa stabla. Korijen stabla (to je najvii vor stabla) sadri polaznu aktivnost, dok listovi tj. vorovi koji nemaju potomaka, sadre aktivnosti ije je rjeavanje jednostavnije. Rjeavanjem svih podaktivnosti iz listova rijeena je i polazna sloena aktivnost. Dakle, stablo aktivnosti predstavlja hijerarhiju definisanih aktivnosti oienu od strelica i omoguuje funkcionalnu dekompoziciju i uvid u dubinu odvijanja veza izmeu aktivnosti. Ovaj pristup je veoma vaan kada uspostavljamo okvir poslovnih procesa koji mogu doi u razmatranje i definiemo njihovu hijerarhijsku vezu. Razbijanje aktivnosti na svoju djecu mora da ima od 3 do 6 podaktivnosti. Ako postoji vie od est podaktivnosti dolazi do zaguenja, tj, smjetanja velikog broja aktivnosti na jedan nivo. Aktivnost na vrhu( root) je uvijek oznaena sa A0. Brojevi se koriste da bi prikazali koliko detalja aktivnost sadri. Aktivnost A0 je dekomponovana - razdvojena - na A1, A2, A3, itd. A1 je dekomponovana u A11, A12, A13, itd. Nakon izvrene i usaglaene dekompozicije od strane korisnika IDEF0 metod omoguuje prelaz na drugi dio razvoja vezan za definisanje entiteta i atributa kroz rjenik podataka. Rjenik sadri definicije o svim aktivnostima i strelicama koje se u modelu pojavljuju kao i uspostavljanje veze sa izmeu IDEF0 (BPwin) metodologije za modeliranje procesa i IDEF1X (ERwin) metodologije za modeliranje procesa. Definicija bi trebala biti jasna pojedincu van poslovnog procesa koji je modelovan. Tokovi podataka prikazani putem strelica povezuju se sa entitetima i sa svim ili samo sa pojedinim atributima tih entiteta. Svakom entitetu se pridodaje nain na koji strelica koristi taj entitet, odnosno ta radi sa pojedinim instancama tog entiteta preko tzv. CRUD matrice: C - Create R - Retrieve U - Update D - Delete

Svakom atributu entiteta koji je identifikovan da ga strelica koristi, odnosno, da ga upotrebljava ta aktivnost, pridodaju se tzv,. IRUN karakteristike I - Insert R - Retrieve U - Update N - Nullifield

Na ovaj nain mogue je kreirati dvije matrice: 1. CRUD matrica na kojoj bi sa jedne strane bili entiteti, a sa druge strane aktivnosti koje koriste te entitete i 2. IRUN matrica sa definicijom koritenja svakog atributa u odreenom entitetu i aktivnosti. Tekstualnim opisom se opisuje do detalja namjena i funkcionisanje svake aktivnosti u modelu. Izvetaji mogu opisati sve relevantne detalje do najsitnijih, a esto razjanjavaju podruje (obim) modela, perspektive i hijerarhiju. 17

6. Realizacija projekta DVD klub uz pomo ERwin-a i BPwin-aKao konkretan primjer modelovanja podataka uz pomo ovih programskih paketa realizovao sam projekat DVD klub. Baza podataka kluba se sastoji od etiri tabele:

Sa prethodnih slika vidimo da su prve tri tabele nezavisni objekti, dok je etvrta zavisan objekat i zavisi od tabele ZADUZENJE. Na sledeim dijagrama prikazan je logiki i fiziki model.

18

Dijagram 1: Logiki model u ERwin-u

23

Dijagram 2: Fiziki model u ERwin-u

24

26

27

28

29

30

31

32

33

34

35

36

7.Literatura:1. Alempije Veljovi, skripta iz predmeta Projektovanje informacionih sistema, Beograd 2009. 2. S. Korth, Database System Concepts, The McGraw Hill Companies, 2001

38

NORMALIZACIJA BAZE PODATAKA

Sadraj1. 2. Uvod ...................................................................................................................................... 2 Osnovni pojmovi ................................................................................................................... 3 2.1. Izrada logikog modela baze podataka ......................................................................... 3 2.2. Teorijske osnove relacione baze podataka .................................................................... 3 2.3. Tabela: skup linija i kolona ........................................................................................... 4 Nebitnost poretka linija ..................................................................................................... 4 Nebitnost poretka kolona .................................................................................................. 4 2.4. Integritet podataka ......................................................................................................... 4 2.5. Primarni klju ................................................................................................................ 5 Neophodnost i obaveznost vrijednosti atributa unutar primarnog kljua ......................... 5 2.6. Referentni integritet....................................................................................................... 5 2.7. Relacije i entiteti............................................................................................................ 6 2.8. Pojam nulte vrijednosti (NULL) ................................................................................... 6 3. Problemi koji se mogu javiti zbog loe projektovanih baza podataka ................................. 8 3.1. Prezentovanje informacija ............................................................................................. 8 3.2. Nemogunost prezentovanja informacija .................................................................... 10 3.3. Gubljenje informacija .................................................................................................. 10 4. Funkcionalna zavisnost. ...................................................................................................... 13 4.1. Potpuna funkcionalna zavisnost .................................................................................. 14 4.2. Parcijalna funkcionalna zavisnost ............................................................................... 14 4.3. Osnovna svojstva funkcionalnih zavisnosti ................................................................ 14 5. Normalizacija ...................................................................................................................... 16 5.1. Prva normalna forma ................................................................................................... 17 5.2. Druga normalna forma ................................................................................................ 20 5.3. Trea normalna forma ................................................................................................. 21 5.4. Boyce-Codd-ova normalna forma (BCNF) ................................................................. 23 5.5. etvrta normalna forma i vieznane zavisnosti ......................................................... 25 6. Zakljuak ............................................................................................................................. 29 7. Literatura ............................................................................................................................. 30

1.

Uvod

Osnovni problem u projektovanju baza podataka je kako grupisati podatake u zapise, segmente ili n-torke. Razliiti naini grupisanja podataka u razliitim situacijama ispoljavaju odreene prednosti ili nedostatke. Veina baza podataka se konstantno mijenja: dodaju se nove vrste podataka, podaci se meusobno udruuju, uklanjaju se nepotrebni ili se mijenjaju postojei. Svaka promjena moe biti ekstremno razorna u sluaju pogrenog grupisanja podataka. U ovom tekstu bie izloeni problemi koji se pojavljuju usljed pogrenog grupisanja podataka, te postupci za realizaciju stabilnih struktura podataka (normalizaciju strukture baze podataka) kojom se minimizuje vjerovatnou pojavljivanja razliitih anomalija. Opti zahtjev koji se postavlja pred relacione baze podataka je da one omogue: smjetanje informacija bez nepotrebnih ponavljanja (redundancije), mogunost (jednostavnog) dobijanja informacija iz baze, modifikacije dijela strukture baze podataka bez potrebe mijenjanja aplikativnih programa niti ostalog dijela strukture baze podataka. Postupak izgradnje strukture baze podataka koja zadovoljava gornje zahtjeve naziva se normalizacija. Postoji vie razliitih normalnih formi organizacije baza podataka koje imaju razliite karakteristike u smislu prethodno navedenih zahtjeva. Svaka normalna forma namee i specifina ogranienja. Za projektanta baza podataka je od interesa da zna u kojoj normalnoj formi je postojea organizacija strukture baze podataka, odnosno da zna postupak izgradnje strukture baze podataka koji zadovoljava zahtjeve odreene normalne forme. Normalizacija baze podataka se bavi smanjivanjem nepotrebnih ponavljanja podataka u tabelama. To za cilj ima izgradnju manje i kompaktnije baze podataka, a posljedica toga je vei broj relacija (tabela) u bazi koje su meusobno povezane preko kljueva i indeksa. Motiv kojim se rukovodimo pri tome je smanjenje konfuzije koja nastaje ako u tabeli ili tabelama baze podataka imamo iste podatke koji se u vie primjeraka pojavljuju na razliitim mjestima. Problem nastaje pri auriranju takvih podataka, postoji mogunost pogreke pri unosu podataka u bazu, problemi pri sortiranju i pretraivanju. Imajui u vidu da u veini sluajeva jednu bazu koristi vie korisnika, jo je oiglednije da e doi do greaka. Sa druge strane, dizajneri baze podataka ne treba da normalizuju bazu po svaku cijenu jer to moe da ima uticaj na brzinu i efikasnost pri radu sa bazom. Uklanjanjem duplikata podataka obezbjeuje se bre sortiranje i bre izvravanje upita, a to znai poboljanje performansi. Iako e normalizacija dati efikasniju baza podataka, mogue je pretjerati u normalizovanju podataka kreiranjem velikog broja relacija i jako puno manjih tabela tako da ako hoemo da pronaemu neku informaciju to zahtjeva pristupanje velikom broju tabela i njihovo udruivanje. Iskusni dizajneri znaju kad se treba zaustaviti pri normalizaciji. Ovo znanje dolazi uglavnom sa iskustvom i praktinim radom. Prije samog razmatranja o postupcima normalizacije baze podataka pretpostavka je da vladamo nekim osnovnim pojmovima vezanim za ovu problematiku. U cilju podsjeanja ovde u iznijeti ukratko objanjenja nekih osnovnih elemenata baze podataka. 2

2.

Osnovni pojmovi

Sam pojam baza podataka pojavio se krajem ezdesetih godina i predstavljao je skup meusobno povezanih podataka koji se uvaju zajedno. Postoji vie naina organizovanja podataka u bazu podataka, ali ovdje e iskljuivo biti govora o relacionim bazama podataka.

2.1. Izrada logikog modela baze podatakaTeorijska osnova za izradu baze podataka poiva na logikom modelu baze podataka. Kao to je pravilo pri modelovanju, i ovaj model predstavlja idealizovanu sliku sistema koji postoji u stvarnosti. Korisnost jednog modela zavisi od tanosti kojom on predstavlja realni sistem. Model najee predstavlja preduzee te stoga ima izraeniju dinamiku nego statiku narav. Neophodno je da model slijedi promjene do kojih dolazi u okviru djelovanja preduzea i da evoluira zajedno sa preduzeem. Logii model baze podataka predstavlja elemente podataka koriene u preduzeu i njihove meusobne relacije. Najee upotrebljavana metoda pri izradi logikog modela baze podataka je tzv. metoda Entiteti-Relacije. Entiteti u logikom modelu predstavljaju osobe, mjesta, objekte, idejne tvorevine. Svaki entitet je opisan kroz skup atributa koji su mu pridrueni. U primjeru baze podataka u kojoj pohranjujemo podatke o preduzeu, s take gledita sekretarice svaki zaposleni radnik predstavljen je skupom atributa kao to su njegovo ime i prezime, odjel u kojem je rasporeen. Za rukovodioca odjela isti zaposleni radnik je predstavljen skupom koji se ne poklapa obavezno sa sekretariinim. U tu grupu atributa spadaju na primjer radno mjesto zaposlenog, struna sprema koju zaposleni posjeduje itd. Kao to se vidi iz primjera, rukovodna pravila upravljaju oblikovanjem logikog modela baze podataka. Nadalje, entiteti ne postoje kao izolovani subjekti, nego su povezani relacijama. Relacije koristimo u cilju primjene rukovodnih pravila. Za primjer moemo navesti pravilo da je jedan i samo jedan zaposleni ujedno i rukovodilac odjela u kojem je rasporeen. Moemo se pitati koja je svrha izrade ovoga modela? Prilikom izrade logikog modela baze podataka moramo uzeti u obzir sve podatke koriene u okviru djelovanja preduzea i njihove meusobne relacije. Pri tome se ne treba obazirati na detalje primjene, kao na primjer tip podataka koji treba da sadri pojedina kolona. Nivo uoptavanja pri izradi logikog modela baze podataka je vii od nivoa uoptavanja fizikog modela baze podataka.

2.2. Teorijske osnove relacione baze podatakaNemogue je je govoriti o izradi baze podataka a da se neto ne kae o teorijskim osnovama na kojima poiva relacioni sistem baza podataka. Ukratko, te osnove su sledee: Svaki entitet posjeduje skup atributa koji ga opisuju. U bazi koju uzimamo za primjer, entitet nazvan Klijent opisuje klijente preduzea. Jedna linija u tabeli odgovara skupu atributa jednog konkretnog entiteta. Konkretan entitet u primjeru Klijenta bio bi klijent preduzea kojeg odreuju sledei atributi: K251, Europrom, Veselina Maslee 25, Banja Luka, 051/123-456. Pojedini atributi jednoznano oznaavaju svaki konkretan entitet. Te atribute ili skupove atributa nazivamo primarnim kljuem. Za entitet koji opisuje klijente 3

preduzea Klijent_ID je primarni klju jer nam omoguuje da identifikujemo svakog klijenta (ne postoje dva klijenta koji posjeduju identian Klijent_ID). Atribut koji sainjava primarni klju mora posjedovati vrijednost (ne moe biti NULL). Strani klju entiteta je atribut ija vrijednost mora postojati kao vrijednost u primarnom kljuu drugog entiteta. Entiteti su meusobno povezani. Poredak linija entiteta je nevaan. Poredak atributa unutar entiteta je nevaan.

2.3. Tabela: skup linija i kolonaS take gledita informatiara entitet je tabela u bazi podataka. Atributi entiteta su kolone jedne tabele. Jedinstven skup atributa odreenog entiteta, odnosno skup vrijednosti kolona jedne tabele naziva se linija. Pojmovi linija i zapis (slog) ravnopravno se koriste. Upravljaki Sistem Relacione Baze Podataka (RDBMS) Microsoft SQL Server raspolae internom strukturom fajlova sa podacima tako da nije mogue odrediti koje su tabele pohranjene u bazi podataka na osnovu strukture fajlova. Pojedini sistemi kao dBASE pohranjuju tabele kao zasebne fajlove to nije ovdje sluaj. Nebitnost poretka linija Kljuni princip teorije relacione baze podataka jeste da tabela ne posjeduje implicitan poredak. Da bismo dobili linije iz baze podataka u eljenom poretku neophodno je da taj poredak naznaimo prilikom konstruisanja upita. Nebitnost poretka kolona Kao u sluaju linija tako ni kolone jedne tabele nemaju neki predodreeni redoslijed. Ukoliko pristupamo kolonama jedne tabele ne navodei ih eksplicitno, onda moramo znati njihov poredak u kojem su kreirane. Npr. ako elimo dodati jedan zapis u tabelu, onda vrijednosti koje dodajemo moraju odgovarati po tipu, redoslijedu i ukupnom broju atributa kako je definisano pri kreiranju tabele. Meutim, nita nas ne spreava da definiemo drugaiji poredak kolona prilikom kostrukcije zahtjeva . Moemo takoe promijeniti definiciju jedne kolone tako da to ne utie na definiciju ostalih kolona iste tabele. Upravljaki sistem je nadlean da tom prilikom obavi sve promjene u fizikoj strukturi baze podataka. Stoga kaemo da relaciona baza podataka prua logiku nezavisnost podataka.

2.4. Integritet podatakaPrema teoriji relacionog sistema, svaki entitet posjeduje skup atributa koji jednoznano identifikuju svaku od njegovih linija. On takoe precizira kako nijedna linija ne treba da je duplicirana unutar tabele odakle proizilazi da svaka tabela treba da posjeduje primarni klju. Ovaj princip je nazvan integritet podataka. Primjera radi, matini broj graanina je jedinstven za svakog zaposlenog. 4

2.5. Primarni kljuSvaki entitet posjeduje skup atributa koji omoguuje da jednoznano identifikujemo konkretan entitet. Taj skup atributa nazivamo primarni klju. Primarni klju moe da sainjava jedan atribut - Klijent_ID u sluaju entiteta Klijent, ili vie atributa - u sluaju entiteta Stavke_racuna svaka stavka je identifikovana atributima Broj_racuna i RB_stavke. Izbor pojedinih primarnih kljueva je oit, to meutim nije uvijek sluaj. Primarni klju je skup atributa koji jednoznano identifikuje liniju. Neophodnost i obaveznost vrijednosti atributa unutar primarnog kljua Kao to je ve reeno, kljuni princip teorije relacionih sistema zahtjeva da niti jedan atribut koji ulazi u sastav primarnog kljua ne moe imati nultu vrijednost (NULL). Prema tome, ukoliko primarni klju ili njegov dio ne posjeduje nikakvu vrijednost on nita ne moe da identifikuje. Jedan klijent, iji primarni klju ne posjeduje vrijednost, ne moe ni na koji nain biti identifikovan ili tretiran.

2.6. Referentni integritetTabele su meusobno povezane posredstvom stranih kljueva. Jedan strani klju se sastoji od jedne ili vie kolona ije su vrijednosti u potpunosti sadrane u primarnom kljuu neke druge tabele.

Slika 1. Grafiki prikaz stranog kljua

Gornji primjer prikazuje tabele "Klijenti", "Racuni" i "Racun_Stavke", povezane stranim kljucevima. Te veza podrazumijevaju da sve vrijednosti u koloni Racun_ID tabele Racun_Stavke moraju postojati u koloni Racun_ID tabele Racuni, i da sve vrijednosti Klijent_ID u tabeli Racuni moraju postojati u koloni Klijent_ID tabele Klijenti. Referentni integritet je postignut onda kada svaka vrijednost stranog kljua postoji meu vrijednostima primarnog kljua na koji nas upuuje strani klju ili je jednaka nultoj vrijednosti (NULL). Od momenta kada smo definisali primarne i strane kljueve nad bazom podataka garantovanje integriteta podataka i referentnog integriteta je u nadlenosti Upravljakog Sistema Relacione Baze Podataka (RDBMS).

5

2.7. Relacije i entitetiRelacija definie odnos izmeu dva entiteta. Unutar relacije jedan entitet je definisan kao roditelj dok je drugi dijete. Relacija posjeduje sledee karakteristike: Identifikaciona ili neidentifikaciona relacija. U sluaju identifikacione relacije, primarni klju roditelja ini sastavni dio primarnog kljua djeteta, to nije sluaj kod neidentifikacionih relacija. Kardinalnost. Kardinalnost jedne relacije je definisana brojem linija entiteta djeteta koje su u vezi sa jednom linijom entiteta roditelja. Mogue je govoriti o donjoj i gornjoj kardinalnosti. U sluaju relacije izmeu entiteta Zaposleni i entiteta Radna_Jedinica, gdje svaka radna jedinica okuplja jednog ili vie zaposlenih, moemo govoriti o kardinalnosti (1,n). Primjeri kardinalnosti sa kojima se susreemo su (0), (1) i (n) . Kardinalnost definie broj linija entiteta djeteta koje su u vezi sa jednom te istom linijom entiteta roditelja. Kardinalnost jedne relacije moe biti obavezna - primjer u kome jedna linija entiteta roditelj mora obavezno biti vezana sa jednom i samo jednom linijom entiteta djeteta. Kardinalnost moe biti i manje restriktivna - primjer u kome jedna linija entiteta roditelja moe da nema vezu ni sa jednom linijom entiteta djeteta ili naprotiv da posjeduje veze sa vie linija entiteta dijete. Obavezna ili neobavezna relacija. Relacija je obavezna u sluaju kada svaka linija entiteta roditelj mora da je u vezi sa jednom ili vie linija entiteta djete. Relacija je neobavezna u sluaju kada linija entiteta roditelja moe da postoji iako joj nijedna linija entiteta djeteta nije pridruena. Pravila integriteta. Ova pravila definiu aktivnosti koje je neophodno preduzeti prilikom izmjene linija u entitetu roditelj ili entitetu dijete. Postoji est mogunosti izmjene: dodavanje, izmjena ili brisanje linije u entitetu roditelj i dodavanje, izmjena ili brisanje linije u entitetu dijete. Za svaku od navedenih izmjena mogue je preduzeti jednu od sljedeih aktivnosti : ograniavanje odnosno spreavanje izmjene, pridruivanje nulte vrijednosti u kljuu entiteta roditelja ili entiteta dijete, pridruivanje za taj sluaj unaprijed definisane vrijednosti u kljuu entiteta roditelj ili entiteta djeteta, primjeniti istovjetnu izmjenu nad odgovarajuim linijama entiteta dijete

2.8. Pojam nulte vrijednosti (NULL)Jedna od osnovnih razlika izmeu relacione baze podataka i starijih baza podataka jeste pojam nulte vrijednosti koji je prisutan u relacionim bazama podataka. Ova specijalna vrijednost ukazuje na odsustvo bilo kakve vrijednost u polju znakovnog ili numerikog tipa. Uvedena je od strane E.F. Codd-a kreatora relacionog modela baze podataka. Null marker slui da ispuni zahtjev svih sistema za upravljanje relacionim bazama podataka da predstavi 6

sluaj "nedostaje informacija" ili "neprimjenljiva informacija". Codd je takoe uveo malo grko slovo omega kao simbol koji predstavlja null vrijednost. Null je SQL rezervisana rije koja se koristi da identifikuje null specijalni marker Nulta vrijednost pokazuje da vrijednost kolone ili formule ili nije primjenjiva u datom sluaju ili da jos nije dodijeljena. U relacionoj bazi podataka nulta vrijednost u koloni moe izraavati razliite koncepte : Koloni nije mogue dodijeliti vrijednost za datu liniju. Koloni nije jo uvijek dodijeljena vrijednost.

Relaciona baza podataka omoguava dodjelu nulte vrijednost u koloni kao i test kolone koji ukazuje da kolona sadri nultu vrijednost.

7

3.

Problemi koji se mogu javiti zbog loe projektovanih baza podatakaUobiajeni problemi koji se javljaju usljed loe projektovane baze podataka su sledei: nepotrebno ponavljanje informacija, nemogunost prezentovanja odreenih informacija gubitak informacija.

Da bi ovo ilustrovali uzeemo primjer iz bankarskog poslovanja. Sledee dvije relacije opisuju podatke o filijalama i kreditima: Filijala (NazivFilijale, RaspolozivaSredstva, GradFilijale) Kredit (NazivFilijale, BrojKredita, NazivKorisnika, Iznos) sa sledeim primjerima moguih instanci datim u tabelama 1 i 2.Tabela 1. Filijala NazivFilijale Jankovac Brdo Kasindol Starevica Lau 1 Lau 2 Centar Stup RaspolozivaSredstva 9.000.000 2.100.000 1.700.000 400.000 8.000.000 3.700.000 300.000 7.100.000 GradFilijale Trebinje Trebinje Sarajevo Banja Luka Banja Luka Banja Luka Laktai Sarajevo

Tabela 2. Kredit NazivFilijale Jankovac Brdo Kasindol Jankovac Starevica Lau 1 Lau 2 Centar Stup Lau 1 Stup BrojKredita 17 23 15 14 93 11 29 16 18 25 10 NazivKorisnika Belt Comesgrafika Drvo commerce Extilia Fanny Iso-tec Kings Agrovet Fructa-trade Atlantik Fobolux Iznos 15.000 20.000 150.000 150.000 10.000 65.000 20.000 25.000 1.000.000 85.000 600.000

3.1. Prezentovanje informacijaNapraviemo i alternativnu organizaciju baze podataka banke u kojoj smo umjesto relacija Filijala i Kredit koristili jedinstvenu emu: Kreditiranje (NazivFilijale, RaspolozivaSredstva, GradFilijale, BrojKredita, NazivKorisnika, Iznos) Nova relacija je dobijena prirodnim spajanjem relacija Kredit i Filijala. 8

Tabela 3. Kreditiranje NazivFilijale Jankovac Brdo Kasindol Jankovac Starevica Lau 1 Lau 2 Centar Stup Lau 1 Stup RaspolozivaSredstva 9.000.000 2.100.000 1.700.000 9.000.000 400.000 8.000.000 3.700.000 300.000 7.100.000 8.000.000 7.100.000 GradFilijale Trebinje Trebinje Sarajevo Trebinje Banja Luka Banja Luka Banja Luka Laktai Sarajevo Banja Luka Sarajevo BrojKredita 17 23 15 14 93 11 29 16 18 25 10 NazivKorisnika Belt Comesgrafika Drvo commerce Extilia Fanny Iso-tec Kings Agrovet Fructa-trade Atlantik Fobolux Iznos 15.000 20.000 150.000 150.000 10.000 65.000 20.000 25.000 1.000.000 85.000 600.000

n-torka - t u relaciji Kreditiranje ima sljedee znaenje: t[RaspolozivaSredstva] predstavlja finansijska sredstva (kapital) namijenjen za odreenu liniju kreditiranja koja su na raspolaganju filijali sa nazivom t[NazivFilijale], t[GradFilijale] je grad u kome je filijala sa nazivom t[NazivFilijale] locirana, t[BrojKredita] je broj kredita odobrenog u filijali t[NazivFilijale] korisniku sa nazivom t[NazivKorisnika] t[Iznos] je iznos kredita broj t[BrojKredita] Pretpostavimo da elimo da dodamo novi kredit u bazu podataka. Pretpostavimo takoe, da je kredit ugovoren u Lau 1 filijali za korisnika Kings u iznosu od 10.000 KM. Neka je broj zajma 31. U poetnoj organizaciji (prvoj verziji) baze podataka, dodali bi ntorku: (Lau 1, 31, Kings, 10000) u relaciju Kredit. U alternativnoj organizaciji baze podataka, ako elimo da registrujemo novi kredit, treba da dodamo odgovarajuu ntorku, sa vrijednostima svih atributa relacije Kreditiranje. Zato, moramo ponoviti RaspolozivaSredstva i GradFilijale za Lau 1, tako da ntorka koja se umee ima sadraj: (Lau 1, 8.000.000, Banja Luka, 31, Kings, 10000) u relaciji Kreditiranje. Generalno, podaci za RaspolozivaSredstva i GradFilijale treba da se pojave samo jedanput bez obzira na broj kredita odobrenih od strane te filijale. Ponavljanje informacija u alternativnom dizajnu nije prihvatljivo. S jedne strane to ponavljanje troi memorijski prostor a s druge strane komplikuje modifikaciju baze podataka. Pretpostavimo naprimjer, da Lau 1filijala dolazi iz Banjaluke u Laktae. Po prvom rjeenju, bila bi potrebna promjena jedne ntorke relacije filijala. Po alternativnom dizajnu, mnogo ntorki relacije Kreditiranje moralo bi da se mijenja. Kada se vri modifikacija alternativne baze na pomenuti nain, mora se osigurati da svaka n-torka koja pripada Lau 1

9

filijali bude modifikovana, ili emo, u suprotnom, imati situaciju da e u bazi postojati dva grada za filijalu Lau 1. Prethodno opaanje je bitno, za razumijevanje zato je alternativno rjeenje loe. Jasno je da je filijala banke smjetena u jednom gradu, tj. NazivFilijale GradFilijale (NazivFilijale identifikuje GradFilijale). S druge strane, poto filijala moe napraviti mnogo zajmova ne vai NazivFilijale BrojKredita. injenica da je filijala locirana u nekom gradu i injenica da filijala daje zajmove su nezavisne, i kao to pokazuje primjer, ove injenice se najbolje predstavljaju u odvojenim relacijama.

3.2. Nemogunost prezentovanja informacijaJo jedan problem sa relacijom Kreditiranje je da ne moemo direktno predstaviti informacije koje se tiu filijala (NazivFilijale, RaspolozivaSredstva, GradFilijale) ukoliko ne postoji najmanje jedan kredit u filijali. To je zato to ntorke u relaciji Kreditiranje zahtijevaju vrijednosti za BrojKredita, Iznos i NazivKorisnika. Jedan nain rjeavanja ovog problema je uvoenje NULL-vrijednosti, ali postoje potekoe u manipulaciji nul-vrijednostima. Ako se ne eli raditi sa nul-vrijednostima, informacije o filijali se mogu kreirati tek nakon to se kreira prvi kredit filijale. Jo nepovoljnije je to bi trebalo izbrisati i informacije o filijali kad svi krediti budu likvidirani. Iz navedenog je vidljivo da je poetna varijanta organizacije baze podataka bolja, jer informacije o filijali mogu postojati u bazi bez obzira da li u filijali postoje ili ne aktivni krediti, i to bez korienja nul-vrijednosti.

3.3. Gubljenje informacijaGore navedeni primjer loeg dizajna baze podataka sugerie da treba dekomponovati relacionu emu sa mnogo atributa u nekoliko ema sa manjim brojem atributa. Nepaljiva dekompozicija moe voditi u jo jednu loe dizajniranu formu. Razmotrimo jedan alternativni dizajn u kome je relacija Kredit dekomponovana u dvije relacije: Iznos i Zajam, kao to slijedi: Iznos (Iznos, NazivKorisnika) Zajam (NazivFilijale, BrojKredita, Iznos)Tabela 4. Zajam NazivFilijale Jankovac Brdo Kasindol Jankovac Starevica Lau 1 Lau 2 Centar Stup Lau 1 Stup BrojKredita 17 23 15 14 93 11 29 16 18 25 10 Iznos 15.000 20.000 150.000 150.000 10.000 65.000 20.000 25.000 1.000.000 85.000 600.000

10

Tabela 5. Iznos Iznos 15.000 20.000 150.000 150.000 10.000 65.000 20.000 25.000 1.000.000 85.000 600.000 NazivKorisnika Belt Comesgrafika Drvo commerce Extilia Fanny Iso-tec Kings Agrovet Fructa-trade Atlantik Fobolux

Ako elimo rekonstruisati relaciju Kredit, prirodan nain je da koristimo prirodno spajanje relacija Iznos i Zajam. Tabela 6. pokazuje rezultat prirodnog spajanja tabela Iznos i Zajam.Tabela 6. Relacija Iznos X Zajam NazivFilijale Jankovac Brdo Kasindol Jankovac Starevica Lau 1 Lau 2 Centar Stup Lau 1 Stup Brdo Kasindol Jankovac Lau 2 BrojKredita 17 23 15 14 93 11 29 16 18 25 10 23 15 14 29 NazivKorisnika Belt Comesgrafika Drvo commerce Extilia Fanny Iso-tec Kings Agrovet Fructa-trade Atlantik Fobolux Kings Extilia Drvo commerce Comesgrafika Iznos 15.000 20.000 150.000 150.000 10.000 65.000 20.000 25.000 1.000.000 85.000 600.000 20.000 150.000 150.000 20.000

Kad se poredi ova relacija sa originalnom relacijom Kredit, predstavljenom u tabeli 2. uoavaju se razlike. Iako se svaka n-torka koja se javlja u relaciji Kredit javlja i u relaciji Iznos X Zajam, moemo uoiti da u relaciji Iznos X Zajam postoje n-torke koje nisu u relaciji Kredit. To su sljedee n-torke:Brdo Kasindol Jankovac Lau 2 23 15 14 29 Kings Extilia Drvo commerce Comesgrafika 20.000 150.000 150.000 20.000

Ako u ovakvu jednu relaciju postavimo upit: "Nai filijale u kojima Kings ima kredit", kao rezultat dobiemo dvije filijale: Brdo i Lau 2. Stvarni rezultat se dobija ako taj isti upit postavimo u relaciju Kredit (tabela 2.). Dobiemo samo jednu filijalu Lau 2. Zato je to tako? Razlog lei u nepravilno izvrenoj dekompoziciji relacije Kredit. 11

Ako ovaj primjer pogledamo paljivije, vidi se da ako postoji vie zajmovva u istom iznosu, ne moemo rekonstruisati koji korisnik ima koji kredit. Dakle, prirodnim spajanjem relacija Iznos X Zajam, ne dobijaju se samo n-torke koje se nalaze u originalnoj relaciji Kredit, nego, takoe i nekoliko dodatnih n-torki. Iako imamo vie n-torki u relaciji Iznos X Zajam, raspolaemo sa manje informacija, zapravo dobijamo pogrene informacije i nismo vie u mogunosti, u optem sluaju, predstaviti u datoj bazi podataka (sa relacijama Iznos i Zajam) kod kojih filijala korisnici koriste kredit. Zbog ovog gubljenja informacija, dekompoziciju relacije Kredit na relacije Iznos i Zajam zovemo LOSSY-JOIN dekompozicija (dekompozicija sa gubljenjem informacija prilikom spajanja). Dekompozicija koja ne gubi informacije se naziva LOSSLESS-JOIN dekompozicija. Potraiemo razlog zbog kojeg dolazi do gubitka informacija. Zajedniki atribut za relacije Iznos i Zajam je atribut [Iznos]. Jedini nain na koji moemo povezati NazivFilijale i NazivKorisnika je kroz atribut Iznos. Takvo ostvarivanje veze nije adekvatno, jer vie korisnika moe imati zajmove sa istim iznosom, a da ovi zajmovi ne moraju biti od istih filijala. Slino tome, mnogo korisnika moe imati zajmove od istih filijala, dok iznosi njihovih zajmova mogu biti nepovezani jedan sa drugim. Primjer bolje dekompozicije imamo na primjeru dekompozicije relacije Kreditiranje na relacije Kredit i Filijala. Zajdniki atribut za ove relacije je [NazivFilijale]. Jedini nain na koji moemo predstaviti vezu izmeu, na primjer, GradFilijale i NazivKorisnika je kroz NazivFilijale. U emi Filijala atributi RaspolozivaSredstva i GradFilijale su jedinstveno odreeni atributom NazivFilijale. NazivFilijale RaspolozivaSredstva NazivFilijale GradFilijale Jedan od osnovnih problema kje je potrebno rijeiti je nain utvrivanja da li je dekompozicija lossless-join ili ne, odnosno kako realizovati lossless-join dekompoziciju. Polazna taka je odreivanje ogranienja koje polazna baza podataka (i analogno, dekomponovane baze podataka) moraju da zadovolje. U narednom tekstu bie izloena teorija funkcionalne zavisnosti, koja se koristi u procesu dekompozicije, odnosno u procesu normalizacije strukture baza podataka.

12

4.

Funkcionalna zavisnost.

U projektovanju sistema najee je neophodno da se relacija dekomponuje na vei broj manjih relacija u cilju eliminisanja problema navedenih u prethodnom dijelu. Koristei koncept funkcionalne zavisnosti moe se definisati vie normalnih formi koje predstavljaju dobru organizaciju baza podataka. Funkcionalne zavisnosti predstavljaju ogranienje na skupu legalnih relacija. Funkcionalne zavisnosti omoguavaju da se izraze svojstva sistema koji se modelira bazom podataka. Funkcionalna zavisnost se definie na sljedei nain: Neka je r relacija nad emom R. Atribut Y u emi R je funkcionalno zavisan od atributa X relacione eme R ako u svakom trenutku vremena, za svaku vrijednost u X nema vie od jedne vrijednosti u Y koja joj je pridruena u relaciji r. ( X , Y R ) relacione eme R, tj. X {A1 , A2 ,... An } , Y {A1 , A2 ,... An } . Sa R[XY ] emo oznaiti projekciju Dakle, neka je R( A1 , A2 ,..., An ) relaciona ema, a X i Y podskupovi skupa svih atributa

R po atributima iz X i Y. Kaemo da postoji funkcionalna zavisnost X Y ako i samo ako uvijek u relaciji nad R[XY ] vai:

R[X ] R[Y ]Ako funkcionalna zavisnost ne postoji (piemo X Y onda u relaciji nad R[XY ] moe / postojati vie elemenata koji imaju istu vrijednost atributa iz X a razliitu vrijednost atributa iz Y. Funkcionalna zavisnost je vremenski nepromjenljivo svojstvo. Ako kaemo da je Y funkcionalno zavisno od X, to je kao da kaemo da X odreuje Y. Posmatrajmo relaciju: Radnik (Radnik#, Radnik-Ime, Plata, Projekat#, Rok-Izrade). Funkcionalne zavisnosti u ovoj relaciji moemo predstaviti grafiki.Radnik# * Radnik-Ime * Plata Projekat# Rok-Izrade Slika 2. Funkcionalne zavisnosti * - oznaava primarne atribute (lanove kandidatskih kljueva)

Radnik# nije funkcionalno zavisan od Plate zato to vie od jednog radnika moe imati istu platu. Slino Radnik# nije funkcionalno zavisan od Projekat#, ali jeste rok izrade i u ovoj relaciji nema vie atributa funkcionalno zavisnih od Projekat#. Atribut esto moe biti funkcionalno zavisan od grupe atributa, umjesto od samo jednog atributa. To moemo ilustrovati preko sledee relacije: RacunStavke (Racun#, RedniBroj, Artikal#, Kolicina, Cijena)

13

Artikal# je funkcionalno zavisan od kandidatskog kljua (Racun#, RedniBroj). Ovdje pretpostavljamo da u okviru iste vrijednosti atributa Racun# ne smiju se ponavljati iste vrijednosti atributa RedniBroj. Funkcionalna zavisnost u ovoj relaciji moe biti nacrtana kao na slici 3.Racun# * RedniBroj * Artikal# Kolicina Cijena Slika 3. Zavisnost od grupe atributa

4.1. Potpuna funkcionalna zavisnostAtribut ili skup atributa B u relacionoj emi R je potpuno funkcionalno zavisan od druge kolekcije atributa A relacione eme R, ako je B funkcionalno zavisan od cijelog A, a ne od nekog njegovog podskupa. Na primjer, u relacionoj emi RacunStavke, atribut Artikal# je potpuno funkcionalno zavisno od konkatenacionog kljua (Racun#, RedniBroj) zato to se odnosi na to koji artikal se nalazi na datom rednom broju (RedniBroj) datog rauna broj Racun#. Niti Racun#, niti RedniBroj pojedinano ne odreuju atribute Artikal#, Kolicina i Cijena.

4.2. Parcijalna funkcionalna zavisnostNeka su X i Y skupovi atributa. Ako za neki X X vai X Y , onda je funkcionalna zavisnost X Y parcijalna.

4.3. Osnovna svojstva funkcionalnih zavisnosti1. Jedinstvenost: Ako su f: X Y i g: X Y funkcionalne zavisnosti, tada je f=g, tj. postoji samo jedna funkcionalna zavisnost za date domene X i Y. 2. Refleksivnost: Ako je X Y tada postoji funkcionalna zavisnost Y X tj. svaki skup atributa identifikuje svaki svoj podskup. Ovakva zavisnost se naziva TRIVIJALNA ZAVISNOST. 3. Tranzitivnost: Ako su f: X Y i g: Y Z funkcionalne zavisnosti nad R, tada vrijedi funkcionalna zavisnost X Z. 4. Proirenje: Ako vae funkcionalne zavisnosti X Y, i Z je skup atributa, tada vai i funkcionalna zavisnost ZX ZY. Iz osnovnih osobina funkcionalne zavisnosti mogu se izvesti sljedee osobine: 1. Pravilo unije: Ako su X Y i X Z funkcionalne zavisnosti nad R, onda postoji funkcionalna zavisnost X YZ. 14

2. Pravilo dekompozicije: Ako vai funkcionalna zavisnost X YZ, tada vae i funkcionalne zavisnosti X Y i X Z. 3. Pseudotranzitivnost: Ako vae funkcionalne zavisnosti X Y, YW Z, tada vai i funkcionalna zavisnost XW Z. Egzistencija funkcionalnih zavisnosti treba da se ouva i nakon zamjene relacije njenim projekcijama, jer se tako prvobitna relacija moe restaurirati primjenom operacije prirodnog spajanja, uz ouvanje originalnih funkcionalnih zavisnosti.

15

5.

Normalizacija

Kreiranje tabela baze podataka je jednostavan posao, meutim vanije je posvetiti se iznalaenju optimalne eme baze podataka. Kod relacionih baza podataka izuzetno je vano izvriti normalizaciju baze podataka. Normalizacija se svodi na izuavanje relacija izmeu tabela, atributa i meusobne zavisnosti atributa u cilju: su: Eliminacija grupa koje se ponavljaju Eliminacija redundantnih podataka Eliminacija kolona koje ne zavise od primarnog kljua Ne uvati izraunate podatke u tabelama Izdvajanje viestrukih zavisnosti minimiziranja nepotrebnih podataka (smanjenje redundancije), izbjegavanja anomalija pri auriranju podataka, izrade strukture podataka pogodne za odravanje.

Edgar F. Codd, istraiva IBM-a je 1969. godine postavio pet pravila normalizacije, a to

Teorija normalizovanja omoguuje nam da opiemo eljenu strukturu tabela i kolona unutar baze podataka u skladu sa pravilima normalizacije. Stadijume u normalizovanju baze podataka nazivamo normalnim formama. Tako imamo prvu normalnu formu, drugu normalnu formu, itd i esto ih oznaavamo kraticama 1NF, 2NF, itd. Najee se baza normalizuje do tree normalne forme, dok se ostale Boyce-Coddova, etvrta, peta i esta tiu znatno sloenijih problema i takve situacije je teko sresti u praksi. Neko ko se bar malo bavi bazama podataka teko da e doi u situaciju da napravi unutar baze podataka tabelu kakva slijedi. Meutim mogue je pasti u zamku u procesu prikupljanja podataka za izradu baze podataka posmatrajui, recimo, dokumente i razne krajnje izvjetaje u jednom preduzeu. Ako posmatramo, npr. jedan raun za kupljenu robu, prvo uoimo broj rauna, pa datum, podatke o kupcu, stavke na raunu i konano iznos koji treba platiti. Ako je to stvarni entitet koji elimo predstaviti u naoj bazi podataka, onda moemo napraviti jednu tabelu sa atributima kao na slici 4. koja, u stvari predstavlja stari nain projekotavnja bez normalizacije. Zasad e to biti jedina tabela u bazi podataka. Atribut koji treba jednoznano da odredi svaki red u ovoj tabeli je broj rauna (RN#) te e to biti atribut sa primarnim kljuem. U okviru ovog entiteta, redoslijed atributa nije bitan (tabele su obino organizovane tako da im je primarni klju prva kolona, ali tehniki gledano ne mora biti tako). U poetnom sastavu ove tabele ne vodi se rauna ni o redoslijedu redova. Tabela, barem na prvi pogled, opisuje samo jedan entitet. Ukratko, moemo zapoeti proces normalizacije.

16

Slika 4. Entitet Rauni sa atributima

5.1. Prva normalna formaPrva normalna forma (1NF) odnosi se na eliminisanje ponavljanja grupa podataka i obezbjeivanje nedjeljivosti podataka (podaci su samostalni i nezavisni). Po definiciji entitet je u prvoj normalnoj formi ako svi njegovi atributi imaju samo atomske (nedjeljive) vrijednosti. U sledeoj tabeli vidimo kako neki podaci mogu da izgledaju i u tu svrhu sam izbacio neke kolone kako bi svi podaci bili vidljivi, ne gubei poentu:Tabela 7. Tabela (entitet) Rauni sa konkretnim vrijednostima atributa RN# (PK) 100 Datum Kupac# Naziv Adresa Stavke

26/11/10

512

Todor doo

Prvomajska 4

7, Klijeta, 1kom, 9.5KM; 4, ica, 10kg, 30KM; 9, Elektrode, 1pak, 24KM 3, Builica, 1kom, 73KM 11, Osigura, 6kom, 18KM; 5, Prekida, 4kom, 16.8KM; 4, ica, 30kg, 90KM 9, Elektrode, 2pak, 48KM

101 102

26/11/10 26/11/10

32 288

Raketa ad Stela

Radnika 45 Sportska bb

103

27/11/10

512

Todor doo

Prvomajska 4

Posmatrajui i analizirajui ovu tabelu moemo doi do sledeih zakljuaka: Nepotrebno smo uskladitili iste podatke vie puta (npr. svi podaci koji su vezani za kupca e se ponoviti kad god taj isti kupac neto kupi). Ponavljanje podataka znai da e se vea koliina podataka prenositi preko magistrale podataka i kroz mreu. Ovo moe znaajno uticati na performanse. Postoji opasnost da se podaci koji se ponavljaju u redovima budu pogreno unijeti te bi se tako stvorio paradoks da dva razliita kupca imaju istu ifru. Ako elimo da u upitu upotrijebimo informacije iz kolone koja sadri kombinaciju podataka, onda najprije moramo da definiemo nain na koji bi ralanili podatke u toj koloni, a to je izuzetno spor proces. Npr. elimo da saznamo koliko je pojedinih artikala prodato u odreenom vremenskom periodu. 17

Postoji nekoliko stvari u ovoj tabeli kojima treba da se bavimo ako namjeravamo da je normalizujemo. Iako imamo primarni klju koji je funkcionalan postoje problemi u obe oblasti koje su vane za prvu normalnu formu. Imamo grupe podataka koje se ponavljaju (informacije o kupcu). Te podatke treba prebaciti u zasebnu tabelu. Kolona Stavke ne sadri podatke koji su nedjeljivi. Prvo emo iz tabele izbaciti nekoliko kolona koje se tiu podataka o kupcima i izdvojiti ih u novi entitet Kupci:Tabela 8. Tabela Rauni RN# (PK) 100 Datum Kupac# (FK) 512 Stavke

26/11/10

7, Klijeta, 1kom, 9.5KM; 4, ica, 10kg, 30KM; 9, Elektrode, 1pak, 24KM 3, Builica, 1kom, 73KM 11, Osigura, 6kom, 18KM; 5, Prekida, 4kom, 16.8KM; 4, ica, 30kg, 90KM 9, Elektrode, 2pak, 48KM

101 102

26/11/10 26/11/10

32 288

103

27/11/10

512

Tabela 9. Kupci Kupac# (PK) 512 32 288 Naziv Adresa Grad

Todor doo Raketa ad Stela

Prvomajska 4 Radnika 45 Sportska bb

Banja Luka Prijedor Banja Luka

Nova tabela mora imati primarni klju. Ovde se namee atribut Kupac# koji je logian kandidat za primarni klju (iz tog razloga je i kreiran ovaj atribut). Kandidat moe da bude i naziv kupca, ali zbog mogunosti da postoji dva ili vie kupaca sa istim imenom, ovog kandidata ne moemo uzeti u razmatranje. Iako smo kupce izdvojili u posebnu tabelu, i dalje moramo zadrati kolonu Kupac# u tabeli Rauni. koja predstavlja referencu na podatke u tabeli Kupci. Kasnije kada budemo pravili reference praviemo ogranienja u vidu spoljnog kljua, koje e zahtjevati da svi rauni imaju ispravne brojeve kupaca.

18

Kao to vidimo u tabeli 3, nemamo vie dva ista reda vezana za kupca "Todor doo". Tako smo eliminisali informacije koje se ponavljaju. Ovim razdvajanjem jedne tabele na dvije smo rijeili problem ponavljanja podataka. Jo je potrebno postii nedjeljivost podataka. To znai da kolonu Stavke trebamo razbiti na vie kolona. Uz to emo dodati jo jednu kolonu u ovoj tabeli a to je Jedinina cijena. Kao to vidimo iz tabele 10. kada ralanimo informacije, primarni klju vie ne odreuje redove jednoznano. Redovi su i dalje jedinstveni ali primarni klju vie nije adekvatan.Tabela 10. Ralanjivanje na nedjeljive podatke RN# Datum Kupac# (FK) 512 512 512 32 288 288 288 512 Artikal# Naziv Kolicina Cijena Iznos

100 100 100 101 102 102 102 103

26/11/10 26/11/10 26/11/10 26/11/10 26/11/10 26/11/10 26/11/10 27/11/10

7 4 9 3 11 5 4 9

Klijeta ica Elektrode Builica Osigura Prekida ica Elektrode

1 10 1 1 6 4 30 2

9.5 3 24 73 3 4.2 3 24

9.5 30 24 73 18 16.8 90 48

To moemo rijeiti dodavanjem rednih brojeva svakoj stavki i to razliitih brojeva u okviru istog rauna, pa tako opet moemo jednoznano odrediti redove.Tabela 11. Tabela u prvoj normalnoj formi RN# (PK) 100 100 100 101 102 102 102 103 RB (PK) 1 2 3 1 1 2 3 1 Datum Kupac# (FK) 512 512 512 32 288 288 288 512 Artikal# Naziv Kolicina Cijena Iznos

26/11/10 26/11/10 26/11/10 26/11/10 26/11/10 26/11/10 26/11/10 27/11/10

7 4 9 3 11 5 4 9

Klijeta ica Elektrode Builica Osigura Prekida ica Elektrode

1 10 1 1 6 4 30 2

9.5 3 24 73 3 4.2 3 24

9.5 30 24 73 18 16.8 90 48

19

Ovdje ve imamo ispunjene kriterijume za prvu normalnu formu. Nemamo grupe podataka koje se ponavljaju i sve kolone su nedjeljive. Jo uvijek treba da odluimo ta emo sa podacima koji treba da se ponavljaju u okviru kolone (zato to su isti za sve redove tog primarnog kljua).

5.2. Druga normalna formaIdemo korak dalje i sledea faza je prelazak na drugu normalnu formu (2NF). Prije nego to napravimo ovaj korak prisjetimo se sa funkcionalne zavisnosti. Ako u relaciji R vrijednost atributa A jednoznano odreuje vrijednost atributa B, onda je atribut B funkcionalno zavisan o atributu A. Piemo: A B. to to znai? Ako postoji vie redova (n-torki) sa istom vrijednou A tada i atribut B mora biti takoe isti. Svaki atribut relacije je funkcionalno zavisan od kljua. Ako je neki atribut B iz R funkcionalno zavisan od sloenog atributa A, a nije funkcionalno zavisan ni od jednog pravog podskupa od A, tada kaemo da je on potpuno funkcionalno zavisan od A. U suprotnom radi se o parcijalnoj funkcionalnoj zavisnosti. Dolazimo do pravila koja ima druga normalna forma: Tabela mora da ispunjava pravila za prvu normalnu formu. Svaka kolona mora da zavisi od cijelog kljua Normalizacija je proces tipa slaganja blokova ne moemo postaviti drugi blok ako prethodno nismo postavili prvi blok. Otuda pravilo da tabela mora da bude u prvoj normalnoj formi prije nego se pristupi primjenjivanju pravila za drugu normalnu formu. U naoj tabeli koju smo doveli u 1NF imamo primarni klju koji je sloen i sastoji se od dva atributa (RN# i RB). Taj par atributa jednoznano odreuje svaku n-torku to nije sporno. Meutim, postavlja se pitanja da li svaka kolona potpuno zavisi od cijelog kljua, to je uslov koji mora da bude ispunjen da bi tabela bila u drugoj normalnoj formi. Odmah vidimo da to nije sluaj. Kolona Kupac#, npr., je funkcionalno zavisna od dijela primarnog kljua (RN#) i piemo: RN# Kupac#. Takoe moemo da piemo i RN# Datum#. Te funkcionalne zavisnosti su uoljive jer za istu vrijednost atributa RN# imamo iste vrijednosti atributa Kupac#, odnosno atributa Datum#. Meutim atribut RN# je dio primarnog kljua, a da bi tabela bila u drugoj normalnoj formi atributi moraju da zavise od cjelokupnog kljua a ne samo od njegovog dijela. Ovde vidimo da navedeni atributi ne zavise i od drugog dijela kljua (RB), odnosno: RB Kupac#; RB Datum. Imamo ovde i atribute koji zavise od cijelog kljua: (RN#, RB) Artikal#, (RN#, RB) Naziv. Dakle ovde imamo situaciju da nam svi atributi ne zavise od cijelog kljua. Nego imamo atribute koji zavise od dijela kljua. Da bi ovo rijeili potrebno je uvesti jo jednu tabelu. Ovdje nailazimo na koncept tabele zaglavlja i tabele detalja. Iako se na prvi pogled ini da ova tabela predstavlja jedan entitet, to 20

nije sluaj. Raun u stavrnosti jeste jedan dokument, ali i na tom dokumentu se ne unosi broj rauna i datum za svaki prodati artikal, nego su ti podaci jednom uneseni (zaglavlje rauna), a stavke (detalji) rauna se unose u posebnom dijelu rauna. Ponovo emo ralaniti tabelu Rauni tako to emo napraviti dvije zasebne tabele ostaviti vezu izmeu njih u vidu stranog kljua. Poeemo od tabele detalja jer ona zadrava najvei broj kolona. Tu novu tabelu emo zvati RacunDetaljiTabela 12. Tabela RacunDetalji RN# (PK, FK) 100 100 100 101 102 102 102 103 RB (PK) 1 2 3 1 1 2 3 1 Artikal# Naziv Kolicina Cijena Iznos

7 4 9 3 11 5 4 9

Klijeta ica Elektrode Builica Osigura Prekida ica Elektrode

1 10 1 1 6 4 30 2

9.5 3 24 73 3 4.2 3 24

9.5 30 24 73 18 16.8 90 48

Zatim, definiemo tabelu zaglavlja i zadraemo naziv Rauni.Tabela 13. Tabela Rauni RN# (PK) 100 101 102 103 Datum Kupac#

26/11/10 26/11/10 26/11/10 27/11/10

512 32 288 512

Sada imamo drugu normalnu formu. Sve kolone zavise od cjelokupnog kljua

5.3. Trea normalna formaTrea normalna forma bavi se zahtjevima koji se odnose na to da kolone u tabeli ne treba da zavise od bilo kog atributa, ve od kljua. Pravila za to su: Tabela mora biti u drugoj normalnoj formi. Nijedna kolona ne moe da zavisi od bilo koje druge kolone koja nije klju. 21

Tabela ne moe sadravati izvedene podatke. Poto ve imamo drugu normalnu formu, trebamo se pozabaviti sa druga dva pravila. Prije toga trebamo se upoznati sa pojmom tranzitivna zavisnost. Neka su X, Y, Z skupovi atributa relacije R(A 1 , . . . , A n ). Kae se da skup atributa Z tranzitivno zavisi od X ako vai X Y, Y X, Y Z. Takve atribute, zajedno sa skupom atributa od kojeg funkcionalno zavise, treba izdvojiti u posebnu tabelu. Drugim rijeima, ako imamo u tabeli kolone koje ne zavise direktno od primarnog kljua, nego zavise od atributa ili skupa atributa koji nisu primarni klju, onda emo ih izdvojiti u drugu tabelu, a u polaznoj tabeli ostaviti atribut koji e preuzeti ulogu stranog kljua, kako bi te dvije tabele bile u vezi, odnosno kako bi sauvali integritet podataka. Ako posmatramo tabelu RacunDetalji vidjeemo da kolone Naziv (artikla) i Cijena ne zavise direktno od primarnog kljua (RN#, RB) nego tranzitivno preko atributa Artikal#. U ovom sluaju bi atribut Artikal# bio poveznica izmeu dvije nove tabele. Na prvi pogled u novu tabelu trebamo preseliti atribute Artikal#, Naziv, Cijena. Meutim, to se tie cijene ovo je djelimino tana konstatacija. Moramo imati u vidu da jednom formiran dokument u kome navodimo cijenu artikala ne moemo mijenjati svaki put kad se cijene pojedinih artikala promijene. U tom smislu atribut Cijena ima dvojak karakter. Atribut Cijena koji e biti u novoj tabeli Artikli zavisie od ifre artikla (Artikal#) i odraavae trenutnu vrijednost. Atribut Cijena koji moramo zadrati i u tabeli RacunDetalji zavisie od primarnog kljua u ovoj tabeli i predstavljae vrijednost ovog atributa u trenutku dodavanja redova u ovu tabelu. Neminovno je da u budunosti doe do izmjena cijena (inflacija, popusti, poskupljenja), ali raun koji je nastao prije tih izmjena ima prethodne cijene artikala. Vrijednosti atributa Iznos su izvedene iz postojeih atributa Kolicina i Cijena i po pravilu ih ne trebamo uvati u tabeli. Da bi zadovoljili ovo pravilo normalizacije trebamo izbaciti kolonu Iznos iz tabele RacunDetalji, a do iznosa moemo uvijek doi mnoenjem vrijednosti Kolicina i Cijena u tekuem redu. Anomalija unoenja u tabelu RacunDetalji ogleda se u nemogunosti unoenja informacija o novom artiklu dok se prethodno ne proda. Anomalija brisanja ogleda se u injenici da ako obriemo detalje rauna na kome se nalaze podaci o jedinom prodatom artiklu, onda gubimo i podatke o tom artiklu. Tako, brisanje detalja sa rauna 101 znai da emo izbrisati cijeli red a u njemu i jedine podatke o artiklu Builica. Anomalija auriranja ogleda se u nemogunosti nezavisnog auriranja vrijednosti atributa Naziv (artikla). Na primjer, ako je potrebno promijeniti naziv artikla sa ifrom 4, iz "ica" u "ica 2mm", onda se taj podatak ne moe promijeniti ("aurirati") u jednom redu tabele, ve se to mora uiniti u svakom redu koji se odnosi na artikal sa ifrom 4, tj. onoliko puta koliko je taj artikal puta prodat. Konano, od tabele RacunDetalji pravimo dvije: RacunDetalji i Artikli.

22

Tabela 14. Tabela RacunDetalji RN# (PK, FK) 100 100 100 101 102 102 102 103 RB (PK) 1 2 3 1 1 2 3 1 Artikal# (FK) 7 4 9 3 11 5 4 9 Kolicina Cijena

Tabela 15. Tabela Artikli Artikal# (PK) 7 4 9 3 11 5 Naziv Cijena

1 10 1 1 6 4 30 2

9.5 3 24 73 3 4.2 3 24

Klijeta ica Elektrode Builica Osigura Prekida

9.5 3 24 73 3 4.2

Izvedeni podaci predstavljaju jedan od naina na koji se najee "denormalizuju" podaci. Razlog zbog kojeg vrimo denormalizaciju je brzina. Izvravanje upita koji sadri reenicu WHERE Iznos > 100 je mnogo bre od upita koji izvrava reenicu WHERE Kolicina * Cijena > 50. Danas kada imamo dovoljnu koliinu jeftine spoljne memorije, vei znaaj pridajemo brzini rada a na utrb vee potronje memorije za skladitenje podataka. Ponekad je potrebno primjeniti neto to vie lii na hibridni pristup tako to emo koristiti izraunate kolone i prepustiti SQL Serveru uvanje zbira ili proizvoda dvije kolone. Ako je to kolona koja je veoma vana sa stanovita performansi (izvrava se dosta upita koji se zasnivaju na filtriranju ove kolone), moda bi trebalo dodati indeks toj koloni sa izraunatom vrijednou. Znaaj ovoga je to e se izvedeni podaci stvarati pri unosu i uskladititi u indeks, a nakon toga se koristi prethodno izraunata kolona to zaista moe biti prilino brzo. Ali, da stvar ne bude tako jednostavna, imamo i jedan razlog protiv. Nepotrebni atributi koji se uvaju u bazi podataka i koji se mogu izraunati iz postojeih nepotrebno optereuju mreu (propusni opseg) pri prenosu velikih koliina podataka izmeu servera ili izmeu servera i radnih stanica. Ako se upiti u kojima je potrebno izvriti raunanja rijetko koriste, onda ipak treba razmisliti o tome da se u bazi ne uvaju izraunate vrijednosti.

5.4. Boyce-Codd-ova normalna forma (BCNF)Tabele u prethodnim primjerima su potpuno normalizovane, tako da se na tom primjeru ne moe pokazati Boyce-Codd-ova normalna forma. U praksi se moe nai sluajeva kada je tabela normalizovana do tree normalne forme, ali ipak pokazuje anomalije pri auriranju. U suprotnom sluaju ako relacija jeste u BCNF onda je ona sigurno u 2NF i 3NF. Znai BoyceCodd-ova normalna forma kao preduslov ne zahtjeva da relacija bude u 2NF i 3NF jer BCNF ukljuuje ove dvije normalne forme. 23

Kada govorimo o BCNF obino prethodno definiemo pojam determinante. Determinanta je atribut (ili kombinacija atributa) o kojem je neki drugi atribut potpuno funkcionalno zavisan. Relacija je u Boyce-Codd-ovoj normalnoj formi ako je svaka njezina determinanta ujedno i kandidat za klju. Primjer za relaciju koja jeste u treoj normalnoj formi ali nije u BCNF moemo konstruisati tako da imamo dva kandidata kljua, oba kljua su sloena i preklapaju se u bar jednom atributu. Na primjer neka na fakultetu jedan kurs predaje vie nastavnika, ali svaki nastavnik predaje samo jedan kurs. Svaki student upisuje vie kurseva, ali ima samo jednog nastavnika za zadani kurs. Situacija se moe opisati relacijom:Tabela 16. Relacija UPISAO

(PK) (PK)

BrIndeksa ImeNastavnika BrKursa

Ova relacija nije ni u 2NF, jer postoji parcijalna zavisnost: ImeNastavnika ali moemo drugaije izabrati primarni klju:Tabela 17. Relacija UPISAO (3NF)

BrKursa,

(PK) (PK)

BrIndeksa BrKursa ImeNastavnika Sad je relacija u 3NF, ali nije i u BCNF jer postoji zavisnost: ImeNastavnika BrKursa,

a pritom ImeNastavnika nije kandidat za klju. Zbog odstupanja od BCNF nastaju sline anomalije kao kod odstupanja od 3NF. Ne moemo evidentirati injenicu da zadani nastavnik predaje zadani kurs, sve dok bar jedan student ne upie taj kurs kod tog nastavnika. Takoe, veza nastavnika i kursa je zapisana s velikom redundancijom, onoliko puta koliko ima studenata, to oteava auriranje. Ako svi studenti odustanu, brie se evidencija da zadani nastavnik predaje zadani kurs. Rjeenje problema je, kao i prije, razbijanje relacije na dvije. Prekida se nepoeljna funkcionalna zavisnost. Klasa ( BrIndeksa, ImeNastavnika ), Predaje ( ImeNastavnika, BrKursa ) .

24

Sad su obe relacije u BCNF. Problemi s relacijom Upisao izbjegli bi se da smo ve u fazi modeliranja entiteta i veza uoili da zapravo imamo posla s dvije nezavisne binarne veze: (N : M) veza izmeu Student i Nastavnik, te (1 : N) veza izmedu Kurs i Nastavnik. Ternarna veza je tada suvina.

5.5. etvrta normalna forma i vieznane zavisnostietvrtu normalnu formu najlake je opisati pomou primjera. Ako posmatramo relaciju koja prikazuje vezu izmeu preduzea, proizvoda i zemalja: Izvozi ( Preduzee, Proizvod, Zemlja ) .Tabela 18. Relacija Izvozi

PK PK PK

Preduzee Proizvod Zemlja

Jedna n-torka oznaava da zadano preduzee zadani proizvod izvozi u zadanu zemlju. Relacija moe u jednom trenutku izgledati kao u tabeli. Lagano je provjeriti da je relacija u BCNF. U nastavku uzimamo da vrijedi pravilo: im preduzee izvozi u neku zemlju, ono odmah izvozi sve svoje proizvode u tu zemlju. Tada relacija oigledno sadri veliku dozu redundancije. Na primjer, da bi dodali novi proizvod IBM-a, moramo upisati n-torku za svaku zemlju u koju IBM izvozi. Slino, ako HP pone izvoziti u Kinu, morae se ubaciti posebna n-torka za svaki njegov proizvod.Tabela 19. Relacija Izvozi (nije u etvrtoj NF)

Predzuee Proizvod (PK) (PK) IBM IBM IBM IBM IBM IBM HP Desktop Desktop Desktop

Zemlja (PK) Francuska Italija Velika Britanija

Mainframe Francuska Mainframe Italija Mainframe Velika Britanija Desktop Francuska 25

HP HP HP HP HP Fujitsu Fujitsu

Desktop Desktop Server Server Server

panija Irska Francuska panija Irska

Mainframe Italija Mainframe Francuska

Redundancija e se eliminisati ako zamijenimo polaznu relaciju Izvozi s dvije manje relacije Radi i Prodaje:Tabela 20. Relacija Radi

(PK) (PK)

Preduzee Proizvod

Tabela 21. Relacija Prodaje

(PK) (PK)

Preduzee Zemlja

Podacima iz tabele 16 tada odgovaraju podaci iz tabela 20 i 21Tabela 22. Tabela Radi podaci (etvrta normalna forma)

Preduzee (PK) IBM IBM HP HP Fujitsu

Proizvod (PK) Desktop Mainframe Desktop Server Mainframe

26

Tabela 23. Tabela Prodaje podaci (etvrta normalna forma)

Preduzee (PK) IBM IBM IBM HP HP HP Fujitsu Fujitsu

Zemlja (PK) Francuska Italija Velika Britanija Francuska panija Irska Italija Francuska

Dosadanja pravila normalizacije nam ne pomau da eliminiemo redundanciju u relaciji Izvozi. To je zato to redundancija nije bila uzrokovana funkcionalnim zavisnostima, ve tzv. vieznanim zavisnostima Preduzee Proizvod , Preduzee Zemlja . Zadana je relacija R(A,B,C). Vieznana zavisnost A B vrijedi ako: skup B vrijednosti koje se u R pojavljuju uz zadani par (A-vrijednost, C-vrijednost) zavisi samo od A-vrijednosti, a ne i od C-vrijednosti. Ista denicija primjenjuje se i kad su A, B i C sloeni atributi (dakle skupovi atributa). U gornjem primjeru, skup zemalja u koje zadano preduzee izvozi zadani proizvod zavisi samo od preduzea a ne i od proizvoda. Slino, skup proizvoda koje zadano preduzee izvozi u zadanu zemlju zavisi samo od preduzea a ne od zemlje. Relacija R je u etvrtoj normalnoj formi (4NF) ako vrijedi: kad god postoji vieznana zavisnost u R, na primjer A B, tada su svi atributi od R f unkcionalno zavisni od A. Ekvivalentno, R je u 4NF ako je u BCNF i sve vieznane zavisnosti u R su zapravo funkcionalne zavisnosti. U naoj relaciji Izvozi , ni jedna od uoenih vieznanih zavisnosti nije funkcionalna zavisnost. Znai, Izvozi nije u 4NF i zato je treba rastaviti na Radi i Prodaje (koje jesu u 4NF). Odstupanje od 4NF opet moemo tumaiti kao greku u modeliranju entiteta i veza. Posmatrana re