Logički model podataka. Koncept normalizacije odnosa

hitna pomoć- dijagrami

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

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

turisti

Vaučeri

Odnosi između ovih objekata mogu se definirati jednostavnim terminima:

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

Svaki bon odgovara svojoj uplati (može biti više uplata ako se bon npr. prodaje na kredit).

Svaka tura može imati nekoliko sezona.

Ulaznica se prodaje za jednu sezonu jedne turneje.

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

Riža. 2. ER dijagram za aplikaciju baze podataka upravitelja putničke agencije

Objekti, atributi i ključevi

Model se dalje razvija definiranjem atributa za svaki objekt. 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 te po potrebi proširujemo rječnik. Atributi za svaki objekt u primjeru prikazani su u tablici 2.

Tablica 2. Objekti i atributi baze podataka

Objekt	turisti	Vaučeri	Ture	Godišnja doba	Plaćanja
			Ime	početni datum	datum plaćanja
				Datum završetka
	Prezime		Informacija
Atributi

Imajte na umu da nekoliko stavki nedostaje. Podaci o registraciji navedeni u funkcionalnoj specifikaciji su izostavljeni. Kako to uzeti u obzir, razmislit ćete sami i finalizirati predloženi primjer. Ali još važnije, atributi potrebni za međusobno povezivanje objekata još uvijek nedostaju. Ovi elementi podataka nisu predstavljeni u ER modelu, budući da zapravo nisu "prirodni" atributi objekata. Oni se drugačije obrađuju i bit će uzeti u obzir u relacijski model podaci.

Relacijski model karakterizira uporaba ključeva i odnosa. U kontekstu relacijske baze podataka postoji razlika između pojmova odnos i odnos. Relacija se tretira kao nesređena, dvodimenzionalna tablica s nepovezanim redovima. Shema podataka se formira između odnosa (tablica) preko zajedničkih atributa, koji su ključevi.

Postoji nekoliko tipova ključeva, a ponekad se razlikuju samo u odnosu prema drugim atributima i odnosima. Primarni ključ jedinstveno identificira red u relaciji (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 potrebno je više od jednog atributa za identifikaciju redaka u odnosu. Skup ovih atributa naziva se složeni ključ. U drugim slučajevima, primarni ključ mora biti posebno kreiran (generiran). Na primjer, u relaciji “Turisti” ima smisla dodati jedinstveni turistički identifikator (turistički kod) kao primarni ključ ove relacije za organiziranje veza s drugim relacijama baze podataka.

Druga vrsta ključa, nazvana strani ključ, postoji samo u smislu podatkovne sheme između dva odnosa. Strani ključ u relaciji je atribut koji je primarni ključ (ili dio primarnog ključa) u drugoj relaciji. To je distribuirani atribut koji tvori podatkovnu shemu između dva odnosa u bazi podataka.

Za dizajniranu bazu podataka, proširit ćemo atribute objekata s kodnim poljima kao primarnim ključevima i koristiti te kodove u odnosima baze podataka za referencu na objekte baze podataka kako slijedi (Tablica 3).

Prerano je konstruiranu shemu baze podataka smatrati potpunom, jer je potrebna njezina normalizacija. Proces poznat kao normalizacija relacijske baze podataka koristi se za grupiranje atributa na posebne načine kako bi se smanjila redundancija i funkcionalna ovisnost.

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

Objekt	turisti	Vaučeri	Ture	Godišnja doba	Plaćanja
Atributi	Turistički kodeks	Šifra putovanja		Šifra sezone	Šifra plaćanja
		Turistički kodeks	Ime	početni datum	datum plaćanja
		Šifra sezone		Datum završetka
	Prezime		Informacija		Šifra putovanja

Normalizacija

Funkcionalne ovisnosti 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. Prema tome, po definiciji, svi atributi bez ključa (bez ključa) funkcionalno će ovisiti o primarnom ključu u svakom odnosu (budući da primarni ključ jedinstveno identificira svaki red). Kada jedan atribut odnosa ne definira jedinstveno drugi atribut, već ga ograničava na skup unaprijed definiranih vrijednosti, to se naziva viševrijednom ovisnošću. Djelomična ovisnost se događa kada je atribut relacije funkcionalno ovisan o jednom atributu složenog ključa. Prijelazne ovisnosti se promatraju kada ne-ključni atribut funkcionalno ovisi o jednom ili više drugih ne-ključnih atributa u odnosu.

Proces normalizacije sastoji se od korak-po-korak izgradnje baze podataka u normalan oblik(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 predmetno područje DB aplikacije ne bi trebale imati unutarnja struktura, čije elemente aplikacija može zahtijevati.

2. Drugi normalni oblik (2NF) nastaje kada se sve djelomične ovisnosti uklone iz odnosa baze podataka. Ako nema kompozitnih ključeva u odnosu, tada se ova razina normalizacije lako postiže.

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

4. Četvrti normalni oblik (4NF) nastaje kada se uklone sve ovisnosti s više vrijednosti.

Baza podataka našeg primjera je u 1NF-u, budući da su sva polja tablica baze podataka atomskog sadržaja. Naša baza podataka je također u 2NF, budući da smo umjetno uveli u svaku tablicu jedinstveni kodovi za svaki objekt (Tourist Code, Travel Code itd.), čime smo ostvarili 2NF za svaku od tablica baze podataka i cjelokupnu bazu podataka u cjelini. Ostaje pozabaviti se trećom i četvrtom normalnom formom.

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

Dakle, koje su tranzitivne i viševrijedne ovisnosti prisutne u našem primjeru baze podataka upravitelja putničke agencije?

Analizirajmo stav "Turista". Razmotrimo ovisnosti između atributa „Turistički kod“, „Prezime“, „Ime“, „Patronim“ i „Putovnica“ (slika 3). Svaki turist, predstavljen u odnosu kombinacijom "Prezime - Ime - Otac", ima samo jednu putovnicu za vrijeme trajanja putovanja, dok puni imenjaci moraju imati različite brojeve putovnica. Stoga atributi "Prezime - ime - patronim" i "Putovnica" čine složeni ključ za turiste.

Riža. 3. Primjer tranzitivne ovisnosti

Kao što se može vidjeti sa slike, atribut “Putovnica” tranzitivno ovisi o ključu “Turistički kod”. Stoga, kako bismo eliminirali ovu tranzitivnu ovisnost, podijelili smo složeni ključ relacije i samu relaciju na 2 prema odnosima jedan na jedan. Prva relacija, ostavimo je uz naziv “Turisti”, uključuje atribute “Turistički kod” i “Prezime”, “Ime”, “Oteče”. Drugu relaciju, nazovimo je “Podaci o turistima”, tvore atributi “Turistički kod” i svi ostali atributi relacije “Turisti”: “Putovnica”, “Telefon”, “Grad”, “Država”, "Indeks". Ove dvije nove relacije više nemaju tranzitivnu ovisnost i nalaze se u 3NF.

U našoj pojednostavljenoj bazi podataka nema ovisnosti s više vrijednosti. Na primjer, pretpostavimo da za svakog turista nekoliko kontakt brojevi(kuća, posao, mobitel itd., što je u praksi vrlo tipično), a ne jedan, kao u primjeru. Dobivamo višeznačnu ovisnost ključa - „Turistički kod” i atribute „Vrsta telefona” i „Telefon”; u ovoj situaciji ključ prestaje biti ključ. Što uraditi? Problem je također riješen dijeljenjem relacijske sheme u 2 nove sheme. Jedna od njih treba predstavljati podatke o telefonima (relacija “Telefoni”), a druga o turistima (relacija “Turisti”), s kojima se kontaktira preko polja “Turistički kod”. “Turistički kod” u odnosu na “Turisti” bit će primarni ključ, a u odnosu na “Telefoni” bit će vanjski ključ.

Slika 1. prikazuje logički model baze podataka studentskog doma.

Slika 1 – logički model

Logički (podatkovni) model je model baze podataka koji nije vezan uz specifični DBMS. Identificira glavne objekte baze podataka i definira odnose između tih objekata. Ponekad će se odrediti tipovi podataka pojedinačnih objekata. Ovaj model izgrađen metodom Entity Relationship.

2.2 Entiteti

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

Esencija Obrazac_o sadrži dva atributa: Ime_fo – serijski broj oblici obrazovanja i Obrazac_o– oblik obuke, od kojih je prva ključna. Ovaj entitet sadrži moguće opcije oblici izobrazbe (budžet i ugovor).

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

Esencija Fakultet sadrži podatke o fakultetima. Prvi atribut (ključ) Nom_fak– redni broj fakulteta, drugi atribut Fakultet– skraćeni naziv fakulteta.

Esencija Specijalitet sadrži informacije o specijalnostima sveučilišta. Atributi su redni broj i digitalna oznaka specijalnosti.

Esencija Soba sadrži brojeve soba i broj slobodnih mjesta u njima. Budući da prema uvjetima ne bi smjelo biti slobodnih soba i da u sobi ima samo 3 mjesta, potrebno je postaviti odgovarajuće ograničenje unosa podataka.

Esencija Cijene sadrži redni broj tarife, kriterije koji određuju trošak - statusni broj i broj oblika izobrazbe, te sam trošak tarife.

Esencija Skupina sadrži broj grupe, definiranje kriterija - broj fakulteta i broj specijalnosti te kolegij.

Zapravo Osobno_dano sadrži informacije o osobnim podacima učenika. Njegov studentski identifikacijski broj, prezime, ime, patronim, broj i serija putovnice, datum rođenja, mjesto rođenja, mjesto upisa i prebivalište.

Esencija Student sadrži broj studentske knjižice, broj tarife za plaćanje smještaja u hostelu, datum upisa na sveučilište i datum diplomiranja na sveučilištu.

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

Esencija Promjena_učenika služi za povezivanje entiteta Student I Promjene. Sadrži broj promjene, broj studentske iskaznice i datum kada je promjena nastala.

Esencija Stud_grupa također je poveznik entiteta Student I Skupina. Sadrži broj studentske iskaznice, broj grupe i podatke o isključenju i povratku studenata.

Još jedan povezujući entitet - Studio_soba. Dizajniran za pohranjivanje brojeva preseljenja studenata, brojeva studentskih iskaznica, brojeva soba te datuma prijave i odjave.

Arhiva– jedinica za smještaj veselih učenika. Sadrži matični broj, broj studentske iskaznice i datum odjave.

Zapravo Neplaćanje sadrži redni broj neplaćanja, broj studentske knjižice studenta koji nije platio smještaj te mjesec i godinu neplaćanja s njegove strane.

Zapravo Roditelji sadrži informacije o roditeljima studenta, kao što su ime oca i majke i status njihovog braka, koji mogu biti potrebni za isplatu dodatnih naknada studentu.

• upoznati tehnologiju izgradnje logičkog modela u ERWin-u,
• metode proučavanja za određivanje ključnih atributa entiteta,
• ovladati metodom provjere primjerenosti logičkog modela,
• proučavati vrste odnosa između entiteta.

Prvi korak u stvaranju 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ćuje da razmotrite cijeli sustav i razjasnite zahtjeve potrebne za njegov razvoj u vezi s pohranjivanjem informacija.

ERD dijagrami se mogu podijeliti u zasebne dijelove koji odgovaraju pojedinim zadacima koje projektirani sustav rješava. To nam omogućuje da sagledamo sustav iz perspektive funkcionalnost, čineći proces dizajna upravljivim.

ERD dijagrami

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

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

Riža.6.1. Primjer ERD dijagrama,

Definiranje entiteta i atributa

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

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

Riža. 6.2. ERD-dijagram atributa

Logički odnosi

Logički odnosi predstavljaju veze između entiteta. Definirani su glagolima koji pokazuju kako se jedan entitet odnosi na drugi.

Neki primjeri odnosa:

• momčad uključuje mnogo igrača,
• avion nosi mnogo putnika,
• Prodavač prodaje mnogo proizvoda.

U svim ovim slučajevima, odnosi odražavaju interakciju između dva entiteta, koja se naziva jedan prema više. To znači da je jedna instanca prvog entiteta u interakciji s više instanci drugog entiteta. Odnosi su predstavljeni linijama koje povezuju dva entiteta s točkom na jednom kraju i glagolom koji se nalazi iznad crte.

Osim odnosa jedan-prema-više, postoji još jedan tip - više-prema-više. Ova vrsta komunikacije opisuje situaciju u kojoj instance entiteta mogu komunicirati s više instanci drugih entiteta. Odnosi više-prema-više koriste se u početnim fazama dizajna. Ova vrsta odnosa je prikazana puna linija s točkicama na oba kraja.

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

Provjera adekvatnosti logičkog modela

Ako su odnosi između entiteta ispravno uspostavljeni, tada 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. Mnogo putnika se prevozi u jednom avionu.

Sastavljanje takvih prijedloga omogućuje vam provjeru usklađenosti rezultirajućeg modela sa zahtjevima i ograničenjima sustava koji se stvara.

Riža. 6.3.Primjer logičkog modela s odnosima

Model podataka temeljen na ključu

Svaki entitet sadrži vodoravna crta dijeleći atribute u dvije skupine. Atributi iznad retka nazivaju se primarni ključ. Svrha primarnog ključa je jedinstvena identifikacija instance entiteta.

Odabir primarnog ključa

Prilikom izrade entiteta trebate 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 točno identificirati instancu entiteta. Nijedan od atributa primarnog ključa ne smije imati nulta vrijednost. Vrijednosti atributa primarnog ključa ne bi se trebale mijenjati. Ako se vrijednost promijenila, onda se radi o drugoj instanci 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 sustav može automatski generirati prilikom dodavanja instance entiteta u bazu podataka. Korištenje jedinstvenih brojeva olakšava proces indeksiranja i pretraživanja u bazi podataka.

Primarni ključ odabran prilikom izrade logičkog modela možda neće biti prikladan za učinkovit 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ćuje da istaknete atribute alternativnih ključeva, a prema zadanim postavkama, u budućnosti, prilikom generiranja sheme baze podataka, jedinstveni indeks će se generirati pomoću ovih atributa. Kada kreirate alternativni ključ, simboli (AK) pojavljuju se pored atributa u dijagramu.

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

Kada se uspostavi veza između dva entiteta, strani ključevi se automatski generiraju u entitetu dijete. Odnos tvori referencu na atribute primarnog ključa u entitetu dijete, a ti atributi tvore strani ključ u entitetu dijete. Atributi stranog ključa označeni su simbolima (FK) iza imena.

Primjer

Razmotrimo proces izgradnje logičkog modela na primjeru baze podataka studenata sustava „Sveučilišne službe za zapošljavanje“. Prvi korak je definiranje entiteta i atributa. Baza podataka će pohranjivati ​​zapise o studentima, stoga će entitet biti student.

Tablica 6.1.Atributi entiteta “Student”.

Atribut	Opis
Broj	Jedinstveni broj za identifikaciju korisnika
PUNO IME.	Prezime, ime i patronim korisnika
Lozinka	Lozinka za pristup sustavu
Dob	Studentska dob
Kat	Spol učenika
Karakteristično	Memo polje sa opća karakteristika korisnik
E-mail	Email adrese
Telefon	Studentski telefonski brojevi (kućni, poslovni)
iskustvo	Specijaliteti i studentsko radno iskustvo u svakom od njih
Specijalitet	Specijalnost koju student dobiva po završetku obrazovne ustanove
Specijalizacija	Područje specijalnosti u kojem student studira
Strani jezik	Popis stranih jezika i njihova razina znanja
Testiranje	Popis testova i ocjene o njihovom završetku
Stručni pregled	Popis predmeta sa stručnim ocjenama za svaki od njih
Ocjene ispita	Popis položenih predmeta s ocjenama

Rezultirajući popis sadrži atribute koji se ne mogu definirati kao jedno polje baze podataka. Takvi atributi zahtijevaju dodatne definicije i trebaju se smatrati entitetima koji se sastoje od atributa. Tu spadaju: radno iskustvo, strani jezik, testiranje, stručna procjena, ocjene na ispitu. Definirajmo njihove atribute.

Tablica 6.2.Atributi entiteta “Radno iskustvo”.

Tablica 6.3.Atributi entiteta “Strani jezik”.

Tablica 6.4.Atributi entiteta Testiranja

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

Atribut	Opis
Disciplina	Naziv discipline iz koje je student ocjenjivan
PUNO IME. učitelj, nastavnik, profesor	PUNO IME. nastavnik koji je ocjenjivao učenika
Razred	Stručna ocjena nastavnika
Atribut		Opis
Artikal		Naziv predmeta iz kojeg se polagao ispit
Razred		Dobiveni rezultat

Kreirajmo ERD dijagram, definirajući vrste atributa i uspostavljajući veze između entiteta (slika 6.4). Svi će entiteti ovisiti o entitetu "Student". Odnosi će biti tipa jedan prema više.

Riža. 6.4.ERD dijagram baze podataka studenata

Na rezultirajućem dijagramu, pored odnosa, prikazan je njegov naziv, pokazujući odnos između entiteta. Kada se uspostavi odnos između entiteta, primarni ključ migrira u entitet dijete.

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

Tablica 6.7.Vrste atributa

Atribut	Tip
Karakteristično
Specijalitet
Specijalizacija
Mjesto rada
Razina znanja
Ime
Opis
Disciplina
PUNO IME. učitelj, nastavnik, profesor

Izaberimo za svaki entitet ključni atributi, nedvosmisleno definirajući entitet. Za entitet "Student" to će biti jedinstveni broj; za entitet "Radno iskustvo" sva polja su ključna, jer u različitim specijalnostima student može imati različito radno iskustvo u različitim tvrtkama. Entitet “Test” definiran je svojim nazivom, budući da student može imati samo jednu ocjenu za jedan test. Ocjenu ispita određuje samo naziv predmeta, stručna ocjena ovisi o nastavniku koji ju je izradio, pa ćemo kao ključne atribute odabrati “Disciplina” i “Ime i prezime”. učitelj, nastavnik, profesor." Za entitet "Strani jezik", razina znanja ovisi samo o nazivu jezika, stoga će to biti ključni atribut.

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

Riža. 6.5.ERD dijagram baze podataka studenata s ključnim atributima

Kontrolna pitanja

1. Imenujte glavne dijelove ERD dijagrama.
2. Svrha ERD dijagrama.
3. Što je glavna komponenta relacijske baze podataka?
4. Što se zove esencija?
5. Formulirajte princip imenovanja entiteta.
6. Što pokazuje odnos između entiteta?
7. Navedite vrste logičkih odnosa.
8. Kako se prikazuju logični odnosi?
9. Opišite mehanizam provjere adekvatnosti logičkog modela.
10. Što je primarni ključ?
11. Navedite principe prema kojima se formira primarni ključ.
12. Što je alternativni ključ?
13. Što se naziva inverzijski ulaz?
14. Kada se formiraju strani ključevi?

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

anotacija

U ovom predmetni 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 i izvješća izrađeni su pomoću alata Oracle Datebase. Tečaj se sastoji od:

Uvod 3

1. Predmetno područje 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.Izrada tablica 10

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 što se definiraju zasebno 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 generiraju se informacije koje oni 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 je dio pravi sustav, od interesa za ovu studiju. Pri projektiranju automatiziranih informacijskih sustava predmetno područje predstavljaju modeli podataka više razina. Broj razina ovisi o složenosti problema koji se rješava, 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. Organizacijska struktura Bolnica se sastoji od dva odjela: registrature i prijemnog dijela. Na recepciji se zakazuje termine, izdaju uputnice, raspoređuju pacijenti na odjele i evidentiraju brojevi osiguranja. Hitna pomoć pak vodi evidenciju o prijemu i otpustu, dijagnozama pacijenata i povijesti bolesti.

Baza podataka namijenjena je pohrani podataka o pacijentima, njihovom smještaju, propisanim lijekovima i liječnicima.

Konceptualni model

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

Konceptualni model je model domene. Komponente modela su objekti i odnosi. Konceptualni model služi kao sredstvo komunikacije između od strane različitih korisnika te se stoga razvija bez uzimanja u obzir značajki fizičkog prikaza podataka. Prilikom dizajniranja konceptualnog modela, svi napori programera trebali bi 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 prikazati u bazi podataka. Odnos može obuhvatiti bilo koji broj objekata. S druge strane, svaki objekt može sudjelovati u bilo kojem broju odnosa. Uz to, postoje odnosi između atributa objekta. Postoje odnosi sljedećih vrsta: "jedan prema jednom", "jedan prema mnogima", "mnogo prema mnogima".

Najviše popularan model konceptualni dizajn je model “entity-relationship” (ER-model), spada u semantičke modele.

Glavni elementi modela su entiteti, veze 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) entiteta.

Domena – skup vrijednosti (područje definiranja atributa).

Entiteti imaju ključne atribute - ključ entiteta je jedan ili više atributa koji jedinstveno identificiraju ovaj 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 odjela);

LIJEČENJE ( Šifra pacijenta, dijagnoza, datum otpusta, šifra liječnika, cijena);

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

PRIHODI ( Šifra pacijenta datum prijema, šifra odjela);

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

LIJEČNICI(Kod doktora 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 određeni model podataka (relacijski, mrežni, hijerarhijski), što je određeno tipom DBMS-a namijenjenog implementaciji informacijskog sustava. 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, prilagođen korisniku tablični prikaz i sposobnost 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) su redovi tablice.

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

Ključ je polje koje vam omogućuje jedinstvenu identifikaciju zapisa 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 logički dizajn podataka 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žajući informacije o strukturi zapisa, njihovom redoslijedu i postojećim putovima pristupa.

Fizički model opisuje tipove, identifikatore i bitne širine polja. Fizički podatkovni model odražava fizički smještaj podataka na strojnom mediju, odnosno koju datoteku, koje objekte, s kojim atributima sadrži i koje su vrste tih atributa.

©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-26

Logički model podataka - opis objekata predmetnog područja, njihovih atributa i odnosa među njima u mjeri u kojoj su podložni izravno skladištenje u bazi podataka sustava.

Logički model se gradi u nekoliko faza uz postupno približavanje optimalnoj opciji za zadane uvjete. Učinkovitost takvog modela ovisi o tome koliko blisko predstavlja predmetno područje koje se proučava. Predmetno područje obuhvaća objekte (isprave, račune, poslovanje s njima i sl.), kao i karakteristike tih objekata, njihova svojstva, interakciju i međusobni utjecaj.

Dakle, prilikom izgradnje logičkog modela podataka prvo se identificiraju oni objekti koji su od interesa za korisnike projektirane baze podataka. Zatim se za svaki objekt formuliraju karakteristike i svojstva koja dovoljno cjelovito opisuju ovaj objekt. Te će se karakteristike kasnije odraziti u bazi podataka kao odgovarajuća polja.

Logički model podataka izgrađen je u okviru jednog od tri pristupa izradi baza podataka. Razlikuju se sljedeći tipovi logičkih modela baze podataka:

Hijerarhijski;

Mreža;

Relacijska.

Hijerarhijski model je struktura stabla koja izražava veze podređenosti niže razine višoj. To olakšava pronalaženje informacija ako upiti imaju istu strukturu.

Mrežni model razlikuje se od prethodnog po tome što ima i horizontalne veze. To komplicira i model i samu bazu podataka i njezine alate za upravljanje.

Relacijski model predstavlja pohranjene informacije u obliku tablica na kojima je moguće izvoditi logičke operacije(operacije relacijske algebre). U trenutno Ova vrsta modela je najrasprostranjenija. To je zbog komparativne jednostavnosti implementacije, jasne definicije odnosa između objekata i lakoće mijenjanja strukture baze podataka.

Opis korisnika sustava i korisničkih grupa

Informacijski i referentni sustav koji se razvija mogu koristiti i zaposlenici kina i posjetitelji. Zaposlenik kina može uređivati ​​postojeće podatke o postojećim filmovima, mijenjati raspored rada kina, te novopristigle filmove uvrstiti na repertoar kina; a posjetitelj može pogledati informacije o radnom vremenu kina, cijenama ulaznica i filmovima za danas.

Model domene

Jedan od naj prikladni alati jedinstveni prikaz podataka, neovisno o implementatoru softver, model je entitet-odnos (ER - model). Model entitet-odnos temelji se na nekim važnim semantičke informacije o stvarnom svijetu i namijenjen je logično predstavljanje podaci. Definira značenja podataka u kontekstu njihovih odnosa s drugim podacima. Kategorije “bit” i “odnos” proglašavaju se temeljnima, a njihova se podjela vrši u fazi stvaranja specifičnih prikaza određenog predmetnog područja.

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

Zbirka entiteta i obrazaca klasa odnosa vrhunska razina modeli.

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

Važna činjenica je da se svi postojeći modeli podataka (hijerarhijski, mrežni, relacijski, objektni) mogu generirati iz modela “entitet-odnos”, dakle on je najopćenitiji.

Model entitet-odnos prikazan je u Dodatku E.

Relacijska baza podataka sastoji se od normaliziranih tablica. U procesu učitavanja i ažuriranja baze podataka, za dobivanje informacija o upitima i izlaznim izvješćima, kao i za rješavanje većine problema, potreban je istovremeni pristup nekoliko međusobno povezanih tablica. Odnos između tablica baze podataka uspostavlja se relacijskim odnosima.

Odnosi definirani u podatkovnoj shemi automatski se koriste pri razvoju obrazaca s više tablica, upita i izvješća, značajno pojednostavljujući proces njihovog dizajna.

Programski proizvod predstavlja projekt - Kino, koji ima 4 međusobno povezana stola:

Tickety - podaci o prodanim 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.