Logički model podataka. Koncept normalizacije odnosa

ER-dijagrami

Uobičajeni način predstavljanja logičkog modela baze podataka je izgradnja dijagrama ER (entitet-odnos). U ovom modelu, entitet je definiran kao diskretni objekt za koji se pohranjuju elementi podataka, a odnos opisuje odnos između dva objekta.

U primjeru menadžera turističke agencije postoji 5 glavnih objekata:

Turisti

Vaučeri

Odnosi između ovih objekata mogu se jednostavno definirati:

Svaki turist može kupiti jedan ili više (više) vaučera.

Svaki vaučer odgovara njegovoj uplati (može biti nekoliko uplata ako se vaučer, na primjer, prodaje na kredit).

Svaka turneja može imati nekoliko sezona.

Ulaznica se prodaje za jednu sezonu jedne turneje.

Ovi objekti i odnosi mogu biti predstavljeni ER dijagramom, kao što je prikazano na slici 2.

Rice. 2. ER dijagram za aplikaciju baze podataka menadžera putničke agencije

Objekti, atributi i ključevi

Model se dalje razvija definisanjem atributa za svaki objekat. Atributi objekta su elementi podataka koji se odnose na određeni objekt koji se moraju sačuvati. Analiziramo sastavljeni rječnik podataka, odabiremo objekte i njihove atribute u njemu i proširujemo rječnik ako je potrebno. Atributi za svaki objekt u primjeru prikazani su u tabeli 2.

Tablica 2. Objekti i atributi baze podataka

Objekt	Turisti	Vaučeri	Tours	Godišnja doba	Plaćanja
			Ime	datum početka	datum uplate
				Datum završetka
	Prezime		Informacije
Atributi

Imajte na umu da nedostaje nekoliko stavki. Podaci o registraciji navedeni u funkcionalnoj specifikaciji su izostavljeni. Kako to uzeti u obzir, sami ćete razmisliti i finalizirati predloženi primjer. Ali što je još važnije, atributi potrebni za međusobno povezivanje objekata još uvijek nedostaju. Ovi elementi podataka nisu predstavljeni u ER modelu, jer zapravo nisu „prirodni“ atributi objekata. Oni se različito obrađuju i biće uzeti u obzir u relacioni model podaci.

Relacioni model karakteriše upotreba ključeva i relacija. Postoji razlika u kontekstu relacione baze podataka između termina relacija i odnos. Relacija se tretira kao neuređena, dvodimenzionalna tabela sa nepovezanim redovima. Šema podataka se formira između relacija (tabela) preko zajedničkih atributa, koji su ključevi.

Postoji nekoliko tipova ključeva, a ponekad se razlikuju samo u pogledu njihovog odnosa prema drugim atributima i odnosima. Primarni ključ jedinstveno identificira red u vezi (tablici), a svaka relacija može imati samo jedan primarni ključ, čak i ako je više od jednog atributa jedinstveno. U nekim slučajevima, više od jednog atributa je potrebno za identifikaciju redova u odnosu. Kolekcija ovih atributa naziva se kompozitni ključ. U drugim slučajevima, primarni ključ mora biti posebno kreiran (generisan). Na primjer, u relaciji “Turisti” ima smisla dodati jedinstveni turistički identifikator (turističku šifru) kao primarni ključ ove relacije za organiziranje veza s drugim relacijama baze podataka.

Druga vrsta ključa, nazvana strani ključ, postoji samo u smislu šeme podataka između dva odnosa. Strani ključ u vezi je atribut koji je primarni ključ (ili dio primarnog ključa) u drugoj relaciji. To je distribuirani atribut koji formira šemu podataka između dva odnosa u bazi podataka.

Za dizajniranu bazu podataka, proširit ćemo atribute objekata sa poljima koda kao primarnim ključevima i koristiti ove kodove u odnosima baze podataka za upućivanje na objekte baze podataka kako slijedi (Tablica 3).

Prerano je da se konstruisana šema baze podataka smatra završenom, jer je potrebna njena normalizacija. Za grupisanje atributa koristi se proces poznat kao normalizacija relacijske baze podataka na posebne načine kako bi se smanjila redundantnost i funkcionalna ovisnost.

Tablica 3. DB objekti i atributi s proširenim kodnim poljima

Objekt	Turisti	Vaučeri	Tours	Godišnja doba	Plaćanja
Atributi	Turistički kod	Šifra putovanja		Sezonski kod	Šifra plaćanja
		Turistički kod	Ime	datum početka	datum uplate
		Sezonski kod		Datum završetka
	Prezime		Informacije		Šifra putovanja

Normalizacija

Funkcionalne zavisnosti nastaju kada se vrijednost jednog atributa može odrediti iz vrijednosti drugog atributa. Za atribut koji se može odrediti kaže se da je funkcionalno ovisan o atributu koji je determinanta. Stoga će, po definiciji, svi atributi koji nisu ključ (bez ključa) funkcionalno ovisiti o primarnom ključu u svakom odnosu (pošto primarni ključ jedinstveno identificira svaki red). Kada jedan atribut relacije ne definira jednoznačno drugi atribut, već ga ograničava na skup unaprijed definiranih vrijednosti, naziva se ovisnost s više vrijednosti. Djelomična ovisnost nastaje kada je atribut relacije funkcionalno ovisan o jednom atributu složenog ključa. Tranzitivne zavisnosti se opažaju kada je neključni atribut funkcionalno ovisan o jednom ili više drugih neključnih atributa u odnosu.

Proces normalizacije sastoji se od izgradnje baze podataka korak po korak normalna forma(NF).

1. Prvi normalni oblik (1NF) je vrlo jednostavan. Sve tablice baze podataka moraju zadovoljiti jedan zahtjev - svaka ćelija u tablicama mora sadržavati atomsku vrijednost, drugim riječima, pohranjenu vrijednost unutar predmetna oblast DB aplikacije ne bi trebale imati unutrašnja struktura, elemente koje aplikacija može zahtijevati.

2. Drugi normalni oblik (2NF) se kreira kada se sve djelomične zavisnosti uklone iz odnosa baze podataka. Ako u odnosu nema kompozitnih ključeva, onda se ovaj nivo normalizacije lako postiže.

3. Treći normalni oblik (3NF) baze podataka zahtijeva uklanjanje svih tranzitivnih zavisnosti.

4. Četvrti normalni oblik (4NF) se kreira kada se uklone sve viševrijedne zavisnosti.

Baza podataka našeg primjera je u 1NF, pošto su sva polja tabela baze podataka atomska po sadržaju. Naša baza podataka je također u 2NF, jer smo umjetno uneli u svaku tabelu jedinstveni kodovi za svaki objekat (Turistička šifra, Putna šifra itd.), zbog čega smo postigli 2NF za svaku od tabela baze podataka i cijelu bazu podataka u cjelini. Ostaje da se pozabavimo trećim i četvrtim normalnim oblikom.

Imajte na umu da postoje samo relativno razne vrste zavisnosti atributa baze podataka. Postoje zavisnosti - morate koštati NF bazu podataka, nema zavisnosti - baza podataka je već u NF. Ali zadnja opcija praktički se nikada ne pojavljuje u stvarnim aplikacijama.

Dakle, koje su tranzitivne i viševrijedne zavisnosti prisutne u našem primjeru baze podataka menadžera turističkih agencija?

Hajde da analiziramo stav "Turista". Razmotrimo zavisnosti između atributa „Turistički kod“, „Prezime“, „Ime“, „Patronim“ i „Pasoš“ (slika 3). Svaki turist, predstavljen u odnosu kombinacijom „Prezime – Ime – Patronim“, ima samo jedan pasoš za vrijeme trajanja putovanja, dok puni imenjaka moraju imati različite brojeve pasoša. Stoga, atributi "Prezime - Ime - Patronim" i "Pasoš" čine kompozitni ključ za turiste.

Rice. 3. Primjer tranzitivne zavisnosti

Kao što se može vidjeti sa slike, atribut “Passport” tranzitivno ovisi o ključu “Tourist Code”. Stoga, da bismo eliminirali ovu tranzitivnu ovisnost, podijelili smo kompozitni ključ relacije i samu relaciju na 2 prema relacijama jedan-na-jedan. Prva relacija, ostavimo je sa imenom “Turisti”, uključuje atribute “Turistički kod” i “Prezime”, “Ime”, “Patronim”. Drugu relaciju, nazovimo je “Informacije o turistima”, formiraju atributi “Turistički kod” i svi preostali atributi relacije “Turisti”: “Pasoš”, “Telefon”, “Grad”, “Država”, “Indeks”. Ova dva nova odnosa više nemaju tranzitivnu zavisnost i nalaze se u 3NF.

U našoj pojednostavljenoj bazi podataka nema viševrijednih ovisnosti. Na primjer, pretpostavimo da je za svakog turista nekoliko kontakt brojeve(kuća, posao, mobitel, itd., što je vrlo tipično u praksi), a ne jedan, kao u primjeru. Dobijamo viševrijednu ovisnost ključa - "Turistički kod" i atributa "Vrsta telefona" i "Telefon"; u ovoj situaciji ključ prestaje biti ključ. sta da radim? Problem je također riješen podjelom relacijske sheme na 2 nove sheme. Jedan od njih treba da predstavlja podatke o telefonima (relacija “Telefoni”), a drugi o turistima (relacija “Turisti”), koji se kontaktiraju putem polja “Turistički kod”. “Turistički kod” u odnosu na “Turisti” će biti primarni ključ, a u odnosu na “Telefone” će biti eksterni ključ.

Na slici 1 prikazan je logički model baze podataka studentskog doma.

Slika 1 – logički model

Logički (podatkovni) model je model baze podataka koji nije vezan za njega specifični DBMS. On identificira glavne objekte baze podataka i definira odnose između ovih objekata. Ponekad će se odrediti tipovi podataka pojedinačnih objekata. Ovaj model izgrađen koristeći metodu odnosa entiteta.

2.2 Entiteti

Ova baza podataka sadrži 16 entiteta. Pogledajmo svaki od njih i veze između njih.

Essence Form_about sadrži dva atributa: Nom_pho – serijski broj oblici obrazovanja, i Form_about– oblik obuke, od kojih je prvi ključan. Ovaj entitet sadrži moguće opcije oblici obuke (budžet i ugovor).

Essence Status također sadrži dva atributa: Nom_st– serijski broj statusa (ključni atribut), i Status– naziv statusa. Status može imati dva značenja: student i diplomirani student.

Essence fakultet sadrži informacije o fakultetima. Prvi atribut (ključ) Nom_fak– redni broj fakulteta, drugi atribut fakultet– skraćeni naziv fakulteta.

Essence Specijalitet sadrži informacije o specijalnostima univerziteta. Atributi su serijski broj i digitalna oznaka specijalnosti.

Essence Soba sadrži brojeve soba i broj slobodnih mjesta u njima. S obzirom na to da prema uslovu ne bi trebalo da bude slobodnih prostorija i da u prostoriji ima samo 3 mjesta, morat ćete postaviti odgovarajuće ograničenje za unos podataka.

Essence Cijene sadrži serijski broj tarife, kriterijume koji određuju cenu - statusni broj i broj oblika obuke, te cenu same tarife.

Essence Grupa sadrži broj grupe, definisanje kriterijuma - broj fakulteta i broj specijalnosti, kao i predmet.

Zapravo Personal_given sadrži informacije o ličnim podacima učenika. Njegov broj studentske karte, prezime, ime, patronime, broj i serija pasoša, datum rođenja, mjesto rođenja, mjesto prijave i prebivalište.

Essence Student sadrži matični broj studenta, broj tarife za plaćanje smještaja u hostelu, datum prijema na fakultet i datum diplomiranja na fakultetu.

Essence Promjene sadrži informacije o promjenama koje su se dogodile tokom studija. Kao atribute sadrži broj promjene, naziv fakulteta, broj specijalnosti, broj predmeta, broj grupe, broj oblika studija i statusni broj.

Essence Student_change služi za povezivanje entiteta Student I Promjene. Sadrži broj promjene, broj studentske karte i datum kada je došlo do promjene.

Essence Stud_group je također konektor entiteta Student I Grupa. Sadrži matični broj studenta, broj grupe i podatke o isključenju i vraćanju studenata.

Još jedan povezujući entitet - Studio_room. Dizajniran za pohranjivanje studentskog broja preseljenja, studentskog ID-a, broja sobe i datuma prijave i odjave.

Arhiva– entitet za skladištenje veselih učenika. Sadrži matični broj, studentski broj i datum odjave.

Zapravo Neplaćanje sadrži redni broj neplaćanja, matični broj studenta koji nije platio smještaj, te mjesec i godinu neplaćenih od njega.

Zapravo Roditelji sadrži podatke o roditeljima učenika, kao što su ime oca i majke i status njihovog braka, koji mogu biti potrebni za isplatu dodatnih beneficija studentu.

• upoznati se sa tehnologijom izgradnje logičkog modela u ERWin-u,
• metode proučavanja za određivanje ključnih atributa entiteta,
• ovladati metodom provjere adekvatnosti logičkog modela,
• proučavaju vrste odnosa između entiteta.

Prvi korak u kreiranju logičkog modela baze podataka je izgradnja ERD (Entity Relationship Diagram). ERD dijagrami se sastoje od tri dijela: entiteta, atributa i odnosa. Entiteti su imenice, atributi su pridjevi ili modifikatori, a odnosi su glagoli.

ERD dijagram vam omogućava da razmotrite cijeli sistem i razjasnite zahtjeve potrebne za njegov razvoj u vezi s pohranom informacija.

ERD dijagrami se mogu podijeliti u zasebne dijelove koji odgovaraju pojedinačnim zadacima koje rješava projektovani sistem. Ovo nam omogućava da sagledamo sistem iz ugla gledišta funkcionalnost, čineći proces dizajna upravljivim.

ERD dijagrami

Kao što znate, glavna komponenta relacione baze podataka je tabela. Tablica se koristi za strukturiranje i pohranjivanje informacija. U relacionim bazama podataka, svaka ćelija tabele sadrži jednu vrednost. Osim toga, unutar jedne baze podataka postoje odnosi između tabela, od kojih svaka specificira dijeljenje podataka tablice.

ERD dijagram grafički predstavlja strukturu podataka projekta informacioni sistem. Entiteti se prikazuju pomoću pravokutnika koji sadrže ime. Imena se obično izražavaju kao imenice u jednini, a odnosi se izražavaju pomoću linija koje povezuju pojedinačne entitete. Odnos pokazuje da se podaci jednog entiteta odnose ili su povezani s podacima drugog.

Rice.6.1. Primjer ERD dijagrama,

Definiranje entiteta i atributa

Entitet je subjekt, mjesto, stvar, događaj ili koncept koji sadrži informacije. Preciznije, entitet je skup (unija) objekata koji se nazivaju instance. Na prikazanoj slici. U primjeru na slici 6.1, entitet CUSTOMER predstavlja svakoga mogući klijenti. Svaka instanca entiteta ima skup karakteristika. Dakle, svaki klijent može imati ime, adresu, telefon, itd. U logičkom modelu, sve ove karakteristike se nazivaju atributi entiteta.

Na sl. Slika 6.2 prikazuje ERD dijagram koji uključuje atribute entiteta.

Rice. 6.2. ERD-dijagram atributa

Logički odnosi

Logički odnosi predstavljaju veze između entiteta. Definirani su glagolima koji pokazuju kako je jedan entitet povezan s drugim.

Neki primjeri veza:

• tim uključuje mnogo igrača,
• avion prevozi mnogo putnika,
• Prodavac prodaje mnoge proizvode.

U svim ovim slučajevima, odnosi odražavaju interakciju između dva entiteta, koja se naziva jedan prema više. To znači da jedna instanca prvog entiteta stupa u interakciju s višestrukim instancama drugog entiteta. Odnosi su predstavljeni linijama koje povezuju dva entiteta sa tačkom na jednom kraju i glagolom postavljenim iznad linije.

Pored odnosa jedan-prema-više, postoji još jedan tip - mnogo-prema-mnogo. Ova vrsta komunikacije opisuje situaciju u kojoj instance entiteta mogu komunicirati s višestrukim instancama drugih entiteta. Odnosi mnogo-prema-mnogo se koriste u početnim fazama dizajna. Ova vrsta odnosa je prikazana puna linija sa tačkama na oba kraja.

Odnos više-prema-više možda neće uzeti u obzir određena sistemska ograničenja, tako da može biti zamijenjen odnosom jedan-prema-više u kasnijoj reviziji dizajna.

Provjera adekvatnosti logičkog modela

Ako su odnosi između entiteta ispravno uspostavljeni, onda se mogu napisati rečenice koje ih opisuju. Na primjer, prema modelu prikazanom na sl. 6.3, možete napraviti sljedeće rečenice:

Avion prevozi putnike. U jednom avionu se prevozi mnogo putnika.

Izrada takvih prijedloga omogućava vam da provjerite usklađenost rezultirajućeg modela sa zahtjevima i ograničenjima sistema koji se kreira.

Rice. 6.3.Primjer logičkog modela sa relacijama

Model podataka baziran na ključu

Svaki entitet sadrži horizontalna linija, dijeleći atribute u dvije grupe. Atributi iznad reda se nazivaju primarni ključ. Svrha primarnog ključa je da jedinstveno identificira instancu entiteta.

Odabir primarnog ključa

Kada kreirate entitet, morate odabrati grupu atributa koji bi potencijalno mogli postati primarni ključ (potencijalni ključevi), zatim odabrati atribute za uključivanje u primarni ključ, slijedeći sljedeće preporuke:

Primarni ključ mora biti odabran na takav način da vrijednosti atributa uključenih u njega mogu precizno identificirati instancu entiteta. Nijedan od atributa primarnog ključa ne smije imati null vrijednost. Vrijednosti atributa primarnog ključa ne bi se trebale mijenjati. Ako se vrijednost promijenila, onda je to druga instanca entiteta.

Kada odaberete primarni ključ, entitetu možete dodati dodatni atribut i učiniti ga ključem. Stoga se za određivanje primarnog ključa često koriste jedinstveni brojevi, koje sistem može automatski generirati prilikom dodavanja instance entiteta u bazu podataka. Upotreba jedinstvenih brojeva olakšava proces indeksiranja i pretraživanja u bazi podataka.

Primarni ključ odabran prilikom kreiranja logičkog modela možda nije prikladan za efikasan pristup bazi podataka i mora se promijeniti prilikom dizajniranja fizičkog modela.

Potencijalni ključ koji ne postane primarni ključ naziva se alternativni ključ. ERWin vam omogućava da istaknete atribute alternativnih ključeva, a prema zadanim postavkama, u budućnosti, prilikom generiranja šeme baze podataka, jedinstveni indeks će se generirati pomoću ovih atributa. Kada kreirate alternativni ključ, simboli (AK) se pojavljuju pored atributa na dijagramu.

Atributi koji učestvuju u nejedinstvenim indeksima nazivaju se inverzioni unosi. Inverzijski ulazi su atribut ili grupa atributa koji ne definiraju jedinstveno instancu, ali se često koriste za upućivanje na instance entiteta. ERWin generiše nejedinstveni indeks za svaki inverzijski ulaz.

Kada se uspostavi veza između dva entiteta, strani ključevi se automatski generiraju u podređenom entitetu. Odnos formira referencu na atribute primarnog ključa u podređenom entitetu, a ti atributi formiraju strani ključ u podređenom entitetu. Atributi stranog ključa označeni su simbolima (FK) nakon njihovog naziva.

Primjer

Razmotrimo proces konstruisanja logičkog modela na primeru baze podataka studenata sistema „Univerzitetske službe za zapošljavanje“. Prvi korak je definiranje entiteta i atributa. Baza podataka će pohraniti evidenciju o studentima, stoga će entitet biti student.

Tabela 6.1.Atributi entiteta “Student”.

Atribut	Opis
Broj	Jedinstveni broj za identifikaciju korisnika
PUNO IME.	Prezime, ime i patronimija korisnika
Lozinka	Lozinka za pristup sistemu
Dob	Studentski uzrast
Kat	Rod studenta
Karakteristično	Memo polje sa opšta karakteristika korisnik
Email	Email adrese
Telefon	Studentski brojevi telefona (kuća, posao)
iskustvo	Specijalnosti i studentsko radno iskustvo u svakom od njih
Specijalitet	Specijalnost koju student dobija po završetku obrazovne ustanove
Specijalizacija	Oblast specijalnosti u kojoj student studira
Strani jezik	Spisak stranih jezika i nivo njihovog znanja
Testiranje	Spisak testova i ocene o njihovom završetku
Stručni pregled	Spisak predmeta sa stručnim ocjenama za svaki od njih
Ocjene na ispitu	Spisak položenih predmeta sa ocjenama

Rezultirajuća lista sadrži atribute koji se ne mogu definirati kao jedno polje baze podataka. Takvi atributi zahtijevaju dodatne definicije i treba ih smatrati entitetima, koji se sastoje od atributa. To uključuje: radno iskustvo, strani jezik, testiranje, stručnu ocjenu, ispitne ocjene. Hajde da definišemo njihove atribute.

Tabela 6.2.Atributi entiteta “Radno iskustvo”.

Tabela 6.3.Atributi entiteta „Strani jezik“.

Tabela 6.4.Atributi entiteta za testiranje

Tabela 6.5.Atributi entiteta “Stručna procjena”.

Atribut	Opis
Disciplina	Naziv discipline u kojoj je student ocjenjivan
PUNO IME. nastavnik	PUNO IME. nastavnik koji je ocjenjivao učenika
Ocjena	Stručna ocjena nastavnika
Atribut		Opis
Stavka		Naziv predmeta iz kojeg se polagao ispit
Ocjena		Received score

Kreirajmo ERD dijagram, definirajući tipove atributa i uspostavljajući veze između entiteta (slika 6.4). Svi entiteti će zavisiti od entiteta “Student”. Odnosi će biti tipa jedan prema više.

Rice. 6.4.ERD dijagram baze podataka studenata

Na rezultirajućem dijagramu, pored odnosa, odražava se njegovo ime koje pokazuje odnos između entiteta. Kada se napravi odnos između entiteta, primarni ključ migrira u podređeni entitet.

Sljedeći korak u izgradnji logičkog modela je identificiranje ključnih atributa i tipova atributa.

Tabela 6.7.Vrste atributa

Atribut	Tip
Karakteristično
Specijalitet
Specijalizacija
Mjesto rada
Nivo znanja
Ime
Opis
Disciplina
PUNO IME. nastavnik

Odaberimo za svaki entitet ključni atributi, nedvosmisleno definirajući entitet. Za entitet „Student” to će biti jedinstven broj, za entitet „Radno iskustvo” su sva polja ključna, jer u različitim specijalnostima student može imati različito radno iskustvo u različitim kompanijama. Entitet “Test” je definisan svojim imenom, jer učenik može imati samo jednu ocjenu za jedan test. Ocjenu ispita određuje samo naziv predmeta, stručna ocjena zavisi od nastavnika koji ju je sastavio, pa ćemo kao ključne atribute odabrati „Disciplina“ i „Puno ime“. učiteljica." Za entitet „Strani jezik“, nivo znanja zavisi samo od naziva jezika, stoga će ovo biti ključni atribut.

Dobijamo novi dijagram, prikazano na sl. 6.5, gdje će se svi ključni atributi nalaziti iznad horizontalne linije unutar okvira koji prikazuje entitet.

Rice. 6.5.ERD dijagram baze podataka studenata sa ključnim atributima

Kontrolna pitanja

1. Imenujte glavne dijelove ERD dijagrama.
2. Svrha ERD dijagrama.
3. Koja je glavna komponenta relacione baze podataka?
4. Šta se zove esencija?
5. Formulirajte princip imenovanja entiteta.
6. Šta pokazuje odnos između entiteta?
7. Navedite vrste logičkih odnosa.
8. Kako se prikazuju logički odnosi?
9. Opisati mehanizam za provjeru adekvatnosti logičkog modela.
10. Šta je primarni ključ?
11. Navedite principe prema kojima se formira primarni ključ.
12. Šta je alternativni ključ?
13. Šta se naziva inverzijskim ulazom?
14. Kada se formiraju strani ključevi?

1. Tema, svrha rada.
2. ERD-dijagram baze podataka Zavoda za zapošljavanje sa atributima i ključevima.
3. Zaključci iz rada

anotacija

U ovom rad na kursu opisuje dizajn baze podataka centralne gradske bolnice i njenu implementaciju u Oracle Datebase. Predstavljena je predmetna oblast, razvijeni su konceptualni, logički i fizički modeli podataka. Potrebne tabele, upiti i izvještaji kreirani su pomoću alata Oracle Datebase. Kurs se sastoji od:

Uvod 3

1. Predmetna oblast 4

2. Konceptualni model 5

3.Logički model baze podataka 7

4.Model fizička organizacija podaci 9

5. Implementacija baza podataka u Oracle 9

6.Kreiranje tabela 10

7.Kreiranje upita 16

8. Zaključak 27

Literatura 28

Uvod

Baza podataka je jedinstveno, prostrano spremište različitih podataka i opisa njihovih struktura, koje, nakon što se definiše zasebno i nezavisno od aplikacija, istovremeno koriste mnoge aplikacije.

Osim podataka, baza podataka može sadržavati alate koji svakom korisniku omogućavaju rad samo sa podacima koji su u njegovoj nadležnosti. Kao rezultat interakcije podataka sadržanih u bazi podataka sa dostupnim metodama određene korisnike generiraju se informacije koje konzumiraju i na osnovu kojih, u okviru vlastite nadležnosti, unose i uređuju podatke

Svrha ovog kursa je razvoj i implementacija baze podataka za centralna bolnica, kako bi se osiguralo skladištenje, akumuliranje i pružanje informacija o aktivnostima bolnice. Kreirana baza podaci su namijenjeni uglavnom za automatizaciju aktivnosti glavnih odjela bolnice.

Predmetna oblast

Predmetno područje je dio pravi sistem, od interesa za ovu studiju. Pri projektovanju automatizovanih informacionih sistema predmetnu oblast predstavljaju modeli podataka više nivoa. Broj nivoa zavisi od složenosti problema koji se rešavaju, ali u svakom slučaju uključuje konceptualne i logičke nivoe.

U ovom nastavnom radu predmetna oblast je rad centralne bolnice koja liječi pacijente. Organizacijske strukture Bolnica se sastoji od dva odjeljenja: registrature i prijemnog dijela. Na recepciji se zakazuju pregledi, izdaju uputnice, pacijenti se raspoređuju na odjeljenja, evidentiraju se brojevi osiguranja. Hitna pomoć, zauzvrat, vodi evidenciju prijema i otpusta, dijagnoze pacijenata i anamnezu.

Baza podataka je dizajnirana za pohranjivanje podataka o pacijentima, njihovom smještaju, prepisanim lijekovima i ljekarima.

Konceptualni model

Prva faza procesa dizajniranja baze podataka je kreiranje baze podataka za dio poduzeća koji se analizira. konceptualni model podaci.

Konceptualni model je model domena. Komponente modela su objekti i odnosi. Konceptualni model služi kao sredstvo komunikacije između od strane različitih korisnika i stoga se razvija bez uzimanja u obzir karakteristika fizičkog predstavljanja podataka. Prilikom dizajniranja konceptualnog modela, svi napori programera treba da budu usmereni uglavnom na strukturiranje podataka i identifikaciju odnosa između njih bez razmatranja karakteristika implementacije i pitanja efikasnosti obrade. Dizajn idejnog modela zasniva se na analizi zadataka obrade podataka koji se rešavaju u ovom preduzeću. Konceptualni model uključuje opise objekata i njihovih odnosa koji su od interesa u predmetnoj oblasti koja se razmatra. Odnosi između objekata su dio konceptualnog modela i moraju biti prikazani u bazi podataka. Odnos može obuhvatiti bilo koji broj objekata. S druge strane, svaki objekat može učestvovati u bilo kojem broju relacija. Uz to, postoje odnosi između atributa objekta. Postoje odnosi sljedećih tipova: „jedan prema jedan“, „jedan prema mnogima“, „mnogo prema mnogima“.

Većina popularan model konceptualni dizajn je model „entitet-odnos” (ER-model), pripada semantičkim modelima.

Glavni elementi modela su entiteti, veze između njih i njihova svojstva (atributi).

Entitet je klasa objekata istog tipa, informacije o kojima se moraju uzeti u obzir u modelu.

Svaki entitet mora imati ime izraženo imenicom u jednini. Svaki entitet u modelu je prikazan kao pravougaonik sa imenom.

Atribut je karakteristika (parametar) entiteta.

Domen – skup vrijednosti (područje definicije atributa).

Entiteti imaju atribute ključa - ključ entiteta je jedan ili više atributa koji jedinstveno identificiraju ovaj entitet.

Skup entiteta za centralnu bolnicu (atributi entiteta su navedeni u zagradama, ključni atributi su podvučeni):

PACIJENTI ( Šifra pacijenta, prezime, ime, datum rođenja, broj police osiguranja, šifra odjeljenja);

LIJEČENJE ( Šifra pacijenta, dijagnoza, datum otpusta, šifra doktora, trošak);

ODELJENJA( Šifra podružnice, naziv odjeljenja, broj odjeljenja);

PRIHOD ( Šifra pacijenta datum prijema, šifra odjeljenja);

KOMORE ( Kod komore, broj mjesta, šifra odjeljenja);

LIJEČNICI(Doktorski kod prezime, ime, datum rođenja, broj ličnog dosijea, šifra odjeljenja);

Dijagram entitet-odnos za okružna bolnica prikazano na slici 1.

Logički model baze podataka

Verzija konceptualnog modela koju može dati određeni DBMS naziva se logički model. Proces izgradnje logičkog modela baze podataka treba da se zasniva na određeni model podataka (relacijski, mrežni, hijerarhijski), koji je određen tipom DBMS-a namijenjenog implementaciji informacionog sistema. U našem slučaju, baza podataka je kreirana u Oracle okruženju i biće relaciona baza podataka.

Relacioni model karakteriše njegova jednostavnost strukture podataka, lak za korišćenje tabelarni prikaz i sposobnost upotrebe formalnog aparata relacijske algebre i relacionog računa za manipulaciju podacima.

U relacionim modelima podataka, objekti i odnosi između njih su predstavljeni pomoću tabela. Svaka tabela predstavlja jedan objekat i sastoji se od redova i kolona. Tabela u relacionom modelu naziva se relacija.

Atribut (polje) – bilo koja kolona u tabeli.

Korke (zapisi) su redovi tabele.

Tabele su međusobno povezane pomoću ključnih polja.

Ključ je polje koje vam omogućava da jedinstveno identifikujete zapis u tabeli. Ključ može biti jednostavan (sastoji se od jednog polja) ili složen (sastoji se od više polja).

IN relacione baze podataka Logički dizajn podataka dovodi do razvoja šeme podataka, koja je prikazana na slici 2.

Fig.2.
4. Model organizacije fizičkih podataka

Fizički model podaci opisuju kako se podaci pohranjuju na računaru, pružajući informacije o strukturi zapisa, njihovom redoslijedu i postojećim putevima pristupa.

Fizički model opisuje tipove, identifikatore i bitne širine polja. Fizički model podataka odražava fizički smještaj podataka na mašinskom mediju, odnosno koji fajl, koje objekte, sa kojim atributima sadrži i koji su tipovi ovih atributa.

©2015-2019 stranica
Sva prava pripadaju njihovim autorima. Ova stranica ne tvrdi autorstvo, ali pruža besplatno korišćenje.
Datum kreiranja stranice: 26.04.2016

Logički model podataka - opis objekata predmetnog područja, njihovih atributa i odnosa između njih u mjeri u kojoj su podložni direktno skladištenje u sistemskoj bazi podataka.

Logički model se gradi u nekoliko faza sa postepenim pristupom optimalnoj opciji za date uslove. Efikasnost takvog modela zavisi od toga koliko blisko predstavlja predmetnu oblast koja se proučava. Predmetna oblast obuhvata objekte (dokumente, račune, operacije sa njima itd.), kao i karakteristike ovih objekata, njihova svojstva, interakciju i međusobni uticaj.

Dakle, prilikom izgradnje logičkog modela podataka prvo se identifikuju oni objekti koji su od interesa za korisnike dizajnirane baze podataka. Zatim se za svaki objekat formulišu karakteristike i svojstva koja dovoljno u potpunosti opisuju ovaj objekat. Ove karakteristike će se kasnije odraziti u bazi podataka kao odgovarajuća polja.

Logički model podataka izgrađen je u okviru jednog od tri pristupa kreiranju baza podataka. Razlikuju se sljedeće vrste modela logičke baze podataka:

Hijerarhijski;

Mreža;

Relaciona.

Hijerarhijski model je struktura stabla koja izražava veze subordinacije nižeg nivoa prema višem. Ovo olakšava pronalaženje informacija ako upiti imaju istu strukturu.

Mrežni model se razlikuje od prethodnog po tome što ima i horizontalne veze. Ovo komplikuje i model i samu bazu podataka i njene alate za upravljanje.

Relacioni model predstavlja pohranjene informacije u obliku tabela na kojima je moguće izvesti logičke operacije(operacije relacione algebre). IN trenutno Ovaj tip modela je najrašireniji. To je zbog komparativne jednostavnosti implementacije, jasne definicije odnosa između objekata i lakoće promjene strukture baze podataka.

Opis korisnika sistema i korisničkih grupa

Informacioni i referentni sistem koji se razvija mogu da koriste i zaposleni u bioskopu i posetioci. Zaposleni u bioskopu može uređivati ​​postojeće informacije o postojećim filmovima, mijenjati raspored rada bioskopa i uključivati ​​novoprimljene filmove u repertoar kina; a posjetitelj može vidjeti informacije o radnom vremenu kina, cijenama ulaznica i filmovima za danas.

Model domene

Jedan od mnogih pogodni alati jedinstveno predstavljanje podataka, nezavisno od implementatora softver, je model entitet-relacija (ER - model). Model entitet-odnos zasniva se na nekim važnim semantičke informacije o stvarnom svijetu i namijenjen je logičko predstavljanje podaci. Definira značenja podataka u kontekstu njihovih odnosa s drugim podacima. Kategorije “suština” i “odnos” proglašavaju se temeljnim, a njihova podjela se vrši u fazi kreiranja specifičnih predstava određene predmetne oblasti.

Svaki entitet pripada određenoj klasi, drugim riječima, odgovara određenom tipu. Postoje veze između entiteta kojima korisnik pripisuje određenu klasu(nekako). Dakle, klasa entiteta i klasa odnosa definiraju skupove specifičnih objekata i relacije između njih. Entitet može pripadati više od jedne klase.

Kolekcija oblika entiteta i klasa odnosa vrhunski nivo modeli.

Entiteti i odnosi su opisani njihovim karakterističnim atributima. Među atributima entiteta ili odnosa razlikuje se podlista čije vrijednosti atributa jedinstveno identificiraju entitet ili odnos unutar tipa. Formiraju se entiteti, odnosi i atributi Niži nivo modeli.

Važna činjenica je da se svi postojeći modeli podataka (hijerarhijski, mrežni, relacioni, objektni) mogu generisati iz modela „entitet-relacija“, pa je on najopštiji.

Model entitet-odnos predstavljen je u Dodatku E.

Relaciona baza podataka se sastoji od normalizovanih tabela. U procesu učitavanja i ažuriranja baze podataka, za dobijanje informacija o upitima i izlaznim izveštajima, kao i za rešavanje većine problema, potreban je istovremeni pristup više međusobno povezanih tabela. Odnos između tablica baze podataka uspostavlja se relacijskim odnosima.

Odnosi definisani u šemi podataka se automatski koriste pri razvoju višetabelskih obrazaca, upita i izveštaja, značajno pojednostavljujući proces njihovog dizajna.

Softverski proizvod predstavljen je projektom - Cinema, koji ima 4 međusobno povezana stola:

Ulaznica - informacije o prodatim ulaznicama;

Filmovi - informacije o svim filmovima dostupnim u kinu;

Seansy - informacije o terminima sesija i cijeni ulaznica za te sesije;

Danas - informacije o filmovima koji će biti prikazani danas.