3 Modeli podatkovnih zbirk

Transcription

Visokošolski študijski program Prometno inženirstvo
Stran 1
Prometna informatika:3_Podatkovne zbirke, Relacijske
3
3.1
Modeli podatkovnih zbirk
Tipi modelov podatkovnih zbirk
Ko opišemo (narišemo) podatkovni model, je naslednja pomembna odločitev, ki jo mora
sprejeti načrotvalec podatkovne zbirke:
Na kakšen način podatke shraniti oziroma kako organizirati zapisovanje podatkov?
Pri tem je ključno vprašanje dostopa do posameznega podatka oziroma navigacija po
podatkovni zbirki. V zgodovini računalništva in informatike so prve oblike organiziranega
zapisovanja podatkov bili tako imenovani datotečni sistemi.
Danes lahko govorimo o štirih tipih podatkovnih modelov oziroma o štirih tipih modelov
podatkovnih zbirk. Ti so:
-
hierarhični
-
mrežni
-
relacijski
-
objektno - orientirani
V hierarhičnih in mrežnih modelih je za iskanje podatka potrebno vedenje o fizični
organizaciji zgradbe podatkov.
V hierarhičnih modelih do posameznega podatka dostopamo po tako imenovani
drevesasti strukturi; od korenine po vseh vejah.
Primer hierarhičnega shranjevanja podatkov: skladišče rezervnih delov za vozilo.
V mrežnih modelih lahko sicer direktno dostopamo do nekega podatka; uporabnik mora
poznati tako imenovane kazalce oziroma ključe (tudi ključne besede). Kazaelc je v bistvu
podatek, ki omogoča izračunavanje lokacije nekega drugega podatka. Tak način je statičen.
Pri tem pristopu govorimo o seznamih (tudi listah), o zapisu (angleško record), o številki
zapisa ali vrstice; znotraj vrstice ali zapisa pa o poljih.
Primer: Princip kazalcev .
Diskutiraj: Kakšne vrste podatkovna zbirka je svetovni splet; kako dostopamo do dokumentov
(spletnih strani) ?
PI-3_PZvPrometu-Relacijske.doc
Stran 2
V relacijskem modelu zadostuje vedenje o logični strukturi podatkov, da bi do nekega
podatka prišli. Uporabnik zahteva “KAJ !” naj bo narejeno in ga ne zanima “KAKO?”.
Uporabnik mora poznati "logiko" podatkovne zbirke. Konkretno to pomeni, da mora
poznati ključe (identifikatorje) in pravila. Relacijski podatkovni model je prevladujoč v
praksi.
(Relacijski model je natančneje opisan v nadaljevanju)
V objektno usmerjenem modelu, izhajamo iz dejstva, da v stvarnem svetu “objekti”
obstajajo. Objekti realnega sveta, ki imajo točno določene lastnosti in izvajajo točno
določene funkcije, pripadajo točno določenemu razredu objektov. Vsi objekti enega
razreda imajo enako procesno obnašanje oz. funkcionalnost. Razredi so lahko urejeni v
hierarhije; posebnost je tudi lastnost dedovanja itd. Na tak način je omogočeno sestavljanje
hierarhičnih zgradb z definiranimi funkcionalnimi odnosi med objekti.
Stran 3
3.2
Osnove relacijskega modela podatkovne zbirke
Relacijski model podatkovne zbirke
Relacijski model podatkovne zbirke temelji na relacijski teoriji, izpeljani iz matematične
teorije množic, razviti pred več kot štiridesetimi leti in ima več kot trideset let “praktične
dobe”. Relacijski model podatkvne zbirke ima preprosto sestavo:
Sestavljajo ga samo dvorazsežne tabele. Tabele so sestavljene samo iz vrstic in
stolpcev.
Tabele relacijskega modela
Tabele relacijskega modela imajo tri osnovne lastnosti:
1. Niso dovoljeni pojavi dveh enakih vrstic, vrstni red vrstic ni pomemben.
2. Atributi oziroma stolpci v tabeli nimajo določenega vrstnega reda.
3. Shranjene vrednosti v posameznih podatkovnih poljih so samo atomarne..
Lastnosti 1 in 2 v praksi pomenita, da se informacija (pomen podatkov) ne izgubi, če
zamenjam vrstice v tabeli ali zamenjam vrstni red stolpcev.
Lastnost 3 pa pomeni, da z relacijskim modelom ni moč neposredno ustvarjati, na primer,
seznamov, pa tudi voznih redov in podobno.
Ta enostavna definicija (govorimo o enostavnosti in uniformnosti) je vzrok, da so relacijski
modeli daleč najbolj razširjeni. Po drugi strani ima ta enostavnost, predvsem zahteva po
atomarnih vrednostih v podatkovnih poljih, za posledico, da se nekaterih podatkovnih
struktur ne da enostavno zapisovati v takšnih tabelah!
Primer:
Kaj so atomarne vrednosti v poljih tabele ?
Katere pojave zapisujemo s seznami (listami, vrstami....) ?
Primeri:
Redovalnica
Potek osi ceste (geometrija oz. geografija)
Evidenca števila smrtnih žrtev v prometu (časovna vrsta)
Stran 4
Prikaz tabele:
− entitetni tip se (načeloma) prevede v eno tabelo;
− shema oziroma glava tabele je časovno načeloma nespremenljiva;
− podaljšek oziroma vsebina tabele so v bistvu vrstice (modifikacije oziroma
spremembe so „normalni pojav”);
− vrstice (entitete); predstavljajo fizično prisotnost posameznih entitet
− stolpci predstavljajo posamezne atribute,
− nastane podatkovno polje z lastnostjo atomarnosti (vanj ne smemo zapisovati
seznamov),
− vrednosti v poljih morajo biti v skladu z „domeno” oziroma definiranim
področjem dopustnih vrednosti za atribute.
entitetni tip:
seznam atributov:
ENTITETA ⇒
POSTAJE
Id_postaje
Ime
stolpec:
⇓
Potniki
2901
Maribor
23.000
⇐ Shema
tabele
⇐ Podaljšek
tabele
vrstica (tuple) ⇒
Gornja definicija praktično pomeni, da podatkovni model preslikamo (prevedemo) v
konkretnejšo obliko - v relacijsko podatkovno zbirko - tako, da praviloma:
- vsak entitetni tip postane ena tabela,
- vsak tip asociacije postane ena tabela,
- vsaka posamezna entiteta (ali asociacija) postane vrstica v tabeli,
- atribut postane stolpec v pripadajoči tabeli
Zgledi:
1. Mejni prehodi - evidenca potnikov
2. Predmeti in študijski program
3. Cestno omrežje (križišča in odseki)
Stran 5
3.3
Lastnosti relacijskega modela podatkovne zbirke
Učinkovitost, zanesljivost in splošno uporabnost relacijskega modela zagotavljajo naslednje
lastnosti in principi delovanja:
•
Primarni ključ (indeks, ID):
definicija: Je atribut oziroma skupina atributov, katere vrednost je edinstvena.
•
Tuji ključ:
definicija: Je atribut, ki je v neki drugi tabeli primarni ključ.
Posledica so soodvisni ključi. Le-ti omogočajo npr. spajanje tabel ipd.
•
Normalizacija podatkovne zgradbe - normalne forme. Te omogočajo, da so tabele
sestavljene tako, da se izognemo redundancam (ali kopičenju podatkov).
Redundance so nezaželen pojav, ki je vir napak in povečuje stroške vzdrževanja
podatkovne zbirke.
•
Integritetna pravila. Če upoštevamo zgoraj omenjene principe - pravimo, da smo
upoštevali integritetna pravila; reducirali smo možnosti podvajanja, nelogičnosti in
podobno.
•
Poizvedovanja (angl.: query). Do posameznih podatkov praviloma ne dostopamo
direktno, ampak opravljamo poizvedovanja. V ta namen uporabljamo:
o Poizvedovalni jezik. Uporablja se standardiziran jezik, imenovan SQL Structured Query Language). S pomočjo ukazov poizvedovalnega jezika
izvajamo predvsem:
•

spajanje tabel (angl.: join) na podlagi ujemanja soodvisnih ključev.

operacije relacijske algebre - operacije nad tabelami; rezultat
operacije nad tabelami so (ponovno) samo tabele !
Uporabniki do podatkov dostopajo preko vmesnikov:
o Uporabniški pogled (view). Uporabnikom podatkovne zbirke se pripravijo
vnaprej pripravljene vsebine.
o Obrazci (form). Uporabnikom s pooblastili za spreminjanje vsebine se
pripravijo obrazci za kontroliran vnos sprememb.
o Poročila (report). Uporabnikom podatkovne zbirke se pripravijo vnaprej
pripravljeni obrazci za poročanje o vsebini.
Stran 6
3.3.1
Primarni ključ in tuji ključ
Po definiciji je
•
Primarni ključ (indeks, ID) atribut oziroma skupina atributov, katere vrednost je
edinstvena.
•
Tuji ključ je atribut, ki je v neki drugi tabeli primarni ključ.
Posledica so soodvisni ključi, ki omogočajo spajanje tabel, iskanje, dinamično povezovanje
različnih podatkovnih baz in podobno.
Primeri:
Na cestnih odsekih imamo števna mesta. V nadaljevanju je prikazan primer.
Cestni odseki
ID
Opis
Dolžina
2056
5.230,500
Maribor-Počehova
Števna mesta
Številka
Opis
Odsek
Št.vozil
511
2056
16.200
Počehova
...
...
Na primerih zgoraj diskutiraj o ključih (identifikatorjih) o tujem ključu itd..
Stran 7
3.3.2
Normalne forme in (nezaželeno) kopičenje podatkov
Kopičenje podatkov
Redundanca (slovensko: kopičenje) imenujemo pojav, ko v podatkovni bazi isti podatek
(podatke) zapisujemo na dveh ali večih mestih! Redundantnosti (je “zlo”) se želimo v
podatkovnih bazah izogniti. Izvajanje postopka normalizacije je osnovni postopek, ki ga
izvajamo v izogib redundantnosti. Podatkovne baze, ki so organizirane v skladu s pravili
normalizacije in ne vsebujejo redundantnih podatkov, so praviloma stabilnejše (napake so
redke ali onemogočene!) in ne povzročajo nepotrebnih stroškov vzdrževanja. Omogočajo
tudi preprostejši razvoj ali širjenje podatkovne baze.
Normalne forme
Normalizacija je proces določitve tako imenovanih normalnih form. Normalne forma so
pravila, kako sestaviti glave tabel, upoštevajoč logične odvisnosti med atributi. Praktično to
pomeni, da razbijamo kompleksnejše in obsežnejše tabele na manjše in enostavnejše
(posledično obvladljivejše in bolj primerne za izvajanje operacij). Literatura o relacijskih
podatkovnih bazah pozna pet osnovnih oblik, imenovanih 1.normalna forma (1NF),
2.normalna forma (2NF), 3.normalna forma (3NF) itd... Vsaka višja je zahtevnejša in
strožja. V praksi se najpogosteje “ustavimo” pri tretji normalni formi:
Primeri:
− prva normalna forma; vrednost v poljih polj je atomarna (ni agregatov)
− druga normalna forma; ni delnih odvisnosti
− tretja normalna forma; ni posrednih odvisnosti
Stran 8
Primer: Postaje in Linije
Postaje
ID_Post
Ime
2001
2002
2003
2004
2005
2006
2007
Maribor
Maribor-STŠ
Maribor-Slavija
Maribor-Primorska
Bohova
Hoče-križišča
....
Linija
ID_Linije
Opis_poti
AAAA
2001, 2003, 2004, 2005
Tabela Linije ni v prvi normalni formi (1NF).
Pravilna relacijska oblika bi bila:
Linija
ID_Linije
Zap_št.
Postajališče
AAAA
AAAA
AAAA
AAAA
1
2
3
4
2001
2003
2004
2005
Primer Analiza poslovanja linije v javnem potniškem prometu
Je primer tabele, ko imamo delne odvisnosti (vrednost enega atributa je odvisna od vrednosti
drugih atributov):
LINIJA
Številka
Opis
Dolžina
Stroški
Potnik_km Prihodki
Donosnost ...
AA502
Počehova
32,500
16.200
140
-2.200
14.000
Atributa Stroški in Prihodki sta (sta lahko?) odvisna od atributov Dolžina in Potnik_km.
Atribut Donosnost je odvisen od stroškov in prihodkov (je torej redundanten podatek – tabela ni v
2NF!)
Stran 9
Primer zbiranja podatkov o postajah javnega potniškega prometa.
Postaje
ID_Post
Ime
Vrsta
Občina
Št.preb.
2001
2002
2002
Maribor
Maribor-STŠ
Maribor-Slavija
P
P
M
Maribor
Maribor
Maribor
180.000
180.000
180.000
...
Število prebivalcev je odvisno od občine in ne od postajališča (tabela ni v 3NF).
V skladu s pravili normalizacije, bi bila pravilnejša struktura:
Postaje
ID_Post
Ime
Vrsta
Občina
2001
2002
2002
Maribor
Maribor-STš
Maribor-Slavija
P
P
M
XXXX
XXXX
XXXX
Občine
ID
Ime
Št.preb.
...
XXXX
Maribor
180.000
...
Stran 10
3.3.3
Integritetna pravila
Integritetna pravila so tista pravila, ki zagotavljajo, da v relacijskih podatkovnih zbirkah
nimamo nelogičnih (“sumljivih”) podatkov. To so predvsem:
- Referenčna integriteta
- Kaskadno obnavljanje in
- Kaskadno brisanje
Do kakšne mere jih uveljavljamo, je odvisno predvsem od problema, ki ga obdelujemo.
Popolno (nekontrolirano) uveljavljanje integritetnih pravil lahko v praksi povzroči, na
primer, tudi nezaželeno brisanje pomembnih podatkov.
Zgled uveljavljanje integritetnih pravil:
Imamo dve tabeli Cestni odseki in Bencinski servisi:
Cestni_Odseki:
ID-odseka
Ime odseka
Dolžina
Primarni ključ v tej tabeli je “ID-odseka”
Bencinski_Servisi:
Ime_servisa Odsek
Lastnik
Primarni ključ v tej tabeli je Ime_servisa; tuji ključ pa Odsek
Tabeli napolnimo z naslednjimi vrsticami:
Cestni_Odseki:
ID-odseka
2001
2102
2105
2500
3001
Ime odseka
Maribor – Hoče
Hoče - Sl.Bistrica
Sl.Bistrica - Sl.Konjice
Sl.Konjice - Celje
Ljubljana - Postojna
Dolžina
12,3
15,5
14,9
20,1
35,1
Bencinski_Servisi:
Ime_servisa
Mb_1
Mb_2
Lopata_1
Odsek Lastnik
2001
Petrol
2001
Petrol
2105
OMV
Stran 11
Uveljavljamo naslednja pravila:
Bencinski_Servis lahko leži samo na obstoječem cestnem odseku. Na enem odseku je lahko
več bencinskih servisov. V tabeli Bencinski_Servisi naj bo v polje Odsek onemogočen vnos
neobstoječih vrednosti ID_odseka. Grafično se takšen odnos lahko prikaže na sledeč način
(grafični prikaz v orodju MS-Access):
Uveljavljanju takšnega pravila rečemo tudi, da zagotavljamo referenčno integriteto.
Vnos naslednje vrstice ni dopusten (!) :
Bencinski_Servisi:
Ime_servisa Odsek Lastnik
Koper
4200
Istrabenz
Če spremenim ID_Odseka, naj se avtomatsko spremeni tudi vrednost atributa Odsek v
tabeli Bencinski_Servisi. Uveljavljanju tega pravila rečemo tudi kaskadno obnavljanje:
Cestni_Odseki:
ID-odseka
9999
2102
2105
2500
3001
Ime odseka
Maribor – Hoče
Hoče - Sl.Bistrica
Sl.Konjice - Celje
Dolžina
12,3
15,5
14,9
20,1
35,1
Bencinski_Servisi:
Ime_servisa
Koper
Mb_1
Mb_2
Lopata_1
Odsek
3100
9999
9999
2105
Lastnik
Istrabenz
Petrol
Petrol
OMV
Stran 12
Če izbrišem vrstico v tabeli Cestni_Odseki, naj se avtomatsko izbrišejo tudi vrstice v tabeli.
Uvljavljanju tega pravila rečemo tudi kaskadno brisanje:
Cestni_Odseki:
ID-odseka
2102
2105
2500
3001
Ime odseka
Hoče - Sl.Bistrica
Sl.Konjice - Celje
Dolžina
15,5
14,9
20,1
35,1
Bencinski_Servisi:
Ime_servisa Odsek Lastnik
Koper
3001
Istrabenz
Lopata_1
2105
OMV
Stran 13
3.3.4
Operacije v relacijskih bazah podatkov
Poizvedovalni jezik
Razvil se je standardizirani (ISO) neproceduralen jezik, ki vsebuje vse postopke potrebne
za delo z relacijskimi podatkovnimi bazami: Structured Query Language – SQL (angl.
query ali slov. poizvedovanje), ki omogoča predvsem:
-
definiranje in spreminjanje strukture podatkov (angl.: Data Definition Language DDL)
-
manipulacije s podatki (angl.: Data Manipulation Language - DML):
-
modifikacije: vstavljanje, odstranitev, spreminjanje (funkcije oziroma ukazi: insert,
delete, update)
-
iskanja in poizvedovanja (funkcije oziroma ukazi: select)
-
nadzor dostopa do podatkov (angl.: Data Control Language - DCL)
Sodobni računalniški programi omogočajo uporabniku prijazno izvjanje funkcij in ukazov
poizvedovanja.
Relacijska algebra
S tabelami (relacijami) tudi „računamo“. Stroga matematična definicija operacij relacijske
algebre je relativno zahtevna in je v nadaljevanju ne bomo natančneje obravnavali. Ob tem
je treba še pripomniti, da računalniški programi za delo z bazami podatkov (RDBMS)
pogosto dopuščajo tudi takšne operacije, ki so strogo teoretično sporne.
Osnovne operacije med dvema tabelama so:
-
unija (pripajanje vrstic dveh kompatibilnih tabel)
-
razlika
-
projekcija (izbor stolpcev; funkcija oziroma ukaz select)
-
selekcija (tudi restrikcija; izbor vrstic: select ... where)
-
kartezični produkt (produkt je množica vseh kombinacij; select* from..)
-
stik oziroma spajanje (spajanje dveh - ali več - tabel s pogoji spajanja; select *
from, where); spajamo preko atributov, ki se morajo ujemati v tipu in obsegu
dopustnih vrednosti.
Dodatne zmožnosti so tako imenovane:
-
aritmetične operacije
-
statistične operacije
-
agregatne operacije
Stran 14
Primeri osnovnih operacij:
Enakovrednostno spajanje (angleško "equi-join" tudi “naravni stik”, "pripojitev")
Primer: Cestni odseki in Bencinski servisi
Cestni_Odseki:
ID-odseka
2001
2102
2105
2500
3001
Ime odseka
Maribor – Hoče
Hoče - Sl.Bistrica
Sl.Konjice - Celje
Bencinski_Servisi:
Dolžina
12,3
15,5
14,9
20,1
35,1
Ime_servisa
Koper
Mb_1
Mb_2
Lopata_1
Odsek
4200
2001
2001
2105
Lastnik
Istrabenz
Petrol
Petrol
OMV
V tabeli Cestni_Odseki je atribut Id_odseka primarni ključ. V tabeli Bencinski_Servisi je
atribut Ime_Servisa primarni ključ, atribut Odsek pa tuji ključ .
Enakovrednostno spajanje preko sovisnih ključev, da sledeč rezultat:
Id_odseka
Ime odseka
2001
Maribor - Hoče
2001
Maribor - Hoče
2105
Dolžina
12,3
12,3
14,9
Ime_servisa
Mb_1
Mb_2
Lopata_1
Lastnik
Petrol
Petrol
OMV
Pripajanje (ni pravo spajanje; pa vendar se intenzivno uporablja)
Ukaz “k tabeli Cestni_odseki pripoji tabelo Bencinski_servisi; povezovalna atributa sta
Id_odseka in Odsek” (takšni ukazi so praviloma na voljo v komercialnih programih), da
sledeč rezultat:
Id_odseka
Ime odseka
2001
Maribor - Hoče
2001
Maribor - Hoče
2102
Hoče - Sl.Bistrica
Dolžina Ime_servisa Lastnik
12,3 Mb_2
Petrol
12,3 Mb_1
Petrol
15,5
2105
3001
14,9 Lopata_1
35,1
2500
Sl.Konjice - Celje
20,1
OMV
Stran 15
Ukaz “k tabeli Bencinski_servisi pripoji tabelo Cestni_odseki; povezovalna atributa sta
Odsek in Id_odseka” pa da sledeč rezultat:
Id_odseka
Ime odseka
2001
Maribor - Hoče
2001
Maribor - Hoče
2105
Dolžina
12,3
12,3
14,9
Ime_servisa
Mb_1
Mb_2
Lopata_1
Koper
Lastnik
Petrol
Petrol
OMV
Istrabenz
Kartezični produkt dveh tabel
Primer: Študenti in Predmeti
Stran 16
3.4
Sklep
Izhajajoč iz sheme postopka načrtovanja podatkovne zbirke lahko ugotovimo, da smo v tem
poglavju opredelili oziroma spoznali tiste pojme, ki omogočajo izdelavo logičnega modela
podatkovne zbirke (točka 3.):
1. analiza problema (identifikacija objektov, razredov objektov itd. ....)
2. konceptualni podatkovni model (definicija entitet, odnosi med entitetami, lastnosti
entitet itd.)
3. logični podatkovni model (izbor modela podatkovne baze; n.pr. tabele, vrstice in
stolpci; določitev imen tabel, imen tipov in domen za atribute; realizacija
integritetnih pravil itd.)
4. fizična implementacija (izbor sistema za upravljanje s PB; n.pr. ustvarjanje PB s
pomočjo orodja ORACLE ali MS-ACCESS ipd.)
5. eksploatacija, vzdrževanje
Primeri za vajo:
Na primerih praktično prikaži celoten postopek načrtovanja relacijske podatkovne baze.
1. Evidenca študenta o svojih izpitih
2. Cestni odseki in Števna mesta
3. Primer voznoredne podatkovne baze

3 Modeli podatkovnih zbirk

Transcription

Similar documents

N TYS PR

katalog-hibridnih-vozil - Toyota Center Ljubljana

nov, inovativen magistrski študijski program zdravstvene vede na

cenik storitev visoke šole za zdravstvene vede slovenj gradec za

Vabilo in prijavnica - Skupnost vrtcev Slovenije

Življenjepis Ingrid Kocjančič

RAČUNALNIŠKO PROGRAMIRANJE IN PODATKOVNE BAZE

Podatkovne baze

NOVOSTI na področju tujih jezikov (pdf)

višja strokovna šola

Letni delovni nacrt AP za leto 2014

KAZALO VSEBINE - Akademija za ples

tukaj - Fizioterapevtika

Skupščina je potrdila letno poročilo in izvolila nov UO

Spoštovani! Pred vami je razpis za vpis v magistrske