Важно

Prevod je zajednički napor možete se pridružiti. Ova stranica je trenutno prevedena na 100.00%.

15.1. Lekcija: Uvod u baze podataka

Pre nego što počnemo sa PostgreSQL-om, utvrdimo osnove kroz opštu teoriju baza podataka. Nećete morati da unosite nijedan primer koda; on je tu samo radi ilustracije.

Cilj ove lekcije: Razumevanje osnovnih pojmova baza podataka.

15.1.1. Šta je baza podataka?

Baza podataka sastoji se od organizovane zbirke podataka za jednu ili više namena, obično u digitalnom obliku. - Vikipedija

Sistem za upravljanje bazom podataka (DBMS) sastoji se od softvera koji upravlja bazama podataka, obezbeđujući skladištenje, pristup, bezbednost, rezervne kopije i druge mogućnosti. - Vikipedija

15.1.2. Tabele

U relacionim bazama podataka i bazama podataka sa ravnim datotekama, tabela je skup elemenata podataka (vrednosti) organizovan po modelu vertikalnih kolona (koje se prepoznaju po nazivu) i horizontalnih redova. Tabela ima zadati broj kolona, ali može imati bilo koji broj redova. Svaki red se identifikuje vrednostima koje se pojavljuju u određenom podskupu kolona koji je označen kao kandidat za ključ. - Vikipedija

 id | name  | age
----+-------+-----
  1 | Tim   |  20
  2 | Horst |  88
(2 rows)

U SQL bazama podataka tabela je poznata i kao relacija.

15.1.3. Kolone / polja

Kolona je skup vrednosti podataka određenog prostog tipa, po jedna za svaki red tabele. Kolone daju strukturu prema kojoj se redovi sastavljaju. Termin polje često se koristi kao sinonim za kolonu, iako mnogi smatraju ispravnijim da se polje (ili vrednost polja) odnosi konkretno na jednu stavku koja postoji na preseku jednog reda i jedne kolone. - Vikipedija

Kolona:

| name  |
+-------+
| Tim   |
| Horst |

Polje:

| Horst |

15.1.4. Zapisi

Zapis je informacija sačuvana u redu tabele. Svaki zapis imaće polje za svaku kolonu u tabeli.

2 | Horst |  88  <-- one record

15.1.5. Tipovi podataka

Tipovi podataka ograničavaju vrstu informacija koje se mogu sačuvati u koloni. - Tim i Horst

Postoji mnogo vrsta tipova podataka. Usredsredimo se na najčešće:

• String - za čuvanje slobodnog teksta

• Integer - za čuvanje celih brojeva

• Real - za čuvanje decimalnih brojeva

• Date - za čuvanje Horstovog rođendana, da niko ne zaboravi

• Boolean - za čuvanje prostih tačno/netačno vrednosti

Bazi podataka možete zadati da vam dozvoli i da u polje ne sačuvate ništa. Ako u polju nema ničega, sadržaj polja se naziva „null“ vrednost:

insert into person (age) values (40);

select * from person;

Rezultat:

id | name  | age
---+-------+-----
 1 | Tim   |  20
 2 | Horst |  88
 4 |       |  40  <-- null for name
(3 rows)

Postoji još mnogo tipova podataka koje možete koristiti - pogledajte PostgreSQL priručnik!

15.1.6. Modelovanje baze podataka adresa

Poslužimo se jednostavnom studijom slučaja da vidimo kako se baza podataka gradi. Želimo da napravimo bazu podataka adresa.

★☆☆ Probajte sami:

Zapišite svojstva koja čine jednostavnu adresu i koja bismo želeli da sačuvamo u našoj bazi podataka.

Odgovor

Za našu teorijsku tabelu adresa, možda bismo želeli da sačuvamo sledeća svojstva:

House Number
Street Name
Suburb Name
City Name
Postcode
Country

Pri pravljenju tabele koja predstavlja objekat adrese, napravili bismo kolone koje predstavljaju svako od ovih svojstava i dali bismo im nazive u skladu sa SQL-om, po mogućstvu skraćene:

house_number
street_name
suburb
city
postcode
country

Struktura adrese

Svojstva koja opisuju adresu su kolone. Vrsta informacija sačuvanih u svakoj koloni je njen tip podataka. U sledećem odeljku analiziraćemo našu konceptualnu tabelu adresa da vidimo kako je možemo poboljšati!

15.1.7. Teorija baza podataka

Proces pravljenja baze podataka podrazumeva pravljenje modela stvarnog sveta; uzimanje pojmova iz stvarnog sveta i njihovo predstavljanje u bazi podataka kao entiteta.

15.1.8. Normalizacija

Jedna od glavnih ideja u bazi podataka jeste izbegavanje dupliranja / redundanse podataka. Proces uklanjanja redundanse iz baze podataka naziva se normalizacija.

Normalizacija je sistematičan način da se obezbedi da struktura baze podataka bude pogodna za upite opšte namene i bez određenih nepoželjnih osobina - anomalija pri umetanju, ažuriranju i brisanju - koje bi mogle dovesti do gubitka integriteta podataka. - Vikipedija

Postoje različite „normalne forme“ normalizacije.

Pogledajmo jednostavan primer:

Table "public.people"

Column    |          Type          |                Modifiers
----------+------------------------+------------------------------------
 id       | integer                | not null default
          |                        | nextval('people_id_seq'::regclass)
          |                        |
 name     | character varying(50)  |
 address  | character varying(200) | not null
 phone_no | character varying      |
Indexes:
 "people_pkey" PRIMARY KEY, btree (id)

select * from people;

id |     name      |           address           |  phone_no
---+---------------+-----------------------------+-------------
 1 | Tim Sutton    | 3 Buirski Plein, Swellendam | 071 123 123
 2 | Horst Duester | 4 Avenue du Roix, Geneva    | 072 121 122
(2 rows)

Zamislite da imate mnogo prijatelja sa istim nazivom ulice ili istim gradom. Svaki put kada se ti podaci dupliraju, troši se prostor. Još gore, ako se naziv grada promeni, moraćete mnogo da radite da ažurirate svoju bazu podataka.

15.1.9. ★☆☆ Probajte sami:

Redizajnirajte gornju teorijsku tabelu people da biste smanjili dupliranje i normalizovali strukturu podataka.

Više o normalizaciji baza podataka možete pročitati ovde

Odgovor

Glavni problem sa tabelom people jeste to što postoji jedno polje adrese koje sadrži celu adresu osobe. Razmišljajući o našoj teorijskoj tabeli address ranije u ovoj lekciji, znamo da se adresa sastoji od mnogo različitih svojstava. Čuvanjem svih tih svojstava u jednom polju mnogo otežavamo ažuriranje i postavljanje upita nad našim podacima. Zbog toga polje adrese moramo podeliti na različita svojstva. To bi nam dalo tabelu sledeće strukture:

id |     name      | house_no |  street_name   |    city    |   phone_no
 --+---------------+----------+----------------+------------+-----------------
 1 | Tim Sutton    |     3    | Buirski Plein  | Swellendam | 071 123 123
 2 | Horst Duester |     4    | Avenue du Roix | Geneva     | 072 121 122

U sledećem odeljku učićete o vezama stranih ključeva, koje bi se u ovom primeru mogle iskoristiti za dalje poboljšanje strukture naše baze podataka.

15.1.10. Indeksi

Indeks baze podataka je struktura podataka koja povećava brzinu preuzimanja podataka iz tabele baze podataka. - Vikipedija

Zamislite da čitate udžbenik i tražite objašnjenje nekog pojma - a udžbenik nema indeks! Moraćete da počnete od korica i pređete celu knjigu dok ne nađete informaciju koja vam treba. Indeks na kraju knjige pomaže vam da brzo skočite na stranicu sa odgovarajućom informacijom:

create index person_name_idx on people (name);

Sada će pretrage po nazivu biti brže:

Table "public.people"

Column   |          Type          |               Modifiers
----------+------------------------+-------------------------------------
 id       | integer                | not null default
          |                        | nextval('people_id_seq'::regclass)
          |                        |
 name     | character varying(50)  |
 address  | character varying(200) | not null
 phone_no | character varying      |
Indexes:
 "people_pkey" PRIMARY KEY, btree (id)
 "person_name_idx" btree (name)

15.1.11. Sekvence

Sekvenca je generator jedinstvenih brojeva. Obično se koristi za pravljenje jedinstvenog identifikatora za kolonu u tabeli.

U ovom primeru, id je sekvenca - broj se uvećava svaki put kada se u tabelu doda zapis:

id |     name     |           address           |  phone_no
---+--------------+-----------------------------+-------------
 1 | Tim Sutton   | 3 Buirski Plein, Swellendam | 071 123 123
 2 | Horst Duster | 4 Avenue du Roix, Geneva    | 072 121 122

15.1.12. Dijagram entiteta i veza

U normalizovanoj bazi podataka obično imate mnogo relacija (tabela). Dijagram entiteta i veza (ER dijagram) koristi se za projektovanje logičkih zavisnosti između relacija. Razmotrite našu nenormalizovanu tabelu people iz ranijeg dela lekcije:

select * from people;

 id |     name     |           address           |  phone_no
----+--------------+-----------------------------+-------------
 1  | Tim Sutton   | 3 Buirski Plein, Swellendam | 071 123 123
 2  | Horst Duster | 4 Avenue du Roix, Geneva    | 072 121 122
(2 rows)

Uz malo rada možemo je podeliti na dve tabele, čime uklanjamo potrebu da se naziv ulice ponavlja za osobe koje žive u istoj ulici:

select * from streets;

 id |     name
----+--------------
 1  | Plein Street
(1 row)

i:

select * from people;

 id |     name     | house_no | street_id |  phone_no
----+--------------+----------+-----------+-------------
  1 | Horst Duster |        4 |         1 | 072 121 122
(1 row)

Zatim možemo povezati dve tabele pomoću „ključeva“ streets.id i people.streets_id.

Ako nacrtamo ER dijagram za ove dve tabele, izgledao bi otprilike ovako:

ER dijagram nam pomaže da izrazimo veze „jedan prema više“. U ovom slučaju simbol strelice pokazuje da jedna ulica može imati mnogo stanovnika.

★★☆ Probajte sami:

Naš model people i dalje ima problema sa normalizacijom - pokušajte da ga dodatno normalizujete i prikažite svoja razmišljanja pomoću ER dijagrama.

Odgovor

Naša tabela people trenutno izgleda ovako:

id |     name     | house_no | street_id |  phone_no
---+--------------+----------+-----------+-------------
 1 | Horst Duster |        4 |         1 | 072 121 122

Kolona street_id predstavlja vezu „jedan prema više“ između objekta people i pripadajućeg objekta street, koji se nalazi u tabeli streets.

Jedan način dalje normalizacije tabele jeste deljenje polja name na first_name i last_name:

id | first_name | last_name  | house_no | street_id |  phone_no
---+------------+------------+----------+-----------+------------
 1 |    Horst   |   Duster   |     4    |     1     | 072 121 122

Možemo napraviti i zasebne tabele za naziv mesta ili grada i za državu, povezujući ih sa našom tabelom people vezama „jedan prema više“:

id | first_name | last_name | house_no | street_id | town_id | country_id
---+------------+-----------+----------+-----------+---------+------------
 1 |    Horst   |   Duster  |     4    |     1     |    2    |     1

ER dijagram koji ovo predstavlja izgledao bi ovako:

15.1.13. Ograničenja, primarni i strani ključevi

Ograničenje baze podataka koristi se da bi se obezbedilo da podaci u relaciji odgovaraju načinu na koji projektant modela smatra da ti podaci treba da budu sačuvani. Na primer, ograničenje na poštanskom broju moglo bi da obezbedi da broj bude između 1000 i 9999.

Primarni ključ je jedna ili više vrednosti polja koje čine zapis jedinstvenim. Obično se primarni ključ zove id i predstavlja sekvencu.

Strani ključ se koristi za upućivanje na jedinstven zapis u drugoj tabeli (pomoću primarnog ključa te druge tabele).

U ER dijagramima, veza između tabela obično se zasniva na stranim ključevima koji upućuju na primarne ključeve.

Ako pogledamo naš primer people, definicija tabele pokazuje da je kolona street strani ključ koji upućuje na primarni ključ u tabeli streets:

Table "public.people"

 Column    |         Type          |  Modifiers
-----------+-----------------------+--------------------------------------
 id        | integer               | not null default
           |                       | nextval('people_id_seq'::regclass)
 name      | character varying(50) |
 house_no  | integer               | not null
 street_id | integer               | not null
 phone_no  | character varying     |
Indexes:
"people_pkey" PRIMARY KEY, btree (id)
Foreign-key constraints:
"people_street_id_fkey" FOREIGN KEY (street_id) REFERENCES streets(id)

15.1.14. Transakcije

Pri dodavanju, menjanju ili brisanju podataka u bazi podataka uvek je važno da baza ostane u dobrom stanju ako nešto pođe naopako. Većina baza podataka nudi mogućnost koja se zove podrška za transakcije. Transakcije vam omogućavaju da napravite tačku za vraćanje na koju se možete vratiti ako se vaše izmene baze podataka nisu odvijale prema planu.

Zamislite scenario u kojem imate računovodstveni sistem. Potrebno je da prenesete sredstva sa jednog računa i dodate ih na drugi. Redosled koraka bio bi ovakav:

• skini R20 sa Džoovog računa

• dodaj R20 na Anin račun

Ako nešto pođe naopako tokom procesa (npr. nestanak struje), transakcija će biti vraćena na prethodno stanje.

15.1.15. Zaključak

Baze podataka omogućavaju vam da podacima upravljate na strukturiran način pomoću jednostavnih kodnih struktura.

15.1.16. Šta je sledeće?

Sada kada smo videli kako baze podataka rade u teoriji, napravimo novu bazu podataka da bismo primenili teoriju koju smo obradili.