Hidroinformatika - University of Belgradehikom.grf.bg.ac.rs/.../1_HidroinformatikaBazepodataka-Uvod_2016.pdf · 1. BAZE PODATAKA - UVOD Zadaci SUBP-a Baza podataka se sastoji od jednog

UNIVERZITET U BEOGRADU

GRAĐEVINSKI FAKULTET

Hidroinformatika

Beograd, 2016.

UVOD U BAZE PODATAKA

Miloš Stanić[email protected]

1. BAZE PODATAKA - UVOD


Zadaci SUBP-a

Baza podataka se sastoji od jednog ili više fajlova

koji se nalaze na jednom (centralna) ili više

(distribuirana) računara (server-a).

SUBP je skup programa koji omogućavaju unos,

čuvanje i pristup strukturama podataka u bazi.

VERIFIKACIJA I VREDNOVANJE

CENTRALNISERVER

RUČNI UNOS

MERNISISTEMI

1. Prikupljanje podataka iz raznih

izvora (i verifikacija –

vrednovanje). Akvizicija

podataka: automatska i

manuelna

2. Čuvanje (transfer i arhiviranje)

“velikog broja” podataka u

jasno definisanim strukturama

3. Pristupanje podacima i prava

pristupa:

- pojedinačni korisnici

- specijalizovani softveri (npr.

vizuelizacija, modeliranje kao

deo HIS-a)


Istorijat:

Do 1951 – Klasična organizacija datoteka (bušene kartice)

1951 – 1965 Složenija obrada, pojava računara, magnetne

trake, rad sa više datoteka, rad sa velikim brojem programa

1965 – Čarls Bahman, koncept integrisanih podataka

(standardi iz 1971 i 1978). Po tom konceptu podaci se

predstavljaju preko slogova, a integracija i uspostavljanje

veza medju podacima se ostvaruje ukazateljskim

ulančavanjem slogova u strukture stabla, lista i

mreža.(Formatizovane BP)


Istorijat:

1971 – Edgar Kod formuliše teorijske osnove relacionih

baza podataka (organizacija podataka i formalizam

manipulacije podacima)

1974 – 1979 IBM realizuje prvu relacionu bazu podataka –

Sistem R.

1981 – Pojavljuju se prve komercijalne relacione baze

podataka.

1986- a, zatim kroz standarde iz 1989, 1992, 1995, 2003

Formulisan je jezik za relacione baze podataka - SQL


Istorijat:

Početak razvoja računara je obeležio period razvoja i

primene pojedinačnih programa

Podaci su čuvani u jednom ili više fajlova

Svaka izmena u strukturi fajlova zahteva izmenu i samog

programa koji koristi ove podatke


Istorijat:

Problemi koji su vezani za ovaj pristup:

Potreba za razvojem dodatnih programa koji bi koristili

zajednički set podataka u postojećim fajlovima

I svoje specifične podatke u novim ili izmenjenim

postojećim fajlovima

Problem ažuriranja podataka odnosno

upravljanja podacima

Problem redundantnih podataka

1. BAZE PODATAKA UVOD

Istorijat:

Osnovni nedostatci

Redundantnost podataka – isti podaci se pojavljuju u više

fajlova koji su vezani za različite aplikacije

Nekonzistentnost podataka – zbog ponavljanja podataka,

izmenu jednog podatka treba obaviti u više fajlova

Zavisnost programa od strukture podataka – obično

svaka promena zahteva izmenu i testiranje svih programa

koji te podatke koriste

Problem istovremenog pristupa podacima više korisnika

problem ažuriranja podataka. Pamti se samo poslednja

promena, problem prava pristupa različitih grupa korisnika


Ciljevi – zahtevi za razvojem SUBP:

Nezavisnost strukture podataka od aplikacija

Normiranost - kontrolisana redundantnost podataka

Konkurentnost - mogućnost korišćenja podataka od strane

većeg broja korisnika

Sigurnost – pristup korisnika sa različitim pravima

Integritet – provera konzistentnosti ažuriranih podataka i

oporavak od naglog prekida izmene podataka

Opštost - upravljanje bazom podataka nije vezeno za

konkretan programski jezik


Ciljevi – zahtevi za razvojem SUBP:

SUBP koji se najviše koriste:

– MySQL (Open Source, svi OS)

– PostgreSQL (Open Source)

– Oracle

– DB2 (IBM)

– Access (Microsoft)

– SQL server (Microsoft)

2. RELACIONI MODEL PODATAKA

Definicija

Baza podataka je integrisani skup podataka o nekom sistemu

organizovan prema potrebama korisnika i elementarni skup

postupaka za njihovo održavanje i korišćenje.

Baza podataka se najčešće prikazuje Modelom podataka.

U ranijim fazama razvoja baza podataka bili su zastupljeni

mrežni i hijerarhijski model podataka

Trenutno su Relacioni modeli podataka odnosno relacione

baze podataka ubedljivo najzastupljenije.

U fazi razvoja je i Objektno orijentisani relacioni model

podataka


!(

!(

!(!(

!( !(!( !(!( !(!(

!(!(

!(!(

!(!( !(!( !(

!( !(

!( !(!(!( !(

!(!(

!(

!(

!(!(!(!( !(

!(!(

!(

!( !(!(!( !( !(!(!( !(!(

!( !(!(!( !(!(

!(!(

!(!(!(

!(

!(!(

!(

!(

!(!(

!(

!(

!(

!(!(!(

!(

Feature

Waterbody

HydroIDHydroCodeFTypeNameAreaSqKmJunctionID

HydroPoint

HydroIDHydroCodeFTypeNameJunctionID

Watershed

HydroIDHydroCodeDrainIDAreaSqKmJunctionIDNextDownID

ComplexEdgeFeature

EdgeType

Flowline

Shoreline

HydroEdge

HydroIDHydroCodeReachCodeNameLengthKmLengthDownFlowDirFTypeEdgeTypeEnabled

SimpleJunctionFeature

1HydroJunction

HydroIDHydroCodeNextDownIDLengthDownDrainAreaFTypeEnabledAncillaryRole

*

1

*

HydroNetwork

*

HydroJunction


HydroJunction


Primer

Arc Hydro – Model podataka.


Primer

Deo 3Dnet – Modela podataka.


Osnovni pojmovi

Baza podataka se sastoji od skupa Tabela - Relacija (Table,

Relation, Recordset) i skupa veza izmedju tih Tabela

Entitet (Entity, Tuple, Record) se prikazuje kao jedan zapis

u tabeli (red) koji ima unapred definisanu strukturu.

Sruktura zapisa je definisana skupom atributa (polja -

kolone u tabeli).

Svaki atribut ai ima domen iz koga može uzimati vrednosti

(Di) i mora imati jedinstveno ime (Ai) u relaciji (tabeli)


Osnovni pojmovi

Relacija (Tabela) r je skup entiteta (zapisa) t

Relacija r je podskup skupa R: D1 x D2 x … x Dn

R predstavlja domen relacije

Jedan zapis (entitet) je

n-torka t:(a1, a2, …, an)

koja predstavlja skup atributa

pri čemu ai Di


Osnovni pojmovi

Relacija r(R) je skup entiteta t:(a1, a2, ... , an).

Da bi r bila bazna relacija moraju biti ispunjeni sledeći

uslovi:

o Ne postoje dva ista zapisa (entiteta)

o Redosled entiteta nije bitan

o Svi atributi zadovoljavaju uslov “atomnosti”


Osnovni pojmovi

Često se relacije predstavljaju preko takozvane šeme relacije:

STUDENT(BRIND, IME, PREZIME, JMBG)

PRIJAVA(SIFPREDMETA, BRIND, ISPROK, OCENA, DATUM)

Ključ relacije r

U svakoj relaciji postoji jedan atribut (prost ključ) ili više atributa

(složen ključ) čije vrednosti jedinstveno predstavljaju svaki zapis u

relaciji.


Osnovni pojmovi

Ključ je kolekcija k jednog ili više atributa A takva da ne postoje

dva zapisa sa istim ključem.

Može postojati više kolekcija koje mogu biti ključ u relaciji.

Ključ koji se odabere da na jedinstveni način predstavlja entitet

(zapis) u relaciji (tabeli) naziva se primarni ključ (pk).


PREDMET(SIFPREDMETA, SEMESTAR, BRČASOVA)



Osnovni pojmovi

Spoljni ključ (sk) je atribut ili grupa atributa u relaciji r1 koji nije

primarni ključ u toj relaciji već je primarni ključ u nekoj drugoj

relaciji r2 i koristi se za povezivanje ove dve relacije.


PREDMET(SIFPREDMETA, SEMESTAR, BRČASOVA)



Osnovni pojmovi

Nula vrednost (NULL) se koristi da označi (u momentu

unosa) nepoznatu vrednost atributa u jednom zapisu.

Pravila integriteta

Integritet entiteta: Atribut koji je primarni ključ (prost ključ)

ili deo ključa (složen ključ) neke relacije, ne sme uzimati

vrednost NULL.

Referencijalni inegritet: Ako neka relacija relacija r2 ima

spoljni ključ sk2, koja je sa relacijom r1 povezuje preko

njenog primarnog ključa pk1, onda svaka vrednost atributa

koji su spoljni ključ mora biti jednaka nekoj vrednosti iz pk1

ili jednaka „ništa“ vrednosti (NULL).


Projektovanje modela podataka

Zašto više tabela i zašto veze između istih?

Table1

Vodomer Adresa broj Korisnik Datum1 Ocitavanje1 Datum2 Ocitavanje2

vod001 Bulevar Kralja Aleksandra

73 Gradj. Fakultet

01/01/2008 1250 31/01/2008 1550


71 Univerz.bibl. 01/01/2008 1100 31/01/2008 1325


69 Hotel Metropol

01/01/2008 1234 31/01/2008 1450


73 Gradj. Fakultet

31/01/2008 1550 28/02/2008 1750


71 Univerz.bibl. 31/01/2008 1325 28/02/2008 1485


69 Hotel Metropol

31/01/2008 1450 28/02/2008 1755



Faze u razvoju baze podataka

Potrebni podaci:

Intervjuisanje budućih

korisnika baze podataka

Analiza postojeće

dokumentacije

Način rada sistema pre uvođenja

baze podataka




Konceptualna šema objedinjuje

sve zahteve za podacima i tražene

formate podataka. U okviru razvoja

konceptualnog modela se rešava

problem redundantnih podataka.

Ovaj postupak se naziva

normalizacija.

Krajnji rezultat konceptualnog

modeliranja je model objekti-veze

(MOV) (engleski: Entity-

Relationship E-R model)




Konceptualna šema

Krajnji rezultat konceptualnog

modeliranja je model objekti-veze

(MOV) (engleski: Entity-

Relationship E-R model)

(Alati za projektovanje ERD-a:

Visio, VisualStudio Net, …)




Logički nivo: prevodjenje

konceptualnog modela na format

(jezik) koji je prepoznatljiv za SUBP.

CASE alati koji su vezani za određeni

DBMS ili korišćenjem DDL-a

Fizički nivo: faza implementacije.

Razvoj postupaka za efikasan pregled,

izmenu, brisanje i dodavanje podataka

u bazu.

Rešava se problem fizičkog smeštanja

podataka (server) i indeksiranja polja u

tabelama.

Table1



73 Gradj. Fakultet

01/01/2008 1250 31/01/2008 1550


71 Univerz.bibl. 01/01/2008 1100 31/01/2008 1325


69 Hotel Metropol

01/01/2008 1234 31/01/2008 1450


73 Gradj. Fakultet

31/01/2008 1550 28/02/2008 1750


71 Univerz.bibl. 31/01/2008 1325 28/02/2008 1485


69 Hotel Metropol

31/01/2008 1450 28/02/2008 1755



Osnovni elementi Modela Objekti Veze (MOV)

Objekti – stvarni ili apstraktni kojima se opisuje model (Korisnik,

Vodomer, Merenje)

Atributi vezani za objekte

Veze između objekata

o Korisnik priključen na Vodomer

o Merenje očitano na Vodomeru

Neformalno govoreći objekti odgovaraju imenicama a veze su

predstavljene glagolom u rečenici.

Table1



73 Gradj. Fakultet

01/01/2008 1250 31/01/2008 1550


71 Univerz.bibl. 01/01/2008 1100 31/01/2008 1325


69 Hotel Metropol

01/01/2008 1234 31/01/2008 1450


73 Gradj. Fakultet

31/01/2008 1550 28/02/2008 1750


71 Univerz.bibl. 31/01/2008 1325 28/02/2008 1485


69 Hotel Metropol

31/01/2008 1450 28/02/2008 1755



Šta treba da ispuni dobro projektovan model podataka?

1. Rešavanje problema izmene podataka u bazi

Primer: Dodaj novi Vodomer

Promena imena Korisnika

Brisanje Korisnika

2. Problem određivanje

funkcionalnih zavisnosti

između atributa u

relacijama.

Normalizacija je proces u kome se rešava problem redundantnih

podataka u bazi.

Table1



73 Gradj. Fakultet

01/01/2008 1250 31/01/2008 1550


71 Univerz.bibl. 01/01/2008 1100 31/01/2008 1325


69 Hotel Metropol

01/01/2008 1234 31/01/2008 1450


73 Gradj. Fakultet

31/01/2008 1550 28/02/2008 1750


71 Univerz.bibl. 31/01/2008 1325 28/02/2008 1485


69 Hotel Metropol

31/01/2008 1450 28/02/2008 1755



Neformalni koraci u formiranju MOV-a:

Prvi korak je provera ispunjenosti uslova atomnosti

(nedeljivosti) atributa u relaciji

Drugi korak je

funkcionalna dekompozicija

relacije u više manjih

relacija. Jednostavan

postupak je identifikacijom

“funkcionalno zavisnih”

atributa čije se vrednosti

ponavljaju.




Prethodni koraci u primeni

neformalnog postupka

normalizacije dovodi nas do

MOV-a koji je prikazan na

slici.

Primarni ključ

Spoljni ključ




Korak “dalje”

Potencijalni problemi:

• Ne postoji mogućnost da jedan

korisnik ima više vodomera.

• Dodavanje novog korisnika (zbog

“referencijalnog integriteta”, mora

biti poznato na koji će vodomer biti

priključen novi korisnik)




Korak “dalje”

Dodavanje veze “više na više”

dodavanjem nove tabele

tblVodomerKorisnik sa dva spoljna

ključa: VodomerID i KorisnikID



PRIMER:Projektovati bazu podataka u koju

će se smeštati rezultati merenja

nivoa podzemne vode u

pijezometrima. Merenja se

obavljaju ručno i sondama za

merenje apsolutnog ili

manometarskog pritiska. Sonde

imaju sopstvenu memoriju za

čuvanje podataka, koja se

povremeno očitava. Ručna merenja

se u proseku obavljaju jednom

nedeljno. Sonde mogu menjati

mesta merenja (pijezometre) ili biti

neaktivne (usled kvara) ili otpisane.



PRIMER:

Pijezometar Sonda Datum Vreme Pritisak (mbar) Komentar

P1 S1(d=15.5m) 05.11.2011 9:05 500 P1 S1(d=15.5m) 05.11.2011 10:05 505 P1 S1(d=15.5m) 05.11.2011 11:05 505 ….

P2 Rucno 6.11.2011 14:00 5.25 dubina do nivoa vode (m)

P3 Rucno 7.11.2011 14:00 4.15 dubina do nivoa vode (m) ….

P2 S2(d=12.5m) 10.11.2011 9:05 1530 Apsolutni pritisak


P2 S2(d=12.5m) 10.11.2011 11:05 1535 Apsolutni pritisak ….




Neorganizovan način čuvanja

podataka merenja bi mogao

izgledati kako je to prikazano u

narednoj tabeli..



PRIMER:

Pijezometar Sonda Datum Vreme Pritisak (mbar) Komentar

P1 S1(d=15.5m) 05.11.2011 9:05 500 P1 S1(d=15.5m) 05.11.2011 10:05 505 P1 S1(d=15.5m) 05.11.2011 11:05 505 ….

P2 Rucno 6.11.2011 14:00 5.25 dubina do nivoa vode (m)

P3 Rucno 7.11.2011 14:00 4.15 dubina do nivoa vode (m) ….



P2 S2(d=12.5m) 10.11.2011 11:05 1535 Apsolutni pritisak ….




Jedan pogrešan pokušaj:



PRIMER:Osnovni nedostatci pogrešnog

modela: 1. pijezometar je direktno

povezan sa sondom, 2. ne uzima u

obzir da se merenja obavljaju u

kampanjama.

Popravljen model

- u tabeli tblMerenja je dodato polje

PritisakID, kojim se definiše šta se

meri (npr. domen atributa PritisakID

bi mogao biti: "MAN", "APS" ili

"NIV")

- rezultati merenja su smešeteni u

posebnu tabelu tblRezultatMerenja.

- moguć je unos rezultata merenja

koja su obavljena ručno: ili bi se u

tabeli tblMerenja bi se polje

SondaID ostavljalo da bude NUL ili

bi se u tabelu tblSonda unela

fiktivna sonda.



PRIMER:

Opšteg modela podataka koji bi

odgovarao, čuvanju vremenskih

nizova izmerenih fizičkih

veličina, na različitim

lokacijama i sa različitim

uređajima.

tblJediniceFV

JedinicaMereID FizickaVelicinaID Name ConversionFactor

100 1 m 1

101 1 cm 0.01

102 1 mm 0.001

…

800 8 N/m2 1

801 8 kN/m2 1000

802 8 bar 100000

tblFizickaVelicina

ID Name

0 none

1 duzina

2 vreme

3 protok

…

8 pritisak

Documents

Hidroinformatika - University of Belgradehikom.grf.bg.ac.rs/.../1_HidroinformatikaBazepodataka-Uvod_2016.pdf · 1. BAZE PODATAKA - UVOD Zadaci SUBP-a Baza podataka se sastoji od jednog