U objektno orijentisanom modelu (OOM), prilikom predstavljanja podataka, moguće je identifikovati pojedinačne zapise baze podataka. Odnosi se uspostavljaju između zapisa baze podataka i njihovih funkcija obrade korištenjem mehanizama sličnih odgovarajućim sredstvima u objektno orijentiranim programskim jezicima.
Standard OOM opisano u preporukama standarda ODMG-93 (Object Database Management Group - grupa za upravljanje objektno orijentisanim bazama podataka). Još uvijek nije bilo moguće u potpunosti implementirati preporuke ODMG-93. Za ilustraciju ključne ideje Razmotrimo donekle pojednostavljeni model objektno orijentisane baze podataka.
Struktura OO DB grafički je predstavljena kao stablo, čiji su čvorovi objekti. Svojstva objekta su opisana nekim standardnim tipom (na primjer, string - string) ili tipom koji je konstruirao korisnik (definiran 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 podređenim objektu u kojem je definiran kao svojstvo. Objekt instance klase pripada njenoj klasi i ima jednog roditelja. Generički odnosi u bazi podataka formiraju povezanu hijerarhiju objekata.
Primjer logičke strukture OO DB bibliotekarstva prikazan je na sl. 3.14. Ovdje je objekt tipa LIBRARY roditelj objekata instance klasa SUBSCRIBER, CATALOG i ISSUANCE. Različiti objekti tipa BOOK koji imaju isti roditelj moraju se razlikovati najmanje po pristupnom broju (jedinstven za svaku instancu knjige), ali imaju iste vrijednosti svojstva isbn, udk, naslov I autor.
Sl.3.14. Logička struktura bibliotekarske baze podataka
Logička struktura OO baze podataka je spolja slična strukturi hijerarhijske baze podataka. Glavna razlika između njih je u metodama manipulacije podacima. Za izvođenje radnji nad podacima u OOM bazi podataka, primijeniti logičke operacije, poboljšan objektno orijentiranim mehanizmima enkapsulacije, nasljeđivanja i polimorfizma. Operacije slične SQL naredbama mogu se koristiti u ograničenoj mjeri (na primjer, za kreiranje baze podataka).
Kreiranje i modifikacija baze podataka je praćeno automatskim formiranjem i naknadnim prilagođavanjem indeksa (tabela indeksa) koji sadrže informacije za brza pretraga podaci.
Razmotrimo ukratko koncepte inkapsulacije, nasljeđivanja i polimorfizma u odnosu na OOM baze podataka.
Enkapsulacija ograničava opseg imena svojstva na objekt u kojem je definirano. Dakle, ako dodate svojstvo objektu tipa KATALOG koji navodi broj telefona autora knjige i ima naziv telefon, tada ćemo dobiti svojstva istog imena za objekte SUBSCRIBER i CATALOG. Značenje takvog svojstva će biti određeno objektom u koji je inkapsulirano.
nasljedstvo, umjesto toga, proširuje opseg svojstva na sve potomke objekta. Dakle, svim objektima tipa BOOK, 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 neposredni srodnici (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 SUBSCRIBER, BOOK i LENDER nasljeđuju ova svojstva. Nije slučajno da se stoga vrijednost imovine ulaznica klase SUBSCRIBER i ISSUANCE prikazane na slici će biti iste - 00015.
Polimorfizam u objektno orijentisanim programskim jezicima znači sposobnost istog programskog koda da radi sa heterogenim podacima. Drugim riječima, to znači prihvatljivost u objektima različite vrste imaju metode (procedure ili funkcije) sa ista imena. Tokom izvršavanja objektnog programa, iste metode rade na različitim objektima ovisno o tipu 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 sa objektima klase BOOK mogu sadržati polimorfni kod.
Pretraživanje u OO DB-u sastoji se u pronalaženju sličnosti između objekta koji je odredio korisnik i objekata pohranjenih u bazi podataka. Korisnički definirani objekt nazvan ciljni objekt (svojstvo objekta tipa goal) općenito može biti podskup cijele hijerarhije objekata pohranjene u bazi podataka. Ciljni objekat, kao i rezultat izvršenja upita, mogu se pohraniti u samoj bazi podataka. Primjer upita o brojevima bibliotečkih kartica i imenima pretplatnika koji su dobili barem jednu knjigu u biblioteci prikazan je na Sl. 3.15.
Main dostojanstvo OOM podaci u poređenju sa relacionim su sposobnost prikazivanja informacija o složenim odnosima objekata. OOM podaci vam omogućavaju da identifikujete jedan zapis baze podataka i odredite funkcije njihove obrade.
nedostatak OOM su visoka konceptualna složenost, neugodnost obrade podataka i mala brzina izvršenje zahtjeva.
 |
Sl.3.15. Fragment baze podataka sa ciljnim objektom
Vratimo se ponovo problemu narudžbi, predstavljenom u obliku relacionog modela podataka na sl. 3.8 i razmotriti ga u smislu objektno orijentisane baze podataka. Ukupno postoje tri razreda: Klijenti», « Naredbe" i " Roba". Objekti klase " Klijenti» su specifični kupci; svojstva klase - broj klijenta, ime klijenta grad, status, itd. Metode klase - " Kreirajte red», « Plati račun" itd. Metoda je neka operacija koja se može primijeniti na objekt; metoda je ono što objekat treba da uradi. Klasa koja odgovara tabeli " Detalji narudžbe", nije potrebno. Podaci tablice mogu biti dio klase " Naredbe". Prisustvo na času Klijenti» metoda « Kreirajte red"dovodi do interakcije sa objektima klasa" Naredbe" i " Roba". U ovom slučaju korisnik ne mora znati za ovu interakciju objekata. Korisnik pristupa samo objektu " Naredbe'i koristi metodu' Kreirajte red". Činjenica utjecaja na druge baze podataka može se sakriti od korisnika. Ako je metoda Kreirajte red"zauzvrat, odnosi se na metodu" Provjerite kreditnu sposobnost kupaca“, tada se i ova činjenica može sakriti od korisnika. U relacionim bazama podataka, da biste izvršili iste funkcije, morate napisati procedure na jeziku Visual basic za aplikaciju (VBA).
Tokom 1990-ih postojali su eksperimentalni prototipovi sistema za upravljanje bazama podataka OO. Trenutno se takvi sistemi široko koriste. Ovo posebno uključuje sljedeće DBMS: POET (POET softver), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (Ardent Software), ODB-Jupiter (Inteltech Plus istraživačko-proizvodni centar) i Iris, Orion i Postgres.
Tehnologije baza podataka zasnovane na gore opisanom MD baziraju se na statičkom konceptu skladištenja informacija, fokusiranom na modeliranje podataka. Međutim, nova područja primjene tehnologije sa složenim, međusobno povezanim objektima baze podataka, kao što su:
Kompjuterski potpomognut dizajn;
Automatizirana proizvodnja;
Automatizirani razvoj softvera;
Uredski informacijski sustavi;
Multimedijski sustavi;
Geoinformacioni sistemi;
Izdavački sistemi i drugi su pokazali ograničenja statičkog koncepta u smislu modeliranja objekata stvarnog svijeta.
Za nove tipove složenih specijalizovanih aplikacija baza podataka, dinamički koncept skladištenja informacija je efikasan, omogućavajući paralelno modeliranje podataka i procesa koji deluju na ove podatke. To omogućava da se uzme u obzir semantika predmetnog područja i da se stoga najadekvatnije opiše ove primjene. Ovaj koncept se zasniva na objektno orijentisanom pristupu koji se široko koristi u razvoju softvera. MD, koji implementira ovaj koncept i zasnovan na objektno orijentisanoj paradigmi (OOP), nazvan je objektno orijentisani model podataka (OODM).
Konstrukcija OOMD-a zasniva se na pretpostavci da se predmetno područje može opisati skupom objekata. Svaki objekt je jedinstveno prepoznatljiv entitet koji sadrži atribute koji opisuju stanje objekata "stvarnog svijeta" i njihove povezane radnje. Trenutno stanje objekta opisuje se jednim ili više atributa, koji mogu biti jednostavni ili složeni. Jednostavan atribut može imati primitivni tip (na primjer, cijeli broj, string, itd.) i uzeti literalnu vrijednost. Kompozitni atribut može sadržavati kolekcije i/ili veze. Atribut veze predstavlja odnos između objekata.
Ključno svojstvo objekta je jedinstvenost njegove identifikacije. Stoga svaki objekt u objektno orijentiranom sistemu mora imati svoj vlastiti identifikator.
Identifikator objekta (OID) je interni način u bazi podataka za označavanje pojedinačnih objekata. Korisnici koji rade sa zadatkom dijaloga upita ili prikaza obično ne vide ove identifikatore. Njih dodeljuje i koristi sam DBMS. Semantika identifikatora u svakom DBMS-u je različita. Može biti ili 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 inkapsulirani, odnosno, reprezentacija ili unutrašnja struktura objekta ostaje skrivena od korisnika. Umjesto toga, korisnik zna samo da objekt može obavljati neku funkciju. Na primjer, za objekat WAREHOUSE mogu se primijeniti metode kao što su ACCEPT_ITEM, ISSUE_TOBAP, itd. Prednost enkapsulacije je u tome što vam omogućava da promijenite interni prikaz objekata bez redizajniranja aplikacija koje koriste ove objekte. Drugim riječima, enkapsulacija podrazumijeva neovisnost podataka.
Objekt enkapsulira podatke i funkcije (metode, prema OOP). Metode definiraju ponašanje objekta. Mogu se koristiti za promjenu stanja objekta promjenom vrijednosti njegovih atributa ili za ispitivanje vrijednosti odabranih atributa. Na primjer, mogu postojati metode za dodavanje informacija o novoj nekretnini za iznajmljivanje, ažuriranje informacija o plati zaposlenika ili štampanje 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 naizmjenično). Svaka takva klasa ima svog predstavnika - objekat, koji je element podataka. Pozivaju se objekti određene klase kopije.
U nekim objektno orijentisanim sistemima, klasa je takođe objekat i ima svoje atribute i metode koje se nazivaju atributi klase i metode klase.
važnih koncepata OOP servis hijerarhiju klasa i hijerarhiju kontejnera.
hijerarhija klasa implicira mogućnost da svaka klasa, u ovom slučaju nazvana superklasa, ima svoju podklasu. Kao primjer može se navesti sljedeći lanac: svi programeri preduzeća su njegovi zaposleni, dakle, svaki programer koji je u okviru OODM-a objekat klase PROGRAMMER, on je ujedno i zaposlenik, koji je zauzvrat , je objekt klase EMPLOYEES. Dakle, PROGRAMI bi bili potklasa, OSOBLJE bi bila superklasa. Ali programeri se također mogu podijeliti na sistemske i aplikativne programere. Stoga će PROGRAMMERS biti nadklasa za potklase SIS_PROGRAMMERS i APPLIC_PROGRAMMERS. Nastavljajući dalje ovaj lanac, dobijamo hijerarhiju klasa, u kojoj svaki objekat potklase nasljeđuje instance varijabli i metoda odgovarajuće superklase.
Postoji nekoliko vrsta nasljeđivanja - jednostruko, višestruko i selektivno. Singularno nasljeđivanje je kada podklase nasljeđuju od najviše jedne superklase. Višestruko nasljeđivanje - nasljeđivanje od više od jedne superklase. Selektivno nasljeđivanje dozvoljava podklasi da nasljeđuje ograničena količina svojstva svoje superklase.
Poziva se nasljeđivanje instance varijable strukturno nasleđe, nasljeđivanje metoda - naslijeđe ponašanja, ali mogućnost korištenja iste metode za različite klase, odnosno primjene različite metode sa istim imenom za različite klase se zove polimorfizam.
Objektno orijentisana arhitektura takođe ima drugu vrstu hijerarhije - hijerarhija kontejnera. Sastoji se u činjenici da neki objekti mogu biti konceptualno sadržani u drugima. Dakle, objekat klase DEPARTMENT mora sadržavati javnu varijablu HEAD, koja je referenca na objekt klase ZAPOSLENIK koji odgovara šefu odjela, a također mora sadržavati referencu na skup referenci na objekte koji odgovaraju zaposlenicima koji rade u ovo odjeljenje.
U nekim objektno orijentisanim sistemima, klasa je takođe objekat i ima svoje atribute i metode. Opće karakteristike Klasa je opisana svojim atributima. Metode klase objekata su neka vrsta analoga svojstava objekata u stvarnom svijetu. Svaki objekat se odnosi na neke određene klase, ima ova svojstva. Stoga, kada je objekat kreiran, potrebno je deklarisati klasu kojoj on pripada da bi se definisala njegova inherentna svojstva.
Korisnik i objekt komuniciraju putem poruka. Kao odgovor na svaku poruku, sistem izvršava odgovarajući metod.
Svi priključci u objektni model implementirani su pomoću referentnih atributa, koji se obično implementiraju kao OID-ovi.
Relacije u relacionoj bazi podataka su predstavljene podudaranjem primarnih i stranih ključeva. U samoj bazi podataka ne postoje strukture za formiranje asocijacija između tabela; veze se koriste po potrebi prilikom povezivanja tabela. Nasuprot tome, odnosi su okosnica objektno orijentirane baze podataka jer svaki objekt uključuje ID-ove objekata s kojima je povezan.
U OOMD-u se mogu implementirati ne samo tradicionalne veze, već i veze zbog nasljeđivanja.
Veza jedan na jedan (1:1) između objekata A i B implementira se dodavanjem referentnog atributa na objektu B objektu A i (da bi se održao referentni integritet) 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 prema objektu A do objekta B (na primjer, dodan je referentni atribut B (OID2, OID3 ...) objektu A, a instance objekta B sa OID2, OID3, ... se dodaje referentni atribut A: OID1.
Odnos mnogo-prema-više (M:N) između objekata A i B implementira se dodavanjem atributa koji sadrži skup veza za 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 PRODUCT i klasa PART i ASSEMBLY. Ova veza je varijanta odnosa mnogo-prema-više sa posebnom semantikom. Odnos cijeli dio implementira se 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 više prema mnogo, 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-u. Odnos "je", poznat i kao odnos generalizacija-specijalizacija, stvara hijerarhiju nasljeđivanja u kojoj su podklase posebni slučajevi nadklasa. Ovo omogućava da se ne opisuju ponovo naslijeđene karakteristike. Kada se koristi odnos "proširuje", potklasa proširuje funkcionalnost superklase umjesto da se ograničava na njen poseban slučaj.
Hajde da razmotrimo kako se komponente kao što su ograničenja integriteta i operacije nad podacima implementiraju u OOMD.
Karakteristike ovih komponenti određene su specifičnostima modela. Ovu specifičnost u OOMD-u diktiraju prvenstveno takvi interni koncepti kao što su enkapsulacija objekata, tj. tajnost interne strukture, pristup podacima samo putem unaprijed definiranih metoda, hijerarhija klasa i hijerarhija kontejnera.
Specifičnosti OOMD-a također su diktirane specifičnostima objekta. Ona se manifestuje u potrebi grupisanja objekata u klase. Svaki objekat je uključen u jednu ili drugu klasu u zavisnosti od zadatka, a jedan objekat može pripadati nekoliko klasa odjednom (na primer familije PROGRAMERI i VISOKO PLAĆAĆI). Još jedna specifična karakteristika objekta je da može "trčati" iz jedne klase (podklase) u drugu. Dakle, SISTEMSKI PROGRAMER može na kraju postati PRIMIJENJENI PROGRAMER. Dakle, hijerarhija klasa nije analogna hijerarhijskom modelu, kao što se ranije moglo činiti, već zahtijeva od sistema da može promijeniti lokaciju svakog objekta unutar hijerarhije klasa, na primjer, pomjeriti se "gore" ili "dolje" unutar datu hijerarhiju. Ali moguć je i složeniji proces – sistem mora obezbijediti sposobnost objekta da se prikači (odvoji) na proizvoljan vrh hijerarhije u bilo kom trenutku.
Važna uloga U OOMD-u se igraju ograničenja integriteta veza. Da bi veze u objektno orijentiranom DM-u funkcionirale, identifikatori objekata na obje strane veze moraju se podudarati. Na primjer, ako postoji povezanost između ZAPOSLENIKA i njihove DJECE, onda mora postojati neka garancija da kada se objekt koji opisuje dijete umetne u objekat koji predstavlja zaposlenika, ID zaposlenika se dodaje odgovarajućem objektu. Ova vrsta integriteta veze, donekle analogna referentnom integritetu u relacionom modelu podataka, uspostavlja se uz pomoć povratnih veza. Da bi se osigurao integritet veza, dizajneru se daje posebna sintaksa potrebna da specificira lokaciju obrnutog identifikatora objekta. Odgovornost dizajnera je da postavi ograničenja na integritet odnosa (kao i referentni integritet u relacionoj bazi podataka).
U OOMD-u se i opis podataka i manipulacija njima odvijaju koristeći isti objektno orijentirani proceduralni jezik.
ODMG (Object Database Management Group) bavi se problemima standardizacije tehnologije objektnih baza podataka. Razvio je objektni model (ODMG 2.0 je usvojen u septembru 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 biblioteka i aplikacija koje koriste ovu semantiku mora biti prenosiva između različitih OODBMS-a koji podržavaju dati model podataka objekta. Glavne komponente ODMG arhitekture su: model objekata (OM), jezik definicije objekata (ODL), jezik upita objekata (OQL) i mogućnost povezivanja na C++, Java i Smalltalk.
Objektni model podataka u skladu sa ODMG 2.0 standardom karakteriziraju slijedeća svojstva:
Osnovni gradivni blokovi su objekti i literali. Svaki objekat ima jedinstveni identifikator. Literal nema svoj identifikator i ne može postojati zasebno kao objekat. Literali su uvijek ugrađeni u objekte i ne mogu se pojedinačno referencirati;
Objekti i literali se razlikuju po vrsti. Svaki tip ima svoju vlastitu domenu koju dijele svi objekti i literali ovog tipa. Tipovi takođe mogu imati ponašanje. Ako tip ima neko ponašanje, onda 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 instancom tipa;
Stanje objekta je definirano 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 je definirano skupom operacija koje se mogu izvesti na objektu ili na samom objektu. Operacije mogu imati listu ulaznih i izlaznih parametara, od kojih svaki ima strogo definiran tip. Svaka operacija također može vratiti otkucani rezultat;
Definicija baze podataka je pohranjena u šemi napisanoj u jeziku definicije objekata (ODL). Baza podataka pohranjuje objekte, omogućavajući im da se dijele među različitim korisnicima i aplikacijama.
DBMS zasnovani na OODM-u nazivaju se objektno orijentisani DBMS (OODBMS). Ovi DBMS se nazivaju DBMS 3. generacije* (* Istorija razvoja modela skladištenja podataka često se deli na tri faze (generacije): prva generacija (kraj 1960-ih - početak 70-ih) - hijerarhijska i mrežni model; druga generacija (otprilike 1970-1980) - relacijski model; treća generacija (1980-te - rane 2000-te) - objektno orijentirani modeli.).
Danas se objektno orijentirane baze podataka koriste u raznim organizacijama za rješavanje širokog spektra problema. Analiza i generalizacija akumuliranog iskustva u oblasti podataka informacionih tehnologija omogućila je da se identifikuju aplikacije u kojima je upotreba objektno orijentisanih baza podataka opravdana:
Aplikacija se sastoji od veliki broj dijelovi u interakciji. Svaki od njih ima svoje ponašanje, koje zavisi od ponašanja drugih;
Sistem 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.
IN trenutno Na tržištu softvera postoji mnogo objektno orijentisanih DBMS-ova. U tabeli. 10.6 prikazuje neke od komercijalni sistemi ove klase.
Tabela 10.6
Savremeni komercijalni OODBMS,
njihove proizvodne kompanije i područja primjene
Jedan od fundamentalne razlike objektne baze podataka iz relacijske je mogućnost kreiranja i korištenja novih tipova podataka. Važna karakteristika OODBMS je da kreiranje novog tipa ne zahteva modifikaciju osnovne jezgre i zasniva se na principima objektno orijentisanog programiranja.
OODBMS kernel je optimizovan za operacije sa objektima. Njegove prirodne operacije su keširanje objekata, upravljanje verzijama objekata, odvajanje prava pristupa specifičnih objekata. OODBMS karakterišu veće performanse na operacijama koje zahtevaju pristup i pronalaženje podataka upakovanih u objekte, u poređenju sa relacionim 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.
Tokom stvaranja razne aplikacije na bazi OODBMS-a, važna je ugrađena struktura klasa određenog DBMS-a. Biblioteka klasa obično podržava ne samo sve standardni tipovi podataka, ali i proširenog skupa multimedije i drugih složenih tipova podataka, kao što su video, zvuk, sekvenca kadrova animacije. U nekim OODBMS-om kreirane su biblioteke klasa koje omogućavaju skladištenje i pretraživanje po punom tekstu dokumentarnih informacija (na primjer, Jasmine, ODB-Jupiter). Primjer osnovne strukture klase prikazan je na sl. 10.17.
Glavnu poziciju u njemu zauzima klasa TOdbObject, koja sadrži sve potrebna svojstva i metode za upravljanje pristupom bazi podataka i izvođenje indeksiranja. Sve ostale klase nadjačavaju njegove metode, dodajući validaciju tipa koji implementiraju i određeni indekser.
Kao što se može vidjeti sa sl. 10.17, u strukturi postoje različite klase fokusirane na obradu dokumentarnih informacija - TOdbText, TOdbDocument, TODBTextDocument, itd. Svaki dokument je predstavljen posebnim objektom. Time je osigurana prirodnost pohranjivanja dokumenata. jedan od kritične operacije je traženje dokumenata na zahtjev. Za većinu klasa implementirana je mogućnost pretraživanja objekata po vrijednosti određenog ključa. Za klasu TOdbText, mogućnost formiranja upit za pretragu frazom napisanom na prirodnom jeziku.
Klasa TOdbDocument je posebna, može sadržavati objekte različitih tipova. Sastoji se od polja, od kojih svako ima ime i pridruženo je objektu određenog tipa. Prisustvo ove klase daje korisniku mogućnost da proširi skup tipova. Modifikacijom objekta kontejnera (dokumenta), možete postaviti određeni skup polja i dobiti novi tip dokumenta.
Na osnovu ODB-Jupitera, OODBMS programeri su kreirali potpuno funkcionalan sistem za pronalaženje informacija ODB-Text, koji ima univerzalnu strukturu pohranjenih podataka i moćan mehanizam pretraživanja. ODB-Text sistem je alat za kolektivnu obradu dokumenata i održavanje korporativne arhive. Na listi moguće primjene nazovimo automatizaciju računovodstva za radni tok moderne kancelarije, izgradnju referentno-informacionih sistema (slično poznatim pravnim bazama podataka), održavanje mrežnih baza podataka, kadrovske evidencije, bibliografije itd.
41. Osobine dizajna primijenjenih IS. Faze razvoja IS-a. (Tema 11, str. 100-103).
11.1.3. Osobine projektiranja sistema primijenjenih IC
Prilikom izgradnje (odabira, prilagođavanja) informacionog sistema možete koristiti dva osnovna koncepta, dva glavna pristupa (treći koncept je njihova kombinacija):
1. Orijentacija na probleme koje je potrebno riješiti uz pomoć ovog informacionog sistema, tj. problemski orijentisani pristup (ili induktivni pristup);
2. fokus na tehnologiju koja je dostupna (ažurirana) u datom sistemu, okruženju, tj. pristup tehnologiji (ili deduktivni pristup).
Izbor koncepta zavisi od strateških (taktičkih) i (ili) dugoročnih (kratkoročnih) kriterijuma, problema, resursa.
Ako se prvo prouče mogućnosti postojeće tehnologije, a zatim se utvrde stvarni problemi koji se uz njihovu pomoć mogu riješiti, onda je potrebno osloniti se na tehnološki orijentiran pristup.
Ako se prvo identifikuju stvarni problemi, a zatim se uvede tehnologija koja je dovoljna za rješavanje ovih problema, onda je potrebno osloniti se na problemski pristup.
Istovremeno, oba koncepta izgradnje informacionog sistema zavise jedan od drugog: uvođenje novih tehnologija mijenja probleme koji se rješavaju, a promjena problema koji se rješavaju dovodi do potrebe uvođenja novih tehnologija; I jedno i drugo utiče na odluke koje se donose.
Dizajn (razvoj) sistema i upotreba bilo kog primenjenog (korporativnog) informacionog sistema mora proći kroz sledeći životni ciklus informacionog sistema:
- predprojektna analiza (iskustvo u kreiranju drugih sličnih sistema, prototipova, razlike i karakteristike sistema koji se razvija, itd.), analiza spoljašnjih manifestacija sistema;
– unutarsistemska analiza, interna analiza (analiza podsistema sistema);
- sistemski (morfološki) opis (reprezentacija) sistema (opis cilja sistema, sistemski odnosi i veze sa okruženje, drugi sistemi i sistemski resursi- materijalne, energetske, informacione, organizacione, ljudske, prostorne i vremenske);
– utvrđivanje kriterijuma za adekvatnost, efikasnost i održivost (pouzdanost);
– funkcionalni opis podsistema sistema (opis modela, algoritama za funkcionisanje podsistema);
- izrada prototipa (opis prototipa) sistema, evaluacija interakcije podsistema sistema (izrada izgleda - implementacija podsistema sa pojednostavljenim funkcionalni opisi, procedure i testiranje interakcije ovih rasporeda kako bi se ispunio cilj sistema), dok je moguće koristiti „izglede“ kriterijuma za adekvatnost, održivost, efikasnost;
- "montaža" i testiranje sistema - implementacija u potpunosti funkcionalni podsistemi i kriterijuma, vrednovanje modela prema formulisanim kriterijumima;
– rad sistema;
– utvrđivanje ciljeva daljeg razvoja sistema i njegove primjene;
- održavanje sistema - pojašnjenje, modifikacija, proširenje mogućnosti sistema u načinu njegovog rada (u cilju njegove evolucije).
Ove faze su glavne za reinženjering informacionih sistema.
Razvoj korporativnog informacionog sistema se po pravilu vrši za dobro definisano preduzeće. Karakteristike predmetne delatnosti preduzeća će, naravno, uticati na strukturu informacionog sistema. Ali istovremeno, strukture različitih preduzeća su generalno slične jedna drugoj. Svaka organizacija, bez obzira na vrstu djelatnosti, sastoji se od niza odjela koji direktno obavljaju jednu ili drugu vrstu djelatnosti kompanije. I ova situacija važi za skoro sve organizacije, bez obzira na to kojom se vrstom aktivnosti bave.
Dakle, svaka organizacija se može smatrati skupom međusobno povezanih elemenata (podjela), od kojih svaki može imati svoju, prilično složenu, strukturu. Odnosi između odjela su također prilično složeni. U opštem slučaju, postoje tri vrste veza između poslovnih jedinica:
Funkcionalne veze - svaka divizija obavlja određene vrste poslova u okviru jednog poslovnog procesa;
Informacione komunikacije - jedinice razmjenjuju informacije (dokumenti, faksovi, pismeni i usmeni nalozi, itd.);
Eksterne komunikacije – neke jedinice su u interakciji sa eksternim sistemima, a njihova interakcija može biti i informatička i funkcionalna.
Zajednička struktura različitih preduzeća omogućava nam da formulišemo neke zajedničke principe za izgradnju korporativnih informacionih sistema.
Generalno, proces razvoja informacionog sistema se može posmatrati sa dva gledišta:
Po vremenu ili po fazama životni ciklus sistem koji se razvija. IN ovaj slučaj razmatra dinamičku organizaciju procesa razvoja, opisanu u terminima ciklusa, faza, iteracija i faza.
Informacioni sistem preduzeća je razvijen kao projekat. Mnoge karakteristike upravljanja projektom i faze razvoja projekta (faze životnog ciklusa) su uobičajene i ne zavise ne samo od predmetne oblasti, već i od prirode projekta (nije bitno da li je inženjerski ili ekonomski projekat). ). Stoga ima smisla prvo razmotriti seriju opšta pitanja upravljanje projektima.
Projekat je vremenski ograničena, svrsishodna promena u posebnom sistemu sa početno jasno definisanim ciljevima od čijeg dostizanja zavisi završetak projekta, kao i sa utvrđenim zahtevima za rokovima, rezultatima, rizikom, utroškom sredstava i resursa, i organizacionu strukturu.
Obično je za složeni koncept (a to je posebno koncept projekta) teško dati jednoznačnu formulaciju koja u potpunosti pokriva sve karakteristike uvedenog koncepta. Stoga, gornja definicija ne tvrdi da je jedinstvena i potpuna.
Sljedeći glavni karakteristike projekat kao kontrolni objekat:
Varijabilnost - svrsishodan prenos sistema sa postojećeg na neki
željeno stanje, opisano u smislu ciljeva projekta;
Ograničenje krajnjeg cilja;
ograničeno trajanje;
Ograničen budžet;
Potrebni ograničeni resursi;
Novost za preduzeće za koje se projekat realizuje;
Složenost - prisustvo velikog broja faktora koji direktno ili indirektno utiču na napredak i rezultate projekta;
Pravni i organizaciona podrška- stvaranje posebne organizacione strukture za vrijeme trajanja projekta.
Efikasnost rada postiže se upravljanjem procesom implementacije projekta, čime se obezbjeđuje alokacija resursa, koordinacija redoslijeda rada koji se obavlja i kompenzacija unutrašnjih i vanjskih smetnji.
Sa stanovišta teorije upravljačkih sistema, projekat kao kontrolni objekat mora biti uočljiv i upravljiv, odnosno razlikuju se neke karakteristike po kojima je moguće stalno pratiti napredak projekta (svojstvo opservabilnosti). Pored toga, postoji potreba za mehanizmima blagovremenog uticaja na tok implementacije projekta (vlasništvo kontrole).
Svojstvo upravljivosti posebno je relevantno u uslovima neizvjesnosti i varijabilnosti predmetne oblasti, koje često prate projekte razvoja informacionih sistema.
Svaki projekat, bez obzira na složenost i obim posla potrebnih za njegovu realizaciju, prolazi kroz određene faze u svom razvoju: 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 (faze, faze).
Postoje određene razlike u određivanju broja faza i njihovog sadržaja, jer ove karakteristike u velikoj mjeri zavise od uslova za realizaciju određenog projekta i iskustva glavnih učesnika. Međutim, logika i glavni sadržaj procesa razvoja informacionog sistema u gotovo svim slučajevima su zajednički.
Mogu se razlikovati sljedeće faze razvoja informacionog sistema:
Formiranje koncepta;
Izrada tehničkih specifikacija;
Dizajn;
Proizvodnja;
Puštanje sistema u rad.
Razmotrimo svaki od njih detaljnije. Druga i delimično treća faza se obično nazivaju fazama projektovanja sistema, a poslednje dve (ponekad uključuju fazu projektovanja) su faze implementacije.
Faza koncepta
Formiranje ideja, postavljanje ciljeva;
Formiranje ključnog projektnog tima;
Proučavanje motivacije i zahtjeva kupaca i ostalih učesnika;
Prikupljanje i analiza osnovnih podataka postojeće stanje;
Definisanje osnovnih zahtjeva i ograničenja, potrebnih materijalnih, finansijskih i radnih resursa;
Komparativna procjena alternativa;
Dostavljanje 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 strukturnog modela projekta;
Izrada predračuna i budžeta za projekat, utvrđivanje potreba za resursima;
Razvoj kalendarski planovi i prošireni rasporedi rada;
Potpisivanje ugovora sa kupcem;
Puštanje u rad sredstava komunikacije učesnika projekta i kontrole toka radova.
Dizajn
U ovoj fazi se najviše određuju podsistemi, njihove međusobne veze efikasne načine izvođenje projekta i korištenje resursa. Karakteristični radovi ove faze:
Realizacija osnovnih projektantskih radova;
Razvoj privatnog projektni zadatak;
Realizacija idejnog rješenja;
Izrada tehničkih specifikacija i uputa;
Prezentacija izrade projekta, ispitivanje i odobrenje.
Razvoj
U ovoj fazi se vrši koordinacija i operativna kontrola rada na projektu, izrađuju se, kombinuju i testiraju podsistemi. Glavni sadržaj:
Izvođenje poslova na razvoju softvera;
Izvođenje priprema za implementaciju sistema;
Kontrola i regulacija glavnih indikatora projekta.
Puštanje sistema u rad
U ovoj fazi se vrše ispitivanja, pilot rad sistema u realnim uslovima, u toku su pregovori o rezultatima projekta i mogućim novim ugovorima. Glavne vrste posla:
Složeni testovi;
42. Koncept životnog ciklusa IP. (Tema 11, str. 103-105).
Uz veliki broj eksperimentalnih projekata (pa čak i komercijalnih sistema) ne postoji općeprihvaćen objektno orijentirani model podataka, i to ne zato što nije razvijen niti jedan cjelovit model, već zato što ne postoji opći dogovor o usvajanju bilo kojeg modela. U stvari, postoje konkretnija pitanja vezana za dizajniranje deklarativnih jezika upita, izvršavanje i optimizaciju upita, formulisanje i održavanje ograničenja integriteta, sinhronizaciju pristupa i upravljanje transakcijama, itd.
Objektno orijentisani model (slika 3) vam omogućava da kreirate, pohranjujete i koristite informacije u obliku objekata. Svaki objekat prilikom kreiranja dobija jedinstveni identifikator koji generiše sistem, koji je povezan sa objektom tokom njegovog postojanja i ne menja se kada se stanje objekta promeni.
Fig.3. Objektno orijentirani model podataka
Svaki objekat ima stanje i ponašanje. Stanje objekta je skup vrijednosti za njegove atribute. Ponašanje objekta je skup metoda (programski kod) koji rade na stanju objekta. Vrijednost atributa objekta je također neki objekt ili skup objekata. Stanje i ponašanje objekta su inkapsulirani u objektu; interakcija objekata zasniva se na prenošenju poruka i izvršavanju odgovarajućih metoda.
Skup objekata sa istim skupom atributa i metoda formira klasu objekata. Objekt mora pripadati samo jednoj klasi (ako ne uzmete u obzir mogućnost nasljeđivanja). Dozvoljeno je imati primitivne unaprijed definirane klase čiji objekti instance nemaju atribute: cijele brojeve, nizove itd. Klasa čiji objekti mogu poslužiti kao vrijednosti atributa objekata druge klase naziva se domenom tog atributa.
Dozvoljeno je generiranje nove klase na osnovu već postojeće klase - nasljeđivanje. U ovom slučaju, nova klasa, nazvana podklasa postojeće klase (superklasa), nasljeđuje sve atribute i metode superklase. Dodatno, dodatni atributi i metode se mogu definirati u podklasi. Postoje slučajevi jednostavnog i višestrukog nasljeđivanja. U prvom slučaju, potklasa se može definirati samo na osnovu jedne nadklase, u drugom slučaju može postojati više nadklasa. Ako jezik ili sistem podržavaju nasljeđivanje jedne klase, skup klasa formira hijerarhiju stabla. Kada se podržava višestruko nasljeđivanje, klase su povezane u usmjereni graf s korijenom, koji se naziva rešetka klasa. Smatra se da objekat potklase pripada bilo kojoj superklasi te klase.
Objektno orijentisane baze podataka našle su najširu primenu u oblastima kao što su kompjuterski potpomognuto projektovanje/proizvodnja (CAD/CAM), sistemi automatizovani razvoj softver (CASE), sistemi za upravljanje složenim dokumentima, tj. u područjima koja nisu tradicionalna za baze podataka. Primjeri objektno orijentisanih DBMS-a su - POET, Jasmine, Versant, Iris, Orion.
2.2.4 Relacioni model podataka
Godine 1970. američki matematičar Codd E.F. objavio revolucionarni članak po svom sadržaju, sugerirajući korištenje teorije skupova za obradu podataka. On je tvrdio da podatke treba povezati prema njihovim logičkim odnosima (npr. unija, presek), a ne fizičkim pokazivačima. On je predložio jednostavan model podataka u kojem su svi podaci sažeti u tabele koje se sastoje od redova i kolona sa jedinstvenim imenima. Ove tabele se nazivaju relacije (relacija - relacija), a model - relacioni model zasnovan na konceptu matematičkih odnosa i ponekad se naziva i Codd model. Coddovi prijedlozi su bili toliko efikasni za sisteme baza podataka da je za ovaj model dobio prestižnu Turingovu nagradu za teoriju računarstva.
U relacionim bazama podataka svi podaci se pohranjuju u jednostavne tabele, podeljene u redove (oni se zovu zapisi) i kolone (oni se zovu polja), na čijem preseku se nalaze informacije o podacima. IN opšti pogled ovo se može predstaviti kao na sl. 4.
Fig.4. Tablica relacijske baze podataka.
Svaka kolona ima svoje ime. Na primjer, u tabeli "Roba na zalihama" (Sl. 5.), nazivi polja su sljedeći: Identifikator, Proizvod, Ime grupe, Grupa, jedinica mjere, Otkupna cijena, Prodajna cijena, Dostupnost na zalihama.
Rice. 5. Tabela „Roba u magacinu »
Sve vrijednosti u jednoj koloni su istog tipa. Dakle, polja su razne karakteristike(ponekad se nazivaju atributi) objekta. Vrijednosti polja u istoj liniji odnose se na isti objekt, a različita polja imaju različita imena.
Svaki zapis se razlikuje po jedinstvenom ključu zapisa, koji su dva tipa: primarni i sekundarni.
primarni 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 kompozitnim ključem.
sekundarni ključ je polje čija se vrijednost može ponoviti u nekoliko zapisa datoteke, odnosno nije jedinstvena.
Eksterni ključ podređena tabela je sekundarni ključ ove relacije, koji istovremeno obavlja funkcije primarnog ključa u glavnoj tabeli. Ako se po vrijednosti primarnog ključa može pronaći samo jedna instanca zapisa, onda ih po vrijednosti stranog ključa ima nekoliko (slika 6).
Fig.6. Primjer korištenja stranog ključa
Relaciona baza podataka se po pravilu sastoji od nekoliko tabela, jer nije moguće spojiti u jednu tabelu sve informacije potrebne zaposlenima (korisnicima baze podataka) bilo koje organizacije za rješavanje problema.
Način efikasnog pristupa po ključu zapisu datoteke je indeksiranje. Indeksiranje stvara dodatni fajl A koji sadrži, po redu, sve ključne vrijednosti datoteke podataka. Za svaki ključ, datoteka indeksa sadrži pokazivač na odgovarajući unos u datoteci podataka. Pokazivač na unos u datoteci podataka pruža direktan pristup tom unosu.
Za rad sa relacionim bazama podataka, jezik strukturiranih upita (SQL) se sada često koristi. To je jezik koji se koristi za kreiranje, modificiranje i manipulaciju podacima. SQL nije algoritamski jezik programiranje. Ovo je informaciono-logički jezik, zasnovan je na relacionoj algebri i podeljen je na tri dela:
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 relacionih baza podataka. Danas data baza smatra se standardom za moderne informacione sisteme.
Dakle, tabela je glavni tip strukture podataka relacionog modela. Struktura tabele je definisana skupom kolona. Svaki red tabele sadrži jednu vrijednost u odgovarajućoj koloni. Tabela ne može imati dva identična reda, ukupan broj redova nije ograničena. Kolona je element podataka, svaka kolona ima ime. Jedan ili više atributa čije vrijednosti jedinstveno identificiraju red tablice su ključ tabele.
Prednosti relacionog modela su:
Jednostavnost i lakoća razumijevanja krajnji korisnik- jedina informaciona struktura je tabela;
Prilikom projektovanja relacione baze podataka primenjuju se stroga pravila, zasnovana na matematičkom aparatu;
Potpuna neovisnost podataka. Prilikom promjene strukture, promjene koje zahtijevaju uvođenje aplikativni programi ah, minimalno;
Za pravljenje upita i pisanje aplikativnih programa nije potrebno znati specifičnu organizaciju baze podataka u vanjskoj memoriji.
Nedostaci relacionog modela su:
Relativno mala brzina pristupa i velika količina eksterne memorije;
Poteškoće u razumijevanju strukture podataka zbog pojave velikog broja tabela kao rezultat logičkog dizajna;
Ne može se uvijek predmetna oblast predstaviti kao skup tabela.
Relacijske baze podataka su trenutno najšire korištene. Mrežni i hijerarhijski modeli se smatraju zastarjelim, objektno orijentirani modeli još uvijek nisu standardizirani i nisu u širokoj upotrebi.
Objektno orijentirana baza podataka(OOBD) - baza podataka u kojoj se podaci modeliraju u obliku objekata, njihovih atributa, metoda i klasa.
Objektno orijentisane baze podataka se obično preporučuju za one slučajeve kada je potrebna obrada podataka sa složenom strukturom visokih performansi.
OODB manifest predlaže obavezne karakteristike koje svaki OODB mora ispuniti. Njihov izbor se zasniva na 2 kriterijuma: sistem mora biti objektno orijentisan i biti baza podataka.
Obavezne karakteristike
1. Podrška za složene objekte. Sistem mora pružiti mogućnost kreiranja kompozitnih objekata korištenjem konstruktora kompozitnih objekata. Neophodno 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 vrijednostima njihovih atributa.
3. Podrška za inkapsulaciju. Ispravna enkapsulacija se postiže činjenicom da programeri imaju pristup samo specifikaciji interfejsa metode, a podaci i implementacija metoda su skriveni unutar objekata.
4. Podrška za tipove 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 je deklarirana sa svojim tipom. Kompajler može koristiti ove informacije da provjeri šta se izvršava sa varijabla operacija za kompatibilnost sa svojim tipom, što vam omogućava da jamčite ispravnost softvera. S druge strane, klasa je predložak za kreiranje objekata i pruža metode koje se mogu primijeniti na te objekte. Dakle, koncept "klase" se 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 nadklase.
6. Preopterećenje u kombinaciji sa punim vezivanjem. Metode se moraju primijeniti na objekte različitih tipova. Implementacija metode mora ovisiti o vrsti objekata na koje se metoda primjenjuje. Da bi se obezbijedila ova funkcionalnost, povezivanje naziva metoda u sistemu ne bi trebalo da se odvija do vremena izvođenja programa.
7. Potpunost računanja. Jezik za manipulaciju podacima treba da bude programski jezik opšte namene.
8. Skup tipova podataka mora biti proširiv. Korisnik mora imati sredstva za kreiranje novih tipova podataka na osnovu skupa unaprijed definiranih tipovi sistema. Štaviše, između načina korištenja sistemskog i prilagođeni tipovi podaci ne bi trebali biti nikakve razlike.
OO DBMS
Objektno orijentirane baze podataka- baze podataka u kojima su informacije predstavljene u obliku objekata, kao u objektno orijentisanim programskim jezicima.
Da li koristiti objektno orijentirane sisteme upravljanja bazom podataka (OODBMS) u pravi projekti danas? Kada ih treba koristiti, a kada ne?
Evo Prednosti koristeći OODBMS:
· Ne postoji problem nekonzistentnosti između modela podataka u aplikaciji i baze podataka (nepodudaranje impedancije). Svi podaci se pohranjuju u bazi podataka u istom obliku kao u aplikacijskom modelu.
· Nije potrebno posebno održavati model podataka na strani DBMS-a.
· Svi objekti na nivou izvora podataka su strogo tipizirani. Nema više imena nizova kolona! Refaktorisanje objektno orijentisane baze podataka i koda koji radi sa njom sada je automatizovan, a ne monoton i dosadan proces.
ODMG Standard
Prvi manifest formalno je bio samo članak predstavljen na Konferencija o objektno orijentisanim i deduktivnim bazama podataka grupa pojedinaca. Kao što ste mogli vidjeti u prethodnom pododjeljku, zahtjevi Manifesta bili su emocionalni, a ne eksplicitno navedeni. 1991. godine formiran je ODMG konzorcij (tada je ova skraćenica otkrivena kao Grupa za upravljanje bazom podataka objekata, ali je kasnije dobio širu interpretaciju - Grupa za upravljanje podacima o objektu). ODMG konzorcijum je usko povezan sa mnogo većim konzorcijumom OMG ( Grupa za upravljanje objektima), koja je nastala dvije godine ranije. Glavni izvorni cilj ODMG-a bio je razviti industrijski standard za objektno orijentirane baze podataka ( opšti model). Osnovni objektni model OMG COM je usvojen kao osnova ( Osnovni objektni model). Tokom svog 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 poslednjih godina neki OMG standardi se oslanjaju na ODMG objektni model. Konkretno, OCL specifikacija je zasnovana na ODMG modelu ( Jezik ograničenja objekta), koji je dio ukupne specifikacije jezika UML 1.4 (i UML 2.0). U ovom članku nemamo za cilj da izvršimo detaljno poređenje OMG i ODMG pristupa i uputimo zainteresovane čitaoce na Encyclopedia Kogalovsky i materijale sa web stranica ovih konzorcija. Ograničavamo se sažetak glavne ideje sadržane u standardu ODMG-3.
ODMG Architecture
Predložena ODMG arhitektura je prikazana na Sl. 2.1. Ova arhitektura definira način na koji se podaci pohranjuju i različite tipove korisničkog pristupa ovom “skladištu podataka” 17 . Objedinjenom skladištu podataka se može pristupiti iz jezika definicije podataka, jezika upita i brojnih jezika za manipulaciju podacima. 18 Na sl. 2.1 ODL znači Jezik definicije objekta (jezik definicije objekta), OQL - Jezik upita objekata (jezik za upite objekata) i OML- Jezik za manipulaciju objektima (jezik za manipulaciju objektima).
Rice. 2.1. ODMG Architecture
Centralno za arhitekturu je model podataka A koji predstavlja organizacionu strukturu u kojoj se pohranjuju svi podaci kojima upravlja OODBMS. Jezik definicije objekata, jezik upita i jezici manipulacije dizajnirani su na takav način da se sve njihove mogućnosti zasnivaju na modelu podataka. Arhitektura dozvoljava postojanje raznovrsnih implementacionih struktura za pohranjivanje modeliranih podataka, ali bitan zahtjev je to sve softverske biblioteke i svi prateći alati su obezbeđeni u objektno orijentisanom okviru i moraju se održavati u skladu sa podacima.
Glavne komponente arhitekture su sljedeće.
- Objektni model podataka. Svi podaci koje čuva OODBMS strukturirani su u smislu konstrukcija modela podataka. Tačna semantika svih koncepata definirana je u modelu podataka (pogledajte dolje za više detalja).
- Jezik definicije podataka (ODL).Šeme baza podataka su opisane u terminima ODL jezika, u kojem su konstrukcije modela podataka instancirane u obliku jezika definicija. ODL vam omogućava da opišete šemu kao skup interfejsa tipa objekta, koji uključuje opis svojstava tipa i odnosa između njih, kao i imena operacija i njihovih parametara. ODL nije kompletan programski jezik; implementacija tipova mora biti obavljena na jednom od jezika OML kategorije. Osim toga, ODL je virtuelno jezika u smislu da ODMG standard ne zahtijeva njegovu implementaciju u softverskih proizvoda OODBMS koji se smatraju usklađenim sa standardom. Prihvatljivo je da ovi proizvodi podržavaju ekvivalentne jezike definicije koji uključuju sve karakteristike ODL-a, ali su prilagođeni specifičnostima određenog sistema. Međutim, prisustvo specifikacije ODL jezika u ODMG standardu je važno jer jezik specificira svojstva modela podataka.
- Jezik upita objekata (ODL). Jezik ima sintaksu sličnu SQL jezik, ali se oslanja na semantiku ODMG objektnog modela. Standard omogućava direktnu upotrebu OQL-a i njegovo ugrađivanje u jedan od jezika OML kategorije.
Relacioni model podataka
Gotovo sve savremeni sistemi na osnovu relacijski(relacijski) modeli upravljanja bazama podataka. Ime relacijski zbog činjenice da svaki zapis u takvoj bazi podataka sadrži informacije koje se odnose samo na jedan određeni objekt.
IN relacijski DBMS svi obrađeni podaci prikazani su u obliku ravnih tabela. Informacije o objektima određene vrste predstavljene su u tabelarni oblik: kolone tabele sadrže različite atribute objekata, a redovi imaju za cilj da svedu opise svih atributa na pojedinačne instance objekata.
Model nastao u fazi infološkog modeliranja, u većina zadovoljava principe relacije. Međutim, da bi se ovaj model doveo u relaciju, potrebno je izvršiti proceduru tzv normalizacija.
Teorija normalizacije radi sa pet normalne forme. Ovi obrasci su dizajnirani da smanje redundantnost informacija, tako da svaki sljedeći normalni oblik mora zadovoljiti zahtjeve prethodnog i neke dodatni uslovi. U praktičnom dizajnu baze podataka, četvrti i peti oblik se obično ne koriste. Ograničili smo se na prva četiri normalna oblika.
Hajde da uvedemo koncepte neophodne za razumevanje procesa dovođenja modela u relacionu šemu.
Stav- apstrakcija opisanog objekta kao skupa njegovih svojstava. Tokom infološke faze dizajna, razgovarali smo o apstrakciji objekata i dodijelili im neka svojstva. Sada, sa konceptualnim dizajnom, prelazimo na sljedeći nivo apstrakcije. U ovoj fazi, objekti, kao takvi, više ne postoje. Radimo sa skupom svojstava koja definiraju objekt.
Instanca veze- skup vrijednosti svojstava određenog objekta.
primarni ključ- identifikacioni skup atributa, tj. vrijednost ovih atributa je jedinstvena u ovo poštovanje. Nijedna dvije instance relacije ne sadrže iste vrijednosti u primarnom ključu.
jednostavan atribut- atribut čije su vrijednosti nedjeljive.
Kompleksni atribut- atribut čija je vrijednost skup vrijednosti od nekoliko razna svojstva objekt ili više vrijednosti istog svojstva.
Suštinski koncepti.
Domain
Koncept domena je specifičniji za baze podataka, iako ima neke analogije sa podtipovima u nekim programskim jezicima. U najopćenitijem obliku, domen se definira specificiranjem nekog osnovnog tipa podataka kojem pripadaju elementi domene, a proizvoljnim boolean izraz Primijenjeno na element tipa podataka. Ako ovaj logički izraz ima vrijednost true, tada je element podataka element domene.
Najispravnije intuitivno tumačenje koncepta domene je razumijevanje domene kao valjanog potencijalnog skupa vrijednosti date vrste. Na primjer, domena "Imena" u našem primjeru je definirana na osnovni tip znakovni nizovi, ali samo oni nizovi koji mogu predstavljati ime mogu biti uključeni u njegovu vrijednost (posebno, takvi nizovi ne mogu započeti mekim karakterom).
Semantičko značenje koncepta domene takođe treba napomenuti: podaci se smatraju uporedivim samo ako pripadaju istoj domeni. U našem primjeru, vrijednosti domena "Brojevi prolaza" i "Brojevi grupe" su cjelobrojnog tipa, ali nisu uporedivi. Imajte na umu da većina relacijskih DBMS-ova ne koristi koncept domene, iako je on već podržan u Oracle V.7.
Postrelacijskimodel
Klasični relacioni model pretpostavlja nedeljivost podataka pohranjenih u poljima tabelarnih zapisa. Postrelacijski model je prošireni relacijski model koji uklanja ograničenje nedjeljivosti podataka. Model dozvoljava višeznačna polja - polja čije se vrijednosti sastoje od podvrijednosti. Razmatra se skup vrijednosti viševrijednih polja nezavisni sto ugrađen u glavnu tabelu.
Na sl. 2.6, na primjeru informacija o fakturama i robi za poređenje, prikazan je prikaz istih podataka korištenjem relacionog (a) i postrelacionog (b) modela. Sa slike se vidi da, u poređenju sa relacionim modelom, postrelacioni model efikasnije skladišti podatke, a tokom obrade neće biti potrebno izvršiti operaciju spajanja podataka iz dve tabele.
Računi
|
N faktura |
Kupac |
N faktura |
Količina |
||
Nad glavom
|
N faktura |
Kupac |
Količina |
|
Rice. 2.6. Strukture podataka relacionih i postrelacijskih modela
Pošto postrelacioni model omogućava skladištenje nenormalizovanih podataka u tabelama, javlja se problem obezbeđivanja integriteta i konzistentnosti podataka. Ovaj problem se rješava uključivanjem odgovarajućih mehanizama u DBMS.
Dostojanstvo Postrelacioni model je sposobnost predstavljanja skupa povezanih relacionih tabela pomoću jedne postrelacione tabele. Ovo omogućava visoku vidljivost prezentacije informacija i povećanje efikasnosti njihove obrade.
nedostatak Postrelacijski model je složenost rješavanja problema osiguranja integriteta i konzistentnosti pohranjenih podataka.
Razmatrani postrelacijski model podataka podržan je od uniVers DBMS-a. Drugi DBMS bazirani na postrelacijskom modelu podataka također uključuju Bubba i Dasdb sisteme.
Višedimenzionalni model
Višedimenzionalni pristup predstavljanju podataka pojavio se gotovo istovremeno sa relacionim pristupom, ali je interesovanje za višedimenzionalni DBMS počelo da raste masovni karakter od sredine 90-ih. Poticaj je bio članak E. Codda 1993. godine. Formulisao je 12 osnovnih zahtjeva za OLAP (OnLine Analytical Processing) sisteme, od kojih su najvažniji vezani za mogućnosti konceptualnog predstavljanja i obrade višedimenzionalnih podataka.
U razvoju koncepata informacionih sistema mogu se razlikovati sljedeća dva pravca:
Operativni (transakcijski) sistemi za obradu;
Sistemi analitičke obrade (sistemi za podršku odlučivanju).
Relacioni DBMS su bili namenjeni informacionim sistemima operativne obrade informacija i veoma su efikasni u ovoj oblasti. U sistemima za analitičku obradu, oni su se pokazali pomalo nespretni i nedovoljno fleksibilni. Višedimenzionalni DBMS-ovi su ovdje efikasniji.
Multidimenzionalni DBMS su visoko specijalizovani DBMS dizajnirani za interaktivnu analitičku obradu informacija. Glavni koncepti koji se koriste u ovim DBMS-ovima su agregabilnost, istoričnost i predvidljivost.
Agregabilnost podaci označavaju razmatranje informacija na različitim nivoima njihove generalizacije. IN informacioni sistemi stepen detaljnosti u prezentaciji informacija za korisnika zavisi od njegovog nivoa: analitičar, korisnik, menadžer, menadžer.
Istoričnost podaci podrazumevaju obezbeđivanje visokog nivoa statičnosti samih podataka i njihovih odnosa, kao i obavezno vezivanje podataka za vreme.
Predvidljivost obrada podataka uključuje postavljanje funkcija predviđanja i njihovu primjenu na različite vremenske intervale.
Višedimenzionalnost modela podataka ne znači višedimenzionalnost digitalne vizualizacije podataka, već višedimenzionalni logički prikaz informacijske strukture u opisu i u operacijama manipulacije podacima.
U poređenju sa relacionim modelom, višedimenzionalna organizacija podataka ima veću vidljivost i više informacija. Za ilustraciju na sl. Slika 2.7 prikazuje relacijske (a) i višedimenzionalne (b) reprezentacije istih podataka o obimu prodaje automobila.
Osnovni koncepti višedimenzionalnih modela podataka: dimenzija i ćelija.
Measurement je skup podataka istog tipa koji čine jedno od lica hiperkocke. U multidimenzionalnom modelu, dimenzije igraju ulogu indeksa koji služe za identifikaciju specifičnih vrijednosti u ćelijama hiperkocke.
Cell 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, to 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 tabele, izračunavaju se prema unaprijed određenim formulama).
Rice. 2.7. Relaciona i multidimenzionalni prikaz podaci
U primjeru na sl. 2,7 b vrijednosti svake ćelije Obim prodaje jedinstveno određeno 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.
Rice. 2.8. Primjer 3D modela
Postojeći višedimenzionalni DBMS koriste dvije glavne sheme organizacije podataka: hiperkubičnu i polikubnu.
IN polycubic Shema pretpostavlja da se nekoliko hiperkocki različitih dimenzija i različitih dimenzija može definirati u bazi podataka kao lica. Primjer sistema koji podržava polikubičnu verziju baze podataka je Oracle server. Express Server.
Kada hiperkubni Shema pretpostavlja da su sve ćelije definirane istim skupom mjerenja. To znači da ako postoji nekoliko hiperkocki u bazi podataka, sve one imaju istu dimenziju i iste dimenzije.
Main dostojanstvo multidimenzionalni model podataka je pogodnost i efikasnost analitičke obrade velikih količina vremenskih podataka.
nedostatak višedimenzionalni model podataka je njegova glomaznost za najjednostavnije zadatke konvencionalne onlajn obrade informacija.
Primjeri sistema koji podržavaju višedimenzionalne modele podataka su Essbase, Media Multi-matrix, Oracle Express Server, Cache. Postoje softverski proizvodi, kao što su Media/MR, koji vam omogućavaju simultani rad sa višedimenzionalnim i relacionim bazama podataka.
Objektno orijentirani model
U objektno orijentisanom modelu, prilikom predstavljanja podataka moguće je identifikovati pojedinačne zapise baze podataka. Odnosi se uspostavljaju između zapisa i njihovih funkcija obrade koristeći mehanizme slične odgovarajućim objektima u objektno orijentisanim programskim jezicima.
Standardizirani objektno orijentirani model opisan je u preporukama standarda ODMG-93 (Object Database Management Group - objektno orijentirana grupa za upravljanje bazom podataka).
Razmotrite pojednostavljeni model objektno orijentisane baze podataka. Struktura objektno orijentisane baze podataka grafički je predstavljena kao stablo, čiji su čvorovi objekti. Svojstva objekata su opisana nekim standardnim ili korisničkim tipom (definiranim kao klasa). Vrijednost svojstva tipa class je objekt koji je instanca odgovarajuće klase. Svaki objekt instance klase smatra se podređenim objektu u kojem je definiran kao svojstvo. Objekt instance klase pripada njenoj klasi i ima jednog roditelja. Generički odnosi u bazi podataka formiraju povezanu hijerarhiju objekata. Primjer logičke strukture objektno orijentirane baze podataka bibliotekarstva prikazan je na sl. 2.9. Ovdje je objekt tipa Biblioteka je roditelj objekata instance klase Pretplatnik, Katalog I izručenje. Različiti tipovi objekata Knjige i mogu imati iste ili različite roditelje. Objekti tipa Book, koji imaju isti roditelj, moraju se razlikovati najmanje za pristupni broj (jedinstven za svaku instancu knjige), ali imati iste vrijednosti svojstva isb n udk, imena e i autor.
Logička struktura objektno orijentisane baze podataka je spolja slična strukturi hijerarhijske baze podataka. Glavna razlika između njih je u metodama manipulacije podacima.
Za izvođenje radnji 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 imena svojstva na objekt u kojem je definirano. Dakle, ako je u objektu tipa Katalog dodajte svojstvo koje specificira telefonski broj autora knjige i ima naslov telefon, tada ćemo dobiti svojstva istog imena za objekte Pretplatnik I Katalog. Značenje takvog svojstva će biti određeno objektom u koji je inkapsulirano.
Nasljedstvo, naprotiv, proširuje opseg svojstva na sve potomke objekta. Dakle, za sve objekte tipa Book, koji su potomci objekta tipa Katalog, možete dodijeliti svojstva roditeljskog objekta: isbn, udk, naslov I autor. Ako je potrebno proširiti djelovanje mehanizma nasljeđivanja na objekte koji nisu neposredni srodnici (na primjer, između dva potomka istog roditelja), tada se apstraktno svojstvo tipa abs. Dakle, definicija apstraktnih svojstava ulaznica I soba u objektu Biblioteka uzrokuje da ova svojstva naslijede svi podređeni objekti Pretplatnik, Book I Problemi ali. Nije slučajno da se stoga vrijednost imovine ulaznica casovi Pretplatnik I izručenje prikazano na sl. 2.9 su isti - 00015.
Polimorfizam u objektno orijentisanim programskim jezicima znači sposobnost istog programskog koda da radi sa heterogenim podacima. Drugim riječima, to znači da objekti različitih tipova mogu imati metode (procedure ili funkcije) s istim imenima. Tokom izvršavanja objektnog programa, iste metode rade na različitim objektima ovisno o tipu argumenta. U odnosu na primjer koji se razmatra, polimorfizam znači da su objekti klase Book imaju različite roditelje iz razreda Katalog, može imati drugačiji skup svojstava. Dakle, programi za rad sa objektima klase Book može sadržavati polimorfni kod.
Pretraživanje u objektno orijentiranoj bazi podataka sastoji se od pronalaženja sličnosti između objekta koji je odredio korisnik i objekata pohranjenih u bazi podataka.
Rice. 2.9. Logička struktura bibliotekarske baze podataka
Main dostojanstvo objektno orijentisani model podataka u poređenju sa relacionim je mogućnost prikaza informacija o složenim odnosima objekata. Objektno orijentirani model podataka omogućava vam da identificirate jedan zapis baze podataka i definirate funkcije za njihovu obradu.
nedostatke objektno orijentisani model su visoka konceptualna složenost, neugodnost obrade podataka i mala brzina izvršenja upita.
Objektno orijentisani DBMS-ovi uključuju POET, Jasmine, Versant, O2, ODB-Jupiter, Iris, Orion, Postgres.
