Opomba: To in naslednji dve predavanji sta posvečeni teoriji relacijskih baz podatkov. Ker je celoten relacijski pristop k organizaciji baze podatkov izključno praktičen, je ta teorija v glavnem pragmatična. Glavna težava, ki jo želi rešiti teorija relacijskih baz podatkov, je odkrivanje uporabnih lastnosti določenih shem baz podatkov in razvoj načinov za konstruiranje takšnih shem. Ta problem se običajno na kratko imenuje problem oblikovanja relacijske baze podatkov.

Uvod

Kljub svoji praktični naravnanosti, teorija relacijskih baz podatkov je samostojno znanstveno področje, na katerem so delovali (in delujejo) številni znani raziskovalci, katerih imena bomo predstavili na naših predavanjih. V tem tečaju nismo nameravali podrobneje opisati glavnih rezultatov na tem področju. Naš cilj je zagotoviti samo definicije in izjave, ki so potrebne za splošno razumevanje procesa oblikovanje relacijske baze podatkov temelji na normalizaciji.

Ker najpomembnejše lastnosti relacijskih baz podatkov s praktičnega vidika temeljijo na konceptu funkcionalna odvisnost, smo kratko obravnavo relevantnih teoretičnih vprašanj vključili v samostojno predavanje. Med temi vprašanji so zaprtja in ki zajema nize funkcionalnih odvisnosti, Armstrongovi aksiomi in Heathov izrek o zadostnem pogoju razgradnja razmerja brez izgub. Koncepti in trditve tega predavanja so res potrebni za obvladovanje snovi v 7. predavanju, vendar smo bralcem skušali tudi s preprostimi primeri prikazati, kaj je teorija relacijskih baz podatkov, kakšna je njegova stopnja kompleksnosti in kako intuitiven je.

Upoštevajte, da nismo ločili teoretičnega gradiva glede večvrednostne odvisnosti in odvisnosti povezave. To je bilo storjeno iz dveh razlogov. Prvič, te vrste odvisnosti so manj pogoste pri modeliranju predmetno področje uporabo baz podatkov. Zato se nam je zdelo dovolj, da v okviru predavanja 8 predstavimo le osnove ustreznega teoretičnega gradiva. Drugič, čeprav teorija večvrednostne odvisnosti in odvisnosti povezave, pravzaprav ni veliko bolj zapleteno od teorije funkcionalne odvisnosti, so njegove definicije in izjave preveč okorne za ta tečaj.

Funkcionalne odvisnosti

Najpomembnejše s praktičnega vidika normalne oblike odnosov temeljijo na temeljnih teorije relacijskih baz podatkov koncept funkcionalna odvisnost. Za nadaljnjo predstavitev bomo potrebovali več definicij in izjav (jih bomo razložili in ilustrirali v nadaljevanju).

Splošne definicije

Naj bo dano spremenljivka odnosa r in sta X in Y poljubni podmnožici glave r ("sestavljeni" atributi).

V smislu spremenljivka odnosa r atribut Y je funkcionalno odvisen od atributa Xče in samo če vsaka vrednost X ustreza točno eni vrednosti Y. V tem primeru je tudi rečeno, da je atribut X funkcionalno opredeljuje atribut Y (X je determinanta ( determinanta) za Y in Y je odvisen od X). To bomo označili kot r.X->r.Y.

Na primer, uporabili bomo relacijo EMPLOYEE_PROJECTS (SLUN_NAME, SLU_NAME, SLU_ZARP, PRO_NOM, PROJECT_RUK)(slika 6.1). Očitno, če je SLU_NOM primarni ključ odnosa ZAPOSLENI, potem je za to razmerje pošteno funkcionalna odvisnost (FD) SLN_NAME->SERV_NAME.

Pravzaprav za telo odnosa ZAPOSLENI_PROJEKTI v obliki, kot je prikazano na sl. 6.1 se izvajajo tudi naslednji FD (1):

riž. 6.1.

SLUN_NOM->SLUN_NAME SLUN_NOM->SLUN_ZARP SLU_NOM->PRO_NOM SLUN_NOM->PROJECT_RUK (SLUN_NAME, SLU_NAME)->SLUN_ZARP (SLUN_NAME, SLUN_NAME)->PRO_NOM (SLUN_NOM, SLUN_NAME)->(SLUN_ZARP, PRO_NAME) … PRO_NOM ->PROJECT_RUK in itd.

Ker so imena vseh zaposlenih različna, so izpolnjeni tudi naslednji FD (2):

SERV_NAME->SERV_NAME SERV_NAME->SLU_ZARP SER_NAME->PRO_NAME itd.

Poleg tega za primer na sl. 6.1 je zadovoljen in FD (3):

SLU_ZARP->PRO_NOM

Vendar upoštevajte, da se narava skupine FD (1) razlikuje od narave skupin FD (2) in (3). Logično je domnevati, da morajo biti identifikacijske številke zaposlenih vedno različne, vsak projekt pa ima samo enega vodjo. Zato morajo biti FD skupine (1) resnični za vsako veljavno vrednost spremenljivka odnosa ZAPOSLENI_PROJEKTI in se lahko šteje za invariante, oz omejitve integritete to spremenljivka odnosa.

FD skupine (2) temeljijo na manj naravni predpostavki, da imajo vsi zaposleni različna imena. To velja za primer na sl. 6.1, vendar je možno, da čez čas skupine FD (2) ne bodo izpolnjene za nobeno vrednost spremenljivka odnosa ZAPOSLENI_PROJEKTI.

Nazadnje, FD skupine (3) temelji na zelo nenaravni predpostavki, da dva zaposlena, ki sodelujeta pri različnih projektih, ne prejemata enake plače. Tudi ta predpostavka velja za primer na sl. 6.1, a najverjetneje je to naključje.

V prihodnje nas bodo zanimali le ti funkcionalne odvisnosti, ki mora biti izpolnjen za vse možne vrednosti spremenljivke razmerja.

Upoštevajte, da če je atribut A relacije r možni ključ, potem za vsak atribut B te relacije vedno velja

PROGRAMIRANJE V OKOLJU DELPHI 6

Baza podatkov. Ustvarite poročilo z Wordom.

Potrdil uredniški in založniški svet

univerza kot laboratorijska delavnica

Voronež 2004

UDK 681.3

Vorobyov E.I., Korotkevich D.E.. Programiranje v okolju Delphi 6: Laboratorijska delavnica: 2. del: Baze podatkov. Ustvarite poročilo z Wordom. Tokovi. Voronež: Voronež. država tehn. Univ., 2004. 107 str.

Drugi del laboratorijske delavnice obravnava teoretične in praktične informacije za pisanje programov v okolju Delphi 6 na temo: “Oblikovanje baz podatkov, izdelava poročil v Wordu in uporaba niti pri izdelavi visoko zmogljivih aplikacij.”

Publikacija izpolnjuje zahteve državnega izobraževalnega standarda višjega strokovnega izobraževanja v smeri 230100 "Informatika in računalništvo", posebnost 230104 "Računalniško podprti sistemi oblikovanja", disciplina "Programiranje v jezikih visoke ravni".

Tabela 3. Il. 19. Bibliografija: 7 naslovov.

Znanstveni urednik: dr. tehn. znanosti, prof. Ya.E. Lvovich

Recenzenti: Oddelek za računalništvo Gozdarske akademije Voronež (vodja oddelka, doktor tehničnih znanosti, prof. V.E. Mezhov);

Dr. tehn. znanosti, prof. O.Yu.Makarov

© Vorobyov E.I., Korotkevich D.E., 2004

© Oblikovanje. Država Voronež

Tehniška univerza, 2004

Uvod

Koncept baze podatkov

Baze podatkov veljajo za glavno prednost Delphija. Tudi specializirani jeziki za delo z bazami podatkov (kot je MS Visual FoxPro) so očitno slabši v preprostosti in moči programiranja te vrste aplikacij. Delphi skriva vso kompleksnost in hkrati daje največjo moč. Še nikoli ni bilo naloge, ki je v Delphiju ne bi bilo mogoče izvesti v kratkem času. In glavna stvar je, da je vse to implementirano zelo priročno in lahko razumljivo. V Delphiju lahko ustvarite preproste aplikacije, tudi s kompleksnimi zbirkami podatkov, brez ene vrstice kode. Ta vadnica zajema laboratorijske naloge za obvladovanje tehnik za delo z lokalnimi zbirkami podatkov.

Teorija relacijskih baz podatkov

Pred desetimi leti je bilo programiranje baz podatkov zelo težka naloga. Dandanes si je to težko predstavljati, saj je bil zahvaljujoč Delphiju postopek pisanja programov poenostavljen, število zbirk podatkov pa je že na desetine.

Baze podatkov delimo na lokalne (nameščene na odjemalčevem računalniku, kjer teče program) in oddaljene (nameščene na strežniku, oddaljenem računalniku). Strežniške baze podatkov se nahajajo na oddaljenem računalniku in delujejo pod nadzorom strežniške programske opreme. Njihove glavne prednosti vključujejo zmožnost dela z eno bazo podatkov hkrati s strani več uporabnikov, hkrati pa obstaja minimalna obremenitev omrežja. Obstajajo tudi omrežne baze podatkov, ki preveč obremenjujejo omrežje in so neprijetne za uporabo tako za programerja kot za končnega uporabnika. Ko se program poveže z omrežno zbirko podatkov, s strežnika prenese njeno skoraj popolno kopijo. Če ste naredili spremembe, bo vaša kopija v celoti prenesena nazaj. To je zelo neprijetno, saj ustvarja veliko obremenitev omrežja zaradi prevelikega prenosa podatkov. V tehnologiji odjemalec-strežnik odjemalski program strežniku pošlje preprosto besedilno zahtevo, da prejme nekaj podatkov. Strežnik jih obdela in vrne le zahtevani del podatkov. Ko morate spremeniti nekatere podatke, se strežniku ponovno pošlje zahteva za spremembo, strežnik pa spremeni podatke v svoji bazi podatkov. Tako se po omrežju prenašajo predvsem samo besedilne zahteve, ki praviloma zavzamejo manj kot kilobajt. Vse podatke obdeluje strežnik, kar pomeni, da je odjemalčev stroj veliko manj obremenjen in ni tako zahteven glede virov. Strežnik odjemalcu pošlje le najnujnejše podatke, kar pomeni, da ni nepotrebnega nalaganja kopije celotne baze podatkov. Zaradi vsega tega so omrežne baze podatkov že zastarele in se praktično ne uporabljajo. Skoraj v celoti jih je nadomestila tehnologija odjemalec-strežnik. Toda lokalne baze podatkov bodo vedno živele. Oblika njihovega shranjevanja se lahko spremeni ali dodajo nekatere nove funkcije, vendar same baze podatkov bodo obstajale. Za nadaljnjo obravnavo moramo definirati nov koncept – tabela. Do sedaj so bila obravnavana le splošna načela, zato je bil uporabljen splošni koncept baze podatkov. Tabela zbirke podatkov je kot dvodimenzionalna matrika, v kateri so podatki urejeni v stolpcu (odličen primer tabele je Excel). Podatkovna baza je, grobo rečeno, samo datoteka, ki lahko shrani od ene do več tabel. Večina lokalnih baz podatkov lahko shrani samo eno tabelo (dBase, Paradox, XML). Vendar pa obstajajo predstavniki lokalnih baz podatkov, kjer je več tabel v eni datoteki (na primer Access).

Lokalne baze podatkov

Med lokalnimi zbirkami podatkov upoštevajmo relacijske kot najpogostejše. Kaj je relacijska zbirka podatkov? To je tabela, v kateri so stolpci imena podatkov, ki so v njej shranjeni, vsaka vrstica pa hrani podatke same. Tabela zbirke podatkov je podobna preglednici Excel (če smo natančnejši, Excel shranjuje svoje podatke v lastniški obliki, zgrajeni na tehnologiji baze podatkov). Tabele lokalne zbirke podatkov lahko shranite na lokalni trdi disk ali centralno shranite na omrežni pogon na datotečnem strežniku. Te datoteke je mogoče kopirati s standardnimi orodji kot vse druge datoteke, ker same tabele baze podatkov niso vezane na določeno lokacijo. Glavna stvar je, da lahko program najde tabelo. Vsaka tabela mora imeti eno edinstveno polje, ki bo edinstveno identificiralo vrstico. To polje se imenuje ključno polje. Ta polja se pogosto uporabljajo za povezovanje več tabel. Tudi če tabela ni povezana, je ključno polje še vedno obvezno. Priporočljivo je, da kot ključ uporabite številski tip, če pa baza podatkov dopušča, bo bolje, če je tipa “autoincrement” (samodejno naraščanje/padanje števila ali števca). Imena stolpcev v tabeli baze podatkov morajo biti prav tako enolična, vendar v tem primeru ne nujno številska. Imenujete jih lahko kakorkoli želite, le da je edinstveno in razumljivo. Vsak stolpec (polje baze podatkov) mora imeti določen tip. Število vrst in njihovih variant je odvisno od vrste baze podatkov, na primer format dBASE (datoteke s končnico DBF) podpira le 6 vrst, Paradox pa jih podpira že do 15. Bazo podatkov lahko shranimo v eno datoteko (Access ) ali v več (Paradox, dBase). Natančneje, podatki tabele so vedno shranjeni v eni datoteki, dodatne informacije pa se lahko nahajajo v ločenih datotekah. Dodatne informacije lahko vključujejo indekse, omejitve ali seznam privzetih vrednosti za določena polja. Če se vsaj ena od datotek poškoduje ali izbriše, podatki morda ne bodo na voljo za urejanje.

Kaj se je zgodilo indeksi? Podatki iz tabel so zelo pogosto podvrženi nekakšnim spremembam, zato jih morate poiskati, preden uredite katero koli vrstico. Tudi statične tabele, ki se uporabljajo kot referenčne knjige, so prav tako predmet iskanja pred prikazom zahtevanih podatkov. Iskanje je precej dolgotrajen postopek, še posebej, če tabela vsebuje veliko vrstic. Indeksi so namenjeni pospešitvi tega postopka in se lahko uporabljajo tudi kot izhodišče za razvrščanje. Na tej stopnji je dovolj vedeti, da neindeksiranega polja ni mogoče naročiti.

Če potrebujete tabelo, ki bo urejena po polju " Priimek«, potem je treba to polje najprej indeksirati. Potem morate samo označiti, da naj tabela zdaj deluje s tem in tem indeksom, in samodejno bo razvrščena.

V dobro zasnovani bazi podatkov je redundanca podatkov odpravljena in verjetnost shranjevanja nedoslednih podatkov je zmanjšana. Tako ima ustvarjanje baz podatkov dva glavna cilja: zmanjšati redundanco podatkov in povečati njihovo zanesljivost.

Življenjski cikel katerega koli programskega izdelka, vključno s sistemom za upravljanje baz podatkov, je sestavljen (večinoma) iz stopenj načrtovanja, implementacije in delovanja.

Seveda je najpomembnejši dejavnik v življenjskem ciklu aplikacije baze podatkov faza načrtovanja. Učinkovitost sistema in njegova informacijska bogastvo ter s tem njegova življenjska doba sta odvisni od tega, kako skrbno je premišljena struktura baze podatkov in kako jasno so definirane povezave med njenimi elementi.

Zahteve glede baze podatkov

Torej, dobro zasnovana zbirka podatkov:

1. Zadovoljuje vse zahteve uporabnikov glede vsebine baze podatkov. Pred načrtovanjem baze podatkov je potrebno opraviti obsežno raziskavo o zahtevah uporabnikov glede funkcionalnosti baze podatkov.

2. Zagotavlja doslednost in celovitost podatkov. Pri oblikovanju tabel je potrebno določiti njihove atribute in nekatera pravila, ki omejujejo možnost, da uporabnik vnese napačne vrednosti. Za preverjanje podatkov, preden jih neposredno zapišemo v tabelo, mora baza podatkov poklicati pravila podatkovnega modela in s tem zagotoviti ohranitev celovitosti informacij.

3. Zagotavlja naravno, lahko razumljivo strukturiranje informacij. Visokokakovostna konstrukcija baze podatkov vam omogoča, da naredite poizvedbe v bazi podatkov bolj "pregledne" in lažje razumljive; Posledično se zmanjša verjetnost vnosa napačnih podatkov in izboljša kakovost vzdrževanja baze podatkov.

4. Izpolnjuje zahteve glede učinkovitosti baze podatkov uporabnikov. Z velikimi količinami informacij, težave z ohranjanjem produktivnosti

začnejo igrati pomembno vlogo in takoj "poudarijo" vse pomanjkljivosti faze načrtovanja.

Naslednje točke predstavljajo osnovne korake oblikovanja baze podatkov:

1. Določite informacijske potrebe baze podatkov.

2. Analizirajte predmete iz resničnega sveta, ki jih je treba modelirati v bazi podatkov. Iz teh objektov oblikujte entitete in značilnosti teh entitet (na primer za entiteto »del« so lahko značilnosti »ime«, »barva«, »teža« itd.) in oblikujte njihov seznam.

3. Povežite entitete in značilnosti – tabele in stolpce (polja) v zapisu DBMS, ki ste ga izbrali (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle itd.).

4. Definirajte atribute, ki enolično identificirajo vsak objekt.

5. Razvijte pravila, ki bodo vzpostavila in ohranila celovitost podatkov.

6. Vzpostavite povezave med objekti (tabele in stolpci), normalizirajte tabele.

7. Načrtujte vprašanja zanesljivosti podatkov in po potrebi ohranjanje tajnosti podatkov.

Povezane informacije.

Relacijska algebra temelji na teoriji množic in je osnova logike baze podatkov.
Ko sem šele študiral zgradbo podatkovnih baz in SQL, mi je predhodno seznanitev z relacijsko algebro močno pripomogla k temu, da se je nadaljnje znanje pravilno umestilo v mojo glavo, in trudil se bom, da bo ta članek imel podoben učinek.

Torej, če boste začeli študirati na tem področju ali vas le zanima, kliknite na mačko.

Relacijska baza podatkov

Najprej predstavimo koncept relacijske baze podatkov, v kateri bomo izvajali vsa dejanja.

Relacijska zbirka podatkov je zbirka odnosov, ki vsebujejo vse informacije, ki morajo biti shranjene v bazi podatkov. V tej definiciji nas zanima izraz relacija, vendar ga bomo za zdaj pustili brez stroge definicije.
Predstavljajmo si bolje tabelo izdelkov.

Tabela IZDELKI

ID	IME	PODJETJE	CENA
123	Piškotki	Temna stran LLC	190
156	čaj	Temna stran LLC	60
235	Ananas	OJSC "Frukti"	100
623	Paradižnik	OOO "Zelenjava"	130

Tabela je sestavljena iz 4 vrstic, vrstica v tabeli je v relacijski teoriji tuple. Niz urejenih tulp se imenuje relacija.
Preden definiramo relacijo, uvedimo še en izraz – domena. Domene v odnosu do tabele so stolpci.

Zaradi jasnosti zdaj uvajamo strogo definicijo relacije.

Naj je danih N množic D1,D2, …. Dn (domene), relacija R nad temi množicami je množica urejenih N-tork oblike , kjer d1 pripada D1 itd. Množice D1,D2,..Dn imenujemo domene relacije R.
Vsak element tuple predstavlja vrednost enega od atributov, ki ustreza eni od domen.

Ključi v odnosih

V relaciji je zahteva, da morajo biti vse tuple ločene. Za enolično identifikacijo tuple obstaja primarni ključ. Primarni ključ je atribut ali niz najmanjšega števila atributov, ki enolično identificira določeno torko in ne vsebuje dodatnih atributov.
Posledica tega je, da morajo biti vsi atributi v primarnem ključu potrebni in zadostni za identifikacijo določene tuple, in če izpustite katerega od atributov v ključu, bo ta nezadostni za identifikacijo.
Na primer, v taki tabeli bo ključ kombinacija atributov iz prvega in drugega stolpca.

tabela GOZNIKI

Razvidno je, da ima lahko organizacija več gonilnikov in za enolično identifikacijo gonilnika sta potrebni tako vrednost iz stolpca »Ime organizacije« kot tudi iz stolpca »Ime gonilnika«. Tak ključ imenujemo sestavljeni ključ.

V relacijski bazi podatkov so tabele med seboj povezane in povezane kot glavne in podrejene tabele. Povezava med glavno in podrejeno tabelo se izvaja preko primarnega ključa glavne tabele in tujega ključa podrejene tabele.
Tuji ključ je atribut ali niz atributov, ki je primarni ključ v glavni tabeli.

Ta pripravljalna teorija bo zadostovala za spoznavanje osnovnih operacij relacijske algebre.

Operacije relacijske algebre

Osnovnih osem operacij relacijske algebre je predlagal E. Codd.

• Združenje
• Križišče
• Odštevanje
• kartezični produkt
• Vzorec
• Projekcija
• Spojina
• Delitev

Prva polovica operacij je podobna enakim operacijam na množicah. Nekatere operacije je mogoče izraziti z drugimi operacijami. Oglejmo si večino operacij s primeri.

Za razumevanje si je pomembno zapomniti, da je rezultat katere koli algebrske operacije na relacijah druga relacija, ki jo je nato mogoče uporabiti v drugih operacijah.
Ustvarimo še eno tabelo, ki nam bo koristila v primerih.

miza SELLERS

ID	PRODAJALEC
123	OOO "Dart"
156	OJSC "Vedro"
235	CJSC "Vegetable Baza"
623	JSC "Firma"

Strinjajmo se, da je v tej tabeli ID tuji ključ, povezan s primarnim ključem tabele IZDELKI.

Najprej si oglejmo najpreprostejšo operacijo - ime razmerja. Njegov rezultat bo enaka relacija, to pomeni, da bomo z izvedbo operacije IZDELKI prejeli kopijo relacije IZDELKI.

Projekcija

Projekcija je operacija, pri kateri se atributi iz relacije ekstrahirajo samo iz določenih domen, to pomeni, da se iz tabele izberejo samo potrebni stolpci, in če dobimo več enakih tulpov, ostane samo en primerek take tuple v nastalo relacijo.
Na primer, naredimo projekcijo na tabelo IZDELKI tako, da v njej izberemo ID in CENO.

Sintaksa operacije:
π (ID, PRICE) IZDELKI

V vzorčnem pogoju lahko uporabimo poljuben logični izraz. Naredimo še en izbor s ceno, višjo od 90, in ID-jem izdelka, manjšim od 300:

σ(CENA>90^ID<300) PRODUCTS

Množenje

Množenje ali kartezični produkt je operacija, ki se izvaja na dveh relacijah, zaradi česar iz obeh začetnih relacij dobimo relacijo z vsemi domenami. Tuple v teh domenah bodo vse možne kombinacije tork iz začetnih relacij. S primerom bo bolj jasno.

Dobimo kartezični produkt tabel IZDELKI in PRODAJALCI.
Sintaksa operacije:

IZDELKI × PRODAJALCI
Opazili boste, da imata ti dve tabeli isto domeno ID-ja. V tem primeru imajo domene z istim imenom predpono z imenom ustreznega razmerja, kot je prikazano spodaj.
Zaradi jedrnatosti ne pomnožimo celotnih razmerij, ampak vzorce z ID-jem stanja<235

(enake tuple so označene z barvo)

IZDELKOV.ID	IME	PODJETJE	CENA	SELLERS.ID	PRODAJALEC
123	Piškotki	Temna stran LLC	190	123	OOO "Dart"
156	čaj	Temna stran LLC	60	156	OJSC "Vedro"
123	Piškotki	Temna stran LLC	190	156	OJSC "Vedro"
156	čaj	Temna stran LLC	60	123	OOO "Dart"

Za primer uporabe te operacije si predstavljajte, da je treba izbrati prodajalce s cenami, nižjimi od 90. Brez izdelka bi bilo treba najprej pridobiti ID-je izdelkov iz prve tabele, nato pa z uporabo teh ID-jev iz druge tabele pridobiti potrebne imena PRODAJALCA in z uporabo izdelka bi bila naslednja poizvedba:

π (PRODAJALEC) σ (PRODUCTS.ID=SELLERS.ID ^ CENA<90) PRODUCTS × SELLERS

Kot rezultat te operacije dobimo razmerje:

PRODAJALEC

OJSC "Vedro"

Povezava in naravna povezava

Operacija združevanja je inverzna operaciji projekcije in ustvari novo relacijo iz dveh obstoječih. Novo relacijo dobimo z veriženjem tulp prve in druge relacije, relacije, v katerih vrednosti podanih atributov sovpadajo, pa so predmet veriženja. Natančneje, če povežete razmerja IZDELKI in PRODAJALCI, so ti atributi atributi ID domen.

Prav tako si lahko zaradi jasnosti predstavljate povezavo kot rezultat dveh operacij. Najprej vzamemo produkt izvornih tabel, nato pa iz nastale relacije naredimo izbor s pogojem enakosti atributov iz istih domen. V tem primeru je pogoj enakost PRODUCTS.ID in SELLERS.ID.

Poskusimo povezati relacije IZDELKI in PRODAJALCI in dobiti relacijo.

IZDELKOV.ID	IME	PODJETJE	CENA	SELLERS.ID	PRODAJALEC
123	Piškotki	Temna stran LLC	190	123	OOO "Dart"
156	čaj	Temna stran LLC	60	156	OJSC "Vedro"
235	Ananas	OJSC "Frukti"	100	235	CJSC "Vegetable Baza"
623	Paradižnik	OOO "Zelenjava"	130	623	JSC "Firma"

Naravno združevanje prejme podobno relacijo, vendar če imamo pravilno konfigurirano shemo v bazi podatkov (v tem primeru je primarni ključ tabele PRODUCTS ID povezan s tujim ključem tabele SELLERS ID), potem nastala relacija vsebuje samo ena ID domena.

Sintaksa operacije:
IZDELKI ⋈ PRODAJALCI;

Dobiš to razmerje:

IZDELKOV.ID	IME	PODJETJE	CENA	PRODAJALEC
123	Piškotki	Temna stran LLC	190	OOO "Dart"
156	čaj	Temna stran LLC	60	OJSC "Vedro"
235	Ananas	OJSC "Frukti"	100	CJSC "Vegetable Baza"
623	Paradižnik	OOO "Zelenjava"	130	JSC "Firma"

Presek in odštevanje.

Rezultat operacije presečišča bo relacija, sestavljena iz tulpov, ki so v celoti vključeni v obe relaciji.
Rezultat odštevanja bo relacija, sestavljena iz tulpkov, ki so tuple prve relacije in ne tuplev druge relacije.
Te operacije so podobne enakim operacijam na množicah, zato menim, da jih ni treba podrobneje opisovati.

Viri informacij

• Osnove uporabe in načrtovanja baz podatkov - V. M. Iljušečkin
• tečaj predavanj Uvod v baze podatkov - Jennifer Widom, Univerza Stanford

Hvaležen bi bil za argumentirane komentarje

Na kratko o pomembnem.

Normalizacija baze podatkov

Prva normalna oblika (1NF)

• brez podvojenih skupin podatkov
• zagotovljena je atomičnost podatkov (vsi podatki so avtonomni in neodvisni).

Na najvišji ravni se to doseže z ustvarjanjem primarnega ključa, nato premikanjem ponavljajočih se skupin podatkov v nove tabele, ustvarjanjem primarnih ključev za te tabele itd. Poleg tega morate vse zapise, katerih stolpci vsebujejo sestavljene informacije, razdeliti v ločene vrstice za vsak del podatkov stolpca.

Druga normalna oblika (2NF)

• tabela izpolnjuje pogoje 1NF
• vsak stolpec je odvisen od celotnega ključa, ne od njegovega dela.

Tretja normalna oblika (3NF)

• tabela izpolnjuje pogoje 2NF
• noben stolpec ni odvisen od stolpca, ki ni del primarnega ključa
• ne vsebuje izvedenih podatkov

Druge običajne oblike, ki nimajo velike praktične vrednosti:

Boyce-Codd normalna oblika

Možnost 3NF. Zasnovan za reševanje situacije, ko obstaja veliko prekrivajočih se kandidatnih ključev. Pravzaprav zunaj akademske skupnosti ni logične utemeljitve.

Četrta normalna oblika

Zasnovan za reševanje težav z odvisnostmi z več vrednostmi. Do takih situacij pride, če je v tabeli, zmanjšani na 3NF, en stolpec sestavljenega primarnega ključa odvisen od drugega stolpca primarnega ključa.

Peta normalna oblika

Uporablja se pri delu z dekompozicijo odnosov z in brez izgub. Nastane v situaciji, ko je možno eno razmerje razcepiti na več različnih razmerij, potem pa ga ne bomo mogli več logično vrniti v prvotno obliko.

Šesta normalna oblika (normalna oblika ključa domene)

Zagotavlja, da v bazi podatkov ni anomalij pri spreminjanju. V realnih razmerah je to praktično nedosegljivo.

Razmerje.

Nekoč sem slišal od žensk, da moški
takoj poskušajte zapustiti prostor, v katerem
Slišala se je beseda "razmerje".<...>ključ do uspeha
odnosov je zavedanje slehernika svoje vloge
v zvezi s tem ter pravila in omejitve,
vsiljuje to razmerje.
(C) Robert Viera, »Profesionalno programiranje SQL Server 2000«

Vrste odnosov

• Ena proti ena (smiselno je, ko je treba ujemajoče se podatke shraniti v različnih zbirkah podatkov ali ko je presežena največja velikost podatkov vrstice)
• Nič ali ena proti ena
• Eden proti mnogo
• Ena proti -nič, -ena ali -mnogo
• Veliko proti mnogo (spojne tabele)

Asociacije

NOTRANJI SPOJ

Ekskluzivna pridružitev. Rezultat izbire vključuje le tiste zapise tabele, ki imajo ujemanja v seznanjeni tabeli za dani pogoj.

LEVO|DESNO ZDRUŽI

Inkluzivna pridružitev. Rezultat izbire vključuje zapise iz tabele levo/desno od PRIDRUŽI SE oz. V tem primeru se dopolnijo podatki iz manjkajočega “parnega” zapisa NIČ.
FROM leva_tabela LEFT JOIN desna_tabela– vključeni so vsi zapisi iz leve tabele left_table
FROM leva_tabela RIGHT JOIN desna_tabela– vključeni so vsi zapisi iz desne tabele right_table

POPOLNA PRIDRUŽITEV

Inkluzivna pridružitev. Rezultat izbire ne vključuje samo zapisov, ki se ujemajo v drugi tabeli, temveč tudi zapise iz obeh tabel, za katere v drugi tabeli ni bilo ujemanja. V tem primeru bodo podatki iz manjkajočega "seznanjenega" zapisa zapolnjeni z NULL.

KRIŽNI SPOJ

Križna unija (kartezični produkt). Vsak zapis iz ene tabele se ujema z vsakim zapisom iz druge tabele. Število nastalih zapisov je enako zmnožku števila zapisov v obeh tabelah.

Načela za urejanje več PRIDRUŽI SE's

Če morate združiti več miz, se morate spomniti dveh načel:

1. Vsi sindikati na levo PRIDRUŽI SE obravnavati kot eno samo tabelo za vključitev ali izključitev iz poizvedbe.
2. Vsi sindikati so na DESNICI PRIDRUŽI SE TUDI obravnava kot eno samo tabelo za vključitev ali izključitev iz poizvedbe.

Posledica teh načel je naslednje priporočilo za oblikovanje kompleksnih združenj:

• Kjer je le mogoče, uporabite INNER JOIN.
• Če obstaja potreba po uporabi ZUNANJIH SPOJEV, jih je treba postaviti nazadnje, NOTRANJI SPOJI pa na začetku spoja.

P.S. Vse našteto so splošni »postulati« teorije relacijskih baz podatkov, ki niso vezani na lastnosti določenih DBMS.

Podatkovni model je niz podatkovnih struktur in operacij za njihovo obdelavo. Z uporabo podatkovnega modela lahko vizualno predstavite strukturo objektov in odnose, vzpostavljene med njimi. Za terminologijo podatkovnega modela sta značilna pojma "podatkovni element" in "zavezujoča pravila". Podatkovni element opisuje poljuben nabor podatkov, povezovalna pravila pa določajo algoritme za medsebojno povezovanje podatkovnih elementov. Do danes je bilo razvitih veliko različnih podatkovnih modelov, v praksi pa se uporabljajo trije glavni. Obstajajo hierarhični, mrežni in relacijski podatkovni modeli. V skladu s tem govorijo o hierarhičnih, omrežnih in relacijskih DBMS.

O Hierarhični podatkovni model. Hierarhično urejeni podatki so v vsakdanjem življenju zelo pogosti. Na primer, struktura visokošolske ustanove je večstopenjska hierarhična struktura. Hierarhično (drevesno) zbirko podatkov sestavlja urejen niz elementov. V tem modelu začetni elementi povzročijo druge elemente, ti pa nato povzročijo nadaljnje elemente. Vsak podrejeni element ima samo en nadrejeni element.

Organizacijske strukture, seznami materialov, kazala v knjigah, projektni načrti in številni drugi nizi podatkov so lahko predstavljeni v hierarhični obliki. Celovitost povezav med predniki in potomci se samodejno ohranja. Osnovno pravilo: noben otrok ne more obstajati brez svojega starša.

Glavna pomanjkljivost tega modela je potreba po uporabi hierarhije, ki je bila osnova baze podatkov med načrtovanjem. Potreba po stalni reorganizaciji podatkov (in pogosto nezmožnost te reorganizacije) je privedla do oblikovanja bolj splošnega modela - mrežnega modela.

O Omrežni podatkovni model. Mrežni pristop k organizaciji podatkov je razširitev hierarhičnega pristopa. Ta model se od hierarhičnega razlikuje po tem, da ima lahko vsak generirani element več kot en generirajoči element. ■

Ker lahko omrežna zbirka podatkov neposredno predstavlja vse vrste odnosov, ki so del podatkov ustrezne organizacije, je po teh podatkih mogoče krmariti, jih raziskati in poizvedovati na različne načine, to pomeni, da omrežni model ni vezan samo na eno hierarhijo. Za zahtevo po omrežni bazi podatkov pa se je potrebno poglobiti v njeno strukturo (imeti pri roki shemo te baze podatkov) in razviti mehanizem za krmarjenje po bazi podatkov, kar je pomembna pomanjkljivost tega modela baze podatkov. .

O Relacijski podatkovni model. Osnovna ideja relacijskega podatkovnega modela je predstaviti kateri koli niz podatkov kot dvodimenzionalno tabelo. V svoji najpreprostejši obliki relacijski model opisuje eno samo dvodimenzionalno tabelo, pogosteje pa model opisuje strukturo in odnose med več različnimi tabelami.

Relacijski podatkovni model

Torej, namen informacijskega sistema je obdelava podatke približno predmetov realnem svetu, ob upoštevanju povezave med predmeti. V teoriji baz podatkov se podatki pogosto imenujejo atributi, in predmeti - entitete. Objekt, atribut in povezava so temeljni koncepti I.S.

Predmet(ali bistvo) je nekaj, kar obstaja in razločljiv, to pomeni, da lahko predmet imenujemo »nekaj«, za kar obstaja ime in način za razlikovanje enega podobnega predmeta od drugega. Na primer, vsaka šola je objekt. Predmeti so tudi oseba, razred v šoli, podjetje, zlitina, kemična spojina itd. Predmeti so lahko ne samo materialni predmeti, ampak tudi bolj abstraktni koncepti, ki odražajo realni svet. Na primer dogodki, regije, umetniška dela; knjige (ne kot tiskani izdelki, ampak kot dela), gledališke predstave, filmi; pravne norme, filozofske teorije itd.

Atribut(oz dano)- to je določen indikator, ki označuje določen predmet in ima določeno številčno, besedilno ali drugo vrednost za določen primerek predmeta. Informacijski sistem deluje z nabori objektov, oblikovanih glede na dano predmetno področje, z uporabo specifičnih vrednosti atributov(podatkov) določenih objektov. Na primer, vzemimo razrede v šoli kot niz predmetov. Število učencev v razredu je podatek, ki ima številčno vrednost (en razred ima 28, drug 32). Ime razreda je dano in ima besedilno vrednost (eden ima 10A, drugi 9B itd.).

Razvoj relacijskih baz podatkov se je začel v poznih 60. letih, ko so se pojavila prva dela, ki so obravnavala; možnost uporabe znanih in naravnih načinov predstavljanja podatkov - t.i. tabelarnih podatkovno-logičnih modelov - pri načrtovanju podatkovnih baz.

Za utemeljitelja teorije relacijskih baz podatkov velja IBM-ov uslužbenec dr. E. Codd, ki je 6. junija 1970 objavil članek Relacijski model podatkov za banke podatkov v veliki skupni rabi(Relacijski podatkovni model za velike zbirne banke podatkov). Ta članek je bil prvi, ki je uporabil izraz »relacijski podatkovni model«. Teorija relacijskih baz podatkov, ki jo je v 70. letih prejšnjega stoletja v ZDA razvil dr. E. Codd, ima močno matematično osnovo, ki opisuje pravila za učinkovito organiziranje podatkov. Teoretični okvir, ki ga je razvil E. Codd, je postal osnova za razvoj teorije oblikovanja baz podatkov.

E. Codd, ki je po izobrazbi matematik, je predlagal uporabo aparata teorije množic (unija, presečišče, razlika, kartezični produkt) za obdelavo podatkov. Dokazal je, da je vsak nabor podatkov mogoče predstaviti v obliki dvodimenzionalnih tabel posebne vrste, ki jih v matematiki poznamo kot »relacije«.

Relacijska Za zbirko podatkov se šteje tista, v kateri so vsi podatki uporabniku predstavljeni v obliki pravokotnih tabel podatkovnih vrednosti, vse operacije v zbirki podatkov pa so zreducirane na manipulacije s tabelami.

Tabela je sestavljena iz stolpci (polja) in vrstice (zapisi); ima edinstveno ime v bazi podatkov. Tabela odraža Vrsta predmeta resnični svet (entiteta), in vsak od nje niz je specifičen predmet. Vsak stolpec tabele je zbirka vrednosti za določen atribut predmeta. Vrednosti so izbrane iz nabora vseh možnih vrednosti za atribut predmeta, ki se imenuje domena.

V svoji najsplošnejši obliki je domena definirana z določitvijo nekega osnovnega podatkovnega tipa, ki mu pripadajo elementi domene, in poljubnega logičnega izraza, uporabljenega za podatkovne elemente. Če ovrednotite logični pogoj za podatkovno postavko in je rezultat resničen, potem ta postavka pripada domeni. V najpreprostejšem primeru je domena definirana kot veljaven potencialni niz vrednosti istega tipa. Zbirka rojstnih datumov vseh zaposlenih na primer predstavlja »domeno rojstnega datuma«, imena vseh zaposlenih pa »domeno imena zaposlenega«. Domena datuma rojstva mora imeti podatkovni tip točke v času, domena imena zaposlenega pa mora imeti znakovni podatkovni tip.

Če dve vrednosti prihajata iz iste domene, je mogoče narediti primerjavo med dvema vrednostima. Na primer, če sta dve vrednosti vzeti iz domene rojstnih datumov, ju lahko primerjate in ugotovite, kateri zaposleni je starejši. Če so vrednosti vzete iz različnih domen, potem njihova primerjava ni dovoljena, saj po vsej verjetnosti ni smiselna. Na primer, primerjava imena in datuma rojstva zaposlenega ne bo nič določnega.

Vsak stolpec (polje) ima ime, ki je običajno zapisano na vrhu tabele. Pri oblikovanju tabel znotraj določenega DBMS je možno za vsako polje izbrati svoje vrsta, to je določiti nabor pravil za njegov prikaz, kot tudi določiti operacije, ki jih je mogoče izvesti s podatki, shranjenimi v tem polju. Nabori tipov se lahko med različnimi DBMS razlikujejo.

Ime polja mora biti edinstveno v tabeli, vendar imajo lahko različne tabele polja z enakim imenom. Vsaka tabela mora imeti vsaj eno polje; Polja se nahajajo v tabeli v skladu z vrstnim redom, v katerem so bila prikazana njihova imena, ko je bila ustvarjena. Za razliko od polj nizi nimajo imen; njihov vrstni red v tabeli ni določen, njihovo število pa je logično neomejeno.

Ker vrstice v tabeli niso urejene, je nemogoče izbrati vrstico glede na njen položaj - med njimi ni "prve", "druge" ali "zadnje". Vsaka tabela ima enega ali več stolpcev, katerih vrednosti enolično identificirajo vsako njeno vrstico. Takšen stolpec (ali kombinacija stolpcev) se imenuje primarni ključ. Številskim zapisom v tabeli je pogosto uvedeno umetno polje. Takšno polje je lahko na primer njegovo vrstno polje, ki lahko zagotovi edinstvenost vsakega zapisa v tabeli. Ključ mora imeti naslednje lastnosti.

Edinstvenost. V danem trenutku nobeni dve različni relacijski zbirki nimata enake vrednosti za kombinacijo atributov, vključenih v ključ. To pomeni, da v tabeli ne moreta biti dve vrstici z isto identifikacijsko številko ali številko potnega lista.

Minimalizem. Nobenega od atributov, vključenih v ključ, ni mogoče izključiti iz ključa, ne da bi pri tem kršili edinstvenost. To pomeni, da ne bi smeli ustvariti ključa, ki vključuje številko potnega lista in identifikacijsko številko. Dovolj je, da uporabite katerega koli od teh atributov za enolično identifikacijo tuple. Prav tako ne smete vključiti neenotnega atributa v ključ, to pomeni, da je uporaba kombinacije identifikacijske številke in imena zaposlenega kot ključa prepovedana. Z izključitvijo imena zaposlenega iz ključa je mogoče vsako vrstico še vedno enolično identificirati.

Vsaka relacija ima vsaj en možen ključ, saj celota vseh njenih atributov izpolnjuje pogoj unikatnosti - to izhaja iz same definicije relacije.

Eden od možnih ključev je naključno izbran kot primarni ključ. Preostali možni ključi, če obstajajo, se vzamejo kot alternativni ključi.Če na primer izberete identifikacijsko številko kot primarni ključ, bo številka potnega lista nadomestni ključ.

Odnos tabel je najpomembnejši element relacijskega podatkovnega modela. Podprto je tujih ključev.

Pri opisovanju modela relacijske baze podatkov se za isti koncept pogosto uporabljajo različni izrazi, odvisno od nivoja opisa (teorija ali praksa) in sistema (Access, SQL Server, dBase). V tabeli 2.3 vsebuje povzetek uporabljenih izrazov.

Tabela 2.3. Terminologija baze podatkov

Teorija baz podatkov____________ Relacijske baze podatkov_________ SQL Server __________

Tabela relacije Tabela Tabela

Tuple Record Row

AttributeField_______________Column

Relacijske baze podatkov

Relacijska baza podatkov je niz relacij, ki vsebujejo vse informacije, ki morajo biti shranjene v bazi podatkov. To pomeni, da baza podatkov predstavlja niz tabel, potrebnih za shranjevanje vseh podatkov. Tabele relacijske baze podatkov so med seboj logično povezane.Zahteve za načrtovanje relacijske baze podatkov na splošno lahko skrčimo na več pravil.

О Vsaka tabela ima edinstveno ime v bazi podatkov in je sestavljena iz vrstic istega tipa.

O Vsaka tabela je sestavljena iz določenega števila stolpcev in vrednosti. V stolpcu ene vrstice ni mogoče shraniti več kot ene vrednosti. Na primer, če obstaja tabela s podatki o avtorju, datumu objave, nakladi itd., potem stolpec z imenom avtorja ne more shraniti več kot enega priimka. Če knjigo pišeta dva ali več avtorjev, boste morali uporabiti dodatne tabele.

O V nobenem trenutku v tabeli ne bosta dve vrstici, ki bi se podvajali. Vrstice se morajo razlikovati v vsaj eni vrednosti, da lahko enolično identificirate katero koli vrstico v tabeli.

О Vsakemu stolpcu je dodeljeno edinstveno ime v tabeli; zanj je nastavljen določen tip podatkov, tako da so v ta stolpec uvrščene homogene vrednosti (datumi, priimki, telefonske številke, denarni zneski itd.).

O Celotna informacijska vsebina baze podatkov je predstavljena kot eksplicitne vrednosti samih podatkov in to je edina metoda predstavitve. Relacije med tabelami na primer temeljijo na podatkih, shranjenih v ustreznih stolpcih, in ne na podlagi kakršnih koli kazalcev, ki umetno definirajo relacije.

О Pri obdelavi podatkov lahko prosto dostopate do katere koli vrstice ali stolpca tabele. Vrednosti, shranjene v tabeli, ne nalagajo nobenih omejitev glede vrstnega reda dostopa do podatkov. Opis stolpcev,