Primjer objektno orijentiranog modela podataka. Objektno orijentirani model baze podataka. Nedovoljna podrška za složene objekte

Objektno orijentirani model podataka proširenje je odredbi objektno orijentiranog programiranja (dok je relacijski model nastao na temelju teorije skupova, upravo kao model podataka). ODMG-93 (Object DataBase Management Group) standard je razvila Object-Oriented Database Management Group. Ovaj standard još nije u potpunosti implementiran.

Struktura objektno orijentirane baze podataka grafički je predstavljena u obliku stabla, čiji su čvorovi objekti. Vidljiva struktura objekta određena je svojstvima njegove klase. Razred 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- bilo standardni tip, kao što je string, ili klasu tipa koju je izradio korisnik. Ponašanje objekata postavlja se pomoću metoda. Metoda Je operacija koja se može primijeniti na objekt.

Kao primjer, razmotrite bazu podataka "LIBRARY" (slika 4.4). Za svaki objekt definiraju se svojstva, njihove vrste i vrijednosti. U DB-u:

"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 orijentirane baze podataka slična je hijerarhijskoj, glavna razlika je u metodama manipulacije podacima. Iznad baze podataka možete izvoditi radnje kao što su logičke operacije, poboljšane objektno orijentiranim metodama enkapsulacije, nasljeđivanja i polimorfizma.

Enkapsulacija ograničava opseg imena svojstva na granice objekta u kojem je definirano. Dakle, ako se nekretnina doda u "KATALOG" telefon autora knjige, zatim dobivene na isti način u "PRETPLATI" i "KATALOGU". Značenje svojstva bit će određeno objektom u koji je inkapsulirano.

Nasljedstvo obrnuto, proširuje opseg svojstva na sve potomke objekta. Tako se svim objektima tipa "KNJIGA" koji su potomci "KATALOGA" mogu dodijeliti svojstva nadređenog isbn-a, UDK-a, imena i autora.

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

Prednosti objektno orijentiranog modela u usporedbi s relacijskim modelom su mogućnost prikaza informacija o složenim odnosima objekata, odsutnost ograničenja u strukturama pohrane podataka. Objektno orijentirana baza podataka može pohraniti ne samo strukturu, već i aspekte ponašanja podataka. Koristeći objektno orijentirani pristup, mogu se kreirati i baze podataka s velikim količinama semantičkih informacija, poput multimedijskih i specijaliziranih za određena predmetna područja (geografsko, dizajn, itd.).

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

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

Tema 5

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

Relacijski 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. Ovaj model se temelji na skupu međusobno povezanih tablica (relacija).

Glavne teorijske ideje relacijskog modela u djelima o teoriji odnosa iznijeli su 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 djelima Peircea i Schroedera dokazano je da je skup relacija zatvoren pod nekim posebnim operacijama koje zajedno tvore apstraktnu algebru. Ovo najvažnije svojstvo odnosa korišteno je u relacijskom modelu za razvoj jezika za manipulaciju podacima.

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

Osnovni koncepti relacijskog modela dati su u tablici. 3.1.

Objekti relacijskog modela su uglavnom tablice (relacije). Integritet podataka osiguravaju vanjski i primarni ključevi (vidi str. "Relacijski integritet podataka").

Operatori u relacijskom modelu skup su instrukcija koje dohvaćaju i manipuliraju podacima.

Tablica 5.1. Elementi relacijskog modela

Termin relacijskog modela	Opis

Baza podataka (DB)	Skup tablica i drugih objekata potrebnih za apstraktno predstavljanje odabranog predmetnog područja
DB shema	Skup zaglavlja tablice koji su međusobno povezani
Stav	Tablica - skup objekata stvarnog svijeta, koji se odlikuju zajedničkim svojstvima i karakteristikama (polja tablice)
Zaglavlje odnosa	Zaglavlje tablice - nazivi polja (stupaca) tablice
Tijelo veze	Tijelo tablice - zbirka vrijednosti za sve objekte u stvarnom svijetu, koji se mogu predstaviti kao zapisi tablice (redovi tablice)
Dijagram odnosa	Redak naslova stupaca tablice (zaglavlje tablice)
Atribut odnosa	Naziv stupca tablice (polje tablice)
Odnosni tuple	Red tablice (zapis) - nedvosmislen prikaz objekta stvarnog svijeta stvorenog pomoću vrijednosti polja tablice
Domena	Mnoge važeće 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 (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, tada se naziva skraćeni (djelomični) strani ključ
Stupanj (arnost) odnosa	Broj stupaca tablice
Snaga odnosa	Broj redaka (torke) tablice
Primjer veze	Skup zapisa (torke) za danu tablicu (relaciju). Instanca se može promijeniti tijekom vremena. Budući da obična baza podataka trenutno radi samo s jednom verzijom odnosa, takva instanca odnosa naziva se trenutna.
Vrsta podataka	Vrsta vrijednosti elemenata tablice
Osnovni odnos	Relacija koja sadrži jedan ili više stupaca koji karakteriziraju svojstva objekta, kao i primarni ključ
Izvedeni omjer	Nije osnovni odnos, t.j. ne karakterizira svojstva objekta i koristi se za pružanje veza između drugih tablica, ne smije sadržavati primarni ključ. Ako je naveden primarni ključ, tada se sastoji od stranih ključeva povezanih s primarnim ključevima temeljnog odnosa
Povezivanje	Uspostavlja odnos između podudarnih vrijednosti u ključnim poljima - primarnog ključa jedne tablice i stranog ključa druge
Odnos jedan na jedan (1:1)	Kada koristite ovu vrstu odnosa, zapis u jednoj tablici može imati najviše jedan pridruženi zapis u drugoj tablici. U obje tablice ključna polja moraju biti primarna. Koristi se za dijeljenje tablica s više polja ili zaštitu podataka na zahtjev
Odnos jedan prema više (1: M)	Kada se koristi ova vrsta odnosa, svaki zapis jedne tablice može odgovarati nekoliko zapisa druge, ali svaki zapis druge tablice odgovara samo jednom zapisu prve tablice. Primarni ključ mora biti naveden u prvoj tablici, a vanjski ključ u drugoj.
Odnos mnogo-prema-više (N:M)	Kod ove vrste 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 projektiranja sheme baze podataka takve se veze transformiraju. Da biste to učinili, trebate uvesti pomoćni odnos koji vam omogućuje da zamijenite odnos mnogo-prema-više s dva odnosa jedan-prema-više.

Struktura podataka relacijskog modela pretpostavlja prikaz 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). Za održavanje ovih veza, obje relacije moraju sadržavati skup atributa pomoću kojih su povezane: u glavnoj relaciji, ovo je primarni ključ relacije (jedinstveno identificira torbu glavne relacije); podređeni odnos mora imati skup atributa koji odgovaraju primarnom ključu glavnog odnosa. Ovdje je ovaj skup atributa već sekundarni ključ ili strani ključ, t.j. definira skup torki izvedene relacije povezan s jednom torbom osnovne relacije.

Nastaju mnoge međusobno povezane tablice db shema.

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

Matematički N-aran odnos R Je skup kartezijanskog proizvoda D 1 × D 2 ×… × D n skupovi (domene) D 1, D 2, ..., D n(n≥1), ne mora se razlikovati:

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

gdje D 1 × D 2 ×… × D n- potpuni kartezijanski proizvod, t.j. skup svih mogućih kombinacija od n elemenata svaki, pri čemu je svaki element preuzet iz vlastite domene.

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

Svojstva domene:

Domena ima jedinstveni naziv (unutar baze podataka),

Definirano na nekom jednostavnom tipu podataka ili na drugoj domeni,

Može imati neki booleov uvjet za opisivanje podskupa podataka dopuštenih za ovu domenu,

Nosi određeno semantičko opterećenje.

Glavno značenje domena je da 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<A: D>).

Imena atributa jedinstvena su unutar odnosa. Često su nazivi atributa isti kao i odgovarajući nazivi domena.

R, definiran u više domena, ima dva dijela: zaglavlje i tijelo.

Zaglavlje odnosa- fiksni broj atributa odnosa koji opisuju kartezijanski proizvod domena na kojima je odnos specificiran:

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

Zaglavlje je statičko: ne mijenja se tijekom rada s bazom podataka.Ako je relacija promijenjena, dodana ili uklonjena atributa, tada se dobiva drugačija relacija. Čak i sa spremljenim imenom.

Tijelo odnos sadrži mnoge torke odnosa.

Svaki povorka je 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 zbirka torki, odnosno podskup kartezijanskog proizvoda domena. Dakle, tijelo relacije je samo po sebi relacija u matematičkom smislu riječi. Tijelo odnosa može se promijeniti tijekom rada s bazom podataka, budući da 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 s naznakom domene kojoj pripadaju:

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

Ako atributi uzimaju vrijednosti iz iste domene, tada se nazivaju θ-usporedivi, gdje je θ skup valjanih usporedbi navedenih za ovu domenu.

Na primjer, ako domena sadrži numeričke podatke, tada su sve operacije usporedbe važeće za nju: θ == (=,<>,>=,<=,<,>). Međutim, čak i za domene koje sadrže znakovne podatke, ne mogu se specificirati samo operacije usporedbe jednakosti i nejednakosti. Ako je leksikografski poredak specificiran za danu domenu, tada ima i cijeli skup operacija usporedbe.

Zovu se sheme dvaju odnosa ekvivalent ako imaju isti stupanj, a poredak imena atributa u shemama je moguć tako da će usporedivi atributi biti na istim mjestima, tj. atributi koji preuzimaju vrijednosti iz iste domene.

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

Prisutnost istog broja atributa;

Prisutnost atributa s istim imenima;

Prisutnost istih nizova u odnosu, s obzirom da se redoslijed atributa može razlikovati;

Odnosi ove vrste su različite slike istog odnosa.

Svojstva odnosa izravno slijede iz gornje definicije odnosa. Ova svojstva su u osnovi razlika između odnosa relacijskog modela podataka i jednostavnih tablica:

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

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

Neuređene torke. Korke nisu poredane (od vrha do dna), budući da je tijelo relacije skup, a skup nije uređen (za usporedbu, redovi u tablicama su poredani). Isti odnos može se predstaviti različitim tablicama, u kojima su redovi različiti redoslijed.

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

Jedinstvenost imena 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 se donekle razlikuje od matematičke definicije odnosa. Isti odnos može se predstaviti 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, odnosno da je raspon vrijednosti (poseban elementarni tip) povezan sa svakim atributom, vrijednosti atributa su preuzete iz iste domene. Sheme odnosa i torke su skupovi, a ne liste, tako da redoslijed kojim su predstavljeni nije bitan. Za usporedbu, različite informacije mogu se smjestiti u ćelije tablice: nizovi, strukture, druge tablice itd.

Komentar:

Iz svojstava relacije proizlazi da ne svaki tablica može biti relacija. Da bi određena tablica definirala odnos potrebno je da tablica ima jednostavnu strukturu (sadrži samo retke i stupce, a svaki red mora imati isti broj polja), tablica ne smije imati identične retke, niti jedan stupac tablice mora sadržavati podatke samo jedne vrste, svi korišteni tipovi podataka 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 prezentacija podataka omogućuje identifikaciju pojedinačnih zapisa baze podataka.

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

Definicija 2

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

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

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

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

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

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

Definicija 3

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

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

Definicija 4

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

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

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

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

Definicija 5

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

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

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

Prednosti i nedostaci objektno orijentiranog modela

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

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

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

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

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

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

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

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

Primjer logičke strukture OO DB knjižničarstva prikazan je na sl. 3.14. Ovdje je objekt tipa KNJIŽNICA nadređeni objekti primjera klasa SUBSCRIBER, DIRECTORY i OUTPUT. Različiti objekti tipa KNJIGA koji imaju isti roditelj moraju se razlikovati barem po inventarnom broju (jedinstven za svaki primjerak knjige), ali imati iste vrijednosti svojstva isbn, udk, ime i Autor.

Slika 3.14. Logička struktura knjižnične baze podataka

Logička struktura OO baze podataka izvana je slična strukturi hijerarhijske baze podataka. Glavna razlika između njih leži u metodama manipulacije podacima. Za izvođenje radnji nad podacima u OOM bazi podataka koriste se logičke operacije, ojačane objektno orijentiranim mehanizmima enkapsulacije, nasljeđivanja i polimorfizma. Operacije slične SQL naredbama mogu se koristiti u ograničenoj mjeri (na primjer, za stvaranje baze podataka).

Kreiranje i modifikacija baze podataka prati automatsko formiranje i naknadno prilagođavanje indeksa (indeksnih tablica) koji sadrže informacije za brzi dohvat podataka.

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

Enkapsulacija ograničava opseg imena svojstva na granice objekta u kojem je definirano. Dakle, ako objektu tipa DIRECTORY dodate svojstvo koje postavlja telefonski broj autora knjige i ima naziv telefon, tada ćemo dobiti svojstva istog imena za objekte SUBSCRIBER i DIRECTORY. Značenje takvog svojstva odredit će objekt u koji je inkapsulirano.

nasljedstvo, naprotiv, proširuje opseg svojstva na sve potomke objekta. Dakle, svim objektima tipa BOOK koji su potomci objekta tipa DIRECTORY mogu se dodijeliti svojstva roditeljskog objekta: isbn, udk, ime i Autor. Ako je potrebno proširiti učinak mehanizma nasljeđivanja na objekte koji nisu neposredni srodnici (na primjer, između dva potomka istog roditelja), tada se u njihovom zajedničkom pretku definira apstraktno svojstvo tipa abs. Dakle, definicija apstraktnih svojstava ulaznica i soba u objektu LIBRARY uzrokuje da ova svojstva nasljeđuju svi podređeni objekti SUBSCRIBER, BOOK i REFERENCE. Nije slučajno da su vrijednosti imovine ulaznica klasa PRETPLATNIK i IZDANJE prikazani na slici bit će isti - 00015.

Polimorfizam u objektno orijentiranim programskim jezicima, to znači sposobnost istog programskog koda da radi s različitim vrstama podataka. Drugim riječima, to znači da je moguće imati metode (procedure ili funkcije) s istim nazivima u objektima različitih tipova. Tijekom izvođenja objektnog programa, iste metode djeluju na različitim objektima ovisno o vrsti argumenta. Kako se primjenjuje na naš OO DB, polimorfizam znači da objekti klase BOOK, koji imaju različite roditelje od klase DIRECTORY, mogu imati različit skup svojstava. Posljedično, programi za rad s objektima klase BOOK mogu sadržavati polimorfni kod.

Pretraživanje u OO bazi podataka sastoji se od pronalaženja sličnosti između objekta koji je odredio korisnik i objekata pohranjenih u bazi podataka. Korisnički definiran objekt nazvan ciljni objekt (svojstvo objekta je tipa goal), u općem slučaju, može predstavljati podskup cijele hijerarhije objekata pohranjenih u bazi podataka. Ciljni objekt, kao i rezultat izvršenja upita, može se pohraniti u samoj bazi podataka. Primjer zahtjeva za brojevima knjižničnih iskaznica i imenima pretplatnika koji su primili barem jednu knjigu u knjižnicu prikazan je na sl. 3.15.

Glavni dostojanstvo OOM u odnosu na relacijske podatke je mogućnost prikaza informacija o složenim objektnim odnosima. OOM podaci omogućuju vam da identificirate jedan zapis baze podataka i definirate funkcije njihove obrade.

Hendikep OOM su visoka konceptualna složenost, neugodnost u obradi podataka i mala brzina upita.

Slika 3.15. Fragment baze podataka s ciljnim objektom

Vratimo se ponovno zadatku Orders, predstavljenom u obliku relacijskog modela podataka na Sl. 3.8 i razmotriti ga u smislu objektno orijentirane baze podataka. Ukupno postoje tri razreda: " Klijenti», « Narudžbe"i" Roba". Objekti klase " Klijenti»Jesu li specifični klijenti; svojstva klase - broj kupca, ime kupca Grad, status itd. Metode klase - " Kreirajte red», « Platiti fakturu" itd. Metoda je neka vrsta operacije koja se može primijeniti na objekt; metoda je ono što objekt treba učiniti. Klasa koja odgovara tablici " Detalji narudžbe", nije obavezno. Podaci tablice mogu biti dio klase " Narudžbe". Prisutnost u razredu" Klijenti"metoda" Kreirajte red"Dovodi do interakcije s objektima klase" Narudžbe"i" Roba". U ovom slučaju korisnik ne mora znati za ovu interakciju objekata. Korisnik se poziva samo na objekt " Narudžbe"I koristi metodu" Kreirajte red". Utjecaj na druge baze podataka može se sakriti od korisnika. Ako je metoda " Kreirajte red", zauzvrat se odnosi na metodu" Provjerite kreditnu sposobnost kupca“, Ova se činjenica također može sakriti od korisnika. U relacijskim bazama podataka, izvođenje iste funkcionalnosti zahtijeva postupke pisanja u Visual Basicu za aplikacije (VBA).

U 90-im godinama postojali su eksperimentalni prototipovi sustava upravljanja OO bazama podataka. Trenutno su takvi sustavi široko rasprostranjeni. To posebno uključuje sljedeće DBMS-ove: POET (POET Software), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (Ardent Software), ODB-Jupiter (Inteltek Plus Research and Production Center) i Iris, Orion i Postgres.

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

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

Slika 3. Objektno orijentirani model podataka

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

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

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

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

2.2.4 relacijski model podataka

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

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

Slika 4. Tablica relacijske baze podataka.

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

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

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

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

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

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

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

Slika 6. Primjer korištenja stranog ključa

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

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

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

· Operatori definicije podataka;

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

· Operatori definicije pristupa podacima.

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

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

Prednosti relacijskog modela su:

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

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

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

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

Nedostaci relacijskog modela su:

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

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

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

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

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 funkcija obrade korištenjem mehanizama sličnih onima 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 je predstavljena u obliku stabla, čiji su čvorovi objekti. Svojstva objekata opisana su nekim standardnim ili korisničkim tipom (definiranim kao klasa). Vrijednost svojstva tipa class je objekt koji je instanca odgovarajuće klase. Svaka instanca klase smatra se potomkom objekta u kojem je definirana kao svojstvo. Objekt instance klase pripada svojoj klasi i ima jednog roditelja. Generički odnosi u bazi podataka čine koherentnu hijerarhiju objekata. Primjer logičke strukture objektno orijentirane knjižničarske baze podataka prikazan je na Sl. 2.9. Ovdje je objekt tipa Knjižnica nadređeni objekti na primjer klasa Pretplatnik, Imenik i Izdavanje. Različiti predmeti knjige mogu imati iste ili različite roditelje. Objekti tipa Knjiga koji imaju isti roditelj moraju se razlikovati barem po inventarnom broju (jedinstveno za svaki primjerak knjige), ali imati iste vrijednosti svojstva isbn, udc, naslov i autora.

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

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

Enkapsulacija ograničava opseg imena svojstva na vanjštinu objekta u kojem je definirano. Dakle, ako objektu tipa Catalog dodamo svojstvo koje postavlja telefonski broj autora knjige i ima naziv phone, tada ćemo dobiti svojstva istog imena za objekte Pretplatnik i Katalog. Značenje takvog svojstva odredit će objekt u koji je inkapsulirano.

Nasljeđivanje, s druge strane, proširuje opseg svojstva na sve potomke objekta. Dakle, svim objektima tipa Book koji su potomci objekta tipa Catalog mogu se dodijeliti svojstva nadređenog objekta: isbn, udk, naslov i autor. Ako je potrebno proširiti učinak 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 ulaznice apstraktnih svojstava i broja u objektu Library dovodi do nasljeđivanja ovih svojstava od strane svih podređenih objekata Subscriber, Book i Issue. Stoga nije slučajno da vrijednosti svojstva ulaznice klasa Pretplatnik i Izdavanje prikazane na Sl. 2.9 su isti - 00015.

Polimorfizam u objektno orijentiranim programskim jezicima znači sposobnost istog programskog koda da radi s različitim vrstama podataka. Drugim riječima, to znači da je moguće imati metode (procedure ili funkcije) s istim nazivima u objektima različitih tipova. Tijekom izvođenja objektnog programa, iste metode djeluju na različitim objektima ovisno o vrsti argumenta. Za ovaj primjer, polimorfizam znači da objekti klase Book koji imaju različite roditelje od klase Catalog mogu imati drugačiji skup svojstava. Stoga programi za rad s objektima klase Book mogu 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.

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

Glavna prednost objektno orijentiranog modela podataka u usporedbi s relacijskim je mogućnost prikaza informacija o složenim odnosima između objekata. Objektno orijentirani model podataka omogućuje vam da identificirate jedan zapis baze podataka i definirate funkcije njihove obrade.

Nedostaci objektno orijentiranog modela su visoka konceptualna složenost, neugodnost u obradi podataka i mala brzina upita.

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

Banke podataka u cjelini obično se klasificiraju prema ekonomskim i pravnim karakteristikama.

Prema uvjetima pružanja usluga razlikuju se besplatne i plaćene banke, koje se, pak, dijele na komercijalne i neprofitne (znanstvene, knjižnične ili društveno značajne).

Prema obliku vlasništva BND se dijele na državne i nedržavne. Prema stupnju pristupačnosti razlikuju javne i s ograničenim brojem korisnika.

Druge vrste klasifikacije povezane su s pojedinačnim komponentama BnD.

1. Razvoj banaka podataka sastoji se od 4 faze:

1. faza. Formiranje i analiza zahtjeva sustava:

Izrađuje se specifikacija sustava, uključujući popis zadataka koje treba riješiti BND;

Popis krajnjih korisnika i njihove funkcije;

Popis zahtjeva za bazu podataka;

Izrađuje se dijagram toka dokumenata u organizaciji.

2. faza. Idejni projekt: izrađuje se informacijski model sustava bez osvrta na vrstu računala i vrstu softvera sustava; gradi se infološki model baze podataka koji najpotpunije opisuje predmetno područje u smislu korisnika.

3. faza. Projekt implementacije: odabire se računalni sustav, softver sustava i DBMS; projektira se struktura podataka i gradi datalogički model baze podataka (shema baze podataka), koji predstavlja opis logičke strukture baze podataka na jeziku određenog odabranog sustava upravljanja bazom podataka.

4. faza. Fizička implementacija, koja uključuje kreiranje i učitavanje podataka u bazu podataka, razvoj i otklanjanje pogrešaka aplikacijskih programa za rad s bazom podataka, pisanje dokumentacije. U ovoj fazi gradi se fizički model baze podataka koji opisuje korištene uređaje za pohranu podataka, metode fizičke organizacije podataka. Opis fizičke strukture baze podataka naziva se shema pohrane. Trenutno postoji tendencija smanjenja ove vrste posla.

2. Glavni zadaci koje rješava osoblje banke podataka

Osoblje BND-a uključuje različite stručnjake: BND administratore, sistemske analitičare, sistemske i aplikativne programere, operatere, stručnjake za tehnička sredstva, marketing itd.

Nabrojimo glavne funkcije i zadatke koje je osoblje riješilo tijekom razvoja i rada baze podataka:

1) analiza predmetnog područja (utvrđivanje potreba krajnjih korisnika, izgradnja informacijskog modela predmetnog područja, utvrđivanje ograničenja integriteta);

2) projektiranje strukture baze podataka (određivanje sastava i strukture datoteka baze podataka, opisivanje njezine sheme u jeziku opisa podataka);

3) postavljanje ograničenja integriteta baze podataka;

4) učitavanje i održavanje baze podataka (održavanje baze podataka uključuje promjenu, brisanje i dodavanje zapisa); razvoj tehnologije utovara i održavanja; razvoj obrazaca za unos podataka; unos i kontrola podataka;

5) zaštita podataka (diferencijacija korisnika, odabir i provjera zaštitnih sredstava, bilježenje pokušaja neovlaštenog pristupa);

6) osiguranje oporavka baze podataka;

7) analiza učinkovitosti BnD-a i razvoja sustava;

8) rad s korisnicima (prikupljanje odgovora, obuka);

9) održavanje softvera sustava (nabavka, instalacija i razvoj);

10) organizacijsko-metodološki rad (izbor metoda projektiranja i modernizacije, planiranje razvoja BND-a, izrada dokumentacije).

3. Korisnici baza podataka

Kao i svaki softversko-organizacijsko-tehnički kompleks, banka podataka postoji u vremenu i prostoru. Ima posebne faze razvoja:

Oblikovati,

implementacija,

podrška,

Ažuriranje i razvoj,

Potpuna reorganizacija.

U svakoj fazi postojanja različite kategorije potrošača su povezane s bankom podataka.

Krajnji korisnici

Ovo je glavna kategorija korisnika čiji su interesi vezani uz banku podataka. Ovisno o karakteristikama kreirane banke podataka, ona se može bitno razlikovati u krugu svojih krajnjih korisnika. To mogu biti slučajni potrošači koji se s vremena na vrijeme obraćaju bazi podataka nakon što dobiju neku informaciju, a mogu biti i obični korisnici. Povremeni kupci mogu se promatrati kao potencijalni kupci tvrtke, pregledavajući katalog nastupa ili usluga s generaliziranim ili detaljnim opisom. Zaposlenici koji rade s programima posebno dizajniranim za njih, koji osiguravaju automatizaciju svojih radnji u obavljanju funkcija, mogu biti obični korisnici. Primjerice, administrator koji planira rad pomoćnog odjela računalne tvrtke ima program koji mu pomaže planirati i rasporediti tekuće narudžbe prema uputama, pratiti napredak njihove produktivnosti i organizirati potrebnu dodatnu opremu za nove narudžbe u skladištu. Glavna, posebna znanja koja se ne bi smjela zahtijevati od krajnjih korisnika u području jezika i računalne tehnologije.

Administratori banke podataka

Riječ je o skupini korisnika koja je u početnoj fazi razvoja baze podataka odgovorna za njen optimalan dizajn sa stajališta istovremenog rada skupa krajnjih korisnika, u potpori, faza je odgovorna za ispravan rad ovog hrpa informacija u višekorisničkom načinu rada. Tijekom faze projektiranja i reorganizacije, ova grupa je odgovorna za sposobnost ispravne reorganizacije stog bez promjene ili dovršetka njegovog tekućeg održavanja.

Programeri i administratori aplikacija

Ovo je grupa korisnika koja funkcionira tijekom projektiranja, kreiranja i reorganizacije baze podataka. Administratori aplikacija koordiniraju rad programera razvijajući određenu aplikaciju ili grupu aplikacija, ujedinjenih u funkcionalni podsustav. Programeri za određene aplikacije rade s dijelom podataka iz baze podataka koji je potreban za određenu aplikaciju.

Nema u svakoj banci podataka odabrane sve vrste korisnika. Poznato je da su u razvoju informacijskih sustava korištenjem tabelarnog DBMS-a administrator banke podataka, administrator aplikacije i programer često postojali u jednoj osobi. Međutim, kada se stvaraju moderne složene poslovne baze podataka koje se koriste za automatizaciju svih ili velikih dijelova poslovnih procesa u velikoj tvrtki ili korporaciji, mogu postojati grupe administratora aplikacija i razvojni odjeli. Najteži načini rada dodijeljeni su skupini administratora baze podataka.

Razmotrimo ih detaljnije.

Dio BnD administratorske grupe trebao bi biti:

Komentatori sustava;

Programeri strukture podataka i izgleda u vezi s bankom podataka za informacijsku podršku;

Programeri tehnoloških procesa obrade podataka;

Programeri sustava i aplikacija;

Operativne tvrtke i stručnjaci u servisu.

Pitanje komercijalne banke podataka igra važnu ulogu pri prodaji stručnjaka.

Glavne funkcije grupe DB administratora

1. Istraživanje podatkovnog područja: opis podatkovnog područja, pakiranje teksta ograničenja integriteta, utvrđivanje stanja (dostupnost, povjerljivost) informacija, utvrđivanje potreba potrošača, utvrđivanje korespondencije "potrošača podataka", određivanje vremenskog razdoblja. volumen karakteristika obrade podataka.

2. Razvoj strukture baze podataka: definicija sastava i strukture datoteka baze podataka i međuveza, izbor metoda za optimizaciju podataka i metoda pristupa informacijama, opisivanje baze podataka u jeziku opisa podataka (DLS) .

3. Postavljanje ograničenja integriteta u opisu strukture baze podataka i postupaka obrade baze podataka:

Postavljanje deklarativnih ograničenja integriteta svojstvenih području podataka;

Određivanje dinamičkih ograničenja integriteta svojstvenih području podataka tijekom promjene informacija pohranjenih u bazi podataka;

Definicija ograničenja integriteta naziva se strukturom baze podataka;

Izrada procedura za održavanje integriteta baze podataka pri unosu i ispravljanju podataka;

Određivanje ograničenja integriteta paralelnim radom potrošača u višekorisničkom načinu rada.

4. Pokrenite preuzimanje i vodite bazu podataka

Razvoj tehnike za pokretanje učitavanja baze podataka, koja će se razlikovati od postupka izmjene i dodavanja podataka uz redovito korištenje baze podataka;

Razvoj tehnike provjere unesenih podataka, stvarnog stanja podatkovnog područja. Stvarni objekti modela baze podataka nekog podatkovnog područja i korelacija je srednja, a u trenutku početka tekućeg popravka ovaj model mora u potpunosti odgovarati stanju objekata podatkovnog područja sada po vremenu;

Prema razvijenoj tehnici pokretanja učitavanja dizajna sustava, može biti potrebno pokretanje unosa podataka.

5. Zaštita podataka

Definiranje sustava lozinki, načela ciljanja potrošača, kreiranje grupa potrošača s identičnim pravima pristupa podacima;

Razvoj načela zaštite određenih podataka i razvojnih objekata; razvoj specijaliziranih metoda za kodiranje informacija tijekom njihovog kruženja u lokalnim i globalnim informacijskim mrežama;

Razvoj sredstava za fiksiranje pristupa podacima i pokušaja narušavanja sigurnosnog sustava;

Ispitivanje sustava zaštite;

Istraživanje slučajeva kršenja sustava zaštite i razvoj dinamičkih metoda zaštite informacija u bazi podataka.

6. Podrška za oporavak baze podataka

Razvoj organizacijskih sredstava arhiviranja i načela oporavka baze podataka;

Razvoj dodatnog softvera i tehnoloških procesa za oporavak baze podataka nakon kvarova.

7. Istraživanje poziva potrošačima baze podataka: skup statistike o simbolu zahtjeva, vremenu uključivanja njihove izvedbe, u skladu s potrebnim izlaznim dokumentima

8. Istraživanje učinkovitosti funkcioniranja BnD:

Istraživanje indeksa funkcioniranja BnD

Planiranje restrukturiranja (strukturne promjene) baze podataka i reorganizacije BND-a.

9. Rad s krajnjim korisnicima:

Prikupljanje informacija o promjeni područja podataka;

Prikupljanje informacija o procjeni rada BnD-a;

Obuka potrošača, savjetovanje potrošača;

Izrada potrebne sustavne i edukativne dokumentacije o radu krajnjih korisnika.

10. Priprema i održavanje alata sustava:

Istraživanje postojećih softvera na tržištu i istraživanje mogućnosti i nužnosti njihove uporabe u okviru BND-a;

Izrada potrebnog organizacijskog i tehničkog programa pokreta za razvoj BND-a;

Provjera izvedbe otkupljenog softvera prije spajanja na BND;

Kontrola povezivanja novog softvera na BND.

11. Organizacijski i sustavni rad u razvoju BND-a:

Odabir ili izrada metode razvoja baze podataka;

Određivanje ciljeva i smjera razvoja sustava u cjelini;

Planiranje faza razvoja BnD-a;

Izrada priručnika za opće rječnike projekta BND i idejnog modela;

Instalacija vanjskih modela razvijenih aplikacija;

Kontrola povezivanja nove aplikacije s radom BND-a;

Mogućnost složenog rješavanja problema skupa aplikacija koje djeluju iz jedne baze podataka.