- definiranje tipova podataka i modela
- hijerarhijski i mrežni modeli
- relacijski model.
U jeziku visoka razina Podržani su dosta napredni tipovi podataka, uključujući jednostavne, strukturirane, referentne i apstraktne (objekte). Jednostavne vrste osnovni su u odnosu na računalo i razlikuju se kao cijeli, realni, logički, doslovni itd. Tip podataka je skup strukture podataka, operacija nametnutih podacima i ograničenja cjelovitosti, odnosno aktivnosti koje osiguravaju ispravan rad operacije s ovom vrstom. Strukturni tip dizajniran da bude konstruiran iz konačnog skupa osnovne vrste složene strukture podataka. Izdvajamo tri glavne strukturni tip: zapis (struktura), niz, datoteka, rekurzivna struktura. niz- zbirka podataka iste vrste. Operacije niza: kreiranje, postavljanje početnih vrijednosti elemenata niza, odabir elemenata prema vrijednosti indeksa ( serijski broj) i selektivno ažuriranje elemenata. Ograničenja integriteta su da su svi elementi istog tipa i da je indeks cijeli broj. Struktura(vrsta zapisa) – skup elemenata drugačiji tip. Na primjer, struktura - zaposlenik uključuje elemente Broj osoblja, puno ime, datum rođenja. Struktura se ne koristi u čisti oblik, ali za konstruiranje složenijih tipova, posebice datoteka. Datoteka je zbirka zapisa iste strukture (niz struktura). Datoteka je pohranjena na tvrdom disku i dizajnirana je za pohranu podataka. Funkcije datoteke: kreiranje, postavljanje pokazivača na početak datoteke, pisanje na kraj datoteke novi rekord, čitati informacije pomoću pokazivača i dobiti pokazivač na kraj datoteke. rekurzivnog tipa– formira se superpozicija tipova podataka kako bi se dobile složenije strukture, kao što su stabla, podržana pokazivačima.
Vrsta reference Pokazivač je memorijska adresa. svi prostor na disku podijeljen na stranice (2, 4, 8, itd. kilobajta), a memorijska adresa je broj stranice + relativni broj bajta unutar stranice. Apstraktni tip(objekt) je interpretirani strukturirani tip s funkcijama definiranim na svojim članovima. Time se definiraju nazivi, tipovi elemenata, funkcije (metode), kao i pravila (ograničenja integriteta) za primjenu ovih funkcija na opisane elemente. Za održavanje u vanjskom pohrana na disku Složenije podatkovne strukture na razini DBMS-a podržane su modelima podataka, uključujući hijerarhijske, mrežne i relacijske. Model podataka- ovo je skup struktura podataka i pravila za njihovo generiranje, operacije na njima i ograničenja cjelovitosti kao popis mjera usmjerenih na održavanje baze podataka ažurnom. Integritet je točnost, ispravnost podataka u bazi podataka u bilo kojem trenutku. Integritet ograničenja - skup mjera usmjerenih na održavanje integriteta baze i ispravnosti odabira informacija.
Hijerarhijski i mrežni model podataka.
U prvim fazama uvođenja baze podataka (50-80 godina), naširoko su korišteni DBMS prve generacije na ES računalima - hijerarhijski i mrežni DBMS.
Hijerarhijski model organizira strukturu u obliku uređenog stabla, vrhovi (čvorovi) odgovaraju entitetima i nazivaju se vrstama zapisa. Tip zapisa može se sastojati od nekoliko elemenata, a luk koji povezuje tipove naziva se "izvor-dijete" i odgovara tipu "jedan-prema-više" (jedna instanca izvornog zapisa odgovara nuli, jednom ili više podređenih zapisa ). Svakom se čvoru pristupa duž hijerarhijske staze, koja je niz vrsta zapisa iz korijena stabla. Gornji vrh je korijen, zadnji je list, mnogo drveća je šuma. Proširenje vrste zapisa je tablica, a proširenje odnosa je skup spojeva između redaka tablice. Svaki red tablice je instanca vrste zapisa. Ograničenje cjelovitosti je da vrh uvijek ima samo jedan luk. Operacije: uključivanje podataka (instanca generiranog zapisa ne može postojati u nedostatku instance izvornika), koja se provodi duž hijerarhijske staze (ključevi zapisa su navedeni); brisanje podataka (prilikom brisanja instance izvornog zapisa automatski se brišu sve instance generiranih budući da su instance zapisa implementirane pomoću pokazivača); podaci se dohvaćaju duž hijerarhijske staze navođenjem ključeva zapisa; ažuriranje podataka - promjena vrijednosti se vrši samo na dohvaćenim zapisima. Primjerak zapisa uvijek ima ćeliju s pokazivačem na brata i sina. Dakle, veze u hijerarhijski model na temelju pokazivača. U cilju implementacije konceptualnog modela predmetno područje potrebno je unijeti 6 hijerarhijskih struktura: materijal - dio - isporuka, skladište - dio - isporuka, grad - dobavljač - isporuka, materijal - dio - izdavanje, skladište - dio - izdavanje, kupac - izdavanje.
Prednost hijerarhijskog modela je jednostavnost i intuitivna percepcija informacija. Trenutno tražilice(preko relacijskih baza podataka) temelje se na konstrukciji navigacijskog hijerarhijskog sučelja. Nedostatak ovog modela je umjetan pristup sa redundancijom u implementaciji odnosa više-prema-više i proceduralna priroda operacija manipulacije podacima.
Na primjer, zamislimo implementaciju na modelu hijerarhijske baze podataka "skladište dijelova".
Za implementaciju baze "skladišta dijelova" na hijerarhijskom DBMS-u potrebno je formirati najmanje četiri hijerarhijske strukture (šume). Budući da su odnosi "dobavljač-detalji", "kupac-detalji" više-prema-više, redundantnost je potrebna na razini modela baze podataka. Odnos više-prema-više oslobađaju 2 hijerarhije.
mrežni model.
Ovo je usmjereni graf, u čijim čvorovima se nalaze tipovi zapisa, graf je proizvoljnog oblika, au vrh može ući nekoliko lukova. Ideju mrežnog modela predložila je udruga KODASIL. Karakteristike modela KODASIL:
- element podataka – osnovna imenovana jedinica
- agregat - zbirka podataka: niz, struktura
- zapis - imenovana zbirka elemenata podataka i/ili agregata
- skup - imenovana zbirka zapisa koji tvore dvorazinsku hijerarhijsku strukturu "izvorno-generirano". Svaki tip skupa predstavlja odnos između dva tipa zapisa. Svaka instanca skupa sadrži jednu instancu unosa "vlasnika" i nula, jednu ili više instanci "člana skupa".
Mreža je skup hijerarhija.
Ograničenje cjelovitosti je sljedeće: u danoj instanci skupa, instanca "člana skupa" ne može imati više od jedne instance unosa "vlasnika". Dakle, mreža je regrutirana skupom hijerarhija jedan prema više. Operacije: ekstrakt - možete ekstrahirati zapis po ključu, iz ekstrahiranog zapisa možete ići do podređenih; uključiti – možete u prethodno najavljenom kompletu, a možete i u tzv. singularni skup koji još nema vlasnika; prebaciti - s jednog skupa na drugi; brisanje - ne briše se zapis, već poveznice; modificirati - promijeniti vrijednost argumenata u odabranom unosu. Prednosti - jednostavnost implementacije odnosa više-prema-više.
Mrežni DBMS – IDMS –> NETWORK i SETOR.
Mrežni modeli su dobri za implementaciju tehničke komunikacije(opis električne mreže, toplinske mreže) i koriste se u inženjerski proračuni. Trenutno se provodi ili kao vlastiti razvoj, ili na OO DBMS.
Primjer mrežnog modela baze "skladište dijelova".
Tako se u bazi podataka pohranjuju instance tipova zapisa "grad", "dobavljač", "isporuka", "detalj" itd., koje su unutar određenih instanci skupova povezane relacijama jedan prema više. Na primjer, dio 1 u tipu skupa "dio - isporuka" je vlasnik instanci isporuke 2 i isporuke 6, a dio 2 u ovom tipu skupa je vlasnik isporuke 1, 2, 7. Dio 1 i 2 su u različitim vezama, odnosno u različitim postavljenim instancama.
Rani tip DBMS-a je pseudo-relacijski. Postali su rašireni na osobnim računalima, to su sustavi grupe dBase. To uključuje Clipper, FoxPro, FoxBase. U tim je sustavima svaka tablica (vrsta zapisa) pohranjena u zasebna datoteka s ekstenzijom dbf, npr. zasebno datoteku "Grad", datoteku "Dobavljač" itd. Veze između datoteka održavane su na programsku razinu V klijentska aplikacija. Indeksi su stvoreni za svaku datoteku kako bi se osiguralo brz pristup arhivirati zapise po ključu. Zatim ćemo prijeći na relacijski model A koji održava referentni integritet između entiteta.
Relacijski model podataka.
Karakteristike modela.
Koncept relacijskog modela predložio je Edward Codd, predložio je ulaganje u osnovu algebre odnosa. Relacijski model temelji se na konceptu skupovno-teorijskih relacija - ovo je podskup Kartezijanskog umnoška domena, a domena je skup vrijednosti koje atribut poprima (skup imena gradova, imena zaposlenika) . Relacija (tablica) je podskup Kartezijevog produkta jedne ili više domena.
| Naziv relacije | ||||
| A1 | A2 | A3 | A4 | – atributi |
| A11 | A12 | A13 | A14 | - uzorci torki |
| A21 | A22 | A23 | A24 | |
| A31 | A32 | A33 | A34 | |
| … | … | … | … |
A11, A12 su vrijednosti atributa.
Relacijska baza podataka je skup međusobno povezanih relacija (tablica), a relacije između tablica specificirane su pomoću stranih ili sekundarnih ključeva, odnosno atributa tablica koji su u nekim drugim aspektima primarni. Popis naziva atributa naziva se shema odnosa. Svaki odnos ima jedinstveno ime. Svojstva odnosa: nema identičnih torki - svi se zapisi razlikuju u primarnom ključu; torke nisu poredane odozgo prema dolje; atributi nisu poredani s lijeva na desno (u operacijama relacijska algebra redovi i stupci odnosa mogu se pregledavati bilo kojim redoslijedom i slijedom, bez obzira na njihovo informacijsko značenje); sve vrijednosti su skalarne i svi elementi stupca su iste prirode, budući da su izgrađeni na istoj domeni. Relacija s takvim svojstvima naziva se normalizirana. U relaciji, jedan ili više atributa su ključ, odnosno oni jedinstveno karakteriziraju tuple. Ključna svojstva: jedinstvena identifikacija odabira, neredundantnost (uklanjanje bilo kojeg atributa lišava ga svojstva jedinstvenosti). Uz semantički ključ koristi se inkrementalni (brojački) ključ koji se sastoji od jednog numeričkog polja koje se automatski povećava.
Pravila prikaza konceptualni model predmetno područje u relacijsku bazu podataka.
Slika 5 prikazuje konceptualni model. Preslikajmo to u relacijske.
- preslikavanje entiteta u relacijske odnose koji su normalizirani
- mapiranje asocijacija povezano je s korištenjem referentnog integriteta između tablica. Odnos asocijacije 1:1, 1:M, M:1 implementiran je postavljanjem vanjskog sekundarnog ključa u entitet iz kojeg potječe strelica asocijacije. Ovaj ključ odgovara primarnom ključu na koji pokazuje strelica. Odnos više-prema-više zahtijeva unakrsnu tablicu koja uključuje sekundarne ključeve primarni ključevi povezani entiteti.
- agregacija se prikazuje pomoću asocijacija, dok se kreira zasebna tablica "dio" sa sekundarnim ključem koji je povezuje s tablicom vlasnika (cijela)
- preslikavanje generalizacije najčešće se vrši preslikavanjem svakog podtipa u zasebnu tablicu uz uključivanje sekundarnog ključa koji odgovara primarnom ključu tablice nadtipova. Primjer: "klijent" ( Kod klijenta) za podvrste "organizacija" ( OGRN, kod klijenta), "IP" ( KOSITAR, Šifra klijenta).
Cjelovitost relacijskog modela.
Cjelovitost objekata (relacije) - u bazi nije dopušteno da bilo koji atribut iz primarnog ključa poprima nedefinirane vrijednosti.
Referentni integritet - baza podataka ne smije sadržavati nedosljedne vrijednosti stranog ključa (FK). Ako relacija R2 među svojim atributima ima neke vanjski ključ, koji odgovara primarnom ključu (PK) relacije R1, tada svaka vrijednost FK mora biti jednaka vrijednosti RK. Primjer: svi kodovi materijala u tablici "dio" moraju biti prisutni kao primarni ključevi u tablici materijala.
Ovi pojmovi odgovaraju opisu grafički prikaz hijerarhijski model u obliku usmjerenog grafa (obrnuto stablo).
Svaki element hijerarhijske strukture odgovara nekom atributu baze podataka. Svaki unos u bazi podataka ima odgovarajući jedini način, koji vodi od korijenskog čvora do atributa lista (lišća). Na primjer, staza A; B3; C4 je zapis u bazi podataka. Ako pod A; razumjeti atribut - br zavoda (npr. MIREA), a pod B3; - broj skupine atributa (npr. VUS - 6,99), a pod C4; - atribut studentski broj (na primjer, Ivanov), zatim ovu strukturu je opis logičke strukture baze podataka studenata MIREA.
U bazi podataka može biti više korijenskih čvorova.
mrežni podatkovni model.
 |
U mrežnom modelu, s istim osnovnim pojmovima (razina, čvor, veza), svaki element se može pridružiti bilo kojem drugom elementu. Grafički prikaz struktura mreže prikazano na sljedećoj slici:
Relacijski model podataka.
Pojam relacijske baze podataka (od engleskog relation - odnos) vezan je prvenstveno uz ime američkog stručnjaka za baze podataka E. Codda.
relacijski model je organizacija podataka u obliku dvodimenzionalnih tablica. Svaka tablica ima sljedeća svojstva:
svaki stupac (atribut ili domena) ima jedinstveno ime;
u tablici nema identičnih redaka;
svi elementi u stupcu imaju isti tip i format;
redoslijed redova i stupaca je proizvoljan.
Baza podataka može imati više tablica, ali svaka tablica mora imati jedinstveno ime.
Sljedeća slika prikazuje primjer relacijskog modela izgrađenog na temelju odnosa: STUDENT, SESIJA, STIPENDIJA.
Polje tj. jedna ili više domena čija vrijednost jedinstveno identificira odgovarajući unos naziva se ključ ili ključ. U tablici. 1. i 2. ključ je polje "broj knjige". Da biste povezali dvije tablice potrebno je unijeti ključ jedne tablice u ključ druge tablice. Na primjer, za povezivanje tablica 2 i 3 potrebno je u tablici. 3 i 2 koriste atribut "rezultat". Da nije u nekoj od tablica, onda bi se moralo unijeti.
Koncept infološkog modela usko je povezan s relacijskim pristupom izgradnji baza podataka.
infoološki model.
Infoološki model temelji se prvenstveno na konceptu informacijskog objekta. Informacijski objekt je opis stvarnog objekta u obliku skupa logički povezanih detalja, ili indikatora, ili na drugi način informacijskih elemenata.
Gomila informacijski objekti formira klasu (ili tip) kojoj je dodijeljeno određeno jedinstveno ime.
Informacijski objekt može imati više ključeva, tj. pojedinosti koje ga jedinstveno definiraju.
Primjer prikaza informacijskog objekta u obliku grafikona prikazan je na sljedećoj slici:
Može doći do grupiranja atributa u informacijskim objektima različiti putevi, ali je poželjno da bude racionalan, tj. minimiziranje dupliciranja podataka i pojednostavljenje postupaka za njihovu obradu. Racionalizacija se postiže normalizacijom odnosa.
Normalizacija odnosa je formalni aparat ograničenja na formiranje odnosa, koji vam omogućuje uklanjanje dupliciranja podataka, osigurava njihovu dosljednost i smanjuje troškove rada za održavanje podataka (tj. unos i ispravak podataka).
E. Codd je izdvojio 3 normalna oblika odnosa i predložio mehanizam za njihovo dobivanje.
Prvi normalni oblik. Relacija je u prvom normalnom obliku (1NF) ako su svi njeni atributi nedjeljivi. Na primjer, atribut "Puno ime". nije u SF 1, jer može se podijeliti na “Prezime”, “Ime”, “Patronim”, tj. smanjen na 1 NF.
Za definiranje druge normalne forme (2NF) potrebno je razjasniti koncept funkcionalna ovisnost. Ovisnost funkcionalnog atributa je ovisnost u kojoj, u instanci informacijskog objekta, svaka ključna vrijednost odgovara samo jednoj vrijednosti neključnog (tj. opisnog) atributa.
Primjer funkcionalne ovisnosti prikazan je na slici:
Osim funkcionalne, postoji i pojam funkcionalne – potpune ovisnosti.
funkcionalni potpuna ovisnost je da je svaki ne-ključni atribut funkcionalno ovisan o ključu, ali nije funkcionalno ovisan ni o jednom dijelu složenog ključa.
Relacija će biti u 2NF ako je u 1NF i svaki atribut ključa potpuno funkcionalno ovisi o složenom ključu.
Primjer odnosa m-osi (u 2NF) je relacija student = ( , prezime, ime, patronim, datum, grupa) - koja se također nalazi u 1NF.
Omjer izvedbe = ( broj, Puno ime, disciplina, evaluacija) nalazi se u 1 NF i ima kompozitni ključ broj + disciplina. Ali ovaj odnos nije u 2NF, jer atributi prezime, ime, patronim nisu u potpunosti funkcionalno ovisni o složenom ključu odnosa (drugim riječima, prezime, ime, patronim funkcionalno ovise o dijelu složenog ključa - atributu broj a to je funkcionalno potpuna ovisnost).
Koncept treće normalne forme temelji se na konceptu tranzitivne i neprelazne ovisnosti.
Prijelazna ovisnost postoji između dva opisna (neključna) atributa ako jedan od njih ovisi o ključu, a drugi opisni atribut ovisi o njemu (tj. prvi opisni atribut).
Relacija će biti u trećem normalnom obliku (3NF) ako, budući da je u 2NF, nema ne-ključne atribute tranzitivno ovisne o primarnom ključu.
 |
Primjer tranzitivne ovisnosti za relaciju “Student” je atribut “Ravnatelj” koji je određen brojem “grupe”.
U tom slučaju će se prezime “Pročelnika” mnogo puta ponavljati u mnogim instancama informacijskog objekta “Student”, što uzrokuje neopravdano trošenje memorije i poteškoće u ispravljanju podataka prilikom zamjene pročelnika.
Da bi se eliminirala tranzitivna ovisnost, potrebno je "razdvojiti" izvorni informacijski objekt. Kao rezultat razdvajanja, neki od atributa uklanjaju se iz izvornog informacijskog objekta - vidi sl.
Primjer grafičkog prikaza infološkog modela koji povezuje informacijske objekte "Student", "Sesija", "Stipendija", "Nastavnik" prikazan je na sl.
Na temelju infološkog modela izgrađuju se konceptualni (logički), interni (fizički) i eksterni modeli baze podataka.
konceptualni model sastoji se od mnogo instanci različite vrste podaci strukturirani u skladu sa zahtjevima DBMS za logična struktura baze podataka (tj. zapravo, to prazne šablone za unos podataka).
unutarnji model sastoji se od pojedinačnih instanci zapisa fizički pohranjenih na vanjskom mediju.
vanjski model podržava privatne prikaze podataka koje zahtijeva određeni korisnik.
©2015-2019 stranica
Sva prava pripadaju njihovim autorima. Ova stranica ne tvrdi da je autor, ali pruža besplatno korištenje.
Datum izrade stranice: 2016-04-02
Srž svake baze podataka je model podataka. Podatkovni model je skup struktura podataka i njihovih operacija obrade.
Prema načinu uspostavljanja odnosa između podataka postoje hijerarhijski, mreža I relacijski model.
Hijerarhijski model omogućuje vam izgradnju baza podataka sa strukturom stabla, gdje svaki čvor sadrži vlastitu vrstu podataka (entitet). Na vrhunska razina stablo u ovom modelu postoji jedan čvor - korijen, na sljedeća razina locirani su čvorovi pridruženi ovom korijenu, zatim čvorovi pridruženi čvorovima prethodne razine itd. U ovom slučaju svaki čvor može imati samo jednog pretka.
Hijerarhijska struktura stabla modela baze podataka
Pronalaženje podataka u hijerarhijski sustav uvijek počinje od korijena. Zatim se vrši spuštanje s jedne razine stabla na drugu dok se ne postigne željena razina. Kretanje kroz sustav s jednog zapisa na drugi provodi se pomoću poveznica.
Glavne prednosti hijerarhijskog modela- jednostavnost opisa hijerarhijskih struktura stvarnog svijeta i brzo izvršavanje upita. Međutim, nije uvijek zgodno svaki put započeti traženje potrebnih podataka iz korijena, a drugi način kretanja po bazi podataka je hijerarhijske strukture Ne. Spomenuti nedostatak snimljeno u mrežnom modelu, gdje (prema barem, teoretski) moguće su veze svih informacijskih objekata sa svima.
U ovom modelu svaki nastavnik može podučavati mnogo (teoretski sve) učenika, a svaki učenik može učiti od mnogo (teoretski svih) učitelja. Budući da je to u praksi naravno nemoguće, potrebno je pribjeći određenim ograničenjima. Korištenje hijerarhijskih i mrežni modeli ubrzava pristup informacijama u bazi podataka. Međutim, budući da svaki podatkovni element mora sadržavati reference na neke druge elemente, potrebni su značajni resursi i na disku i u glavnoj memoriji računala. Nedostatak glavne memorije, naravno, smanjuje brzinu obrade podataka. Osim toga, takve modele karakterizira složenost implementacije sustava za upravljanje bazom podataka.
Relacijski model razvijen je ranih 1970-ih. Codd. Jednostavnost i fleksibilnost ovog modela privukli su pozornost programera, a već u 80-im godinama dvadesetog stoljeća. postalo je rašireno. Tako, relacijski DBMS postali industrijski standard.
Relacijski model temelji se na sustavu pojmova relacijske algebre od kojih su najvažniji tablica, red, stupac, relacija i primarni ključ, a sve operacije u ovom slučaju svode se na manipulacije tablicama. U relacijskom modelu informacije su predstavljene u obliku pravokutnih tablica, od kojih se svaka sastoji od redaka i stupaca i ima naziv koji je jedinstven unutar baze podataka.
Tablica odražava stvarni objekt - entitet, a svaki redak (zapis) odražava jednu specifičnu instancu objekta - instancu entiteta. Svaki stupac u tablici ima jedinstveno ime za tu tablicu. Stupci su raspoređeni prema redoslijedu njihovih naziva usvojenih prilikom izrade tablice.
Za razliku od stupaca, retci nemaju imena, njihov redoslijed u tablici nije definiran, a njihov broj nije logički ograničen. Budući da retci u tablici nisu poredani, nije moguće odabrati red po položaju. Broj prisutan u datoteci za svaki redak ne karakterizira ga, jer se njegova vrijednost mijenja kada se redovi izbrišu iz tablice. Logično, nema prvog i zadnjeg reda.
Relacijski sustavi eliminirali su potrebu za složenom navigacijom, budući da podaci u njima nisu prikazani u obliku jedne datoteke, već u neovisnim skupovima, a za odabir podataka koriste se operacije relacijske algebre - primijenjena teorija skupova.
Svaka tablica u relacijskom modelu mora imati stupac (ili skup stupaca) čija vrijednost jedinstveno identificira svaki od njegovih redaka. Ovaj stupac (ili skup stupaca) naziva se primarnim ključem tablice.
Ako tablica zadovoljava zahtjev jedinstvenosti primarnog ključa, naziva se relacija. U relacijskom modelu sve se tablice moraju pretvoriti u odnose. Odnosi relacijskog modela su međusobno povezani. Odnosi su podržani stranim ključevima.
Vanjski ključ- ovo je stupac (skup stupaca), čija vrijednost jedinstveno karakterizira vrijednosti primarnog ključa druge relacije (tablica).
Za relaciju u kojoj je definiran strani ključ kaže se da se odnosi na odgovarajuću relaciju u kojoj je isti skup stupaca primarni ključ.
U gornjem primjeru, odnos ZAPOSLENIKA odnosi se na odnos ODJEL kroz naziv odjela.
Shema relacijske tablice (odnos) je skup naziva polja koji čine njen zapis:
NAZIV TABLICE (Polje 1, Polje 2, ..., Polje n).
Na primjer, za tablice prikazane na slici imamo sljedeće sheme (primarni ključevi su u kurzivu):
DJELATNIK (propusnica, puno ime, pozicija, naziv odjela, broj telefona);
ODJEL (naziv odjela, mjesto odjela, namjena odjela).
Model objektno orijentirane baze podataka počeo se razvijati u vezi s pojavom objektno orijentiranih programskih jezika 90-ih godina dvadesetog stoljeća. Ove vrste baza podataka pohranjuju metode klase, a ponekad i postojane objekte klase, omogućujući besprijekornu integraciju između obrade podataka i aplikacije.
Dominaciju relacijskog modela u modernom DBMS-u određuju:
prisutnost razvijene teorije (relacijska algebra);
prisutnost aparata za redukciju drugih modela podataka na relacijski model;
prisutnost posebna sredstva ubrzani pristup informacijama;
imajući standardiziranu jezik visoke razine zahtjeva prema bazi podataka, što omogućuje da se njima manipulira bez poznavanja specifične fizičke organizacije baze podataka u vanjskoj memoriji.
VRSTE ODNOSA U MODELU
U praksi se često koriste poveznice koje uspostavljaju različite vrste korespondencije između objekata "povezanih" tipova su jedan-na-jedan (1:1), jedan-na-više (1:M), mnogo-na-više (M:M).
Odnos jedan prema jedan znači da svaka instanca prvog objekta (A) odgovara samo jednoj instanci drugog objekta (B) i, obrnuto, svaka instanca drugog objekta (B) odgovara samo jednoj instanci objekta prvi objekt (A).
Odnos jedan prema više znači da svaka instanca jednog objekta (A) može odgovarati nekoliko instanci drugog objekta (B), a svaka instanca drugog objekta (B) može odgovarati samo jednoj instanci prvog objekta ( A).
Odnos više-prema-više znači da svaka instanca jednog objekta (A) može odgovarati nekoliko instanci drugog objekta (B) i, obrnuto, svakoj instanci drugog objekta (B) također može odgovarati nekoliko instanci prvi objekt (A).
Primjer. Razmotrite skup sljedećih informacijskih objekata:
STUDENT (broj studenta, puno ime, datum rođenja, broj grupe);
STIPENDIJA (broj studenta, iznos stipendije);
GRUPA (broj grupe, specijalnost);
NASTAVNIK (Šifra nastavnika, puno ime, radno mjesto).
Ovdje su info-objekti STUDENT i STIPENDIJA povezani u odnosu jedan-na-jedan, budući da svaki student može imati samo jednu stipendiju i svaka se stipendija može dodijeliti samo jednom studentu.
Informacijski objekti GRUPA i STUDENT povezani su u odnosu jedan prema više, budući da jedna grupa može uključivati više studenata, dok svaki student može učiti samo u jednoj grupi.
Informacijski objekti STUDENT i NASTAVNIK povezani su u odnosu više-prema-više, budući da jedan učenik može učiti od mnogo nastavnika, a jedan nastavnik može poučavati mnogo učenika.
anotacija
U ovom seminarski rad opisuje dizajn središnje gradske bolničke baze podataka i njezinu implementaciju u Oracle Datebase. Predstavljeno je predmetno područje, razvijeni konceptualni, logički i fizički modeli podataka. Potrebne tablice, upiti, izvješća izrađeni su korištenjem Oracle Datebase alata. Nastavni rad se sastoji od.
Uvod 3
1. Predmetno područje 4
2.Konceptualni model 5
3.Logički model baza podataka 7
4. Model fizičke organizacije podataka 9
5. Implementacija baze podataka u Oracle 9
6.Izrada 10 tablica
7. Kreiranje upita 16
8. Zaključak 27
Reference 28
Uvod
Baza podataka je jedinstveno, prostrano spremište različitih podataka i opisa njihovih struktura, koje nakon definiranja, provedenog odvojeno i neovisno o aplikacijama, istovremeno koristi više aplikacija.
Osim podataka, baza može sadržavati alate koji svakom korisniku omogućuju da radi samo s podacima koji su u njegovoj nadležnosti. Kao rezultat interakcije podataka sadržanih u bazi podataka s dostupnim metodama specifičnim korisnicima, formiraju se informacije koje konzumiraju i na temelju kojih, u okviru vlastite nadležnosti, unose i uređuju podatke
Svrha ovog kolegija je razviti i implementirati bazu podataka za centralna bolnica osigurati pohranjivanje, prikupljanje i pružanje informacija o djelatnosti bolnice. Stvorena baza podaci namijenjeni su uglavnom za automatizaciju aktivnosti glavnih odjela bolnice.
Predmetno područje
Predmetno područje naziva se dio pravi sustav od interesa za ovu studiju. Pri projektiranju automatiziranih informacijskih sustava predmetno područje prikazuje se modelima podataka više razina. Broj razina zavisti ovisi o složenosti zadataka koji se rješavaju, ali u svakom slučaju uključuje konceptualnu i logičku razinu.
U ovom kolegiju predmetno područje je rad centralne bolnice u kojoj se liječe bolesnici. Organizacijski ustroj bolnice čine dva odjela: matični i hitni prijem. U registru se zakazuje pregled, izdaju uputnice, raspoređuju pacijenti na odjele i evidentiraju brojevi polica osiguranja. Hitna pomoć pak vodi evidenciju o prijemima i otpustima, dijagnozama pacijenata i povijesti bolesti.
Baza je namijenjena pohrani podataka o pacijentima, njihovom smještaju, propisanim lijekovima i liječnicima.
konceptualni model
Prva faza procesa projektiranja baze podataka je izrada konceptualnog modela podataka za analizirani dio poduzeća.
Konceptualni model je model domene. Komponente modela su objekti i odnosi. Konceptualni model služi kao sredstvo komunikacije između različitih korisnika i stoga se razvija bez uzimanja u obzir značajki fizičkog prikaza podataka. Prilikom dizajniranja konceptualnog modela, svi napori programera trebaju biti usmjereni uglavnom na strukturiranje podataka i identificiranje odnosa među njima bez razmatranja značajki implementacije i pitanja učinkovitosti obrade. Dizajn konceptualnog modela temelji se na analizi zadataka obrade podataka koji se rješavaju u ovom poduzeću. Konceptualni model uključuje opise objekata i njihovih odnosa koji su od interesa za predmetno područje koje se razmatra. Odnosi između objekata dio su konceptualnog modela i moraju se preslikati u bazu podataka. Odnos može obuhvatiti bilo koji broj objekata. S druge strane, svaki objekt može sudjelovati u bilo kojem broju veza. Uz to, postoje odnosi između atributa objekta. Postoje odnosi tipa: "jedan prema jedan", "jedan prema mnogima", "mnogi prema mnogima".
najviše popularan model konceptualni dizajn je model entitet-odnos (ER-model), odnosi se na semantičke modele.
Glavni elementi modela su entiteti, odnosi između njih i njihova svojstva (atributi).
Entitet je klasa objekata iste vrste, informacije o kojima se moraju uzeti u obzir u modelu.
Svaki entitet mora imati ime izraženo imenicom u jednini. Svaki entitet u modelu prikazan je kao pravokutnik s imenom.
Atribut je karakteristika (parametar) nekog entiteta.
Domena je skup vrijednosti (područje definiranja atributa).
Entiteti imaju ključne atribute - ključ entiteta je jedan ili više atributa koji jedinstveno identificiraju određeni entitet.
Skup entiteta za središnju bolnicu (atributi entiteta navedeni su u zagradama, ključni atributi su podvučeni):
PACIJENTI ( Šifra pacijenta, prezime, ime, datum rođenja, broj police osiguranja, šifra poslovnice);
LIJEČENJE ( Šifra pacijenta, dijagnoza, datum otpusta, šifra liječnika, trošak);
UREDI ( Šifra odjela, naziv odjela, broj komora);
PRIHODI ( kod pacijenta, datum prijema, šifra sobe);
KOMORA ( Kod komore, broj mjesta, šifra poslovnice);
LIJEČNICI(kod liječnika, prezime, ime, datum rođenja, broj osobnog dosjea, šifra odjela);
Dijagram entitet-odnos za okružna bolnica prikazano na slici 1.
Logički model baze podataka
Verzija konceptualnog modela koju može pružiti određeni DBMS naziva se logički model. Proces izgradnje logičkog modela baze podataka trebao bi se temeljiti na specifičnom modelu podataka (relacijski, mrežni, hijerarhijski), koji je određen tipom predložene implementacije. informacijski sistem DBMS. U našem slučaju, baza podataka je kreirana u Oracle okruženju i bit će relacijska baza podataka.
Relacijski model karakterizira njegova jednostavnost strukture podataka, tablični prikaz lak za korištenje i mogućnost korištenja formalnog aparata relacijske algebre i relacijskog računa za manipuliranje podacima.
U relacijskim modelima podataka, objekti i odnosi između njih predstavljeni su pomoću tablica. Svaka tablica predstavlja jedan objekt i sastoji se od redaka i stupaca. Tablica u relacijskom modelu naziva se relacija.
Atribut (polje) – bilo koji stupac u tablici.
Torke (zapisi) - redovi tablice.
Tablice su međusobno povezane ključnim poljima.
Ključ je polje koje jedinstveno identificira zapis u tablici. Ključ može biti jednostavan (sastoji se od jednog polja) ili složen (sastoji se od više polja).
U relacijske baze podataka podaci logičan dizajn dovodi do razvoja podatkovne sheme, koja je prikazana na slici 2.
sl.2.
4. Model fizičke organizacije podataka
Fizički model data opisuje kako se podaci pohranjuju na računalu, pruža informacije o strukturi zapisa, njihovom redoslijedu i pristupnim stazama koje postoje.
Fizički model opisuje vrste, identifikatore i bitnu dubinu polja. Fizički podatkovni model odražava fizičku lokaciju podataka na strojnom mediju, odnosno koju datoteku, koje objekte, s kojim atributima sadrži i koje vrste tih atributa.
©2015-2019 stranica
Sva prava pripadaju njihovim autorima. Ova stranica ne polaže pravo na autorstvo, ali omogućuje besplatnu upotrebu.
Datum izrade stranice: 2016-04-26
Prisutnost u DBMS-u određene, valjane strukture podataka dovodi do koncepta strukturiranih baza podataka, odnosno podaci u takvim bazama moraju biti prikazani kao skup međusobno povezanih elemenata. Ako dopustimo mogućnost generiranja novih tipova i dinamički proces uspostavljanja poveznica (tijekom pojavljivanja objekta u bazi podataka), dolazimo do pojma nestrukturiranih baza podataka. Prihvatljive su i srednje opcije koje se nazivaju baza podataka s djelomično determinističkom shemom. Ovakva podjela baze podataka prema stupnju strukturiranosti pohranjenih podataka pokazuje se bitnim momentom pri odabiru nosivog DBMS-a za implementaciju IS-a, budući da konkretni DBMS obično podržava određeni model podataka. S druge strane, treba imati na umu da se za svaku od navedenih vrsta baza podataka koriste odgovarajući modeli podataka, tj. postoji veliki broj modela podataka.
Trenutno postoje tri glavne vrste strukturiranih baza podataka logički modeli podataka ovisno o prirodi veza koje podržavaju između podatkovnih elemenata - mrežnih, hijerarhijskih i relacijskih. Klasifikacijske značajke u ovim modelima su: stupanj krutosti (fiksacije) veze, matematički prikaz strukture modela i dopušteni tipovi podataka (vidi tablicu 1.1). O valjanim tipovima podataka raspravljat ćemo kasnije u studiji. relacijski model.
Riža. 1.8 ilustrira značajke svakog modela podataka. Kada se uspoređuju modeli, treba imati na umu da su svi teoretski ekvivalentni. Ekvivalencija modela leži u činjenici da se oni mogu svesti jedan na drugi formalnim transformacijama. Detaljan dokaz ove činjenice može se naći u klasičnoj monografiji J. Martina o bazama podataka. Bit dokaza je odbacivanje principa redundantnosti podataka, odnosno dopušteno je dupliciranje podataka u reprezentativnim čvorovima. Tada se transformacija jednog modela u drugi dobiva jednostavnim udvostručenjem vrhova odgovarajuće reprezentacije u "mrežno-hijerarhijsko-relacijskom" lancu modela.
Riža. 1.8.
Opća načela klasifikacije DBMS-a
Vrlo često se DBMS-ovi klasificiraju prema vrsti podatkovnog modela koji podržavaju. Dakle, postoje mrežni, hijerarhijski i relacijski DBMS. Međutim, u praksi obrade podataka, DBMS-ove karakterizira njihova sposobnost podrške određena vrsta DB. U samom opći pogled Baza podataka je podijeljena na:
- faktografske, koje pohranjuju skup integriranih činjenica, po mogućnosti iz raznih dokumenata;
- dokumentarni, koji su usmjereni na pohranu dokumenata;
- dokumentarni i faktografski, koji imaju obilježja oba.
Da, DBMS CDS/ISIS prvenstveno usmjerena na podršku radu s dokumentom, koji se sastoji od određeni broj naslovi indeksirani tezaurusom ključne riječi. DBMS ADABAS je vrlo prikladan za organiziranje činjeničnih baza podataka, a DBMS ORACLE je prikladan za mješovite baze podataka. Kako bi se izbjegla zabuna s upotrebom specifični model podataka, baza podataka, uz rijetke iznimke, treba biti klasificirana prema vrsti modela koji se koristi u DBMS-u. Imajte na umu da je klasifikacija baza podataka daleko od dovršenog područja istraživanja: nastavljaju se pokušaji uvođenja novih tipova baza podataka (aktivne, deduktivne, neizrazite relacijske, grafičke baze podataka itd.).
U mnogim slučajevima, za programere IS-a važno je podijeliti DBMS (i bazu podataka) prema prirodi obrade: na centralizirane i distribuirane. Pri korištenju distribuirane obrade pozornost treba obratiti na prirodu transakcijske obrade, jer potonji imaju značajan utjecaj na performanse sustava. U najopćenitijem slučaju, transakcija se shvaća kao jedinica rada koju korisnik zahtijeva od baze podataka, bez obzira na prirodu obrade. Najčešće se kao rezultat obrade transakcije realizira zahtjev korisnika ili za dohvaćanje podataka iz baze podataka, ili za ažuriranje baze podataka, ili za izvođenje nekih drugih radnji nad bazom podataka. Pretpostavlja se da je izvršenje zahtjeva popraćeno izvršavanjem niza unutarsustavskih radnji DBMS-a usmjerenih na održavanje integriteta podataka, kontrolu pristupa itd.
Postoje različiti konceptualni pristupi obradi transakcija u distribuiranoj obradi. Temeljno pitanje ovdje nije samo kako, nego i gdje je obrada transakcija lokalizirana: na računalne datoteke krajnji korisnik ili na računalu posvećenom mreži. Odabir jednog ili drugog koncepta ovisit će o vremenu odgovora sustava na zahtjev korisnika. Parametar "vrijeme odgovora sustava na zahtjev korisnika" vrlo često djeluje kao definirajući ili poželjni parametar sustava koji se razvija. Na primjer, za distribuirani sustav rezerviranje zrakoplovnih karata za najveće svjetske zrakoplovne prijevoznike, ovaj je parametar bitan i propisan je u dizajnersko rješenje ne dulje od 30-45 sekundi.
