Objektno orijentirani model podataka

Objektno orijentisani model podataka je proširenje odredbi objektno orijentisanog programiranja (dok je relacioni model nastao na osnovu teorije skupova, odnosno kao model podataka). Grupa za upravljanje bazom podataka objekata razvila je standard ODMG-93 (Object DataBase Management Group). Ovaj standard još nije u potpunosti implementiran.

Struktura objektno orijentisane baze podataka grafički je predstavljena kao stablo, čiji su čvorovi objekti. Vidljiva struktura objekta određena je svojstvima njegove klase. Klasa uključuje objekte, dok su struktura i ponašanje objekata iste klase isti. Svaki objekat, odnosno instanca klase, smatra se potomkom objekta u kojem je definisan kao svojstvo. Svojstva objekta- bilo standardni tip, kao što je string, ili tip klase koju je konstruirao korisnik. Ponašanje objekata se postavlja pomoću metoda. Metoda je operacija koja se može primijeniti na objekt.

Kao primjer, razmotrite bazu podataka "BIBLIOTEKA" (slika 4.4). Svojstva, njihove vrste i vrijednosti su definirane za svaki objekt. u DB:

"BIBLIOTEKA" - roditelj (predak) za "PRETPLATA", "KATALOG", "IZDANJE";

"KATALOG" je roditelj za "KNJIGU".

"KNJIGA" - različiti objekti mogu imati iste ili različite roditelje. Ako je isti roditelj (jedan autor), onda su inventarni brojevi različiti, ali su isbn, UDK, naslov i autor isti.

Logička struktura objektno orijentisane baze podataka je slična hijerarhijskoj, glavna razlika je u metodama manipulacije podacima. U bazi podataka možete izvoditi takve radnje kao što su logičke operacije, poboljšane objektno orijentiranim metodama enkapsulacije, nasljeđivanja i polimorfizma.

Enkapsulacija ograničava opseg imena svojstva na objekt u kojem je definirano. Dakle, ako se nekretnina doda u "KATALOG" telefon autora knjige, onda se na sličan način dobijaju u "PRETPLATI" i "KATALOGU". Značenje svojstva će biti određeno objektom u koji je inkapsulirano.

Nasljedstvo, obrnuto, proširuje opseg svojstva na sve potomke objekta. Dakle, svim objektima tipa "BOOK", koji su potomci "KATALOG", mogu se dodijeliti svojstva matičnog isbn-a, UDK-a, naslova i autora.

Poliformizam znači sposobnost istog programskog koda da radi sa heterogenim podacima. Drugim riječima, to znači prihvatljivost u objektima različitih tipova da imaju metode - procedure i funkcije - s istim imenima. Tokom izvršavanja objektnog programa, iste metode rade na različitim objektima ovisno o tipu argumenta. Za bazu podataka "BIBLIOTEKA" to znači da objekti klase "BOOK" koji imaju različite roditelje od klase "CATALOG" mogu imati različit skup svojstava, tj. programi za rad sa objektom klase "BOOK" mogu sadržati polimorfni kod. U klasi metoda nema tijelo, odnosno nije definirano koje konkretne radnje treba izvršiti. Svaka podklasa izvodi potrebne operacije. Enkapsulacija skriva detalje implementacije od svih objekata izvan date hijerarhije.

Prednosti objektno orijentisanog modela u odnosu na relacioni su mogućnost prikaza informacija o složenim odnosima objekata, odsustvo ograničenja u strukturama skladištenja podataka. Objektno orijentirana baza podataka može pohraniti ne samo strukturu, već i aspekte ponašanja podataka. Koristeći objektno orijentisani pristup, mogu se kreirati i baze podataka sa velikim količinama semantičkih informacija, kao što su multimedijalne baze podataka i baze podataka specijalizovane za određene predmetne oblasti (geografske, dizajnerske, itd.).

Nedostaci ovog pristupa su velika konceptualna složenost, neugodnost obrade podataka i mala brzina izvršenja upita.

1990-ih stvoreni su prototipovi postojećih objektno orijentiranih baza podataka. To su POET (POET SoftWare), JASMINE (KOMPJUTERSKI SARADNICI), IRIS, ORION, POSTGRES.

Tema 5

Relacioni pristup u izgradnji informaciono-logičkog modela: osnovni pojmovi

Relacioni model podataka. Osnovni koncepti

Kao što je navedeno u dijelu prethodnog predavanja, relacijski model je trenutno jedan od najčešćih modela na tržištu baza podataka. Osnova ovog modela je skup međusobno povezanih tabela (relacija).

Glavne teorijske ideje relacionog modela iznijeli su u radovima o teoriji relacija američki logičar Charles Souders Peirce (1839-1914) i njemački logičar Ernst Schroeder (1841-1902), kao i američki matematičar Edgar Codd.

U radovima Piercea i Schroedera dokazano je da je skup relacija zatvoren pod nekim specijalnim operacijama koje zajedno čine apstraktnu algebru. Ovo suštinsko svojstvo odnosa korišćeno je u relacionom modelu za razvoj jezika za manipulaciju podacima.

Godine 1970. pojavio se članak E. Codd o prezentaciji podataka organizovanih u obliku dvodimenzionalnih tabela, nazvanih relacije. Codd je prvi uveo osnovne koncepte i ograničenja relacionog modela kao osnove za skladištenje podataka, te pokazao mogućnost obrade podataka korištenjem tradicionalnih operacija na skupovima i posebno uvedenih relacijskih operacija.

Osnovni koncepti relacionog modela dati su u tabeli. 3.1.

Objekti relacionog modela su uglavnom tabele (relacije). Integritet podataka je osiguran stranim i primarnim ključevima (pogledajte odjeljak "Integritet relacijskih podataka").

Operatori u relacionom modelu su skup instrukcija koje obezbeđuju dohvaćanje i manipulaciju podacima.

Tabela 5.1. Elementi relacionog modela

Termin relacionog modela	Opis
Baza podataka (DB)	Skup tabela i drugih objekata neophodnih za apstraktno predstavljanje odabrane predmetne oblasti
DB Schema	Skup zaglavlja tablice koji su međusobno povezani
Stav	Tabela - skup objekata iz stvarnog svijeta koji se odlikuju zajedničkim svojstvima i karakteristikama (polja tabele)
Zaglavlje odnosa	Zaglavlje tabele - imena polja (kolona) tabele
Tijelo veze	Tijelo tabele je skup vrijednosti za sve objekte stvarnog svijeta, koji je predstavljen kao unosi u tablicu (redovi tablice)
shema odnosa	Red zaglavlja kolone tabele (zaglavlje tabele)
atribut odnosa	Naziv kolone tabele (polje tabele)
relacija tuple	Red tabele (zapis) – jedan-na-jedan prikaz objekta iz stvarnog sveta kreiranog korišćenjem vrednosti polja tabele
Domain	Skup valjanih vrijednosti atributa
Vrijednost atributa	Vrijednost polja u zapisu (torka)
primarni ključ	Jedan ili više (u slučaju kompozitnog ključa) atributa koji jedinstveno definiraju vrijednost tuple (vrijednost reda tablice)
Eksterni ključ	Atribut tablice čije vrijednosti odgovaraju vrijednostima primarnog ključa u drugoj povezanoj (nadređenoj, primarnoj) tablici. Strani ključ se može sastojati od jednog ili više atributa (kompozitni strani ključ). Ako je broj atributa stranog ključa manji od broja atributa odgovarajućeg primarnog ključa, onda se naziva skraćenim (djelimični) strani ključ.
Stepen (aritet) odnosa	Broj kolona tabele
Moć odnosa	Broj redova (torke) tabele
Instanca veze	Skup zapisa (torke) za datu tabelu (relaciju). Instanca se može promijeniti tokom vremena. Pošto obična baza podataka u trenutnom trenutku radi samo sa jednom verzijom relacije, takva instanca relacije se naziva trenutna.
Tip podataka	Tip vrijednosti elementa tablice
Osnovni omjer	Relacija koja sadrži jednu ili više kolona koje karakteriziraju svojstva objekta, kao i primarni ključ
Izvedena relacija	Nije bazna relacija, tj. ne karakterizira svojstva objekta i koristi se za pružanje veza između drugih tabela, ne može sadržavati primarni ključ. Ako je naveden primarni ključ, tada se on sastoji od stranih ključeva koji se odnose na primarne ključeve bazne relacije
Veza	Uspostavlja odnos između odgovarajućih vrijednosti u ključnim poljima - primarnog ključa jedne tablice i stranog ključa druge
Komunikacija jedan na jedan (1:1)	Kada se koristi ovaj tip odnosa, unos u jednoj tablici može imati najviše jedan pridruženi unos u drugoj tablici. U obje tabele ključna polja moraju biti primarna. Koristi se za odvajanje tabela sa više polja ili za potrebe zaštite podataka
Odnos jedan-prema-više (1:M)	Kada se koristi ovaj tip odnosa, svaki zapis jedne tabele može odgovarati nekoliko zapisa druge, ali svaki zapis druge tabele odgovara samo jednom zapisu prve tabele. Prva tabela mora imati primarni ključ, druga mora imati strani ključ.
Odnos više-na-više (N:M)	Kod ovog tipa odnosa jedan zapis u prvoj tabeli može odgovarati nekoliko zapisa druge tabele, ali jedan zapis druge tabele može odgovarati i nekoliko zapisa prve. Jedinstvenost ključeva za takve tabele nije potrebna. U procesu dizajniranja šeme baze podataka, takve veze se transformišu. Da biste to učinili, morate uvesti pomoćnu relaciju koja vam omogućava da zamijenite odnos mnogo prema mnogo s dva odnosa jedan prema mnogo

Struktura podataka relacionog modela pretpostavlja predstavljanje predmetnog područja problema koji se razmatra kao skup međusobno povezanih odnosa.

U svakom odnosu jedan odnos može djelovati kao glavni (osnovni, roditelj), a drugi kao podređen (izveden, dijete). Da bi se održale ove veze, oba odnosa moraju sadržavati skup atributa pomoću kojih su povezani: u glavnoj relaciji, ovo je primarni ključ relacije (jedinstveno identificira torbu glavne relacije); podređena relacija mora imati skup atributa koji odgovaraju primarnom ključu glavne relacije. Ovdje je ovaj skup atributa već sekundarni ključ ili strani ključ, tj. definira skup izvedenih relacijskih torva povezanih s jednom torbom osnovne relacije.

Formira se skup međusobno povezanih tabela shema baze podataka.

Dakle, odnos R je dvodimenzionalna tabela koja sadrži neke podatke.

Matematički N-aran odnos R je skup kartezijanskog proizvoda D 1×D 2×…×Dn skupovi (domene) D 1 , D 2 ,…,D n(n≥1), opciono različito:

R D 1×D 2×…×Dn,

gdje D 1×D 2×…×Dn je potpuni kartezijanski proizvod, tj. skup mogućih kombinacija od n elemenata svaki, gdje je svaki element preuzet iz svog domena.

Domain je semantički koncept koji se može smatrati podskupom vrijednosti nekog tipa podataka koji imaju specifično značenje.

Svojstva domene:

Domena ima jedinstveno ime (unutar baze podataka),

Definirano na nekom jednostavnom tipu podataka ili na drugoj domeni,

Može imati neki logički uslov za opis podskupa podataka dozvoljenih za tu domenu,

Nosi određeno semantičko opterećenje.

Glavna vrijednost domena je da ograničavaju usporedbe: ne možete upoređivati ​​vrijednosti iz različitih domena, čak i ako imaju isti tip podataka.

Atribut odnos je par oblika

<Имя_атрибута: Имя_домена>(ili<A:D>).

Imena atributa unutar relacije su jedinstvena. Često su imena atributa ista kao i odgovarajući nazivi domena.

Relacija R definirana na skupu domena sadrži dva dijela: zaglavlje i tijelo.

Zaglavlje odnosa– fiksni broj atributa relacije koji opisuju kartezijanski proizvod domena na kojima je relacija specificirana:

(<A1: D1>, <A2: D2 >, …, <A n: D n>).

Zaglavlje je statičko: ne mijenja se tokom rada sa bazom podataka.Ako se atributi mijenjaju, dodaju ili brišu u odnosu, onda se dobija druga relacija. Čak i sa sačuvanim imenom.

Tijelo relacija sadrži skup relacija tuple.

Svaki tuple je skup parova oblika:

<Имя_атрибута: Значение атрибута>:

R(<A1:Val1>, <A2:Val2 >, …, <A n: Val n>).

Takva da vrijednost Val i atribut A i pripada domeni D i.

Tijelo relacije je skup točaka, tj. podskup kartezijanskog proizvoda domena. Dakle, tijelo relacije je zapravo relacija u matematičkom smislu riječi. Tijelo relacije se može promijeniti tokom rada sa bazom podataka, budući da se tuple mogu mijenjati, dodavati i uklanjati tokom vremena.

Odnos se obično piše kao:

R(<A1: D1>, <A2: D2 >, …, <A n: D n>),

ili skraćeno: R(A 1, A2, …, A n) ili R.

shema odnosa je skup zaglavlja relacija uključenih u bazu podataka, tj. lista naziva atributa date relacije, koji označava domen na koji se odnose:

S R =(A 1, A2, …, A n), A i D i, i = 1,...,n.

Ako atributi uzimaju vrijednosti iz iste domene, tada se nazivaju θ-uporedivi, gdje je θ skup važećih poređenja navedenih za ovu domenu.

Na primjer, ako domena sadrži numeričke podatke, tada su za nju dozvoljene sve operacije poređenja: θ == (=,<>,>=,<=,<,>). Međutim, za domene koje sadrže znakovne podatke, ne mogu se specificirati samo operacije poređenja za jednakost i nejednakost vrijednosti. Ako je datoj domeni dat leksikografski poredak, tada ima i cijeli skup operacija poređenja.

Zovu se šeme dvije relacije ekvivalentan, ako imaju isti stepen, a moguće je rasporediti imena atributa u šemama na način da se uporedivi atributi, odnosno atributi koji uzimaju vrijednosti iz istog domena, nalaze na istim mjestima.

Dakle, za ekvivalentne odnose su zadovoljeni sljedeći uslovi:

Imaju isti broj atributa;

Prisutnost atributa sa istim imenima;

Prisutnost identičnih nizova u relacijama, uzimajući u obzir činjenicu da redoslijed atributa može varirati;

Relacije ove vrste su različite reprezentacije iste relacije.

Relationship Properties proizilaze direktno iz gornje definicije relacije. Ova svojstva su glavne razlike između odnosa relacionog modela podataka i jednostavnih tabela:

Jedinstvenost imena relacije. Ime jedne relacije mora se razlikovati od naziva drugih relacija.

Jedinstvenost torki. Nema identičnih tuple u odnosu. Zaista, tijelo relacije je skup torki i, kao svaki skup, ne može sadržavati elemente koji se ne mogu razlikovati. Tabele, za razliku od relacija, mogu sadržavati identične redove. Svaka ćelija relacije sadrži samo atomsku (nedjeljivu) vrijednost.

Tuple poremećaj. Korke nisu uređene (od vrha do dna), jer je tijelo relacije skup, a skup nije uređen (za poređenje, redovi u tabelama su poređani). Isti odnos može biti predstavljen različitim tabelama sa redovima u različitim redosledom.

Poremećaj atributa. Atributi nisu poređani (s lijeva na desno).

Jedinstvenost imena atributa unutar odnosa. Svaki atribut ima jedinstveno ime unutar relacije, što znači da redosled atributa nije bitan (za poređenje, kolone u tabeli su poredane). Ovo svojstvo donekle razlikuje relaciju od matematičke definicije relacije. Ista relacija može biti predstavljena različitim tabelama u kojima su stupci u različitom redoslijedu.

Atomičnost vrijednosti atributa. Sve vrijednosti atributa su atomske. Ovo proizilazi iz činjenice da osnovni atributi imaju atomske vrijednosti, tj. neka domena vrijednosti (poseban elementarni tip) je povezana sa svakim atributom, vrijednosti atributa su preuzete iz istog domena. Šema i tuple relacije su skupovi, a ne liste, tako da redosled kojim su predstavljeni nije bitan. Poređenja radi – razne informacije se mogu postaviti u ćelije tabele: nizovi, strukture, druge tabele itd.

komentar:

Iz svojstava relacije slijedi da ne svaki tabela može biti relacija. Da bi određena tabela definisala odnos potrebno je da tabela ima jednostavnu strukturu (sadrži samo redove i kolone, a svaki red mora imati isti broj polja), tabela ne sme imati iste redove, bilo koje kolona tabele mora sadržavati podatke samo jednog tipa, svi tipovi podataka koji se koriste moraju biti jednostavni.

Treba napomenuti da je relacijski model baza podataka u obliku skupa međusobno povezanih odnosa, koji se nazivaju shema relacijske baze podataka.

Osnovni koncepti

Definicija 1

Objektno orijentirani model predstavljanje podataka omogućava identifikaciju pojedinačnih zapisa baze podataka.

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

Definicija 2

Grafičko predstavljanje Struktura objektno orijentisane baze podataka je stablo čiji čvorovi predstavljaju objekte.

Standardni tip (na primjer, string - string) ili tip koji je kreirao korisnik ( klasa), opisuje svojstva objekta.

Na slici 1, objekt LIBRARY je roditelj objekata instance klasa CATALOG, SUBSCRIBER i ISSUES. Različiti objekti tipa BOOK mogu imati jednog ili različite roditelje. Objekti tipa BOOK koji imaju isti roditelj moraju imati najmanje različite pristupne brojeve (jedinstvene za svaku instancu knjige), ali iste vrijednosti svojstva autor, naslov, udk i isbn.

Logičke strukture objektno orijentisane i hijerarhijske baze podataka su spolja slične. Razlikuju se uglavnom po metodama manipulacije podacima.

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

Prilikom kreiranja i modifikacije baze podataka automatski se formiraju i naknadno ispravljaju indeksi (tabele indeksa), koji sadrže informacije za brzo pronalaženje podataka.

Definicija 3

Target inkapsulacija– ograničavanje opsega imena svojstva na granice objekta u kojem je ono definirano.

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

Definicija 4

Nasljedstvo, obrnuto od enkapsulacije, odgovoran je za proširenje opsega svojstva na sve potomke objekta.

Na primjer, svim objektima BOOK koji su potomci objekta CATALOG mogu se dodijeliti svojstva roditeljskog objekta: autor, naslov, udk i isbn.

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

Dakle, svojstva soba i ulaznica u objektu BIBLIOTEKE nasljeđuju svi podređeni objekti LENDING, BOOK i SUBSCRIBER. Zbog toga su vrijednosti ovog svojstva klasa SUBSCRIBER i ISSUANCE iste - 00015 (Slika 1).

Definicija 5

Polimorfizam omogućava da isti programski kod radi sa heterogenim podacima.

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

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

Prednosti i nedostaci objektno orijentisanog modela

Main prednost objektno orijentisani model podataka za razliku od relacionog modela je mogućnost prikaza informacija o složenim odnosima objekata. Razmatrani model podataka omogućava definisanje zasebnog zapisa baze podataka i funkcija njegove obrade.

TO nedostatke objektno orijentisani model uključuje visoku konceptualnu složenost, nezgodnu obradu podataka i nisku brzinu izvršavanja upita.

Do danas su takvi sistemi prilično rasprostranjeni. To uključuje DBMS:

• postgres,
• orion,
• iris,
• ODBJupiter,
• Versant,
• Objektivnost/DB,
• prodavnica predmeta,
• statično,
• dragi kamen
• g baza.

U OOMD-u, prilikom prezentovanja 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 alatima 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). Još uvijek nije bilo moguće u potpunosti implementirati preporuke ODMG-93. Da biste ilustrirali ključne ideje, razmotrite donekle pojednostavljeni model objektno orijentisane baze podataka.

Struktura objektno orijentisane baze podataka (OODB) je grafički 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 koherentnu hijerarhiju objekata.

Primjer logičke strukture OODB-a za bibliotekarstvo prikazan je na sl. 2.8.

Ovdje je objekt tipa LIBRARY roditelj objekata instance klasa SUBSCRIBER, CATALOG i ISSUANCE. Različiti objekti tipa BOOK 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 imaju iste vrijednosti svojstva isbn, udk, naslov i autor.

Rice. 2.8. Logička struktura bibliotekarske baze podataka

Logička struktura OODB-a je spolja slična strukturi IDB-a. 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. 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 (indeksnih tabela) koji sadrže informacije za brzo pronalaženje podataka.

Razmotrimo ukratko koncepte enkapsulacije, nasljeđivanja i polimorfizma u odnosu na objektno orijentirani model baze podataka.

Enkapsulacija ograničava opseg imena svojstva na objekt u kojem je definirano. Dakle, ako objektu tipa KATALOG dodamo svojstvo koje specificira telefonski broj autora knjige i ima naziv phone, onda ć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 karte apstraktnih svojstava i broja u objektu BIBLIOTEKA dovodi do nasljeđivanja ovih svojstava od strane svih podređenih objekata SUBSCRIBER, BOOK i ISSUANCE. Nije slučajno da se stoga vrijednost imovine ulaznica klase SUBSCRIBER i ISSUANCE prikazane na slici će biti iste - 00015.

Polimorfizam v objektno orijentisani programski jezici znače 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 našu objektno orijentisanu bazu podataka, polimorfizam znači da objekti klase BOOK koji imaju različite roditelje od klase CATALOG mogu imati drugačiji skup svojstava. Shodno tome, programi za rad sa objektima klase BOOK mogu sadržati polimorfni kod.

Pretraga u OODB-u se sastoji u pronalaženju sličnosti između objekta koji je odredio korisnik i objekata pohranjenih u bazi podataka. Korisnički definirani objekt koji se zove ciljni objekt (svojstvo objekta ima tipgol), u općem slučaju, to može biti podskup cijele hijerarhije objekata pohranjenih 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. 2.9.

Rice. 2.9. Fragment baze podataka sa ciljnim objektom

Main dostojanstvo OOMD u poređenju sa relacionim je mogućnost prikaza informacija o složenim odnosima objekata. OOMD vam omogućava da identifikujete jedan zapis baze podataka i definišete funkcije njihove obrade.

Main nedostatke OOMD su visoka konceptualna složenost, neugodnost obrade podataka i mala brzina izvršavanja upita.

Devedesetih godina postojali su eksperimentalni prototipovi OODBMS-a. Trenutno postoji više od 300 takvih DBMS-a. Neki sistemi su relativno rasprostranjeni, kao što su sledeći DBMS: Cache (InterSystems), ROET (ROET Software), Jasmine (Computer Associates), Versant (VersantTechnologies), O2 (ArdentSoftware), ODB-Jupiter (Istraživačko-proizvodni centar „Inteltek Plus "), kao i Iris, Orion i Postgres.

Prednosti OODB-a u budućnosti bi trebalo da dovedu do njihove veoma široke distribucije. Da biste to učinili, prvo morate riješiti probleme eliminacije inherentnih nedostataka OODB-a: povećati fleksibilnost strukture baze podataka, izgraditi jasan programski jezik, razraditi sintaksu za raščlanjivanje upita, definirati nekoliko metoda pristupa podacima, razraditi pitanja istovremenog pristupa, utvrđivanje složenog nabrajanja podataka, razrada zaštite i oporavka podataka. Lista zadataka koje je potrebno riješiti može se nastaviti.

Međutim, i nakon rješavanja ovih problema, prelazak na OODB će biti postepen i ne baš brz, jer će se iz objektivnih i subjektivnih razloga teško odvojiti od ogromnog broja postojećih relacijskih DBMS-a. Da bi takav prelaz bio manje bolan omogućit će uključivanje u OODBMS ne samo objektne, već i relacijske komponente. Osim toga, MMD treba uvesti u OODBMS kako bi se formirali OLAP sistemi skladišta podataka koji su u praksi sve traženiji.

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 temelji se na objektno orijentiranoj paradigmi (OOP) naziva se objektno orijentirani 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žni koncepti OOP-a su 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 omogućava podklasi da naslijedi ograničen broj svojstava od svoje superklase.

Poziva se nasljeđivanje instance varijable strukturno nasleđe, nasljeđivanje metoda - naslijeđe ponašanja, a mogućnost korištenja iste metode za različite klase, odnosno korištenja različitih metoda s istim imenom za različite klase, naziva se 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 klase opisane su njenim atributima. Metode klase objekata su neka vrsta analoga svojstava objekata u stvarnom svijetu. Svaki objekat koji pripada određenoj klasi 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 odnosi u objektnom modelu su napravljeni 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. Ovaj odnos je varijanta odnosa mnogo-prema-više koji ima posebnu semantiku. 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.

Ograničenja integriteta veze igraju važnu ulogu u OODM-u. 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 je dizajnera 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 domenu, koju dijele svi objekti i literali tog 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) - hijerarhijski i mrežni modeli; druga generacija (otprilike 1970-1980-te) - relacioni model; treća generacija; 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 velikog broja delova 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 obavljati predvidljiv pristup podacima, tako da navigaciona priroda objektno orijentisanih baza podataka neće biti značajan nedostatak;

Potreba za neplaniranim zahtjevima je ograničena;

Struktura pohranjenih podataka je hijerarhijske ili slične prirode.

Trenutno na tržištu softvera postoji mnogo objektno orijentisanih DBMS-ova. U tabeli. 10.6 prikazuje neke od komercijalnih sistema ove klase.

Tabela 10.6

Savremeni komercijalni OODBMS,

njihove proizvodne kompanije i područja primjene

Jedna od fundamentalnih razlika između objektnih i relacijskih baza podataka je mogućnost kreiranja i korištenja novih tipova podataka. Važna karakteristika OODBMS-a je da kreiranje novog tipa ne zahteva modifikaciju jezgra baze podataka 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, dijeljenje prava pristupa određenim objektima. 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.

Prilikom kreiranja različitih aplikacija zasnovanih na OODBMS-u, važna je ugrađena struktura klasa određenog DBMS-a. Biblioteka klasa, u pravilu, podržava ne samo sve standardne tipove podataka, već i prošireni skup multimedijalnih i drugih složenih tipova podataka, kao što su video, zvuk, slijed 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 njoj zauzima klasa TOdbObject, koja sadrži sva potrebna svojstva i metode za kontrolu pristupa 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. Jedna od najvažnijih operacija 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 implementirana je mogućnost generiranja upita za pretraživanje na osnovu fraze napisane 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. Među mogućim aplikacijama navešćemo automatizaciju knjigovodstvenog toka dokumenata moderne kancelarije, izgradnju referentnih i 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 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 (prikaz) sistema (opis cilja sistema, sistemskih odnosa i veza sa okruženjem, drugim sistemima i sistemskim resursima - materijalnim, energetskim, informacionim, organizacionim, ljudskim, prostornim i vremenskim);

– utvrđivanje kriterijuma za adekvatnost, efikasnost i održivost (pouzdanost);

– funkcionalni opis podsistema sistema (opis modela, algoritama za funkcionisanje podsistema);

- izrada prototipa (lažni opis) sistema, evaluacija interakcije podsistema sistema (razvoj modela - implementacija podsistema sa pojednostavljenim funkcionalnim opisima, procedurama i testiranje interakcije ovih modela kako bi se zadovoljio cilj sistema ), dok je moguće koristiti „modele“ kriterijuma za adekvatnost, stabilnost, efikasnost;

- "montaža" i testiranje sistema - implementacija punopravnih funkcionalnih podsistema i kriterijuma, evaluacija 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:

Vremenom ili fazama životnog ciklusa sistema koji se razvija. U ovom slučaju razmatramo 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 to inženjerski ili ekonomski projekat). ). Stoga ima smisla prvo razmotriti niz općih pitanja upravljanja 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.

Mogu se razlikovati sljedeće glavne karakteristike projekta kao objekta upravljanja:

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;

Pravna i organizaciona podrška - stvaranje specifične organizacione strukture za vreme 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 realizacije projekta (vlasništvo kontrolisanosti).

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 početnih podataka i analiza postojećeg stanja;

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;

Izrada kalendarskih planova i proširenih rasporeda rada;

Potpisivanje ugovora sa kupcem;

Puštanje u rad sredstava komunikacije učesnika projekta i kontrole toka radova.

Dizajn

U ovoj fazi određuju se podsistemi i njihove međusobne veze, odabiru najefikasniji načini implementacije projekta i korištenje resursa. Karakteristični radovi ove faze:

Realizacija osnovnih projektantskih radova;

Izrada privatnih tehničkih specifikacija;

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).

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. Skup vrijednosti za polja s više vrijednosti smatra se samostalnom tablicom ugrađenom u glavnu tablicu.

Na sl. 2.6, na primjeru podataka 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šedimenzionalne DBMS počelo da postaje široko rasprostranjeno od sredine 1990-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. U informacionim sistemima 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 proračunske tablice, se izračunavaju prema unapred definisanim formulama).

Rice. 2.7. Relaciona i višedimenzionalna reprezentacija podataka

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.

V 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 varijantu baze podataka je Oracle 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 a. 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.