Napomena: Ovo i naredna dva predavanja posvećena su teoriji relacionih baza podataka. Budući da je cijeli relacijski pristup organizaciji baze podataka čisto praktičan, ova teorija je uglavnom pragmatična. Glavni problem koji teorija relacijske baze podataka ima za cilj da riješi je otkrivanje korisnih svojstava određenih shema baze podataka i razvoj načina za konstruiranje takvih shema. Ovaj problem se obično ukratko naziva problem dizajna relacijske baze podataka.

Uvod

Uprkos svojoj praktičnoj orijentaciji, teorija relacione baze podataka je samostalna naučna oblast u kojoj su radili (i rade) brojni poznati istraživači čija će se imena pojavljivati ​​u našim predavanjima. U ovom kursu nismo planirali detaljno opisati glavne rezultate na terenu. Naš cilj je da pružimo samo definicije i izjave neophodne za opšte razumevanje procesa dizajn relacione baze podataka na osnovu normalizacije.

Budući da su najvažnija svojstva relacionih baza podataka sa praktične tačke gledišta zasnovana na konceptu funkcionalna zavisnost, kratku raspravu o relevantnim teorijskim pitanjima uključili smo u posebno predavanje. Među ovim pitanjima, zatvaranja i pokrivaju skupove funkcionalnih zavisnosti, Armstrongovi aksiomi i Heathova teorema o dovoljnom uslovu dekompozicija odnosa bez gubitaka. Koncepti i iskazi ovog predavanja su zaista neophodni za savladavanje gradiva u 7. predavanju, ali smo takođe nastojali da čitaocima na jednostavnim primerima pokažemo šta je to teorija relacione baze podataka, koji je nivo njegove složenosti i koliko je intuitivan.

Napominjemo da nismo odvajali teorijski materijal koji se tiče višeznačne zavisnosti I zavisnosti od veze. To je učinjeno iz dva razloga. Prvo, ove vrste zavisnosti su manje uobičajene u modeliranju predmetna oblast koristeći baze podataka. Stoga smo smatrali da je dovoljno da u okviru predavanja 8 iznesemo samo osnove relevantnog teorijskog materijala. Drugo, iako teorija višeznačne zavisnosti I zavisnosti od veze, zapravo, nije mnogo komplikovanije od teorije funkcionalne zavisnosti, njegove definicije i izjave su previše glomazne za ovaj kurs.

Funkcionalne zavisnosti

Najvažnije sa praktične tačke gledišta normalne forme odnosa zasnivaju se na fundamentalnim teorije relacionih baza podataka koncept funkcionalna zavisnost. Za daljnju prezentaciju trebat će nam nekoliko definicija i izjava (objašnjavaćemo ih i ilustrovati u nastavku).

Opće definicije

Neka se da varijabla relacije r , a X i Y su proizvoljni podskupovi r zaglavlja ("kompozitni" atributi).

U značenju varijabla relacije r atribut Y je funkcionalno ovisan o atributu X ako i samo ako svaka vrijednost X odgovara tačno jednoj vrijednosti Y. U ovom slučaju se takođe kaže da je atribut X funkcionalno definiše atribut Y (X je determinanta ( odrednica) za Y, a Y zavisi od X). Ovo ćemo označiti kao r.X->r.Y.

Na primjer, koristit ćemo relaciju EMPLOYEE_PROJECTS (SLUN_NAME, SLU_NAME, SLU_ZARP, PRO_NOM, PROJECT_RUK)(Sl. 6.1). Očigledno, ako je SLU_NOM primarni ključ veze ZAPOSLENI, onda je za ovaj odnos fer funkcionalna zavisnost (FD) SLN_NAME->SERV_NAME .

Zapravo, za tijelo veze EMPLOYEES_PROJECTS u obliku u kojem je prikazano na sl. 6.1, sljedeći FD (1) se također izvršavaju:

Rice. 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) ->(PROJESLUN_NAME)->, PROJESLUN_NAME_ZARP … itd.

Budući da su imena svih zaposlenih različita, zadovoljeni su i sljedeći FD (2):

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

Štaviše, za primjer na sl. 6.1 je zadovoljen i FD (3):

SLU_ZARP->PRO_NOM

Međutim, imajte na umu da se priroda FD grupe (1) razlikuje od prirode FD grupa (2) i (3). Logično je pretpostaviti da identifikacioni brojevi zaposlenih uvek treba da budu različiti, a svaki projekat ima samo jednog menadžera. Stoga, FD-ovi grupe (1) moraju biti istiniti za bilo koju valjanu vrijednost varijabla relacije EMPLOYEES_PROJECTS i može se smatrati kao invarijante, ili ograničenja integriteta ovo varijabla relacije.

Grupni FD (2) zasnivaju se na manje prirodnoj pretpostavci da svi zaposleni imaju različita imena. Ovo važi za primjer na sl. 6.1, ali je moguće da tokom vremena FD grupe (2) neće biti zadovoljene ni za jednu vrijednost varijabla relacije EMPLOYEES_PROJECTS.

Konačno, FD grupe (3) zasniva se na vrlo neprirodnoj pretpostavci da dva zaposlenika uključena u različite projekte ne primaju istu platu. Opet, ova pretpostavka je tačna za primjer na sl. 6.1, ali najvjerovatnije je to slučajnost.

Ubuduće će nas zanimati samo oni funkcionalne zavisnosti, koji mora biti zadovoljen za sve moguće vrijednosti varijable odnosa.

Imajte na umu da ako je atribut A relacije r mogući ključ, onda za bilo koji atribut B ove relacije uvijek vrijedi

PROGRAMIRANJE U DELPHI 6 OKRUŽENJU

Baza podataka. Kreirajte izvještaj koristeći Word.

Odobreno od Uređivačko-izdavačkog vijeća

univerzitet kao laboratorijska radionica

Voronjež 2004

UDK 681.3

Vorobyov E.I., Korotkevich D.E. Programiranje u Delphi 6 okruženju: Laboratorijska radionica: Dio 2: Baze podataka. Kreirajte izvještaj koristeći Word. Streams. Voronjež: Voronjež. stanje tech. Univ., 2004. 107 str.

U drugom dijelu laboratorijske radionice razmatraju se teorijske i praktične informacije za pisanje programa u Delphi 6 okruženju na temu: “Dizajniranje baza podataka, kreiranje izvještaja u Wordu i korištenje niti pri kreiranju aplikacija visokih performansi.”

Publikacija ispunjava uslove Državnog obrazovnog standarda visokog stručnog obrazovanja na smeru 230100 „Informatika i računarstvo“, specijalnost 230104 „Sistemi projektovanja pomoću računara“, disciplina „Programiranje na jezicima visokog nivoa“.

Table 3. Il. 19. Bibliografija: 7 naslova.

Naučni urednik: dr. tehnič. nauka, prof. Ya.E. Lvovich

Recenzenti: Katedra za računarstvo, Voronješka šumarska akademija (šef katedre, doktor tehničkih nauka, prof. V.E. Mezhov);

Dr. Tech. nauka, prof. O.Yu.Makarov

© Vorobyov E.I., Korotkevič D.E., 2004

© Dizajn. Voronješka država

Tehnički univerzitet, 2004

Uvod

Koncept baze podataka

Baze podataka se smatraju glavnom prednošću Delphi-ja. Čak su i specijalizirani jezici za rad s bazama podataka (kao što je MS Visual FoxPro) očito inferiorni u jednostavnosti i snazi ​​programiranja ove vrste aplikacija. Delphi skriva svu složenost i istovremeno daje najveću moć. Nikada nije postojao zadatak koji se u Delphiju ne bi mogao implementirati u kratkom vremenskom periodu. A glavna stvar je da se sve ovo implementira vrlo zgodno i lako razumljivo. U Delphiju možete kreirati jednostavne aplikacije, čak i sa složenim bazama podataka, bez ijednog reda koda. Ovaj tutorijal pokriva laboratorijske zadatke za savladavanje tehnika za rad sa lokalnim bazama podataka.

Teorija relacionih baza podataka

Prije deset godina, programiranje baze podataka bilo je vrlo težak zadatak. Danas je to teško zamisliti, jer je zahvaljujući Delphiju proces pisanja programa pojednostavljen, a broj varijanti baza podataka već se kreće na desetine.

Baze podataka se dijele na lokalne (instalirane na računaru klijenta, gdje se program pokreće) i udaljene (instalirane na serveru, udaljenom računaru). Serverske baze podataka nalaze se na udaljenom računaru i rade pod kontrolom serverskog softvera. Njihove glavne prednosti uključuju mogućnost istovremenog rada s jednom bazom podataka od strane više korisnika, a istovremeno postoji minimalno opterećenje mreže. Postoje i mrežne baze podataka koje stvaraju preveliko opterećenje na mreži i koje su nezgodne za korištenje i za programera i za krajnjeg korisnika. Kada se program poveže sa mrežnom bazom podataka, preuzima njenu skoro kompletnu kopiju sa servera. Ako ste izvršili promjene, vaša kopija će biti u potpunosti preuzeta nazad. Ovo je vrlo nezgodno jer stvara veliko opterećenje na mreži zbog prevelikog prijenosa podataka. U klijent-server tehnologiji, klijentski program šalje jednostavan tekstualni zahtjev serveru da primi neke podatke. Server ga obrađuje i vraća samo potreban dio podataka. Kada treba da promenite neki podatak, serveru se ponovo šalje zahtev da ga promeni, a server menja podatke u svojoj bazi podataka. Dakle, uglavnom se samo tekstualni zahtjevi prenose preko mreže, koji općenito zauzimaju manje od kilobajta. Sve podatke obrađuje server, što znači da je klijentova mašina znatno manje opterećena i nije toliko zahtjevna za resurse. Server šalje klijentu samo najpotrebnije podatke, što znači da nema nepotrebnog preuzimanja kopije cijele baze podataka. Zahvaljujući svemu tome, mrežne baze podataka su već zastarjele i praktički se ne koriste. Oni su gotovo u potpunosti zamijenjeni tehnologijom klijent-server. Ali lokalne baze podataka će uvijek živjeti. Format njihovog skladištenja se može promeniti ili se mogu dodati neke nove funkcije, ali same baze podataka će postojati. Za dalje razmatranje, moramo definisati novi koncept - sto. Do sada su razmatrani samo opšti principi, pa je korišćen opšti koncept baze podataka. Tabela baze podataka je poput dvodimenzionalnog niza u kojem su podaci raspoređeni u kolonu (primjenac tabele je Excel). Baza podataka je, grubo govoreći, samo datoteka koja može pohraniti od jedne do nekoliko tabela. Većina lokalnih baza podataka može pohraniti samo jednu tablicu (dBase, Paradox, XML). Ali postoje predstavnici lokalnih baza podataka, gdje je nekoliko tablica sadržano u jednoj datoteci (na primjer, Access).

Lokalne baze podataka

Među lokalnim bazama podataka, razmotrimo relacijske kao najčešće. Šta je relaciona baza podataka? Ovo je tabela u kojoj su kolone nazivi podataka pohranjenih u njoj, a svaki red pohranjuje podatke. Tabela baze podataka je slična Excel tabeli (da budemo precizniji, Excel pohranjuje svoje podatke u vlasničkom formatu izgrađenom na tehnologiji baze podataka). Tabele lokalne baze podataka mogu biti pohranjene na lokalnom tvrdom disku ili centralno pohranjene na mrežnom disku na serveru datoteka. Ove datoteke se mogu kopirati pomoću standardnih alata kao i svaki drugi fajl, jer same tabele baze podataka nisu vezane za određenu lokaciju. Glavna stvar je da program može pronaći tabelu. Svaka tabela mora imati jedno jedinstveno polje koje će jedinstveno identificirati red. Ovo polje se zove ključno polje. Ova polja se vrlo često koriste za povezivanje nekoliko tabela zajedno. Ali čak i ako tabela nije povezana, ključno polje je i dalje obavezno. Preporučljivo je koristiti numerički tip kao ključ, a ako baza to dozvoljava, bolje bi bilo da bude tipa „autoinkrement“ (automatski povećavajući/opadajući broj ili brojač). Imena kolona u tabeli baze podataka također moraju biti jedinstvena, ali u ovom slučaju ne nužno numerička. Mogu se zvati kako god želite, samo da je jedinstveno i razumljivo. Svaka kolona (polje baze podataka) mora imati određeni tip. Broj tipova i njihove varijante zavise od tipa baze podataka, na primjer, dBASE format (datoteke sa ekstenzijom DBF) podržava samo 6 tipova, a Paradox već podržava do 15. Baza podataka može biti pohranjena u jednoj datoteci (Pristup ) ili u nekoliko (Paradox, dBase). Tačnije, tabelarni podaci se uvijek pohranjuju u jednu datoteku, ali dodatne informacije mogu biti smještene u odvojenim datotekama. Dodatne informacije mogu uključivati ​​indekse, ograničenja ili listu zadanih vrijednosti za određena polja. Ako se barem jedna od datoteka ošteti ili izbriše, podaci mogu postati nedostupni za uređivanje.

Šta se desilo indeksi? Vrlo često podaci iz tabela prolaze kroz neku vrstu promjena, tako da prije nego što uredite bilo koji red, morate ga pronaći. Čak i statične tabele koje se koriste kao referentne knjige takođe su podložne operacijama pretraživanja pre prikazivanja traženih podataka. Pretraga je prilično dugotrajna operacija, posebno ako tabela sadrži puno redova. Indeksi imaju za cilj da ubrzaju ovu proceduru, a mogu se koristiti i kao polazna tačka za sortiranje. U ovoj fazi, dovoljno je znati da se neindeksirano polje ne može naručiti.

Ako vam je potreban neki sto da se naruči po polju " Prezime", onda ovo polje prvo mora biti indeksirano. Onda samo treba da naznačite da tabela sada treba da radi sa tim i takvim indeksom i automatski će se sortirati.

U dobro dizajniranoj bazi podataka, redundantnost podataka je eliminisana i vjerovatnoća pohranjivanja nekonzistentnih podataka je minimizirana. Dakle, kreiranje baza podataka ima dva glavna cilja: smanjiti redundantnost podataka i povećati njihovu pouzdanost.

Životni ciklus bilo kojeg softverskog proizvoda, uključujući sistem za upravljanje bazom podataka, sastoji se (u velikoj mjeri) od faza dizajna, implementacije i rada.

Naravno, najznačajniji faktor u životnom ciklusu aplikacije baze podataka je faza dizajna. Performanse sistema i njegovo informaciono bogatstvo, a time i njegov životni vek, zavise od toga koliko je pažljivo osmišljena struktura baze podataka i koliko su jasno definisane veze između njenih elemenata.

Zahtjevi baze podataka

Dakle, dobro dizajnirana baza podataka:

1. Zadovoljava sve korisničke zahtjeve za sadržaj baze podataka. Prije dizajniranja baze podataka potrebno je provesti opsežno istraživanje zahtjeva korisnika za funkcionalnošću baze podataka.

2. Osigurava konzistentnost i integritet podataka. Prilikom dizajniranja tabela potrebno je definirati njihove atribute i neka pravila koja ograničavaju mogućnost da korisnik unese pogrešne vrijednosti. Za provjeru podataka prije nego što ih direktno upiše u tabelu, baza podataka mora pozvati pravila modela podataka i na taj način osigurati da se održava integritet informacija.

3. Pruža prirodno, lako razumljivo strukturiranje informacija. Visokokvalitetna konstrukcija baze podataka omogućava vam da upite bazi podataka učinite „transparentnijim“ i lakšim za razumijevanje; Posljedično, smanjuje se vjerovatnoća unosa pogrešnih podataka i poboljšava se kvalitet održavanja baze podataka.

4. Zadovoljava zahtjeve performansi baze podataka korisnika. Sa velikim količinama informacija, problemi održavanja produktivnosti

početi igrati glavnu ulogu, odmah "istaknuvši" sve nedostatke faze dizajna.

Sljedeće tačke predstavljaju osnovne korake dizajna baze podataka:

1. Odredite informacijske potrebe baze podataka.

2. Analizirajte objekte iz stvarnog svijeta koje je potrebno modelirati u bazi podataka. Iz ovih objekata formirajte entitete i karakteristike ovih entiteta (na primjer, za entitet „dio”, karakteristike mogu biti „ime”, „boja”, „težina” itd.) i formirajte njihovu listu.

3. Usporedite entitete i karakteristike - tabele i kolone (polja) u notaciji DBMS-a koji ste odabrali (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle, itd.).

4. Definirajte atribute koji jedinstveno identificiraju svaki objekt.

5. Razviti pravila koja će uspostaviti i održavati integritet podataka.

6. Uspostaviti veze između objekata (tabela i kolona), normalizirati tabele.

7. Planirati pitanja pouzdanosti podataka i, po potrebi, očuvanja tajnosti informacija.

Povezane informacije.

Relaciona algebra je zasnovana na teoriji skupova i osnova je logike baze podataka.
Kada sam tek proučavao strukturu baza podataka i SQL-a, preliminarno upoznavanje sa relacijskom algebrom uvelike mi je pomoglo da se daljnje znanje pravilno uklopi u moju glavu, te ću pokušati da ovaj članak ima sličan učinak.

Dakle, ako namjeravate započeti svoje studije u ovoj oblasti ili ste samo zainteresirani, kliknite na mačku.

Relaciona baza podataka

Prvo, predstavimo koncept relacijske baze podataka u kojoj ćemo izvoditi sve radnje.

Relaciona baza podataka je kolekcija relacija koje sadrže sve informacije koje moraju biti pohranjene u bazi podataka. U ovoj definiciji zanima nas pojam relacija, ali ćemo ga za sada ostaviti bez striktne definicije.
Zamislimo bolje tablicu proizvoda.

PROIZVODI stol

ID	NAME	COMPANY	CIJENA
123	Kolačići	Dark Side LLC	190
156	Tea	Dark Side LLC	60
235	Ananas	OJSC “Frukty”	100
623	Paradajz	OOO "Povrće"	130

Tabela se sastoji od 4 reda, red u tabeli je torka u teoriji relacija. Skup uređenih točaka naziva se relacija.
Prije definiranja odnosa, uvedemo još jedan pojam - domena. Domeni u odnosu na tabelu su kolone.

Radi jasnoće, sada uvodimo strogu definiciju relacije.

Neka je dat N skupova D1,D2, …. Dn (domene), relacija R nad ovim skupovima je skup uređenih N-torki oblika , gdje d1 pripada D1, itd. Skupovi D1,D2,..Dn nazivaju se domeni relacije R.
Svaki element tuple predstavlja vrijednost jednog od atributa koji odgovara jednom od domena.

Ključevi u odnosima

U vezi, zahtjev je da sve tuple moraju biti različite. Za jedinstvenu identifikaciju tuple postoji primarni ključ. Primarni ključ je atribut ili skup minimalnog broja atributa koji jedinstveno identificira određenu torbu i ne sadrži dodatne atribute.
Implikacija je da svi atributi u primarnom ključu moraju biti neophodni i dovoljni za identifikaciju određenog tuple-a, a izostavljanje bilo kojeg od atributa u ključu će ga učiniti nedovoljnim za identifikaciju.
Na primjer, u takvoj tablici ključ će biti kombinacija atributa iz prve i druge kolone.

DRIVERS sto

Može se vidjeti da organizacija može imati nekoliko drajvera, a da bi se upravljački program jedinstveno identificirao, potrebne su i vrijednosti iz kolone „Naziv organizacije” i iz kolone „Naziv vozača”. Takav ključ se naziva kompozitni ključ.

U relacijskoj bazi podataka, tabele su međusobno povezane i povezane jedna s drugom kao glavne i podređene tablice. Veza između glavne i podređene tabele se vrši preko primarnog ključa glavne tabele i stranog ključa podređene tabele.
Strani ključ je atribut ili skup atributa koji je primarni ključ u glavnoj tablici.

Ova pripremna teorija će biti dovoljna za upoznavanje sa osnovnim operacijama relacione algebre.

Operacije relacione algebre

Osnovnih osam operacija relacione algebre predložio je E. Codd.

• Udruženje
• Raskrsnica
• Oduzimanje
• Kartezijanski proizvod
• Uzorak
• Projekcija
• Compound
• Division

Prva polovina operacija je slična istim operacijama na skupovima. Neke operacije se mogu izraziti u terminima drugih operacija. Pogledajmo većinu operacija na primjerima.

Za razumijevanje, važno je zapamtiti da je rezultat bilo koje algebarske operacije na relacijama druga relacija, koja se zatim može koristiti u drugim operacijama.
Kreirajmo još jednu tabelu koja će nam biti korisna u primjerima.

PRODAVCI sto

ID	PRODAVAC
123	OOO “Dart”
156	OJSC "Vedro"
235	CJSC “Baza povrća”
623	AD "Firma"

Složimo se da je u ovoj tabeli ID strani ključ povezan sa primarnim ključem tabele PRODUCTS.

Prvo, pogledajmo najjednostavniju operaciju - naziv veze. Njegov rezultat će biti ista relacija, odnosno izvođenjem operacije PROIZVODI, dobićemo kopiju relacije PROIZVODI.

Projekcija

Projekcija je operacija u kojoj se atributi iz relacije izdvajaju samo iz navedenih domena, odnosno iz tabele se biraju samo potrebni stupci, a ako se dobije više identičnih torki, tada ostaje samo jedna instanca takve torke u rezultirajuću relaciju.
Na primjer, napravimo projekciju na tablici PROIZVODI odabirom ID-a i CIJENE iz nje.

Sintaksa operacije:
π (ID, CIJENA) PROIZVODI

U uvjetu uzorka, možemo koristiti bilo koji Boolean izraz. Napravimo još jedan odabir sa cijenom većom od 90 i ID-om proizvoda manjim od 300:

σ(CIJENA>90^ID<300) PRODUCTS

Množenje

Množenje ili Kartezijanski proizvod je operacija koja se izvodi na dvije relacije, kao rezultat koje dobijamo relaciju sa svim domenima iz dvije početne relacije. Korke u ovim domenima će biti sve moguće kombinacije torki iz početnih relacija. Na primjeru će biti jasnije.

Dobijamo kartezijanski proizvod tablica PROIZVODI i PRODAVAČA.
Sintaksa operacije:

PROIZVODI × PRODAVCI
Primetićete da ove dve tabele imaju isti ID domen. U ovoj situaciji, domeni sa istim imenom imaju prefiks sa imenom odgovarajuće veze, kao što je prikazano u nastavku.
Radi kratkoće, pomnožimo ne potpune omjere, već uzorke s ID uvjeta<235

(iste tuple su označene bojom)

PROIZVODI.ID	NAME	COMPANY	CIJENA	SELLERS.ID	PRODAVAC
123	Kolačići	Dark Side LLC	190	123	OOO “Dart”
156	Tea	Dark Side LLC	60	156	OJSC "Vedro"
123	Kolačići	Dark Side LLC	190	156	OJSC "Vedro"
156	Tea	Dark Side LLC	60	123	OOO “Dart”

Za primjer korištenja ove operacije, zamislite potrebu za odabirom prodavača s cijenama manjim od 90. Bez proizvoda, bilo bi potrebno prvo dobiti ID-ove proizvoda iz prve tablice, a zatim pomoću ovih ID-ova iz druge tablice dobiti potrebne imena PRODAVACA, a korištenjem proizvoda sljedeći upit bi bio:

π (PRODAVAC) σ (RODUCTS.ID=SELLERS.ID ^ PRICE<90) PRODUCTS × SELLERS

Kao rezultat ove operacije dobijamo relaciju:

PRODAVAC

OJSC "Vedro"

Povezanost i prirodna povezanost

Operacija spajanja je inverzna od operacije projekcije i stvara novu relaciju od dvije postojeće. Nova relacija se dobija spajanjem torki prve i druge relacije, dok su relacije u kojima se poklapaju vrednosti navedenih atributa podložne konkatenaciji. Konkretno, ako povežete relacije PROIZVODI i PRODAVAČI, ovi atributi su atributi domena ID-a.

Također, radi jasnoće, možete zamisliti vezu kao rezultat dvije operacije. Prvo se uzima proizvod izvornih tabela, a zatim iz rezultirajuće relacije vršimo selekciju uz uslov jednakosti atributa iz istih domena. U ovom slučaju uvjet je jednakost PRODUCTS.ID i SELLERS.ID.

Hajde da pokušamo da povežemo relacije PROIZVODI i PRODAVCE i dobijemo relaciju.

PROIZVODI.ID	NAME	COMPANY	CIJENA	SELLERS.ID	PRODAVAC
123	Kolačići	Dark Side LLC	190	123	OOO “Dart”
156	Tea	Dark Side LLC	60	156	OJSC "Vedro"
235	Ananas	OJSC “Frukty”	100	235	CJSC “Baza povrća”
623	Paradajz	OOO "Povrće"	130	623	AD "Firma"

Prirodno spajanje prima sličnu relaciju, ali ako imamo ispravno konfiguriranu shemu u bazi podataka (u ovom slučaju, primarni ključ tablice PRODUCTS ID je povezan sa stranim ključem tablice SELLERS ID), tada rezultirajuća relacija sadrži samo jedan ID domen.

Sintaksa operacije:
PROIZVODI ⋈ PRODAVCI;

Dobijate ovu relaciju:

PROIZVODI.ID	NAME	COMPANY	CIJENA	PRODAVAC
123	Kolačići	Dark Side LLC	190	OOO “Dart”
156	Tea	Dark Side LLC	60	OJSC "Vedro"
235	Ananas	OJSC “Frukty”	100	CJSC “Baza povrća”
623	Paradajz	OOO "Povrće"	130	AD "Firma"

Presjek i oduzimanje.

Rezultat operacije presjeka bit će relacija koja se sastoji od torki koje su u potpunosti uključene u obje relacije.
Rezultat oduzimanja će biti relacija koja se sastoji od torki koje su torke prve relacije, a ne torke druge relacije.
Ove operacije su slične istim operacijama nad skupovima, pa mislim da ih nema potrebe detaljno opisivati.

Izvori informacija

• Osnove korištenja i dizajniranja baza podataka - V. M. Ilyushechkin
• kurs predavanja Uvod u baze podataka - Jennifer Widom, Univerzitet Stanford

Bio bih zahvalan na obrazloženim komentarima

Ukratko o bitnim stvarima.

Normalizacija baze podataka

Prvi normalni oblik (1NF)

• nema duplih grupa podataka
• atomičnost podataka je zagarantovana (svi podaci su autonomni i nezavisni).

Na najvišem nivou, to se postiže kreiranjem primarnog ključa, zatim premeštanjem ponavljajućih grupa podataka u nove tabele, kreiranjem primarnih ključeva za ove tabele i tako dalje. Osim toga, morate podijeliti sve zapise čije kolone sadrže složene informacije u zasebne redove za svaki dio podataka kolone.

Drugi normalni oblik (2NF)

• tabela zadovoljava uslove 1NF
• svaka kolona ovisi o cijelom ključu, a ne o njegovom dijelu.

Treći normalni oblik (3NF)

• tabela zadovoljava uslove 2NF
• nijedna kolona ne zavisi od kolone koja nije dio primarnog ključa
• ne sadrži izvedene podatke

Drugi normalni oblici koji nemaju veliku praktičnu vrijednost:

Boyce-Codd normalna forma

Opcija 3NF. Dizajniran da riješi situaciju u kojoj postoji mnogo preklapajućih ključeva kandidata. Zapravo, ne postoji logično opravdanje izvan akademske zajednice.

Četvrta normalna forma

Dizajniran za rješavanje problema s viševrijednim ovisnostima. Takve situacije nastaju ako, u tablici smanjenoj na 3NF, jedan stupac kompozitnog primarnog ključa ovisi o drugom stupcu primarnog ključa.

Peti normalni oblik

Koristi se pri radu sa dekompozicijom odnosa sa i bez gubitaka. Nastaje u situaciji kada je moguće jednu relaciju podijeliti na više različitih relacija, ali je nakon toga više nećemo moći logički vratiti u prvobitni oblik.

Šesti normalni oblik (normalni oblik ključa domene)

Osigurava da nema modifikacijskih anomalija u bazi podataka. U realnim uslovima to je praktično nedostižno.

Veza.

Jednom sam čula od žena da su muškarci
odmah pokušajte da napustite prostoriju u kojoj
Čula se riječ "veza".<...>ključ uspjeha
odnosi su svačija svijest o svojoj ulozi
s tim u vezi, kao i pravila i ograničenja,
nametnuta ovim odnosom.
(C) Robert Viera, “Profesionalno SQL Server 2000 programiranje”

Vrste odnosa

• Jedan na jedan (ima smisla kada se podudarni podaci moraju pohraniti u različite baze podataka ili kada je premašena maksimalna veličina podataka reda)
• Nula ili jedan prema jedan
• Jedan prema više
• Jedan do -nula, -jedan ili -više
• Mnogo-prema-više (spojne tablice)

Udruženja

INNER JOIN

Exclusive join. Rezultat odabira uključuje samo one zapise tablice koji imaju podudaranja u uparenoj tablici za dati uvjet.

LIJEVO|DESNO PRIDRUŽENJE

Inclusive join. Rezultat odabira uključuje zapise iz tabele lijevo/desno od PRIDRUŽITE SE respektivno. U tom slučaju će se popuniti podaci iz „uparenog“ zapisa koji nedostaje NULL.
FROM left_table LIJEVO PRIDRUŽENJE desno_table– svi zapisi iz lijeve tabele su uključeni left_table
IZ lijeve_tablice DESNO PRIDRUŽENJE desnoj_tablici– uključeni su svi zapisi iz desne tabele right_table

FULL JOIN

Inclusive join. Rezultat odabira uključuje ne samo zapise koji se podudaraju u drugoj tabeli, već i zapise iz obje tabele za koje nije pronađeno podudaranje u drugoj tabeli. U ovom slučaju, podaci iz „uparenog“ zapisa koji nedostaju biće popunjeni sa NULL.

CROSS JOIN

Unakrsni spoj (kartezijanski proizvod). Svaki zapis iz jedne tabele se uparuje sa svakim zapisom iz druge tabele. Broj rezultirajućih zapisa jednak je proizvodu broja zapisa u obje tabele.

Principi za uređenje nekoliko PRIDRUŽITE SE's

Ako trebate spojiti nekoliko stolova, morate zapamtiti dva principa:

1. Svi sindikati na lijevo PRIDRUŽITE SE tretira se kao jedna tabela za uključivanje ili isključivanje iz upita.
2. Svi sindikati su na DESNICI PRIDRUŽITE SE TAKOĐER se tretira kao jedna tabela za uključivanje ili isključivanje iz upita.

Posljedica ovih principa je sljedeća preporuka za formiranje složenih asocijacija:

• Gdje god je moguće, trebate koristiti INNER JOIN.
• Ako postoji potreba za korištenjem OUTER JOIN-ova, treba ih postaviti posljednje, a INNER JOIN-ove treba postaviti na početak spajanja.

P.S. Sve gore navedeno su opšti „postulati“ teorije relacionih baza podataka, koji nisu vezani za karakteristike određenih DBMS-ova.

Model podataka je skup struktura podataka i operacija za njihovu obradu. Koristeći model podataka, možete vizualno predstaviti strukturu objekata i odnose uspostavljene između njih. Terminologiju modela podataka karakterišu koncepti „elementa podataka“ i „pravila vezivanja“. Element podataka opisuje bilo koji skup podataka, a pravila asocijacije definiraju algoritme za međusobno povezivanje elemenata podataka. Do danas je razvijeno mnogo različitih modela podataka, ali se u praksi koriste tri glavna. Postoje hijerarhijski, mrežni i relacioni modeli podataka. Shodno tome, govore o hijerarhijskim, mrežnim i relacionim DBMS-ovima.

O Hijerarhijski model podataka. Hijerarhijski organizirani podaci vrlo su česti u svakodnevnom životu. Na primjer, struktura visokoškolske ustanove je hijerarhijska struktura na više nivoa. Hijerarhijska (stablo) baza podataka se sastoji od uređenog skupa elemenata. U ovom modelu, početni elementi dovode do drugih elemenata, a ti elementi zauzvrat dovode do daljnjih elemenata. Svaki podređeni element ima samo jedan roditeljski element.

Organizacione strukture, spiskovi materijala, sadržaji u knjigama, planovi projekata i mnogi drugi skupovi podataka mogu se prikazati u hijerarhijskom obliku. Integritet veza između predaka i potomaka se automatski održava. Osnovno pravilo: nijedno dijete ne može postojati bez svog roditelja.

Glavni nedostatak ovog modela je potreba da se prilikom projektovanja koristi hijerarhija koja je bila osnova baze podataka. Potreba za stalnom reorganizacijom podataka (a često i nemogućnost te reorganizacije) dovela je do stvaranja općenitijeg modela – mrežnog modela.

O Mrežni podatkovni model. Mrežni pristup organizaciji podataka je proširenje hijerarhijskog pristupa. Ovaj model se razlikuje od hijerarhijskog po tome što svaki generirani element može imati više od jednog generirajućeg elementa. ■

Budući da mrežna baza podataka može direktno predstavljati sve vrste odnosa svojstvenih podacima odgovarajuće organizacije, ti podaci se mogu kretati, istraživati ​​i ispitivati ​​na različite načine, odnosno mrežni model nije vezan samo jednom hijerarhijom. Međutim, da bi se uputio zahtjev mrežnoj bazi podataka, potrebno je duboko ući u njenu strukturu (imati pri ruci shemu ove baze podataka) i razviti mehanizam za navigaciju bazom podataka, što je značajan nedostatak ovog modela baze podataka. .

O Relacioni model podataka. Osnovna ideja relacionog modela podataka je da se bilo koji skup podataka predstavi kao dvodimenzionalna tabela. U svom najjednostavnijem obliku, relacioni model opisuje jednu dvodimenzionalnu tabelu, ali češće nego ne, model opisuje strukturu i odnose između nekoliko različitih tabela.

Relacioni model podataka

Dakle, svrha informacionog sistema je obrada podaci o objekata stvarnom svijetu, uzimajući u obzir veze između objekata. U teoriji baze podataka, podaci se često nazivaju atributi, i objekti - entiteta. Objekt, atribut i veza su fundamentalni koncepti I.S.

Objekt(ili suština) je nešto što postoji i prepoznatljiv, odnosno objektom se može nazvati ono „nešto“ za što postoji ime i način da se jedan sličan objekt razlikuje od drugog. Na primjer, svaka škola je objekt. Predmeti su i osoba, razred u školi, kompanija, legura, hemijsko jedinjenje, itd. Objekti mogu biti ne samo materijalni objekti, već i apstraktniji koncepti koji odražavaju stvarni svijet. Na primjer, događaji, regije, umjetnička djela; knjige (ne kao štampani proizvodi, već kao djela), pozorišne predstave, filmovi; pravne norme, filozofske teorije itd.

Atribut(ili dato)- ovo je određeni pokazatelj koji karakterizira određeni objekt i uzima određenu numeričku, tekstualnu ili drugu vrijednost za određeni primjerak objekta. Informacioni sistem funkcioniše sa skupovima objekata dizajniranih u odnosu na datu predmetnu oblast, koristeći specifične vrijednosti atributa(podaci) određenih objekata. Na primjer, uzmimo nastavu u školi kao skup objekata. Broj učenika u razredu je podatak koji poprima brojčanu vrijednost (jedan razred ima 28, drugi 32). Ime klase je dato ime koje uzima tekstualnu vrijednost (jedna ima 10A, druga ima 9B, itd.).

Razvoj relacionih baza podataka započeo je kasnih 60-ih, kada su se pojavili prvi radovi koji su razmatrali; mogućnost korištenja poznatih i prirodnih načina predstavljanja podataka - tzv. tabelarnih datalogičkih modela - pri dizajniranju baza podataka.

Osnivačem teorije relacionih baza podataka smatra se zaposlenik IBM-a, dr. E. Codd, koji je objavio članak 6. juna 1970. godine. Relacioni model podataka za velike dijeljene banke podataka(Relacioni model podataka za velike zbirne banke podataka). Ovaj članak je bio prvi koji je koristio termin "relacijski model podataka". Teorija relacionih baza podataka, koju je 70-ih godina u SAD razvio dr E. Codd, ima moćnu matematičku osnovu koja opisuje pravila za efikasno organizovanje podataka. Teorijski okvir koji je razvio E. Codd postao je osnova za razvoj teorije dizajna baza podataka.

E. Codd, kao matematičar po obrazovanju, predložio je korištenje aparata teorije skupova (unija, presjek, razlika, kartezijanski proizvod) za obradu podataka. On je dokazao da se svaki skup podataka može predstaviti u obliku dvodimenzionalnih tabela posebne vrste, poznatih u matematici kao „relacije“.

Relaciona Bazom podataka se smatra ona u kojoj se svi podaci prikazuju korisniku u obliku pravokutnih tablica vrijednosti podataka, a sve operacije na bazi podataka se svode na manipulacije s tabelama.

Tabela se sastoji od kolone (polja) I linije (zapisi); ima ime koje je jedinstveno unutar baze podataka. Table odražava Vrsta objekta stvarnom svijetu (entitet), i svaki od nje string je specifičan objekat. Svaki stupac tablice je zbirka vrijednosti za određeni atribut objekta. Vrijednosti se biraju iz skupa svih mogućih vrijednosti za atribut objekta, koji se zove domena.

U svom najopćenitijem obliku, domen je definiran specificiranjem nekog osnovnog tipa podataka kojem pripadaju elementi domene i proizvoljnim Booleovim izrazom primijenjenim na elemente podataka. Ako procijenite Boolean uslov za stavku podataka i rezultat je istinit, tada ta stavka pripada domeni. U najjednostavnijem slučaju, domen se definira kao valjani potencijalni skup vrijednosti istog tipa. Na primjer, zbirka datuma rođenja svih zaposlenih čini „domen datuma rođenja“, a imena svih zaposlenih čine „domen imena zaposlenih“. Domena datuma rođenja mora imati tip podataka u trenutku, a domena imena zaposlenika mora imati karakterni tip podataka.

Ako dvije vrijednosti dolaze iz istog domena, onda se može napraviti poređenje između te dvije vrijednosti. Na primjer, ako se iz domene datuma rođenja uzmu dvije vrijednosti, možete ih uporediti i odrediti koji je zaposlenik stariji. Ako su vrijednosti preuzete iz različitih domena, onda njihovo poređenje nije dozvoljeno, jer, po svoj prilici, nema smisla. Na primjer, ništa definitivno neće proizaći iz upoređivanja imena i datuma rođenja zaposlenog.

Svaka kolona (polje) ima ime, koje se obično piše na vrhu tabele. Prilikom dizajniranja tabela u okviru određenog DBMS-a moguće je za svako polje odabrati svoje tip, odnosno da se definiše skup pravila za njegov prikaz, kao i da se odrede operacije koje se mogu izvršiti nad podacima pohranjenim u ovom polju. Skupovi tipova mogu varirati između različitih DBMS-ova.

Ime polja mora biti jedinstveno u tabeli, ali različite tabele mogu imati polja sa istim imenom. Svaka tabela mora imati najmanje jedno polje; Polja se nalaze u tabeli u skladu sa redosledom kojim su se njihova imena pojavljivala kada je kreirana. Za razliku od polja, stringovi nemaju imena; njihov redosled u tabeli nije definisan, a njihov broj je logički neograničen.

Budući da redovi u tabeli nisu poređani, nemoguće je odabrati red po njegovoj poziciji - među njima nema "prvog", "drugog" ili "poslednjeg". Svaka tabela ima jednu ili više kolona, ​​čije vrijednosti na jedinstven način identificiraju svaki njen red. Takav stupac (ili kombinacija kolona) se zove primarni ključ. Umjetno polje se često uvodi u zapise brojeva u tabeli. Takvo polje, na primjer, može biti njegovo ordinalno polje, koje može osigurati jedinstvenost svakog zapisa u tabeli. Ključ mora imati sljedeća svojstva.

Jedinstvenost. U bilo kojem trenutku, dvije različite relacijske torke nemaju istu vrijednost za kombinaciju atributa uključenih u ključ. Odnosno, ne mogu postojati dva reda u tabeli koja imaju isti identifikacioni broj ili broj pasoša.

Minimalizam. Nijedan od atributa uključenih u ključ ne može se isključiti iz ključa bez narušavanja jedinstvenosti. To znači da ne biste trebali kreirati ključ koji uključuje i broj pasoša i identifikacijski broj. Dovoljno je koristiti bilo koji od ovih atributa za jedinstvenu identifikaciju tuple. Također ne biste trebali uključivati ​​nejedinstveni atribut u ključ, odnosno korištenje kombinacije identifikacionog broja i imena zaposlenika kao ključa je zabranjeno. Isključivanjem imena zaposlenog iz ključa, svaki red se i dalje može jedinstveno identifikovati.

Svaka relacija ima barem jedan mogući ključ, budući da ukupnost svih njegovih atributa zadovoljava uslov jedinstvenosti – to proizilazi iz same definicije relacije.

Jedan od mogućih ključeva je nasumično odabran kao primarni ključ. Preostali mogući ključevi, ako ih ima, uzimaju se kao alternativni ključevi. Na primjer, ako odaberete identifikacijski broj kao primarni ključ, tada će broj pasoša biti alternativni ključ.

Odnos tabela je najvažniji element relacionog modela podataka. Podržano je strani ključevi.

Kada se opisuje model relacione baze podataka, za isti koncept se često koriste različiti termini, u zavisnosti od nivoa opisa (teorija ili praksa) i sistema (Access, SQL Server, dBase). U tabeli 2.3 daje sažetak korištenih termina.

Tabela 2.3. Terminologija baze podataka

Teorija baze podataka____________ Relacijske baze podataka_________ SQL Server __________

Tabela relacija Tabela Tabela

Tuple Record Red

AttributeField_______________ Kolona

Relacijske baze podataka

Relaciona baza podataka je skup relacija koji sadrži sve informacije koje moraju biti pohranjene u bazi podataka. Odnosno, baza podataka predstavlja skup tabela neophodnih za skladištenje svih podataka. Tabele relacijske baze podataka su logički povezane jedna s drugom.Zahtjevi za dizajniranje relacijske baze podataka općenito se mogu svesti na nekoliko pravila.

O Svaka tabela ima jedinstveno ime u bazi podataka i sastoji se od redova istog tipa.

O Svaka tabela se sastoji od fiksnog broja kolona i vrijednosti. Više od jedne vrijednosti ne može se pohraniti u jednu kolonu reda. Na primjer, ako postoji tabela s podacima o autoru, datumu izdanja, tiražu itd., onda kolona s imenom autora ne može pohraniti više od jednog prezimena. Ako knjigu pišu dva ili više autora, morat ćete koristiti dodatne tabele.

O Ni u jednom trenutku neće postojati dva reda u tabeli koja se međusobno dupliraju. Redovi se moraju razlikovati u najmanje jednoj vrijednosti da bi mogli jedinstveno identificirati bilo koji red u tabeli.

O Svakoj koloni je dodijeljeno jedinstveno ime unutar tabele; za njega je postavljen određeni tip podataka tako da se u ovu kolonu postavljaju homogene vrijednosti (datumi, prezimena, brojevi telefona, novčani iznosi itd.).

O Kompletan informacijski sadržaj baze podataka predstavljen je kao eksplicitne vrijednosti samih podataka, a to je jedini način predstavljanja. Na primjer, odnosi između tabela temelje se na podacima pohranjenim u odgovarajućim stupcima, a ne na osnovu pokazivača koji umjetno definiraju odnose.

O Prilikom obrade podataka, možete slobodno pristupiti bilo kojem redu ili koloni tabele. Vrijednosti pohranjene u tabeli ne nameću nikakva ograničenja u pogledu redoslijeda pristupa podacima. Opis kolona,