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 pomoću mehanizama sličnih odgovarajućim mogućnostima u objektno orijentiranim programskim jezicima.
Standardni OOM opisan u preporukama standarda ODMG-93 (Object Database Management Group – grupa za upravljanje objektno orijentiranim bazama podataka). Još uvijek nije bilo moguće u potpunosti provesti preporuke ODMG-93. Za ilustraciju ključne ideje Razmotrimo donekle pojednostavljeni model objektno orijentirane baze podataka.
Struktura OO DB je grafički prikazana kao stablo, čiji su čvorovi objekti. Svojstva objekta opisana su nekim standardnim tipom (na primjer, niz - niz) ili korisnički konstruiranim tipom (definiranim kao klasa).
Vrijednost svojstva tipa string je niz znakova. Vrijednost svojstva tipa class je objekt koji je instanca odgovarajuće klase. Svaki objekt instance klase smatra se djetetom objekta u kojem je definiran kao svojstvo. Objekt instance klase pripada svojoj klasi i ima jednog roditelja. Generički odnosi u bazi podataka tvore povezanu hijerarhiju objekata.
Primjer logičke strukture OO DB knjižničarstva prikazan je na sl. 3.14. Ovdje je objekt tipa LIBRARY nadređeni objektima instance klasa PRETPLATNIK, KATALOG i IZDAVANJE. Različiti objekti tipa BOOK koji imaju istog roditelja moraju se razlikovati barem po pristupnom broju (jedinstvenom za svaku instancu knjige), ali imaju iste vrijednosti Svojstva isbn, udk, naslov i Autor.
Sl.3.14. Logička struktura baze podataka knjižničarstva
Logička struktura OO baze podataka je izvana slična strukturi hijerarhijske baze podataka. Glavna razlika između njih je u metodama manipulacije podacima. Za izvođenje radnji na podacima u OOM bazi podataka, primijenite logičke operacije, pojačan objektno orijentiranim mehanizmima enkapsulacije, nasljeđivanja i polimorfizma. Operacije slične SQL naredbama mogu se koristiti u ograničenoj mjeri (na primjer, za stvaranje baze podataka).
Stvaranje i izmjena baze podataka prati automatsko formiranje i naknadno prilagođavanje indeksa (indeksnih tablica) koji sadrže podatke za brza pretraga podaci.
Ukratko razmotrimo koncepte enkapsulacije, nasljeđivanja i polimorfizma u odnosu na OOM baze podataka.
Enkapsulacija ograničava opseg naziva svojstva na objekt u kojem je definirano. Dakle, ako objektu tipa KATALOG dodate svojstvo koje navodi telefonski broj autora knjige i ima naziv telefon, tada ćemo dobiti istoimena svojstva za objekte PRETPLATNIK i KATALOG. Značenje takvog svojstva odredit će objekt u koji je uklopljeno.
nasljedstvo, umjesto toga, proširuje opseg svojstva na sve potomke objekta. Dakle, svim objektima tipa KNJIGA, koji su potomci objekta tipa KATALOG, mogu se dodijeliti svojstva nadređenog objekta: isbn, udk, naslov i Autor. Ako je potrebno proširiti djelovanje mehanizma nasljeđivanja na objekte koji nisu u neposrednom srodstvu (na primjer, između dva potomka istog roditelja), tada se u njihovom zajedničkom pretku definira apstraktno svojstvo tipa abs. Dakle, definicija apstraktnih svojstava ulaznica i soba u objektu LIBRARY uzrokuje da svi podređeni objekti PRETPLATNIKA, KNJIGE i POSUDIOCA naslijede ta svojstva. Nije slučajno da stoga vrijednost imovine ulaznica klase PRETPLATNIK i IZDAVANJE prikazane na slici bit će iste - 00015.
Polimorfizam u objektno orijentiranim programskim jezicima znači sposobnost istog programskog koda za rad s heterogenim podacima. Drugim riječima, to znači dopuštenost u objektima različiti tipovi imaju metode (postupke ili funkcije) sa ista imena. Tijekom izvođenja objektnog programa, iste metode djeluju na različite objekte ovisno o vrsti argumenta. U odnosu na naš OO DB, polimorfizam znači da objekti klase BOOK koji imaju različite roditelje od klase CATALOG mogu imati različit skup svojstava. Shodno tome, programi za rad s objektima klase BOOK mogu sadržavati polimorfni kod.
Pretraživanje u OO DB sastoji se od pronalaženja sličnosti između objekta koji je odredio korisnik i objekata pohranjenih u bazi podataka. Korisnički definirani objekt koji se naziva ciljni objekt (svojstvo objekta tipa goal) općenito može biti podskup cijele hijerarhije objekata pohranjenih u bazi podataka. Ciljni objekt, kao i rezultat izvršenja upita, mogu se pohraniti u samu bazu podataka. Primjer upita o brojevima iskaznica knjižnice i imenima pretplatnika koji su dobili barem jednu knjigu u knjižnici prikazan je na sl. 3.15.
Glavni dostojanstvo OOM podaci u usporedbi s relacijskim imaju mogućnost prikazivanja informacija o složenim odnosima objekata. OOM podaci omogućuju vam identificiranje jednog zapisa baze podataka i određivanje funkcija njihove obrade.
hendikep OOM su visoka konceptualna složenost, neugodnost obrade podataka i mala brzina izvršenje zahtjeva.
 |
sl.3.15. Fragment baze podataka s ciljnim objektom
Vratimo se ponovno problemu naloga, prikazanom u obliku relacijskog podatkovnog modela na sl. 3.8 i razmotrite ga u smislu objektno orijentirane baze podataka. Ukupno postoje tri klase: Klijenti», « Narudžbe" i " Proizvodi". Objekti klase " Klijenti» su specifični kupci; svojstva klase - broj klijenta, ime klijenta, grad, status itd. Metode klase - " Napravi red», « Plati račun" itd. Metoda je neka operacija koja se može primijeniti na objekt; metoda je ono što objekt treba učiniti. Klasa koja odgovara tablici " Detalji narudžbe", nije obavezno. Podaci tablice mogu biti dio klase " Narudžbe". Prisutnost u nastavi Klijenti» metoda « Napravi red" dovodi do interakcije s objektima klasa " Narudžbe" i " Proizvodi". U ovom slučaju, korisnik ne mora znati za ovu interakciju objekata. Korisnik pristupa samo objektu " Narudžbe' i koristi metodu ' Napravi red". Činjenica utjecaja na druge baze podataka može biti skrivena od korisnika. Ako se metoda Napravi red", zauzvrat, odnosi se na metodu " Provjerite kreditnu sposobnost kupca”, tada se ta činjenica također može sakriti od korisnika. U relacijskim bazama podataka, za izvođenje istih funkcija, morate napisati procedure na jeziku Visual Basic za aplikaciju (VBA).
U 1990-ima postojali su eksperimentalni prototipovi OO sustava za upravljanje bazama podataka. Trenutno se takvi sustavi široko koriste. To posebno uključuje sljedeće DBMS-ove: POET (POET Software), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (Ardent Software), ODB-Jupiter (Inteltech Plus Research and Production Center) i Iris , Orion i Postgres.
Tehnologije baze podataka temeljene na gore opisanom MD-u temelje se na statičkom konceptu pohrane informacija, usmjerenom na modeliranje podataka. Međutim, nova područja primjene tehnologije sa složenim, međusobno povezanim objektima baze podataka, kao što su:
Računalno potpomognuto projektiranje;
Automatizirana proizvodnja;
Automatizirani razvoj softver;
Uredski informacijski sustavi;
Multimedijski sustavi;
Geoinformacijski sustavi;
Izdavački sustavi i drugi pokazali su ograničenja statičkog koncepta u smislu modeliranja objekata stvarnog svijeta.
Za nove vrste složenih specijaliziranih aplikacija baza podataka učinkovit je dinamički koncept pohrane informacija, koji omogućuje paralelno modeliranje podataka i procesa koji djeluju na te podatke. To omogućuje da se uzme u obzir semantika predmetnog područja i stoga najprikladnije opiše te primjene. Ovaj se koncept temelji na objektno orijentiranom pristupu koji se široko koristi u razvoju softvera. MD, koji provodi ovaj koncept a temeljen na objektno orijentiranoj paradigmi (OOP), nazvan je objektno orijentirani podatkovni model (OODM).
Konstrukcija OOMD-a temelji se na pretpostavci da se predmetno područje može opisati skupom objekata. Svaki objekt je entitet koji se može jedinstveno identificirati i sadrži atribute koji opisuju stanje objekata "stvarnog svijeta" i njihove pridružene akcije. Trenutno stanje objekta opisuje jedan ili više atributa, koji mogu biti jednostavni i složeni. Jednostavan atribut može imati primitivni tip (na primjer, cijeli broj, niz itd.) i imati doslovnu vrijednost. Složeni atribut može sadržavati zbirke i/ili veze. Atribut veze predstavlja odnos između objekata.
Ključno svojstvo objekta je jedinstvenost njegove identifikacije. Stoga svaki objekt u objektno orijentiranom sustavu mora imati vlastiti identifikator.
Identifikator objekta (OID) je interni način označavanja pojedinačnih objekata u bazi podataka. Korisnici koji rade s upitom ili poslom dijaloga prikaza obično ne vide ove identifikatore. Njih dodjeljuje i koristi sam DBMS. Semantika identifikatora u svakom DBMS-u je drugačija. Može biti nasumična vrijednost ili sadržavati informacije potrebne za pronalaženje objekta u datoteci baze podataka, kao što je broj stranice u datoteci i pomak objekta od njegovog početka. To je identifikator koji bi se trebao koristiti za organiziranje referenci na objekt.
Svi objekti su enkapsulirani, odnosno prikaz ili unutarnja struktura objekta ostaje skrivena od korisnika. Umjesto toga, korisnik samo zna da objekt može obavljati neku funkciju. Na primjer, za objekt WAREHOUSE mogu se primijeniti metode kao što su ACCEPT_ITEM, ISSUE_TOBAP, itd. Prednost enkapsulacije je u tome što vam omogućuje promjenu unutarnjeg prikaza objekata bez redizajniranja aplikacija koje koriste te objekte. Drugim riječima, enkapsulacija podrazumijeva neovisnost podataka.
Objekt enkapsulira podatke i funkcije (metode, prema OOP-u). Metode definiraju ponašanje objekta. Mogu se koristiti za promjenu stanja objekta mijenjanjem vrijednosti njegovih atributa ili za upit vrijednosti odabranih atributa. Na primjer, mogu postojati metode za dodavanje informacija o novoj nekretnini za iznajmljivanje, ažuriranje podataka o plaći zaposlenika ili ispis informacija o određenom proizvodu.
Objekti koji imaju isti skup atributa i odgovaraju na iste poruke mogu se grupirati u Klasa(u literaturi se pojmovi "klasa" i "tip" često koriste kao sinonimi). Svaka takva klasa ima svog predstavnika - objekt, koji je element podataka. Pozivaju se objekti određene klase kopije.
U nekim objektno orijentiranim sustavima, klasa je također objekt i ima svoje atribute i metode koje se pozivaju atributi klase i metode klase.
važni pojmovi OOP poslužiti hijerarhija klasa i hijerarhija spremnika.
klasna hijerarhija implicira mogućnost da svaka klasa, u ovom slučaju nazvana superklasa, ima svoju podklasu. Sljedeći lanac može se navesti kao primjer: svi programeri poduzeća su njegovi zaposlenici, dakle, svaki programer koji je u okviru OODM-a objekt klase PROGRAMMER, on je također zaposlenik, koji zauzvrat , je objekt klase EMPLOYEES. Dakle, PROGRAMERI bi bili podklasa, OSOBLJE bi bila nadklasa. Ali programere također možemo podijeliti na sistemske i aplikacijske programere. Stoga će PROGRAMMERS biti nadklasa podklasama SIS_PROGRAMMERS i APPLIC_PROGRAMMERS. Nastavljajući ovaj lanac dalje, dobivamo hijerarhiju klasa, u kojoj svaki objekt podklase nasljeđuje instance varijabli i metoda odgovarajuće superklase.
Postoji nekoliko vrsta nasljeđivanja – jednokratno, višestruko i selektivno. Singularno nasljeđivanje je kada podklase nasljeđuju od najviše jedne superklase. Višestruko nasljeđivanje - nasljeđivanje iz više od jedne superklase. Selektivno nasljeđivanje dopušta podklasi nasljeđivanje ograničena količina svojstva svoje nadklase.
Nasljeđivanje instance varijable se zove strukturalno nasljeđe, nasljeđivanje metode - nasljeđe ponašanja, ali mogućnost korištenja iste metode za različite klase, odnosno primjene različite metode s istim imenom za različite klase se zove polimorfizam.
Objektno orijentirana arhitektura također ima drugu vrstu hijerarhije - hijerarhija spremnika. Sastoji se u činjenici da neki objekti mogu biti pojmovno sadržani unutar drugih. Dakle, objekt klase DEPARTMENT mora sadržavati javnu varijablu HEAD, koja je referenca na objekt klase EMPLOYEE koji odgovara voditelju odjela, a također mora sadržavati referencu na skup referenci na objekte koji odgovaraju zaposlenicima koji rade u ovaj odjel.
U nekim objektno orijentiranim sustavima, klasa je također objekt i ima svoje vlastite atribute i metode. Opće karakteristike Klasa je opisana svojim atributima. Metode klase objekata svojevrsni su analogni svojstvima objekata u stvarnom svijetu. Svaki predmet povezan s nekim određena klasa, ima ova svojstva. Stoga, kada se kreira objekt, potrebno je deklarirati klasu kojoj pripada kako bi se definirala njegova inherentna svojstva.
Korisnik i objekt komuniciraju putem poruka. Kao odgovor na svaku poruku, sustav izvršava odgovarajuću metodu.
Svi priključci u objektni model implementiraju se pomoću referentnih atributa, koji se obično implementiraju kao OID-ovi.
Odnosi u relacijskoj bazi podataka predstavljeni su podudaranjem primarnih i stranih ključeva. U samoj bazi ne postoje strukture za formiranje asocijacija između tablica, poveznice se koriste po potrebi prilikom povezivanja tablica. Nasuprot tome, odnosi su okosnica objektno orijentirane baze podataka jer svaki objekt uključuje ID-ove objekata s kojima je povezan.
U OOMD se mogu implementirati ne samo tradicionalne veze, već i veze zbog nasljeđivanja.
Odnos jedan na jedan (1:1) između objekata A i B implementira se dodavanjem referentnog atributa na objektu B objektu A i (za održavanje referentnog integriteta) referentnog atributa na objektu A objektu B.
Odnos jedan prema više (1:M) između objekata A i B implementira se dodavanjem referentnog atributa objektu B objektu A i atributa koji sadrži skup veza između objekta A i B (na primjer, dodaje se referentni atribut B (OID2, OID3 ...) objektu A i instanci objekta B s OID2, OID3, ... dodaje se referentni atribut A: OID1.
Odnos više-prema-više (M:N) između objekata A i B implementira se dodavanjem atributa koji sadrži skup poveznica na svaki objekt.
U OODM-u možete koristiti odnos "cijeli dio", koji opisuje da objekt jedne klase sadrži objekte drugih klasa kao svoje dijelove. U slučaju proizvodne baze podataka, postojao bi odnos "cijeli dio" između klase PROIZVOD i klasa DIO i SKLOP. Ova veza je varijanta odnosa više-prema-više s posebnom semantikom. Odnos cijeli dio implementiran je kao i svaki drugi odnos više-prema-više, sa skupom pridruženih identifikatora objekta. Međutim, on, za razliku od uobičajenog odnosa mnogo prema mnogima, ima drugačije semantičko značenje.
Budući da objektno orijentirana paradigma podržava nasljeđivanje, moguće je koristiti odnos "je" i odnos "proširuje" u OODM. Odnos "jest", također poznat kao odnos generalizacije-specijalizacije, stvara hijerarhiju nasljeđivanja u kojoj su podklase posebni slučajevi nadklasa. To dopušta da se ne opisuju ponovno naslijeđene značajke. Kada se koristi odnos "proširuje", podklasa proširuje funkcionalnost superklase umjesto da bude ograničena na njezin poseban slučaj.
Razmotrimo kako su komponente kao što su ograničenja integriteta i operacije nad podacima implementirane u OOMD.
Značajke ovih komponenti određene su specifičnostima modela. Ovu specifičnost u OOMD-u diktiraju prije svega interni koncepti kao što je enkapsulacija objekta, tj. tajnost unutarnje strukture, pristup podacima samo putem unaprijed definiranih metoda, hijerarhija klasa i hijerarhija spremnika.
Specifičnosti OOMD također su diktirane specifičnostima objekta. Očituje se u potrebi grupiranja objekata u klase. Svaki objekt je uključen u jednu ili drugu klasu ovisno o zadatku, a jedan objekt može pripadati nekoliko klasa odjednom (na primjer, obitelji PROGRAMERI i VISOKO PLAĆAJUĆI). Još jedna specifičnost objekta je da može "trčati" iz jedne klase (podklase) u drugu. Tako SUSTAVNI PROGRAMER s vremenom može postati PRIMIJENJENI PROGRAMER. Dakle, hijerarhija klasa nije analogna hijerarhijskom modelu, kao što se prije moglo činiti, već zahtijeva da sustav može promijeniti lokaciju svakog objekta unutar hijerarhije klasa, na primjer, pomaknuti se "gore" ili "dolje" unutar ovu hijerarhiju. Ali moguć je i složeniji proces - sustav mora osigurati mogućnost da se objekt u bilo kojem trenutku pripoji (odvoji) od proizvoljnog vrha hijerarhije.
Važna uloga U OOMD igraju ograničenja na integritet poveznica. Da bi veze u objektno orijentiranom DM-u radile, identifikatori objekata na obje strane veze moraju se podudarati. Na primjer, ako postoji odnos između ZAPOSLENIKA i njihove DJECE, tada mora postojati neko jamstvo da kada se objekt koji opisuje dijete umetne u objekt koji predstavlja zaposlenika, ID zaposlenika se dodaje odgovarajućem objektu. Ova vrsta integriteta veze, donekle analogna referentnom integritetu u modelu relacijskih podataka, uspostavlja se uz pomoć povratnih veza. Kako bi se osigurao integritet veza, dizajneru je dana posebna sintaksa potrebna za određivanje lokacije obrnutog identifikatora objekta. Odgovornost je dizajnera da postavi ograničenja na integritet odnosa (kao i referentni integritet u relacijskoj bazi podataka).
U OOMD-u se i opis podataka i manipulacija njima odvijaju korištenjem istog objektno orijentiranog proceduralnog jezika.
ODMG (Object Database Management Group) bavi se problemima standardizacije tehnologije objektnih baza podataka. Razvio je objektni model (ODMG 2.0 usvojen je u rujnu 1997.) koji definira standardni model za semantiku objekata baze podataka. Ovaj model je važan jer definira ugrađenu semantiku koju objektno orijentirani DBMS (OODBMS) razumije i može implementirati. Struktura knjižnica i aplikacija koje koriste ovu semantiku moraju biti prenosive među različitim OODBMS-ima koji podržavaju dati objektni model podataka. Glavne komponente ODMG arhitekture su: Object Model (OM), Object Definition Language (ODL), Object Query Language (OQL) i mogućnost povezivanja na C++, Java i Smalltalk.
Objektni model podataka u skladu sa standardom ODMG 2.0 karakteriziraju sljedeća svojstva:
Osnovni građevni blokovi su objekti i literali. Svaki objekt ima jedinstveni identifikator. Literal nema vlastiti identifikator i ne može postojati zasebno kao objekt. Literali su uvijek ugrađeni u objekte i ne mogu se pojedinačno referencirati;
Objekti i literali razlikuju se po vrsti. Svaki tip ima vlastitu domenu koju dijele svi objekti i literali ove vrste. Tipovi također mogu imati ponašanje. Ako tip ima neko ponašanje, tada svi objekti tog tipa imaju isto ponašanje. U praksi, tip može biti klasa iz koje je objekt kreiran, sučelje ili jednostavan tip podataka (kao što je cijeli broj). Objekt se može smatrati primjerkom tipa;
Stanje objekta definirano je skupom trenutnih vrijednosti implementiranih skupom svojstava. Ova svojstva mogu biti atributi objekta ili odnosi između objekta i jednog ili više drugih objekata;
Ponašanje objekta definirano je skupom operacija koje se mogu izvesti na objektu ili na samom objektu. Operacije mogu imati popis ulaznih i izlaznih parametara, od kojih svaki ima strogo definiran tip. Svaka operacija također može vratiti tipizirani rezultat;
Definicija baze podataka pohranjena je u shemi napisanoj u jeziku za definiranje objekata (ODL). Baza podataka pohranjuje objekte, dopuštajući njihovo dijeljenje između različitih korisnika i aplikacija.
DBMS bazirani na OODM nazivaju se objektno orijentirani DBMS (OODBMS). Ovi DBMS-ovi se nazivaju 3. generacija DBMS-a* (* Povijest razvoja modela pohrane podataka često se dijeli na tri faze (generacije): prva generacija (kasne 1960-ih - rane 70-e) - hijerarhijska i mrežni model; druga generacija (otprilike 1970-1980-ih) - relacijski model; treća generacija (1980-ih - ranih 2000-ih) - objektno orijentirani modeli.).
Danas se objektno orijentirane baze podataka koriste u raznim organizacijama za rješavanje širokog spektra problema. Analiza i generalizacija prikupljenog iskustva u području podataka informacijske tehnologije omogućila je identificiranje aplikacija u kojima je korištenje objektno orijentiranih baza podataka opravdano:
Aplikacija se sastoji od veliki broj dijelovi koji međusobno djeluju. Svaki od njih ima svoje ponašanje, koje ovisi o ponašanju drugih;
Sustav mora obraditi velike količine nestrukturiranih ili složenih struktura podataka;
Aplikacija će pristupiti podacima na predvidljiv način, tako da navigacijska priroda objektno orijentirane baze podataka neće biti značajan nedostatak;
Potreba za neplaniranim zahtjevima je ograničena;
Struktura pohranjenih podataka je hijerarhijske ili slične prirode.
NA ovaj trenutak Na tržištu softvera postoje mnogi objektno orijentirani DBMS-ovi. U tablici. 10.6 prikazuje neke od komercijalni sustavi ove klase.
Tablica 10.6
Moderni komercijalni OODBMS,
njihove proizvodne tvrtke i područja primjene
Jedan od temeljne razlike objektne baze podataka od relacijskih je sposobnost stvaranja i korištenja novih tipova podataka. Važna značajka OODBMS je da stvaranje novog tipa ne zahtijeva modifikaciju osnovne jezgre i temelji se na principima objektno orijentiranog programiranja.
OODBMS kernel je optimiziran za rad s objektima. Njegove prirodne operacije su predmemoriranje objekta, verzija objekta, odvajanje prava pristupa specifičnih objekata. OODBMS karakterizira veća izvedba u operacijama koje zahtijevaju pristup i dohvaćanje podataka upakiranih u objekte, u usporedbi s relacijskim DBMS-ovima, za koje potreba za dohvaćanjem povezanih podataka dovodi do dodatnih internih operacija.
Od velike važnosti za OODBMS je mogućnost premještanja objekata iz jedne baze podataka u drugu.
Dok je stvarao razne aplikacije na temelju OODBMS-a važna je ugrađena struktura klasa pojedinog DBMS-a. Knjižnica razreda obično ne podržava samo sve standardne vrste podataka, ali i prošireni skup multimedijskih i drugih složenih vrsta podataka, kao što su video, zvuk, slijed animacijskih okvira. U nekim OODBMS stvorene su biblioteke klasa koje omogućuju pohranjivanje i pretraživanje cijelog teksta dokumentarnih informacija (na primjer, Jasmine, ODB-Jupiter). Primjer strukture osnovne klase prikazan je na sl. 10.17.
Glavno mjesto u njemu zauzima klasa TOdbObject koja sadrži sve potrebna svojstva te metode za upravljanje pristupom bazi podataka i izvođenje indeksiranja. Sve druge klase nadjačavaju njegove metode, dodajući provjeru valjanosti tipa koji implementiraju i određeni indekser.
Kao što se može vidjeti sa sl. 10.17, u strukturi postoje različite klase usmjerene na obradu dokumentarnih informacija - TOdbText, TOdbDocument, TODBTextDocument itd. Svaki dokument predstavljen je zasebnim objektom. Tako je osigurana prirodnost pohranjivanja dokumenata. jedan od kritične operacije je traženje dokumenata na zahtjev. Za većinu klasa implementirana je mogućnost traženja objekata prema vrijednosti određenog ključa. Za klasu TOdbText, mogućnost oblikovanja upit za pretraživanje frazom napisanom prirodnim jezikom.
Klasa TOdbDocument je posebna, može sadržavati objekte različitih tipova. Sastoji se od polja od kojih svako ima ime i povezano je s objektom određene vrste. Prisutnost ove klase daje korisniku mogućnost proširenja skupa tipova. Izmjenom objekta spremnika (dokumenta) možete postaviti određeni skup polja i dobiti novu vrstu dokumenta.
Na temelju ODB-Jupitera, programeri OODBMS-a stvorili su potpuno opremljen sustav za pronalaženje informacija ODB-Text, koji ima univerzalnu strukturu pohranjenih podataka i snažan mehanizam pretraživanja. Sustav ODB-Text je alat za zbirnu obradu dokumenata i održavanje korporativne arhive. Na popisu moguće primjene nabrojimo automatizaciju računovodstva za tijek rada modernog ureda, izgradnju referentnih i informacijskih sustava (slično poznatim pravnim bazama podataka), održavanje mrežnih baza podataka, kadrovske evidencije, bibliografije itd.
41. Konstruktivne značajke primijenjenih IS. Faze razvoja IS-a. (Tema 11, str. 100-103).
11.1.3. Značajke projektiranja sustava primijenjenih IC
Prilikom izgradnje (odabira, prilagodbe) informacijskog sustava, možete koristiti dva glavna koncepta, dva glavna pristupa (treći koncept je njihova kombinacija):
1. Orijentacija na probleme koje je potrebno riješiti uz pomoć ovog informacijskog sustava, tj. pristup usmjeren na problem (ili induktivni pristup);
2. fokus na tehnologiju koja je dostupna (ažurirana) u danom sustavu, okruženju, tj. pristup usmjeren na tehnologiju (ili deduktivni pristup).
Izbor koncepta ovisi o strateškim (taktičkim) i (ili) dugoročnim (kratkoročnim) kriterijima, problemima, resursima.
Ako se najprije proučavaju mogućnosti raspoložive tehnologije, a potom utvrđuju stvarni problemi koji se uz njihovu pomoć mogu riješiti, tada se treba osloniti na tehnološki orijentiran pristup.
Ako se prvo identificiraju stvarni problemi, a zatim uvede tehnologija dovoljna za rješavanje tih problema, tada se treba osloniti na problemski pristup.
Pritom oba koncepta izgradnje informacijskog sustava ovise jedan o drugom: uvođenje novih tehnologija mijenja probleme koji se rješavaju, a promjena problema koji se rješavaju dovodi do potrebe za uvođenjem novih tehnologija; Oboje utječe na odluke koje se donose.
Projektiranje (razvoj) sustava i korištenje bilo kojeg primijenjenog (korporativnog) informacijskog sustava mora proći kroz sljedeći životni ciklus informacijskog sustava:
- predprojektna analiza (iskustvo u stvaranju drugih sličnih sustava, prototipovi, razlike i značajke sustava koji se razvija, itd.), analiza vanjskih manifestacija sustava;
– unutarsustavna analiza, interna analiza (analiza podsustava sustava);
- sustav (morfološki) opis (reprezentacija) sustava (opis cilja sustava, sistemski odnosi i veze sa okoliš, drugi sustavi i resursi sustava- materijalni, energetski, informacijski, organizacijski, ljudski, prostorni i vremenski);
– određivanje kriterija primjerenosti, učinkovitosti i održivosti (pouzdanosti);
– funkcionalni opis podsustava sustava (opis modela, algoritama za funkcioniranje podsustava);
- izrada prototipa (opis prototipa) sustava, evaluacija interakcije podsustava sustava (razvoj izgleda - implementacija podsustava s pojednostavljenim funkcionalni opisi, procedure i testiranje interakcije ovih modela u cilju ispunjavanja cilja sustava), a moguće je koristiti i "modele" kriterija za primjerenost, održivost, učinkovitost;
- "montaža" i testiranje sustava - implementacija punopravnog funkcionalni podsustavi i kriteriji, vrednovanje modela prema formuliranim kriterijima;
– rad sustava;
– određivanje ciljeva daljnjeg razvoja sustava i njegove primjene;
- održavanje sustava - pojašnjenje, modifikacija, proširenje mogućnosti sustava u načinu rada (u svrhu njegove evolucije).
Ove faze su glavne za reinženjering informacijskih sustava.
Razvoj korporativnog informacijskog sustava, u pravilu, provodi se za dobro definirano poduzeće. Značajke predmetne djelatnosti poduzeća, naravno, utjecat će na strukturu informacijskog sustava. Ali u isto vrijeme, strukture različitih poduzeća općenito su slične jedna drugoj. Svaka organizacija, bez obzira na vrstu svoje djelatnosti, sastoji se od niza odjela koji izravno provode jednu ili drugu vrstu djelatnosti tvrtke. I to vrijedi za gotovo sve organizacije, bez obzira na vrstu djelatnosti kojom se bave.
Stoga se svaka organizacija može smatrati skupom međusobno povezanih elemenata (pododjela), od kojih svaki može imati vlastitu, prilično složenu strukturu. Odnosi između odjela također su prilično složeni. U općem slučaju postoje tri vrste veza između poslovnih jedinica:
Funkcionalne veze - svaki odjel obavlja određene vrste poslova unutar jednog poslovnog procesa;
Informacijske komunikacije - postrojbe razmjenjuju informacije (dokumenti, faksovi, pismene i usmene zapovijedi i dr.);
Vanjske komunikacije - neke jedinice su u interakciji s vanjskim sustavima, a njihova interakcija također može biti informacijska i funkcionalna.
Zajedničkost strukture različitih poduzeća omogućuje nam formuliranje nekih zajedničkih načela za izgradnju korporativnih informacijskih sustava.
Općenito, proces razvoja informacijskog sustava može se promatrati s dvije točke gledišta:
Po vremenu, ili po fazama životni ciklus sustav koji se razvija. NA ovaj slučaj razmatra dinamičku organizaciju razvojnog procesa, opisanu u terminima ciklusa, faza, ponavljanja i faza.
Informacijski sustav poduzeća razvija se kao projekt. Mnoge značajke projektnog menadžmenta i faza razvoja projekta (faze životnog ciklusa) su uobičajene i ne ovise ne samo o predmetnom području, već io prirodi projekta (nije važno radi li se o inženjerskom ili gospodarskom projektu). ). Stoga ima smisla prvo razmotriti seriju opća pitanja upravljanje projektima.
Projekt je vremenski ograničena, svrhovita promjena u zasebnom sustavu s inicijalno jasno definiranim ciljevima čije postizanje određuje dovršetak projekta, kao i s utvrđenim zahtjevima za rokove, rezultate, rizik, utrošak sredstava i resursa, i organizacijsku strukturu.
Obično je za složen koncept (što je, posebice, koncept projekta) teško dati jednoznačnu formulaciju koja u potpunosti pokriva sve značajke uvedenog koncepta. Stoga gornja definicija ne tvrdi da je jedinstvena i potpuna.
Sljedeći glavni značajke projekt kao kontrolni objekt:
Varijabilnost – svrhovito prenošenje sustava s postojećeg na neki
željeno stanje, opisano u smislu ciljeva projekta;
Ograničenje krajnjeg cilja;
ograničeno trajanje;
Ograničeni proračun;
Potrebni ograničeni resursi;
Novost za poduzeće za koje se projekt provodi;
Složenost - prisutnost velikog broja čimbenika koji izravno ili neizravno utječu na napredak i rezultate projekta;
Pravni i organizacijska podrška- stvaranje specifične organizacijske strukture za vrijeme trajanja projekta.
Učinkovitost rada postiže se upravljanjem procesom provedbe projekta, čime se osigurava raspodjela resursa, koordinacija slijeda radova koji se izvode te kompenzacija unutarnjih i vanjskih smetnji.
Sa stajališta teorije sustava upravljanja, projekt kao objekt upravljanja mora biti vidljiv i upravljiv, odnosno izdvajaju se neke karakteristike po kojima je moguće stalno pratiti napredovanje projekta (observability property). Osim toga, potrebni su mehanizmi pravovremenog utjecaja na tijek realizacije projekta (svojstvo upravljivosti).
Svojstvo upravljivosti posebno je relevantno u uvjetima neizvjesnosti i varijabilnosti predmetnog područja, koji često prate projekte razvoja informacijskih sustava.
Svaki projekt, bez obzira na složenost i količinu posla koji je potreban za njegovu realizaciju, prolazi kroz određene faze razvoja: od stanja kada „još nema projekta“ do stanja kada „projekta više nema“. Skup faza razvoja od nastanka ideje do potpunog završetka projekta obično se dijeli na faze (etape, etape).
Postoje određene razlike u određivanju broja faza i njihovog sadržaja, jer te karakteristike uvelike ovise o uvjetima provedbe pojedinog projekta i iskustvu glavnih sudionika. Međutim, logika i glavni sadržaj procesa razvoja informacijskog sustava u gotovo svim slučajevima su zajednički.
Mogu se razlikovati sljedeće faze razvoja informacijskog sustava:
Formiranje koncepta;
Izrada tehničkih specifikacija;
Oblikovati;
proizvodnja;
Puštanje sustava u rad.
Razmotrimo svaki od njih detaljnije. Druga i dijelom treća faza obično se nazivaju fazama projektiranja sustava, a zadnje dvije (ponekad uključuju i fazu projektiranja) su faze implementacije.
Faza koncepta
Formiranje ideja, postavljanje ciljeva;
Formiranje ključnog projektnog tima;
Proučavanje motivacije i zahtjeva kupca i ostalih sudionika;
Prikupljanje i analiza osnovnih podataka postojeće stanje;
Definiranje osnovnih zahtjeva i ograničenja, potrebnih materijalnih, financijskih i radnih resursa;
Usporedna procjena alternativa;
Podnošenje prijedloga, njihovo ispitivanje i odobravanje.
Izrada tehničkog prijedloga
Razvoj glavnog sadržaja projekta, osnovne strukture projekta;
Izrada i odobravanje projektnog zadatka;
Planiranje, dekompozicija osnovnog konstrukcijskog modela projekta;
Izrada procjena i proračuna za projekt, određivanje potreba za resursima;
Razvoj kalendarski planovi i povećani radni raspored;
Potpisivanje ugovora s kupcem;
Puštanje u rad sredstava komunikacije sudionika projekta i nadzor nad odvijanjem radova.
Oblikovati
U ovoj fazi se najviše utvrđuju podsustavi, njihove međusobne veze učinkovite načine izvođenje projekta i korištenje resursa. Karakteristični radovi ove faze:
Provedba temeljnih projektantskih radova;
Razvoj privatnih projektni zadatak;
Provedba idejnog rješenja;
Izrada tehničkih specifikacija i uputa;
Prikaz izrade projekta, ispitivanja i odobrenja.
Razvoj
U ovoj fazi se provodi koordinacija i operativna kontrola rada na projektu, izrađuju se, kombiniraju i testiraju podsustavi. Glavni sadržaj:
Obavljanje poslova na razvoju softvera;
Izvođenje priprema za implementaciju sustava;
Kontrola i regulacija glavnih pokazatelja projekta.
Puštanje sustava u rad
U ovoj fazi provode se testiranja, probni rad sustava u realnim uvjetima, pregovara se o rezultatima projekta i mogućim novim ugovorima. Glavne vrste rada:
Složeni testovi;
42. Koncept životnog ciklusa IP-a. (Tema 11, str. 103-105).
Uz veliki broj eksperimentalnih projekata (pa čak i komercijalnih sustava) ne postoji općeprihvaćeni objektno orijentirani model podataka, i to ne zato što nije razvijen niti jedan cjeloviti model, već zato što ne postoji opća suglasnost o prihvaćanju bilo kojeg modela. U stvari, postoje specifičnija pitanja koja se odnose na dizajniranje deklarativnih jezika upita, izvršavanje i optimiziranje upita, formuliranje i održavanje ograničenja integriteta, sinkronizaciju pristupa i upravljanje transakcijama, i tako dalje.
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 promijeni stanje objekta.
sl.3. Objektno orijentirani podatkovni model
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 također je neki objekt ili skup objekata. Stanje i ponašanje objekta su kapsulirani u objektu; interakcija objekata temelji se na prijenosu poruka i izvršavanju odgovarajućih metoda.
Skup objekata s istim skupom atributa i metoda tvori klasu objekta. Objekt mora pripadati samo jednoj klasi (ako ne uzmete u obzir mogućnost nasljeđivanja). Dopušteno je imati primitivne unaprijed definirane klase čiji objekti instance nemaju atribute: cijeli brojevi, nizovi itd. Klasa čiji objekti mogu poslužiti kao vrijednosti atributa objekata druge klase naziva se domenom tog atributa.
Dopušteno je generiranje nove klase na temelju već postojeće klase – nasljeđivanje. U ovom slučaju, nova klasa, koja se naziva podklasa postojeće klase (superklasa), nasljeđuje sve atribute i metode nadklase. Dodatno, dodatni atributi i metode mogu se definirati u podklasi. Postoje slučajevi jednostavnog i višestrukog nasljeđivanja. U prvom slučaju, potklasa se može definirati samo na temelju jedne superklase, u drugom slučaju može postojati više superklasa. Ako jezik ili sustav podržava nasljeđivanje jedne klase, skup klasa čini hijerarhiju stabla. Kada podržavaju višestruko nasljeđivanje, klase su povezane u usmjereni graf s korijenom, koji se naziva rešetka klasa. Smatra se da objekt podklase pripada bilo kojoj nadklasi te klase.
Objektno orijentirane baze podataka koje se najčešće koriste nalaze se u područjima kao što su računalno potpomognuto projektiranje/proizvodnja (CAD/CAM), sustavi automatizirani razvoj softver (CASE), složeni sustavi za upravljanje 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 podatkovni model
Godine 1970. američki matematičar Codd E.F. objavio revolucionaran članak u svom sadržaju, predlažući korištenje teorije skupova za obradu podataka. Tvrdio je da podatke treba povezivati prema njihovim logičkim odnosima (npr. unija, raskrižje), a ne fizičkim pokazivačima. Predložio je jednostavan model podataka u kojem su svi podaci sažeti u tablice koje se sastoje od redaka i stupaca s jedinstvenim nazivima. Te se tablice nazivaju relacije (relatio - odnos), a model - relacijski model temelji se na konceptu matematičkih odnosa i ponekad se naziva i Coddovim modelom. Coddovi prijedlozi bili su toliko učinkoviti za sustave baza podataka da je za ovaj model nagrađen prestižnom Turingovom nagradom za teoriju računalstva.
U relacijskim bazama podataka svi su podaci pohranjeni u jednostavnim tablicama, podijeljenim u retke (nazivaju se zapisi) i stupce (nazivaju se polja), na čijem sjecištu se nalaze informacije o podacima. NA opći pogled to se može prikazati kao na sl. četiri.
sl.4. Tablica relacijske baze podataka.
Svaki stupac ima svoje ime. Na primjer, u tablici "Roba na zalihi" (Sl. 5.), nazivi polja su sljedeći: Identifikator, Proizvod, Grupno ime, Skupina, jedinica mjere, Nabavna cijena, Prodajna cijena, Dostupnost: u skladištu.
Riža. 5. Tablica „Roba u skladištu »
Sve vrijednosti u jednom stupcu su istog tipa. Dakle, polja su razne karakteristike(ponekad zvani atributi) objekta. Vrijednosti polja u istom retku odnose se na isti objekt, a različita polja imaju različita imena.
Svaki zapis se razlikuje po jedinstvenom ključu zapisa, a postoje dvije vrste: primarni i sekundarni.
glavni ključ je 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ženi ključ.
sekundarni ključ je polje čija se vrijednost može ponavljati u više zapisa datoteke, odnosno nije jedinstveno.
Vanjski ključ podređena tablica je sekundarni ključ ove relacije, koji ujedno obavlja funkcije primarnog ključa u glavnoj tablici. Ako se prema vrijednosti primarnog ključa može pronaći jedna jedina instanca zapisa, onda ih prema vrijednosti stranog ključa postoji nekoliko (slika 6).
sl.6. Primjer korištenja stranog ključa
Relacijska baza podataka se u pravilu sastoji od nekoliko tablica jer nije moguće u jednu tablicu objediniti sve informacije potrebne zaposlenicima (korisnicima baze podataka) bilo koje organizacije za rješavanje problema.
Način učinkovitog pristupa ključem zapisu datoteke je indeksiranje. Indeksiranje stvara dodatna datoteka A koji redom sadrži sve ključne vrijednosti podatkovne datoteke. Za svaki ključ, indeksna datoteka sadrži pokazivač na odgovarajući unos u podatkovnoj datoteci. Pokazivač na unos u podatkovnoj datoteci omogućuje izravan pristup tom unosu.
Za rad s relacijskim bazama podataka sada se često koristi Structured Query Language (SQL). To je jezik koji se koristi za stvaranje, modificiranje i manipuliranje podacima. SQL nije algoritamski jezik programiranje. Ovo je informacijsko-logički jezik, temelji se na relacijskoj algebri i podijeljen je u tri dijela:
operatori definicije podataka;
operatori za manipulaciju podacima (Insert, Select, Update, Delete);
· operatori definicije pristupa podacima.
Godine 1986. SQL je usvojen kao ANSI (American National Standards Institute) standard za jezike relacijskih baza podataka. Danas dana baza smatra se standardom za moderne informacijske sustave.
Dakle, tablica je glavna vrsta strukture podataka relacijskog modela. Struktura tablice definirana je skupom stupaca. Svaki redak tablice sadrži jednu vrijednost u odgovarajućem stupcu. Tablica ne može imati dva identična reda, ukupni broj redaka nije ograničeno. Stupac je element podataka, svaki stupac ima ime. Jedan ili više atributa čije vrijednosti jedinstveno identificiraju red tablice su ključ tablice.
Prednosti relacijskog modela su:
Jednostavnost i lakoća razumijevanja krajnji korisnik- jedina informacijska struktura je tablica;
Pri projektiranju relacijske baze podataka primjenjuju se stroga pravila, temeljena na matematičkom aparatu;
Potpuna neovisnost podataka. Prilikom promjene strukture, promjene koje je potrebno izvršiti u aplikacijski programi ah, minimalno;
Za izradu upita i pisanje aplikacijskih programa nije potrebno poznavati specifičnu organizaciju baze podataka u vanjskoj memoriji.
Nedostaci relacijskog modela su:
Relativno niska 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;
Ne može se uvijek predmetno područje predstaviti kao skup tablica.
Trenutno se najviše koriste relacijske baze podataka. Mrežni i hijerarhijski modeli smatraju se zastarjelima, objektno orijentirani modeli još nisu standardizirani i nemaju široku primjenu.
Objektno orijentirana baza podataka(OOBD) - baza podataka u kojoj su podaci modelirani u obliku objekata, njihovih atributa, metoda i klasa.
Objektno orijentirane baze podataka obično se preporučuju za one slučajeve gdje je potrebna obrada podataka visokih performansi sa složenom strukturom.
OODB manifest predlaže obvezne karakteristike koje svaki OODB mora zadovoljiti. Njihov izbor temelji se na 2 kriterija: sustav mora biti objektno orijentiran i biti baza podataka.
Obvezne karakteristike
1. Podrška za složene objekte. Sustav mora predvidjeti mogućnost kreiranja složenih objekata korištenjem konstruktora složenih objekata. Potrebno je da konstruktori objekata budu ortogonalni, odnosno da se bilo koji konstruktor može primijeniti na bilo koji objekt.
2. Podrška individualnosti objekata. Svi objekti moraju imati jedinstveni identifikator koji je neovisan o njihovim vrijednostima atributa.
3. Podrška za enkapsulaciju. Ispravna enkapsulacija se postiže zahvaljujući činjenici da programeri imaju pravo pristupa samo specifikaciji sučelja metoda, a podaci i implementacija metoda skriveni su unutar objekata.
4. Podrška za vrste i klase. Potrebno je da OODB podržava barem jedan koncept razlike između tipova i klasa. (Izraz "tip" je prikladniji za koncept apstraktnog tipa podataka. U programskim jezicima, varijabla se deklarira sa svojim tipom. Kompajler može koristiti ove informacije za provjeru izvršenja varijabla operacija za kompatibilnost s njegovom vrstom, što vam omogućuje da jamčite ispravnost softvera. S druge strane, klasa je predložak za stvaranje objekata i pruža metode koje se mogu primijeniti na te objekte. Stoga se koncept "klase" više odnosi na vrijeme izvođenja nego na vrijeme kompajliranja.)
5. Podrška za nasljeđivanje tipova i klasa od njihovih predaka. Podtip, ili podklasa, mora naslijediti atribute i metode od svog supertipa, odnosno superklase.
6. Preopterećenje u kombinaciji s potpunim vezanjem. Metode se moraju primijeniti na objekte različitih tipova. Implementacija metode mora ovisiti o vrsti objekata na koje se metoda primjenjuje. Da bi se osigurala ova funkcionalnost, vezanje naziva metoda u sustavu ne bi se trebalo odvijati do vremena izvođenja programa.
7. Računska cjelovitost. Jezik za rukovanje podacima trebao bi biti programski jezik opće namjene.
8. Skup tipova podataka mora biti proširiv. Korisnik mora imati sredstva za stvaranje novih tipova podataka na temelju skupa unaprijed definiranih vrste sustava. Štoviše, između načina korištenja sustavnih i prilagođene vrste podaci ne bi trebali biti nikakvih razlika.
OO DBMS
Objektno orijentirane baze podataka- baze podataka u kojima su informacije predstavljene u obliku objekata, kao u objektno orijentiranim programskim jezicima.
Bilo da koristite sustave za upravljanje objektno orijentiranim bazama podataka (OODBMS) ili ne pravi projekti danas? Kada ih treba koristiti, a kada ne?
Ovdje Prednosti koristeći OODBMS:
· Ne postoji problem nedosljednosti između modela podataka u aplikaciji i baze podataka (neusklađenost impedancije). Svi podaci pohranjuju se u bazu podataka u istom obliku kao u modelu aplikacije.
· Nije potrebno zasebno održavati podatkovni model na strani DBMS-a.
· Svi objekti na razini izvora podataka strogo su tipizirani. Nema više naziva nizova stupaca! Refaktoriranje objektno orijentirane baze podataka i koda koji radi s njom sada je automatizirano, a ne monoton i dosadan proces.
ODMG standard
Prvi manifest formalno je bio samo članak predstavljen na Konferencija o objektno orijentiranim i deduktivnim bazama podataka skupina pojedinaca. Kao što ste mogli vidjeti u prethodnom pododjeljku, zahtjevi Manifesta bili su emocionalni, a ne eksplicitno navedeni. Godine 1991. formiran je konzorcij ODMG (tada je ova kratica otkrivena kao Grupa za upravljanje bazom podataka objekata, ali je kasnije dobio šire tumačenje - Grupa za upravljanje objektnim podacima). Konzorcij ODMG usko je povezan s mnogo većim konzorcijem OMG ( Grupa za upravljanje objektima), koja je osnovana dvije godine ranije. Glavni izvorni cilj ODMG-a bio je razviti industrijski standard za objektno orijentirane baze podataka ( opći model). Kao osnova je usvojen osnovni objektni model OMG COM ( Osnovni objektni model). Tijekom više od deset godina postojanja ODMG je objavio tri osnovne verzije standard, od kojih se najnoviji zove ODMG 3.0. 16
Smiješno je da iako je ODMG (prema autoru) napustio OMG, u posljednjih godina neki OMG standardi oslanjaju se na ODMG objektni model. Konkretno, OCL specifikacija temelji se na ODMG modelu ( Jezik ograničenja objekta), koji je dio cjelokupne specifikacije jezika UML 1.4 (i UML 2.0). U ovom članku nemamo namjeru provesti detaljnu usporedbu OMG i ODMG pristupa i uputiti zainteresirane čitatelje na Enciklopedija Kogalovsky i materijale s web stranica ovih konzorcija. Ograničavamo se Sažetak glavne ideje sadržane u standardu ODMG-3.
ODMG arhitektura
Predložena ODMG arhitektura prikazana je na sl. 2.1. Ova arhitektura definira način na koji se podaci pohranjuju i različite vrste korisničkog pristupa ovoj „skladištu podataka” 17 . Unificiranoj pohrani podataka može se pristupiti iz jezika za definiranje podataka, jezika za upite i niza jezika za manipulaciju podacima. 18 Na sl. 2.1 ODL znači Object Definition Language (jezik za definiranje objekta), OQL - Object Query Language (jezik upita za objekte) i OML- Object Manipulation Language (jezik za rukovanje objektima).
Riža. 2.1. ODMG arhitektura
Središnje mjesto u arhitekturi je model podataka A koji predstavlja organizacijsku strukturu u kojoj su pohranjeni svi podaci kojima upravlja OODBMS. Jezik definicije objekta, upitni jezik i manipulativni jezici dizajnirani su na takav način da se sve njihove mogućnosti temelje na modelu podataka. Arhitektura dopušta postojanje niza implementacijskih struktura za pohranu modeliranih podataka, ali važan je zahtjev da svi softverske biblioteke a svi alati za podršku pružaju se u objektno orijentiranom okviru i moraju biti usklađeni s podacima.
Glavne komponente arhitekture su sljedeće.
- Model podataka objekta. Svi podaci koje pohranjuje OODBMS strukturirani su u smislu konstrukata modela podataka. Točna semantika svih koncepata definirana je u podatkovnom modelu (pogledajte dolje za više detalja).
- Jezik za definiranje podataka (ODL). Sheme baze podataka opisane su u terminima ODL jezika, u kojem su konstrukcije modela podataka instancirane u obliku definicijskog jezika. ODL vam omogućuje da opišete shemu kao skup sučelja tipa objekta, što uključuje opis svojstava tipa i odnosa između njih, kao i imena operacija i njihovih parametara. ODL nije potpuni programski jezik; implementacija tipova mora biti urađena na jednom od jezika OML kategorije. Osim toga, ODL je virtualan jezika u smislu da ODMG standard ne zahtijeva njegovu implementaciju softverski proizvodi OODBMS za koje se smatra da su usklađeni sa standardom. Prihvatljivo je da ovi proizvodi podržavaju ekvivalentne definicijske jezike koji uključuju sve značajke ODL-a, ali su prilagođeni specifičnostima određenog sustava. Međutim, prisutnost specifikacije ODL jezika u ODMG standardu je važna jer jezik specificira svojstva modela podataka.
- Jezik upita za objekte (ODL). Jezik ima sintaksu sličnu SQL jezik, ali se oslanja na semantiku ODMG objektnog modela. Standard dopušta izravnu upotrebu OQL-a i njegovu ugradnju u jedan od jezika OML kategorije.
Relacijski model podataka
Gotovo sve moderni sustavi na temelju relacijski(relacijski) modeli upravljanja bazom podataka. Ime relacijski zbog činjenice da svaki zapis u takvoj bazi podataka sadrži informacije koje se odnose samo na jedan određeni objekt.
NA relacijski DBMS svi obrađeni podaci su prikazani u obliku ravnih tablica. Informacije o objektima određene vrste prikazane su u tablični oblik: u stupcima tablice koncentrirani su razni atributi objekata, a redovi su namijenjeni reduciranju opisa svih atributa na pojedinačne instance objekata.
Model nastao u fazi infološkog modeliranja, u najviše zadovoljava principe relacionizma. Međutim, da bi se ovaj model doveo u relacijski, potrebno je izvršiti proceduru tzv normalizacija.
Teorija normalizacije operira s pet normalne forme. Ovi su obrasci dizajnirani da smanje redundantnost informacija, tako da svaki sljedeći normalni obrazac mora zadovoljiti zahtjeve prethodnog i nekih dodatni uvjeti. U praktičnom dizajnu baze podataka, četvrti i peti oblik se obično ne koriste. Ograničili smo se na prva četiri normalna oblika.
Uvedimo koncepte potrebne za razumijevanje procesa dovođenja modela u relacijsku shemu.
Stav- apstrakcija opisanog objekta kao skupa njegovih svojstava. Tijekom infološke faze dizajna, razgovarali smo o apstrakciji objekata i dodijelili im neka svojstva. Sada, s konceptualnim dizajnom, prelazimo na sljedeću razinu apstrakcije. U ovoj fazi objekti kao takvi više ne postoje. Radimo sa skupom svojstava koja definiraju objekt.
Instanca odnosa- skup vrijednosti svojstava određenog objekta.
glavni ključ- identifikacijski skup atributa, tj. vrijednost ovih atributa je jedinstvena u ovo poštovanje. Ne postoje dvije instance relacije koje sadrže iste vrijednosti u primarnom ključu.
jednostavan atribut- atribut čije su vrijednosti nedjeljive.
Složeni atribut- atribut čija je vrijednost skup vrijednosti od nekoliko razna svojstva objekta ili više vrijednosti istog svojstva.
Suštinski pojmovi.
Domena
Koncept domene specifičniji je za baze podataka, iako ima neke analogije s podtipovima u nekim programskim jezicima. U najopćenitijem obliku, domena se definira specificiranjem nekog osnovnog tipa podataka kojem elementi domene pripadaju i proizvoljnog booleov izraz Primijenjeno na element tipa podataka. Ako ovaj Booleov izraz ima vrijednost true, tada je podatkovni element element domene.
Najispravnije intuitivno tumačenje pojma domene je razumijevanje domene kao valjanog potencijalnog skupa vrijednosti danog tipa. Na primjer, domena "Imena" u našem primjeru definirana je na osnovni tip znakovni nizovi, ali samo oni nizovi koji mogu predstavljati ime mogu biti uključeni u njegovu vrijednost (konkretno, takvi nizovi ne mogu započeti mekim znakom).
Također treba napomenuti semantičko značenje koncepta domene: podaci se smatraju usporedivima samo ako pripadaju istoj domeni. U našem primjeru, vrijednosti domena "Brojevi prolaza" i "Brojevi grupe" su cjelobrojnog tipa, ali nisu usporedive. Imajte na umu da većina relacijskih DBMS-ova ne koristi koncept domene, iako je već podržan u Oracle V.7.
Postrelacijskimodel
Klasični relacijski model pretpostavlja nedjeljivost podataka pohranjenih u poljima zapisa tablice. Postrelacijski model je prošireni relacijski model koji uklanja ograničenje nedjeljivosti podataka. Model dopušta polja s više vrijednosti - polja čije se vrijednosti sastoje od podvrijednosti. Razmatran je skup vrijednosti viševrijednih polja nezavisna tablica ugrađen u glavnu tablicu.
Na sl. 2.6, na primjeru podataka o fakturama i robi za usporedbu, prikazan je prikaz istih podataka pomoću relacijskih (a) i postrelacijskih (b) modela. Sa slike je vidljivo da postrelacijski model u usporedbi s relacijskim modelom učinkovitije pohranjuje podatke, a tijekom obrade neće biti potrebno izvoditi operaciju spajanja podataka iz dvije tablice.
Fakture
|
N faktura |
Kupac |
N faktura |
Količina |
||
Nadzemni
|
N faktura |
Kupac |
Količina |
|
Riža. 2.6. Strukture podataka relacijskih i postrelacijskih modela
Budući da postrelacijski model dopušta pohranjivanje nenormaliziranih podataka u tablice, javlja se problem osiguranja cjelovitosti i konzistentnosti podataka. Ovaj problem se rješava uključivanjem odgovarajućih mehanizama u DBMS.
Dostojanstvo Postrelacijski model je sposobnost predstavljanja skupa povezanih relacijskih tablica pomoću jedne postrelacijske tablice. To osigurava visoku preglednost prezentacije informacija i povećanje učinkovitosti njihove obrade.
hendikep Postrelacijski model je složenost rješavanja problema osiguranja cjelovitosti i konzistentnosti pohranjenih podataka.
Razmatrani post-relacijski model podataka podržava univerzalni DBMS. Ostali DBMS-ovi koji se temelje na post-relacijskom podatkovnom modelu također uključuju sustave Bubba i Dasdb.
Višedimenzionalni model
Višedimenzionalni pristup predstavljanju podataka pojavio se gotovo istovremeno s relacijskim pristupom, ali je počeo jačati interes za višedimenzionalni DBMS masovni karakter od sredine 90-ih. Poticaj je bio 1993. članak E. Codda. Formulirao je 12 osnovnih zahtjeva za sustave klase OLAP (OnLine Analytical Processing), od kojih su najvažniji vezani uz mogućnosti konceptualne reprezentacije i obrade višedimenzionalnih podataka.
U razvoju koncepata informacijskih sustava mogu se razlikovati sljedeća dva pravca:
Operativni (transakcijski) procesni sustavi;
Sustavi analitičke obrade (sustavi za podršku odlučivanju).
Relacijski DBMS namijenjeni su informacijskim sustavima operativne obrade informacija i vrlo su učinkoviti u tom području. U sustavima analitičke obrade pokazali su se pomalo nespretnim i nedovoljno fleksibilnim. Višedimenzionalni DBMS-ovi su ovdje učinkovitiji.
Višedimenzionalni DBMS su visoko specijalizirani DBMS dizajnirani za interaktivnu analitičku obradu informacija. Glavni koncepti koji se koriste u ovim DBMS-ovima su agregabilnost, povijesnost i predvidljivost.
Agregabilnost podatak znači razmatranje informacije na različitim razinama njezine generalizacije. NA informacijski sustavi stupanj detalja u prezentaciji informacija za korisnika ovisi o njegovoj razini: analitičar, korisnik, menadžer, menadžer.
Povijesnost podataka podrazumijeva osiguranje visoke razine statičnosti samih podataka i njihovih odnosa, kao i obveznu vezanost podataka za vrijeme.
Predvidljivost obrada podataka uključuje postavljanje funkcija predviđanja i njihovu primjenu na različite vremenske intervale.
Višedimenzionalnost podatkovnog modela ne znači višedimenzionalnost digitalne vizualizacije podataka, već višedimenzionalni logički prikaz informacijske strukture u opisu iu operacijama manipulacije podacima.
U usporedbi s relacijskim modelom, višedimenzionalna organizacija podataka ima veću vidljivost i sadržaj informacija. Za ilustraciju na sl. Slika 2.7 prikazuje relacijske (a) i višedimenzionalne (b) prikaze istih podataka o obujmu prodaje automobila.
Osnovni koncepti višedimenzionalnih modela podataka: dimenzija i ćelija.
Mjerenje je skup podataka iste vrste koji tvore jednu od strana hiperkocke. U višedimenzionalnom modelu, dimenzije igraju ulogu indeksa koji služe za identifikaciju specifičnih vrijednosti u ćelijama hiperkocke.
Ćelija je polje čija je vrijednost jedinstveno određena fiksnim skupom mjerenja. Tip polja se najčešće definira kao numerički. Ovisno o tome kako se formiraju vrijednosti određene ćelije, ona može biti varijabla (vrijednosti se mijenjaju i mogu se učitati iz vanjskog izvora podataka ili generirati programski) ili formula (vrijednosti, poput ćelija formule proračunske tablice, izračunavaju se prema unaprijed određenim formulama).
Riža. 2.7. Relacijski i multidimenzionalni prikaz podaci
U primjeru na sl. 2,7 b svaka vrijednost ćelije Obujam prodaje jedinstveno određena kombinacijom vremenske dimenzije Mjesec prodaje i modeli automobila. U praksi je često potrebno više mjerenja. Primjer trodimenzionalnog modela podataka prikazan je na sl. 2.8.
Riža. 2.8. Primjer 3D modela
Postojeći višedimenzionalni DBMS-ovi koriste dvije glavne sheme organizacije podataka: hiperkubičnu i polikubičnu.
NA polikubični Shema pretpostavlja da se nekoliko hiperkocki različitih dimenzija i dimenzija mogu definirati u bazi podataka kao lica. Primjer sustava koji podržava polikubnu verziju baze podataka je Oracle poslužitelj. Express poslužitelj.
Kada hiperkubičan Shema pretpostavlja da su sve ćelije definirane istim skupom mjerenja. To znači da ako postoji nekoliko hiperkocki u bazi podataka, sve imaju istu dimenziju i iste dimenzije.
Glavni dostojanstvo višedimenzionalni podatkovni model je pogodnost i učinkovitost analitičke obrade velikih količina vremenski povezanih podataka.
hendikep Višedimenzionalni model podataka je njegova glomaznost za najjednostavnije zadatke konvencionalne online obrade informacija.
Primjeri sustava koji podržavaju višedimenzionalne modele podataka su Essbase, Media Multi-matrix, Oracle Express Server, Cache. Postoje softverski proizvodi, poput Media / MR, koji vam omogućuju istovremeni rad s višedimenzionalnim i relacijskim bazama podataka.
Objektno orijentirani model
U objektno orijentiranom modelu, prilikom prezentiranja podataka, moguće je identificirati pojedinačne zapise baze podataka. Odnosi se uspostavljaju između zapisa i njihovih obradnih funkcija pomoću mehanizama sličnih odgovarajućim mogućnostima u objektno orijentiranim programskim jezicima.
Standardizirani objektno orijentirani model opisan je u preporukama standarda ODMG-93 (Object Database Management Group - objektno orijentirana grupa za upravljanje bazom podataka).
Razmotrimo pojednostavljeni model objektno orijentirane baze podataka. Struktura objektno orijentirane baze podataka grafički se prikazuje kao stablo čiji su čvorovi objekti. Svojstva objekata opisana su nekim standardnim ili korisnički konstruiranim tipom (definiranim kao klasa). Vrijednost svojstva tipa class je objekt koji je instanca odgovarajuće klase. Svaki objekt instance klase smatra se djetetom objekta u kojem je definiran kao svojstvo. Objekt instance klase pripada svojoj klasi i ima jednog roditelja. Generički odnosi u bazi podataka tvore povezanu hijerarhiju objekata. Primjer logičke strukture objektno orijentirane knjižničarske baze podataka prikazan je na sl. 2.9. Ovdje objekt tipa Knjižnica je roditelj objekata instance klase Pretplatnik, Katalog i izručenje. Objekti raznih vrsta knjige a mogu imati iste ili različite roditelje. Objekti tipa Knjiga, koji imaju istog nadređenog, moraju se razlikovati barem po pristupnom broju (jedinstvenom za svaku instancu knjige), ali imati iste vrijednosti svojstava isb n udk, imena e i Autor.
Logička struktura objektno orijentirane baze podataka je izvana slična strukturi hijerarhijske baze podataka. Glavna razlika između njih je u metodama manipulacije podacima.
Za izvođenje akcija nad podacima u razmatranom modelu baze podataka koriste se logičke operacije, poboljšane objektno orijentiranim mehanizmima enkapsulacije, nasljeđivanja i polimorfizma.
Enkapsulacija ograničava opseg naziva svojstva na objekt u kojem je definirano. Dakle, ako u objektu tipa Katalog dodajte svojstvo koje navodi telefonski broj autora knjige i ima naslov telefon, tada ćemo dobiti istoimena svojstva za objekte Pretplatnik i Katalog. Značenje takvog svojstva odredit će objekt u koji je uklopljeno.
Nasljedstvo, naprotiv, proširuje opseg svojstva na sve potomke objekta. Dakle, za sve objekte tipa Knjiga, koji su potomci objekta tipa Katalog, možete dodijeliti svojstva nadređenog objekta: isbn, udk, titula i Autor. Ako je potrebno proširiti mehanizam nasljeđivanja na objekte koji nisu neposredni srodnici (na primjer, između dva potomka istog roditelja), tada se apstraktno svojstvo tipa trbušnjaci. Dakle, definicija apstraktnih svojstava ulaznica i soba u objektu Knjižnica uzrokuje da ta svojstva naslijede svi podređeni objekti Pretplatnik, Knjiga i Problemi a. Nije slučajno da stoga vrijednost imovine ulaznica klase Pretplatnik i izručenje prikazano na sl. 2.9 su isti - 00015.
Polimorfizam u objektno orijentiranim programskim jezicima znači sposobnost istog programskog koda za rad s heterogenim podacima. Drugim riječima, to znači da objekti različitih tipova mogu imati metode (procedure ili funkcije) s istim imenima. Tijekom izvođenja objektnog programa, iste metode djeluju na različite objekte ovisno o vrsti argumenta. U odnosu na primjer koji razmatramo, polimorfizam znači da objekti klase Knjiga imati različite roditelje iz razreda Katalog, može imati drugačiji skup svojstava. Stoga programi za rad s objektima klase Knjiga može sadržavati polimorfni kod.
Pretraživanje u objektno orijentiranoj bazi podataka sastoji se u pronalaženju sličnosti između objekta koji je naveo korisnik i objekata pohranjenih u bazi podataka.
Riža. 2.9. Logička struktura baze podataka knjižničarstva
Glavni dostojanstvo objektno orijentirani model podataka u usporedbi s relacijskim jest mogućnost prikaza informacija o složenim odnosima objekata. Objektno orijentirani podatkovni model omogućuje vam identificiranje jednog zapisa baze podataka i definiranje funkcija za njihovu obradu.
nedostatke Objektno orijentirani model je visoka konceptualna složenost, neugodnost obrade podataka i mala brzina izvršenja upita.
Objektno orijentirani DBMS-ovi uključuju POET, Jasmine, Versant, O2, ODB-Jupiter, Iris, Orion, Postgres.
