SVEUILITE U ZAGREBU FAKULTET ORGANIZACIJE I INFORMATIKE VARADIN

Tomislav Jeli

OBJEKTNO-RELACIJSKE BAZE PODATAKA: Primjer i uspredba s relacijskom bazom podataka

Varadin, 2012.

SVEUILITE U ZAGREBU FAKULTET ORGANIZACIJE I INFORMATIKE VARADIN

Tomislav Jeli Redoviti student Broj indeksa: 39063/10-R Smjer: Informacijski sustavi Preddiplomski studij

OBJEKTNO-RELACIJSKE BAZE PODATAKA: Primjer i uspredba s relacijskom bazom podataka

Mentor: Prof. dr. sc. Mirko Malekovi

Varadin, travanj 2012.

SadrajUvod................................................................................................................................................ 1 Primjer objektno-relacijske baze podataka i usporedba s relacijskom bazom podataka ................ 2 Zakljuak......................................................................................................................................... 9 Literatura ....................................................................................................................................... 10

I

UvodU iduim stranicama emo se upoznati s konceptom objektno-relacijske baze podataka s tim da e se u ovom dijelu rada najvea pozornost ipak prikloniti praktinom dijelu, tj. samom oblikovanju i usporedbi s mogunostima relacijske baze podataka. No, najprije emo se upoznati sa samim konceptom objektno-relacijske baze podataka. Kao to i samo ime govori radi se o bazi podataka koja je slina relacijskoj, ali posjeduje i neke znaajke objektno-orijentiranih modela kao to su objekti ili recimo nasljeivanje. Mogli bismo rei da je sam cilj ovakvog tipa baze podataka je da zatvori rupu izmeu objektno-orijentirane baze podataka i relacijske baze podataka. Naime, objektno-orijentirane baze podataka koriste informacije koje su reprezentirane kao objekti. Razvitak objektno-relacijske baze podataka se vee uz rane devedesete godine prolog stoljea. U sutini je to bio rezultat istraivanja koje je ispitivalo proirenje klasine relacijske baze podataka upotrebom nekih objektnih koncepata. Najvei uspjeh je ipak postignut projektom Postgres. Navedeni projekt je izveden na poznatom sveuilitu Berkley u SAD-u. Oni su razvili PostgreSQL koji e biti koriten kao sustav s kojim e biti raeni primjeri u radu. Do kraja desetljea (do kraja 1990-tih) PostgreSQL se razvio kao vodei sustav na ovom podruju. Veina poetnih ideja je unesena u SQL:1999. SQL:1999 koji je poznat kao i SQL3 je revizija SQL standarda. Sad smo objasnili same poetke cijelog sustava. U daljnjem radu emo se bazirati na primjeni mogunosti koje nam nudi objektno-relacijska baza podataka. Pokazat emo usporedbe s relacijskom, stvarati funkcije i sl.

1

Primjer objektno-relacijske baze podataka i usporedba s relacijskom bazom podatakaKreemo s pravim primjerima i prikazom dobrih strana objektno-relacijske baze podataka te njenu usporedbu sa samom relacijskom. Zapoeti emo tako to emo kreirati novu bazu podataka. Napominjem da se u izradi rada koristi PosgreSQL 9.1.

create database seminar; Kreirali smo dakle nau bazu u koju emo pisati tablice i prikazivati primjere. Sad trebamo se prikljuiti na danu bazu i poeti izradu.

/connect seminar;

A to smo napravili preko napisane naredbe. Na primjer e biti jednostavna baza koja e sadravati radnike nekog poduzea. Svaki radnik je osoba koja ima svoje ime i prezime pa emo na tom primjeru prikazati jednu znaajku koja se naziva kreiranje tipa. U ovom sluaju emo kreirati tip osoba koja e biti sastavljena od ime i prezime. Za kreiranje tipa koristimo naredbu CREATE TYPE te navodimo od ega se taj tip sastoji. Kako to sad zvui prilino apstraktno, navest emo danu naredbu pa emo detaljnije objasniti o emu se radi.

CREATE TYPE osoba AS (ime VARCHAR(20),prezime VARCHAR(20)); S CREATE TYPE iskazujemo naredbu za stvaranjem tipa, zatim upisivamo njen naziv koji e kasnije biti koriten pri pozivu. U ovom sluaju to je osoba. Nadalje AS(PODACI...) nam govore kakav emo tip stvoriti, as-kao, a to se odnosi na skup razliitih atributa koje spajamo u jedan. U ovom sluaju alfanumeriku varijablu ime i prezime koje su obje duljine 20 znakova postavljamo kao dijelove osobe.

2

Stvoriti emo naravno i tablicu u koju e se stavljati svi radnici koji rade u poduzeu. Kako smo definirali tip osoba nee biti potrebno pri izradi tablice postaviti da su ime i prezime zasebni atributi ve e oni biti zastupljeni unutar tipa osoba.

CREATE TABLE zaposlenici( radnik osoba); Stvorili smo dakle tablicu zaposlenici u koju emo kasnije unositi radnik. Radnik, kao atribut je tipa osoba. Na koncu se dobije sljedeca tablica u ispisu tablica.

Schema | Name | Type | Owner ----------+-------------+--------+---------public | zaposlenici| table | postgres Mi bismo dakle u naem primjeru eljeli stvoriti tablicu radnika bez obzira na to gdje se oni upisali, tj. da li postoji neka druga tablica u koju se to upisuje. Sad emo primjetiti jednu razliku izmeu nae objektno- relacijske baze i onoga to bismo radili u relacijskoj bazi. U relacijskoj bazi bi stvarali primarni klju i povezivali ga sa svim ostalim tablicama u kojima bi se eventualno unosio novi radnik. No, kao to se vidi mi ovdje nismo upotrijebili nikakav primarni klju niti smo stvarali vanjske kljueve kakve bi imali kod relacijskih baza u drugim tablicama. Postavlja se pitanje kako emo to ovdje izvesti. Upotrijebiti emo onaj dio objektnog to ga moemo uzeti kao rjeenje. Posluit emo se nasljeivanjem. U ovom sluaju emo napraviti drugu tablicu u kojoj e pisati u kojem odjelu netko radi i koja mu je plaa, a atribute ime i prezime emo nasljediti iz tablice zaposlenici. Prvo emo opet pokazati naredbu a onda objasniti kako ista radi.

CREATE TABLE zaposlenik_odjel(identifikacija VARCHAR(20),odjel VARCHAR (20),placa INTEGER) INHERITS (zaposlenici);

3

Stvorili smo tablicu zaposlenik_odjel u kojoj emo vriti unos zaposlenika prema odjelu. Sastoji se od identifikacije, odjela i plae. Klju nasljeivanja u tablici je oznaka INHERITS koja govori da se neto treba naslijediti a u zagradama se oznaava koja tablica. U ovom sluaju je to tablica zaposlenici koja sadri tip osoba a on je sastavljen od ime i prezime. Sad moramo napomenuti kako u vlastite tipove unos nije jednak kao u standardne (VARCHAR, INTEGER...) ve je situacija samo malo drugaija. Navesti emo primjere unosa. Prvo emo poeti u jednostavnu tablicu zaposlenici:

insert into zaposlenici values (('ime1','prezime1')); insert into zaposlenici values (('ime2','prezime2'));

Vidimo kako se u naem tipu koji se sastoji od dva dijela stavljaju dvoje zagrade. Prve su radi unosa koji imamo kao i obino, dok ove unutarnje slue kako bi unijeli za dani tip podatka. Kako se trae dvije stvari ime i prezime navodimo iste te na kraju zatvaramo zagradu za unose. Sad emo odraditi upise i za zaposlenik_odjel.

INSERT INTO zaposlenik_odjel VALUES (('ime3','prezime3'),'123a','odjel _1',5000); INSERT INTO zaposlenik_odjel VALUES (('ime4','prezime4'),'123b','odjel _1',5500); INSERT INTO zaposlenik_odjel VALUES (('ime5','prezime5'),'123c','odjel _2',7500); INSERT INTO zaposlenik_odjel VALUES (('ime6','prezime6'),'123d','odjel _2',4500); Kako se vrilo nasljeivanje, nasljeeni atributi dolaze prvi po redu tako su atributi redom osoba, identifikacija, odjel, plaa. Opet, kako je reeno poto je prvi atribut osoba za njega moramo unos vriti posebno, tj. unutar jo jednih zagrada jer se sam sastoji od dva dijela, dok ostatak napravimo po standardnim pravilima unosa. Sad nas zanima naravno ispisi unosa u tablicama, to je ono zato smo sve ovo i radili. Sad emo ih pogledati i prokomentirati.

select * from zaposlenik_odjel;

4

radnik

| identifikacija | odjel

| placa

--------------------+----------------+------------+-------(ime3,prezime3) | 123a (ime4,prezime4) | 123b (ime5,prezime5) | 123c (ime6,prezime6) | 123d | odjel_1 | 5000 | odjel_1 | 5500 | odjel_2 | 7500 | odjel_2 | 4500

Oito je da nam je ispis dao samo one podatke koje smo unijeli, ali to se dogodilo s tablicom zaposlenici ?

select * from zaposlenici;

radnik ----------------(ime1,prezime1) (ime2,prezime2) (ime3,prezime3) (ime4,prezime4) (ime5,prezime5) (ime6,prezime6)

Ovdje vidimo da smo kao rezultat dobili i rezultate unosa u tablicu koja je imala naslijedstvo. Ovo sve je bilo izvrstan nain da se pokae mogunost naslijeivanja. Opet govorim da smo radili samo relacijske da bismo morali raditi vanjske kljueve i primarne te dodatne argumente upisivati, dok to ovdje nije sluaj. Naslijeivanjem atributa osoba smo postigli to da nam se uvijek u jednoj tablici pune svi ti radnici koje smo unijeli. Tako bi, recimo mogli najjednostavnije doi do popisa svih djelatnika nekog poduzea ili slino, a i samo postupak je dosta jednostavniji nego iroko pisanje koda i upita u samoj relacijskoj bazi podataka. Jo emo obraditi i kreiranje funkcija kao jednu od znaajki objektno-relacijske baze podataka. Za poetak emo kreirati funkciju koja nee primati nikakve argumente a kao rezultat e nam vratiti sumu plaa po odjelima koje smo naveli u tablici zaposlenik_odjel.

5

CREATE FUNCTION zbroj_placa_odjel() RETURNS TABLE(odjel TEXT,suma_plac a BIGINT) AS 'SELECT odjel,SUM(placa) FROM zaposlenik_odjel GROUP BY odjel' LANGUAGE SQL; Objasnit emo samu strukturu funkcije. Upotrijebivi kljune rijei CREATE FUNCTION dajemo do znanja sustavu da elimo kreirati funkciju. Nakon toga unosimo eljeno ime funkcije te unutar zagrada argumente koje emo funkciji proslijediti. Valja takoer i odrediti to e nam vraati ta funkcija to oznaavamo sa RETURNS a kako imamo dosta toga moemo rei da nam se vrati kao ureena tablica pa nadodamo TABLE (iako moemo napraviti i bez toga kad bi se vraala samo jedna varijabla). Kako radimo funkciju koja vraa odjel i plae, moramo pravilno ustvrditi tipove podataka. Tako emo za odjel koristiti TEXT jer e tu samo pisati naziv odjela a kod suma_plaa emo koristiti BIGINT jer bi s dosta zaposlenika taj broj mogao poprilino narasti. Nakon dijela AS definiramo ono to ta funkcija izvrava. Moramo paziti da izvedbeni dio funkcije vraa one dijelove koji su zadani iza RETURNS. Kako pokazujemo plau po odjelu radimo SELECT odjel,SUM(placa) s im biramo stupac odjel te zbrajamo plau te to grupiramo prema odjelu zadamo i to preko GROUP BY. Nadalje, postoji vie naina pozivanja funkcija. U radu u prikazati dva dobra, po jedan za svaku funkciju koju objasnim i jedan lo samo za ovu fukciju. Navest emo prvo lo primjer pozivanja ove nae funkcije.

SELECT zbroj_placa_odjel() FROM zaposlenik_odjel; Kako je u samoj funkciji zadano da SELECT bira iz zaposlenik_odjel onda e se u ovom sluaju dana funkcija izvesti 4 puta tj. po jednom za svaki unos u tablici a kako se vraaju dva rezultata (imamo 2 odjela) dobit emo tablicu s 8 redova koja e imati ponavljajue rezultate.

6

zbroj_placa_odjel --------------------(odjel_1,13250) (odjel_2,12000) (odjel_1,13250) (odjel_2,12000) (odjel_1,13250) (odjel_2,12000) (odjel_1,13250) (odjel_2,12000) Kao to smo napomenuli unutar same funkcije nam je odreeno kako se parametri uzmimaju pa je prikladan nain pozivanja funkcije:

select * from zbroj_placa_odjel();

odjel | suma_placa ----------+-----------odjel_1 | 10500 odjel_2 | 12000 Mislim da je na ovom dijelu sve jasno. Dani SELECT uzima sve iz funkcije kao to je zadano i odradi svoj dio. Funkcije emo objasniti jo jednim primjerom, a to e biti funkcija koja unosi sadraj u zaposlenik_odjel.

CREATE OR REPLACE FUNCTION unos(ime TEXT,prezime TEXT,identifikacija TEXT,odjel TEXT,placa INTEGER) RETURNS TABLE(netko osoba,identifikacija TEXT,odjel TEXT,placa INTEGER ) AS 'INSERT INTO zaposlenik_odjel VALUES(($1,$2),$3,$4,$5); SELECT * FROM zaposlenik_odjel;' LANGUAGE SQL;

7

Ovdje smo isto radi primjera uzeli opciju CREATE OR REPLACE koja stvara ili mjenja postojeu funkciju. Kako tablica zaposlenik_odjel prima argumente tipova podataka osoba (koja se sastoji od dva dijela), identifikacija, odjel i plaa morali smo se pobrinuti da funkcija unos koristi isto toliko argumenata pri svom pozivu. Takoer je napravljeno da se nakon unosa prikae cijeli sadraj tablice tako da se odmah vidi da li je posao uspjeno obavljen. Sve operacije koje se dogaaju iza AS moraju biti u jednostrukim navodnicima ' ', tako se zna to se to tono treba izvesti funkcijom. Unutar unosa (($1,$2),$3,$4,$5) prestavljaju redni broj argumenta kojeg uzima funkcija. Ostalo se radi kao u tipinom unosu u relacijsku bazu podataka. Primjerice $1 odgovara ime TEXT, dok $4 odgovara odjel TEXT. Nakon zavretka dijela s unosom stavljamo ; te umeemo dio koji prikazuje stanje tablice koji e se naravno odnositi na stanje nakon samog unosa tj. pokretanja funkcije. Na kraju zadanih naredbi zatvaramo jednostruke navodnike. Na ovom primjeru emo pokazati jo jedan nain poziva funkcije.

SELECT unos('ime7','prezime7','123i','odjel_1',2750);

unos ------------------------------------------------("(ime3,prezime3)",123a,odjel_1,5000) ("(ime4,prezime4)",123b,odjel_1,5500) ("(ime5,prezime5)",123c,odjel_2,7500) ("(ime6,prezime6)",123d,odjel_2,4500) ("(ime7,prezime7)",123i,odjel_1,2750) Kao to se iz rezultata vidi pravilan unos rezultira pozitivnim ishodom te se ova funkcija dalje moe koristiti za unoenje u tablicu zaposlenik_odjel. I dalje se moe vidjeti kako se radi tipa podatka osoba ispis vri s jo jednom zagradom koja predstavlja sloeni tip. S relacijskom bazom podataka biste zauvijek ostali zakljuani sa INSERT INTO, dok u naem sluaju moete to promjeniti u neto to vam se vie svia.

8

ZakljuakU radu smo prikazali neke osnovne znaajke objektno-relacijske baze podataka u smislu da se iste to lake shvate. Usporedbe s relacijskom bazom podataka su najvie bile u tome to se jednostavno prikazivalo dosta toga to one ne mogu izvesti (kao funkcija unos). Nadalje prikazali smo efikasnost kroz cijeli primjer s radnicima. Nije bilo potrebe za stvaranjem vie tablica, a nasljeivanjem poetne tablice dobili smo to da se svaki put kad se napravi neka nova tablica nasljeivanjem iz prve, njeni unosi dodaju. Tako lako dobijete popis odreenih stvari koji imaju svoju osnovu zajedniku. Na primjeru osoba je ipak to bilo najlake za napraviti. Dakako, postoje stvari koje se mogu i dalje napraviti na vie naina. Zbroj plaa se dao jednostavno napraviti u relacijskoj bazi (tj. da smo koristili samo njene funkcije) ,ali radi elje prikaza mogunosti napravljeno je kompliciranije.

9

LiteraturaDate C.J. (2000). An introduction to database systems. Addison -Wesley. Post V.G. Database management systems. McGraw Hill. Gali Z. (2006). Geoprostorne baze podataka. Golden marketing-tehnika knjiga. Graham I. (2001). Object-oriented methods, principles & practice, Third edition. Addison-Wesley. University of Southern California. (2009). Introduction to Object-Relational Database Development. Dostupno 14.03.2012. na http://infolab.usc.edu/csci585/Spring2010/den_ar/ordb.pdf http://www.postgresql.org/docs/9.1/interactive/index.html dostupno 8.4.2012 (prirunici za sve obrade u PostgreSQL-u)

10