Povećanje ekonomskih i statističkih informacija u dvostrukturnim relacionim bazama podataka. Zahtjevi za baze podataka Faze životnog ciklusa baze podataka

Dizajn baze podataka je proces kreiranja projekta baze podataka koji je osmišljen da podrži funkcionisanje privrednog subjekta i doprinese ostvarivanju njegovih ciljeva. To je radno intenzivan proces koji zahtijeva zajedničke napore analitičara, dizajnera i korisnika. Prilikom dizajniranja baze podataka potrebno je uzeti u obzir činjenicu da baza podataka mora zadovoljiti niz zahtjeva.

Ovi zahtjevi su sljedeći.

1. Integritet baze podataka. (Zahtjev za potpunost i konzistentnost podataka).

2. Ponovna upotreba podataka.

3. Brza pretraga i pronalaženje informacija na osnovu zahtjeva korisnika.

4. Lako ažuriranje podataka.

5. Smanjite nepotrebnu redundantnost podataka.

6. Zaštita podataka od neovlašćenog pristupa, izobličenja i uništenja.

Životni ciklus baze podataka(DCDB) je proces dizajniranja, implementacije i održavanja baze podataka. LCBD se sastoji od sljedećih sedam faza:

1) preliminarno planiranje;

2) proveru izvodljivosti;

3) definisanje uslova;

4) idejno rešenje;

5) logičko projektovanje;

6) fizički dizajn;

7) evaluacija performansi i podrška bazi podataka.

Hajde da opišemo glavne zadatke svake faze.

1. Preliminarno planiranje baze podataka. Ovo je važan korak u procesu prelaska sa različitih na integrisane podatke. U ovoj fazi prikupljaju se informacije o aplikativnim programima u upotrebi iu procesu razvoja i datotekama pridruženim njima. Pomaže u uspostavljanju veza između trenutnih aplikacija i načina na koji se koriste informacije o aplikaciji. Osim toga, omogućava vam da odredite buduće zahtjeve baze podataka.

2. Provjera izvodljivosti. Uključuje pripremu izvještaja o tri pitanja:

1) da li je tehnologija – neophodan hardver i softver – dostupna za implementaciju planirane baze podataka? ( tehnološka izvodljivost);

2) Da li su na raspolaganju osoblje, objekti i stručnjaci za uspješnu implementaciju plana baze podataka? ( operativna izvodljivost);

3) hoće li se planirana baza podataka isplatiti? ( ekonomska efikasnost).

3. Definirajte zahtjeve.U ovoj fazi se utvrđuje:

· ciljevi baze podataka;

· informacione potrebe različitih strukturnih odjeljenja i njihovih rukovodilaca;

· zahtjevi za opremom;

· softverski zahtjevi.

4. Idejno rješenje. U ovoj fazi kreiraju se detaljni modeli prilagođenih prikaza podataka domene. Oni su tada integrisani u konceptualni model, koji hvata sve elemente korporativnih podataka koji se učitavaju u bazu podataka. Ovaj model se također naziva konceptualni dijagram baze podataka.

5.Logičan dizajn. U ovoj fazi se bira tip modela podataka. Konceptualni model je prikazan u logički model, već na osnovu struktura karakterističnih za odabrani model. Dakle, ako se odabere relacijski model, tada se razvijaju strukture tablica, određuju njihovi ključevi, uspostavljaju se odnosi između tabela, a kreirani model baze podataka se optimizira (redundantnost podataka je minimizirana). Najčešća metoda u optimizaciji je metoda normalnih oblika ili, drugim riječima, normalizacija podataka

6.Fizički dizajn. U ovoj fazi, od programera se očekuje da donese konačnu odluku o tome kako implementirati bazu podataka koja se kreira. Logički model je proširen karakteristikama potrebnim za određivanje metoda fizičkog skladištenja baze podataka, vrste uređaja za skladištenje, metoda pristupa podacima baze podataka, potrebne količine memorije, pravila održavanja baze podataka itd.

7. Evaluacija i podrška baze podataka. Procjena uključuje anketiranje korisnika kako bi se utvrdilo koje su im potrebe za informacijama koje ostaju nezadovoljene. Po potrebi se vrše izmjene u dizajniranoj bazi podataka. Korisnici su obučeni za rad sa bazom podataka. Kako se poslovne potrebe šire i mijenjaju, podrška baze podataka se pruža unošenjem izmjena, dodavanjem novih podataka i razvojem novih aplikacija koje rade sa bazom podataka.

15. Model odnosa entiteta

Alat za modeliranje predmetne oblasti u fazi idejnog projektovanja je model “entitet-odnos”.Često se naziva ER model (entitet, relacija). U njemu se modeliranje strukture podataka predmetne oblasti zasniva na upotrebi grafičkih alata - ER dijagrami(dijagrami entitet-odnos). Oni vizuelno predstavljaju odnose između entiteta.

Osnovni koncepti ER dijagrama – entitet, atribut, veza.

esencija – ovo je neki predmet iz stvarnog svijeta koji može postojati nezavisno. Entitet ima kopije, koji se međusobno razlikuju po vrijednostima atributa i omogućavaju nedvosmislenu identifikaciju.

Atribut – ovo je vlasništvo entiteta. Na primjer, entitet KNJIGA karakteriziraju takvi atributi kao što su autor, naslov, cijena, izdavač, tiraž, broj stranica. Određene knjige su instance entiteta BOOK. Oni se razlikuju u vrijednostima navedenih atributa i jedinstveno su identificirani atributom "name". Poziva se atribut koji jedinstveno identificira instance entiteta ključ. Možda kompozitni ključ koji predstavlja kombinaciju nekoliko atributa.

Pretpostavimo da se kreira baza podataka za skladištenje informacija o aktivnostima određene kompanije. Ova kompanija ima filijale. Ograncima upravljaju menadžeri. Kupci naručuju u filijalama. Filijale obrađuju ove narudžbe. Nazovimo opisanu predmetnu oblast COMPANY. Može razlikovati četiri entiteta: filijala, menadžer, nalog, klijent.

U ER dijagramu, entitet je predstavljen pravougaonikom koji sadrži njegovo ime. na primjer,

MANAGER

U stvarnom svijetu postoje veze između entiteta. Veza predstavlja interakciju između entiteta. Karakteriziran je moć, što pokazuje koliko je entiteta uključeno u odnos. Odnos između dva entiteta se zove binarni.

U predmetnoj oblasti koja se razmatra, FIRM, mogu se razlikovati tri veze:

1. RUKOVODITELJ – UPRAVLJA – PODRUŽNICA

2. GRANA – PROCESI – RED

3. KLIJENT – PRAVI – NARUČUJE

U ER dijagramu, odnos je predstavljen dijamantom.

na primjer,

Važna karakteristika komunikacije je tip komunikacije ( kardinalnost).

Razmotrimo gore navedene vrste veza 1–3.

Pošto menadžer upravlja samo jednom granom, svaka instanca entiteta MANAGER može biti povezana sa najviše jednom instancom entiteta BRANCH. U ovom slučaju, odnos 1 je tipa jedan-na-jedan (1:1). Na sl. Slika 15.1 prikazuje ER dijagram za odnos tipa 1:1.

Budući da podružnica obrađuje više naloga, a narudžbu obrađuje samo jedna grana, svaka instanca entiteta BRANCH može biti povezana s više od jedne instance entiteta ORDER, a svaka instanca entiteta ORDER može biti povezana s najviše jednom instanca entiteta BRANCH.

U ovom slučaju, odnos 2 je tip jedan prema više (1:M). Na sl. Slika 15.2 prikazuje ER dijagram za komunikaciju tipa 1:M.

Budući da nekoliko kupaca može napraviti narudžbu, a kupac može imati nekoliko naloga, svaka instanca entiteta ORDER može biti povezana s nekoliko instanci entiteta KLIJENT, a svaka instanca entiteta KLIJENT može biti povezana s nekoliko instanci entiteta ORDER. U ovom slučaju, odnos 3 je tipa mnogo-prema-više (M:N). Na sl. Slika 10.3 prikazuje ER dijagram za vezu tipa M:N.

Hajde da razmotrimo koncept klasa članstva entiteta.

Ako je svaka instanca entiteta A povezana sa instancom entiteta B, tada je klasa članstva entiteta A obavezno. Ova činjenica je na ER dijagramu naznačena crnim krugom postavljenim u pravougaonik pored pravougaonika entiteta A.

Ako nije svaka instanca entiteta A povezana sa instancom entiteta B, onda je klasa članstva entiteta A opciono. Ova činjenica je na ER dijagramu označena crnim krugom postavljenim na komunikacijskoj liniji u blizini pravokutnika entiteta A.

Kao primjer na sl. Slika 10.4 prikazuje moguće ER dijagrame za odnos M:N, uzimajući u obzir klasu članstva entiteta.

U ER dijagramu, 1. klasa članstva oba entiteta je opciona.

Na dijagramu ER, klasa 2 entiteta CLIENT je obavezna, a ORDER entitet je opcionalan.

Na dijagramu ER, klasa 3 entiteta CLIENT je opciona, a ORDER entitet je obavezan.

Na dijagramu ER potrebna je klasa članstva 4 za oba entiteta.

Pretpostavimo da je u predmetnoj oblasti koja se razmatra, FIRM, klasa članstva sva četiri entiteta obavezna. Tada će ER-model predmetne oblasti FIRM imati oblik prikazan na Sl. 10.5.

Svaki od četiri entiteta datog ER modela može se opisati za sebe

skup atributa (slika 15.6).

ER model, zajedno sa skupovima atributa entiteta, može poslužiti kao primjer konceptualnog modela domene ili konceptualne sheme baze podataka.

Rice. 15.6 . Skupovi atributa entiteta u domeni COMPANY

Napomena. Ključni atributi su podebljani.

Koncept u opštem smislu predstavlja određeni sistem pogleda na proces ili pojavu. Komponente koncepta su skup principa i metodologije. Metodologija se shvata kao skup metoda za rešavanje problema.

Princip – pravila kojih se treba pridržavati u aktivnostima. Često se principi formuliraju u obliku ograničenja i zahtjeva, posebno zahtjeva za baze podataka.

Zahtjevi baze podataka

Iz moderne perspektive, zahtjeve za transakcionim (operativnim) bazama podataka i skladištima podataka treba razmotriti odvojeno.

Prvo navodimo osnovne zahtjeve koji se odnose na operativne baze podataka, a samim tim i na DBMS na kojem su izgrađene.

1. Lako ažuriranje podataka. Podoperacija ažuriranja odnosi se na dodavanje, brisanje i promjenu podataka.
2. Visoke performanse (kratko vrijeme odgovora na zahtjev). Vrijeme odgovora je vremenski interval od trenutka zahtjeva do baze podataka i stvarnog prijema podataka. Sličan termin je vrijeme pristupa - vremenski interval između izdavanja naredbe za pisanje (čitanje) i stvarnog prijema podataka. Pristup se odnosi na operaciju pretraživanja, čitanja ili pisanja podataka.
3. Nezavisnost podataka.
4. Dijeljenje podataka među mnogim korisnicima.
5. Sigurnost podataka - zaštita podataka od namjerne ili nenamjerne povrede povjerljivosti, izobličenja ili uništenja.
6. Standardizacija konstrukcije i rada baze podataka (u stvari, DBMS).
7. Adekvatnost prikaza podataka odgovarajuće predmetne oblasti.
8. Prijateljski korisnički interfejs.

Prva dva kontradiktorna zahteva su najvažnija. Povećanje performansi zahteva pojednostavljenje strukture baze podataka, što zauzvrat komplikuje proceduru ažuriranja podataka i povećava njenu redundantnost (vidi Poglavlje 4).

Nezavisnost podataka je mogućnost promjene logičke i fizičke strukture baze podataka bez promjene percepcije korisnika. Nezavisnost podataka pretpostavlja nepromjenjivost prirode skladištenja podataka, softvera i hardvera. Osigurava minimalne promjene strukture baze podataka kada se promijeni strategija pristupa podacima i struktura samih izvornih podataka. Ovo se postiže, kao što će biti pokazano u nastavku, “miješanjem” svih promjena u fazi konceptualnog i logičkog dizajna sa minimalnim promjenama u fazi fizičkog dizajna |2).

Sigurnost podataka uključuje integritet i zaštitu podataka. Integritet podataka je otpornost pohranjenih podataka na uništenje i uništenje povezano s kvarovima tehničke opreme, sistemskim greškama i pogrešnim radnjama korisnika.

Pretpostavlja se:

nepostojanje netačno upisanih podataka ili dva identična unosa o istoj činjenici;
zaštita od grešaka pri ažuriranju baze podataka;
nemogućnost zasebnog brisanja (kaskadno brisanje) povezanih podataka iz različitih tabela;
neiskrivljavanje podataka pri radu u višekorisničkom režimu i u distribuiranim bazama podataka;
sigurnost podataka u slučaju kvarova opreme (oporavak podataka).

Integritet se osigurava okidačima integriteta - posebnim aplikativnim programima koji rade pod određenim uvjetima. Za neke DBMS (na primjer, Access, Paradox) okidači su ugrađeni.

Zaštita podataka od neovlaštenog pristupa uključuje ograničavanje pristupa povjerljivim podacima i može se postići:

uvođenje sistema lozinki;
dobijanje dozvola od administratora baze podataka (DBA);
zabrana DBA pristupa podacima;
formiranje tipova - tabela, izvedenih iz originalnih i namenjenih određenim korisnicima.

Posljednje tri procedure se lako izvode unutar jezika strukturiranih upita - SQL, koji se često naziva SQL2.

Standardizacija osigurava kontinuitet generacija DBMS-a i pojednostavljuje interakciju baza podataka iste generacije DBMS-a sa istim i različitim modelima podataka. Standardizacija (ANSI/SPARC) je u velikoj mjeri provedena u pogledu korisničkog sučelja DBMS i SQL jezika. To je omogućilo uspješno rješavanje problema interakcije između različitih relacijskih DBMS-a, kako korištenjem SQL jezika tako i korištenjem Open DataBase Connection (ODBC) aplikacije. U tom slučaju se može obezbijediti i lokalni i udaljeni pristup podacima (klient-server tehnologija ili mrežna opcija).

Pređimo na zahtjeve za skladišta podataka, koja su strukturno nastavak operativnih baza podataka.

Neka baza podataka sadrži podatke o uspješnosti studenata treće godine, s tim da su tekući semestar peti i šesti. Podaci za prva četiri semestra nalaze se (prenose) u skladištu podataka (DW), odnosno u dodatnoj, specifičnoj bazi podataka. Potrebno je iz repozitorija zatražiti imena studenata koji su u prva četiri semestra studirali sa odličnim uspjehom.

Drugim riječima, podaci iz operativne baze podataka se periodično prenose u elektronsku arhivu (u razmatranom primjeru podaci za prva četiri semestra), a zatim se mogu obrađivati prema zahtjevu korisnika.

Budući da se podaci u skladištu praktično ne mijenjaju, već se samo dodaju, zahtjev za lakoćom ažuriranja postaje irelevantan. Zbog značajne količine podataka u skladištu, zahtjevi za visokim performansama su na prvom mjestu.

Sljedeći dodatni zahtjevi se odnose na skladišta podataka:

visoke performanse učitavanja podataka iz operativnih baza podataka;
mogućnost filtriranja, preformatiranja, provjere integriteta izvornih podataka, indeksiranja podataka, ažuriranja metapodataka;
povećani zahtjevi za kvalitetom izvornih podataka u smislu obezbjeđivanja njihove konzistentnosti, budući da se mogu dobiti iz različitih izvora;
visoke performanse upita;
osiguravanje visoke dimenzionalnosti;
istovremeni pristup skladištu podataka;
Dostupnost administrativnih alata.

Podrška za analizu podataka korištenjem odgovarajućih metoda (alata).

Kao što je navedeno u E.F. Na osnovu svog iskustva, Codd je postavio sljedeće zahtjeve za OLAP sistem.

1. Višedimenzionalni konceptualni prikaz podataka.
2. Transparentnost tehnologije i izvora podataka.
3. Pristup izvorima podataka pri korištenju različitih modela podataka.
4. Dosljedan učinak pripreme izvještaja kako se povećava obim, broj mjerenja i procedure sumiranja podataka.
5. Korištenje fleksibilne, prilagodljive, skalabilne klijent-server arhitekture.
6. Univerzalnost mjerenja (formule i alati za kreiranje izvještaja ne bi trebali biti vezani za određene vrste dimenzija).
7. Dinamičko upravljanje razrjeđenošću matrice (prazne NULL vrijednosti moraju biti pohranjene na efikasan način).
8. Podrška za više korisnika.
9. Neograničene operativne veze između dimenzija.
10. Podržava intuitivnu manipulaciju podacima.
11. Fleksibilnost alata za izvještavanje.
12. Neograničen broj dimenzija i nivoa generalizacije.

Navedeni zahtjevi se razlikuju od zahtjeva za operativne baze podataka, što je dovelo do pojave specijalizovanih baza podataka – skladišta podataka.

Različite grupe ljudi već duže vreme proučavaju ovu problematiku u institucijama koje koriste računare, u vladinim komisijama iu javnim računarskim centrima. CODASYL komitet je objavio izvještaje na ovu temu (CODASYL je organizacija koja je razvila jezik COBOL). Korisničke organizacije IBM SHARE i GUIDE formulirale su zahtjeve za sistem upravljanja bazom podataka u svom izvještaju. Organizacija ACiM (Asocijacija za računarske mašine) je takođe proučavala ovo pitanje.

U nastavku su navedeni osnovni zahtjevi za organizaciju baze podataka.

Uspostavljanje multilateralnih veza

Različiti programeri zahtijevaju različite logičke datoteke. Ove datoteke su dobijene iz istog skupa podataka. Mogu postojati različite veze između elemenata pohranjenih podataka. Neke baze podataka će sadržavati složene mreže odnosa. Metoda organizovanja podataka treba da bude takva da je moguće pogodno predstaviti ove odnose i brzo se dogovoriti o promenama koje su na njima napravljene. Sistem upravljanja bazom podataka mora osigurati mogućnost dobivanja potrebnih logičkih datoteka iz postojećih podataka i odnosa koji postoje između njih. Mora postojati barem neka sličnost između prikaza logičke datoteke u aplikacijskom programu i načina na koji se podaci fizički pohranjuju.

Performanse

Baze podataka posebno dizajnirane za korištenje od strane operatera terminala pružaju vremena odgovora koja su zadovoljavajuća za dijalog od čovjeka do terminala. Osim toga, sistem baze podataka mora obezbijediti adekvatnu propusnost. U sistemima dizajniranim za mali protok zahtjeva, propusnost nameće manja ograničenja na strukturu baze podataka. U sistemima sa velikim protokom zahteva, na primer, u sistemima za rezervaciju avio karata, propusnost ima odlučujući uticaj na izbor organizacije fizičkog skladištenja podataka.

U sistemima koji su namenjeni samo za serijsku obradu, vreme odziva nije toliko važno i način fizičke organizacije se može izabrati da bi se obezbedila efikasna batch obrada.

Minimalni troškovi

Da bi se smanjili troškovi kreiranja i rada baze podataka, odabiru se organizacijske metode koje minimiziraju zahtjeve vanjske memorije. Sa ovim tehnikama, fizička reprezentacija podataka u memoriji može biti veoma različita od reprezentacije koju koristi programer aplikacije. Konverzija iz jednog prikaza u drugi vrši se softverom ili, ako je moguće, hardverom ili firmverom. U takvim slučajevima morate birati između cijene algoritma konverzije i uštede memorije.

Funkcionalni zahtjevi

Baza podataka treba da obezbedi skladištenje podataka o operaciji hemijskog čišćenja. U bazu podataka potrebno je unijeti sljedeće podatke:

Vrste usluga (šifra vrste usluge, naziv, vrsta, cijena).

Klijenti (kod klijenta, prezime, ime, patronim, atribut redovnog klijenta).

Usluge (Šifra usluge, Šifra vrste usluge, Šifra klijenta, Datum prijema, Datum povratka).

Potrebno je organizovati automatski obračun cijene usluga, uzimajući u obzir popuste i doplate, te automatsku registraciju klijenta kao stalnog klijenta od trećeg zahtjeva.

Zahtjevi za sastav i parametre tehničkih sredstava

Potrebna količina slobodne RAM memorije za pokretanje programa nije veća od 15 Mb, slobodan prostor na disku za instalaciju programa je do 20 Mb, procesor P400.

Zahtjevi za informacije i kompatibilnost softvera

Baza podataka mora biti u serverskom formatu FireBird 2.5, a na računaru mora biti instaliran uslužni program za bazu podataka IB Expert (IB Expert radi pod Windows operativnim sistemom).

Zahtjevi za softversku dokumentaciju

Dokumentacija za program mora biti sastavljena u skladu s postojećim GOST-ovima i sadržavati sljedeće odjeljke:

1. Analiza domena

2. Projektni zadatak

3. Konceptualni model podataka

4. Logički model podataka

5. Fizički model podataka

6. Izračunata polja, generatori i okidači

7. Program i metodologija testiranja

8. Opis primjene

9. Zaključak

10. Spisak korištenih izvora

11. Tekst SQL skripte

12. Dijagrami

13. Rezultati ispitivanja

Faze i faze razvoja

a) Kratka analiza dizajna

b) Razvoj konceptualnog modela podataka

c) Razvoj logičkog modela

d) Razvoj fizičkog modela

e) Kreiranje izračunatih polja, generatora, okidača

f) Unošenje podataka u bazu podataka i rad na testiranju

g) Dokumentacija u skladu sa postojećim GOST-ovima

Procedura kontrole i prihvatanja

Za praćenje rada baze podataka potrebno je izraditi testni set podataka koji se sastoji od liste klijenata, informacija o prijemu artikala i vrstama radova u hemijskoj čistionici.

Potrebno je ručno izračunati cijenu usluga uzimajući u obzir popuste i doplate. Pripremljenu listu potrebno je unijeti u bazu podataka i uporediti rezultat rada sa rezultatom dobijenim ručnim proračunom. Potrebno je provjeriti mogućnost uređivanja i dodavanja podataka, ispravan rad generatora i okidača.

Konceptualni model podataka

Konceptualni model podataka prikazuje generalizirani prikaz podataka, bez obzira na tip odabranog DBMS-a. On opisuje koji su podaci pohranjeni u bazi podataka, kao i odnose koji postoje između njih. U stvari, to je potpuni prikaz zahtjeva za podacima organizacije u kojoj korisnici rade.

Konceptualni model podataka sastoji se od entiteta sa njihovim atributima i n-arnim odnosima i koristi se kao sredstvo za konstruisanje i predstavljanje informacionih potreba preduzeća.

Nakon analize opisa predmetne oblasti, odabiremo objekte čije su informacije uključene u opis. U pravilu se malo mijenjaju s vremenom i ne ovise o postojanju drugih objekata. Entiteti su prikazani u dijagramu objekta/relacije kao pravokutnici. Entiteti uključuju sljedeće objekte: „Klijenti“, „Vrsta posla“, „Usluge“.

Za svaki objekt definiramo svojstvo ključa koje će se kasnije koristiti kao primarni ključ. Ključna svojstva odabrana za entitete su:

„Klijenti“ – šifra klijenta

“Usluge” – šifra usluge

“Vrsta posla” – šifra vrste posla

Zatim unosimo ne-ključna svojstva (atribute) za objekte.

Definirani entiteti i atributi prikazani su u tabelama 1-3:

Tabela 1. Klijenti entiteta

Tabela 2 Suština Vrste posla

Objekti međusobno ulaze u određene semantičke odnose, koji se na dijagramu „objekt/odnos“ prikazuju u obliku ovala (veza). Ovale su povezane ravnim segmentima sa pravokutnicima koji odgovaraju objektima koji sudjeluju u odnosu:

1-M (jedan-prema-više) – Usluge-Klijenti (pružene), Usluge-Vrsta posla (povezano).

Stepen učešća „Obezbeđene“ veze između entiteta Usluge i Klijenti je nepotpun i ima pokazatelje kardinalnosti 1,1 i N,1, respektivno, budući da se usluge klijentima mogu pružati više puta, a samo jednom klijentu odgovara jedna evidencija usluge .

Stepen učešća “Relate” veze između usluga i subjekata vrste poslova je nepotpun i ima pokazatelje kardinalnosti 1,1 odnosno N,1, budući da se iste vrste poslova mogu pružati više puta, a samo jedna vrsta posla. rad odgovara jednom uslužnom zapisu.

Koncept dijagram je predstavljen u Dodatku B, slika 1.

PREGLED BILJEŠKI PREDAVANJA

Za studente specijalnosti
T1002 “Softver informacione tehnologije”

(dr L.V. Rudikova, vanredni profesor)

Pitanje 31. ARHITEKTURA DBMS. MODEL RELACIJSKIH PODATAKA

1. Koncept baze podataka.

2. Troslojna arhitektura baze podataka.

3. Životni ciklus baze podataka.

4. DBMS arhitektura.

5. Relacioni model podataka.

6. Dizajn relacionih baza podataka.

7. Normalni oblici odnosa.

8. Relaciona algebra.

1. Koncept baze podataka.

Sistem baze podataka je svaki informacioni sistem zasnovan na računaru u kojem se podaci mogu dijeliti među mnogim aplikacijama.

Informacioni sistem – automatski sistem koji organizuje podatke i pruža informacije.

Informacijski i upravljački sistem – sistem koji pruža informatičku podršku menadžmentu.

Podaci – razbacane činjenice.

Informacije – organizovani i obrađeni podaci.

Ispod baza podataka odnosi se na skup međusobno povezanih elementarnih grupa podataka (informacija) koje može obraditi jedan ili više aplikacijskih sistema. Sistem baze podataka sastoji se od baze podataka; softver opšte namene tzv sistem za upravljanje bazom podataka (DBMS) , i služi za upravljanje bazom podataka; odgovarajuću opremu i ljude.

Svaki DBMS mora ispunjavati sljedeće zahtjeve:

· daju korisniku mogućnost kreiranja novih baza podataka i njihovog definiranja shema (logička struktura podataka) koristeći poseban jezik - jezik definicije podataka; podržavaju višestruke prikaze istih podataka;

· pusti " zahtjev» podatke i mijenjajte ih koristeći jezik upita, ili jezik za manipulaciju podacima; omogućavaju integraciju i dijeljenje podataka između aplikacija;

· podržavaju pohranjivanje veoma velikih količina podataka, mjerenih u gigabajtima ili više, na duže vrijeme, štiteći ih od slučajnog oštećenja i neovlaštenog korištenja, a također omogućavaju modifikaciju baze podataka i pristup podacima putem upita, tj. garantovati sigurnost i integritet podataka;

· kontrolisati pristup podacima istovremeno za više korisnika; isključiti utjecaj zahtjeva jednog korisnika na zahtjev drugog i spriječiti istovremeni pristup, koji bi mogao oštetiti podatke, tj. osigurati kontrolu konkurentnosti pristupa podacima.

Sistem baze podataka sastoji se od sljedećih komponenti:

· Korisnici, tj. ljudi koji koriste podatke.

· Prijave, tj. korisničke programe koji zahtijevaju podatke iz sistema.

· DBMS je softver koji upravlja pristupom podacima i pruža specificiranu funkcionalnost sistema baze podataka.

· Podaci, tj. stringovi pohranjeni u fajlovima.

· Host sistem je računarski sistem na kojem se pohranjuju datoteke. Host sistem pristupa redovima podataka. Uloga DBMS-a je da generiše upite koji omogućavaju da se funkcionalnost upravljanja datotekama host sistema koristi za opsluživanje različitih aplikacija. DBMS je dodatni sloj softvera izgrađen na vrhu softvera glavnog sistema.

Dakle, sistem sa bazom podataka može se predstaviti kao sledeći niz nivoa:

Na najnižem nivou nalaze se podaci pohranjeni u fizičkim datotekama (fizička memorija baze podataka). Na najvišem nivou - aplikacije sa sopstvenim prikazima istih fizičkih podataka. Svaki pogled baze podataka je specifična logička struktura izgrađena od osnovnih fizičkih podataka. Da bi se obezbedio interfejs između fizičke memorije baze podataka i njenih različitih logičkih verzija (više podržanih pogleda), DBMS se zauzvrat mora sastojati od nekoliko slojeva.

2. Arhitektura baze podataka na tri nivoa.

Razlika između logičkog i fizičkog predstavljanja podataka formalno je prepoznata 1978. godine kada je komitet ANSI/SPARC predložio generaliziranu strukturu sistema baza podataka. Ova struktura se naziva troslojna arhitektura. Tri nivoa arhitekture su: unutrašnji, konceptualni i eksterni.

Interni nivo – ovo je nivo koji određuje fizički izgled baze podataka, najbliži fizičkoj memoriji i povezan je sa metodama skladištenja informacija na fizičkim uređajima za skladištenje podataka. S ovim nivoom su povezani diskovi, fizičke adrese, indeksi, pokazivači itd. Ovaj sloj je odgovornost dizajnera fizičke baze podataka koji odlučuju koji će fizički uređaji pohranjivati podatke, koje metode pristupa će se koristiti za dohvaćanje i ažuriranje podataka i koje mjere treba poduzeti za održavanje ili poboljšanje performansi sistema za upravljanje bazom podataka. Korisnici ne dodiruju ovaj nivo.

Konceptualni nivo – strukturni nivo koji definiše logički dizajn baze podataka. Na ovoj razini vrši se idejno rješenje baze podataka koje uključuje analizu informacijskih potreba korisnika i identifikaciju elemenata podataka koji su im potrebni. Rezultat idejnog dizajna je konceptualni dijagram, logički opis svih elemenata podataka i odnosa među njima.

Eksterni nivo – strukturni nivo baze podataka, koji definiše korisničke poglede na podatke. Svaka korisnička grupa dobija svoj pogled na podatke u bazi podataka. Svaki takav prikaz podataka pruža opis elemenata podataka koji čine prikaz podataka usmjeren na korisnika i odnosa između njih. Može se direktno izvesti iz konceptualnog okvira. Prikupljanje takvih prikaza korisničkih podataka pruža vanjski nivo.

Pogledi korisnika i aplikacija	Eksterni nivo

Displeji

Konceptualni dijagram	Konceptualni nivo

Display	Interni nivo

Host sistem

Pohranjeni podaci

Rice. DBMS nivoi

3. Životni ciklus baze podataka.

Proces projektovanja, implementacije i održavanja sistema baze podataka naziva se životni ciklus baze podataka (LDC). Procedura za kreiranje sistema se zove životni ciklus sistema (SLC).

Razumijevanje i ispravan pristup LCBD-u je veoma važan i zahtijeva detaljno razmatranje, jer se zasniva na pristupu data-centric. Elementi podataka su stabilniji od sistemskih funkcija koje se izvode. Stvaranje prave strukture podataka zahtijeva kompleksnu analizu klasa jedinica podataka i odnosa između njih. Ako izgradite logičku shemu baze podataka, tada u budućnosti možete kreirati bilo koji broj funkcionalnih sistema koji koriste ovu shemu. Funkcionalno orijentisani pristup može se koristiti samo za kreiranje privremenih sistema koji su dizajnirani za kratak period rada.

LCBD se sastoji od sljedećih faza:

1. Prethodno planiranje – planiranje baze podataka, koje se sprovodi u procesu izrade strateškog plana baze podataka. Tokom procesa planiranja prikupljaju se sljedeće informacije:

· koji se aplikativni programi koriste i koje funkcije obavljaju;

· koje datoteke su povezane sa svakom od ovih aplikacija;

· koje su nove aplikacije i fajlovi u izradi.

Ove informacije pomažu u određivanju načina na koji se koriste informacije aplikacije i određuju buduće zahtjeve za sistem baze podataka.

Informacije iz ove faze dokumentuju se u obliku generalizovanog modela podataka.

2. Provjera izvodljivosti . Ovdje se utvrđuje tehnološka, operativna i ekonomska izvodljivost plana kreiranja baze podataka, tj.:

· tehnološka izvodljivost – da li je tehnologija dostupna za implementaciju planirane baze podataka?

· Operativna izvodljivost – Da li su potrebna sredstva i stručnjaci za uspješnu implementaciju plana baze podataka?

· ekonomska izvodljivost – da li se zaključci mogu utvrditi? Hoće li se planirani sistem isplatiti? Da li je moguće procijeniti troškove i koristi?

3. Definiranje zahtjeva uključuje odabir ciljeva baze podataka, pojašnjenje zahtjeva za informacijama za sistem i zahtjeva za hardver i softver. Dakle, u ovoj fazi prikupljanja podataka i definisanja zahtjeva, a opšti informacioni model, izraženo u sljedećim zadacima:

· Analizom informacijskih potreba određuju se ciljevi sistema. Također, nužno ukazuje na to kakvu bazu podataka treba kreirati (distribuirana, holistička) i koji su komunikacijski alati potrebni. Izlazni dokument je komentar koji opisuje ciljeve sistema.

· Utvrđivanje zahtjeva korisnika: dokumentacija u obliku generalizovanih informacija (komentari, izvještaji, ankete, upitnici, itd.); fiksiranje sistemskih funkcija i identificiranje aplikativnih sistema koji će ispuniti ove zahtjeve. Podaci se prikazuju u obliku relevantnih dokumenata.

· Određivanje opštih hardverskih i softverskih zahteva u vezi sa održavanjem željenog nivoa performansi. (Pronađite broj korisnika sistema, broj ulaznih poruka po danu, broj ispisa). Ove informacije se koriste za odabir tipova računara i DBMS-a, kapaciteta diska i broja štampača. Podaci iz ove faze su predstavljeni u izvještaju koji sadrži uzorke hardverskih i softverskih konfiguracija.

· Izrada plana za fazno kreiranje sistema, uključujući odabir početnih aplikacija.

4. Idejni dizajn – kreiranje konceptualnog dijagrama baze podataka. Specifikacije se razvijaju u mjeri u kojoj je to potrebno za prelazak na implementaciju.

Glavni izlazni dokument je jedan informacioni model(ili shema baze podataka na konceptualnom nivou). Prilikom razvoja ovog modela koriste se informacije i funkcije koje sistem mora da obavlja, utvrđene u fazi prikupljanja i utvrđivanja sistemskih zahtjeva. U ovoj fazi je takođe poželjno definisati: 1) pravila za podatke; 2) pravila za procese; 3) pravila za interfejs.

5. Implementacija – proces pretvaranja konceptualnog modela u funkcionalnu bazu podataka. Uključuje sljedeće korake.

1) Odabir i nabavka potrebnog DBMS-a.

2) Pretvaranje konceptualnog (infološkog) modela baze podataka u logički i fizički model podataka:

· Na osnovu infološkog modela podataka, izrađuje se šema podataka za određeni DBMS, ako je potrebno, baza podataka se denormalizira kako bi se ubrzala obrada upita u svim vremenski kritičnim aplikacijama;

· utvrđuje se koji procesi aplikacije moraju biti implementirani u šemu podataka kao pohranjene procedure;

· implementirati ograničenja osmišljena da osiguraju integritet podataka i provedu pravila o podacima;

· dizajnirati i generirati okidače za implementaciju svih centralno definiranih pravila podataka i pravila integriteta podataka koja se ne mogu specificirati kao ograničenja;

· razviti strategiju indeksiranja i klasteriranja; procijeniti veličine svih tabela, klastera i indeksa;

· odrediti nivoe pristupa korisnika, razviti i implementirati pravila sigurnosti i revizije. Kreirajte uloge i sinonime da biste omogućili pristup za više korisnika sa dosljednim nivoima dozvola pristupa.

· razviti mrežnu topologiju baze podataka i mehanizam za nesmetan pristup udaljenim podacima (replicirana ili distribuirana baza podataka).

3) Izrada rječnika podataka koji definira skladištenje definicija strukture podataka baze podataka. Rječnik podataka također sadrži informacije o dozvolama pristupa, pravilima zaštite podataka i kontroli podataka.

4) Popunjavanje baze podataka.

5) Kreiranje aplikativnih programa, kontrola upravljanja.

6) Obuka korisnika.

6. Evaluacija i poboljšanje šeme baze podataka. Uključuje anketiranje korisnika kako bi se identificirale funkcionalne nezadovoljene potrebe. Promjene se vrše prema potrebi, dodajući nove programe i elemente podataka kako se potrebe mijenjaju i proširuju.

Dakle, LCBD uključuje:

· Proučite predmetnu oblast i obezbijedite relevantnu dokumentaciju (1-3).

· Konstrukcija informacionog modela (4).

· Implementacija (5).

· Procjena učinka i podrška bazi podataka (6).

4. Arhitektura DBMS-a.

Rice. Glavne komponente DBMS-a

Podaci, metapodaci - sadrže ne samo podatke, već i informacije o strukturi podataka ( metapodaci). U relacionom DBMS-u, metapodaci uključuju sistemske tabele (relacije), imena relacija, imena atributa tih relacija i tipove podataka tih atributa.

Često DBMS podržava indeksi podaci. Indeks je struktura podataka koja pomaže da se brzo pronađu elementi podataka kojima je dat dio njihove vrijednosti (na primjer, indeks koji pronalazi torke određene relacije koji imaju zadanu vrijednost jednog od atributa). Indeksi su dio pohranjenih podataka, a opisi koji pokazuju koje atribute indeksi imaju dio su metapodataka.

Memory manager - prima tražene informacije sa lokacije za skladištenje podataka i mijenja informacije u njoj na zahtjev viših nivoa sistema.

U jednostavnim sistemima baza podataka, menadžer memorije može biti sistem datoteka operativnog sistema. Međutim, da bi poboljšao efikasnost, DBMS obično vrši direktnu kontrolu memorije. Upravitelj memorije se sastoji od dvije komponente:

· File Manager prati lokaciju datoteka na disku i dobiva blok ili blokove koji sadrže datoteke kada to zatraži upravitelj bafera (disk je općenito podijeljen na disk blokovi- susjedna memorijska područja koja sadrže od 4000 do 16000 bajtova).

· Buffer Manager upravlja glavnom memorijom. On prima blokove podataka sa diska preko upravitelja datoteka i bira glavnu memorijsku stranicu za pohranjivanje određenog bloka. Može privremeno pohraniti blok diska u glavnu memoriju, ali ga vraća na disk kada je stranica glavne memorije potrebna za drugi blok. Stranice se takođe vraćaju na disk kada to zatraži menadžer transakcija.

Procesor "zahtjeva". - obrađuje zahtjeve i zahtijeva izmjene podataka ili metapodataka. Predlaže najbolji način za izvođenje potrebne operacije i izdaje odgovarajuće komande upravitelju memorije.

Procesor upita (menadžer) pretvara upit ili radnju baze podataka koja se može izvršiti na vrlo visokom nivou (na primjer, kao upit SQL ), u niz zahtjeva za pohranjenim podacima kao što su pojedinačne torke relacije ili dijelovi indeksa na relaciji. Često najteži dio obrade zahtjev je njegov organizacija, tj. biranje dobrog plan upita ili niz zahtjeva memorijskom sistemu koji odgovara na zahtjev.

Menadžer transakcija - odgovoran je za integritet sistema i mora osigurati istovremenu obradu većeg broja zahtjeva, odsustvo smetnji zahtjeva (dodavanje, min, max ) i zaštitu podataka u slučaju kvara sistema. On stupa u interakciju s upraviteljem upita jer mora znati na koje podatke utječu trenutni upiti (da bi se izbjegli sukobi) i može odgoditi neke upite i operacije kako bi izbjegao sukobe. Upravitelj transakcija također stupa u interakciju s upraviteljem memorije jer šeme zaštite podataka obično uključuju pohranjivanje dnevnika promjena podataka. Ako je operacija izvedena ispravno, datoteka registracija će sadržavati zapis promjena, tako da možete ponovo izvršiti čak i one promjene koje nisu stigle na disk zbog kvara sistema.

Tipični DBMS-ovi omogućavaju korisniku da grupiše više upita i/ili promjena u jednu transakciju. Transakcija je grupa operacija koje se moraju izvoditi uzastopno kao jedna cjelina.

Tipično, sistem baze podataka podržava više transakcija istovremeno. Ispravno izvršenje svih takvih transakcija osigurava menadžer transakcija. Osigurano je ispravno izvršenje transakcijaACID -osobine (atomičnost, konzistencija, izolacija, trajnost):

· atomičnost- izvršenje ili svih transakcija ili nijedna od njih (na primjer, podizanje novca sa bankomata i izvršenje odgovarajućeg zaduženja računa klijenta mora biti jedna atomska transakcija; nije dozvoljeno da se svaka od ovih operacija izvodi zasebno);

· konzistentnost - stanje u kojem podaci ispunjavaju sva moguća očekivanja (na primjer, uslov konzistentnosti baze podataka avio kompanije je da nijedno sjedište u avionu nije rezervisano za dva putnika);

· izolacija- kada se dvije ili više transakcija izvršavaju paralelno, njihovi rezultati moraju biti izolovani jedan od drugog. Istovremeno izvršenje dvije transakcije u isto vrijeme ne bi trebalo dovesti do rezultata koji se ne bi dogodio da su izvršene uzastopno (na primjer, pri prodaji karata za isti let u slučaju slobodnog posljednjeg sjedišta kada dva agenta istovremeno traže , zahtjev jednog mora biti ispunjen, drugog - Ne);

· dugovečnost - nakon što je transakcija završena, rezultat ne bi trebao biti izgubljen u slučaju kvara sistema, čak i ako se ovaj kvar dogodi odmah nakon završetka transakcije.

Razmotrimo i 3 vrste pristupa DBMS-u:

1. Zahtjevi - Pitanja o podacima mogu se generirati na dva načina:

a)korišćenjem zajednički upitni interfejs(na primjer, relacijski DBMS dozvoljava upite SQL , koji se prenose procesoru zahtjeva, a također primaju odgovore na njih);

b) uz pomoć sučelja aplikacijskih programa- zahtjevi se prenose preko posebnog interfejsa (preko ovog interfejsa se ne mogu prenositi proizvoljni zahtjevi);

2. Modifikacije - Ovo su operacije za promjenu podataka. Takođe se mogu izvršiti ili preko zajedničkog interfejsa ili kroz interfejs aplikacijskog programa;

3. Modifikacije kola - Ovo su timovi administratora baze podataka koji imaju pravo promijeniti šemu baze podataka ili kreirati novu bazu podataka.

Arhitektura klijent/server. Mnoge verzije modernog softvera implementiraju arhitekturu klijent/server: Jedan proces (klijent) šalje zahtjev drugom procesu (serveru) za izvršenje. Obično je baza podataka često podijeljena na serverski proces i nekoliko klijentskih procesa.

U najjednostavnijoj arhitekturi klijent/server, čitav DBMS je server, osim interfejsa upita, koji komuniciraju sa korisnikom i šalju upite ili druge komande serveru. Na primjer, relacijski DBMS često koristi jezik SQL za predstavljanje zahtjeva od klijenta do servera. Server baze podataka tada daje klijentu odgovor u obliku tabele (relacija). Postoji tendencija povećanja opterećenja na klijentu, jer ako postoji više korisnika baze podataka koji istovremeno rade, mogu nastati problemi sa serverom.

5. Relacioni model podataka.

RMD određene predmetne oblasti je skup odnosa koji se mijenjaju tokom vremena. Prilikom kreiranja informacionog sistema, skup relacija vam omogućava da pohranite podatke o objektima predmetne oblasti i modelirate veze između njih.

Stav je dvodimenzionalna tabela koja sadrži neke podatke. Matematički ispodN -aran odnos R razumjeti kartezijanski skup proizvoda D 1 D 2 … D n setovi ( domene) D 1, D 2, …, D n (), opciono različito:

R D 1 D 2 … D n ,

gdje je D 1 D 2 … D n – kompletan kartezijanski proizvod, tj. skup svih mogućih kombinacija n svaki element, pri čemu je svaki element preuzet iz vlastitog domena.

Domain je semantički koncept. Domen se može smatrati podskupom vrijednosti nekog tipa podataka koji imaju specifično značenje. Domen karakterišu sljedeća svojstva:

· Domena ima jedinstveno ime(unutar baze podataka).

· Domen je definiran kod nekih jednostavno tip podataka ili na drugoj domeni.

· Domena može imati neke logično stanje, koji vam omogućava da opišete podskup podataka koji je važeći za dati domen.

· Domena nosi određene semantičko opterećenje.

Atribut odnosa ima par takvih<Имя_атрибута: Имя_домена>. Imena atributa moraju biti jedinstvena unutar odnosa. Često su imena atributa veze ista kao i imena odgovarajućih domena.

Ratio , definiran na više domena, sadrži dva dijela: zaglavlje i tijelo.

Zaglavlje odnosa je fiksni broj atributa relacije:

Glava relacije opisuje kartezijanski proizvod domena na kojima je relacija definirana. Zaglavlje je statičko; ono se ne mijenja tokom rada sa bazom podataka. Ako se atributi promijene, dodaju ili obrišu u odnosu, rezultat će biti ostalo vezu (čak i sa istim imenom).

Odnos tijela sadrži mnoge tuples odnos. Svaki relacija tuple predstavlja skup parova oblika<Имя_атрибута: Значение_атрибута>:

tako da vrijednost atributa pripada domeni . Tijelo relacije je skup torki, tj. podskup kartezijanskog proizvoda domena. Dakle, tijelo relacije je zapravo relacija u matematičkom smislu riječi. Tijelo relacije se može mijenjati tokom rada sa bazom podataka - torke se mogu mijenjati, dodavati i brisati.

Odnos se obično piše kao:

ili kraće

ili samo

Poziva se broj atributa u vezi stepen (ili -arity ) odnos. Kardinalnost skupa torki relacije naziva se moć odnos.

Dijagram odnosa je lista imena atributa date veze koja ukazuje na domenu kojoj pripadaju:

Ako atributi uzimaju vrijednosti iz iste domene, oni se nazivaju -usporedivi, gdje je skup valjanih operacija poređenja specificiranih za datu domenu. Na primjer, ako domena sadrži numeričke podatke, tada su sve operacije poređenja važeće za nju, tada . Međutim, za domene koje sadrže znakovne podatke, ne mogu se specificirati samo operacije poređenja za jednakost i nejednakost vrijednosti. Ako dati domen ima leksikografski poredak, onda ima i cijeli niz operacija poređenja.

Zovu se šeme dvije relacije ekvivalentno , ako imaju isti stepen i moguće je porediti nazive atributa u shemama na način da uporedivi atributi, odnosno atributi koji uzimaju vrijednosti iz istog domena, budu na istim mjestima:

Neka – dijagram odnosa. – shema relacije nakon naručivanja imena atributa. Onda

Dakle, za ekvivalentne relacije ispunjeni su sljedeći uslovi:

· Tabele imaju isti broj kolona.

· Tabele sadrže kolone sa istim imenima.

· Kolone sa istim imenima sadrže podatke sa istih domena.

· Tabele imaju iste redove, ali redoslijed kolona može varirati.

Sve takve tablice su različite slike isti odnos.

Svojstva odnosa. Svojstva relacija direktno slijede iz gornje definicije relacije. Ova svojstva su glavne razlike između relacija i tabela.

· Ne postoje identične tuple u vezi .

· Korke nisu naručene (od vrha do dna) .

· Atributi nisu poređani (s lijeva na desno) .

· Sve vrijednosti atributa su atomske .

Rice. Šematski prikaz odnosa

Relacioni model je baza podataka u obliku skupa međusobno povezanih odnosa. U svakoj vezi, jedan odnos može djelovati kao glavni, a drugi odnos djeluje kao podređen. Dakle, jedan skup glavne relacije može biti povezan s nekoliko torki podređene relacije. Da bi podržali ove odnose, oba odnosa moraju sadržavati skupove atributa pomoću kojih su povezani. U osnovi je ovo primarni ključ veze , koji jedinstveno definira tuple glavne relacije. Za modeliranje odnosa, podrelacija mora imati skup atributa koji odgovara primarnom ključu glavnog odnosa. Međutim, ovdje se već nalazi ovaj skup atributa sekundarni ključ ili strani ključ , tj. definiše skup torki relacija koje su povezane sa jednom torkom glavne relacije.

6. Dizajn relacionih baza podataka.

Prilikom dizajniranja relacijske baze podataka moraju se riješiti sljedeći problemi:

1) Uzimajući u obzir semantiku predmetne oblasti, potrebno je najbolje predstaviti objekte predmetne oblasti u obliku apstraktnog modela podataka (data design). One. - odlučiti o šemi baze podataka: od kojih relacija treba da se sastoji baza podataka, koje atribute treba da imaju ti odnosi, koje su veze između relacija.

2) Osigurati efikasnost izvršavanja upita baze podataka (fizički dizajn baze podataka).

Nakon faze logičkog dizajna, potrebno je pribaviti sljedeće dokumente:

· Izgradnja ispravne šeme podataka na osnovu relacionog modela podataka.

· Opis šeme baze podataka u smislu odabranog DBMS-a.

· Opis eksternih modela u smislu odabranog DBMS-a.

· Opis deklarativnih pravila za održavanje integriteta baze podataka.

· Razvoj procedura za održavanje semantičkog integriteta baze podataka.

Dakle, zadatak dizajniranja relacijske baze podataka je odabrati shemu baze podataka između mnogih alternativnih opcija.

Tačno je shema baze podataka u kojoj nema neželjenih ovisnosti između atributa relacije. Proces razvoja ispravne šeme baze podataka se zove logičan dizajn .

Dizajniranje šeme baze podataka može se izvršiti na dva načina:

· Metoda dekompozicije (particije). – originalni skup relacija uključen u šemu baze podataka je zamijenjen drugim skupom relacija koji su projekcije originalnih relacija! Istovremeno se povećava broj veza.

· Metoda sinteze – raspored sheme baze podataka iz datih početnih elementarnih zavisnosti između objekata predmetnog područja.

Klasični dizajn baze podataka povezan je s teorijom normalizacija , koji se zasniva na analizi funkcionalnih zavisnosti između atributa odnosa. Funkcionalne zavisnosti definišu stabilne odnose između objekata i njihovih svojstava u predmetnoj oblasti koja se razmatra.

Metoda dekompozicije je proces sekvencijalne normalizacije relacionih šema: svaka nova iteracija odgovara normalnom obliku višeg reda i ima bolja svojstva u odnosu na prethodnu. Dakle, u početku se pretpostavlja postojanje univerzalne relacije koja sadrži sve atribute baze podataka, a zatim se na osnovu analize veza između atributa vrši (ili pokušava) dekompozicija univerzalne relacije, tj. prijelaz na nekoliko relacija niže dimenzije, a originalna relacija se mora vratiti korištenjem prirodne operacije spajanja.

Dakle, svaki normalni oblik odgovara određenom skupu ograničenja, a relacija je u određenom normalnom obliku ako zadovoljava svoj inherentni skup ograničenja.

U teoriji relacijskih baza podataka obično se razlikuju sljedeći normalni oblici:

prvi normalni oblik (1 NF);

· drugi normalni oblik (2 NF);

· treći normalni oblik (3 NF);

· Bays-Codd normalna forma ( BCNF);

· četvrti normalni oblik (4 NF);

· peti normalni oblik ili projekcijski oblik - spojevi (5 NF ili PYNF).

Osnovna svojstva normalnih oblika:

· svaki sljedeći normalni oblik je u nekom smislu bolji od prethodnog;

· pri prelasku na sljedeći normalni oblik, svojstva prethodnih normalnih svojstava se čuvaju.

Pozivaju se šeme baze podataka ekvivalentno, ako se sadržaj izvorne baze podataka može dobiti prirodnom vezom relacija uključenih u rezultirajuću shemu, a u izvornoj bazi podataka se ne pojavljuju novi torovi.

7. Normalni oblici odnosa.

Proces normalizacije zasniva se na adekvatnom odrazu predmetnog područja u obliku tabela koje sadrže podatke o modeliranom objektu, te mogućnosti promjene stanja baze podataka tokom vremena. U pravilu, zbog neusklađenosti između modela podataka domene, može doći do anomalija koje se pojavljuju prilikom izvođenja odgovarajućih operacija:

· Anomalije umetanja (INSERT) – skladištenje heterogenih informacija u jednom pogledu.

· Ažuriraj anomalije (UPDATE) –Redundantnost podataka o odnosima zbog heterogenog skladištenja.

· Anomalije brisanja (DELETE) – skladištenje heterogenih informacija u jednoj relaciji.

Također je potrebno uzeti u obzir i nastajuće nedefinirano ( NULL) vrijednosti. U različitim DBMS-ovima, prilikom izvođenja različitih operacija (poređenje, spajanje, sortiranje, grupisanje, itd.) dva NULL -vrijednosti mogu ili ne moraju biti jednake jedna drugoj, imati različite efekte na rezultat izvođenja operacija za određivanje prosječnih vrijednosti i pronalaženje broja vrijednosti. Za uklanjanje grešaka u mnogim DBMS-ovima moguće je zamijeniti NULL -vrijednosti su nula prilikom izvođenja proračuna, deklariranja svih NULL -vrijednosti jednake jedna drugoj itd.

Normalizacija – dijeljenje tabele na nekoliko, koje imaju bolja svojstva prilikom ažuriranja, umetanja i brisanja podataka. One. normalizacija je proces uzastopne zamjene tabele sa njenim potpunim dekompozicijama dok sve ne budu u 5NF, međutim, u praksi je dovoljno pretvoriti tabele u BCNF.

Procedura normalizacije se zasniva na činjenici da jedine funkcionalne zavisnosti u bilo kojoj tabeli treba da budu zavisnosti oblika , gde je primarni ključ, a neko drugo polje. Stoga, tokom procesa normalizacije, trebali biste se riješiti svih „drugih“ funkcionalnih ovisnosti, tj. od onih koji imaju drugačiji izgled od .

Ako zamenimo kodove primarnih (stranih) ključeva tokom normalizacije, onda bismo trebali razmotriti 2 slučaja:

1. Tabela ima složeni primarni ključ, na primjer, i polje koje funkcionalno ovisi o dijelu ovog ključa, na primjer, (ne ovisi o punom ključu). Preporučuje se da kreirate drugu tabelu koja sadrži i ( – primarni ključ) i da je izbrišete iz originalne tabele:

Zamijenite, primarni ključ, savezni zakon

na , primarni ključ

i , primarni ključ .

2. Tabela ima primarni (mogući) ključ, polje koje nije mogući ključ, ali funkcionalno zavisi od, i drugo neključno polje koje funkcionalno zavisi od:. Preporučuje se kreiranje tabele koja sadrži i ( - primarni ključ) i - brisanje iz originalne tabele: Treba napomenuti da za izvođenje ovakvih operacija u početku treba imati neke “velike” (univerzalne) relacije kao ulazne podatke.

Def.1. Veza je unutra prvi normalni oblik (1NF) ako i samo ako nijedan od njegovih redova ne sadrži jednu vrijednost ni u jednom od svojih polja i nijedno od ključnih polja relacije nije prazno.

Prema definiciji 1, svaka relacija će biti u 1NF, tj. relacija koja zadovoljava svojstva relacija: u relaciji nema identičnih torki; tuple nisu naručene; atributi nisu poredani i razlikuju se po imenu; sve vrijednosti atributa su atomske.

Def.2. Veza je unutra drugi normalni oblik (2NF) ako i samo ako je relacija u 1NF i nema atributa koji nisu ključ koji zavise od dijela složenog ključa (to jest, sva polja koja nisu uključena u primarni ključ povezana su punom funkcionalnom ovisnošću s primarnim ključem).

Ako je ključ kandidata prost, tada je relacija automatski u 2NF.

Da bi se eliminisala ovisnost atributa o dijelu složenog ključa, potrebno je izvršiti raspadanje višeodnosne veze. Atributi koji zavise od dijela kompleksnog ključa stavljaju se u posebnu relaciju.

Atributi veze se nazivaju međusobno nezavisni , ako nijedno od njih nije funkcionalno ovisno o drugom.

Def.3. Veza je unutra treći normalni oblik (3NF) ako i samo ako je relacija u 2NF i svi neključni atributi su međusobno nezavisni (to jest, nijedno od neključnih polja relacije ne zavisi funkcionalno od bilo kojeg drugog neključnog polja).

Da biste eliminirali ovisnost ne-ključnih atributa, morate rastaviti odnos na nekoliko relacija. U ovom slučaju, oni ne-ključni atributi koji su zavisni stavljaju se u posebnu relaciju.

Kada se relacije svode pomoću algoritma normalizacije na relacije u 3NF, pretpostavlja se da sve relacije sadrže jedan kandidatski ključ. To nije uvijek tačno. Postoje slučajevi kada relacija može sadržavati više ključeva.

Def.4. Veza je unutra Bays-Codd normalna forma (NFBK) ako i samo ako su determinante svih funkcionalnih zavisnosti potencijalni ključevi (ili ako se bilo koja funkcionalna zavisnost između njenih prijatelja svede na potpunu funkcionalnu zavisnost od mogućeg ključa).

Ako je relacija u BCNF, onda je ona automatski u 3NF, kao što slijedi iz definicije 4. Da bi se eliminirala ovisnost o determinantama koje nisu potencijalni ključevi, treba izvršiti dekompoziciju, stavljajući ove determinante i dijelove koji zavise od njih u odvojeni odnos.

Postoje slučajevi kada relacija ne sadrži nikakve funkcionalne zavisnosti. One. stav je potpuno ključan, tj. ključ odnosa je čitav skup atributa. Dakle, imamo viševrijednu ovisnost, jer Još uvijek postoji odnos između atributa.

Def.5. Veza je unutra četvrti normalni oblik (4NF) ako i samo ako je relacija u BCNF-u i ne sadrži netrivijalne viševrijedne zavisnosti.

Relacije s netrivijalnim viševrijednim ovisnostima nastaju, po pravilu, kao rezultat prirodne povezanosti dvije relacije preko zajedničkog polja, koje nije ključno ni u jednoj relaciji. U stvarnosti, to dovodi do pohranjivanja informacija o dva nezavisna entiteta u jednoj relaciji.

Da biste eliminirali netrivijalne viševrijedne zavisnosti, možete rastaviti originalnu relaciju na nekoliko novih.

Def.6. Veza je unutra peti normalni oblik (5NF) ako i samo ako je bilo koja prisutna zavisnost veza trivijalna.

Def.6. identično također slijedi definiciju.

Def.7. Relacija nije u 5NF ako relacija ima netrivijalnu zavisnost spajanja.

To. Ako u svakoj potpunoj dekompoziciji sve projekcije originalne relacije sadrže mogući ključ, možemo zaključiti da je relacija u 5NF. Relacija koja nema nikakvu potpunu dekompoziciju je također u 5NF.

Bez znanja o tome koji su potencijalni ključevi u vezi i kako su atributi međusobno povezani, ne može se reći da je ova relacija u 5NF ili drugim normalnim oblicima.

Mogući ključ relacija je skup atributa relacije koji potpuno i jedinstveno (funkcionalno potpuno) određuju vrijednosti svih ostalih atributa relacije. Općenito, relacija može imati više mogućih ključeva. Među svim mogućim ključevima veze obično se bira jedan, koji se smatra glavnim i koji se naziva primarnim ključem odnosa.

Međusobno nezavisni atributi – to su atributi koji ne zavise jedan od drugog. Ako postoji nekoliko fizičkih zakona u vezi, onda se svaki atribut ili skup atributa o kojem ovisi drugi atribut naziva determinantom relacije.

9. Relaciona algebra.

Relaciona algebra pruža okvir za pristup relacionim podacima. Glavna svrha algebre je da pruži izraze koji se mogu zapisati. Izrazi se mogu koristiti za:

· definicije područja uzorci, tj. definiranje podataka za odabir kao rezultat operacije uzorkovanja;

· definicije područja ažuriranja, tj. definiranje podataka koji se ubacuju, mijenjaju ili brišu kao rezultat operacije ažuriranja;

· definicija (imenovani) virtuelni odnosi, tj. prezentacija podataka za vizualizaciju kroz prikaze;

· definicija snapshot-a, tj. definiranje podataka koji se pohranjuju kao “snimka” odnosa;

· definisanje sigurnosnih pravila, tj. utvrđivanje podataka za koje se vrši kontrola pristupa;

· utvrđivanje zahtjeva održivosti, tj. utvrđivanje podataka koji su uključeni u opseg za određene operacije kontrole konkurentnosti;

· definisanje pravila integriteta, tj. neka specifična pravila koja baza podataka mora zadovoljiti, zajedno sa općim pravilima koja predstavljaju dio relacionog modela i primjenjuju se na svaku bazu podataka.

Implementacije specifičnih relacionih DBMS-a trenutno ne koriste čistu relacionu algebru ili relacioni račun u svom čistom obliku. De facto standard za pristup relacionim podacima postao je SQL (Structured Query Language).

Relaciona algebra, koju je definisao Codd, sastoji se od 8 operatora koji se sastoje od 2 grupe:

tradicionalni set operacija (unija, presek, oduzimanje, kartezijanski proizvod);
specijalne relacione operacije (izbor, projekcija, veza, podjela).

Osim toga, algebra uključuje operaciju dodjele, koja vam omogućava da sačuvate rezultate izračunavanja algebarskih izraza u bazi podataka, i operaciju preimenovanja atributa, koja omogućava pravilno formiranje zaglavlja (šeme) rezultirajuće veze.

Kratak pregled operatora relacione algebre.

Uzorak– vraća relaciju koja sadrži sve skupove određene relacije koje zadovoljavaju neke uslove. Operacija uzorkovanja se također naziva operacija ograničenja ( ograničiti - ograničenje, sada se češće prihvata uzorkovanje - SELECT ).

Projekcija– vraća relaciju koja sadrži sve torke (tj. - pod-torke) određene relacije nakon što se iz nje izuzmu neki atributi.

Posao– vraća relaciju koja sadrži sve moguće torke koji su kombinacija dvaju torki koji pripadaju dvije definirane relacije, respektivno.

Udruženje– vraća relaciju koja sadrži sve torke koje pripadaju jednom ili oba definirana odnosa.

raskrsnica –vraća relaciju koja sadrži sve torke koje istovremeno pripadaju dvije definirane relacije.

oduzimanje –vraća relaciju koja sadrži sve skupove koji pripadaju prvoj od dvije definirane relacije, a ne drugoj.

Veza (prirodna) – vraća relaciju čiji su tokovi kombinacija dvaju torki (koji pripadaju dvije definirane relacije) koje imaju zajedničku vrijednost za jedan ili više zajedničkih atributa dvije relacije (i takve zajedničke vrijednosti se pojavljuju samo jednom u rezultirajućem tupleu, ne dva puta).

divizija –za dvije relacije, binarnu i unarnu, vraća relaciju koja sadrži sve vrijednosti jednog atributa binarne relacije koje odgovaraju (u drugom atributu) svim vrijednostima u unarnoj relaciji.

LITERATURA

1. Datum K.J. Uvod u sisteme baza podataka, 6. izdanje: Trans. sa engleskog - TO.; M.; St. Petersburg: Williams Publishing House, 2000. – 848 str.

2. Connolly T., Begg K., Strachan A. Baze podataka: dizajn, implementacija i održavanje. Teorija i praksa, 2. izd.: Trans. sa engleskog – M.: Williams Publishing House, 2000. – 1120 str.

3. Karpova T.S. Baze podataka: modeli, razvoj, implementacija. – Sankt Peterburg: Petar, 2001. – 304 str.

4. Faronov V.V., Šumakov P.V. Delphi 4. Vodič za programere baze podataka. – M.: “Znanje”, 1999. – 560 str.

5. J. Groff, P. Weinberg. SQL: Kompletan vodič: Per. sa engleskog – K.: Izdavačka grupa BHV, 2001. – 816 str.

6. Ken Goetz, Paul Litwin, Mike Gilbert. Access 2000. Vodič za programere. T.1, 2. Per. sa engleskog – K.: Izdavačka grupa BHV, 2000. – 1264 str., 912 str.

7. Maklakov S.V BPwin i EPwin. CASE-alati za razvoj informacionih sistema. – M.: DIJALOG-MEPhI, 2001. – 304 str.

8. Ullman D., Widom D. Uvod u sisteme baza podataka / Transl. sa engleskog – M.: “Lori”, 2000. – 374 str.

9. Khomonenko A.D., Tsygankov V.M., Maltsev M.G. Baze podataka: Udžbenik za visokoškolske ustanove / Ed. Prof. A.D. Khomonenko. – Sankt Peterburg: CORONA print, 2000. – 416 str.