Pojava računalne tehnologije u našojmodernost je obilježila informacijsku revoluciju u svim sferama ljudskog djelovanja. No, kako bi se spriječilo da sve informacije postanu nepotrebno smeće na globalnom Internetu, izumljen je sustav baza podataka u kojem se materijali sortiraju, sistematiziraju, a kao rezultat toga mogu se lako pronaći i predstaviti za naknadnu obradu. Tri su glavne vrste - relacijske baze podataka, hijerarhijske, mrežne.
Vratimo se podrijetlu baza podataka, vrijedireći da je ovaj proces bio prilično složen, potječe s razvojem programabilne opreme za obradu informacija. Stoga ne čudi da broj njihovih modela u ovom trenutku doseže više od 50, no glavnima se smatraju hijerarhijski, relacijski i mrežni, koji se još uvijek široko koriste u praksi. Što su oni?
Hijerarhijska baza podataka ima stablostrukturu i sastoji se od podataka različitih razina, između kojih postoje veze. DB mrežni model složeniji je obrazac. Njegova struktura nalikuje hijerarhijskoj, a shema se proširuje i poboljšava. Razlika je u tome što nasljedni podaci hijerarhijskog modela mogu imati vezu samo s jednim pretkom, dok mrežni podaci mogu imati nekoliko. Struktura relacijske baze podataka mnogo je složenija. Stoga bi ga trebalo detaljnije analizirati.
Ovaj je model razvijen 1970-ih.Edgar Codd, doktor znanosti. To je logički strukturirana tablica s poljima koja opisuju podatke, međusobne odnose, radnje izvršene na njima i najvažnije, pravila koja jamče njihovu cjelovitost. Zašto se model naziva relacijskim? Temelji se na odnosima (od lat. Relatio) između podataka. Postoje mnoge definicije za ovu vrstu baze podataka. Relacijske tablice s informacijama mnogo je lakše organizirati i obraditi nego u mrežnom ili hijerarhijskom modelu. Kako se to može učiniti? Dovoljno je poznavati značajke, strukturu modela i svojstva relacijskih tablica.
Da biste stvorili vlastiti DBMS, trebali bistekoristite jedan od alata za modeliranje, razmislite s kojim informacijama trebate raditi, dizajnirajte tablice i relacijske pojedinačne i višestruke odnose između podataka, popunite ćelije entiteta i postavite primarne, strane ključeve.
Modeliranje stolova i relacijski dizajnbaze podataka proizvode se putem besplatnih alata kao što su Workbench, PhpMyAdmin, Case Studio, dbForge Studio. Nakon detaljnog dizajna, trebali biste spremiti grafički spreman relacijski model i prevesti ga u gotov SQL kod. U ovoj fazi možete započeti rad sa sortiranjem, obradom i sistematizacijom podataka.
Svaki izvor opisuje svoje elemente na svoj način, pa bih radi manje zabune želio dati mali savjet:
Da biste došli do svojstava relacijske baze podataka, morate znati od kojih se osnovnih komponenata sastoji i čemu služe.
Sada, znajući sastavne elemente tablice, možete prijeći na svojstva relacijskog modela baze podataka:
Na temelju svojstava relacijskog DBMS-a, jasno je da vrijednosti atributa moraju biti iste vrste i duljine. Razmotrimo značajke vrijednosti atributa.
Imena polja moraju biti jedinstvenajedan entitet. Relacijski atribut baze podataka ili tipovi polja opisuju koje su kategorije kategorije pohranjene u poljima entiteta. Polje relacijske baze podataka mora imati fiksnu veličinu u znakovima. Parametri i format vrijednosti atributa određuju kako će se podaci ispravljati u njima. Postoji i stvar poput "maske" ili "uzorka unosa". Namijenjen je definiranju konfiguracije unosa podataka u vrijednost atributa. Nužno je da se poruka greške izda kada pišete pogrešan tip podataka u polje. Također, određena su ograničenja na elemente polja - uvjeti za provjeru točnosti i unos podataka bez pogrešaka. Postoji neka potrebna vrijednost atributa koja mora biti jednoznačno popunjena podacima. Neki se nizovi atributa mogu ispuniti NULL vrijednostima. U atribute polja dopušteno je unositi prazne podatke. Kao i obavijest o pogrešci, postoje vrijednosti koje sustav automatski popunjava - ovo su zadani podaci. Indeksirano polje namijenjeno je ubrzanju pretraživanja bilo kojih podataka.
| Naziv atributa 1 | Naziv atributa 2 | Naziv atributa 3 | Naziv atributa 4 | Naziv atributa 5 |
| Stavka_1_1 | Stavka_1_2 | Stavka_1_3 | Stavka_1_4 | Stavka_1_5 |
| Stavka_2_1 | Stavka_2_2 | Stavka_2_3 | Stavka_2_4 | Stavka_2_5 |
| Stavka_3_1 | Stavka_3_2 | Stavka_3_3 | Stavka_3_4 | Stavka_3_5 |
Za detaljno razumijevanje sustava upravljanjaModeli koji koriste SQL, shemu najbolje mogu pogledati primjerom. Već znamo što je relacijska baza podataka. Zapis u svakoj tablici je jedna stavka podataka. Da bi se spriječila suvišnost podataka, potrebno je izvršiti operacije normalizacije.
1. Vrijednost imena polja za relacijsku tablicu mora biti jedinstvena, jedinstvena (prvi normalni obrazac je 1NF).
2. Za tablicu koja je već smanjena na 1NF, naziv bilo kojeg neidentificirajućeg stupca mora ovisiti o jedinstvenom identifikatoru tablice (2NF).
3. Za cijelu tablicu koja je već u 2NF, svako neidentificirajuće polje ne može ovisiti o elementu druge neprepoznate vrijednosti (entitet 3NF).
Postoje 2 glavne vrste odnosa relacijske tablice:
Primarni i sekundarni ključevi definirajupotencijalni odnosi baze podataka. Relacijske veze podatkovnog modela mogu imati samo jedan potencijalni ključ, to će biti primarni ključ. Kakav je on? Primarni ključ je stupac entiteta ili skup atributa koji vam omogućuju pristup podacima za određeni redak. Mora biti jedinstven, jedinstven i njegova polja ne mogu sadržavati prazne vrijednosti. Ako se primarni ključ sastoji samo od jednog atributa, tada se naziva jednostavnim, inače će biti komponenta.
Uz primarni ključ, postoji i vanjski(strani kljuc). Mnogi ne razumiju u čemu je razlika među njima. Pogledajmo ih detaljnije na primjeru. Dakle, postoje 2 tablice: "Dekanat" i "Studenti". Entitet "Dekanat" sadrži polja: "Student ID", "Full name" i "Group". Tablica "Studenti" ima vrijednosti atributa kao što su "Ime", "Grupa" i "Prosjek". Budući da studentski ID ne može biti isti za više učenika, ovo će polje biti primarni ključ. "Puno ime" i "Grupa" iz tablice "Studenti" mogu biti jednaki za nekoliko osoba, pozivaju se na matični broj studenta iz entiteta "Dekanat", stoga se mogu koristiti kao strani ključ.
Radi jasnoće dat ćemo jednostavan primjer relacijskog modela baze podataka koji se sastoji od dva entiteta. Postoji tablica pod nazivom "Dekanat".
Suština "Dekanat" | ||
studentska iskaznica | Puno ime | grupa |
111 | Ivanov Oleg Petrovič | IN-41 |
222 | Ilja Lazarev | IN-72 |
333 | Konoplev Petr Vasilievich | IN-41 |
444 | Kušnereva Natalija Igorevna | IN-72 |
Trebate uspostaviti veze da biste dobilipunopravna relacijska baza podataka. Zapis "IN-41", poput "IN-72", može biti prisutan više puta na pločici "Dekanat", a prezime, ime i prezime studenta u rijetkim slučajevima mogu se podudarati, pa se ta polja ne mogu napravio primarni ključ. Pokažimo entitet "Studenti".
Tablica "Studenti" | |||
Puno ime | grupa | Prosjek bodova | Broj telefona |
Ivanov Oleg Petrovič | IN-41 | 3,0 | 2-27-36 |
Ilja Lazarev | IN-72 | 3,8 | 2-36-82 |
Konoplev Petr Vasilievich | IN-41 | 3,9 | 2-54-78 |
Kušnereva Natalija Igorevna | IN-72 | 4,7 | 2-65-25 |
Kao što vidimo, vrste polja u relacijskim bazama podatakapotpuno drukčije. Postoje i digitalni i simbolički unosi. Stoga bi vrijednosti cjelobrojnih vrijednosti, char, vachar, datum i druge trebale biti navedene u postavkama atributa. U tablici "Dekanat" jedinstvena je vrijednost samo studentska iskaznica. Ovo se polje može uzeti kao primarni ključ. Puno ime, grupa i telefonski broj entiteta "Studenti" mogu se uzeti kao strani ključ koji se odnosi na studentsku iskaznicu. Veza je uspostavljena. Ovo je primjer modela odnosa jedan-na-jedan. Hipotetski je jedna od tablica suvišna, lako se mogu kombinirati u jedan entitet. Da bi se spriječilo da studentski brojevi postanu općepoznati, postojanje dvije tablice sasvim je realno.
