Potpuna funkcionalna ovisnost bd. Funkcionalna zavisnost baze podataka

Predavanja br. 8-9.

funkcionalna zavisnost. normalne forme.

Svrha časa: upoznati učenike sa definicijom funkcionalne zavisnosti atributa, konceptom normalizacije početne relacije, govoriti o razlozima koji dovode do potrebe za normalizacijom fajlova zapisa, uvesti načine da se osigura potreban nivo normalnosti tabele, da bi se odredili normalni oblici pomoću konkretnog primera.

Funkcionalne zavisnosti

Teorija normalizacije, kao i teorija baze podataka općenito, zasniva se na matematičkom aparatu, koji se temelji na teoriji skupova i elementima algebre.

Isti podaci se mogu grupirati u tabele (relacije) Različiti putevi. Grupisanje atributa u relacijama treba da bude racionalno (tj. dupliciranje podataka treba da bude minimalno) i da pojednostavi procedure za njihovu obradu i ažuriranje. Uklanjanje suvišnosti podataka jedan je od najvažnijih zadataka dizajna baze podataka i obezbjeđuje se normalizacijom.

Normalizacija tabela (relacija)- ovo je formalni aparat ograničenja formiranja tabela (relacija), koji vam omogućava da eliminišete dupliciranje, osigurava konzistentnost onih pohranjenih u bazi podataka i smanjuje troškove rada za održavanje (unos, ispravljanje) baze podataka. Proces normalizacije sastoji se u dekomponovanju (dekomponovanju) početnih odnosa baze podataka na više jednostavan odnos. Svaka faza ovog procesa dovodi shemu odnosa u uzastopne normalne oblike. Za svaku fazu normalizacije, postoje skupovi ograničenja koja odnosi baze podataka moraju zadovoljiti. Normalizacija vam omogućava da uklonite suvišne ne-ključne informacije iz tablica baze podataka.

Prvo, prisjetimo se nekih koncepata:

jednostavan atribut je atribut čije su vrijednosti nedjeljive. Drugim riječima, u tabeli nema polja tipa Puno ime ili Adresa - ona se dekomponuju na Prezime, Ime, Patronimija u prvom slučaju i na polja Poštanski broj, Grad itd. u drugom slučaju. .

Složeni (kompozitni) atribut dobijeno kombinovanjem nekoliko atomskih atributa, inače se naziva vektor ili agregat podataka.

Definicija funkcionalne zavisnosti: Neka bude X i Y su atributi neke relacije. Ako u bilo kom trenutku proizvoljna vrijednost X odgovara jednoj vrijednosti Y, tada je Y funkcionalno ovisan od X (X→Y)

Ako je ključ kompozitni, onda bilo koji atribut mora ovisiti o ključu u cjelini, ali ne može biti funkcionalno ovisan ni o jednom dijelu kompozitnog ključa, tj. funkcionalna zavisnost ima oblik (X 1 , X 2 , ..., X)→Y.

Funkcionalna ovisnost može biti potpuna ili nepotpuna.

Nepotpuna ovisnost naziva se ovisnost atributa koji nije ključ od dijela kompozitnog ključa .

Potpuna funkcionalna ovisnost naziva se zavisnost neključnog atributa o cijelom kompozitnom ključu, a ne o njegovim dijelovima.

Definicija tranzitivne funkcionalne zavisnosti: Neka bude X, Y, Z- tri atributa neke relacije. At Ovo je Tom X→Y i Y→Z, ali nema obrnute korespondencije, to jest, Y ne zavisi od Z, a X ne zavisi od Y. Onda to kažu Z tranzitivno zavisi od X.

Definicija viševrijedne zavisnosti: Neka su X i Y atributi neke relacije. Y atribut visoko zavisna iz atributa X ako. svaka X vrijednost odgovara skupu Y vrijednosti koje nisu povezane s drugim atributima iz relacije. Viševrijedne zavisnosti mogu biti jedan prema više (1:M), više prema jedan (M:1) ili više prema više (M:M), označene redom: X=>Y, Y<=X и X<=>Y. Na primjer, nastavnik predaje nekoliko predmeta, a svaki predmet može predavati nekoliko nastavnika, tada postoji naziv zavisnosti <=> Predmet.

Razmotrimo sljedeći primjer: Pretpostavimo da je za obrazovni dio fakulteta kreirana baza podataka o nastavnicima, koja uključuje sljedeće atribute:

Puno ime - prezime i inicijali nastavnika (isključena su podudarnosti prezimena i inicijala).

Pozicija - pozicija koju drži nastavnik.

Plata je plata nastavnika.

Iskustvo - nastavno iskustvo. D_Stage - bonus za staž.

Odsjek - broj odjeljenja gdje je nastavnik registrovan.

Predmet - naziv predmeta (discipline) koji čita nastavnik.

Grupa - broj grupe u kojoj nastavnik izvodi nastavu.

Tip časa - vrsta nastave koju izvodi nastavnik u studijskoj grupi.

Početni stav UČITELJ

Informacije su uvijek imale odgovarajući dinamički interes. Razvoj programskih jezika, relacione baze podataka data i informaciona tehnologija radikalno je promenila sadržaj i strukturu interesovanja. Razvio se određeni strogi sistem reprezentacija. Formalizacija, egzaktna matematika i binarni odnosi postali su uspješno i brzo razvijajuće polje znanja i iskustva.

Prirodni svijet informacija nije promijenio svoju dinamiku i, razvijajući sadržaj i strukturu, uzdigao se do novih visina. Ima glatke forme i nema ničega u prirodi "pravougaoni". Informacije se, naravno, podležu formalizaciji, ali imaju dinamiku, ne mijenjaju se samo podaci i algoritmi za njihovu obradu, već se mijenjaju i sami zadaci i područja njihove primjene.

Informacije > formalizacija >> podaci

Informacije se pretvaraju u informacijsku strukturu, bazu podataka...) kako je programer vidi. Nema garancije da je ova vizija ispravna, ali ako njegov program ispuni zadatak, onda su podaci predstavljeni kao eventualno odgovarajući.

Pitanje koliko su tačne informacije formalizovane pitanje je vremena. Do sada je koncept dinamike (samoprilagođavanja promjenjivim uvjetima korištenja) samo programski san.

Funkcionalna zavisnost: " ispravno rješenje= program (programer)" i uslov: "kontinuirano uklapanje u zadatak" vrijede u većini slučajeva, ali samo zajedno. Ali ovo nije matematička osnova koja se koristi pri kreiranju baza podataka.

Direktna izjava: prirodna i kontinuirana dinamika informacija i algoritama za rješavanje problema uvijek je istinita. A to su binarni odnosi + stroga matematika + precizne formalne konstrukcije, + ...

i baze podataka

Kako se podaci pohranjuju dugo je bilo nevažno: bilo da je tako RAM ili eksterni uređaj. Hardverska komponenta je dostigla stabilan tempo razvoja i pruža dobra kvaliteta u velikim količinama.

Glavne opcije pohrane koje se razlikuju u slučajevima korištenja podataka su:

• datoteke;
• Baza podataka.

Prvi je na milost i nemilost programera (šta napisati, u kom formatu, kako to učiniti, kako čitati...), drugi odmah donosi potrebu za poznavanjem jednostavne funkcionalne zavisnosti.

Brzina preuzimanja i pisanja informacija pri radu sa datotekama (razumne veličine, a ne astronomske) je veoma velika, a brzina sličnih operacija sa bazom podataka ponekad može biti primetno spora.

Lično iskustvo i kolektivni um

U istoriji je bilo pokušaja da se prevaziđe dostignute granice, ali do danas dominiraju relacione baze podataka. Akumuliran je veliki teorijski potencijal, praksa primjene je opsežna, a programeri su visoko kvalifikovani.

Programeri baze podataka nameću koncept funkcionalne zavisnosti programeru, čak i ako on ne namerava da koristi bogato matematičko i logičko iskustvo u izgradnji složenih informacionih struktura, radu sa njima, uzorkovanju i snimanju informacija.

Čak iu jednostavan slučaj programer zavisi od logike baze podataka sa kojom odabere da radi. Nema želje da se pridržavate kanona, možete koristiti fajlove, dobijate puno fajlova i mnogo lično iskustvo. Utrošit će se puno ličnog vremena i zadatak će biti riješen za dugo vremena.

Koliko god se činili složeni primjeri funkcionalne ovisnosti, uopće nije potrebno uranjati u dubine značenja i logike. Često se to mora prepoznati kolektivni um uspeo da napravi odlične baze podataka, različite veličine i funkcionalnost:

• solid Oracle;
• zahtjevan MS SQL Server;
• popularan MySQL.

Odlične relacijske baze podataka sa dobrom reputacijom, jednostavne za korištenje, brze u pravim rukama. Njihova upotreba štedi vrijeme i eliminira potrebu za pisanjem još jednog lista pomoćnog koda.

Karakteristike programiranja i podataka

Programiranje dugo vremena ima bolest stalnog prepisivanja nečega, ponavljanja rada prethodnika, kako bi se nešto na neki način prilagodilo promijenjenoj informaciji, zadatku ili uslovima za njegovu upotrebu.

Posebnost funkcionalne zavisnosti je da, kao iu programiranju, greška može biti veoma skupa. Zadatak je rijetko lak. Obično se tokom formalizacije informacija dobija složena reprezentacija podataka. Obično se razlikuju njihovi elementi, zatim se povezuju ključevima u određene relacije, zatim se prilagođavaju algoritmi za formiranje tabela, upita, algoritmi za izdvajanje informacija.

Često veliki značaj ima vezu za kodiranje. Ne nude sve baze podataka mobilna rješenja, često se možete susresti kako savršeno konfiguriran MySQL, na kojem leži desetak baza podataka, koji radi savršeno i stabilno, prisiljava programera da napravi jedanaestu bazu podataka slični onima koji su već tamo.

Ima trenutaka kada dijeljeni hosting ograničava funkcionalnost PHP-a i to utiče na programiranje pristupa bazi podataka.

IN savremeno programiranje odgovornost za programski algoritam je ekvivalentna odgovornosti za kreiranje modela podataka. Sve bi trebalo da funkcioniše, ali ne treba uvek roniti u divljinu teorije.

DB: jednostavna ovisnost o podacima

Prije svega, koncept baze podataka je i baza podataka kao sistem upravljanja (na primjer, MySQL) i određena informacijska struktura koja odražava podatke zadatka i odnose između njih. Jedan MySQL baza podataka"drži" bilo koji broj informacijskih struktura u različitim poljima primjene. Jedan Oracle baza, može pružiti informacionih procesa velika kompanija ili banke, za kontrolu sigurnosti i sigurnosti podataka o najviši nivo, koji se nalazi na raznim računarima koji se nalaze na različita udaljenost, u raznim instrumentalnim okruženjima.

Općenito je prihvaćeno da je odnos glavna stvar relacioni model. Elementarna relacija je skup kolona s imenima i redova sa vrijednostima. Classical "pravougaonik"(tabela) - jednostavan i efikasan napredak. Složenost i funkcionalna zavisnost baze podataka počinje kada "pravokutnici" počinju da komuniciraju jedni s drugima.

Ime svake kolone u svakoj tabeli mora biti jedinstveno u kontekstu zadatka. Isti podaci ne mogu biti u dvije tabele. Znati značenje pojmova:

• "definirati entitete";
• "eliminirati višak";
• "popraviti odnose";
• „osigurati kredibilitet“.

Elementarna potreba za korištenje baze podataka i izgradnju modela podataka za određeni zadatak.

Kršenje bilo kojeg od ovih koncepata - niska efikasnost algoritma, sporo uzorkovanje podataka, gubitak podataka i drugi problemi.

Funkcionalna zavisnost: logika i značenje

Ne možete čitati o skupovima relacija, o činjenici da je funkcija korespondencija skupa argumenata skupu vrijednosti, a funkcija nije samo formula ili graf, već se može postaviti skupom vrijednosti - sto.

Nije potrebno, ali uopće ne škodi funkcionalnu ovisnost predstaviti kao:

F(x1, x2, …, xN) = (y1, y2, …, yN).

Ali budite sigurni da shvatite da je ulaz tabela, izlaz je također tablica ili specifično rešenje. Tipično, funkcionalna zavisnost uspostavlja logiku odnosa između tabela, upita, privilegija, okidača, pohranjenih procedura i drugih momenata (komponenti) baze podataka.

Obično se tabele konvertuju jedna u drugu, a zatim u rezultat. Ali upotreba funkcionalne zavisnosti nije ograničena samo na takvu ideju. Programer sam gradi svoj vlastiti prikaz slike podataka, informaciona struktura... nije bitno kako ga zovete, ali ako radi na određenoj bazi podataka, mora biti izgrađena prema svojoj logici, uzeti u obzir njeno značenje i dijalekt jezika koji se koristi, obično SQL.

Može se tvrditi da su svojstva funkcionalne zavisnosti baze podataka dostupna preko dijalekta baze podataka koja se koristi. SQL jezik. Ali mnogo je važnije razumjeti: nakon svih peripetija razvoja, nije preživjelo mnogo baza podataka, ali postoji mnogo dijalekata ovog jezika i karakteristika unutrašnje strukture i u bazama.

O dobrom starom Excelu

Kada se računar pokazao sa pozitivnu stranu, svijet se odmah podijelio na programere i korisnike. U pravilu, prva upotreba:

• PHP, Perl, JavaScript, C++, Delphi.
• MySQL, Oracle, Visual FoxPro.

• riječ.
• Excel.

Neki korisnici uspevaju da urade svoje (bez pomoći programera) u Word bazi podataka - prava glupost.

Korisničko iskustvo u Excelu za kreiranje baza podataka je praktično i zanimljivo. Važno je da je Excel, sam po sebi, funkcionalan, šaren i praktičan.

Tabelarna ideja je definisala koncept funkcionalne zavisnosti na jasan i pristupačan način, ali svaka baza podataka ima nijanse. Svaki ima svoje "lice", ali svi od Excela do Oraclea manipulišu jednostavnim kvadratima, odnosno tabelama.

S obzirom na to da Excel uopće nije baza podataka, već ga mnogi korisnici (neprogrameri) koriste na taj način, a Oracle je najsloženije i najmoćnije dostignuće velikog tima programera u oblasti baza podataka, prirodno je priznati da baza podataka je specifična reprezentacija programera (tima) o tome konkretan zadatak i njenu odluku.

Šta je funkcionalna zavisnost, od čega, gde, zašto... to je očigledno samo autoru ili njihovom timu.

O tome gdje idu relacijski odnosi

Naučno-tehnološki napredak je veoma bolan postupak, a ponekad i okrutan. Ako se sjećate kako su počele baze podataka, šta je *.dbf, kako je kibernetika stigmatizirana, onda su se zaljubili u informatiku i počeli stvarati barijere kretanju visoke tehnologije na nivou države postaje jasno zašto su relacione baze podataka tako izdržljive i dobre. Zašto klasični stil programiranje živi do danas, a objektno orijentirano programiranje je jednostavno cijenjeno, ali još uvijek ne dominira.

Bez obzira koliko je lepa funkcionalna zavisnost u kontekstu matematike:

Ovo nije binarni odnos, tačnije, to je prilika da se preispita ideja o uspostavljanju odnosa između mnogih atributa, da se istraže odnosi "jedan prema mnogo", "mnogo prema jednom", "mnogo prema mnogo" ili "mnogo" općenito, a jedan posebno."

Postoji mnogo opcija za veze. To je matematika sa logikom, i to je strogo! Informacija je sopstvena matematika, posebna. U njemu se o formalnosti može govoriti samo sa veoma velikim minusom.

Možete formalizirati rad kadrovske službe, napisati automatizirani kontrolni sistem za proizvodnju ulja ili proizvodnju mlijeka, kruha, napraviti uzorak u ogromna baza Google, Yandex ili Rambler, ali rezultat će uvijek biti statičan i svaki trenutak vremena je isti!

Ako je funkcionalna zavisnost = stroga logika i matematika = osnova za baze podataka, o kakvoj dinamici onda možemo govoriti. Bilo koje rješenje će biti formalno, bilo koji formalni model podataka + rigorozni algoritam = tačno i nedvosmisleno rješenje. Informacije i opseg bilo kojeg programa uvijek se mijenjaju.

Uzorak pretraživač na istoj frazi za pretragu ne može biti ista za sat ili dva i, definitivno, za dan - ako fraza za pretragu odnosi se na oblast informacija u kojoj se broj sajtova, resursa, znanja i drugih elemenata stalno menja.

Čak i ako je program čisto matematički i njegova baza podataka uopće ne razmišlja o dinamici, sve je uvek na liniji. I niz ima dužinu. I ne može biti beskonačan. Ne može čak ni biti varijabla, već samo uslovna varijabla. Između ostalog, svaka baza podataka sa svojim matematičkim i binarno-birokratskim aparatom nameće puno formalnosti, a to je brzina + kvalitet uzorkovanja i obrade informacija.

A ako su određena polja u bazi podataka brojevi, posebno stvarni, onda će se dodati ograničenjima: kapacitet broja, prisustvo slova "e", format prezentacije - ukratko, svugdje i uvijek imamo bitan svojstva funkcionalne zavisnosti baze podataka: nizovi uslovno promenljive dužine sa puno binarnih formalnosti i strogih matematičkih ograničenja.

Ako promijenite ton i osluškujete puls dinamike, onda se sve može oslikati u objekte. Kao prva aproksimacija, naziv kolone u tabeli je objekat, lista imena je takođe objekat, ukratko, tabela je objekat zaglavlja i sadrži nazive kolona u zaglavlju. A možda uopće nema šešira...

Ali tabela može imati redove. I u nizu mogu biti vrijednosti. I zašto bi uvijek bili isti broj. Pun kvadratni sto- ovo je posebna, au većini slučajeva, privatna.

Ako sve konstrukcije u bazi podataka predstavimo kao objekte, možda nećemo morati da gradimo stroge binarne odnose. Ovo ima prirodno i stvarno značenje, makar samo zato što, prema objektivnoj (definitivno ne matematičkoj) logici, odražava dinamiku informacija i okruženje u kojem zadaci postoje.

Atribut B funkcionalno zavisna iz atributa A ako svaka vrijednost A odgovara tačno jednoj vrijednosti B.

Oznaka: A → B. To znači da će u svim torkama sa istom vrijednošću atributa A, atribut B također imati istu vrijednost.

Ako postoji funkcionalna zavisnost oblika A → B i B → A, onda postoji između A i B dopisivanje jedan na jedan, ili funkcionalna zavisnost. O

Oznaka: A↔B ili B↔A.

Ako je relacija u 1NF, tada su svi atributi koji nisu ključ funkcionalno ovisni o ključu s različitim stupnjevima ovisnosti.

Djelimična zavisnost(djelomična funkcionalna ovisnost) - ovisnost atributa koji nije ključ od dijela kompozitnog ključa.

Potpuna funkcionalna ovisnost– ovisnost neključnog atributa o cijelom kompozitnom ključu.

tranzitivna zavisnost

Atribut C zavisi od atributa A tranzitivno(postoji tranzitivna zavisnost), ako su za atribut A, B, C ispunjeni uslovi A→B i B→C, nema inverznih odnosa.

Višestruka ovisnost

Za R atribut B visoko zavisna iz atributa A, ako svaka vrijednost A odgovara skupu vrijednosti B koje nisu povezane s drugim atributima R.

Notacija: A=>B, A<=B, A<=>b.

Međusobno nezavisni atributi

Pozivaju se dva ili više atributa međusobno nezavisni ako nijedan od ovih atributa nije funkcionalno ovisan o drugim atributima.

Notacija: A →B, A=B.

Normalni oblici:

Prvo normalna forma (1NF). Relacija je u 1NF ako su svi njeni atributi jednostavni (imaju jednu vrijednost).

Drugi normalni oblik(2NF). Relacija je u 2NF ako je u 1NF i svaki atribut koji nije ključ je funkcionalno ovisan o primarnom (kompozitnom) ključu.

treći normalni oblik(3NF). Relacija je u 3NF ako i samo ako su svi atributi relacije međusobno nezavisni i potpuno zavisni od primarnog ključa.

Boyce-Codd normalna forma(NFBK). Odnos je u BCNF-u ako je u 3NF-u i nema ovisnosti o ključu (kompozitnim atributima ključa) o ne-ključnim atributima.

četvrti normalni oblik(4NF). Relacija je u 4NF ako i samo ako postoji višeznačna zavisnost A => B, a svi ostali atributi relacije su funkcionalno zavisni od A.

Peti normalni oblik(5NF). Relacija je u 5NF ako je u 4NF i zadovoljava zavisnosti konekcije u odnosu na svoje projekcije.

šesti normalni oblik(6NF). Relacija je u 6NF ako i samo ako se ne može dalje razložiti bez gubitka.

Osiguravanje konzistentnosti i integriteta podataka u bazi podataka

Odgovori :

Integritet- ovo je svojstvo baze podataka, što znači da sadrži potpune, dosljedne i adekvatno odražavaju informacije o predmetnoj oblasti.

razlikovati:

fizički integritet- Dostupnost fizički pristup na podatke i da podaci nisu izgubljeni.

logički integritet- odsustvo logičkih grešaka u bazi podataka, koje uključuju kršenje strukture baze podataka ili njenih objekata, brisanje ili promjenu uspostavljene veze između objekata itd.

Održavanje integriteta baze podataka uključuje:

Provjera integriteta (kontrola)

Oporavak u slučaju neslaganja u bazi podataka.

Stanje integriteta je dato sa ograničenja integriteta(uslovi koje podaci moraju zadovoljiti). Dva tip ograničenja integriteta:

Ograničavanje vrijednosti atributa odnosa. Na primjer: zahtjev nevažećih NULL-vrijednosti, nevažećih duplih vrijednosti u atributima, kontrola vlasništva nad vrijednostima atributa datog raspona.

Strukturna ograničenja na tuple relacija. Definira zahtjeve integritet entiteta i referentni integritet.

Requirement integritet entiteta je li to bilo koji skup relacije mora biti različit od bilo kojeg drugog torka ove relacije, drugim riječima, svaka veza mora imati primarni ključ.

Requirement integritet veze je da za svaku vrijednost stranog ključa roditeljske tablice mora postojati red u podređenoj tablici s istom vrijednošću primarnog ključa.

Metoda entitet-odnos

Odgovori :

Metoda entitet-odnos(metoda ER dijagrama) je metoda zasnovana na upotrebi dijagrama, odnosno nazvanih dijagrami ER instance i dijagrami tipa ER.

Osnovni koncepti

Essence je objekt, informacije o kojem se pohranjuju u bazi podataka.

Atribut je vlasništvo entiteta.

Ključ entiteta je atribut (skup atributa) koji se koristi za identifikaciju instance entiteta.

Veza između entiteta je zavisnost između atributa ovih entiteta.

Grafički alati koristi se za jasnoću i praktičnost dizajna:

DijagramER-kopije;

DijagramER-tip ili ER-dijagram.

Na osnovu analize ER-dijagrama formiraju se relacije projektovane baze podataka. Ovo uzima u obzir stepen povezanosti entiteta i klasa njihovog članstva.

Stepen povezanosti je karakteristika odnosa između entiteta (1:1, 1:M; M:1; M:M).

klasa članstva entiteti mogu biti: obavezna I opciono.

Obavezno– ako sve instance subjekta nužno učestvuju u odnosu koji se razmatra.

Opciono– ne učestvuju sve instance u razmatranom odnosu.

Koraci dizajna baze podataka

Odgovori :

I. Idejno rješenje– prikupljanje, analiza i uređivanje zahtjeva podataka.

Target: kreacija konceptualni model podaci zasnovani na percepciji korisnika predmetna oblast.

Procedure:

Definicija entiteta i njihova dokumentacija;

Definiranje odnosa između entiteta i njihovo dokumentiranje;

Kreiranje modela domene;

Definiranje vrijednosti atributa;

Definiranje primarnih ključeva za entitete.

II. Logic design– na osnovu konceptualnog modela kreira se struktura podataka.

Target: transformacija konceptualnog modela zasnovanog na odabranom modelu podataka u logički model, nezavisno od karakteristika DBMS-a koji će se u budućnosti koristiti za fizičku implementaciju baze podataka.

Procedure:

Odabir modela podataka;

Definisanje skupa tabela i njihove dokumentacije;

Normalizacija tablice;

Određivanje zahtjeva za održavanje integriteta podataka i njihove dokumentacije.

III. Fizički dizajn– definicija karakteristika podataka i metoda pristupa.

Svrha: opis konkretne implementacije baze podataka, postavljanje u eksternu memoriju kompjuter.

Procedure:

Dizajniranje tablica baze podataka;

Dizajn fizička organizacija DB;

Izrada strategije zaštite baze podataka.

Životni ciklus baze podataka

Odgovori :

DB životni ciklus je proces dizajniranja, implementacije i održavanja sistema baza podataka.

Faze životnog ciklusa baze podataka:

Analiza– analiza predmetne oblasti i identifikacija zahteva za nju, procena relevantnosti sistema.

Dizajn– stvaranje logičkog strukture baze podataka, funkcionalni opis programski modeli i zahtjevi za informacijama.

Implementacija– razvoj softvera za bazu podataka, vrši se testiranje.

Eksploatacija I pratnja.

Faze životnog ciklusa baze podataka:

unapred planiranje– planiranje baze podataka, izvršenje strateški plan razvoj baze podataka (koje se aplikacije koriste, koje funkcije obavljaju, koje datoteke su povezane sa svakom od ovih aplikacija i koje nove datoteke i aplikacije su u razvoju).

Provjera izvodljivosti– provjera tehnološke, operativne i ekonomske izvodljivosti.

Definicija zahtjeva– izbor namjene baze podataka, identifikacija zahtjeva za informacijama za bazu podataka, zahtjeva za hardver i softver, određivanje zahtjeva korisnika.

Idejno rješenje- izrada idejne šeme.

Implementacija- dovođenje konceptualnog modela u funkcionalnu bazu podataka.

Izbor i nabavka potrebnog DBMS-a.

Pretvaranje konceptualnog modela u logički i fizički model.

Na osnovu informacija logički model shema podataka je napravljena za određeni DBMS.

Određuje se koji procesi aplikacije treba implementirati kao pohranjene procedure.

Implementirajte ograničenja dizajnirana da osiguraju integritet podataka.

Dizajnerski pokretači.

Razviti strategiju indeksiranja i klasteriranja, procijeniti veličine stolova, klasteri i indeksi.

Definirajte nivoe pristupa korisnika, razvijte i implementirajte sigurnosna pravila.

Razviti topologiju mreže baze podataka.

Kreiranje rječnika podataka.

Popunjavanje baze podataka.

Izrada aplikativnog softvera, kontrola upravljanja.

Obuka korisnika.

Evaluacija i poboljšanje šeme baze podataka.

Pravila izgradnje odnosa

Odgovori :

Pravila formiranja odnosi se zasnivaju na sledećem:

Stepen povezanosti između entiteta (1:1, 1:M, M:1, M:M);

Klasa članstva instanci entiteta (obavezno i ​​opciono).

a. Kada razmatramo kvantitativnu stranu različitih procesa, gotovo uvijek primjećujemo da varijable zavise jedna od druge; na primjer, put kojim slobodno pada tijelo u vakuumu ovisi samo o vremenu, pritisak u parnom kotlu ovisi samo o temperaturi pare.

Dubina okeana u jednoj tački je konstantna, ali na razne tačke različito, zavisi samo od dvije varijable - od geografske dužine i geografska širina mjesta.

Visina rastućeg drveta zavisi od mnogih varijabli - sunčeve svetlosti, vlažnosti, količine hranljivih materija u tlu, itd.

Vidimo da se neke varijable mijenjaju nezavisno, nazivaju se nezavisne varijable ili argumenti, dok druge ovise o njima, nazivaju se funkcijama.

Sama zavisnost naziva se funkcionalnom. Inače, funkcionalna ovisnost je jedna od najvećih važnih koncepata matematike.

b. Uvijek treba razlikovati od kojeg broja nezavisnih varijabli funkcija ovisi. Najlakše je proučavati funkcije jedne varijable, njima ćemo se prije svega pozabaviti. Proučavanje funkcija mnogih varijabli je teže, ali se na ovaj ili onaj način svodi na proučavanje funkcija jedne varijable.

c. Ako želimo matematički zapisati da varijabla y ovisi o , tada ćemo koristiti sljedeću notaciju:

Ovaj unos glasi:

Ne; treba misliti da je slovo pomnoženo sa , to je samo skraćenica od riječi "funkcija", a cijela notacija je skraćeni izraz (2).

Slično, ako funkcija U ovisi o dva argumenta, tada se ova ovisnost označava na sljedeći način:

Ovdje slova f, x i y također nisu faktori.

Sasvim je jasno kako se označava funkcija tri četiri ili više argumenata.

Umjesto slova najčešće se koriste druga slova.

d. Zapisi poput (1) i (3) su najopćenitije oznake funkcija, budući da se mogu shvatiti kao bilo koje funkcije, pa stoga, imajući samo ove oznake u ruci, nećemo moći ništa naučiti o svojstvima ovih funkcija. .

Da biste mogli proučiti funkciju, morate je definirati.

e. Postoji mnogo načina za definiranje funkcije, ali svi se svode na tri osnovna tipa:

1) funkcija se može definisati pomoću tabele njenih numeričkih vrednosti koje odgovaraju numeričkim vrednostima njenog argumenta;

2) funkcija se može specificirati grafički;

3) funkcija se može podesiti matematička formula.

f. Navedimo primjere. Poznato je da kada se zamašnjak okreće, nastaju naprezanja koja imaju tendenciju da slome njegov rub. Ako je naplatak kotača izrađen od homogenog materijala, tada naponi ovise samo o brzini rotacije. Označavajući brzinu kao v i napon na obodu kao , možemo to napisati

Teorija otpornosti materijala daje sljedeću tablicu za vrijednosti funkcije (4) ako je obod izrađen od lijevanog čelika:

Ovdje se v mjeri u metrima u sekundi - Njutnima po kvadratnom centimetru.

Velika prednost tabelarnog načina postavljanja funkcije je što se brojevi u tabeli mogu direktno koristiti za različite proračune.

Nedostatak je što se bilo koja tablica ne daje za sve vrijednosti argumenta, već u određenim intervalima, pa ako u tablici nema vrijednosti funkcije, onda treba uzeti detaljniju tablicu; ako potonjeg nema, potrebno je odabrati traženi broj, manje-više približno, u skladu s prirodom promjene brojeva tabele,

g. Veliki nedostatak je i to što ako tabela sadrži mnogo brojeva, onda je teško uhvatiti prirodu promjene funkcije. Konačno, treći nedostatak je da proučavanje svojstava funkcije, data tabela, hard; štaviše, rezultirajuća svojstva će biti netačna.

h. Slobodno od prva dva grafički način funkcije.

Da biste ilustrirali grafičku metodu, razmotrite sljedeći primjer.

Ako je bilo koji materijal podvrgnut istezanju, tada će sila potrebna za istezanje ovisiti o tome koliko rastezanja treba biti učinjeno, odnosno, sila je funkcija istezanja. Ako je postotak istezanja označen sa X, a zatezna sila, koja se obično mjeri u Njutnima po kvadratnom centimetru, označena je sa , tada

Za razni materijali ovaj odnos će biti drugačiji. Uzmimo koordinatne ose i smatramo k kao apscisu, a kao ordinatu, tada za svaki par njihovih vrijednosti dobijemo tačku na ravni.

Sve ove tačke će se nalaziti na nekoj krivoj, koja ima različite vrste za razne materijale. Postoje uređaji koji automatski crtaju takve krivulje.

Za meki čelik dobijamo sledeću krivu (slika 31):

k. Kao što vidimo, grafički snob je zaista jasan i daje vrijednosti funkcije za sve vrijednosti argumenata. Ali tu postoji i treći nedostatak. Još uvijek je teško proučavati svojstva funkcije date grafički.

l. Sada ćemo pokazati kako definirati funkciju pomoću formule. Uzmimo primjer. Površina kruga očigledno zavisi od radijusa. Ako je poluprečnik označen sa i, a površina sa y, tada je, kao što je poznato iz geometrije, gde je odnos obima i dužine prečnika. Vidimo da je ovisnost ovdje data matematičkom formulom, pa se treći način naziva matematičkim putem. Drugi primjer: dužina hipotenuze pravokutnog trokuta ovisi o dužinama oba kraka. Ako označimo dužinu hipotenuze kroz , i dužine nogu kroz tada, prema Pitagorinoj teoremi, imat ćemo

Budući da obje noge možemo mijenjati neovisno jedna o drugoj, ovdje imamo primjer funkcije dva argumenta, dat matematički.

Može se navesti još mnogo primjera matematički datih funkcija iz područja raznih nauka.

m. Matematička metoda ima ogromnu prednost u odnosu na druge metode specificiranja funkcija, naime: u proučavanje matematički datih funkcija može se uključiti matematička analiza.

Osim toga, ako je potrebno, uvijek možete matematički način pretvori u sto. Zaista, imamo pravo da postavljamo argumente koje želimo numeričke vrijednosti i koristite formulu da izračunate onoliko vrijednosti funkcije koliko želite. Dakle, jedna formula zamjenjuje cijelu tabelu.

n. Matematička metoda ima samo jedan nedostatak, naime, formula ne daje vizualni prikaz promjene funkcije. Međutim, ovaj nedostatak uvijek možemo nadoknaditi, jer se matematički način zadavanja uvijek može pretvoriti u grafički. To se radi ovako.

o. Ako imamo funkciju jedne varijable, tada sastavljamo tablicu i uzimamo svaki par vrijednosti argumenta i funkcije kao koordinate, nakon toga možemo graditi više bodova. Sve dobijene tačke će se nalaziti na nekoj krivoj liniji, koja će biti grafik funkcije. Ako imamo funkciju od dva ili više argumenata, onda se ona može prikazati i grafički. Ali ovo je već mnogo komplikovanije, pa ćemo se ovim pitanjem pozabaviti malo kasnije.

str. Sve navedeno ukazuje da je matematička metoda specificiranja funkcija najpovoljnija.

Stoga uvijek nastoje, ako je funkcija data tablicom ili grafikonom, da je izraze formulom. Ovaj zadatak je obično veoma težak, ali izuzetno važan za prirodne i tehničke nauke. Bez preterivanja se može reći da se svi problemi mehanike, prirodnih nauka – primenjenih nauka svode na uspostavljanje i proučavanje funkcionalnih zavisnosti između varijabli kojima se ove discipline bave. Bel uspeva da izrazi ove funkcionalne zavisnosti formulama, tada nauka dobija pouzdanu polugu za primenu sve ogromne moći matematičke analize i napreduje daleko u njenom razvoju.

S druge strane, matematička analiza, primajući ovu odličnu hranu, sama raste i napreduje.

q. S obzirom na to da prevođenje formula funkcionalnih zavisnosti na jezik nije direktan zadatak matematike, pretpostavićemo da su funkcije već izražene formulama. Dakle, u nastavku ćemo se baviti samo funkcijama datim matematičkim putem.

Napomena: Ovo predavanje uvodi koncept funkcionalne zavisnosti. Ovaj koncept je osnova matematičke teorije relacionih baza podataka.

Informacije, podaci, informacioni sistemi

Koncept funkcionalne zavisnosti u podacima

Ostavljajući za sada po strani pitanje zašto su dizajni relacionih baza podataka loši, tj. zašto trebate dizajnirati relacionu bazu podataka. Pokušajmo prvo odgovoriti na pitanja „Šta je dizajn relacione baze podataka? i "Šta je osnova procedura?"

Kao što znate, osnovna jedinica reprezentacije podataka u relacionom modelu je relacija, koja je matematički određena listom imena atributa, inače - shema odnosa. Na sceni logičan dizajn U relacionoj bazi podataka, dizajner definiše i gradi dijagrame odnosa unutar određene predmetne oblasti, naime, predstavlja entitete, grupiše njihove atribute i identifikuje glavne odnose između entiteta. Da, u samom opšti smisao Dizajniranje relacione baze podataka je informirani izbor specifičnih šema odnosa iz mnoštva različitih alternativne opcije sheme.

U praksi, konstrukcija logičkog modela baze podataka, bez obzira na korišteni model podataka, provodi se uzimajući u obzir dva glavna zahtjeva: da se eliminira redundantnost i da se maksimizira pouzdanost podataka. Ovi zahtjevi proizlaze iz zahtjeva za dijeljenjem podataka od strane grupe korisnika. Formalni način opisivanja podataka neophodnih za provjeru ispravnosti popunjavanja struktura modela očito nije dovoljan. Izbor entiteta, atributa i fiksiranje odnosa između entiteta zavisi od semantike predmetne oblasti i vrši ga sistemski analitičar subjektivno u skladu sa svojim ličnim shvatanjem specifičnosti. primijenjen zadatak. Različiti ljudi definiraju i prezentiraju podatke na različite načine.

Stoga, svako apriorno poznavanje ograničenja domena nametnutih vezama između podataka i vrijednosti podataka, te poznavanje njihovih svojstava i odnosa između njih, može igrati ulogu u ispunjavanju gore navedenih zahtjeva. Formalizacija takvog apriornog znanja o svojstvima podataka predmetnog područja baze podataka ogleda se u konceptu funkcionalna zavisnost podataka, tj. ograničenja mogućih odnosa između podataka, koji mogu biti trenutne vrijednosti šeme odnosa.

Korke relacija mogu predstavljati instance entiteti domene ili popraviti njihov odnos. Ali čak i ako su ovi tuples ispravno definirani, tj. odgovaraju shemi relacije i biraju se iz dozvoljenih domena, ne može svaki od njih biti trenutna vrijednost neke relacije. Na primjer, starost osobe rijetko je starija od 120 godina ili isti pilot ne može upravljati dva različita leta u isto vrijeme. Takva ograničenja na semantiku domene praktički ne utječu na izbor jedne ili druge sheme odnosa. To su ograničenja za tipove podataka.

A priori ograničenja predmetnog područja na odnos vrijednosti pojedinačnih atributa imaju najveći uticaj za proces dizajna sheme relacijske baze podataka. Korespondencija u vrijednosti pojedinih atributa različitih relacija baze podataka, tj. ovisnost njihovih vrijednosti jedna o drugoj, određuje indikatori pouzdanosti te ispravnost pohranjenih podataka u njihovoj zajedničkoj i dosljednoj upotrebi.

Prisjetimo se definicije funkcije kao korespondencije skupa argumenata određenim vrijednostima iz skupa definicija funkcija i načina definiranja funkcija: formule, grafikona i nabrajanja (tablica). To je lako razumjeti funkcionalna zavisnost(FZ) se može definirati na prilično širokoj klasi objekata. Definicija funkcije ne nameće nikakva ograničenja na skup argumenata i skup vrijednosti funkcije, osim njihovog postojanja i prisutnosti korespondencije između njihovih elemenata. Budući da se FD može postaviti na tabelarni način, a tabela je oblik reprezentacije odnosa, veza između FD i relacije postaje očigledna. Relacija može postaviti FZ. Ova izjava je prva (1) konstruktivna ideja koja leži u osnovi teorije dizajn relacione baze podataka.

Definicija 1. Neka je r (A 1 , A 2 , ..., A n) shema relacije R i neka su X i Y podskupovi r . Za X se kaže da funkcionalno određuje Y ako je svaki atribut vrijednost relacija tuple iz X odgovara najviše jednoj vrijednosti atributa istog relacija tuple od Y. Takav FZ je označen kao .

Kao što se vidi iz definicije, funkcionalna zavisnost je nepromjenjiva na promjene stanja baze podataka tokom vremena.

Primjer. Koncept funkcionalne zavisnosti Hajde da demonstriramo koncept funkcionalne zavisnosti na primeru aerodromskog reda letenja. FLIGHT_RED (Pilot, let, datum_polaska, vrijeme_polaska)

Poznato je da:

• svaki let odgovara određeno vrijeme odlazak;
• moguć je samo jedan let za svakog pilota, datum i vrijeme polaska;
• određeni pilot je raspoređen na određeni dan i let.

posljedično:

• "Departure_time" funkcionalno ovisi o "Let": "Let" -> "Vrijeme_() polaska" ;
• "Let" je funkcionalno ovisan o ("Pilot", "Departure_Date", "Departure_Time"): ("Pilot", "Datum_polaska", "Vrijeme_polaska") -> "Let" ;
• "Pilot" je funkcionalno ovisan o ("Let", "Datum_polaska"): ("Let", "Datum_polaska") -> "Pilot".

Važan zadatak u identifikaciji funkcionalne zavisnosti o atributima relacije, koja je po definiciji skup, treba otkriti koji od atributa djeluje kao argument, a koji - kao vrijednost FD. Najprikladniji kandidati za FZ argumente su mogući ključevi, jer tuple predstavljaju instance entiteta, koji su identificirani po vrijednostima njihovih ključnih atributa. Lako rečeno, funkcionalna ovisnost se odvija na relaciji kada vrijednosti torke na jednom skupu atributa jedinstveno određuju vrijednosti torke na drugom skupu atributa. Ovo radna definicija FD ne sadrži one formalne elemente koji omogućavaju odgovor na pitanje "Kako provjeriti prisustvo FD između atributa relacije?" Neophodan formalizam za to daje upotreba relacione operacije. Da bismo dobili formalnu (striktnu) definiciju prisustva saveznog zakona u vezi, osvrćemo se na relacione operacije.

Definicija 2. Neka postoji relacija R sa šemom r, X i Y - dva podskupa R. FZ se odvija na R ako je skup ima najviše jednu tuple za svaku vrijednost x. Takav FD se također naziva F-ovisnost.

Kao što se vidi iz definicije, formalna verifikacija prisustva FD u odnosu na R sastoji se u izboru (izboru) relacije prema vrijednostima mogući ključ i utvrđivanje prisustva nedvosmislenosti između njegove vrijednosti i vrijednosti drugih atributa.

Algoritam koji provjerava da li relacija R zadovoljava FZ sastoji se od sortiranja relacije po vrijednostima mogući ključ i utvrđivanje činjenice nedvosmislenosti između njegove vrijednosti i vrijednosti drugih atributa. Ovaj algoritam je koristan, ali je pomoćne prirode.

Jasno je da ako je semantika predmetnog područja baze podataka složena, onda je prilično teško provjeriti da li tuple pripadaju FD-u. Teško je utvrditi postojanje funkcionalna zavisnost odgovara prirodi razmatranih podataka. Uz pomoć takve formalne metode moguće je identificirati FD koji nisu stvarni i slučajne su prirode. Dizajner relacijske baze podataka trebao bi biti svjestan ove metode provjere postojanja FD-a, ali kada dizajnira nova baza podataka, njegova upotreba je neefikasna. Može biti korisno u reinženjeringu postojeća baza podaci.

Funkcionalne zavisnosti u stvari, to su izjave o svim odnosima predmetne oblasti. Ove relacije mogu biti vrijednosti šeme r i, zapravo, ne mogu se dobiti formalnim metodama. Jedini način uspostavljanje funkcionalne zavisnosti jer shema r je istraživanje semantike atributa entiteti domene. Biti izjave o entiteti domene, ne mogu se dokazati. Ova okolnost u suštini dovodi do nejedinstvenosti predstavljanja predmetnog područja relacijama relacionih baza podataka.

Ovdje je prikladno postaviti hipotezu zašto postoje dobri i loših projekata baze podataka. Prvo, zbog subjektivnosti pristupa analiza domena analitičari mogu propustiti važne savezne zakone. To može dovesti do činjenice da, radeći na setu, očigledno ne ekvivalentna kola, dizajner će kreirati nezadovoljavajući dizajn baze podataka. Drugo, nejedinstvenost predstavljanja predmetnog područja relacijama dovodi do problema izbora između raznih alternativa. U ovom slučaju, shema baze podataka odabrana iz skupa ekvivalentnih shema je ispravna, ali može organizirati podatke za korisnika na neobičan način. Treće, moguće je definirati („izrezati“) šeme baze podataka na takav način da će kao rezultat operacija s FD-om biti izgubljeni i FD i sami podaci.