Sistemi baza usmeni - pitanja Flashcards
- ER model: pojam i osnovni elementi.
Osnovna ideja
Realan savet može se opisati pomoću dva primitivna koncepta: entitet i veza.
Entitet je bilo koji objekat koji se može jednoznačno identifikovati.
Veza je relacija između dva ili više entiteta.
Namena modela
Za formiranje konceptualnog (logičkog) modela podataka.
Pogodno sredstvo za komunikaciju između korisnika i analitičara i projektanta softvera.
Osnovni koncepti ER model su:
entiteti i tip entiteta; jaki i slabi tip entiteta
atributi i vrednost atributa; ključni atribut; domen atributa
veze i tip veze; specijalni tipovi veza
ER dijagram (grafička reprezentacija ER modela)
Opis elemenata ER modela:
Entitet je subjekat, objekat, pojam, događaj ili stanje o kojima se prikupljaju, obrađuju i prezentiraju podaci u automatizovanim informacionim sistemima a koji se može jednoznačno identifikovati.
Atributi predstavljaju zajedničke osobine koje poseduju svi entiteti jednog skupa entiteta (jednovrednosni, viševrednosni, prost, složen, izveden, ključ).
Tip veze modelira relacije između entiteta u istom ili različitim skupovima. Veza uvek funkcioniše u oba smera.
- EER model: pojam i osnovni elementi.
EER (Enhanced entity-relationship) – prošireni ER model.
Osnovni koncepti:
Klase
Klasa se posmatra kao skup (kolekcija) entiteta. Tipovi entiteta se tretiraju kao klase.
Podklasa i nadklasa
Podklase nasleđuju nadklase.
Nasleđivanje
Ograničenja u nasleđivanju:
1. Participacija – disjunktna (svaki entitet nadklase pripada samo jednoj podklasi), overlap (entitet nadklase može da pripada većem broju podklasa).
2. Kompletnost – potpuna (svaki entitet nadklase priprada nekoj podklasi), parcijalna (entiteti nadklase ne moraju pripadati nijednoj podklasi).
Specijalizacija
Postupak definisanja podklasa pri čemu se kreće od postojećih klasa, kod kojih se traže moguće specijalizacije koje pored zajedničkih osobina sadržanih u klasi imaju svoje specifične.
Generalizacija
Postupak kod koga se od više postojećih uočavanjem zajedničkih osobina definiše generalnija klasa.
Kategorije
Kategorije su nastale zbog potrebe postojanja klasa koje imaju više od jedne nadklase.
Ako se nadklase jedne podklase totalno razlikuju, nemaju isti ključ takva podklasa se naziva kategorija.
Kod kategorija postoji selektivno nasleđivanje odnosno nasleđivanje predstavlja presek nadklasa.
Deljive klase
Deljive klase su klase sa više od jedne nadklase.
Deljive klase obezbeđuju višestruko nasleđivanje.
Deljive klase nasleđuju klase istog tipa (isti ključ) i nasleđivanje predstavlja uniju.
- Prevođenje ER modela u relacioni model.
- Prevođenje regularnih tipova entiteta.
- Prevođenje slabih tipova entiteta.
- Prevođenje veze 1:1.
- Prevođenje veze 1:N.
- Prevođenje veze M:N.
- Prelikavanje viševrednosnih atributa.
- Preslikavanje N-arnih veza.
- Prevođenje EER modela u relacioni model.
Za prevođenje EER modela neophodna su tri dodatna koraka u odnosu na ER model. U praksi se primenjuju ranije, paralelno sa slabim tipovima entiteta.
1. Preslikavanje veza tipa klasa/podklasa.
Alternativa A: Tabele i za nadklase i podklase.
Alternativa B: Tabele samo za podklase.
Alternativa C: Tabela samo za nadklasu sa svim mogudim atributima i tipom.
Alternativa D: Tabela samo za nadklasu sa svim mogudim atributima i bool-ovima za podklase.
2. Preslikavanje deljivih klasa.
Slično kao i za klase/podklase, te alternative.
3. Preslikavanje kategorija.
Dodaje se surogat ključ svim relacijama. Relacije za sve entitete.
- PL/SQL – pojam, namena i osnovni elemeneti.
Procedural language extension to SQL – proceduralno proširenje SQL-a.
SQL ne poseduje elemente koji bi omogudili razvoj strukturnih programa.
Koristi se kada je korisnik ograničen samo na SQL on prosleđuje jednu po jednu naredbu DBMS-u.
PL/SQL prevazilazi ograničenja i dodaje strukturne elemente SQL-u.
Strukturni programski jezik za ORACLE.
Osnovni ciljevi PL/SQL:
Povedanje ekspresivnosti SQL-a.
Pristup rezultatima upita korišdenjem slogova.
Optimizacija kombinacija SQL naredbi.
Razvoj modularnih aplikacija za rad sa bazom podataka.
Višestruko korišdenje programskog koda.
Smanjenje cene održavanja i izmene aplikacije.
Osnovna struktura PL/SQL programa:
Osnovna gradivna jedinica je blok.
PL/SQL program se satoji od blokova koji se mogu ugnježdavati.
Blok predstavlja jednu logučku operaciju.
Blokovi koji predstavljaju funkcije, procedure ili pakete moraju imati ime.
PL/SQL ima opcionu selekciu za deklaracije, obavezan deo koji sadrži PL/SQL naredbe i opcioni za obradu grešaka i izuzetka.
PL/SQL program u obaveznom delu može imati SQL naredbe iz grupe DML narebi (SELECT, INSERT, UPDATE, DELETE…).
PL/SQLprogram ne sme da sadrži SQL naredbe iz grupe DDL narebi (CREATE, DROP, ALTER…) umesto njih koristi funkcije iz posebno definisanih paketa.
PL/SQL program sadrži:
deklaracije promenljivih
naredbe dodele
naredbe za kontrolu toka
naredbe petlji
pozive funkcija i procedura
pozive trigger-a
naredbe za obradu grešaka i izuzetaka
Promenljive se koriste za razmenu podataka između baze podataka i PL/SQL programa. Konstante, promenljive, kursori i izuzeci koji se koriste u nekom bloku moraju biti deklarisani u DECLARE sekciji tog bloka.
- Objasniti pojam trigera.
Element šeme baze podataka.
Blok PL/SQL koda koji se izvršava (jednom, pre ili posle) kao odgovor na događaje –insert, update, delete, ako je ispunjen zadati uslov.
Nadgledanje (potencijalnih) promena u bazi podataka.
Forsiranje ograničenja.
Primena trigera:
Forsiranje poslovnih (business) pravila koja se ne mogu predstaviti built-in ograničenjima integriteta.
Automatsko setovanje IDova (autonumber, surogat ključeva) i izvedenih vrednosti .
Provera promena u podacima.
Automatsko čuvanje starih verzija podataka (logovanje akcija korisnika).
Automatska propagacija modifikacija.
Realizacija materijalizovanih pogleda (pogledi koji fizički postoje, fizička kopija podataka)i replikacija promena u osnovne tabele.
Podrška za smart modifikacije pogleda .
Šta sve može da se nadgleda:
Događaji u bazi podataka.
Događaji koji se odnose na definiciju podataka.
Događaji koji se odnose na manipulaciju podacima.
Granularnost trigera:
Na nivou izraza – izvršava se kod trigera jednom, pre ili posle izraza koji je naveden.
Na nivou vrste – Izvršava se kod trigera jednom, pre ili posle promene svake vrste.
- Tipična arhitekturna rešenja za razvoj aplikacija za rad sa bazama podataka.
Klijent je bilo koji korisnik ili program koji zeli da izvrsi odredjenu operaciju nad sistemom. Klijent interaguje sa sistemom koriscenjem prezentacionog sloja (korisnicki interfejs). Aplikativna logika definise sta sistem radi. Namece poslovna pravila i definise poslovne procese. Sloj za upravljanje resursima definise organizaciju (skladistenje, indeksiranje i pribavljanje) podataka koji su neophodni kao podrska za aplikativnu logiku. Tipicno se radi o bazi podataka.
Jednoslojna arhitektura (prez/app log/resursi) :
Svi slojevi aplikacije su implementirani kao jedan monolitni entitet. Kompletna aplikacija se nalazi na jednom racunaru tj. Na jednoj platformi. Sve se desava na jednom mestu.
Dvoslojna arhitektura (prezentacioni + app log/resursi):
Ovo je tradicionalna ahitektura i ukljucuje postojanje 2 racunara koji ucestvuju u izvrsenju aplikacije.
Klijenti su medjusobno nezavisni pa za različite klijente moze da postoji različiti prezentacioni sloj u zavisnosti od funkcionalnosti koje aplikacija nudi. Obicno su tanki (thin client) i imaju vrlo ogranicene mogucnosti. Klijentima su se smatrali i prosti ulazni uredjaji ciji zadatak je bio da samo prikazu klijentski interfejs koji se izvrsava na udaljenoj platformi. Ovo su tanki klijenti.
Na serveru se nalaze sve datoteke, baza podataka i komponente koje implementiraju aplikativnu logiku.
Baza podataka ima samo jednog klijenta: sloj aplikativne logike.
Vremenom klijentski racunari postaju sve mocniji. U cilju rasterecivanja servera deo aplikativne logike se seli na klijentski racunar. Samim tim klijenti dobijaju mogucnost da izvrsavaju znacajniji deo funkcionalnosti aplikacije pa se klijenti u tim situacijama smatraju debljim (fat client). Debljina klijenta varira od aplikacije do aplikacije i delom je odgovornost projektanata aplikacija. Ukoliko se zanemari prezentacioni sloj, na serverskoj strani se sve izvrsava na jednom mestu poput sistema sa jednoslojnom arhitekturom. Definise se pojam programskog interfejsa aplikacije (API) – interfejs koji omogucava da se elementi aplikativne logike pozovu spolja.
Dvoslojna klijent/server arhitektura uvodi pojam servisa. Klijenti koriste servise koje server implementira. Takodje se uvodi pojam interfejsa servisa. Interfejs servisa definise kako klijent moze koristiti servis. Interfejsi svih servisa koje server implementira predstavlja serverski API.
Troslojna arhitektura (prez + app log + resursi):
Dvoslojne arhitekture su bile popularne do trenutka kada je postalo jasno da je opterecenje na serverskoj strani moguce dodatno raspodeliti odnosno distribuirati. Osnovni problem dvoslojne arhitekture je jaka sprega izmedju aplikativne logike i izvora podataka koji aplikacija koristi. Kod troslojnih sistema tri sloja aplikacije su potpuno odvojena i u vecini slucajeva distribuirana na razlicitim platformama. Srednji sloj obuhvata kompletnu aplikativnu logiku i naziva se middleware i aplikativni server. Bolja raspodela opterecenja i bolja skalabilnost sistema.
Viseslojna arhitektura (prez sloj nije više kod klijenta) :
Web serveri se cesto ponasaju kao klijenti u situacijama kada koriste usluge drugih servera, ukljucujuci i servere baze podataka. Viseslojne aplikacije poseduju veci broj slojeva koji se mogu ponasati i kao klijenti i kao serveri. Svaki skup susednih slojeva predstavlja klijent-server uparivanje. U viseslojnim aplikacijama svaki sloj predstavlja aplikacioni sloj (browser, web server, aplikacioni server, baza podataka..). Poslednji sloj u arhitekturi je web klijent (u vecini slucajeva Web citac ili inteligenti agent) koji inicira obradu podataka slanjem podataka Web serveru.
- Tehnike za razdvajanje slojeva kod aplikacija za rad sa bazama podataka.
Osnovu svake aplikacije cine podaci, logika za njihovu obradu i nacin njihovog prikaza. Ove tri komponente cesto predstavljaju poprilicno nezavisne aspekte razvoja aplikacije. Posmatrano iz ugla koriscenja podataka, nebitan je izvor iz koga su podaci pribavljeni (baza podataka, fajl sistem, email..). Veoma je bitno izabrati otvoreni model za predstavljanje i obradu podataka. Time se omogucava vizuelizacija informacija na razlicite nacine tj kreiranje razlicitih pogleda na isti model podataka. Za razdvajanje slojeva mogu se koristiti razliciti projektni obrasci.
Model-View-Controller (MVC)
FALI SLIKA
Kontroler moze da salje komande modelu kako bi azurirao njegovo stanje. Kontroler salje komande pridruzenom pogledu kako bi promenio prezentaciju modela.
Model salje notifikacije pridruzenim kontrolerima i pogledima kada promeni svoje stanje. Ove notifikacije omogucavaju pogledima da generisu izmenjenu reprezentaciju modela a kontrolerima da izmene dostupni skup komandi. U nekim slucajevima implementacija MVC obrasca je pasivna. I pogledi i kontroleri moraju da prozivaju model kako bi detektovali izmene u njegovom stanju. Pogled zahteva informacije od modela na osnovu kojih generise reprezentaciju za potrebe korisnika.
Model-View-Presenter (MVP)
FALI SLIKA
Model predstavlja interfejs koji definise podatke koji ce biti prikazani ili na drugi nacin reaguje na akcije korisnika.
Pogled predstavlja pasivni interfejs koji prikazuje podatke i rutira korisnicke komande prezenteru radi dalje obrade.
Prezenter predstavlja sponu izmedju pogleda i modela. Na osnovu primljenih dogadjaja, pribavlja podatke iz modela i formatira za potrebe prikaza u pogledu.
Model-View-ViewModel (MVVM)
Model
FALI SLIKA
Model je skup klasa koje predstavljaju objektnu reprezentaciju podataka pribavljenih iz izvora podataka (baza podataka ili servis).
Pogled je komponenta sistema odgovorna za prezentaciju informacija.
ViewModel priprema podatke pribavljene iz modela za prikaz u pogledu. ViewModel se cesto opisuje kao reprezentacija stanja podataka u modelu.
- Navesti i objasniti projektne obrasce koji se koriste za modeliranje domena.
Domenska logika ili poslovna logika Posao koji sistem zaista obavlja odnosno implementacija različitih poslovnih procesa.
Za modeliranje domena mogu se iskoristiti 3 projektna obrasca:
1. Transaction Script.
Organizuje poslovnu logiku u vidu procedura pri čemu je svaka procedura zadužena za obradu jednog zahteva od strane prezentacionog sloja. Transaction Script logiku organizuje u jednu proceduru pri čemu se vrši direktna komunikacija sa izvorom podataka. Može se implementirati korišdenjem procedura, grupisanjem tranakcija u jednu ili više klasa i korišdenjem command patterna. Osnovna prednost korišdenja je jednostavnost i koristi se kada je domeska logika jednostavna. Za kompleksne poslovne logike se ne preporučuje (ograničen interfejs ili teško razumljiv kod).
2. Table Module.
Za svaku tabelu/pogled/upit postoji posebna instanca koja sadrži kompletnu poslovnu logiku za rad sa vrstama te tabele/pogleda/upita. Upakovani podaci da bi se maksimalno koristile prednosti relacionog modela. Poslovna logika upakovana kroz niz metoda koje pristupaju odgovarajudoj tabeli. Nije pogodan za predstavljanje kompleksne logike.
3. Domain Model.
OO model domena koji uključuje i podatke i poslovnu logiku. Mogu postojati objekti koji samo predstavljaju podatke, objekti koji predstavljaju poslovnu logiku ili objekti koji sadrže i jedno i drugo. Svaki objekat predstavlja neki od domenskih entiteta. Za kompleksne sisteme se koristi. Problem su razlike između OO modela i relacionog modela, neophodna stalna transformacija.
Za implementaciju se koriste 2 pristupa:
I. Active Record – Pored podataka i poslovne logike objekat uključuje i metode za rad sa relacionom bazom podataka. Predstavlja slog u tabeli odnosno za svaki slog se može kreirati instanca.
II. Data Mapper – Pored objekata koji sadrže podatke i poslovnu logiku postoje i posebni objekti koji su zaduženi za komunikacijom sa bazom podataka (transformacija jednog modela u drugi). OO model potpuno odvojen od baze i ne mora da bude svestan njenog postojanja.
- Objasniti problem Object-Relational Impedance Mismatch.
Skup konceptualnih i tehničkih problema koji se javljaju u situacijama kada OO sistem treba da koristi podatke u relacionoj bazi podataka, naročito u situacijama kada je objekte i klase potrebno mapirati u šemu relacione baze podataka.
Tipični problemi:
Granularnost – broj klasa ne odgovara broju tabela u bazi
Nasleđivanje – nije podržano u relacionom modelu Identitet- jednakost primarnih ključeva vs. identičnost i jednakost objekata
Asocijacije – veze između klasa vs. strani ključevi
Navigacija podataka – veze između klasa vs. strani ključevi
- Objasniti pojam objektno-relacionog mapera.
O/R maper predstavlja implementaciju Data Mapper projektnog obrasca. Object-Relational mapper (ORM) predstavlja tehniku koja omogudava konverziju podataka između nekompatibilnih sistema OO aplikacija i relacionih baza podataka. O/R maperi obezbeđuju perzistentnost objekata odnosno omogudavaju da objekti postoje nezavisno od same aplikacije.
-Prednosti korišdenja O/R mapera:
Skalabilnost
Skradeno vreme razvoja
Domain driven design
Nezavisnost od RDBMS-a
-Nedostaci O/R maper tehnologije
Performanse
Problemi prilikom mapiranja između OO modela i relacionog modela
- Navesti tipične projektne obrasce na kojima s ebazira arhitektura O/R mapera.
Unit of Work
Projektni obrazac koji omogudava O/R maperima:
Vođenje evidencije o svim objektima koji su izmenjeni tokom transakcije Kordinaciju upisa izmena u bazu podataka Rešavanje problema konkurencije
Nije pogodan pristup kod koga se svaka izmena nad objektima u memoriji prenosi u bazu podataka. Izmene se prosleđuju bazi podataka tek po završetku transakcije.
Identity map
Projektni obrazac koji omogudava O/R maperima:
Svaki objekat može u memoriju da se učita samo jednom Sve objekte učitane u memoriju čuva u mapi (dictionary) Prilikom referenciranja objekata koristi se njihova instanca koja je učitana u mapu
Identity map je validna tokom trajanja Unity of Work.
Lazy load
Projektni obrazac koji omogudava O/R maperima:
Prilikom učitavanja objekta ne učitavaju se svi podaci koje objekat sadrži Inicijalno su učitani samo neophodni podaci Ostali podaci se učitavaju na zahtev odnosno u trenutku kada su potrebni Objekat zna kako da učita nedostajude podatke
Kada se objekat učitava u memoriju korisno je učitati i povezane objekte. Time se znatno olakšava navigacija podataka. Takva strategija može da dovede do nepotrebnog učitavanja velikih količina podataka. Zbog toga je korišdenje lazy load tehnika od ključne važnosti.
NHibernate
Glavna funkcionalnost koju Nhibernate obezbeđuje je mapiranje između .NET klasa i odgovrajudih tabela u relacionoj bazi. Osim toga obezbeđuje mehanizme za pretraživanje i učitavanje podataka. Omogudava da se razvijaju poslovni objekti u obliku .NET klasa. Svaki poslovni objekat je predstavljen jednom POCO .NET klasom. To je standardna klasa koja ne nasleđuje bilo koju specijanu klasu. Nhibernate koristi XML mapping datoteke za odgovarajude .NET klase kako bi obezbedio podršku za CRUD operacije.
- Definisati pojam transakcije, osnovne operacije I svojstva.
ACID svojstva transakcije:
1. Atomičnost (atomicity) – Sve naredbe transakcije se izvršavaju kao celina ili se ne izvršavaju.
2. Konzistentnost (consistency)- Transakcija prevodi bazu podataka iz jednog konzistentnog stanja u drugo.
3. Izolacija (isolation) – Efekti transakcije nisu vidljivi dok se transakcija ne komituje.
4. Trajnost (Durability) – Izmene nad podacima načinjene tokom transakcije su trajne.
Transakcija predstavlja sekvencu SQL DML (data manipulation) naredbi koja predstavlja jednu logičku celinu.
Oracle transakciju tretira kao celinu sve dok sve izmene načinjene od strane SQL naredbi ne postanu validne (commited) ili dok ne budu poništene (rollbacked).
Prva SQL naredba nekog programa započinje novu transakciju. Jedna se završi slededa počinje.
Svaka SQL naredba je sastavni deo neke transakcije.
COMMIT Nareba završava tekudu transakciju i potvrđuje i trajno snima modifikacije učinjene tokom trasakcije.
ROLLBAC K naredba završava tekudu transakciju i poništava sve modifikacije učinjene tokom transakcije.
SAVEPOINT naredba označava i snima tekudu tačku u transakciji.
- Definisati pojam nivo izolacije I objasniti na primeru Oracle DBMS-a.
Nivo izolacije je sposobnost sistema da promene učinjene u jednoj operaciji učini nevidljivim za druge operacije.
Oracle podržava 3 nivoa izolacije:
1. READ COMMITED :
Podrazumevani nivo izolacije. Ukoliko neka naredba transakcije zahteva lock koji ved drži neka druga transakcija, naredba čeka da se oslobodi. Transakcije se izvršavaju paralelno i izmene koje vrši jedna transakcija nisu vidljive ostalim dok sene izvrši COMMIT naredba. Vide se izmene samo koje su bile commitovane pre početka.
2. SERIALIZABLE:
Transakcije se izvršavaju tako da izgleda kao da se izvršavaju jedna za drugom. Ako neka transakcija zahteva lock koji drži neka druga transakcija onda se ta naredba završava greškom. Vide se izmene samo koje su bile validne pre početka transakcije.
3. READ ONLY:
Poseban slučaj serializable izolacije. Transakcija čita podatke samo iz baze. Transakcija vidi izmene koje su bile validne pre početka transakcije. Podržane su naredbe: SELECT INTO, FETCH, CLOSE, LOCK TABLE, COMMIT, ROLLBACK.
- Definisati mehanizam zaključavanja kod relacionih DBMS-ova.
Mehanizam zaključivanja omogudava korišdenje baze podataka u višekorisničkom okruženju bez opasnosti da de dodi do narušavanja konzistentnosti podataka. Sprečava mogudnost destruktivne iterakcije između transakcija. Oracle vodi automatski računa o mehanizmu zaključivanja. Svi lock-ovi koje naredbe pribave u okviru jedne transakcije sve dok se ne commituje ili rollbackuje. Po završetku Oracle oslobađa sve lock-ove.
Oracle podržava dva moda zaključavanja:
1. Ekskluzivni mod – Onemogudava deljenje resursa između transakcija.
2. Deljivi mod – Omogudava deljenje resursa u zavisnosti od operacije koja se izvršava nad tim resursom.
Oracle podržava nekoliko tipova zaključavanja:
1. DML locks (row level i table level locks) – Zaključavanje sloga/skupa slogova ili sprečava DDL nad tabelom.
2. DDL locks – štiti definiciju objekta toko izvršavanja DDL operacija.
3. Oracle Internal Locks – potpuno automatizovani mehanizam za oracle-ve interne strukture podataka.
