Baze podataka su relacijske. Koncept relacijske baze podataka

Pojavom računalne tehnologije u našemModernost je obilježila informacijsku revoluciju u svim sferama ljudske aktivnosti. No, kako bi se osiguralo da sve informacije ne postanu nepotrebne smeće na globalnom internetu, izumio je sustav baze podataka u kojem se materijali razvrstavaju i sistematiziraju kako bi se lako pronašli i podvrgnuli naknadnoj obradi. Postoje tri glavne vrste - alocirajte baze podataka relacijske, hijerarhijske, mreže.

Temeljni modeli

Povrat na stvaranje baza podataka vrijedireći da je taj proces bio prilično složen, počinje razvojem programabilne opreme za obradu informacija. Stoga ne čudi da broj njihovih modela u ovom trenutku doseže više od 50, ali glavni su hijerarhijski, relacijski i mrežni, koji su i dalje široko korišteni u praksi. Što su oni?

Hijerarhijska baza ima stablostruktura i sastavlja se od podataka različitih razina, između kojih postoje linkovi. Mrežni model baze podataka složeniji je predložak. Njezina struktura sliči hijerarhijskoj strukturi, a shema se proširuje i profinjenom. Razlika između njih je da se nasljedni podaci hijerarhijskog modela mogu povezati samo s jednim predakom, a mreža može imati nekoliko. Struktura relacijske baze podataka je mnogo složenija. Stoga treba detaljnije razgraditi.

Osnovni koncept relacijske baze podataka

Ovaj je model razvijen u 1970-imadoktor znanosti Edgar Codd. To je logički strukturirana tablica s područjima koja opisuju podatke, njihove međusobne veze, operacije koje se obavljaju na njima i, najvažnije, pravila koja jamče njihov integritet. Zašto se model naziva relacijskim? Temelji se na odnosima (od latinske relatio) između podataka. Postoji mnogo definicija ove vrste baze podataka. Relacijske tablice s informacijama mnogo su lakše organizirati i dati obradu nego u mreži ili hijerarhijskom modelu. Kako se to može učiniti? Dovoljno je znati značajke, strukturu modela i svojstva relacijskih tablica.

Proces modeliranja i sastavljanja osnovnih elemenata

Da biste izradili vlastiti DBMS, trebali bisteupotrijebite jedan od alata za modeliranje, razmislite o tome koje informacije trebate raditi, dizajnerskim tablicama i relacijskim jednodijelnim i višestrukim vezama između podataka, ispunite ćelije entiteta i uspostavite primarne, strane ključeve.

Modeliranje tablica i projektiranje relacijskihbaze podataka se vrše 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 završni SQL kôd. U ovoj fazi možete početi raditi s sortiranjem, obradom i sistematizacijom podataka.

Značajke, struktura i pojmovi povezani s relacijskim modelom

Svaki izvor opisuje svoje elemente na svoj način, tako da bih, radi manje zbunjenosti, želio dati mali trag:

relacijska ploča = entitet;
layout = atribute = nazivi polja = naziv stupaca entiteta;
entitet instance = tuple = record = redak oznake;
vrijednost atributa = entitetska ćelija = polje.

Da biste išli na svojstva relacijske baze podataka, trebali biste znati koje osnovne komponente čine i za što su namijenjene.

Esencija. Tablica relacijske baze podataka može biti jedna, a može biti čitav skup tablica koje karakteriziraju opisane objekte zahvaljujući pohranjenim podacima. Imaju fiksni broj polja i varijabilan broj zapisa. Tablica modela relacijske baze podataka sastoji se od redaka, atributa i izgleda.
Zapis je promjenjivi broj redaka koji predstavljaju podatke koji karakteriziraju opisani objekt. Sustav bilježi zapise automatski.
Atributi su podaci koji prikazuju opis stupaca entiteta.
Polje. Predstavlja entitetski stupac. Njihov broj je fiksna vrijednost koja je postavljena u trenutku kreiranja ili promjene tablice.

Sada, znajući konstitutivne elemente tablice, možete ići na svojstva baze podataka relacijskog modela:

Subjekti relacijskog DB su dvodimenzionalni. Zbog ove imovine s njima, lako je obavljati razne logičke i matematičke operacije.
Redoslijed vrijednosti atributa i zapisa u relacijskoj tablici može biti proizvoljan.
Stupac unutar jednog relacijskog stola mora imati vlastiti pojedinačni naziv.
Svi podaci u stupcu entiteta imaju fiksnu duljinu i isti tip.
Bilo koji zapis u biti se smatra jednim elementom podataka.
Konstitutivne komponente linija jedinstvene su u njihovoj vrsti. U relacijskom entitetu nema identičnih redaka.

Na temelju svojstava relacijskog DBMS-a, jasno je da vrijednosti atributa moraju biti iste vrste, duljine. Razmotrimo značajke vrijednosti atributa.

Glavne značajke polja relacijskih baza podataka

Nazivi polja moraju biti jedinstveni u okvirujedna suština. Vrste atributa ili polja relacijske baze podataka opisuju koja je kategorija podataka pohranjena u polju entiteta. Polje relacijske baze podataka mora imati fiksnu veličinu koja se broji u znakovima. Parametri i format atributnih vrijednosti određuju način na koji ispravljaju podatke. I dalje postoji takav koncept, kao "maska" ili "predložak ulaza". Namjera je definirati konfiguraciju unosa podataka u vrijednost atributa. Nužno mora primiti obavijest o pogrešci kada pogrešan tip podataka u snimanje. Također, određena su ograničenja na elementima polja - uvjeti za provjeru točnosti i točnosti unosa podataka. Postoji neka obvezna vrijednost atributa koja mora biti jedinstveno popunjena podacima. Neke linije atributa mogu se ispuniti NULL vrijednostima. Dopuštena je unos praznih podataka u polje atributa. Kao i obavijest o pogrešci, postoje vrijednosti koje sustav automatski popunjava - to su zadani podaci. Da bi se ubrzao traženje bilo kakvih podataka, namijenjeno je indeksirano polje.

Dvodimenzionalna shema tablice relacijske baze podataka

Shema relacijske baze podataka
Naziv atributa 1	Naziv atributa 2	Naziv atributa 3	Naziv atributa 4	Naziv atributa 5
Element_1_1	Element_1_2	Element_1_3	Element_1_4	Element_1_5
Element_2_1	Element_2_2	Element_2_3	Element_2_4	Element_2_5
Element_3_1	Element_3_2	Element_3_3	Element_3_4	Element_3_5

Za detaljno razumijevanje sustava upravljanjamodel uz pomoć SQL je najbolje uzeti u obzir shemu za primjer. Već znamo što je relacijska baza podataka. Zapis u svakoj tablici je jedna podatkovna stavka. Da biste spriječili redundantnost podataka, potrebno je izvršiti operacije normalizacije.

Osnovna pravila za normalizaciju relacijske cjeline

1. Vrijednost naziva polja za relacijsku tablicu mora biti jedinstvena, jedinstvena (prvi uobičajeni oblik je 1NF).

2. Za tablicu koja je već smanjena na 1NF, naziv bilo kojeg stupca koji ne identificira treba ovisiti o jedinstvenom identifikatoru tablice (2NF).

3. Za cijeli stol, koji je već u 2NF, svaki neidentificirani polje ne može ovisiti o elementu druge neidentificirane vrijednosti (entitet 3NF).

Baze podataka: relacijski odnosi između tablica

Postoje dvije glavne vrste odnosa između relacijskih tablica:

„Jedan-više”. Pojavljuje se kada jedan ključni unos tablice 1 odgovara nekoliko primjeraka drugog entiteta. Ikona ključa na jednom kraju linije označava da je entitet na "jednoj" strani, drugi kraj linije često je obilježen simbolom beskonačnosti.

"Multi-lot" odnos nastaje kada postoji jasna logička interakcija između nekoliko redaka jednog entiteta s brojem zapisa druge tablice.
Ako postoji veza između dva entitetapovezivanje "jedan do jedan", to znači da je ključni identifikator jedne tablice prisutan u drugom entitetu, a zatim treba ukloniti jedan od tablica, to je suvišno. Ali ponekad, iz sigurnosnih razloga, programeri namjerno dijele ta dva entiteta. Stoga, hipotetički, može postojati jedan-na-jedan odnos.

Postojanje ključeva u relacijskoj bazi podataka

Odredite osnovne i sekundarne tipkepotencijalne baze podataka. Relacijski model modela podataka može imati samo jedan potencijalni ključ, to je primarni ključ. Što je on? Primarni ključ je entitetski stupac ili skup atributa kojima možete pristupiti podacima određenog retka. Mora biti jedinstveno, jedinstveno, a polja ne mogu sadržavati prazne vrijednosti. Ako se primarni ključ sastoji od samo jednog atributa, naziva se jednostavno, inače će biti komponenta.

Osim primarnog ključa, postoji i vanjska(strani ključ). Mnogi ne razumiju kakva je razlika između njih. Neka ih analizirati detaljnije pomoću primjera. Dakle, postoje 2 tablice: "Deaninov ured" i "Studenti". Suština "Deanery" sadrži polja: "Studentski ID", "Ime" i "Grupa". Tablica "Studenti" ima takve atributne vrijednosti kao što su "Ime", "Grupa" i "Prosječna lopta". Budući da student ID ne može biti isti za nekoliko studenata, ovo će polje biti primarni ključ. "Ime" i "Grupa" iz tablice "Studenti" mogu biti isti za više ljudi, odnose se na studentski ID broj iz entiteta "Deanery", kako bi se mogli koristiti kao strani ključ.

Primjer modela relacijske baze podataka

Radi jasnoće, dajemo jednostavan primjer relacijskog modela baza podataka koji se sastoji od dva entiteta. Postoji tablica pod nazivom "Deanery".

Suština "Deanery"
Student ID	Puno ime	Grupa
111	Ivanov Oleg Petrovich	U-41
222	Lazarev Ilya Alexandrovich	U-72
333	Konoplev Petr Vasilievich	U-41
444	Kushnereva Natalia Igorevna	U-72

Morate uspostaviti vezekompletna relacijska baza podataka. Stupanje „U-41”, kao i „U-72”, može biti prisutan više od jedanput u tablici „Dean” kao prezime, ime i prezime studenata, u rijetkim slučajevima, može biti isti, tako da ova polja ne može biti da bi primarni ključ. Pokazat ćemo bit "studenata".

Tablica "Studenti"
Puno ime	Grupa	Prosječna lopta	Telefonski broj
Ivanov Oleg Petrovich	U-41	3,0	2-27-36
Lazarev Ilya Alexandrovich	U-72	3,8	2-36-82
Konoplev Petr Vasilievich	U-41	3,9	2-54-78
Kushnereva Natalia Igorevna	U-72	4,7	2-65-25

Kao što vidimo, vrste polja relacijskih baza podatakasasvim drugačije. Postoje i digitalni unosi i znakovi. Stoga, u postavkama atributa trebate navesti vrijednosti cijelog broja, char, vachar, datuma i drugih. U tablici "dekan", samo student ID je jedinstvena vrijednost. 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 studentski ID. Uspostavljena je veza. Ovo je primjer jednog-na-jednog modela. Hipotetički, jedan od tablica je suvišan, oni se lako mogu kombinirati u jedan entitet. Da bi student ID-ovi ne bi postali opće poznati, postojanje dvaju tablica je sasvim realno.