DB predavanje Poglavlje 2 RELACIJSKE BAZE PODATAKA 2.1. Pojmovi i definicije Razvoj relacijskih baza podataka započeo je krajem 1960-ih, kada su se pojavili prvi radovi u kojima se raspravljalo o mogućnostima korištenja metoda formaliziranog prikaza podataka u obliku tablica koje su bile poznate stručnjaku. Neki stručnjaci su ovaj način prezentiranja informacija nazvali tablicama odlučivanja, drugi - tabličnim algoritmima. Teoretičari relacijskih baza podataka nazvali su tabelarni način predstavljanja informacija datalogičkim modelima. Utemeljiteljem teorije relacijskih baza podataka smatra se zaposlenik IBM-a dr. EF Codd, koji je 6. lipnja 1970. objavio članak "Relacijski model podataka za velike dijeljene banke podataka" "Relacijski model podataka za Velike zajedničke banke podataka". U ovom je članku po prvi put korišten izraz "relacijski model podataka" koji je postavio temelje za relacijske baze podataka. Teorija relacijske baze podataka razvijena je 1970-ih. u SAD-u dr. E. F. Codda, oslanjao se na matematički aparat teorije skupova. On je dokazao da se svaki skup podataka MOŽE predstaviti u obliku dvodimenzionalnih tablica posebne vrste, u matematici poznatih kao relacije. Od engleske riječi "relacija" "relacija") i došao je naziv "relacijski model podataka". Trenutno je teorijska osnova za dizajn baza podataka (DB) matematički aparat relacijske algebre (vidi odjeljak 1.2). Dakle, relacijska baza podataka je informacija (podatak) o objektima, predstavljena u obliku dvodimenzionalnih nizova - tablica, ujedinjenih određenim poveznicama. Baza podataka može se sastojati i od jedne tablice. Prije nego što prijeđemo na daljnje proučavanje relacijskih baza podataka, razmotrimo pojmove i definicije koje se koriste u teoriji i praksi. Tablica baze podataka- dvodimenzionalni niz koji sadrži informacije o jednoj klasi objekata. U teoriji relacijske algebre naziva se dvodimenzionalni niz (tablica). stav. Tablica se sastoji od sljedećih elemenata: polje, ćelija, zapis (slika 2.1). Polje sadrži vrijednosti jednog od atributa koji karakteriziraju objekte baze podataka. Broj polja u tablici odgovara broju znakova koji karakteriziraju objekte baze podataka. 22 stanica sadrži specifičnu vrijednost odgovarajućeg polja (atribut jednog objekta). Snimanje- red stola. Sadrži vrijednosti svih znakova koji karakteriziraju jedan objekt. Broj zapisa (redova) odgovara broju objekata o kojima se podaci nalaze u tablici. U teoriji baza podataka, pojam snimanje odgovara konceptu kor-tež- niz atributa koji su međusobno povezani relacijom I (AND). U teoriji grafova povorka označava jednostavnu granu usmjerenog grafa – stablo. Stol 2.1 prikazani su pojmovi koji se koriste u teoriji i praksi razvoja relacijskih baza podataka. Jedan od važnih koncepata potrebnih za izgradnju optimalne strukture za relacijske baze podataka je koncept ključa ili ključnog polja. Ključ smatra se polje čije vrijednosti nedvosmisleno određuju vrijednosti svih ostalih polja u tablici. Na primjer, polje "Broj putovnice", odnosno "Identifikacijski broj poreznog obveznika (PIN)", jedinstveno definira karakteristike svakog pojedinca (prilikom sastavljanja odgovarajućih tablica baze podataka ZA Odjele ljudskih resursa ili računovodstvo poduzeća). 
23
Ključ tablice može biti ne jedno, već nekoliko polja. U ovom slučaju, skup polja može biti mogući ključ za tablicu samo kada su zadovoljena dva vremenski neovisna uvjeta: jedinstvenost i minimalnost. Svako polje koje nije dio primarnog ključa naziva se poljem bez ključa u tablici.
Jedinstvenost ključ znači da u bilo kojem trenutku tablica baze podataka ne može sadržavati dva različita zapisa koja imaju iste vrijednosti polja ključa. Ispunjenje uvjeta jedinstvenosti je obavezno. Stanje minimalnost ključna polja znači da samo kombinacija vrijednosti odabranih polja ispunjava zahtjeve za jedinstvenost zapisa tablice baze podataka. To također znači da se nijedno od polja uključenih u ključ ne može isključiti iz njega bez narušavanja jedinstvenosti. Prilikom formiranja ključa tablice baze podataka, koja se sastoji od nekoliko polja, potrebno je voditi se sljedećim odredbama: u ključ ne biste trebali uključivati polja tablice, čije vrijednosti same po sebi jedinstveno identificiraju zapise u tablici . Na primjer, ne biste trebali kreirati ključ koji istovremeno sadrži polja "broj putovnice" i "identifikacijski broj poreznog obveznika", budući da svaki od ovih atributa može jedinstveno identificirati zapise u tablici; ne možete uključiti nejedinstveno polje u ključ, odnosno polje čije se vrijednosti mogu ponoviti u tablici. Svaka tablica mora imati barem jedan mogući ključ, koji se bira kao glavni ključ. Ako u tablici postoje polja, vrijednosti svake od kojih jedinstveno definiraju zapise, tada se ta polja mogu uzeti kao alternativni ključevi. Na primjer, ako odaberete identifikacijski broj poreznog obveznika kao primarni ključ, tada će broj putovnice biti alternativni ključ. 2.2. Normaliziranje tablica relacijske baze podataka Relacijska baza podataka je skup tablica koje su međusobno povezane. Broj tablica u jednoj datoteci ili jednoj bazi podataka ovisi o mnogim čimbenicima, od kojih su glavni: sastav korisnika baze podataka, osiguranje integriteta informacija (osobito važno u višekorisničkim informacijskim sustavima), osiguranje najmanje potrebne memorije i minimalno vrijeme obrade podataka. 24Razmatranje ovih čimbenika u dizajnu relacijskih baza podataka provodi se metodama normalizacije tablica i uspostavljanja veza među njima.
Normaliziranje tablica je način podjele jedne tablice baze podataka u nekoliko tablica koje općenito zadovoljavaju gore navedene zahtjeve. Normalizacija tablice je uzastopna promjena strukture tablice sve dok ne ispuni zahtjeve posljednjeg oblika normalizacije. Ukupno postoji šest oblika normalizacije:- prvi normalni oblik (First Normal Form - 1NF); drugi normalni oblik (Second Normal Form - 2NF); treći normalni oblik (Third Normal Form - ZNF); normalni oblik Boyes - Codd (Brice - Codd Normal Form -BCNF); četvrti normalni oblik (Četvrto Normalni oblik - 4NF); peti normalni oblik, ili normalni projekcijski oblik - veze (Fifth Normal Form - 5NF, ili PJ / NF ).
26 
Polje "Ukupne dimenzije (duljina x širina x visina), mm", podijeljeno u tri polja: "Duljina, mm", "Širina, mm", "Visina, mm". Ključno polje ove tablice može biti polje “Model stroja” ili “Br. 2.3. Uzmimo još jedan primjer. Na sl. 2.2 prikazuje ulomak lista s rezultatima testa, koji, kao u prethodnom primjeru, izvorno nije bio namijenjen za računalnu obradu. Pretpostavimo da želimo izraditi bazu podataka za automatiziranu obradu rezultata testno-ispitne sesije u skladu s 
27
sa sadržajem ispitnog i ispitnog lista. Da bismo to učinili, sadržaj obrasca pretvaramo u tablice baze podataka. Polazeći od potrebe poštivanja uvjeta funkcionalne ovisnosti između polja, potrebno je formirati najmanje dvije tablice (slika 2.3) (ključna polja u svakoj tablici su podebljana). Prva tablica sadrži rezultate položenog testa (ispita) svakog studenta iz određenog predmeta. Druga tablica sadrži konačne rezultate položenog testa (ispita) određene skupine učenika iz određenog predmeta. U prvoj tablici ključno je polje "Puno ime i prezime studenta", a u drugoj tablici - polje "Disciplina". Tablice moraju biti povezane poljima "Disciplina" I "Šifra grupe".
Prikazane strukture tablica u potpunosti zadovoljavaju zahtjeve prvog normalnog oblika, ali ih karakteriziraju sljedeći nedostaci: dodavanje novih podataka u tablice zahtijeva unos vrijednosti za sva polja; u svaki red svake tablice potrebno je unijeti ponovljene vrijednosti polja "Disciplina", "Puno ime nastavnika", "Šifra grupe". Posljedično, s takvim sastavom tablica i njihovom strukturom, postoji jasna redundantnost informacija, što će, naravno, zahtijevati dodatnu memoriju. Kako bismo izbjegli navedene nedostatke, potrebno je tablice dovesti u drugi ili treći normalni oblik. Drugi normalni oblik. Tablica je u drugom normalnom obliku ako ispunjava zahtjeve prvog normalnog oblika i sva njena polja koja nisu uključena u primarni ključ u potpunosti su funkcionalna ovisna o primarnom ključu. 28
Ako tablica ima jednostavan primarni ključ koji se sastoji od samo jednog polja, tada je automatski u drugom normalnom obliku.
Ako je primarni ključ složen, tada je tablica opcionalno u drugom normalnom obliku. Zatim se mora podijeliti u dvije ili više tablica na takav način da primarni ključ jedinstveno identificira vrijednost u bilo kojem polju. Ako tablica ima barem jedno polje koje ne ovisi o primarnom ključu, dodatni stupci moraju biti uključeni u primarni ključ. Ako nema takvih stupaca, onda morate dodati novi stupac. Na temelju ovih uvjeta, koji određuju drugi normalni oblik, mogu se izvući sljedeći zaključci o karakteristikama sastavljenih tablica (vidi sliku 2.3). U prvoj tablici nema izravne veze između ključnog polja i polja "Puno ime i prezime nastavnika", budući da prolaz ili ispit iz istog predmeta mogu polagati različiti nastavnici. U tablici postoji potpuna funkcionalna ovisnost samo između svih ostalih polja i ključnog polja "Disciplina". Slično, u drugoj tablici nema izravne veze između ključnog polja i polja "Puno ime i prezime nastavnika". Za optimizaciju baze podataka, posebno za smanjenje potrebne količine memorije zbog potrebe da se u svakom zapisu ponavljaju vrijednosti polja "Disciplina" i "Puno ime nastavnika", potrebno je promijeniti strukturu baza podataka - transformirati izvorne tablice u drugi normalni oblik. Sastav tablica modificirane strukture baze podataka prikazan je na Sl. 2.4. Konvertirana struktura baze podataka sastoji se od šest tablica, od kojih su dvije međusobno povezane (ključna polja u svakoj tablici su podebljana). Sve tablice zadovoljavaju zahtjeve drugog normalnog oblika. Peta i šesta tablica imaju duplicirane vrijednosti u poljima, ali s obzirom na to da su te vrijednosti cijeli brojevi umjesto tekstualnih podataka, ukupna količina memorije potrebna za pohranu informacija je mnogo manja nego u izvornim tablicama (vidi sliku 2.1. ). Osim toga, nova struktura baze podataka omogućit će popunjavanje tablica od strane raznih stručnjaka (odjela usluga upravljanja). Daljnja optimizacija tablica baze podataka svodi se na dovođenje u treći normalni oblik. Treći normalni oblik. Tablica je u trećem normalnom obliku ako zadovoljava definiciju drugog normalnog oblika i nijedno od njenih neključnih polja funkcionalno ne ovisi o bilo kojem drugom neključnom polju. 29
Također možete reći da je tablica u trećem normalnom obliku ako je u drugom normalnom obliku i svako polje koje nije ključno ne ovisi tranzitivno o primarnom ključu. Treći zahtjev normalnog oblika je da sva neključna polja ovise samo o primarnom ključu i da ne ovise jedno o drugom. U skladu s tim zahtjevima, kao dio tablica baze podataka (vidi sliku 2.3), prva, druga, treća i četvrta tablica pripadaju trećem normalnom obliku. Kako bismo petu i šestu tablicu doveli u treći normalni oblik, izradit ćemo novu tablicu s podacima o sastavu predmeta za koje se ispiti ili ispiti održavaju u grupama učenika. Kao ključ ćemo kreirati polje „Brojač“ koje postavlja broj zapisa u tablici, budući da svaki zapis mora biti jedinstven. trideset
Kao rezultat, dobivamo novu strukturu baze podataka, koja je prikazana na Sl. 2.5 (ključna polja u svakoj tablici su podebljana). Ova struktura sadrži sedam tablica koje zadovoljavaju zahtjeve trećeg normalnog oblika.
Boyceova normalna forma je Codd. Tablica je u normalnom Boyce-Codd obliku samo ako je bilo kakva funkcionalna ovisnost između njezinih polja svedena na potpunu funkcionalnu ovisnost o mogućem ključu. Prema ovoj definiciji, u strukturi baze podataka (vidi sliku 2.4) sve tablice zadovoljavaju zahtjeve Boyes-Coddovog normalnog oblika. Daljnju optimizaciju tablica baze podataka treba svesti na potpunu dekompoziciju tablica. Potpuna razgradnja tablice naziva se takva zbirka proizvoljnog broja njegovih projekcija, čija se veza potpuno poklapa sa sadržajem tablice. Projekcija je kopija tablice koja ne uključuje jedan ili više stupaca nove tablice. Četvrti normalni oblik.Četvrti normalni oblik je poseban slučaj petog normalnog oblika, kada potpuna dekompozicija mora biti unija dviju projekcija.
31 Vrlo je teško pronaći tablicu koja je u četvrtom normalnom obliku, ali ne zadovoljava definiciju petog normalnog oblika.
Peti normalni oblik. Tablica je u petom normalnom obliku ako i samo ako sve projekcije sadrže mogući ključ u svakoj od svojih punih deko-pozicija. Tablica koja nema nikakvu potpunu dekompoziciju također je u petom normalnom obliku. U praksi, optimizacija tablica baze podataka završava u trećem normalnom obliku. Svođenje tablica na četvrti i peti normalni oblik je, po našem mišljenju, od čisto teorijskog interesa. U praksi se ovaj problem rješava razvojem upita za kreiranje nove tablice. 2.3. Dizajniranje odnosa između tablica Proces normalizacije početnih tablica baze podataka omogućuje vam stvaranje optimalne strukture informacijskog sustava - razvoj baze podataka koja zahtijeva najmanje memorijskih resursa i, kao rezultat, pruža najkraće vrijeme pristupa informacijama. Istodobno, podjela jedne izvorne tablice na više zahtijeva ispunjenje jednog od najvažnijih uvjeta za projektiranje informacijskih sustava – osiguranje integriteta informacija tijekom rada baze podataka. U gornjem primjeru normalizacije izvornih tablica (vidi sliku 2.3), od dvije tablice konačno smo dobili sedam tablica svedenih na treći i četvrti normalni oblik. Kao što pokazuje praksa, u stvarnoj proizvodnji i poslovanju baze podataka su višekorisnički sustavi. To se odnosi i na stvaranje i održavanje podataka u zasebnim tablicama i na korištenje informacija za donošenje odluka. U navedenom primjeru, u stvarno funkcionalnom sustavu upravljanja obrazovnim procesom na sveučilištu ili visokoj školi, početno formiranje studijskih skupina provode prijemne komisije pri upisu pristupnika na temelju rezultata prijamnih ispita. Daljnje vođenje podataka o sastavu studenata u grupama na sveučilištima dodijeljeno je dekanatima, a na visokim školama - obrazovnim odjelima ili relevantnim strukturama. Sastav akademskih disciplina u skupinama određuju druge službe ili specijalisti. Podaci o nastavnom osoblju formiraju se u kadrovskim odjelima. Rezultati testnih i ispitnih sjednica nužni su pročelnicima dekanata i odjela, pa tako i za donošenje odluka o dodjeli stipendija 32 uspješna studenta ili "istupanju iz stipendije" neuspješnih studenata. Svaka promjena u bilo kojoj tablici u bazi podataka mora pronaći odgovarajuću promjenu u svim ostalim tablicama. To je bit osiguravanja integriteta baze podataka. U praksi se ovaj zadatak provodi uspostavljanjem veza između tablica baze podataka. Formulirajmo osnovna pravila za uspostavljanje odnosa između tablica. 1. Odaberite master i slave iz dvije povezane tablice. 2. U svakoj tablici odaberite ključno polje. Poziva se ključno polje glavne tablice primarni ključ. Poziva se ključno polje podređene tablice strani kljuc. 3. Vezana polja tablice moraju biti istog tipa podataka. 4. Između tablica uspostavljaju se sljedeće vrste veza: "jedan na jedan"; Jedan prema više; Mnogi-prema-više: odnos jedan-na-jedan se uspostavlja kada je određeni red glavne tablice povezan samo s jednim redom podređene tablice u bilo kojem trenutku; odnos jedan prema više uspostavlja se u slučajevima kada određeni red glavne tablice u bilo kojem trenutku
33 je povezana s više redaka podređene tablice; u ovom slučaju, bilo koji red podređene tablice povezan je samo s jednim redom glavne tablice; odnos mnogo-prema-više uspostavlja se u slučajevima kada je određeni red glavne tablice u bilo kojem trenutku povezan s nekoliko redaka podređene tablice, a istovremeno je jedan red podređene tablice povezan s nekoliko redaka glavne tablice stol. Prilikom promjene vrijednosti primarnog ključa u glavnoj tablici moguća su sljedeća ponašanja zavisne tablice. Kaskadno. Kada se mijenjaju podaci primarnog ključa u glavnoj tablici, mijenjaju se i odgovarajući podaci stranog ključa u ovisnoj tablici. Svi postojeći priključci su zadržani. Ograničiti. Ako pokušate promijeniti vrijednost primarnog ključa povezanog s recima u ovisnoj tablici, promjene se odbacuju. Dopušteno je mijenjati samo one vrijednosti primarnog ključa za koje nije uspostavljena veza s ovisnom tablicom. Uspostava (odnos). Kada se podaci primarnog ključa promijene, strani ključ se postavlja na nultu vrijednost (NULL). Izgubljene su informacije o vlasništvu retka za ovisnu tablicu. Ako promijenite nekoliko vrijednosti primarnog ključa, tada se u ovisnoj tablici formira nekoliko skupina redaka, koje su prethodno bile povezane s promijenjenim ključevima. Nakon toga je nemoguće odrediti koji je red povezan s kojim primarnim ključem. Na sl. 2.6 prikazani su dijagrami veza između tablica baze podataka prikazanih na Sl. 2.5. Kontrolna pitanja 1. Dajte definicije sljedećim elementima tablice baze podataka: polje, ćelija, zapis. 2. Što znače pojmovi "ključ", "ključno polje"? 3. Koje se polje ključa naziva primarni ključ, a koje vanjski ključ? 4. Kakav je proces normalizacije tablica baze podataka? 5. Kojih pet normalnih oblika tablica baze podataka poznajete? 6. Definirajte sljedeće vrste odnosa između tablica baze podataka: "jedan prema jedan"; Jedan prema više; Mnogi-prema-mnogima. Osnovni koncepti relacijskih baza podataka su tip podataka, domena, atribut, tuple, primarni ključ i odnos. Pokažimo značenje ovih pojmova na primjeru odnosa ZAPOSLENICI koji sadrži podatke o zaposlenicima određene organizacije:
1. Vrsta podataka
Koncept vrsta podataka u relacijskom modelu podataka u potpunosti je adekvatan konceptu tipa podataka u programskim jezicima. Tipično, moderne relacijske baze podataka omogućuju pohranjivanje znakovnih, numeričkih podataka, nizova bitova, specijaliziranih numeričkih podataka (kao što je "novac"), kao i posebnih "vremenskih" podataka (datum, vrijeme, vremenski interval). Aktivno se razvija pristup proširenju mogućnosti relacijskih sustava s apstraktnim tipovima podataka (na primjer, sustavi obitelji Ingres / Postgres imaju takve mogućnosti). U našem primjeru imamo posla s tri vrste podataka: nizovima znakova, cijelim brojevima i novcem.
2. Domena
Koncept domena specifičnije za baze podataka, iako ima neke analogije s podtipovima u nekim programskim jezicima. U svom najopćenitijem obliku, domena je definirana specificiranjem neke osnovne vrste podataka kojoj pripadaju elementi domene i proizvoljnim logičkim izrazom primijenjenim na element tipa podataka. Ako ovaj Booleov izraz ima vrijednost true, tada je stavka podataka stavka domene. Najispravnije intuitivno tumačenje pojma domene je shvaćanje domene kao dopuštenog potencijalnog skupa vrijednosti dane vrste. Na primjer, "Imena" domene u našem primjeru definirana je na osnovnom tipu znakovnih nizova, ali njegove vrijednosti mogu uključivati samo one nizove koji mogu predstavljati ime (konkretno, takvi nizovi ne mogu započeti mekim znakom). Treba napomenuti i semantičko opterećenje koncepta domene: podaci se smatraju usporedivim samo ako pripadaju istoj domeni. U našem primjeru vrijednosti za domene "Gap Numbers" i "Group Numbers" su cjelobrojnog tipa, ali nisu usporedive. Imajte na umu da većina relacijskih DBMS-ova ne koristi koncept domene, iako ga Oracle V.7 već podržava.
3. Shema odnosa, shema baze podataka
Shema odnosa je imenovani skup parova (ime atributa, naziv domene (ili tip ako pojam domene nije podržan)). Stupanj ili "aritet" sheme odnosa je kardinalnost ovog skupa. Stupanj odnosa ZAPOSLENICI je četiri, odnosno 4-aran. Ako su svi atributi jednog odnosa definirani na različitim domenama, ima smisla koristiti nazive odgovarajućih domena za imenovanje atributa (naravno, imajući na umu da je ovo samo prikladna metoda imenovanja i da ne eliminira razliku između koncepti domene i atributa). DB shema (u strukturnom smislu) je skup imenovanih shema odnosa.
4. Tuple, relacija
Korta koja odgovara danoj shemi odnosa je skup parova (ime atributa, vrijednost) koji sadrži jedno pojavljivanje imena svakog atributa koji pripada shemi odnosa. "Vrijednost" je valjana vrijednost domene za dati atribut (ili tip podataka ako pojam domene nije podržan). Dakle, stupanj ili "arnost" tuple, t.j. broj elemenata u njemu podudara se s "aritetom" odgovarajuće sheme odnosa. Jednostavnim riječima, tuple je zbirka imenovanih vrijednosti danog tipa.
Odnos je skup torki koje odgovaraju istoj shemi odnosa. Ponekad, da ne bi došlo do zabune, kažu "relacija-shema" i "relacija-instanca", ponekad se shema relacije naziva naslovom relacije, a relacija kao skup torki naziva se tijelom odnos. Zapravo, koncept sheme odnosa najbliži je konceptu strukturiranog tipa podataka u programskim jezicima. Bilo bi sasvim logično dopustiti zasebno definiranje sheme odnosa, a zatim jednog ili više odnosa s tom shemom.
Uobičajeni svakodnevni prikaz odnosa je tablica čiji je naslov dijagram odnosa, a redovi su torke odnosa instance; u ovom slučaju, nazivi atributa imenuju stupce u toj tablici. Stoga ponekad kažu "stupac tablice", što znači "atribut odnosa". Relacijska baza podataka je skup relacija čija su imena ista kao i imena shema odnosa u shemi baze podataka.
Temeljna svojstva odnosa
1.Nema duplikata tuple
Svojstvo da odnos ne sadrži duplicirane torke proizlazi iz definicije odnosa kao skupa torki. U klasičnoj teoriji skupova, po definiciji, svaki se skup sastoji od različitih elemenata. Ovo svojstvo podrazumijeva da svaki odnos ima takozvani primarni ključ - skup atributa čije vrijednosti na jedinstven način određuju torbu odnosa. Za svaki odnos, barem cijeli skup njegovih atributa ima ovo svojstvo. Međutim, u formalnoj definiciji primarnog ključa, potrebno je osigurati da je "minimalni"; skup atributa primarnog ključa ne bi trebao uključivati takve atribute koji se mogu odbaciti bez štete po glavno svojstvo - da nedvosmisleno identificiraju torku. Koncept glavni ključ iznimno je važno u vezi s konceptom cjelovitosti baze podataka.
2.Nedostatak redoslijeda torki
Svojstvo da torke relacije nisu uređene također je posljedica definiranja relacije instance kao skupa torki. Nepostojanje zahtjeva za održavanjem reda na skupu torki relacije daje DBMS-u dodatnu fleksibilnost prilikom pohranjivanja baza podataka u vanjsku memoriju i prilikom izvršavanja upita bazi podataka. To nije u suprotnosti s činjenicom da kada formulirate upit bazi podataka, na primjer, u SQL jeziku, možete zahtijevati sortiranje rezultirajuće tablice u skladu s vrijednostima nekih stupaca. Takav rezultat, općenito govoreći, nije relacija, već neki uređeni popis torki.
3.Nedostatak redoslijeda atributa
Atributi odnosa nisu poredani jer, po definiciji, shema odnosa ima mnogo parova (ime atributa, naziv domene). Naziv atributa uvijek se koristi za upućivanje na vrijednost atributa u torci relacije. Ovo svojstvo teoretski omogućuje, na primjer, modificiranje shema postojećih odnosa ne samo dodavanjem novih atributa, već i uklanjanjem postojećih atributa. Međutim, u većini postojećih sustava takva mogućnost nije dopuštena, i iako poredak skupa atributa odnosa nije eksplicitno potreban, često se njihov redoslijed u linearnom obliku definiranja sheme odnosa koristi kao implicitni poredak atributima.
4.Atomičnost vrijednosti atributa.
Sve vrijednosti atributa su atomske. To proizlazi iz definicije domene kao potencijalnog skupa vrijednosti jednostavnog tipa podataka, tj. vrijednosti domene ne mogu sadržavati skupove vrijednosti (relacije). Uobičajeno je reći da su u relacijskim bazama podataka dopušteni samo normalizirani odnosi ili odnosi predstavljeni u prvom normalnom obliku.
Relacijski model podataka. Prema Dateu, relacijski model se sastoji od tri dijela koji opisuju različite aspekte relacijskog pristupa: strukturni dio, manipulacijski dio i integralni dio. U strukturnom dijelu modela utvrđeno je da je jedina struktura podataka koja se koristi u relacijskim bazama podataka normalizirana n-arna relacija. Manipulacijski dio modela potvrđuje dva temeljna mehanizma za manipulaciju relacijskim bazama podataka - relacijsku algebru i relacijski račun. Prvi mehanizam temelji se uglavnom na klasičnoj teoriji skupova (s nekim poboljšanjima), a drugi - na klasičnom logičkom aparatu predikatskog računa prvog reda.
Integritet entiteta i poveznica. Konačno, u integralnom dijelu relacijskog modela podataka, fiksirana su dva osnovna zahtjeva integriteta koji moraju biti podržani u bilo kojem relacijskom DBMS-u. Prvi uvjet se zove zahtjev integriteta entiteta... Objekt ili entitet stvarnog svijeta u relacijskim bazama podataka odgovara nizu relacija. Konkretno, zahtjev je da se bilo koja torka bilo koje relacije razlikuje od bilo koje druge torke ove relacije, tj. drugim riječima, svaki odnos mora imati primarni ključ. Kao što smo vidjeli u prethodnom odjeljku, ovaj je zahtjev automatski zadovoljen ako osnovna svojstva odnosa nisu narušena u sustavu. Drugi zahtjev se zove Zahtjev za integritet prema referenci i nešto je složeniji. Očito, ako su odnosi normalizirani, složeni entiteti stvarnog svijeta su predstavljeni u relacijskoj bazi podataka u obliku nekoliko torki od nekoliko relacija.
Relacijske operacije i numeriranje.
Nakon što je predložio relacijski model podataka, E.F. Codd je također stvorio alat za prikladan rad s odnosima - relacijsku algebru. Svaka operacija ove algebre koristi jednu ili više tablica (relacija) kao svoje operande i kao rezultat proizvodi novu tablicu, tj. omogućuje "rezanje" ili "lijepljenje" stolova (slika 3.3). 
Riža. 3.3. Neke operacije relacijske algebre
Stvoreni su jezici za manipulaciju podacima koji omogućuju implementaciju svih operacija relacijske algebre i gotovo svake njihove kombinacije. Među njima su najčešći SQL (Structured Query Language) i QBE (Quere-By-Example) [,]. Oba su jezika vrlo visoke razine, uz pomoć kojih korisnik specificira koje podatke treba dobiti bez navođenja postupka za njihovo dobivanje. S jednim upitom na bilo kojem od ovih jezika možete spojiti više tablica u privremenu tablicu i iz nje izrezati potrebne retke i stupce (odabir i projekcija).
Podrška za jezik baze podataka
Za rad s bazom podataka koriste se posebni jezici, koji se općenito nazivaju jezicima baze podataka.
U prvim bazama podataka postojala su 2 jezika:
1. Jezik definicije za SDL shemu baze podataka.
2. jezik za upravljanje podacima DML.
Prvi je služio za definiranje logičke strukture baze podataka, a drugi je sadržavao skup operatora koji su omogućavali manipulaciju podacima, odnosno unos u bazu i brisanje iste. U modernom DBMS-u obično je podržan jedan jezik koji sadrži sve potrebne alate za rad s bazom podataka. Ovaj jezik omogućuje i stvaranje baze podataka i pružanje baze podataka korisniku.
Daleko najčešći jezik je
S strukturiran
L jezika
Ovaj jezik podržava i stvara shemu baze podataka i omogućuje manipulaciju ovim podacima. Sadrži sve alate koji su vam potrebni da osigurate integritet vaše baze podataka. Ova ograničenja integriteta sadržana su u posebnim imenicima koji vam omogućuju kontrolu integriteta baze podataka na razini jezika. Posebni operatori jezika SQL definiraju takozvane poglede baze podataka. Pogled - ϶ᴛᴏ upiti koji su pohranjeni u bazi podataka. Za korisnika je pogled ϶ᴛᴏ tablica uz pomoć koje možete ograničiti ili proširiti vidljivost baze podataka za određenog korisnika podataka. Jezik SQL sadrži tako posebne operande koji daju autorizaciju pristupa objektima baze podataka. Budući da različiti korisnici imaju različite dozvole za rad s podacima, te su dozvole opisane u posebnim tablicama – katalozima koji su podržani na razini jezika.
Osnovni koncepti relacijskih baza podataka su: tip podataka, domena, atribut, tuple, primarni ključ, odnos.
Pod tipom podataka u relacijskom modelu obično se podrazumijeva ista vrsta podataka u programskim jezicima, odnosno podaci mogu biti znakovni, numerički, bitni nizovi, posebni numerički podaci (novac), kao i posebni vremenski podaci (vrijeme, datum, vremenski interval).
U svom najopćenitijem obliku, domena se određuje specificiranjem određene osnovne vrste podataka kojoj pripadaju elementi ove domene, pojam domene je njezino shvaćanje kao dopuštene množinske vrijednosti baze podataka. Domena ima semantičko opterećenje. Podaci se smatraju usporedivim samo ako pripadaju istoj domeni.
Uobičajeno je da se tuple razumije kao skup parova elemenata baze podataka koji sadrže jedno pojavljivanje svakog sjemena atributa u shemi odnosa.
Shema odnosa - ϶ᴛᴏ imenovani skup parova elemenata. I u
tuple = atribut name͵ vrijednost, to jest, tuple je zbirka imenovanih vrijednosti danog tipa.
Relacija - ϶ᴛᴏ skup torki koji odgovaraju nekoj jednoj shemi, odnosno relacijska baza podataka - ϶ᴛᴏ skup relacija čija se imena podudaraju s imenima shema odnosa u strukturi baze podataka.
Relacijske baze podataka danas su najraširenije, iako uz općepriznate prednosti imaju i niz nedostataka. Prednosti relacijskog pristupa uključuju:
Prisutnost malog skupa apstrakcija koje čine relativno lakim modeliranje većine uobičajenih predmetnih područja i omogućuju precizne formalne definicije, a pritom ostaju intuitivne;
Prisutnost jednostavnog i istovremeno moćnog matematičkog aparata, koji se uglavnom temelji na teoriji skupova i matematičkoj logici i pruža teorijsku osnovu za relacijski pristup organiziranju baza podataka;
Mogućnost nenavigacijske manipulacije podacima bez potrebe poznavanja specifične fizičke organizacije baza podataka u vanjskoj memoriji.
Relacijskim sustavima trebalo je dosta vremena da postanu široko rasprostranjeni. Dok su glavni teoretski rezultati na ovom području dobiveni još 70-ih godina, a istodobno su se pojavili i prvi prototipovi relacijskih DBMS-a, dugo se vremena smatralo nemogućim postići učinkovitu implementaciju takvih sustava. Međutim, gore navedene prednosti i postupno gomilanje metoda i algoritama za organiziranje i upravljanje relacijskim bazama podataka doveli su do činjenice da su sredinom 80-ih relacijski sustavi praktički istisnuli rane DBMS-ove sa svjetskog tržišta.
Trenutačno, glavni predmet kritike relacijskih DBMS-a nije njihova neučinkovitost, već neka ograničenja koja su inherentna ovim sustavima (izravna posljedica jednostavnosti) kada se koriste u tzv. netradicionalnim područjima (najčešći primjeri su sustavi za automatizaciju dizajna). ), koji zahtijevaju izuzetno složene strukture podataka. Još jedan često uočeni nedostatak relacijskih baza podataka je nemogućnost da se na odgovarajući način odražava semantika domene. Drugim riječima, mogućnosti predstavljanja znanja o semantičkim specifičnostima domene u relacijskim sustavima vrlo su ograničene. Suvremena istraživanja u području postrelacijskih sustava uglavnom su posvećena preciznom otklanjanju ovih nedostataka.
Osnovni koncepti relacijskih baza podataka su tip podataka, domena, atribut, tuple, primarni ključ i odnos.
Koncept vrsta podataka u relacijskom modelu podataka u potpunosti je adekvatan konceptu tipa podataka u programskim jezicima. Tipično, moderne relacijske baze podataka omogućuju pohranjivanje znakovnih, numeričkih podataka, nizova bitova, specijaliziranih numeričkih podataka (kao što je "novac"), kao i posebnih "vremenskih" podataka (datum, vrijeme, vremenski interval). Aktivno se razvija pristup proširenju mogućnosti relacijskih sustava s apstraktnim tipovima podataka (na primjer, sustavi obitelji Ingres / Postgres imaju takve mogućnosti).
Strukture podataka relacijskog modela. Relacijski model podataka organizira i predstavlja podatke u obliku tablica ili relacija. Relacijski Je pojam koji dolazi iz matematike i označava jednostavnu dvodimenzionalnu tablicu. Relacijski pristup izgradnji baza podataka koristi terminologiju teorije odnosa. Najjednostavnija dvodimenzionalna tablica definirana je kao stav.
stol je glavni tip strukture podataka (objekt) relacijskog modela. Strukturu tablice određuje populacija stupaca. Svaki red tablice sadrži jednu vrijednost u odgovarajućoj stupac. U tablici ne mogu postojati dva identična reda. Ukupan broj linija nije ograničen.
Stupac odgovara nekom podatku - atribut, što je najjednostavnija struktura podataka. Više stavki, grupa ili ponavljajuća grupa ne mogu se definirati u tablici kao u mrežnim i hijerarhijskim modelima o kojima smo gore raspravljali. Svaki stupac tablice mora imati Ime odgovarajući element podataka (atribut).
Poziva se stupac tablice s vrijednostima odgovarajućeg atributa domena, i nizovi s vrijednostima različitih atributa - tuple.
Relacijska tablica-relacija. Na sl. 9 je ilustracija relacijskog odnosa tablice R... Formalna definicija odnos R (relacijska tablica) se oslanja na njegovu ideju domene D ja, (stupci) i torke K j (crte). Relacija R definirana na skupovima domena (D i) je podskup Kartezijanski (izravni) proizvod domena D 1 * D 2 *… .. * D n
Tablica-odnos(vidi sliku 1) sadrži stupce s nazivima elemenata podataka - atributa (A 1, A 2, ...). Vrijednosti d atributa nalaze se u sadržajnom dijelu tablice i oblikuju retke i stupce. Mnoge vrijednosti atributa u jednom stupcu čine jednu domena D i... Mnoge vrijednosti atributa u jednom retku čine jednu povorka Za j. Stav R je formiran skupom uređenih torke.
R = (Kj), J = 1- m Kj = (d 1j, d 2 j,… d nj),
gdje je n broj domena relacije; definira dimenzija odnosa;
j je broj torke;
m je ukupan broj torki u odnosu tzv subroj odnos.
Slika 9. Ilustracija relacijske tablice i odnosa
Domena. U svom najopćenitijem obliku, domena je definirana specificiranjem neke osnovne vrste podataka kojoj pripadaju elementi domene i proizvoljnim logičkim izrazom koji se primjenjuje na element tipa podataka. Ako ovaj Booleov izraz ima vrijednost true, tada je stavka podataka stavka domene.
Najispravnije intuitivno tumačenje pojma domene je shvaćanje domene kao dopuštenog potencijalnog skupa vrijednosti dane vrste. Na primjer, "Imena" domene u našem primjeru definirana je na osnovnom tipu znakovnih nizova, ali njegove vrijednosti mogu uključivati samo one nizove koji mogu predstavljati ime (konkretno, takvi nizovi ne mogu započeti mekim znakom).
Treba napomenuti i semantičko opterećenje koncepta domene: podaci se smatraju usporedivim samo ako pripadaju istoj domeni. U našem primjeru vrijednosti za domene "Gap Numbers" i "Group Numbers" su cjelobrojnog tipa, ali nisu usporedive. Imajte na umu da većina relacijskih DBMS-ova ne koristi koncept domene, iako ga Google V.7 već podržava.
Shema odnosa, shema baze podataka. Shema odnosa je imenovani skup parova (ime atributa, naziv domene (ili tip ako pojam domene nije podržan)). Stupanj ili "aritet" sheme odnosa je kardinalnost ovog skupa. Stupanj omjera PRIMJERA je ŠEST, odnosno 6-aran. Ako su svi atributi jednog odnosa definirani na različitim domenama, ima smisla koristiti nazive odgovarajućih domena za imenovanje atributa (ne zaboravljajući, naravno, da je ovo samo prikladna metoda imenovanja i da ne eliminira razliku između koncepti domene i atributa). DB shema (u strukturnom smislu) je skup imenovanih shema odnosa.
Popis koji daje nazive relacijskih tablica, navodeći njihove atribute (podvučene ključeve) i definicije stranih ključeva naziva se shema relacijske baze podataka. To je preliminarni sažetak stvaranja faze životnog ciklusa relacijske baze podataka. Primjer:
RADNIK [ RADNIK-ID, IME, SATNA STOPA, VRSTA VJEŠTINE, SVPV-ID]
Strani ključevi: SKILL-TYPE referencira SKILL
SVPV-ID referenciran RADNIK
ZADATAK [ RADNIK-ID, BLDG-ID, DATUM POČETKA, BROJ DANA]
Strani ključevi: WORKER-ID referenciran WORKER
BLDG-ID na koji upućuje BVILDING
BVILDING [ BLDG-ID, ADRESA, VRSTA, QLTY-LEVEL, STATVS]
VJEŠTINA [ VJEŠTINA- VRSTA, STOPA BONUSA, SATI PO TJEDNU]
Tuple, odnos. Korta koja odgovara danoj shemi odnosa je skup parova (ime atributa, vrijednost koja sadrži jedno pojavljivanje svakog naziva atributa koji pripada shemi odnosa. "Vrijednost" je valjana vrijednost domene za dati atribut (ili tip podataka ako pojam domene nije podržan). Dakle, stupanj ili "arnost" torke, odnosno broj elemenata u njoj, podudara se s "aritetom" odgovarajuće sheme odnosa.
Stav Je skup torki koji odgovaraju istoj shemi odnosa. Ponekad, da ne bi bilo zabune, kažu "relacija sheme" i "relacija instance", ponekad se shema relacije naziva naslovom relacije, a relacija, kao skup torki, naziva se tijelom relacije. Zapravo, koncept sheme odnosa najbliži je konceptu strukturiranog tipa podataka u programskim jezicima. Bilo bi sasvim logično dopustiti zasebno definiranje sheme odnosa, a zatim jednog ili više odnosa s tom shemom.
Međutim, to nije slučaj u relacijskim bazama podataka. Naziv sheme odnosa u takvim bazama podataka uvijek je isti kao i naziv odgovarajućeg odnosa instance. U klasičnim relacijskim bazama podataka, nakon definiranja sheme baze podataka, mijenjaju se samo odnosi instanci. U njima se mogu pojaviti novi torovi, a postojeći se mogu brisati ili mijenjati. Međutim, mnoge implementacije također dopuštaju promjenu sheme baze podataka: definiranje novih i modificiranje postojećih shema odnosa. Ovo se obično zove evolucija sheme baze podataka.
Uobičajeni svakodnevni prikaz odnosa je tablica čiji je naslov dijagram odnosa, a redovi su torke odnosa instance; u ovom slučaju, nazivi atributa imenuju stupce u toj tablici. Stoga ponekad kažu "stupac tablice", što znači "atribut odnosa". Kada prijeđemo na praktična pitanja organizacije relacijskih baza podataka i alata za upravljanje, koristit ćemo se ovom uobičajenom terminologijom. Ovu terminologiju koristi većina komercijalnih relacijskih DBMS-a.
Relacijska baza podataka je skup relacija čija su imena ista kao i imena shema odnosa u shemi baze podataka.
Kao što vidite, osnovni strukturni koncepti relacijskog modela podataka (osim koncepta domene) imaju vrlo jednostavnu intuitivnu interpretaciju, iako su u teoriji relacijskih baza podataka svi definirani apsolutno formalno i točno.
Ključ tablice odnosa. Tuple se ne smiju ponavljati unutra tablice odnosa i, sukladno tome, moraju imati jedinstveni identifikator - glavni ključ. Jedan ili više atributa čije vrijednosti jedinstveno identificiraju red tablice su ključ tablice.
Primarni ključ se zove jednostavan , kada se sastoji od jednog atributa, ili kompozit, kada se sastoji od više atributa. Osim primarnog ključa, relacija također može sadržavati sekundarni ključevi.
Sekundarni ključ – to je ključ čije se vrijednosti mogu ponoviti u različitim nizovima tuple. Mogu se koristiti za traženje grupe redaka s istom vrijednošću sekundarnog ključa.
Vanjski ključ - to je skup atributa iz jedne tablice koji je ključ druge (ili iste) tablice. Strani ključevi pružaju važne odnose između tablica. Koriste se za povezivanje podataka iz jedne tablice s podacima u drugoj tablici. Atributi stranog ključa ne moraju imati ista imena kao ključni atributi kojima odgovaraju.
Slične informacije.
RELACIJSKA BAZA PODATAKA I NJEGOVE ZNAČAJKE. VRSTE RELACIJA IZMEĐU RELACIJSKIH TABLICA
Relacijska baza podataka je zbirka međusobno povezanih tablica, od kojih svaka sadrži informacije o objektima određene vrste. Redak tablice sadrži podatke o jednom objektu (na primjer, proizvod, kupac), a stupci tablice opisuju različite karakteristike tih objekata – atribute (na primjer, naziv, šifra proizvoda, informacije o kupcu). Zapisi, odnosno redovi tablice, imaju istu strukturu – sastoje se od polja u kojima se pohranjuju atributi objekta. Svako polje, odnosno stupac, opisuje samo jednu karakteristiku objekta i ima strogo definiran tip podataka. Svi zapisi imaju ista polja, samo što prikazuju različita informacijska svojstva objekta.
U relacijskoj bazi podataka svaka tablica mora imati primarni ključ — polje ili kombinaciju polja koja jedinstveno identificiraju svaki redak u tablici. Ako se ključ sastoji od više polja, naziva se složeni ključ. Ključ mora biti jedinstven i jedinstveno identificirati unos. Vrijednost ključa može se koristiti za pronalaženje jednog zapisa. Ključevi se također koriste za organiziranje informacija u bazi podataka.
Tablice relacijske baze podataka moraju zadovoljiti zahtjeve za normalizaciju odnosa. Normalizacija odnosa je formalni aparat ograničenja za formiranje tablica, koji eliminira dupliciranje, osigurava dosljednost onih pohranjenih u bazi podataka i smanjuje troškove rada za održavanje baze podataka.
Neka se izradi tablica Student koja sadrži sljedeća polja: broj grupe, puno ime, broj studenta studenta, datum rođenja, miješanje specijalnosti, naziv fakulteta. Takva organizacija pohrane informacija imat će niz nedostataka:
- dupliciranje informacija (naziv specijalnosti i fakulteta se ponavlja za svakog studenta), stoga će se volumen baze podataka povećati;
- postupak ažuriranja podataka u tablici otežan je zbog potrebe uređivanja svake tablične zapise.
Normalizacija tablice namijenjena je rješavanju ovih nedostataka. Tamo je tri normalna oblika odnosa.
Prvi normalni oblik. Relacijska tablica se reducira na prvi normalni oblik ako i samo ako niti jedan njezin redak ne sadrži više od jedne vrijednosti u bilo kojem od svojih polja i nijedno ključno polje nije prazno. Dakle, ako se iz tabele učenika traži podatak o imenu studenta, tada se polje punog imena treba podijeliti na dijelove Prezime, Ime, Patronim.
Drugi normalni oblik... Relacijska tablica je specificirana u drugom normalnom obliku ako zadovoljava zahtjeve prvog normalnog oblika i sva njena polja koja nisu uključena u primarni ključ su u potpunosti funkcionalno povezana s primarnim ključem. Za dovođenje tablice u drugi normalni oblik potrebno je odrediti funkcionalnu ovisnost polja. Funkcionalna ovisnost polja je ovisnost, kada u instanci informacijskog objekta samo jedna vrijednost opisnog atributa odgovara određenoj vrijednosti ključnog atributa.
Treći normalni oblik. Tablica je u trećem normalnom obliku ako zadovoljava zahtjeve drugog normalnog oblika, niti jedno njeno neključno polje nije funkcionalno ovisno o bilo kojem drugom neključnom polju. Na primjer, u tablici Student (broj grupe, puno ime, broj razredne knjige, datum rođenja, starosta) tri polja - broj razrednika, broj grupe, starosta su u prijelaznom odnosu. Broj grupe ovisi o broju razredne knjige, a ravnatelj o broju grupe. Da bi se eliminirala tranzitivna ovisnost, potrebno je dio polja Studentske tablice prenijeti u drugu tablicu Grupa. Tablice će biti sljedećeg oblika: Učenik (broj grupe, puno ime, broj razredne knjige, datum rođenja), grupa (broj grupe, voditelj).
Sljedeće su operacije moguće na relacijskim tablicama:
- Povezivanje tablica s istom strukturom. Rezultat je zajednička tablica: prvo prva, zatim druga (konkatenacija).
- Sjecište tablica s istom strukturom. Rezultat - odabiru se oni zapisi koji se nalaze u obje tablice.
- Oduzimanje tablica s istom strukturom. Rezultat - odabiru se oni zapisi koji nisu u oduzetom.
- Uzorak (horizontalni podskup). Rezultat – odabiru se zapisi koji ispunjavaju određene uvjete.
- Projekcija (okomiti podskup). Rezultat je relacija koja sadrži neka od polja iz izvornih tablica.
- Kartezijanski proizvod dviju tablica Zapisi rezultirajuće tablice dobivaju se kombiniranjem svakog zapisa prve tablice sa svakim zapisom druge tablice.
Relacijske tablice mogu biti povezane jedna s drugom, stoga se podaci mogu dohvatiti iz više tablica u isto vrijeme. Tablice su međusobno povezane kako bi se u konačnici smanjila veličina baze podataka. Odnos svakog para tablica je osiguran ako imaju iste stupce.
Postoje sljedeće vrste informativnih poveznica:
- jedan na jedan;
- jedan-prema-više;
- mnogo-prema-mnogima.
Komunikacija jedan na jedan pretpostavlja da jedan atribut prve tablice odgovara samo jednom atributu druge tablice, i obrnuto.
Odnos jedan prema više pretpostavlja da jedan atribut u prvoj tablici odgovara nekoliko atributa u drugoj tablici.
Odnos mnogo-prema-mnogima pretpostavlja da jedan atribut prve tablice odgovara nekoliko atributa druge tablice, i obrnuto.
