Objektno orijentirani podatkovni model

Objektno orijentirani podatkovni model proširenje je odredbi objektno orijentiranog programiranja (dok je relacijski model nastao na temelju teorije skupova, upravo kao podatkovni model). Grupa za upravljanje bazom podataka objekata razvila je standard ODMG-93 (Grupa za upravljanje bazom podataka objekata). Ovaj standard još nije u potpunosti implementiran.

Struktura objektno orijentirane baze podataka grafički se prikazuje 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 objekt, odnosno instanca klase, smatra se potomkom objekta u kojem je definiran kao svojstvo. Svojstva objekta- ili standardni tip, kao što je string, ili korisnički konstruirani tip klase. Ponašanje objekata specificira se pomoću metoda. metoda je određena operacija koja se može primijeniti na objekt.

Kao primjer, razmotrite bazu podataka “LIBRARY” (slika 4.4). Za svaki objekt definirana su svojstva, njihove vrste i vrijednosti. U bazi podataka:

“KNJIŽNICA” – roditelj (prethodnik) za “PRETPLATA”, “KATALOG”, “BROJ”;

"KATALOG" je roditelj "KNJIGE".

“KNJIGA” – različiti objekti mogu imati iste ili različite roditelje. Ako se radi o istoj matici (isti autor), onda su inventarski brojevi različiti, ali su isti isbn, UDK, naslov i autor.

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

Enkapsulacija ograničava opseg naziva svojstva na granice objekta u kojem je ono definirano. Dakle, ako je nekretnina dodana u “KATALOG” telefon autora knjige, onda se dobivaju na sličan način u “PRETPLATI” i “KATALOGU”. Značenje svojstva će biti određeno objektom u koji je uklopljeno.

Nasljedstvo,obrnuto, proširuje opseg svojstva na svu djecu objekta. Dakle, svim objektima tipa “KNJIGA” koji su potomci “IMENIK” mogu se dodijeliti svojstva matičnog broja, UDK, naslova i autora.

Poliformizam znači sposobnost istog programskog koda za rad s različitim vrstama podataka. Drugim riječima, to znači da je dopušteno da objekti različitih tipova imaju metode - procedure i funkcije - s istim imenima. Tijekom izvođenja objektnog programa, iste metode djeluju na različite objekte ovisno o vrsti argumenta. Za bazu podataka “LIBRARY” to znači da objekti klase “BOOK” koji imaju različite roditelje od klase “DIRECTORY” mogu imati različit skup svojstava, tj. programi za rad s objektom klase BOOK mogu sadržavati polimorfni kod. U klasi metoda nema tijelo, odnosno nije definirano koje konkretne radnje treba izvoditi. Svaka podklasa izvodi potrebne operacije. Enkapsulacija skriva detalje implementacije od svih objekata izvan dane hijerarhije.

Prednosti objektno orijentiranog modela u usporedbi s relacijskim jesu mogućnost prikaza informacija o složenim odnosima između objekata i nepostojanje ograničenja u strukturama za pohranu podataka. Objektno orijentirana baza podataka može pohraniti ne samo strukturu, već i aspekte ponašanja podataka. Korištenjem objektno orijentiranog pristupa mogu se stvoriti baze podataka s velikim količinama semantičkih informacija, poput multimedijskih i specijaliziranih za određena tematska područja (geografska, dizajn, itd.).

Nedostaci ovog pristupa uključuju visoku konceptualnu složenost, neugodnost obrade podataka i malu brzinu izvršavanja upita.

U 90-ima su stvoreni prototipovi operativnih objektno orijentiranih baza podataka. To su POET (POET SoftWare), JASMINE (RAČUNALNI SURADNICI), IRIS, ORION, POSTGRES.

Tema 5

Relacijski pristup izgradnji informacijsko-logičkog modela: osnovni pojmovi

Relacijski model podataka. Osnovni koncepti

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

Glavne teorijske ideje relacijskog modela iznijele su u radovima o teoriji odnosa 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 određenim posebnim operacijama koje zajedno tvore apstraktnu algebru. Ovo bitno svojstvo odnosa korišteno je u relacijskom modelu za razvoj jezika za manipulaciju podacima.

Godine 1970. pojavio se rad E. Codda o prezentaciji podataka organiziranih u dvodimenzionalne tablice koje se nazivaju odnosima. Codd je prvi uveo osnovne koncepte i ograničenja relacijskog modela kao temelja za pohranu podataka, te pokazao mogućnost obrade podataka korištenjem tradicionalnih operacija na skupovima i posebno uvedenih relacijskih operacija.

Osnovni koncepti relacijskog modela dani su u tablici. 3.1.

Objekti relacijskog modela su uglavnom tablice (relacije). Cjelovitost podataka osigurana je stranim i primarnim ključevima (vidi paragraf “Cjelovitost relacijskih podataka”).

Operatori u relacijskom modelu su skup instrukcija koje omogućuju odabir i manipulaciju podacima.

Tablica 5.1. Elementi relacijskog modela

Termin relacijskog modela	Opis
Baza podataka (DB)	Skup tablica i drugih objekata potrebnih za apstraktni prikaz odabranog predmetnog područja
DB shema	Skup zaglavlja tablica međusobno povezanih
Stav	Tablica je zbirka objekata stvarnog svijeta koje karakteriziraju zajednička svojstva i karakteristike (polja tablice)
Zaglavlje odnosa	Naslov tablice – nazivi polja (kolona) tablice
Odnos tijela	Tijelo tablice je skup vrijednosti za sve objekte stvarnog svijeta, koji se mogu predstaviti u obliku zapisa tablice (retci tablice)
Dijagram odnosa	Redak zaglavlja stupca tablice (zaglavlje tablice)
Atribut odnosa	Naziv stupca tablice (polje tablice)
Torka odnosa	Redak tablice (zapis) – nedvosmislen prikaz objekta iz stvarnog svijeta kreiran pomoću vrijednosti polja tablice
Domena	Skup valjanih vrijednosti atributa
Vrijednost atributa	Vrijednost polja u zapisu (torka)
Glavni ključ	Jedan ili više (u slučaju složenog ključa) atributa koji jedinstveno definiraju vrijednost torke (vrijednost retka tablice)
Vanjski ključ	Atribut tablice čije vrijednosti odgovaraju vrijednostima primarnog ključa u drugoj povezanoj (roditeljskoj, 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, tada se on naziva skraćeni (djelomični) strani ključ
Stupanj (arnost) odnosa	Broj stupaca tablice
Omjer snaga	Broj redaka (torki) tablice
Instanca odnosa	Skup zapisa (torki) za danu tablicu (odnos). Instanca se može promijeniti tijekom vremena. Budući da obična baza podataka trenutno radi samo s jednom verzijom relacije, takva se instanca relacije naziva trenutnom
Tip podataka	Vrsta vrijednosti elementa tablice
Osnovni stav	Odnos koji sadrži jedan ili više stupaca koji karakteriziraju svojstva objekta, kao i primarni ključ
Izvedena relacija	Nije osnovni odnos, tj. ne karakterizira svojstva objekta i koristi se za pružanje odnosa između drugih tablica; ne smije sadržavati primarni ključ. Ako je naveden primarni ključ, on se sastoji od stranih ključeva povezanih s primarnim ključevima temeljne relacije
Veza	Uspostavlja odnos između podudarnih vrijednosti u ključnim poljima - primarnog ključa jedne tablice i stranog ključa druge
Komunikacija jedan na jedan (1:1)	Kada koristite ovu vrstu odnosa, zapis u jednoj tablici može imati najviše jedan povezani zapis u drugoj tablici. U obje tablice ključna polja moraju biti primarna. Koristi se za odvajanje tablica s brojnim poljima ili prema zahtjevima zaštite podataka
Komunikacija jedan prema više (1:M).	Kada koristite ovu vrstu odnosa, svaki zapis jedne tablice može odgovarati nekoliko zapisa druge, ali svaki zapis druge tablice odgovara samo jednom zapisu prve tablice. Prva tablica mora imati primarni ključ, druga mora imati strani ključ.
Odnos više-prema-više (N:M).	S ovom vrstom odnosa, jedan zapis u prvoj tablici može odgovarati nekoliko zapisa druge tablice, ali jedan zapis druge tablice može odgovarati nekoliko zapisa prve. Jedinstvenost ključeva za takve tablice nije potrebna. U procesu dizajniranja sheme baze podataka takve se veze transformiraju. Da biste to učinili, potrebno je uvesti pomoćnu relaciju koja vam omogućuje da zamijenite odnos više-prema-više s dva odnosa jedan-prema-više.

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

U svakoj vezi jedan odnos može djelovati kao glavni (osnovni, roditelj), a drugi može djelovati kao podređeni (izvedeni, dijete). Kako bi se održali ti odnosi, obje relacije moraju sadržavati skup atributa po kojima su povezane: u glavnoj relaciji, ovo je primarni ključ relacije (jedinstveno identificira torku glavne relacije); podređeni odnos mora imati skup atributa koji odgovara primarnom ključu glavnog odnosa. Ovdje je ovaj skup atributa već sekundarni ključ ili strani ključ, tj. definira skup torki izvedene relacije povezane s jednom torkom glavne relacije.

Formiraju se mnoge međusobno povezane tablice shema baze podataka.

Dakle stav R je dvodimenzionalna tablica koja sadrži neke podatke.

Matematički N-arni odnos R je kartezijanski proizvod skupa D 1 ×D 2 ×…×D n skupovi (domene) D 1 , D 2 ,…,D n(n≥1), nije nužno različito:

R D 1 ×D 2 ×…×D n,

Gdje D 1 ×D 2 ×…×D n– potpuni kartezijanski produkt, tj. skup svih mogućih kombinacija od po n elemenata, pri čemu je svaki element uzet iz vlastite domene.

Domena je semantički koncept koji se može promatrati kao podskup vrijednosti nekog tipa podataka koji imaju određeno značenje.

Svojstva domene:

Domena ima jedinstveno ime (unutar baze podataka),

Definiran na nekom jednostavnom tipu podataka ili na drugoj domeni,

Može imati neki logički uvjet koji vam omogućuje da opišete podskup podataka valjanih za ovu domenu,

Nosi određeno semantičko opterećenje.

Glavni značaj domena je da one ograničavaju usporedbe: ne možete uspoređivati ​​vrijednosti iz različitih domena, čak i ako imaju isti tip podataka.

Atribut odnos je par oblika

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

Nazivi atributa jedinstveni su unutar odnosa. Često su nazivi atributa isti kao i nazivi odgovarajućih domena.

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

Zaglavlje odnosa– fiksni broj atributa relacije, koji opisuju kartezijanski produkt domena na kojima je relacija navedena:

(<A 1: D 1>, <A 2: D 2 >, …, <A n: D n>).

Zaglavlje je statično: ne mijenja se tijekom rada s bazom podataka.Ako se atributi mijenjaju, dodaju ili brišu u relaciji, tada se dobiva drugačija relacija. Čak i ako je ime spremljeno.

Tijelo relacija sadrži skup relacijskih torki.

Svaki povorka automobila predstavlja skup parova oblika:

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

R(<A 1: Val 1>, <A 2: Val 2 >, …, <A n: Val n>).

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

Tijelo relacije je skup torki, tj. podskup Kartezijevog produkta domena. Dakle, tijelo relacije zapravo je relacija u matematičkom smislu riječi. Tijelo relacije može se mijenjati tijekom rada s bazom podataka jer se torke mogu mijenjati, dodavati i brisati tijekom vremena.

Odnos se obično piše kao:

R(<A 1: D 1>, <A 2: D 2 >, …, <A n: D n>),

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

Dijagram odnosa je skup zaglavlja relacija uključenih u bazu podataka, tj. popis naziva atributa dane relacije koji označavaju domenu kojoj pripadaju:

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

Ako atributi uzimaju vrijednosti iz iste domene, tada se nazivaju θ-usporedivim, gdje je θ skup valjanih operacija usporedbe navedenih za danu domenu.

Na primjer, ako domena sadrži numeričke podatke, tada su za nju važeće sve operacije usporedbe: θ == (=,<>,>=,<=,<,>). Međutim, za domene koje sadrže znakovne podatke, ne mogu se specificirati samo operacije usporedbe za jednakost i nejednakost vrijednosti. Ako određena domena ima leksikografski poredak, tada također ima i cijeli skup operacija usporedbe.

Sheme dvaju odnosa nazivaju se ekvivalent, ako imaju isti stupanj, a moguće je poredati nazive atributa u shemama na način da se usporedivi atributi, odnosno atributi koji uzimaju vrijednosti iz iste domene, nalaze na istim mjestima.

Dakle, za ekvivalentne relacije zadovoljeni su sljedeći uvjeti:

Imati isti broj atributa;

Prisutnost atributa s istim imenima;

Prisutnost identičnih redaka u odnosima, uzimajući u obzir da redoslijed atributa može varirati;

Odnosi ove vrste su različite slike istog odnosa.

Svojstva odnosa izravno slijede iz prethodno date definicije odnosa. Ova su svojstva glavne razlike između odnosa relacijskih modela podataka i jednostavnih tablica:

Jedinstvenost naziva relacije. Naziv jednog odnosa mora se razlikovati od naziva drugih odnosa.

Jedinstvenost torki. Ne postoje identične torke u relaciji. Doista, tijelo relacije je skup torki i, kao bilo koji skup, ne može sadržavati nerazlučive elemente. Tablice, za razliku od odnosa, mogu sadržavati identične retke. Svaka ćelija relacije sadrži samo atomsku (nedjeljivu) vrijednost.

Poremećaj tuplesa. Torke nisu poredane (odozgo prema dolje), jer je tijelo relacije skup, a skup nije uređen (za usporedbu, redaci u tablicama su poredani). Isti odnos može se prikazati različitim tablicama u kojima su redovi različitim redoslijedom.

Poremećaj atributa. Atributi nisu poredani (s lijeva na desno).

Jedinstvenost naziva atributa unutar odnosa. Svaki atribut ima jedinstveno ime unutar odnosa, što znači da redoslijed atributa nije bitan (za usporedbu, stupci u tablici su poredani). Ovo svojstvo donekle razlikuje relaciju od matematičke definicije relacije. Isti odnos može se prikazati različitim tablicama u kojima su stupci različitim redoslijedom.

Atomičnost vrijednosti atributa. Sve vrijednosti atributa su atomske. To proizlazi iz činjenice da temeljni atributi imaju atomske vrijednosti, tj. svaki atribut ima domenu vrijednosti (zaseban elementarni tip) povezanu s njim, a vrijednosti atributa su preuzete iz iste domene. Shema i torke relacije su skupovi, a ne popisi, tako da redoslijed kojim su prikazani nije bitan. Za usporedbu, u ćelije tablice možete smjestiti različite informacije: nizove, strukture, druge tablice itd.

Komentar:

Iz svojstava relacije slijedi da nitko tablica može biti relacija. Da bi tablica definirala odnos, tablica mora imati jednostavnu strukturu (sadržati samo retke i stupce, a svaki redak mora imati isti broj polja), tablica ne smije imati identične retke, bilo koji stupac u tablici mora sadrže samo jednu vrstu podataka, svi korišteni tipovi podataka moraju biti jednostavni.

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

Osnovni koncepti

Definicija 1

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

Zapisi baze podataka i njihove funkcije obrade povezani su mehanizmima sličnim onima implementiranim u objektno orijentiranim programskim jezicima.

Definicija 2

Grafički prikaz Struktura objektno orijentirane baze podataka je stablo čiji čvorovi predstavljaju objekte.

Standardni tip (na primjer, niz - niz) ili vrsta koju je izradio korisnik ( razreda), opisuje svojstva objekta.

Na slici 1, objekt LIBRARY je nadređeni objektima instance klasa DIRECTORY, SUBSCRIBER i ISSUE. Različiti objekti tipa KNJIGA mogu imati iste ili različite roditelje. Objekti tipa BOOK koji imaju istog roditelja moraju imati najmanje različite pristupne brojeve (jedinstvene za svaku instancu knjige), ali iste vrijednosti svojstava Autor, Ime, udk I isbn.

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

Prilikom izvođenja radnji na podacima, objektno orijentirani model koristi logičke operacije koje su poboljšane enkapsulacijom, nasljeđivanjem i polimorfizmom. Uz neka ograničenja, možete koristiti operacije koje su slične SQL naredbama (na primjer, kada stvarate bazu podataka).

Prilikom izrade i izmjene baze podataka automatski se generiraju i naknadno prilagođavaju indeksi (indeksne tablice) koji sadrže informacije za brzo pretraživanje podataka.

Definicija 3

Cilj enkapsulacija– ograničavanje opsega naziva svojstva na granice objekta u kojem je definirano.

Na primjer, ako se objektu DIRECTORY doda svojstvo koje navodi telefonski broj autora i ima ime telefon, tada će objekti IMENIK i PRETPLATNIK imati ista svojstva. Značenje svojstva određeno je objektom u koji je uklopljeno.

Definicija 4

Nasljedstvo, obrnuto od enkapsulacije, odgovorno je za širenje opsega svojstva u odnosu na sve potomke objekta.

Na primjer, svim objektima BOOK koji su potomci objekta DIRECTORY mogu se dodijeliti svojstva nadređenog objekta: Autor, Ime, udk I isbn.

Ako je potrebno proširiti mehanizam nasljeđivanja na objekte koji nisu u neposrednom srodstvu (na primjer, na dva potomka jednog roditelja), apstraktno svojstvo tipa definirano je u njihovom zajedničkom pretku trbušnjaci.

Dakle, svojstva broj I ulaznica u objektu LIBRARY nasljeđuju svi podređeni objekti ISSUE, BOOK i SUBSCRIBER. Zbog toga su vrijednosti ovog svojstva klasa SUBSCRIBER i ISSUING iste - 00015 (slika 1).

Definicija 5

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

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

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

Prednosti i nedostaci objektno orijentiranog modela

Osnove prednost Objektno orijentirani podatkovni model, za razliku od relacijskog modela, sposobnost je prikaza informacija o složenim odnosima između objekata. Model podataka koji se razmatra omogućuje nam definiranje zasebnog zapisa baze podataka i funkcija za njegovu obradu.

DO nedostatke Objektno orijentirani model karakterizira visoka konceptualna složenost, neugodna obrada podataka i mala brzina upita.

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

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

U OOMD je prilikom prikaza podataka moguće identificirati pojedinačne zapise baze podataka. Odnosi se uspostavljaju između zapisa baze podataka i njihovih funkcija obrade pomoću mehanizama sličnih odgovarajućim 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 provesti preporuke ODMG-93. Kako bismo ilustrirali ključne ideje, razmotrimo donekle pojednostavljeni model objektno orijentirane baze podataka.

Struktura objektno orijentirane baze podataka (OODB) grafički se prikazuje kao stablo čiji su čvorovi objekti. Svojstva objekata opisana su nekim standardnim tipom (na primjer, string) ili korisnički konstruiranim tipom (definiranim kao klasa).

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

Primjer logičke strukture knjižničarskog OOBD-a prikazan je na sl. 2.8.

Ovdje je objekt tipa LIBRARY nadređeni objektima instance klasa SUBSCRIBER, DIRECTORY i ISSUE. Različiti objekti tipa KNJIGA mogu imati iste ili različite roditelje. Objekti tipa KNJIGA koji imaju istog roditelja moraju se razlikovati barem po inventarnom broju (jedinstvenom za svaku instancu knjige), ali imati iste vrijednosti svojstava isbn, udk, naslov I Autor.

Riža. 2.8. Logička struktura baze podataka knjižničarstva

Logička struktura OODB-a je izvana slična strukturi IDB-a. Glavna razlika između njih je u metodama manipulacije podacima.

Za izvođenje radnji nad podacima u modelu baze podataka koji se razmatra, koriste se logičke operacije, poboljšane objektno orijentiranim mehanizmima enkapsulacije, nasljeđivanja i polimorfizma. Operacije slične SQL naredbama (na primjer, za stvaranje baze podataka) mogu se koristiti u ograničenoj mjeri.

Izrada i izmjena baze podataka prati automatsko formiranje i naknadno prilagođavanje indeksa (indeksnih tablica) 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 naziva svojstva na granice objekta u kojem je ono definirano. Dakle, ako objektu tipa IMENIK dodamo svojstvo koje navodi telefonski broj autora knjige i zove se telefon, tada ćemo za objekte PRETPLATNIK i IMENIK dobiti istoimena svojstva. Značenje takvog svojstva odredit će objekt u koji je uklopljeno.

nasljedstvo, naprotiv, proširuje opseg svojstva na sve potomke objekta. Dakle, svim objektima tipa KNJIGA koji su potomci objekta tipa IMENIK mogu se dodijeliti svojstva nadređenog objekta: isbn, udc, naslov i autor. Ako je potrebno proširiti mehanizam nasljeđivanja na objekte koji nisu u neposrednom srodstvu (na primjer, između dvoje djece istog roditelja), tada se apstraktno svojstvo tipa abs definira u njihovom zajedničkom pretku. Dakle, definiranje apstraktnih svojstava ulaznice i broja u objektu KNJIŽNICA dovodi do nasljeđivanja ovih svojstava od strane svih podređenih objekata PRETPLATNIK, KNJIGA i IZDANJE. Nije slučajno da vrijednost imovine ulaznica klase PRETPLATNIK i IZDAVANJE prikazane na slici bit će iste - 00015.

Polimorfizam V Objektno orijentirani programski jezici znači sposobnost istog programskog koda za rad s različitim vrstama podataka. Drugim riječima, to znači da je dopušteno da objekti različitih tipova imaju metode (procedure ili funkcije) s istim imenima. Tijekom izvođenja objektnog programa, iste metode djeluju na različite objekte ovisno o vrsti argumenta. U odnosu na našu objektno orijentiranu bazu podataka, polimorfizam znači da objekti klase BOOK koji imaju različite roditelje od klase DIRECTORY mogu imati različit skup svojstava. Shodno tome, programi za rad s objektima klase BOOK mogu sadržavati polimorfni kod.

Pretraživanje u OODB-u sastoji se od pronalaženja sličnosti između objekta koji je odredio korisnik i objekata pohranjenih u bazi podataka. Korisnički definirani objekt koji se naziva ciljni objekt (svojstvo objekta ima tipcilj), u općem slučaju, to može biti podskup cjelokupne hijerarhije objekata pohranjenih u bazi podataka. Ciljani objekt, kao i rezultat upita, mogu se pohraniti u samu bazu podataka. Primjer zahtjeva za brojeve iskaznica knjižnice i imena pretplatnika koji su dobili barem jednu knjigu iz knjižnice prikazan je na sl. 2.9.

Riža. 2.9. Fragment baze podataka s ciljnim objektom

Glavni dostojanstvo OOMD u usporedbi s relacijskim je mogućnost prikaza informacija o složenim odnosima između objekata. OOMD vam omogućuje da identificirate pojedinačni zapis baze podataka i odredite funkcije za njihovu obradu.

Glavni nedostatke OOMD karakterizira visoka konceptualna složenost, neprikladnost obrade podataka i niska brzina izvršavanja upita.

U 90-ima su postojali eksperimentalni prototipovi OODBMS-a. Trenutno postoji više od 300 takvih DBMS-ova. Neki sustavi su postali relativno rašireni, na primjer sljedeći DBMS: Cache (InterSystems), ROET (ROET Software), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (ArdentSoftware), ODB-Jupiter (Inteltek Plus Research and Production). Centar ), kao i Iris, Orion i Postgres.

Prednosti OODB-a u budućnosti bi trebale dovesti do njihove vrlo široke distribucije. Da biste to učinili, prvo trebate riješiti probleme kako biste uklonili inherentne nedostatke OODB-a: povećajte fleksibilnost strukture baze podataka, izgradite jasan programski jezik, razradite sintaksu parsiranja upita, definirajte nekoliko metoda pristupa podacima, riješite probleme istovremenog pristup, definirati enumeraciju složenih podataka, razraditi zaštitu i oporavak podataka. Popis problema koje je potrebno riješiti može se nastaviti.

Međutim, čak i nakon rješavanja ovih problema, prijelaz na OODB bit će postupan i ne baš brz, budući da će se iz objektivnih i subjektivnih razloga teško odvojiti od ogromnog broja postojećih relacijskih DBMS-ova. Da bi takav prijelaz bio manje bolan uključivanje ne samo objekta, već i relacijske komponente u OODBMS. Dodatno, MMD treba uvesti u OODBMS za formiranje OLAP sustava skladišta podataka, koji su u praksi sve traženiji.

Tehnologije baze podataka temeljene na gore opisanom MD-u temelje se na statičkom konceptu pohrane informacija, usmjerenom na modeliranje podataka. Međutim, nova područja primjene tehnologije sa složenim, međusobno povezanim objektima baze podataka, kao što su:

Računalno potpomognuto projektiranje;

Automatizirana proizvodnja;

Automatizirani razvoj softvera;

Uredski informacijski sustavi;

Multimedijski sustavi;

Geografski informacijski sustavi;

Izdavački sustavi i drugi pokazali su ograničene mogućnosti statičkog koncepta u smislu modeliranja objekata stvarnog svijeta.

Za nove vrste složenih specijaliziranih aplikacija baza podataka učinkovit je dinamički koncept pohrane informacija, koji omogućuje paralelno modeliranje podataka i procesa koji djeluju na te podatke. To vam omogućuje da uzmete u obzir semantiku predmetnog područja i stoga najprikladnije opišete ove aplikacije. Ovaj se koncept temelji na objektno orijentiranom pristupu koji se široko koristi u izradi softvera. MD, koji implementira ovaj koncept i temelji se na objektno orijentiranoj paradigmi (OOP), naziva se objektno orijentirani podatkovni model (OODM).

Konstrukcija OOMD-a temelji se na pretpostavci da se predmetno područje može opisati skupom objekata. Svaki objekt je entitet koji se može jedinstveno identificirati i sadrži atribute koji opisuju stanje objekata "stvarnog svijeta" i radnje povezane s njima. Trenutno stanje objekta opisuje jedan ili više atributa, koji mogu biti jednostavni i složeni. Jednostavan atribut može biti primitivnog tipa (na primjer, cijeli broj, niz, itd.) i imati doslovnu vrijednost. Složeni atribut može sadržavati zbirke i/ili reference. Referentni atribut predstavlja odnos između objekata.

Ključno svojstvo objekta je jedinstvenost njegove identifikacije. Stoga svaki objekt u objektno orijentiranom sustavu mora imati vlastiti identifikator.

Identifikator objekta (OID) interni je način označavanja pojedinačnih objekata u bazi podataka. Korisnici koji rade s upitom koji se temelji na dijalogu ili preglednikom informacija obično ne vide ove identifikatore. Njih dodjeljuje i koristi sam DBMS. Semantika identifikatora je drugačija u svakom DBMS-u. Može biti nasumična vrijednost ili sadržavati informacije potrebne za pronalaženje objekta u datoteci baze podataka, na primjer, broj stranice u datoteci i pomak objekta od njegovog početka. To je identifikator koji se mora koristiti za organiziranje referenci na objekt.

Svi objekti su enkapsulirani, što znači da prikaz ili unutarnja struktura objekta ostaje skrivena od korisnika. Umjesto toga, korisnik samo zna da objekt može obavljati neke funkcije. Stoga se za objekt WAREHOUSE mogu koristiti metode kao što su RECEIVE_GOOD, ISSUE_TOBAP, itd. Prednost enkapsulacije je u tome što vam omogućuje promjenu interne reprezentacije objekata bez prerade aplikacija u kojima se ti objekti koriste. Drugim riječima, enkapsulacija podrazumijeva neovisnost podataka.

Objekt enkapsulira podatke i funkcije (metode, prema OOP-u). Metode definiraju ponašanje objekta. Mogu se koristiti za promjenu stanja objekta mijenjanjem vrijednosti njegovih atributa ili za upit vrijednosti odabranih atributa. Na primjer, mogu postojati metode za dodavanje informacija o novoj nekretnini za iznajmljivanje, za ažuriranje podataka o plaći zaposlenika ili za ispis informacija o određenom proizvodu.

Objekti koji imaju isti skup atributa i odgovaraju na iste poruke mogu se grupirati u Klasa(u literaturi se pojmovi "klasa" i "tip" često koriste kao sinonimi). Svaka takva klasa ima svog predstavnika - objekt, koji je element podataka. Nazivaju se objekti određene klase kopije.

U nekim objektno orijentiranim sustavima, klasa je također objekt i ima svoje atribute i metode koje se pozivaju atributi klase i metode klase.

Važni koncepti OOP-a su hijerarhija klasa i hijerarhija spremnika.

Hijerarhija klasa implicira mogućnost da svaka klasa, u ovom slučaju nazvana superklasa, ima svoju podklasu. Kao primjer možemo navesti sljedeći lanac: svi programeri bilo kojeg poduzeća su njegovi zaposlenici, dakle, svaki programer koji je, u okviru OOMD-a, objekt klase PROGRAMERI, također je zaposlenik, koji, pak, je objekt klase EMPLOYEES. Dakle, PROGRAMERI će biti podklasa, ZAPOSLENICI će biti nadklasa. Ali programere također možemo podijeliti na sistemske i aplikacijske programere. Stoga će PROGRAMMERS biti nadklasa podklasama SIS_PROGRAMMERS i APPLICATION_PROGRAMERS. Nastavljajući ovaj lanac dalje, dobivamo hijerarhiju klasa u kojoj svaki objekt podklase nasljeđuje instance varijabli i metode odgovarajuće superklase.

Postoji nekoliko vrsta nasljeđivanja – jednokratno, višestruko i selektivno. Jednostruko nasljeđivanje je slučaj kada potklase nasljeđuju od najviše jedne superklase. Višestruko nasljeđivanje je nasljeđivanje iz više od jedne superklase. Selektivno nasljeđivanje dopušta podklasi da naslijedi ograničen broj svojstava od svoje nadklase.

Nasljeđivanje instanci varijable se zove strukturalno nasljeđe, nasljeđivanje metode - nasljeđe ponašanja a sposobnost korištenja iste metode za različite klase ili bolje rečeno upotrebe različitih metoda s istim imenom za različite klase naziva se polimorfizam.

Objektno orijentirana arhitektura također ima drugu vrstu hijerarhije - hijerarhija spremnika. To je da neki objekti mogu biti pojmovno sadržani unutar drugih. Dakle, objekt klase ODJEL mora sadržavati javnu varijablu HEAD, koja je veza na objekt klase ZAPOSLENIKA koji odgovara voditelju odjela, a također mora sadržavati vezu na skup veza na objekte koji odgovaraju zaposlenicima koji rade u ovom odjelu.

U nekim objektno orijentiranim sustavima, klasa je također objekt i ima svoje vlastite atribute i metode. Opće karakteristike klase opisuju se njezinim atributima. Metode klase objekata svojevrsni su analogni svojstvima objekata stvarnog svijeta. Svaki objekt koji pripada određenoj klasi ima ova svojstva. Stoga je prilikom kreiranja objekta potrebno deklarirati klasu kojoj pripada, kako bi se time definirala njegova inherentna svojstva.

Korisnik i objekt komuniciraju putem poruka. Kao odgovor na svaku poruku, sustav izvršava odgovarajuću metodu.

Svi odnosi u objektnom modelu napravljeni su pomoću referentnih atributa, koji se obično implementiraju kao OID-ovi.

Odnosi u relacijskoj bazi podataka predstavljeni su usporedbom primarnih i stranih ključeva. U samoj bazi podataka ne postoje strukture za formiranje asocijacija između tablica, veze se koriste po potrebi prilikom povezivanja tablica. Nasuprot tome, odnosi čine osnovu objektno orijentirane baze podataka jer svaki objekt uključuje identifikatore objekata s kojima je povezan.

U OOMD se mogu implementirati ne samo tradicionalne veze, već i veze zbog nasljeđivanja.

Komunikacija jedan na jedan (1:1) između objekata A i B implementira se dodavanjem referentnog atributa objektu B objektu A i (za održavanje referentnog integriteta) referentnog atributa objektu A objektu B.

Odnos jedan prema više (1:M). između objekata A i B implementira se dodavanjem referentnog atributa objektu A objektu B i atributa koji sadrži skup referenci od objekta A do objekta B (na primjer, dodaje se referentni atribut B(OID2, OID3...) objektu A, a instancama objekta B s OID2, OID3,... dodaje se referentni atribut A: OID1.

Odnos više-prema-više (M:N). između objekata A i B implementira se dodavanjem atributa svakom objektu koji sadrži skup poveznica.

U OOMD-u možete koristiti odnos "cijeli dio", koji opisuje da objekt jedne klase sadrži objekte drugih klasa kao svoje dijelove. U slučaju proizvodne baze podataka, postojao bi odnos cijeli dio između klase PROIZVOD i klasa DIO i SKLOP. Ovaj odnos je varijanta odnosa više-prema-više, koji ima posebnu semantiku. Odnos cjelina-dijel implementira se kao i svaki drugi odnos više-prema-više, koristeći skup povezanih identifikatora objekata. Međutim, za razliku od uobičajenog odnosa više-prema-više, ima drugačije semantičko značenje.

Budući da objektno orijentirana paradigma podržava nasljeđivanje, OOMD može koristiti odnose tipa "je" i odnose tipa "proširuje". Odnos "jest", također nazvan odnosom generalizacija-specijalizacija, dovodi do hijerarhije nasljeđivanja u kojoj su podklase posebni slučajevi nadklasa. To omogućuje da se ne opisuju ponovno naslijeđene karakteristike. Kada se koristi odnos "proširi", podklasa proširuje funkcionalnost superklase umjesto da bude ograničena na njen poseban slučaj.

Pogledajmo kako su komponente kao što su ograničenja integriteta i podatkovne operacije implementirane u OOMD.

Značajke ovih komponenti određene su specifičnostima modela. Ovu specifičnost u OOMD-u diktiraju prije svega interni koncepti kao što je enkapsulacija objekata, tj. skrivena unutarnja struktura, pristup podacima samo putem unaprijed određenih metoda, hijerarhija klasa i hijerarhija spremnika.

Specifičnosti OOMD diktiraju specifičnosti objekta. Očituje se u potrebi grupiranja objekata u klase. Svaki objekt je uključen u jednu ili drugu klasu ovisno o zadatku, a jedan objekt može pripadati nekoliko klasa odjednom (na primjer, obitelji PROGRAMERI i VISOKO PLAĆENI). Još jedna specifična značajka objekta je da se može “seliti” iz jedne klase (potklase) u drugu. Tako SUSTAVSKI PROGRAMER s vremenom može postati APLIKACIJSKI PROGRAMER. Dakle, hijerarhija klasa nije analogna hijerarhijskom modelu, kao što bi se prije moglo činiti, već zahtijeva da sustav može promijeniti lokaciju svakog objekta unutar hijerarhije klasa, na primjer, pomaknuti se "gore" ili "dolje" unutar zadanu hijerarhiju. Ali moguć je i složeniji proces - sustav mora osigurati mogućnost da se objekt u bilo kojem trenutku pripoji (odvoji) od proizvoljnog vrha hijerarhije.

Ograničenja integriteta veza igraju važnu ulogu u OOMD. Da bi poveznice u objektno orijentiranom MD-u radile, identifikatori objekata s obje strane veze moraju odgovarati jedan drugome. Na primjer, ako postoji odnos između ZAPOSLENIKA i njihove DJECE, tada mora postojati neko jamstvo da kada se objekt koji opisuje dijete umetne u objekt koji predstavlja zaposlenika, identifikator potonjeg se dodaje odgovarajućem objektu. Ova vrsta relacijske cjelovitosti, donekle analogna referentnoj cjelovitosti u modelu relacijskih podataka, uspostavlja se pomoću povratnih veza. Kako bi se osigurala cjelovitost odnosa, dizajner ima posebnu sintaktičku konstrukciju potrebnu za specificiranje lokacije identifikatora obrnutog objekta. Odgovornost za postavljanje ograničenja na integritet odnosa (kao i referentni integritet u relacijskoj bazi podataka) leži na dizajneru.

U OOMD-u se i opis podataka i manipulacija događaju koristeći isti objektno orijentirani proceduralni jezik.

Grupa ODMG (Object Database Management Group) bavi se problemima standardizacije tehnologije objektnih baza podataka. Razvio je objektni model (ODMG 2.0 usvojen je u rujnu 1997.) koji definira standardni model za semantiku objekata baze podataka. Ovaj model je važan jer definira ugrađenu semantiku koju objektno orijentirani DBMS (OODBMS) razumije i može implementirati. Struktura knjižnica i aplikacija koje koriste ovu semantiku moraju biti prenosive između različitih OODBMS-ova koji podržavaju ovaj objektni MD. Glavne komponente ODMG arhitekture su: objektni model (OM), jezik za definiranje objekata (ODL), jezik upita za objekte (OQL) i mogućnost vezanja na C++, Javu i Smalltalk.

Objektni model podataka u skladu sa standardom ODMG 2.0 karakteriziraju sljedeća svojstva:

Osnovni građevni blokovi su objekti i literali. Svaki objekt ima jedinstveni identifikator. Literal nema vlastiti identifikator i ne može postojati zasebno kao objekt. Literali su uvijek ugrađeni u objekte i ne mogu se referencirati pojedinačno;

Objekti i literali razlikuju se po vrsti. Svaki tip ima vlastitu domenu, koju dijele svi objekti i literali tog tipa. Tipovi također mogu imati ponašanje. Ako tip ima neko ponašanje, tada svi objekti ovog tipa imaju isto ponašanje. U praksi, tip može biti klasa iz koje je objekt kreiran, sučelje ili jednostavan tip podataka (kao što je cijeli broj). Objekt se može smatrati primjerkom tipa;

Stanje objekta određeno je skupom trenutnih vrijednosti ostvarenih skupom svojstava. Ova svojstva mogu biti atributi objekta ili odnosi između objekta i jednog ili više drugih objekata;

Ponašanje objekta definirano je skupom operacija koje se mogu izvesti na objektu ili na samom objektu. Operacije mogu imati popis ulaznih i izlaznih parametara, svaki strogo definiranog tipa. Svaka operacija također može vratiti tipizirani rezultat;

Definicija baze podataka pohranjena je u shemi napisanoj u jeziku za definiranje objekata (ODL). Baza podataka pohranjuje objekte, dopuštajući njihovo dijeljenje između različitih korisnika i aplikacija.

DBMS-ovi temeljeni na OODS-u nazivaju se objektno orijentirani DBMS-ovi (OODBMS). Ovi DBMS-ovi su klasificirani kao DBMS-ovi treće generacije* (* Povijest razvoja modela pohrane podataka često se dijeli u tri faze (generacije): prva generacija (kasne 1960. - rane 70.) - hijerarhijski i mrežni modeli; druga generacija (približno 1970.-1980.) - relacijski model; treća generacija (1980-ih - ranih 2000-ih) - objektno orijentirani modeli.).

Danas se objektno orijentirane baze podataka koriste u raznim organizacijama za rješavanje širokog spektra problema. Analiza i generalizacija prikupljenog iskustva u području podataka informacijske tehnologije omogućila je identificiranje aplikacija u kojima je korištenje objektno orijentiranih baza podataka opravdano:

Aplikacija se sastoji od velikog broja međusobno povezanih dijelova. Svaki od njih ima svoje ponašanje, koje ovisi o ponašanju drugih;

Sustav mora obraditi velike količine nestrukturiranih ili složenih podataka;

Aplikacija će pristupiti podacima na predvidljiv način, tako da navigacijska priroda objektno orijentiranih 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 postoji mnogo objektno orijentiranih DBMS-ova na tržištu softvera. U tablici 10.6 prikazuje neke od komercijalnih sustava ove klase.

Tablica 10.6

Moderni komercijalni OODBMS,

njihovih proizvođača i područja primjene

Jedna od temeljnih razlika između objektnih baza podataka i relacijskih je mogućnost stvaranja i korištenja novih tipova podataka. Važna značajka OODBMS-a je da stvaranje novog tipa ne zahtijeva modifikaciju jezgre baze podataka i temelji se na principima objektno orijentiranog programiranja.

Jezgra OODBMS je optimizirana za rad s objektima. Prirodne operacije za njega su pohranjivanje objekata u predmemoriju, održavanje verzija objekata i podjela prava pristupa određenim objektima. OODBMS karakterizira veća izvedba u operacijama koje zahtijevaju pristup i dohvaćanje podataka upakiranih u objekte, u usporedbi s relacijskim DBMS-ovima, kod kojih potreba za dohvaćanjem povezanih podataka dovodi do izvođenja 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 temeljenih na OODBMS-u, važna je ugrađena struktura klasa određenog DBMS-a. Knjižnica klasa u pravilu podržava ne samo sve standardne tipove podataka, već i prošireni skup multimedijskih i drugih složenih tipova podataka, kao što su video, zvuk i niz okvira animacije. Neki OODBMS-ovi su stvorili biblioteke klasa koje omogućuju pohranjivanje i pretraživanje informacija o dokumentima u cijelom tekstu (na primjer, Jasmine, ODB-Jupiter). Primjer strukture osnovne klase prikazan je na sl. 10.17.

Glavno mjesto u njoj zauzima klasa TOdbObject koja sadrži sva potrebna svojstva i metode za kontrolu pristupa bazi podataka i izvođenje indeksiranja. Sve druge klase nadjačavaju njegove metode, dodajući provjeru tipa za ispravnost tipa koji implementiraju i određeni indekser.

Kao što se može vidjeti sa Sl. 10.17, u strukturi postoje različite klase usmjerene na obradu dokumentarnih informacija - TOdbText, TOdbDocument, TODBTextDocument itd. Svaki dokument predstavljen je zasebnim objektom. Time se osigurava prirodna pohrana dokumenata. Jedna od najvažnijih operacija je traženje dokumenata na zahtjev. Za većinu klasa implementirana je mogućnost traženja objekata prema vrijednosti određenog ključa. Za klasu TOdbText implementirana je mogućnost generiranja upita za pretraživanje na temelju fraze napisane prirodnim jezikom.

Klasa TOdbDocument je posebna, može sadržavati različite vrste objekata. Sastoji se od polja od kojih svako ima naziv i povezano je s objektom određene vrste. Prisutnost ove klase daje korisniku mogućnost proširenja skupa tipova. Izmjenom objekta spremnika (dokumenta) možete postaviti određeni skup polja i dobiti novu vrstu dokumenta.

Na temelju ODB-Jupitera, OODBMS programeri stvorili su potpuno funkcionalan sustav za pretraživanje informacija ODB-Text, koji ima univerzalnu strukturu pohranjenih podataka i moćnu tražilicu. Sustav ODB-Text je alat za zbirnu obradu dokumenata i održavanje korporativne arhive. Moguće primjene uključuju automatizaciju računovodstva protoka dokumenata u modernom uredu, izgradnju referentnih i informacijskih sustava (slično poznatim Pravnim bazama podataka), održavanje mrežnih baza podataka, kadrovske evidencije, bibliografije itd.

41. Značajke primijenjenog dizajna IC. Faze razvoja IP-a. (Tema 11, str. 100-103).

11.1.3. Značajke projektiranja sustava primijenjenih IC

Pri izgradnji (odabiru, prilagodbi) informacijskog sustava možete koristiti dva glavna koncepta, dva glavna pristupa (treći koncept je njihova kombinacija):

1. fokusirati se na probleme koje treba riješiti pomoću ovog informacijskog sustava, tj. pristup usmjeren na problem (ili induktivni pristup);

2. usmjerenost na tehnologiju koja je dostupna (ažurirana) u danom sustavu ili okruženju, tj. pristup usmjeren na tehnologiju (ili deduktivni pristup).

Izbor koncepta ovisi o strateškim (taktičkim) i/ili dugoročnim (kratkoročnim) kriterijima, problemima, resursima.

Ako se najprije proučavaju mogućnosti postojeće tehnologije, a zatim identificiraju aktualni problemi koji se uz njihovu pomoć mogu riješiti, tada se treba osloniti na tehnološki orijentiran pristup.

Ako se prvo identificiraju trenutni problemi, a potom uvede tehnologija koja je dostatna za rješavanje tih problema, tada se treba osloniti na problemski orijentirani pristup.

Pritom oba koncepta izgradnje informacijskog sustava ovise jedan o drugom: uvođenje novih tehnologija mijenja probleme koji se rješavaju, a promjena problema koji se rješavaju dovodi do potrebe za uvođenjem novih tehnologija; oboje utječu na donesene odluke.

Projektiranje (razvoj) sustava i korištenje bilo kojeg primijenjenog (korporativnog) informacijskog sustava mora proći kroz sljedeći životni ciklus informacijskog sustava:

– analiza prije dizajna (iskustvo u stvaranju drugih sličnih sustava, prototipovi, razlike i značajke sustava koji se razvija, itd.), analiza vanjskih manifestacija sustava;

– unutarsustavna analiza, interna analiza (analiza podsustava sustava);

– sistemski (morfološki) opis (reprezentacija) sustava (opis cilja sustava, odnosa i veza sustava s okolinom, drugim sustavima i resursima sustava - materijalnim, energetskim, informacijskim, organizacijskim, ljudskim, prostornim i vremenskim);

– određivanje kriterija primjerenosti, učinkovitosti i održivosti (pouzdanosti);

– funkcionalni opis podsustava sustava (opis modela, algoritama za funkcioniranje podsustava);

– izrada prototipa (opis izgleda) sustava, procjena interakcije podsustava sustava (razvoj izgleda - implementacija podsustava s pojednostavljenim funkcionalnim opisima, procedurama i testiranje interakcije tih izgleda kako bi se zadovoljio cilj sustava), dok je moguće koristiti "izglede" kriterija za primjerenost, stabilnost, učinkovitost;

– “montaža” i testiranje sustava - implementacija punopravnih funkcionalnih podsustava i kriterija, evaluacija modela prema formuliranim kriterijima;

– rad sustava;

– određivanje ciljeva daljnjeg razvoja sustava i njegove primjene;

– održavanje sustava - pojašnjenje, modifikacija, proširenje mogućnosti sustava u načinu rada (u svrhu njegove evolucije).

Ove faze su glavne za informacijski reinženjering sustava.

Razvoj korporativnog informacijskog sustava, u pravilu, provodi se za vrlo specifično poduzeće. Značajke predmetne djelatnosti poduzeća sigurno će utjecati na strukturu informacijskog sustava. Ali u isto vrijeme, strukture različitih poduzeća općenito su slične jedna drugoj. Svaka organizacija, bez obzira na vrstu djelatnosti, sastoji se od niza odjela koji izravno provode jednu ili drugu vrstu djelatnosti poduzeća. I ova situacija vrijedi za gotovo sve organizacije, bez obzira na vrstu aktivnosti kojom se bave.

Stoga se svaka organizacija može smatrati skupom međusobno povezanih elemenata (dijelova), od kojih svaki može imati vlastitu, prilično složenu strukturu. Odnosi između odjela također su prilično složeni. Općenito, mogu se razlikovati tri vrste veza između odjela poduzeća:

Funkcionalna povezanost - svaki odjel obavlja određene vrste poslova unutar jedinstvenog poslovnog procesa;

Informacijske komunikacije - odjeli razmjenjuju informacije (dokumenti, faksovi, pisani i usmeni nalozi i sl.);

Vanjske komunikacije - neki odjeli su u interakciji s vanjskim sustavima, a njihova interakcija također može biti informacijska i funkcionalna.

Zajedničkost strukture različitih poduzeća omogućuje nam formuliranje nekih zajedničkih načela za izgradnju korporativnih informacijskih sustava.

Općenito, proces razvoja informacijskog sustava može se promatrati s dvije točke gledišta:

Po vremenu, odnosno po fazama životnog ciklusa sustava koji se razvija. U ovom slučaju, razmatramo dinamičku organizaciju razvojnog procesa, opisanu u terminima ciklusa, faza, ponavljanja i faza.

Informacijski sustav poduzeća razvija se kao projekt. Mnoge značajke projektnog menadžmenta i faze razvoja projekta (faze životnog ciklusa) su zajedničke, neovisne ne samo o predmetnom području, već io prirodi projekta (nije važno radi li se o inženjerskom ili gospodarskom projektu). Stoga ima smisla prvo razmotriti niz općih pitanja upravljanja projektom.

Projekt je vremenski ograničena, svrhovita promjena u zasebni sustav s inicijalno jasno definiranim ciljevima, čije postizanje određuje završetak projekta, kao i s utvrđenim zahtjevima za vrijeme, rezultate, rizik, okvir za trošenje sredstava i resursa , te za organizacijsku strukturu.

Obično je za složen koncept (kao što je, posebice, koncept projekta) teško dati jednoznačnu formulaciju koja u potpunosti pokriva sve značajke uvedenog koncepta. Stoga navedena definicija ne pretendira biti jedinstvena i potpuna.

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

Varijabilnost je svrhovito prenošenje sustava s postojećeg na neki

željeno stanje, opisano u smislu ciljeva projekta;

Ograničenje konačnog cilja;

Ograničeno trajanje;

Proračunska ograničenja;

Potrebni ograničeni resursi;

Novost za poduzeće za koje se projekt provodi;

Složenost - prisutnost velikog broja čimbenika koji izravno ili neizravno utječu na napredak i rezultate projekta;

Pravna i organizacijska podrška - stvaranje specifične organizacijske strukture za vrijeme trajanja projekta.

Učinkovitost rada postiže se upravljanjem procesom provedbe projekta, čime se osigurava raspodjela resursa, koordinacija slijeda obavljenih radova i kompenzacija unutarnjih i vanjskih ometajućih utjecaja.

Sa stajališta teorije sustava upravljanja, projekt kao objekt upravljanja mora biti vidljiv i kontroliran, odnosno identificirati određene karakteristike po kojima se može stalno pratiti napredovanje projekta (svojstvo vidljivosti). Osim toga, potrebni su mehanizmi za pravovremeni utjecaj na napredak projekta (svojstvo upravljivosti).

Svojstvo upravljivosti posebno je relevantno u uvjetima neizvjesnosti i varijabilnosti predmetnog područja, koji često prate projekte razvoja informacijskih sustava.

Svaki projekt, bez obzira na složenost i količinu posla potrebnog za njegovu realizaciju, u svom razvoju prolazi kroz određena stanja: od stanja kada „projekt još ne postoji“ do stanja kada „projekt više ne postoji“. Skup faza razvoja od nastanka ideje do potpunog završetka projekta obično se dijeli na faze (etape, etape).

Postoje neke razlike u određivanju broja faza i njihovog sadržaja, jer te karakteristike uvelike ovise o uvjetima konkretnog projekta i iskustvu glavnih sudionika. Međutim, logika i osnovni sadržaj procesa razvoja informacijskog sustava zajednički su u gotovo svim slučajevima.

Mogu se razlikovati sljedeće faze razvoja informacijskog sustava:

Formiranje pojma;

Izrada tehničkih specifikacija;

Oblikovati;

proizvodnja;

Puštanje sustava u rad.

Pogledajmo svaki od njih detaljnije. Druga i djelomično treća faza obično se nazivaju fazama projektiranja sustava, a zadnje dvije (ponekad je ovdje uključena i faza projektiranja) su faze implementacije.

Konceptualna faza

Formiranje ideja, postavljanje ciljeva;

Formiranje ključnog projektnog tima;

Proučavanje motivacije i zahtjeva kupca i ostalih sudionika;

Prikupljanje početnih podataka i analiza postojećeg stanja;

Utvrđivanje temeljnih zahtjeva i ograničenja, potrebnih materijalnih, financijskih i radnih resursa;

Usporedna procjena alternativa;

Podnošenje prijedloga, njihovo ispitivanje i odobravanje.

Izrada tehničkog prijedloga

Razvoj glavnog sadržaja projekta, osnovne strukture projekta;

Izrada i odobrenje tehničkih specifikacija;

Planiranje, dekompozicija osnovnog konstrukcijskog modela projekta;

Izrada procjene i proračuna za projekt, određivanje potrebnih sredstava;

Izrada kalendarskih planova i proširenih rasporeda rada;

Potpisivanje ugovora s kupcem;

Puštanje u rad sredstava komunikacije između sudionika projekta i praćenje napredovanja radova.

Oblikovati

U ovoj fazi se utvrđuju podsustavi i njihovi odnosi te odabiru najučinkovitiji načini provedbe projekta i korištenja resursa. Tipični rad ove faze:

Izvođenje osnovnih projektantskih poslova;

Izrada privatnih tehničkih specifikacija;

Izrada idejnog rješenja;

Izrada tehničkih specifikacija i uputa;

Prikaz izrade projekta, ispitivanja i odobrenja.

Razvoj

U ovoj fazi se provodi koordinacija i operativna kontrola rada projekta, izrađuju se, integriraju i testiraju podsustavi. Glavni sadržaj:

Obavljanje poslova razvoja softvera;

Priprema za implementaciju sustava;

Praćenje i reguliranje ključnih pokazatelja projekta.

Puštanje sustava u rad

U ovoj fazi provode se testiranja, probni rad sustava u stvarnim uvjetima, vode se pregovori o rezultatima projekta i mogućim novim ugovorima. Glavne vrste rada:

Sveobuhvatno testiranje;

42. Koncept životnog ciklusa IP-a. (Tema 11, str. 103-105).

Postrelacijskimodel

Klasični relacijski model pretpostavlja nedjeljivost podataka pohranjenih u poljima zapisa tablice. Postrelacijski model je prošireni relacijski model koji uklanja ograničenje nedjeljivosti podataka. Model dopušta polja s više vrijednosti—polja čije se vrijednosti sastoje od podvrijednosti. Skup vrijednosti polja s više vrijednosti smatra se zasebnom tablicom, ugrađenom u glavnu tablicu.

Na sl. 2.6, na primjeru podataka o fakturama i robi za usporedbu, prikazuje prikaz istih podataka korištenjem relacijskih (a) i postrelacijskih (b) modela. Sa slike je vidljivo da, u usporedbi s relacijskim modelom, postrelacijski model učinkovitije pohranjuje podatke, a tijekom obrade nije potrebno izvoditi operaciju spajanja podataka iz dvije tablice.

Fakture Fakture-roba

N faktura	Kupac		N faktura		Količina

Fakture

N faktura	Kupac		Količina

Riža. 2.6. Strukture podataka relacijskih i postrelacijskih modela

Budući da postrelacijski model dopušta pohranjivanje nenormaliziranih podataka u tablice, javlja se problem osiguranja integriteta i dosljednosti podataka. Ovaj problem se rješava uključivanjem odgovarajućih mehanizama u DBMS.

Dostojanstvo Postrelacijski model je sposobnost predstavljanja skupa povezanih relacijskih tablica pomoću jedne postrelacijske tablice. To osigurava visoku jasnoću prezentacije informacija i povećava učinkovitost njihove obrade.

Hendikep Postrelacijski model je teškoća rješavanja problema osiguranja cjelovitosti i konzistentnosti pohranjenih podataka.

Razmatrani relacijski model podataka podržava univerzalni DBMS. Ostali DBMS-ovi koji se temelje na post-relacijskom podatkovnom modelu također uključuju sustave Bubba i Dasdb.

Višedimenzionalni model

Višedimenzionalni pristup prezentaciji podataka pojavio se gotovo istodobno s relacijskim, ali interes za višedimenzionalne DBMS počeo je biti raširen od sredine 90-ih. Poticaj je bio članak E. Codda 1993. godine. Formulirao je 12 osnovnih zahtjeva za sustave klase OLAP (OnLine Analytical Processing), od kojih su najvažniji vezani uz mogućnosti konceptualne reprezentacije i obrade višedimenzionalnih podataka.

U razvoju koncepta informacijskih sustava mogu se razlikovati sljedeća dva pravca:

Operativni (transakcijski) procesni sustavi;

Sustavi analitičke obrade (sustavi za podršku odlučivanju).

Relacijski DBMS bili su namijenjeni informacijskim sustavima za online obradu informacija i vrlo su učinkoviti u ovom području. U sustavima analitičke obrade pokazali su se pomalo nespretnim i nedovoljno fleksibilnim. Višedimenzionalni DBMS-ovi su ovdje učinkovitiji.

Višedimenzionalni DBMS-ovi su visoko specijalizirani DBMS-ovi dizajnirani za interaktivnu analitičku obradu informacija. Glavni koncepti koji se koriste u ovim DBMS-ovima su agregabilnost, povijesnost i predvidljivost.

Agregabilnost podatak znači razmatranje informacije na različitim razinama njezine generalizacije. U informacijskim sustavima stupanj detaljnosti u prezentaciji informacija korisniku ovisi o njegovoj razini: analitičar, korisnik, menadžer, menadžer.

Povijesnost Upravljanje podacima podrazumijeva osiguranje visoke razine statičnosti samih podataka i njihovih odnosa, kao i obveznu vremensku vezanost podataka.

Predvidljivost Obrada podataka uključuje određivanje funkcija predviđanja i njihovu primjenu na različite vremenske intervale.

Višedimenzionalnost podatkovnog modela ne znači višedimenzionalnu vizualizaciju digitalnih podataka, već višedimenzionalni logički prikaz strukture informacija u opisu iu operacijama manipulacije podacima.

U usporedbi s relacijskim modelom, višedimenzionalna organizacija podataka je vizualnija i informativnija. Za ilustraciju na Sl. Slika 2.7 prikazuje relacijske (a) i višedimenzionalne (b) prikaze istih podataka o obujmu prodaje automobila.

Osnovni koncepti višedimenzionalnih modela podataka: dimenzija i ćelija.

Mjerenje je skup podataka istog tipa koji čini jednu od strana hiperkocke. U višedimenzionalnom modelu, mjerenja igraju ulogu indeksa koji služe za identifikaciju specifičnih vrijednosti u ćelijama hiperkocke.

Ćelija je polje čija je vrijednost jedinstveno određena fiksnim skupom mjerenja. Vrsta polja najčešće se definira kao digitalna. Ovisno o tome kako su vrijednosti ćelije generirane, ona može biti varijabla (vrijednosti se mijenjaju i mogu se učitati iz vanjskog izvora podataka ili generirati programski) ili formula (vrijednosti, poput ćelija formule u proračunskim tablicama, izračunavaju se pomoću unaprijed definiranih formula).

Riža. 2.7. Relacijsko i višedimenzionalno predstavljanje podataka

U primjeru na Sl. 2,7 b svaka vrijednost ćelije Obujam prodaje jedinstveno određena kombinacijom vremenskih dimenzija Mjesec prodaje i modeli automobila. U praksi je često potrebno više mjerenja. Primjer trodimenzionalnog podatkovnog modela prikazan je na sl. 2.8.

Riža. 2.8. Primjer 3D modela

Postojeći višedimenzionalni DBMS-ovi koriste dvije glavne sheme organizacije podataka: hiperkubičnu i polikubičnu.

U polikubični Shema pretpostavlja da se u bazi podataka može definirati nekoliko hiperkocki različitih dimenzija i s različitim dimenzijama lica. Primjer sustava koji podržava polikubnu verziju baze podataka je Oracle Express Server.

Kada hiperkubičan Dizajn pretpostavlja da su sve ćelije definirane istim skupom mjera. To znači da ako postoji nekoliko hiperkocki u bazi podataka, sve imaju istu dimenziju i iste dimenzije.

Glavni dostojanstvo višedimenzionalni podatkovni model je pogodnost i učinkovitost analitičke obrade velikih količina vremenski povezanih podataka.

Hendikep Nedostatak višedimenzionalnog modela podataka je njegova glomaznost za najjednostavnije zadatke obične operativne obrade informacija.

Primjeri sustava koji podržavaju višedimenzionalne modele podataka su Essbase, Media Multi-matrix, Oracle Express Server, Cache. Postoje softverski proizvodi, na primjer Media / MR, koji vam omogućuju istovremeni rad s višedimenzionalnim i relacijskim bazama podataka.

Objektno orijentirani model

U objektno orijentiranom modelu, prilikom prezentiranja podataka, moguće je identificirati pojedinačne zapise baze podataka. Odnosi se uspostavljaju između zapisa i njihovih obradnih funkcija pomoću mehanizama sličnih odgovarajućim alatima u objektno orijentiranim programskim jezicima.

Standardizirani objektno orijentirani model opisan je u preporukama standarda ODMG-93 (Object Database Management Group).

Razmotrimo pojednostavljeni model objektno orijentirane baze podataka. Struktura objektno orijentirane baze podataka grafički se prikazuje kao stablo čiji su čvorovi objekti. Svojstva objekata opisana su nekim standardnim tipom ili korisnički konstruiranim tipom (definiranim kao klasa). Vrijednost svojstva tipa class je objekt koji je instanca odgovarajuće klase. Svaki objekt instance klase smatra se djetetom objekta u kojem je definiran kao svojstvo. Objekt instance klase pripada svojoj klasi i ima jednog roditelja. Generički odnosi u bazi podataka tvore koherentnu hijerarhiju objekata. Primjer logičke strukture objektno orijentirane bibliotečne baze podataka prikazan je na sl. 2.9. Ovdje je objekt tipa Knjižnica je roditelj objekata instance klase Pretplatnik, Katalog I Problem. Objekti raznih vrsta knjige a mogu imati iste ili različite roditelje. Objekti tipa Knjiga, koji imaju istog roditelja, moraju se razlikovati barem u pristupnom broju (jedinstvenom za svaki primjerak knjige), ali imati iste vrijednosti svojstava isb n, udk, Ime e i Autor.

Logička struktura objektno orijentirane baze podataka naizgled je slična strukturi hijerarhijske baze podataka. Glavna razlika između njih je u metodama manipulacije podacima.

Za izvođenje radnji nad podacima u modelu baze podataka koji se razmatra, koriste se logičke operacije, poboljšane objektno orijentiranim mehanizmima enkapsulacije, nasljeđivanja i polimorfizma.

Enkapsulacija ograničava opseg naziva svojstva na granice objekta u kojem je ono definirano. Dakle, ako u objektu tipa Katalog dodajte svojstvo koje navodi telefonski broj autora knjige i ima naslov telefon, tada ćemo dobiti istoimena svojstva za objekte Pretplatnik I Katalog. Značenje takvog svojstva odredit će objekt u koji je uklopljeno.

Nasljedstvo, naprotiv, proširuje opseg svojstva na sve potomke objekta. Dakle, svi objekti tipa Knjiga, koji su potomci objekta tipa Katalog, nadređenom objektu možete dodijeliti svojstva: isbn, udk, Ime I Autor. Ako je potrebno proširiti mehanizam nasljeđivanja na objekte koji nisu neposredni srodnici (na primjer, između dvoje djece istog roditelja), tada se apstraktno svojstvo tipa definira u njihovom zajedničkom pretku trbušnjaci. Dakle, definicija apstraktnih svojstava ulaznica I broj u objektu Knjižnica uzrokuje da ta svojstva naslijede svih sedam podređenih objekata Pretplatnik, Knjiga I Problemi A. Nimalo slučajno, tako vrijednosti imovine ulaznica klase Pretplatnik I Problem, prikazano na sl. 2.9 su isti – 00015.

Polimorfizam u objektno orijentiranim programskim jezicima znači sposobnost istog programskog koda za rad s različitim vrstama podataka. Drugim riječima, to znači da je dopušteno da objekti različitih tipova imaju metode (procedure ili funkcije) s istim imenima. Tijekom izvođenja objektnog programa, iste metode djeluju na različite objekte ovisno o vrsti argumenta. U odnosu na primjer koji razmatramo, polimorfizam znači da objekti klase Knjiga imati različite roditelje iz razreda Katalog, može imati drugačiji skup svojstava. Stoga programi za rad s objektima klase Knjiga može sadržavati polimorfni kod.

Pretraživanje u objektno orijentiranoj bazi podataka uključuje pronalaženje sličnosti između objekta određenog od strane korisnika i objekata pohranjenih u bazi podataka.

Riža. 2.9. Logička struktura baze podataka knjižničarstva

Glavni dostojanstvo Objektno orijentirani podatkovni model u usporedbi s relacijskim je sposobnost prikazivanja informacija o složenim odnosima između objekata. Objektno orijentirani podatkovni model omogućuje vam identificiranje pojedinačnih zapisa baze podataka i definiranje funkcija za njihovu obradu.

Nedostaci Objektno orijentirani model karakterizira visoka konceptualna složenost, neugodnost obrade podataka i niska brzina izvršavanja upita.

Objektno orijentirani DBMS-ovi uključuju POET, Jasmine, Versant, O 2, ODB - Jupiter, Iris, Orion, Postgres.