Uvod

Pojavu smjera objektno orijentiranih baza podataka (OODB) odredile su, prije svega, potrebe prakse: potreba za razvojem složenih informacijskih aplikacijskih sustava za koje tehnologija dosadašnjih sustava baza podataka nije bila u potpunosti zadovoljavajuća. Naravno, OODB se nije pojavio niotkuda. Odgovarajuću osnovu dali su i prethodni radovi na području baza podataka, kao i područja programskih jezika koji se dugo razvijaju s apstraktnim tipovima podataka i objektno orijentiranim programskim jezicima.

S obzirom na odnos s dosadašnjim radom u području baza podataka, najsnažniji utjecaj na rad u području OODB imao je razvoj DBMS-a i sljedeće obitelji kronoloških baza podataka, u kojoj je podržano upravljanje složenim objektima. Ove aktivnosti dale su strukturnu osnovu za organizaciju OOBD-a. U ovom sažetku razmatrat će se OOMD i OODBMS.

Objektno orijentirani model podataka

Razmotrimo jedan od pristupa izgradnji baze podataka – korištenjem objektno orijentiranog modela podataka (OOMD). Modeliranje podataka u OOMD-u temelji se na konceptu objekta. ODM se obično koristi u složenim predmetnim područjima kojima nedostaje funkcionalnost relacijskog modela za modeliranje (na primjer, za sustave za automatizaciju dizajna (CAD), sustave za izdavaštvo, itd.).

Objektno orijentirani model podataka ODMG razlikuje se od ostalih modela, prije svega, u jednom temeljnom aspektu. U SQL podatkovnom modelu i stvarnom relacijskom podatkovnom modelu, baza podataka je zbirka imenovanih spremnika podataka istog generičkog tipa: tablice ili relacije, respektivno. U objektno orijentiranom modelu podataka baza podataka je zbirka objekata (spremnika podataka) proizvoljnog tipa.

Prilikom izrade objektno orijentiranog DBMS-a (OODBMS) koriste se različite metode i to:

ugrađivanje u objektno orijentirani jezik sredstava namijenjenih radu s bazom podataka;

proširenje postojećeg jezika za rad s bazama podataka s objektno orijentiranim funkcijama;

stvaranje objektno orijentiranih knjižnica funkcija za rad s bazom podataka;

stvaranje novog jezika i novog objektno orijentiranog modela podataka.

Prednosti OOMD-a uključuju obilje mogućnosti za modeliranje domene, izražajan jezik upita i visoke performanse. Svaki objekt u OOMD-u ima jedinstveni identifikator (OID - identifikator objekta). Dohvaćanje OID-a znatno je brže od pretraživanja relacijskih tablica.

Među nedostacima OOMD-a treba istaknuti nedostatak općeprihvaćenog modela, nedostatak iskustva u izradi i radu OODB-a, složenost korištenja i nedostatna sredstva zaštite podataka.

Pogledajmo sada kako je podrška modela podataka implementirana u stvarnim sustavima upravljanja bazama podataka.

U objektno orijentiranom modelu (OOM) prilikom prezentiranja podataka moguće je identificirati pojedinačne zapise baze podataka. Odnosi se uspostavljaju između zapisa baze podataka i njihovih funkcija obrade korištenjem mehanizama sličnih onima u objektno orijentiranim programskim jezicima.

Standard OOM opisan je u preporukama standarda ODMG-93 (Object Database Management Group). Preporuke ODMG-93 još nisu u potpunosti provedene. Da bismo ilustrirali ključne ideje, razmotrimo donekle pojednostavljeni model objektno orijentirane baze podataka.

Struktura OO baze podataka grafički je predstavljena u obliku stabla čiji su čvorovi objekti. Svojstva objekata opisuju se nekim standardnim tipom (na primjer, string tipom) ili tipom koji je izradio korisnik (definiran kao klasa).

Vrijednost svojstva tipa string je niz znakova. Vrijednost svojstva tipa class je objekt koji je instanca odgovarajuće klase. Svaka instanca klase smatra se potomkom objekta u kojem je definirana kao svojstvo. Objekt instance klase pripada svojoj klasi i ima jednog roditelja. Generički odnosi u bazi podataka tvore srodnu hijerarhiju objekata.

Prvi formalizirani i općeprihvaćeni model podataka bio je Coddov relacijski model. U ovom modelu, kao iu svim sljedećim, izdvajaju se tri aspekta - strukturni, holistički i manipulativni. Strukture podataka u relacijskom modelu temelje se na ravnim normaliziranim odnosima, ograničenja integriteta izražena su pomoću logike prvog reda i, konačno, manipulacija podacima temelji se na relacijskoj algebri ili njenom ekvivalentnom relacijskom računu. Kao što mnogi istraživači primjećuju, relacijski model podataka uvelike duguje svoj uspjeh činjenici da se oslanjao na rigorozni matematički aparat teorije skupova, odnosa i logike prvog reda. Dizajneri svakog određenog relacijskog sustava smatrali su svojom dužnošću pokazati da njihov određeni model podataka odgovara općem relacijskom modelu, koji je djelovao kao mjera "relacije" sustava.

Glavne poteškoće objektno orijentiranog modeliranja podataka proizlaze iz činjenice da ne postoji tako razvijen matematički aparat na koji bi se mogao osloniti opći objektno orijentirani model podataka. U velikoj mjeri, dakle, još uvijek ne postoji osnovni objektno orijentirani model. S druge strane, neki autori tvrde da se opći objektno orijentirani model podataka u klasičnom smislu ne može definirati zbog neprikladnosti klasičnog koncepta modela podataka objektno orijentiranoj paradigmi.

Jedan od najpoznatijih teoretičara modela podataka, Beeri, nudi nacrt formalnog okvira za OODB, koji je daleko od potpunog i nije model podataka u tradicionalnom smislu, ali omogućuje istraživačima i programerima OODB sustava da govore barem jedan jezik (osim ako, naravno, rečenice Beeri neće biti razvijene i podržane). Bez obzira na daljnju sudbinu ovih prijedloga, smatramo korisnim ukratko ih sažeti.

Prvo, slijedeći praksu mnogih OODB-ova, predlaže se razlikovanje dvije razine modeliranja objekata: donja (strukturna) i gornja (bihevioralna). Na strukturnoj razini podržavaju se složeni objekti, njihova identifikacija i vrste "isa" komunikacije. Baza podataka je zbirka elemenata podataka povezanih odnosom "je u klasi" ili "je atribut". Dakle, DB se može smatrati usmjerenim grafom. Važna je točka održavati, uz koncept objekta, i koncept značenja (kasnije ćemo vidjeti koliko se na tome gradi u jednom od uspješnih objektno orijentiranih DBMS O2).

Važan aspekt je jasno odvajanje sheme baze podataka i same baze podataka. Primarni koncepti razine OODB sheme su tipovi i klase. Primjećuje se da je u svim sustavima koji koriste samo jedan koncept (bilo tip ili klasu), ovaj koncept neizbježno preopterećen: tip pretpostavlja prisutnost određenog skupa vrijednosti određenih strukturom podataka ovog tipa; klasa također pretpostavlja skup objekata, ali ovaj skup je korisnički definiran. Dakle, tipovi i klase imaju različite uloge, a za strogost i jednoznačnost potrebno je podržati oba koncepta u isto vrijeme.

Beeri ne predstavlja potpuni formalni model strukturne razine OODB-a, ali izražava uvjerenje da je trenutna razina razumijevanja dovoljna za formaliziranje takvog modela. Što se tiče bihevioralne razine, predlaže se samo opći pristup logičkom aparatu koji je za to potreban (logika prve razine nije dovoljna).

Važna, iako nedovoljno potkrijepljena, Beerijeva pretpostavka je da dva tradicionalna sloja - shema i podaci - nisu dovoljni za OODB. Za točno definiranje OODB-a potrebna je razina meta-sheme, čiji sadržaj mora odrediti vrste objekata i odnosa koji su dopušteni na razini sheme baze podataka. Meta-shema bi trebala igrati istu ulogu za OODB-ove kao što strukturni dio relacijskog modela podataka igra za sheme relacijskih baza podataka.

Postoje mnoge druge publikacije vezane uz temu objektno orijentiranih modela podataka, ali se ili dotiču prilično specifičnih pitanja ili koriste matematički aparat koji je preozbiljan za ovaj pregled (npr. neki autori definiraju objektno orijentirani model podataka na temelju teorije kategorija).

Da bismo ilustrirali trenutno stanje stvari, ukratko ćemo razmotriti značajke specifičnog modela podataka koji se koristi u O2 objektno orijentiranom DBMS-u (ovo, naravno, također nije podatkovni model u klasičnom smislu).

O2 podržava objekte i vrijednosti. Objekt je par (identifikator, vrijednost), a objekti su enkapsulirani, tj. njihove vrijednosti su dostupne samo kroz metode - procedure vezane za objekte. Vrijednosti mogu biti atomske ili strukturne. Strukturne vrijednosti se grade od vrijednosti ili objekata predstavljenih njihovim identifikatorima pomoću konstruktora skupova, tuple i popisa. Članovima strukturne vrijednosti pristupa se korištenjem unaprijed definiranih operacija (primitiva).

Postoje dva načina organiziranja podataka: klase koje instanciraju objekti koji enkapsuliraju podatke i ponašanje i tipovi čije su instance vrijednosti. Svaka klasa je povezana s tipom koji opisuje strukturu instanci klase. Tipovi se definiraju rekurzivno iz atomskih tipova i prethodno definiranih tipova i klasa korištenjem konstruktora. Strana ponašanja klase određena je skupom metoda.

Objekti i vrijednosti mogu se imenovati. Imenovanje objekta ili vrijednosti povezano je s njegovom postojanošću: svi imenovani objekti ili vrijednosti su postojani; bilo koji objekt ili vrijednost koji je dio drugog imenovanog objekta ili vrijednosti je trajan.

Uz pomoć posebne upute date prilikom definiranja klase, možete postići dugotrajnu pohranu bilo kojeg objekta ove klase. U tom slučaju sustav automatski generira zadanu vrijednost čije je ime isto kao i naziv klase. Ovaj skup zajamčeno sadrži sve objekte ove klase.

Metoda - programski kod povezan s određenom klasom i primjenjiv na objekte ove klase. Određivanje metode u O2 provodi se u dvije faze. Prvo se deklarira potpis metode, tj. njegovo ime, klasu, tipove ili klase argumenata i vrstu ili klasu rezultata. Metode mogu biti javne (dostupne iz objekata drugih klasa) ili privatne (dostupne samo unutar ove klase). U drugoj fazi utvrđuje se implementacija klase u jednom od programskih jezika O2 (o jezicima se detaljnije govori u sljedećem odjeljku našeg pregleda).

O2 model podržava višestruko nasljeđivanje klasa na temelju odnosa supertip/podtip. Podklasi je dopušteno dodavati i/ili nadjačavati atribute i metode. Dvosmislenosti moguće s višestrukim nasljeđivanjem (u imenovanju atributa i metoda) rješavaju se ili preimenovanjem ili eksplicitnim navođenjem izvora nasljeđivanja. Objekt potklase je objekt svake nadklase iz koje je potklasa izvedena.

Podržana je unaprijed definirana klasa "Objekt", koja je korijen rešetke klase; bilo koja druga klasa je implicitni nasljednik klase "Object" i nasljeđuje unaprijed definirane metode ("is_same", "is_value_equal" itd.).

Specifična značajka O2 modela je mogućnost deklariranja dodatnih "ekskluzivnih" atributa i metoda za imenovane objekte. To znači da određeni imenovani reprezentativni objekt klase može imati tip koji je podtip tipa klase. Naravno, metode standardne klase ne rade s takvim atributima, ali se dodatne (ili standardne) metode mogu definirati posebno za imenovani objekt, za koji su dodatni atributi već dostupni. Naglašava se da se dodatni atributi i metode ne vežu za određeni objekt, već za ime, iza kojeg, općenito govoreći, mogu stajati različiti objekti u različito vrijeme. Za implementaciju ekskluzivnih atributa i metoda potrebno je razviti tehnike kasnog uvezivanja.

U sljedećem ćemo odjeljku, između ostalog, razmotriti značajke programskih jezika i upita O2 sustava, koji su, naravno, usko povezani sa specifičnostima podatkovnog modela.

Osnovni koncepti

Definicija 1

Objektno orijentirani model prezentacija podataka omogućuje identifikaciju pojedinačnih zapisa baze podataka.

Zapisi baze podataka i njihove funkcije obrade povezani su mehanizmima sličnim odgovarajućim alatima koji su implementirani u objektno orijentiranim programskim jezicima.

Definicija 2

Grafički prikaz objektno orijentirana struktura baze podataka je stablo čiji čvorovi predstavljaju objekte.

Standardna vrsta (na primjer, string - niz) ili tip koji je kreirao korisnik ( razreda), opisuje svojstva objekta.

Na slici 1, objekt LIBRARY je roditelj instanci objekata DIRECT, SUBSCRIBER i REFERENCE. Različiti objekti tipa KNJIGA mogu imati jednog ili različite roditelje. Objekti tipa BOOK koji imaju isti roditelj moraju imati najmanje različite inventarne brojeve (jedinstvene za svaki primjerak knjige), ali iste vrijednosti svojstva Autor, titula, udk i isbn.

Logičke strukture objektno orijentirane baze podataka i hijerarhijske baze podataka su površno slične. Razlikuju se uglavnom u metodama manipulacije podacima.

Prilikom izvođenja radnji nad podacima u objektno orijentiranom modelu koriste se logičke operacije koje su ojačane enkapsulacijom, nasljeđivanjem i polimorfizmom. Uz određena ograničenja, možete koristiti operacije koje su slične SQL naredbama (na primjer, prilikom stvaranja baze podataka).

Prilikom kreiranja i modifikacije baze podataka vrši se automatsko formiranje i naknadno prilagođavanje indeksa (indeksnih tablica) koji sadrže informacije za brzi dohvat podataka.

Definicija 3

Cilj inkapsulacije- ograničavanje opsega imena svojstva na granice objekta u kojem je definirano.

Na primjer, ako je svojstvo dodano objektu DIRECTORY koji postavlja telefonski broj autora i ima naziv telefon, svojstva istog imena će se dobiti za objekte DIRECTORY i SUBSCRIBER. Značenje svojstva određeno je objektom u koji je inkapsulirano.

Definicija 4

Nasljedstvo, inverzno enkapsulirajući, odgovoran je za širenje opsega svojstva u odnosu na sve potomke objekta.

Na primjer, svim objektima BOOK koji su potomci objekta DIRECTORY mogu se dodijeliti svojstva roditeljskog objekta: Autor, titula, udk i isbn.

Ako je potrebno proširiti djelovanje mehanizma nasljeđivanja na objekte koji nisu neposredni srodnici (na primjer, dva potomka istog roditelja), svojstvo apstraktnog tipa definira se u njihovom zajedničkom pretku trbušnjaci.

Dakle, svojstva soba i ulaznica u objektu KNJIŽNICA nasljeđuju svi podređeni objekti REFERENCA, BOOK i SUBSCRIBER. Zato su vrijednosti ovog svojstva klasa SUBSCRIBER i OUTPUT iste - 00015 (slika 1).

Definicija 5

Polimorfizam omogućuje da isti programski kod radi s različitim vrstama podataka.

Drugim riječima, omogućuje objektima različitih tipova da imaju metode (funkcije ili procedure) s istim imenima.

traži u objektno orijentiranoj bazi podataka, to je odrediti sličnost između objekta koji korisnik specificira i objekata koji su pohranjeni u bazi podataka.

Prednosti i nedostaci objektno orijentiranog modela

Glavni prednost objektno orijentirani model podataka, za razliku od relacijskog modela, sastoji se u mogućnosti prikaza informacija o složenim odnosima objekata. Razmatrani model podataka omogućuje definiranje zasebnog zapisa baze podataka i funkcija njegove obrade.

DO nedostatke Objektno orijentirani model karakterizira visoka konceptualna složenost, nezgodna obrada podataka i niska brzina izvršavanja upita.

Danas su takvi sustavi prilično rašireni. To uključuje DBMS:

• Postgres,
• Orion,
• Iris,
• ODBJupiter,
• Versant,
• Objektivnost / DB,
• ObjectStore,
• Statice,
• Dragi kamen
• G-baza.

06.04.2004. Siha Bagui

Razvoj objektno orijentiranih sustava baza podataka započeo je sredinom 1980-ih kao odgovor na potrebu ispunjavanja zahtjeva drugih aplikacija osim onih koje održavaju i održavaju sustavi relacijskih baza podataka. Razmotrite napredak u tehnologiji objektno orijentirane baze podataka, kao i izazove koje razvojna zajednica tek treba riješiti da bi tehnologija objektno orijentirane baze podataka bila jednako raširena kao i tehnologija relacijske baze podataka.

Razvoj objektno orijentiranih sustava baza podataka (tzv. pete generacije tehnologija baza podataka) započeo je sredinom 1980-ih u vezi s potrebom ispunjavanja zahtjeva drugih aplikacija osim onih aplikacija za obradu podataka koje su karakteristične za sustave relacijskih baza podataka (četvrti generacijska tehnologija baze podataka).generacija). Pokušaji korištenja tehnologija relacijskih baza podataka u tako složenim aplikacijama kao što je projektiranje pomoću računala (CAD); računalno potpomognuta proizvodnja (CAM); tehnologija programiranja; sustavi temeljeni na znanju i multimedijski sustavi razotkrili su ograničenja sustava relacijske baze podataka (RDB)... S pojavom nove generacije aplikacija za baze podataka, pojavile su se potrebe koje se najbolje zadovoljavaju korištenjem objektno orijentirane baze podataka (OODB).

Predložene su mnoge definicije objektno orijentirane i objektno orijentirane baze podataka, ali ćemo objektno orijentirane baze podataka definirati kao baze koje kombiniraju objektnu orijentaciju s mogućnostima baza podataka. Objektna orijentacija omogućuje izravnije predstavljanje i modeliranje problema u stvarnom svijetu, i funkcionalnost baze podataka potrebno za osiguranje stabilnosti podataka i istodobnog pristupa više korisnika informacijama o aplikaciji.

Trenutno na tržištu postoji preko 25 OODB sustava. To uključuje Servio GemStone, Ontosov ONTOS, Object Design's ObjectStore i mnoge druge. Osim toga, sustavi upravljanja relacijskim bazama podataka koje su razvili Oracle, Microsoft, Borland, Informix uključivali su objektno orijentirane alate. Mnogi od tih proizvoda pojavili su se u drugoj polovici 1980-ih, a danas, nakon gotovo desetljeća i pol razvoja, još nisu dostigli zrelost; ovo je jedan od razloga zašto je svjetsko tržište aplikacija u stvarnom svijetu do danas sporo usvajalo OODB sustave. Među modernim OODB-ovima gotovo da nema potpuno razvijenih sustava usporedivih s modernim sustavima relacijskih baza podataka. Razmotrimo glavna postignuća i probleme povezane s trenutnim stanjem OODB-a.

OODB model

Razlog za pojavu objektno orijentiranih sustava baza podataka bila je potreba za adekvatnijim predstavljanjem i modeliranjem entiteta iz stvarnog svijeta, budući da OODB-ovi pružaju mnogo napredniji model podataka od tradicionalnih relacijskih baza podataka. OODB paradigma temelji se na brojnim osnovnim konceptima kao što su objekt, prepoznatljivost, klasa, nasljeđivanje, preopterećenje i lijeno uvezivanje.

U objektno orijentiranom modelu podataka, svaki entitet stvarnog svijeta predstavljen je samo jednim konceptom - objekt... Stanje i ponašanje povezani su s objektom. Stanje objekta određeno je vrijednostima njegovih svojstava - atributima... Vrijednosti svojstava mogu biti primitivne vrijednosti (kao što su nizovi ili cijeli brojevi) i neprimitivni objekti. Neprimitivni objekt se pak sastoji od skupa svojstava. Dakle, objekti se mogu rekurzivno definirati u terminima drugih objekata. Ponašanje objekta definira se pomoću metode, koji djeluju na stanje objekta.

Svaki objekt ima sustav definiran jedinstveni identifikator... Objekti s istim svojstvima i ponašanjem grupirani su u razreda... Objekt može biti instanca samo jedne klase ili nekoliko klasa.

Nastava je organizirana u hijerarhiji klasa. Potklasa nasljeđuje svojstva i metode nadklase; osim toga, podklase mogu imati pojedinačna svojstva i metode. U nekim sustavima, na primjer ORION, klasa može imati više od jedne superklase (višestruko nasljeđivanje), dok je u drugim sustavima broj superklasa ograničen na jednu (jedno nasljedstvo).

Većina modela dopušta preopterećenje naslijeđena svojstva i metode. Preopterećenje se sastoji od zamjene domene svojstva novom domenom ili zamjene jedne implementacije metode drugom implementacijom.

Prednosti OODB modela

Objektno orijentirane baze podataka omogućuju vam predstavljanje složenih objekata izravnije od relacijskih sustava. Zadržimo se na nekim od postojećih dostignuća na području OODB-a. OODB sustavi omogućuju korisnicima da definiraju apstrakcije; olakšati dizajn nekih poveznica; Uklonite potrebu za korisnički definiranim ključevima podržavaju novi skup predikata za usporedbu; u nekim slučajevima eliminirati potrebu za priključcima; u nekim situacijama pružaju bolje performanse od sustava koji se temelje na relacijskom modelu; pružiti podršku za verzije i dugotrajne transakcije. Konačno, objektna algebra je razvijena - iako možda još ne toliko detaljno kao relacijske algebre.

Definiranje prilagođenih apstrakcija

Objektno orijentirane baze podataka pružaju mogućnost definiranja novih apstrakcija i kontrole implementacije takvih apstrakcija. Ove nove apstrakcije mogu odgovarati strukturama podataka potrebnim za složene zadatke, novim apstraktnim tipovima podataka. Drugim riječima, moderni OODB paketi omogućuju korisniku da stvori novu klasu s atributima i metodama, imaju klase koje nasljeđuju atribute i metode iz superklasa, kreiraju instance klase, od kojih svaka ima jedinstven identifikator objekta, dohvaćaju te instance jednu po jednu ili u grupama, te metode učitavanja i izvršavanja. Osim toga, OODB-ovi dopuštaju da se objekti definiraju kao zbirke drugih objekata, a za zbirke je dopušteno više razina ugniježđenja. Svojstva također mogu biti složena i mogu se definirati pomoću konstruktora zbirke. Štoviše, mogu imati neprimitivne objekte kao vrijednosti, što omogućuje formiranje duboko ugniježđenih objekata objekata.

Viševrijedna svojstva koriste se u objektno orijentiranim modelima podataka za izražavanje složenih struktura podataka. U relacijskom modelu to se postiže dodatnim odnosima i spojevima.

Primjer OODB paketa koji ima sve gore navedene mogućnosti je ENCORE. Model podataka u ENCORE prvenstveno se temelji na apstrakciji podataka. ENCORE omogućuje podtipizaciju (nasljeđivanje), enkapsulaciju, složene strukture, identifikaciju objekata i vezanje lijenih metoda. Osim toga, ENCORE pruža mogućnost povezivanja objekata pomoću svojstava. U sustavu ENCORE, svojstvo p povezuje objekt x sa skupom objekata S bez ikakvih naznaka kako se veza izračunava. Može se izračunati izravnim navođenjem identifikatora skupa S (ili identifikatora njegovih članova) ili mapiranjem vrijednosti drugih svojstava, kao u spoju.

Lagani dizajn nekih poveznica

Objektno orijentirane baze podataka podržavaju mogućnost inverznog povezivanja za izražavanje recipročnih veza između dva objekta (binarna veza). Takav sustav osigurava referentni integritet uspostavljanjem odgovarajuće povratne veze odmah nakon kreiranja veze prema naprijed. Postoji čak i mogućnost automatskog širenja brisanja putem ovih veza. Primjer OODB paketa koji omogućuje automatsko održavanje inverznih odnosa je ObjectStore.

Nema potrebe za korisnički definiranim ključevima

OODB model ima koncept identifikatora objekata, automatski generiranih od strane sustava i zajamčeno jedinstvenih za svaki objekt. Ovo, u kombinaciji s činjenicom da OODB model eliminira potrebu za korisnički definiranim ključevima, pruža objektno orijentirane baze podataka s drugim prednostima. Prvo, aplikacija ne može mijenjati identifikator objekta. Drugo, pojam prepoznatljivosti objekta podrazumijeva odvojen i dosljedan pojam identiteta, neovisno o tome kako se objektu pristupa ili kako se objekt modelira korištenjem deskriptivnih podataka. Dakle, dva objekta nisu identična ako imaju različite identifikatore objekata; u ovom slučaju objekti mogu imati iste strukture, a sva njihova svojstva - iste vrijednosti. U RDB modelu, gdje se objekti identificiraju pomoću korisnički definiranih ključeva, takvi bi se objekti smatrali istim objektom.

Predikati za usporedbu

U RDB-u usporedba se uvijek temelji samo na vrijednostima. U ovom modelu, dvije torke su jedan entitet ako svi njihovi ključni atributi imaju istu vrijednost. Međutim, u OODB modelu su razvijene i definirane druge vrste usporedbe.

1. Jednakost objekata na temelju njihova identiteta. Dva objekta, S1 i S2 su jednaka ako su isti objekt (tj. imaju isti ID objekta).
2. Jednakost objekata na temelju vrijednosti. To se može odrediti u dva prolaza - (a) dva primitivna objekta su jednaka ako imaju istu vrijednost; (b) dva neprimitivna objekta su jednaka ako imaju isti broj svojstava, a za svako svojstvo pi objekta S1 postoji svojstvo pj objekta S2 koje je jednako vrijednosti.
3. Svojstvena jednakost na temelju vrijednosti.
4. Jednakost svojstava na temelju njihovog identiteta.

Manja potreba za vezama

Mogućnost navigacije strukturama objekata i rezultirajućim izrazima putanje u smislu atributa objekta daju nam novi pogled na problem spajanja u OODB-ovima. Relacijsko spajanje je mehanizam koji preslikava dva odnosa na temelju vrijednosti odgovarajućih parova atributa u tom odnosu. Budući da dvije klase u OODB-u mogu imati odgovarajuće parove atributa, još uvijek može postojati potreba za relacijskim spajanjem (ili eksplicitnim spajanjem) u ovom modelu. Na primjer, recimo da imamo razrede Učenik i Škola, a svaki od tih razreda ima atribute Ime i Dob. Iako se domene atributa Ime i Dob razreda škole možda ne podudaraju s domenama atributa Ime i Dob razreda Učenik, možda ćemo htjeti povezati ove klase na temelju vrijednosti ovih atributa (recimo pronaći sve učenike mlađe od dobi škole koju ovaj učenik pohađa).

No, kao što je već navedeno, podrška za izraze puta može značajno smanjiti potrebu za spajanjem klasa u usporedbi sa situacijom u RDB-u. Postoje čak i situacije u kojima se potreba za relacijskim spajanjem može potpuno eliminirati. Na primjer, kada je domena atributa klase A klasa B, dohvaćanje identifikatora objekta neke klase koji su pohranjeni kao vrijednosti atributa druge klase eliminira potrebu za implicitnim spajanjem objekata.

Dakle, u objektno orijentiranim bazama podataka, implicitni spojevi generirani hijerarhijskim ugniježđenjem objekata razlikuju se od eksplicitnih spojeva. Potonji nalikuju relacijskim spojevima: dva objekta se eksplicitno uspoređuju na temelju vrijednosti atributa ili identifikatora objekta. Štoviše, sva eksplicitna spajanja (temeljena na usporedbi vrijednosti ili identifikatora) ne mogu se izraziti u relacijskom jeziku upita, budući da bilo koji predikat u RDB-u može sadržavati samo atomske atribute.

Dobitak performansi

Moderni OODB-ovi nisu potpuno razvijeni sustavi baza podataka u usporedbi s modernim OODB-ovima; OODB-ovi imaju nekoliko značajki koje im osiguravaju povećanje performansi.

1. U OODB-u vrijednost atributa objekta X čija je domena drugi objekt Y je identifikator objekta Y. Stoga, ako je aplikacija već dohvatila objekt X i sada želi dohvatiti objekt Y, DBMS može dohvatiti objekt Y tražeći njegov identifikator. Ako je ovaj identifikator fizička adresa objekta, tada se ovaj objekt može dohvatiti izravno; ako je identifikator logička adresa, tada objekt pronalaženjem odgovarajućeg elementa hash tablice (pod pretpostavkom da sustav održava hash tablicu koja preslikava identifikator objekta u fizičku adresu). To možda neće uspjeti tako lako u RDB-u, budući da identifikatori objekata nisu podržani u RDB-u.
2. Druga značajka OODB-a, koja osigurava povećanje performansi, je da se u većini OODB-ova, kada se objekt učita u memoriju, identifikatori objekta pohranjeni u ovom objektu pretvaraju u pokazivače iz memorije. Budući da identifikatori objekata nisu pohranjeni u RDB-u, nemoguće je pohraniti pokazivače u memoriju na druge torke u njima. Nemogućnost navigacije kroz objekte sadržane u memoriji temeljno je svojstvo RDB-a, a rezultirajuće smanjenje performansi ne može se nadoknaditi jednostavnim povećanjem količine memorije međuspremnika. Dakle, kada se izvode aplikacije koje uključuju višestruku navigaciju kroz povezane objekte učitane u memoriju, OODB-ovi mogu značajno nadmašiti RDB-ove u izvedbi.
3. Osim toga, čak i ako OODB-ovi nisu indeksirani, može biti prikladno izvršiti proizvoljne upite koji odgovaraju strukturi objekta uzastopnim skeniranjem, t.j. koristiti referentne staze između objekata. Kada je zahtjev formuliran u smjeru koji nije podržan poveznicama, taj će se zahtjev obraditi uzastopnim skeniranjem. Međutim, upiti temeljeni na takvim objektnim odnosima koji se ne modeliraju izravno pomoću veza su neučinkoviti.

Podrška za izradu verzija i dugotrajne transakcije

RDB ne podržava ni verziju niti dugotrajne transakcije. Ova podrška je dostupna u nekim OODB-ovima, iako s ograničenim mogućnostima.

Objektna algebra

Objektna algebra nije tako detaljna i zrela kao relacijska algebra. Ali kako god bilo, takva algebra postoji i ona definira pet temeljnih operacija koje čuvaju objekte: udruživanje, razliku, odabir, generiranje i mapiranje. Druge operacije mogu se definirati na temelju ovih temeljnih operacija, kao što je križanje. Pravila pretvorbe za logičku optimizaciju izraza objektne algebre uz očuvanje ekvivalencije izvedena su u i. Dok operacije unija, razlika i mapa izvode uglavnom mapiranje jedan-na-jedan, operacije odabira i generiranja proizvode mapiranje jedan-prema-više. Spremanje objekata znači da algebarske operacije vraćaju objekte koji pripadaju prethodno definiranim klasama baze podataka i ne stvaraju nove objekte. Operator unije vraća objekte sadržane u skupu P ili skupu Q, ili oboje. Operator razlike vraća skup objekata koji pripadaju skupu P, ali nisu skupu Q. select vraća podskup skupa koji ste unijeli. generira generira objekte od onih koji pripadaju ulaznom skupu. map vraća skup objekata koji proizlaze iz svake primjene niza metoda.

Nedostaci OODB modela

Očekivalo se da će objektno orijentirane metode omogućiti tehnologiji baze podataka da napravi neku vrstu kvantne tranzicije. No, usprkos navedenim postignućima, OODB nije uspio značajno utjecati na stanje u ovom području. Još uvijek postoje slabosti i u modelu i u OODB tehnologiji.

Objektno orijentiranim bazama podataka nedostaju osnovni alati na koje su korisnici baze podataka navikli i stoga očekuju da će ih vidjeti. Između ostalog, može se primijetiti: nedostatak interoperabilnosti između RDB i OODB; minimalna optimizacija upita; nedostatak standardne algebre upita; nedostatak sredstava za podršku zahtjevima; nedostatak podrške za podneske; sigurnosni problemi; nedostatak podrške za dinamičke promjene u definicijama klasa; ograničena podrška za ograničenja integriteta; ograničene mogućnosti podešavanja performansi; nedovoljna podrška za složene objekte; ograničena integracija s postojećim objektno orijentiranim programskim sustavima; ograničeni dobitak performansi.

Nedostatak interoperabilnosti između RDB-a i OODB-a

Da bi OODB-ovi imali značajan utjecaj na tržište baza podataka, moraju biti ispunjeni brojni uvjeti.

1. Pretvorite OODB-ove u potpuno razvijene sustave baza podataka koji su razumno kompatibilni s RDB-ovima. Potreban je put migracije kako bi se osigurao suživot postojećih i novih proizvoda, kao i nesmetan prijelaz s prvih na druge.
2. Ponuditi alate za razvoj aplikacija i sredstva za pristup objektno orijentiranim bazama podataka.
3. Objedinite arhitekturu RDB-a i OODB-a.
4. Objediniti modele podataka RDB i OODB.

Nedovoljno sredstava za optimizaciju upita

Jedan od najznačajnijih problema u OODB-u je optimizacija deklarativnih upita. Optimiziranje upita prema OODB-ovima otežano je dodatnom složenošću samog objektno orijentiranog modela podataka. Ova dodatna složenost posljedica je niza čimbenika.

1. Mogućnost korisnika da definiraju nove tipove i klase pomoću nasljeđivanja olakšava i otežava optimizaciju upita. Primjer gdje ova značajka može pomoći u optimizaciji je upit koji uključuje sjecište skupova zaposlenika i nadzornika. Ako je Employee nadklasa Supervisora, tada optimizator može pretpostaviti da su Supervisori vlastiti podskup zaposlenika i pojednostaviti sjecište skupova. Primjer u kojem dodatni tipovi podataka ograničavaju opcije optimizacije je unija skupova Studenti i Employees; nadklasa za obje klase je Person. Ako želimo pronaći sve nadzornike učenika i zaposlenika, prvo bismo izvršili spajanje, a zatim upotrijebili supervizor ().
2. Upiti se mogu temeljiti na operacijama na zbirkama, ali vrste optimizacije koje utječu na skupove (ili multiskupove, ili liste, itd.) moraju se kombinirati s optimizacijom nad tipovima objekata sadržanih u tim skupovima. Objektno orijentirani optimizator upita mora biti sposoban primijeniti postupke optimizacije specifične za ove tipove, kao i postupke optimizacije koji uzimaju u obzir odnose između objekata različitih tipova.
3. Složenost obrade upita u OODB-ovima otežava prisutnost složenih objekata, metoda i enkapsulacija. Složeni objekti generiraju izraze putanja koji kompliciraju obradu upita. Stvaranje indeksa za izraze putanje, posebno kada u izrazima postoje proizvoljne metode, komplicira obradu upita. Problem je još složeniji ako metode imaju nuspojave. Drugi problem s izrazima putanja je taj što oni provode redoslijed poziva metodama izraza putanje, a taj redoslijed može biti prilično neučinkovit. Na primjer, izraz putanje Orders.part.name najbolje se procjenjuje s desna na lijevo ako postoji mnogo narudžbi i malo dijelova, ali ako ima mnogo dijelova, a malo narudžbi, bolje je evaluirati izraz s lijeva na desno. Osim toga, ponekad se izrazi puta učinkovitije obrađuju pomoću Join. Na primjer, razmotrite upit s izrazom puta s.comp.name, gdje s pripada skupu Studenti. Možda bi bilo učinkovitije (ako je broj tvrtki, comp, mali) prvo izračunati naziv za svaku tvrtku i pohraniti rezultat u torku. Zatim bi evaluacija izraza od studenta do naziva tvrtke uključivala pridruživanje skupa učenika skupu torki preslikavanjem svojstva comp klase učenika u vrijednost atributa Company neke torke.
4. U OODB jezicima upita podržana je upotreba ugniježđenih struktura, što opet može značajno zakomplicirati proces optimizacije, budući da ga iz lokalnog problema pretvaraju u globalni, budući da je potrebno globalno poznavanje cjelokupnog izraza upita.
5. Kada se objekti mogu identificirati, postavlja se pitanje što se podrazumijeva pod jednakošću dvaju objekata. Ovo se pitanje prenosi na jezik gdje se usporedbe jednakosti koriste u predikatima i gdje je potrebno donijeti odluku o stvaranju novih objekata prilikom izvršavanja upita. Objektno orijentirani optimizator modela mora biti sposoban riješiti probleme povezane s stvaranjem novih objekata i s alternativnim definicijama jednakosti.

Ovi problemi ukazuju na to da je optimizacija objektno orijentiranih upita iznimno težak zadatak, a ovo je područje još uvijek u istraživanju. Današnji objektno orijentirani sustavi baza podataka nude prilično jednostavne strategije optimizacije. Problem optimizacije veza također zahtijeva više pažnje.

Nedostatak standardne algebre upita

Još jedan veliki nedostatak OODB-ova je nedostatak standarda algebre upita. Ova okolnost također otežava optimizaciju upita. Za OODB je predloženo nekoliko različitih formalnih jezika upita zasnovanih na algebri i računu. Te se algebre i računi razlikuju u nekoliko aspekata, kako po izražajnosti tako i po podršci za optimizaciju pravila ponovnog pisanja. Gotovo sve ove algebre temelje se na varijablama, t.j. koristiti varijable za pohranjivanje međurezultata. KOLA, jedan od OODB paketa, je isključivo funkcionalan proizvod; varijable se u njemu ne koriste. Autor tvrdi da upravo zbog nepostojanja varijabli KOLA algebra omogućuje izgradnju snažnijih sustava pravila.

U RDB-u postoji bliska korespondencija između algebarskih operacija i primitiva niske razine fizičkog sustava. Ovo snažno podudaranje postiže se mapiranjem između relacija i datoteka, te između torki i zapisa. Međutim, u OODB-u ne postoji analogna intuitivna korespondencija između operacija objektne algebre i primitivnih elemenata fizičkih sustava. Bilo koja rasprava o generiranju plana izvršenja također treba prvo definirati primitive za manipulaciju objektima niske razine.

Nedostatak sredstava za podršku zahtjevima

Većina OODB-ova nema mogućnosti podrške za upite. U nekoliko sustava koji imaju odgovarajuće mogućnosti, jezik upita nije usklađen s ANSI SQL. Među tim načinima pružanja upita nema ugniježđenih potupita, upita sa skupovima (unija, presjek, razlika), agregatnih funkcija i GROUP BY, spajanja nekoliko klasa - mogućnosti koje su potpuno podržane u RDB-u.

Osim toga, ne postoji standard za objektne upite, iako se mora reći da je bilo pokušaja razvoja SQL objektnog jezika. SQL3 će vjerojatno biti odgođen nekoliko godina.

Nedostatak podrške za pregled

Pogledi nisu podržani u OODB-ovima. Iako je u vezi s tim dano nekoliko prijedloga, nije bilo konsenzusa o tome kako bi prezentacijski mehanizam trebao funkcionirati u OODB-u. Razvoj objektno orijentiranog stroja za prikaz kompliciran je takvim svojstvima modela kao što je prepoznatljivost objekta. Koji je ID objekta u prikazu? S druge strane, izraženo je stajalište da vam sposobnost enkapsuliranja podataka i nasljeđivanja omogućuje da bez eksplicitnih definicija pogleda.

Sigurnosni problemi

Autorizacija je podržana u RDB-ovima, dok je u većini OODB-ova nema. RDB-ovi omogućuju korisnicima prijenos i opoziv dopuštenja za čitanje ili modificiranje definicija i torova u odnosima i pogledima. OODB-ovi će moći steći šire prihvaćanje u poslovnom području samo ako se ta funkcija u njima poboljša.

U nekim OODB sustavima, korisnici moraju eksplicitno postaviti i otpustiti zaključavanja. RDB sustavi automatski postavljaju i otpuštaju zaključavanja prilikom obrade korisničkih zahtjeva i ažuriranja operatera.

Nedostatak podrške za dinamičke promjene definicija klasa

Uz činjenicu da jedinstveni standardni podatkovni model još nije razvijen za OODB-ove, većina OODB-ova ne dopušta dinamičke promjene sheme baze podataka, kao što je dodavanje novog atributa ili metode u klasu, dodavanje nove superklase u klasu , uklanjanje nadklase klase, dodavanje nove klase i brisanje klase. RDB-ovi omogućuju korisniku da dinamički mijenja shemu baze podataka pomoću naredbe ALTER; novi stupac se može dodati u odnos, odnos se može ukloniti, au nekim slučajevima moguće je ukloniti stupac iz odnosa.

Većina OODB-ova također nema automatsko upravljanje proširenjima klasa. Ako je potrebno proširiti klasu, korisnik mora definirati kolekciju za nju i osigurati da se sva umetanja i brisanja u nju zabilježe na vrijeme.

Ograničena podrška za ograničenja integriteta

Ne postoje mehanizmi za deklariranje ključnih svojstava atributa (na primjer, atribut klase ne može se deklarirati kao primarni ključ klase), ili ograničenja jedinstvenosti, eksplicitna ograničenja integriteta i preduvjeti metode. Iako se sve to može učiniti korištenjem metoda, eksplicitna ograničenja bila bi lakša za korisnika, generirala bi manje bugova i bila bi provjerljiva i izmjenjiva.

Ograničene mogućnosti podešavanja performansi

Većina OODB-ova pruža samo ograničena sredstva za parametrizirano podešavanje performansi. U RDB-u instalaterima se daje mogućnost podešavanja performansi sustava postavljanjem velikog broja parametara koje postavlja administrator sustava. Ovi parametri uključuju broj memorijskih međuspremnika, količinu slobodnog prostora rezerviranog na stranici podataka za buduće umetanje podataka, itd. ...

Nedovoljna podrška za složene objekte

Puna funkcionalnost složenih objekata još uvijek nije podržana. Pomoću tih veza možete se kretati kroz veze i operacije koda, ali ne postoje unaprijed definirane generičke operacije koje koriste različite vrste semantike veza. Smatra se da sve reference upućuju na nezavisne objekte, a semantika posebnih odnosa unutar složenih objekata skrivena je u operacijama koje isporučuje korisnik.

Ograničena integracija s objektno orijentiranim programskim sustavima

Teško je prepisati objektno orijentirane programe za upravljanje stabilnim podacima. Ovdje se javlja niz problema: sukobi imena; potreba za ponovnom izradom hijerarhija klasa; OODB sklonost preopterećenju operacija sustava.

Ograničeno povećanje performansi

Kad bi sve aplikacije baze podataka zahtijevale samo traženje objekata baze podataka kroz identifikatore objekata i brz rad s objektima u glavnoj memoriji pomoću pokazivača, tada bi OODB-ovi stvarno nadmašili RDB-ove u izvedbi za dva do tri reda veličine. Međutim, većina aplikacija koje zahtijevaju pristup objektima putem identifikatora također trebaju pristup bazi podataka i mogućnosti ažuriranja koje se nalaze u RDB-u. Te mogućnosti uključuju masovno učitavanje baze podataka; stvaranje, ažuriranje i brisanje pojedinačnih objekata (jedan po jedan); dohvaćanje iz klase jednog ili više objekata koji zadovoljavaju određene uvjete pretraživanja; povezivanje nekoliko klasa; izvršavanje transakcija itd. Prilikom pokretanja takvih aplikacija, OODB-ovi nemaju nikakve prednosti u izvedbi u odnosu na RDB-ove.

Značajke koje još nisu podržane u OODB-ovima uključuju okidače, kontrole metapodataka i ograničenja integriteta kao što su UNIQUE i NULL.

***

Zbog ovih slabosti, OODB-ovi nisu bili u mogućnosti ispuniti svoja očekivanja o pružanju svih važnih alata poželjnih za njihove predviđene aplikacije. Izraz "OODB" se netočno koristi za većinu modernih sustava. Gotovo svi moderni OODB-ovi nisu toliko sustavi baza podataka koliko stabilni sustavi za pohranu podataka za neki objektno orijentirani programski jezik. Dakle, dok je objektno orijentirani model podataka na mnogo načina bogatiji od relacijskog modela, objektno orijentirani model još nije u potpunosti sazrio. Danas je očito više nedostataka u OODB sustavima nego prednosti.

Književnost

1. S. Abiteboul, A. Bonner, "Objekti i pogledi". ACM SIGMOD Int. Konf. O upravljanju podacima, 1991.
2. M. Atkinson, et al., "Manifest sustava objektno orijentiranih baza podataka." Izgradnja objektno orijentiranog sustava baze podataka: priča o O2. Morgan Kaufman, 1992.
3. F. Bancilhon, "Objektno orijentirani sustavi baza podataka." 7. ACM SIGART / SIGMOD Conf., 1988.
4. J. Banerjee, et al., "Problemi modela podataka za objektno orijentirane aplikacije." ACM Trans. O uredskim informacijskim sustavima, siječanj 1987.
5. J. Banerjee, W. Kim, K.C. Kim, "Upiti u objektno orijentiranim bazama podataka." IEEE Data Engineering Conf., veljače. 1988.
6. D. Beech, "Temelji za evoluciju i baze podataka o objektima." Proc. Tehnologija proširene baze podataka, ožujak. 1988.
7. E. Bertino, M. Negri, G. Pelagatti, L. Sbattella, "Objektno orijentirani jezici upita: pojam i problemi." IEEE Transactions on Knowledge and Data Engineering, mar. 1992. godine.
8. A.W. Brown, Objektno orijentirane baze podataka, aplikacije u softverskom inženjerstvu. New York: McGraw-Hill, 1991.
9. R.G.G. Cattell, Upravljanje objektnim podacima, objektno orijentirani i prošireni sustavi relacijskih baza podataka. Addison-Wesley, 1991.
10. M. Cherniack, "Oblici (ers) nad funkcijom (s): KOLA Query Algebra." Tehničko izvješće, Sveučilište Brown, prosinac. 1995.
11. S. Cluet, et al., "Reloop, jezik upita temeljen na algebri za objektno orijentirani sustav baze podataka." 1. međ. Konf. O deduktivnim i objektno orijentiranim bazama podataka, dec. 1989.
12. AKO. Cruz, DOODLE: Vizualni jezik za objektno orijentirane baze podataka. ACM SIGMOD Int. Konf. O upravljanju podacima, 1992.
13. U. Dayal, "Upiti i pogledi u objektno orijentiranom modelu podataka." 2. međ. Raditi. O programskim jezicima baza podataka, lipanj 1989.
14. K.A. Dittrich, K.R. Dittrich, "Gdje bi objektno orijentirani DBMS-ovi trebali biti bolji: kritika temeljena na ranim iskustvima." Moderni sustavi baza podataka: objektni model, interoperabilnost i dalje, ACM Press, Addison Wesley, 1995.
15. U. Erlingsson, "Object-Qriented Query Optimization", neobjavljeni rukopis.
16. L. Fegaras, D. Maier, "Prema učinkovitom proračunu za jezike upita objekata." ACM SIGMOD Int. Konf. o upravljanju podacima, San Jose, Kalifornija, svibanj 1995.
17. L. Fegaras, D. Maier, T. Sheard, "Određivanje optimizatora upita temeljenih na pravilima u reflektirajućem okviru." 3. međ. Konf. on Deductive and Object-Oriented Databases, Phoenix, Arizona, dec. 1993.
18. S. Heiler, S. Zdonik, "Pogled na objekt: Proširivanje vizije." 6. međ. Konf. O inženjerstvu podataka, 1990.
19. J.G. Hughes, Objektno orijentirane baze podataka. New York: Prentice-Hall, 1991.
20. S. Khoshafian, "Uvid u objektno orijentirane baze podataka." Informacijska i softverska tehnologija, tra. 1990.
21. S. Khoshafian, Objektno orijentirane baze podataka, New York: John Wiley & Sons, 1993.
22. S. Khoshafian, G. Copeland, "Identitet objekta". 1. međ. Konf. O sustavima, jezicima i aplikacijama za objektno orijentirano programiranje, okt. 1986.
23. W. Kim, "Zaklada za objektno orijentirane baze podataka." MCC Tech. Rep., N. ACA-ST-248-88, kolovoz. 1988.
24. W. Kim, Uvod u objektno orijentirane baze podataka. MIT Press, 1991.
25. W. Kim, "Objektno orijentirani sustavi baza podataka: obećanja, stvarnost i budućnost." Moderni sustavi baza podataka: objektni model, interoperabilnost i dalje, ACM Press, Addison Wesley, 1995.
26. T.W. Leung, et al, "Aqua Data Model and Algebra". Tehničko izvješće CS-93-09, Sveučilište Brown, ožujak. 1993.
27. G. Mitchell, S.B. Zdonik, U. Dayal, "Objektno orijentirana optimizacija upita - što? Je li problem?" Tehničko izvješće CS-91-41, Sveučilište Brown, lipanj 1991.
28. E.A. Rudensteiner, "Multiview: Metodologija za podršku višestrukih pogleda u objektno orijentiranim bazama podataka." 18. međ. Konf. O vrlo velikim bazama podataka, 1992.
29. M. Scholl, H. Schek, "Relacijski objektni model". 3. međ. Konf. O teoriji baza podataka, LNCS, sv. 470, Springer Verlag, 1990.
30. P.G. Selinger, et al, "Odabir pristupne staze u sustavu upravljanja relacijskim bazama podataka." ACM SIGMOD Int. Konf. O upravljanju podacima, 1979.
31. M. Štefik, D.G. Bobrow, "Objektno orijentirano programiranje: Teme i varijacije". Mag. AI, siječanj. 1986.
32. M. Stonebraker, et al, "Manifest sustava baze podataka treće generacije". Odbor za naprednu funkciju DBMS-a, Sveučilište u Kaliforniji, Berkeley, 1990.
33. DD. Straube, M.T. Ozsu, "Upiti i obrada upita u objektno orijentiranim sustavima baza podataka." ACM transakcije o informacijskim sustavima, okt. 1990.
34. DD. Straube, M.T. Ozsu, "Generacija plana izvršenja za objektno orijentirani podatkovni model." 2. međ. Konf. o deduktivnim i objektno orijentiranim bazama podataka, München, Njemačka, dec. 1991. godine.
35. S.Y.W. Su, M. Guo, H. Lam, Association Algebra: Matematička zaklada za objektno orijentirane baze podataka. IEEE Transactions on Knowledge and Data Engineering, okt. 1993.
36. S.B. Zdonik, D. Maier, ur., Readings in Object-Oriented Database Systems, Morgan Kauffman, 1989.
37. S.B. Zdonik, P. Wegner, "Jezik i metodologija za objektno orijentirana okruženja baze podataka." Hawaii Int. Konf. o sistemskim znanostima, siječanj. 1986.

Siha Bagui([e-mail zaštićen]) je predavač na Odsjeku za računalstvo Sveučilišta West Florida. Koautor triju knjiga o bazama podataka: Učenje SQL-a: Vodič korak-po-korak pomoću Oraclea, Učenje SQL-a: Korak-po-korak vodič za korištenje pristupa (Addison Wesley) i Dizajn baze podataka pomoću dijagrama odnosa entiteta (CRC Press).

Preveo iz "Dostignuća i slabosti objektno orijentiranih baza podataka" Sikha Bagui u Journal of Object Technology (JOT), sv. 2, br. 4, srpanj-kolovoz 2003., stranice 29-41. Prevedeno na ruski za Otkrytye Systemy uz posebno dopuštenje izvornog izdavača. Autorsko pravo JOT, 2003. Izvorni članak na http://www.jot.fm/issues/issue_2003_07/column2.

Od urednika prijevoda

OODB - dospijeće ili pad?

Sergej Kuznjecov

U objektno orijentiranim bazama podataka u posljednjih nekoliko godina došlo je do upečatljivog zatišja, što neki doživljavaju kao pad tehnologije, a drugi kao prijelaz tehnologije u zrelo i stabilno stanje. Prema mojim zapažanjima, takvo zatišje ponekad dovodi do pojave zabluda, pa čak i mitova među ljudima koji su bliski IT-u, ali nisu stručnjaci za područje baza podataka. Jedna od tih zabluda je da osoba uzima skup pojmova koji su se razvili u njezinoj glavi (objekt, atribut, metoda, klasa, nasljeđe, itd.) za općeprihvaćen objektno orijentirani model podataka.

To objašnjava našu odluku da objavimo prijevod prilično običnog članka Sihe Baguija. Ovakva objava opravdana je barem činjenicom da prekida to zatišje i pokazuje, prije svega, da područje OODB-a ne samo da nije ušlo u razdoblje zrelosti, već i dalje ostaje konglomerat heterogenih i zbrkanih ideja koje su ujedinjeni na razini slogana, a ne tehnologije.

Članak se temelji na analizi 36 publikacija posvećenih objektno orijentiranim bazama podataka objavljenih u razdoblju 1986.-1995. Stoga, često korištena karakteristika "modernih" OODB-ova nije u potpunosti istinita. Citati, ponekad dati u sadašnjem vremenu, ponekad izgledaju prilično sumnjivo.

Naravno, brojni izvori koristili su se različitom terminologijom, pa je u tom pogledu njihov pregled izrazito šarolik. Osim toga, mnogi su članci dovoljno tehnički složeni da ih citiranje bez navođenja konteksta samo otežava razumijevanje. Najupečatljiviji primjer je pododjeljak o razvoju objektne algebre. Prve tri "temeljne" operacije - udruživanje, razlika, odabir - intuitivno su jasne (iako u stvarnosti autori izvornog članka dopuštaju ne baš očit odabir u obliku poluspajanja), ali posljednje dvije - generiranje i mapa - teško ih je definirati i nisu očite operacije.

Želim istaknuti još jednu čudnu osobinu Baguyina članka. Do 2001. postojao je međunarodni konzorcij Object Data Management Group, koji je objavio tri verzije prijedloga za standardizaciju objektno orijentiranog modela podataka; najnovija verzija - ODMG 3.0 objavljena je 2000. godine. To je jedini dokument koji nudi relativno dosljednu terminologiju i, u određenoj mjeri, objektno orijentirani model podataka. Šteta što Bagui ne koristi ovaj materijal.

Napominjemo da je časopis "DBMS" objavio članak o prvoj verziji standarda, ODMG-93. Pregled standarda ODMG 3.0 možete pronaći u. Također bih preporučio prijevod Object Oriented Database Systems Manifesto i vrlo lijep pregled OODB tehnologije.

Književnost

1. Standard podataka o objektu: ODMG 3.0. R.G.G. Cattel, D.K. Barry, ur., Morgan Kauffmann, 2000.
2. LA. Kaliničenko,. // DBMS, broj 1, 1996.
3. S. D. Kuznjecov. Tri manifesta baze podataka: retrospektiva i perspektiva. Izvještaj na konferenciji "Baze podataka i informacijske tehnologije XXI stoljeća", Moskva, rujan 2003. http://www.citforum.ru/database/articles/manifests.
4. M. Atkinson i sur., // DBMS, broj 4, 1995.
5. Ark Andrejev, Dmitrij Berezkin, Roman Samarev,. // Otvoreni sustavi, broj 3, 2001.

Objektno orijentirane baze podataka: postignuća i izazovi

Uz veliki broj eksperimentalnih projekata (pa čak i komercijalnih sustava) ne postoji općeprihvaćeni objektno orijentirani model podataka, ne zato što nije razvijen cjeloviti model, već zato što ne postoji opći dogovor o usvajanju bilo kojeg modela. Zapravo, postoje specifičniji problemi koji se odnose na razvoj deklarativnih jezika upita, izvršavanje i optimizaciju upita, formuliranje i održavanje ograničenja integriteta, sinkronizaciju pristupa i upravljanje transakcijama itd.

Objektno orijentirani model (slika 3) omogućuje stvaranje, pohranjivanje i korištenje informacija u obliku objekata. Svaki objekt nakon stvaranja dobiva jedinstveni identifikator koji generira sustav, a koji je povezan s objektom tijekom njegovog postojanja i ne mijenja se kada se stanje objekta promijeni.

Slika 3. Objektno orijentirani model podataka

Svaki objekt ima stanje i ponašanje. Stanje objekta je skup vrijednosti za njegove atribute. Ponašanje objekta je skup metoda (programski kod) koji djeluju na stanje objekta. Vrijednost atributa objekta je također neki objekt ili skup objekata. Stanje i ponašanje objekta je kapsulirano u objekt; interakcija objekata temelji se na prijenosu poruka i izvršavanju odgovarajućih metoda.

Mnogi objekti s istim skupom atributa i metoda čine klasu objekata. Objekt bi trebao pripadati samo jednoj klasi (ako ne uzmete u obzir mogućnost nasljeđivanja). Dopuštena je prisutnost primitivnih unaprijed definiranih klasa, čiji objekti-instance nemaju atribute: cijele brojeve, nizove itd. Klasa čiji objekti mogu poslužiti kao vrijednosti atributa objekata druge klase naziva se domena tog atributa.

Dopušteno je kreirati novu klasu na temelju postojeće klase – nasljeđivanje. U ovom slučaju, nova klasa, nazvana podklasa postojeće klase (superklasa), nasljeđuje sve atribute i metode nadklase. Potklasa također može definirati dodatne atribute i metode. Razlikuju se slučajevi jednostavnog i višestrukog nasljeđivanja. U prvom slučaju podklasa se može definirati samo na temelju jedne nadklase, u drugom slučaju može postojati više nadklasa. Ako jezik ili sustav podržava jedno nasljeđivanje klasa, skup klasa tvori hijerarhiju stabla. Dok se održava višestruko nasljeđivanje, klase su povezane u ukorijenjeni usmjereni graf koji se naziva rešetka klasa. Smatra se da objekt potklase pripada bilo kojoj nadklasi te klase.

Objektno orijentirane baze podataka najšire se koriste u područjima kao što su sustavi računalno potpomognutog projektiranja/proizvodnje (CAD/CAM), sustavi za razvoj računalno potpomognutog softvera (CASE), sustavi za upravljanje složenim dokumentima, t.j. u područjima koja nisu tradicionalna za baze podataka. Primjeri objektno orijentiranih DBMS-a su POET, Jasmine, Versant, Iris, Orion.

2.2.4 relacijski model podataka

Godine 1970. američki matematičar E.F. objavio članak koji je bio revolucionaran po svom sadržaju, predlažući korištenje teorije skupova za obradu podataka. Tvrdio je da bi podaci trebali biti vezani prema njihovom logičkom odnosu (npr. unija, presjek), a ne fizičkim pokazivačima. Predložio je jednostavan model podataka u kojem su svi podaci tablično prikazani s jedinstvenim nazivima redaka i stupaca. Te se tablice nazivaju relacije (relacija - relacija), a model je relacijski model podataka izgrađen na konceptu matematičkih relacija i ponekad se naziva i Codd model. Coddovi prijedlozi bili su toliko učinkoviti za sustave baza podataka da je za ovaj model dobio prestižnu Turingovu nagradu za teorijske temelje računarstva.

U relacijskim bazama podataka svi se podaci pohranjuju u jednostavne tablice, podijeljene u retke (zvane zapisi) i stupce (zvana polja), na čijem se sjecištu nalaze informacije o podacima. Općenito, to se može prikazati kao na sl. 4.

Slika 4. Tablica relacijske baze podataka.

Svaki stupac ima svoje ime. Na primjer, u tablici "Roba na zalihama" (slika 5.), nazivi polja su sljedeći: Identifikator, Proizvod, Grupno ime, Skupina, jedinica mjere, Nabavna cijena, Prodajna cijena, Dostupnost zaliha.

Riža. 5. Tablica „Roba na zalihama »

Sve vrijednosti u jednom stupcu su istog tipa. Dakle, polja su različite karakteristike (ponekad kažu - atributi) nekog objekta. Vrijednosti polja u jednom retku odnose se na isti objekt, a različita polja se razlikuju po nazivu.

Svaki zapis se razlikuje po jedinstvenom ključu zapisa, koji su dvije vrste: primarni i sekundarni.

Glavni ključ Je li jedno ili više polja koja jedinstveno identificiraju zapis. Ako se primarni ključ sastoji od jednog polja, naziva se jednostavnim ključem, a ako se sastoji od više polja, naziva se složenim ključem.

Sekundarni ključ Je polje čija se vrijednost može ponoviti u nekoliko zapisa datoteke, odnosno nije jedinstvena.

Vanjski ključ podređena tablica je sekundarni ključ ovog odnosa, koji istovremeno služi i kao primarni ključ u glavnoj tablici. Ako se po vrijednosti primarnog ključa može pronaći samo jedna instanca zapisa, onda ih prema vrijednosti stranog ključa ima nekoliko (slika 6).

Slika 6. Primjer korištenja stranog ključa

Obično se relacijska baza podataka sastoji od nekoliko tablica, budući da Nije moguće u jednoj tablici objediniti sve informacije potrebne zaposlenicima (korisnicima baze podataka) bilo koje organizacije za rješavanje problema.

Indeksiranje je način učinkovitog pristupa zapisu datoteke pomoću ključa. Indeksiranje stvara dodatnu datoteku koja sadrži sve ključne vrijednosti datoteke podataka na uređen način. Za svaki ključ, datoteka indeksa sadrži pokazivač na odgovarajući unos podatkovne datoteke. Pokazivač na zapis u datoteci podataka izravno pristupa tom zapisu.

Za rad s relacijskim bazama podataka trenutno se uobičajeno koristi jezik strukturiranih upita (Structured Query Language - SQL). To je jezik koji se koristi za stvaranje, modificiranje i manipulaciju podacima. SQL nije algoritamski programski jezik. To je informacijsko-logički jezik, temelji se na relacijskoj algebri i podijeljen je u tri dijela:

· Operatori definicije podataka;

Operatori manipulacije podacima (Insert, Select, Update, Delete);

· Operatori definicije pristupa podacima.

1986. godine SQL je usvojen kao ANSI (American National Standards Institute) standard za jezike relacijskih baza podataka. Danas se ova baza podataka smatra standardom za moderne informacijske sustave.

Dakle, tablica je glavni tip strukture podataka relacijskog modela. Struktura tablice određena je zbirkom stupaca. Svaki red tablice sadrži jednu vrijednost u odgovarajućem stupcu. U tablici ne mogu biti dva identična retka, ukupan broj redaka nije ograničen. Stupac je stavka podataka, svaki stupac ima naziv. Jedan ili više atributa čije vrijednosti jedinstveno identificiraju red tablice je ključ tablice.

Prednosti relacijskog modela su:

Jednostavnost i lakoća razumijevanja od strane krajnjeg korisnika - jedina informacijska struktura je tablica;

Prilikom projektiranja relacijske baze podataka primjenjuju se stroga pravila temeljena na matematičkom aparatu;

Potpuna neovisnost podataka. Kada se struktura promijeni, promjene koje je potrebno napraviti u aplikacijskim programima su minimalne;

Za izradu upita i pisanje aplikacijskih programa nije potrebno poznavati specifičnu organizaciju baze podataka u vanjskoj memoriji.

Nedostaci relacijskog modela su:

Relativno mala brzina pristupa i velika količina vanjske memorije;

Poteškoće u razumijevanju strukture podataka zbog pojave velikog broja tablica kao rezultat logičkog dizajna;

Predmetno područje nije uvijek moguće predstaviti u obliku skupa tablica.

Relacijske baze podataka trenutno su najraširenije. Mrežni i hijerarhijski modeli smatraju se zastarjelima, objektno orijentirani modeli još nisu standardizirani i široko rasprostranjeni.