Miroslav Naumovski 12999

Modeliranje podataka u vidu objekata

Ne postoje tabele kao kod relacionih Rezultat kombinovanja OO koncepata sa DBMS principima

OO + DBMS principi Baza integrisana unutar PJ, reen problem konzistentnosti PJ i OODBMS koriste isti model podataka Vae sva pravila kao kod objektnih sistema Object Identifier, generie sistem, olakavaju uvanje referenci Transparentan pristup objektima Nemamo potrebe za SQL-om, database client-ima kao to je ADO ili JDBC

Operacije sa bazom kreemo iz database root odgovarajue strukture, i obilazimo je Dva naina korienja objekta, kao privremen, ili ogledalo onoga u bazi OO baze prvenstveno koriste kompanije koje se bave prikazom multimedijalnh sadraja ili koriste CAD dizajn Veina baza radi sa programskim jezicima C++, Java, itd. Druge imaju razvijene svoje

Veina OO jezika nudi neku vrstu query jezika OQL Joining tabela bie nije potreban,prate se pokazivai Iste definicije tipova i u bazi i u aplikaciji Mnoge baze nude versioning, objekat skup verzija sebe Uveana efikasnost podataka u podrujima gde se trai mnogo informacija o neemu Banke Uklonjene greke pri konverziji tabela u objekte i obrnuto, dovoljan razlog zato ih koristiti

Enkapsulacija Tipovii klase Nasleivanje Kompleksni objekti Identitet objekata Proirivost izvedeni tipovi Overriding i overloading Kompletna mogunost raunanja

Perzistentnost Upravljanje sekundarnom memorijom Konkurentnost Mogunost oporavka revovery Podeavanje performansi sistema tuning Mogunost pravljenja ad hoc upita nezavisno od aplikacije, moe i u vidu grafikog interfejsa

Potrebno manje koda kod programiranja Smanjeno stranienje Laka navigacija Bolja kontrola konkurentnosti jer se hijerarhija moe zakljuati Model baziran na stvarnom svetu Radi dobro sa distribuiranim arhitekturama

Manja efikasnost kada su podaci i veze prosti Relacione tabele su prostije Kasno povezivanje late binding moe da uspori brzinu pristupa Trenutno postoji vie razvijenih alata za Relacione nego za OO baze Standardi za RDBMS su stabilniji

Kompozitni objekti i veze, ne vri se join pri svakom upitu, objektni 10 do 1000x bri Hijerarhija klasa Nema potrebe za query jezikom Nema Impedance Mismatch-a Nema primarnih kljueva Jedan model podataka, sve se modelira kao jedan UML dijagram Bolja interakcija sa OO jezicima kao to je C++ Projektant definie strukturu objekata i njihovo ponaanje

Promene u emi zahtevaju rekompajliranje Zavisnost od jezika OODBMS je vezan za odreeni jezik preko specifinog API-ja, to nije sluaj sa RDBMS-om Nedostatak ad-hoc upita ne moemo da vrimo join, jer nemamo tabele.Zato upiti zavise od strukture sistema

session = Session.create(null, null); session.join(); Database db = Database.open("IMdatabase", ObjectStore.UPDATE);

Transaction tr = Transaction.begin(ObjectStore.READONLY); OSHashMap users = (OSHashMap) db.getRoot("IMusers"); UserObject s4l = (UserObject) users.get("Student4Life"); UserObject[] contactList = s4l.getContactList(); System.out.println("This are the people on Student4Life's contact list"); for(int i=0; i < contactList.length;i++) System.out.println(contactList[i].toString()); sessiontr.commit(); db.close();

session.termnate();

Statement sqlQry = conn.createStatement(); ResultSet rset = sqlQry.executeQuery("SELECT fname, lname, user_name, online_status, webpage FROM contact_list, user_table" +"WHERE contact_list.owner_name='Student4Life' and contact_list.buddy_name =

user_table.user_name");
System.out.println("These are the people on Student4Life's contact list"); while(rset.next())

System.out.println("Full Name:" + rset.getString(1) + " " + rset.getString(2) + "

User Name:" + rset.getString(3) + " OnlineStatus:"+ rset.getString(4) + " HomePage URL:" + rset.getString(5));

Dati imena ljudi koji nisu TAs(Tutor Assistants):

SELECT p.name FROM p in People WHERE not ( p.name in SELECT t.name FROM t in TAs )

Koja su imena svih crnih proizvoda?

SELECT distinct p.name FROM products p Where p.color = black

Validno i u SQL-u i u OQL-u ali su rezultati drugaiji.