Postojanost predmeta i Java

Trajnost predmeta ili postojanost pojam je koji često čujete zajedno s pitanjem spremanja objekata u baze podataka. Očekuje se da će postojanost funkcionirati s transakcijskim integritetom i kao takva podliježe strogim uvjetima. (Pogledajte odjeljak Resursi ovog članka za više informacija o obradi transakcija.) Suprotno tome, jezične usluge koje se nude kroz knjižnice i pakete standardnih jezika često nemaju transakcijska ograničenja.

Kao što ćemo vidjeti u ovom članku, dokazi upućuju na to da će postojanje Java-a vjerojatno proizlaziti iz samog jezika, dok će sofisticiranu funkcionalnost baze podataka nuditi dobavljači baza podataka.

Nijedan objekt nije otok

U stvarnom svijetu rijetko možete pronaći objekt koji nema veze s drugim objektima. Objekti su sastavnice objektnih modela . Pitanje trajnosti predmeta nadilazi pitanje trajnosti i distribucije objektnog modela kad jednom primijetimo da su objekti međusobno povezani na temelju međusobnih odnosa.

Relacijski pristup pohrani podataka nastoji agregirati podatke po vrstama. Redovi u tablici predstavljaju fizički agregat objekata iste vrste na disku. Odnosi među objektima tada su predstavljeni ključevima koji se dijele u mnogim tablicama. Iako kroz organizaciju baze podataka relacijske baze podataka ponekad omogućavaju da se tablice koje će se vjerojatno koristiti zajedno smještaju (ili grupiraju ) u istoj logičkoj particiji, kao što je segment baze podataka, one nemaju mehanizam za pohranu odnosa objekata u bazi podataka. Dakle, da bi se konstruirao objektni model, ti se odnosi grade iz postojećih ključeva u vrijeme izvođenja u procesu koji se naziva spajanje tablice . To je isto dobro poznato svojstvo relacijskih baza podataka koje se nazivajuneovisnost podataka . Gotovo sve varijante objektnih baza podataka nude neki mehanizam za poboljšanje performansi sustava koji uključuje složene objektne odnose u odnosu na tradicionalne relacijske baze podataka.

Za upit ili za navigaciju?

Prilikom spremanja objekata na disk suočeni smo s izborom kolociranja povezanih objekata radi boljeg prilagođavanja navigacijskom pristupu ili za pohranu objekata u zbirke nalik tablici koje agregiraju objekte po vrstama kako bi se olakšao pristup zasnovan na predikatima (upiti) ili oboje . Kolokacija objekata u trajnoj pohrani područje je u kojem se relacijske i objektno orijentirane baze podataka uvelike razlikuju. Izbor jezika upita drugo je područje razmatranja. Strukturirani jezik upita (SQL) i njegova proširenja pružili su relacijskim sustavima mehanizam pristupa zasnovan na predikatima. Objektni upitni jezik (OQL) objektna je varijanta SQL-a, koju je standardizirao ODMG, ali podrška za taj jezik trenutno je oskudna. Polimorfne metode nude neviđenu eleganciju u konstruiranju semantičkog upita za zbirku predmeta. Na primjer,zamislite polimorfno ponašanje zaacccountpozvao isInGoodStanding. Može vratiti logičku vrijednost true za sve račune s dobrom reputacijom, a false u suprotnom. Sada zamislite eleganciju upita za prikupljanje računa, gdje inGoodStandingse različito implementira na temelju poslovnih pravila, za sve račune s dobrom reputacijom. To može izgledati otprilike ovako:

setOfGoodCustomers = setOfAccounts.query(account.inGoodStanding());

Iako je nekoliko postojećih baza podataka objekta sposobno obraditi takav stil upita u C ++ i Smalltalk, teško im je to učiniti za veće (recimo, 500+ gigabajta) zbirke i složenije izraze upita. Nekoliko tvrtki s relacijskim bazama podataka, poput Oraclea i Informixa, uskoro će ponuditi drugu sintaksu koja se temelji na SQL-u kako bi postigla isti rezultat.

Postojanost i tip

Objektivni ljubitelj jezika rekao bi da su postojanost i tip ortogonalna svojstva predmeta; odnosno trajni i prolazni objekti iste vrste mogu biti identični jer jedno svojstvo ne bi trebalo utjecati na drugo. Alternativni stav drži da je ustrajnost ponašanje koje podržavaju samo postojani objekti, a određena ponašanja mogu se odnositi samo na postojane objekte. Potonji pristup zahtijeva metode koje upućuju trajne objekte da se pohrane i izvuku iz trajne pohrane, dok prvi pruža aplikaciji besprijekoran prikaz cijelog objektnog modela - često proširujući sustav virtualne memorije.

Kanonikalizacija i jezična neovisnost

Objekti istog tipa u jeziku trebaju se pohraniti u trajnu pohranu s istim rasporedom, bez obzira na redoslijed kojim se pojavljuju njihova sučelja. Procesi pretvaranja izgleda objekta u ovaj uobičajeni format zajednički su poznati kao kanonizacija predstavljanja predmeta. U kompiliranim jezicima sa statičkim tipkanjem (ne Java), objekti napisani na istom jeziku, ali kompilirani u različitim sustavima, trebaju biti identično predstavljeni u trajnoj pohrani.

Proširenje kanonikalizacije obrađuje neovisno o jeziku predstavljanje objekata. Ako se objekti mogu predstavljati na jezik neovisno, bit će moguće da različiti prikazi istog objekta dijele istu trajnu pohranu.

Jedan od mehanizama za postizanje ovog zadatka je uvođenje dodatne razine neizravnosti putem jezika za definiranje sučelja (IDL). Sučelja baze podataka objekata mogu se napraviti putem IDL-a i odgovarajućih struktura podataka. Loša strana veza u IDL stilu je dvostruka: Prvo, dodatna razina indirektnosti uvijek zahtijeva dodatnu razinu prevođenja, što utječe na ukupnu izvedbu sustava; drugo, ograničava upotrebu usluga baza podataka koje su jedinstvene za određene dobavljače i koje bi mogle biti dragocjene za programere aplikacija.

Sličan mehanizam je podrška objektnim uslugama kroz proširenje SQL-a. Prodavači relacijske baze podataka i manji objektni / relacijski dobavljači zagovornici su ovog pristupa; međutim, koliko će ove tvrtke biti uspješne u oblikovanju okvira za pohranu predmeta, tek ćemo vidjeti.

Ali ostaje pitanje: Je li postojanost predmeta dio ponašanja objekta ili je to vanjska usluga koja se objektima nudi putem zasebnih sučelja? Što kažete na zbirke objekata i metode za njihovo postavljanje upita? Relacijski, prošireni relacijski i objektno-relacijski pristupi nastoje zagovarati razdvajanje jezika, dok objektne baze podataka - i sam jezik Java - perzistentnost vide kao svojstvenu jeziku.

Upornost izvorne Java kroz serializaciju

Serijalizacija objekata je mehanizam specifičan za Java jezik za pohranu i preuzimanje Java objekata i primitiva u tokove. Vrijedno je napomenuti da, iako komercijalne biblioteke trećih strana za serializiranje C ++ objekata postoje već neko vrijeme, C ++ nikada nije ponudio izvorni mehanizam za serializaciju objekata. Evo kako se koristi Java serializacija:

// Zapisivanje "foo" u stream (na primjer, datoteku)

// Korak 1. Stvorite izlazni tok

// to jest stvoriti skup za primanje bajtova

FileOutputStream out = novi FileOutputStream ("fooFile");

// Korak 2. Stvaranje ObjectOutputStream

// to jest stvorite crijevo i stavite mu glavu u kantu

ObjectOutputStream os = novi ObjectOutputStream (izlaz)

// Korak 3. Napišite niz i objekt u tok

// odnosno pustimo da tok teče u kantu

os.writeObject ("foo");

os.writeObject (novi Foo ());

// Korak 4. Isperite podatke do odredišta

os.flush ();

U WriteobjectMetoda serializes foo i njegov prijelazni zatvaranje - to jest, svi objekti koji se mogu upućuje od foo u graf. Unutar toka postoji samo jedna kopija serializiranog objekta. Ostale reference na objekte pohranjuju se kao ručke za objekte radi uštede prostora i izbjegavanja kružnih referenci. Serijalizirani objekt započinje s klasom koju slijede polja svake klase u hijerarhiji nasljeđivanja.

// Čitanje objekta iz struje

// Korak 1. Stvorite ulazni tok

FileInputStream u = new FileInputStream ("fooFile");

// Korak 2. Stvorite ulazni tok objekta

ObjectInputStream ins = novi ObjectInputStream (u);

// Korak 3. Moram znati što čitate

Niz fooString = (niz) ins.readObject ();

Foo foo = (Foo) s.readObject ();

Serijalizacija i sigurnost objekata

Prema zadanim postavkama, serializacija piše i čita ne-statička i netrajna polja iz struje. Ova se karakteristika može koristiti kao sigurnosni mehanizam proglašavanjem polja koja se ne mogu serijski pretvoriti u privatna prijelazna. Ako je jedna klasa ne može serijaliziranom na sve, writeObjecta readObjectmetode treba provesti kako bi se baciti NoAccessException.

Postojanost s transakcijskim integritetom: Predstavljanje JDBC-a

Po uzoru na X / Open SQL CLI (sučelje na razini klijenta) i Microsoftove ODBC apstrakcije, povezivanje Java baze podataka (JDBC) ima za cilj pružiti mehanizam povezivanja baze podataka koji je neovisan o osnovnom sustavu upravljanja bazom podataka (DBMS). Da bi postali upravljački programi JDBC-kompatibilni treba podržati barem ANSI SQL-2 API početne razine, koji pruža nezavisnim dobavljačima alata i aplikacijama dovoljno fleksibilnosti za pristup bazi podataka.

JDBC je dizajniran da bude u skladu s ostatkom Java sustava. Dobavljači se potiču da napišu API koji se tipka jače od ODBC-a, što omogućuje veću statičku provjeru tipa u vrijeme sastavljanja.

Evo opisa najvažnijih JDBC sučelja:

  • java.sql.Driver.Manager rukuje učitavanjem upravljačkih programa i pruža podršku za nove veze s bazom podataka.

  • java.sql.Connection predstavlja vezu s određenom bazom podataka.

  • java.sql.Statement djeluje kao spremnik za izvršavanje SQL izraza na datoj vezi.

  • java.sql.ResultSet kontrolira pristup skupu rezultata.

JDBC pokretački program možete implementirati na nekoliko načina. Najjednostavnije bi bilo napraviti vozač kao most do ODBC-a. Ovaj pristup je najprikladniji za alate i programe koji ne zahtijevaju visoke performanse. Proširiviji dizajn uveo bi dodatnu razinu indirektnosti na DBMS poslužitelj pružanjem JDBC mrežnog pokretačkog programa koji pristupa DBMS poslužitelju putem objavljenog protokola. Međutim, najučinkovitiji pokretač izravno bi pristupio vlasničkom API-ju DBMS-a.

Baze podataka objekata i postojanost Java

Niz tekućih projekata u industriji nudi postojanost Java na objektnoj razini. Međutim, od pisanja ovog članka, PSE (Persistent Storage Engine) i PSE Pro Object Design-a jedini su potpuno dostupni objektno-orijentirani paketi baza podataka koji se temelje na Javi (barem, koliko mi je poznato). Pogledajte odjeljak Resursi za više informacija o PSE i PSE Pro.

Razvoj Java doveo je do odstupanja od tradicionalne razvojne paradigme za dobavljače softvera, ponajviše u vremenskom slijedu razvojnog procesa. Na primjer, PSE i PSE Pro razvijeni su u heterogenom okruženju. A budući da u procesu razvoja nema koraka povezivanja, programeri su uspjeli stvoriti različite funkcionalne komponente neovisne jedna o drugoj, što rezultira boljim, pouzdanijim objektno orijentiranim kodom.

PSE Pro ima mogućnost oporavka oštećene baze podataka iz pokidane transakcije uzrokovane kvarom sustava. Klase odgovorne za ovu dodanu funkcionalnost nisu prisutne u izdanju PSE. Ne postoje nikakve druge razlike između dva proizvoda. Ovi proizvodi su ono što nazivamo "dribbleware" - izdanja softvera koja poboljšavaju njihovu funkcionalnost uključivanjem novih komponenata. U ne tako dalekoj budućnosti koncept kupnje velikog, monolitnog softvera postao bi stvar prošlosti. Novo poslovno okruženje u cyber prostoru, zajedno s Java računalstvom, omogućuje korisnicima kupnju samo onih dijelova objektnog modela (objektni graf) koji su im potrebni, što rezultira kompaktnijim krajnjim proizvodima.

PSE djeluje naknadnom obradom i označavanjem datoteka klasa nakon što ih je stvorio programer. S gledišta PSE-a, klase u objektnom grafu su ili postojano sposobne ili trajno svjesne. Klase koje su sposobne za postojanost mogu ustrajati same dok klase koje su svjesne postojanosti mogu operirati na trajnim objektima. Ova je razlika neophodna jer upornost možda nije poželjno ponašanje za određene razrede. Postprocesor datoteke klase vrši sljedeće izmjene klasa: