Dizajn baze podataka. Definiranje polja sa jedinstvenim vrijednostima u svakom zapisu

1.1. Vrste stolova;
1.2. Vrste imenika;
1.3. Vrste ligamenata;
2. Generalizacija klasifikacije;
2.1. Klasifikacija u tabličnom obliku;
2.2. Klasifikacija u shematskom obliku;
3. Neki komentari na primjenu klasifikacije;
3.1. Primjena klasifikacije pri normalizaciji tabela;
Zaključak.

Obrazloženje za članak i neki ključni koncepti

Vrlo često sam pohađao obuku iz discipline „Baze podataka“. Jednom sam sam učio... Nekako sam čak morao voditi cijeli kurs za prijatelje i poznanike. Tokom obuke primijetio sam da se poteškoće javljaju već u fazi razumijevanja tabela i načina njihovog korištenja. Mnogi jednostavno nisu mogli i ne mogu razviti najjednostavnije baze podataka. Nakon detaljnijeg pogleda na koncept tabela i male klasifikacije, teškoća uočavanja tabela u relacionim bazama podataka gotovo uvek nestaje. Dakle!

Ovaj članak će razmotriti malu klasifikaciju tabela zasnovanu na integritetu i redundantnosti. Šta to znači? To znači da će biti dati primjeri koji opisuju strukturu tablice koju možete učiniti da spriječite (pokušate spriječiti) redundantnost i postići konzistentnost u relacijskim bazama podataka.

Za razumijevanje, dat ćemo kratke definicije integritet podataka i redundantnost:

Integritet podataka- ovo je svojstvo mogućnosti obnavljanja drugih iz jednog podatka, a da se pritom ne izgubi semantičko jedinstvo ovih podataka i odnos između njih (između podataka).

Redundantnost podataka- Ovo je stanje baze podataka u kojoj su dodatni podaci prisutni u tabelama.

Integritet podataka može biti ugrožen kao rezultat operacija modifikacije podataka. Ako su operacije brisanja i ažuriranja zabranjene u bazi podataka, tada se integritet može narušiti samo kao rezultat operacije dodavanja, kao i pogrešno napisane skripte za prikaz podataka.

1.1. Vrste stolova

Idemo malo dublje u malu klasifikaciju tablica prema vrstama njihove strukture. Podijelite stolove na dva opšti pogled... Prvi tip će biti referentne tabele, a drugi će biti tabele veza.

Slika 1. Reference i veze

Informacije u tabelama mogu se podijeliti u dvije vrste. Informacije koje opisuju objekte (subjekte), veze i informacije koje opisuju radnje, procese, događaje itd.

Priručnici sadrže informacije o objektima i subjektima, vezama. Paketi sadrže informacije o akcijama, procesima, događajima itd.

Paketi pohranjuju podatke preuzete iz tabela priručnika. Budući da je neisplativo ponavljati iste podatke prilikom opisivanja objekata (subjekata) i prilikom opisivanja njihove interakcije, podaci o objektima (subjektima) se unose u direktorije, a tabele linkova ne pohranjuju podatke o objektima (subjektima) u čista forma, ali samo veze na njih (strani ključ). Dakle, vezivanja pohranjuju podatke o interakciji objekata (subjekata) i veze sa samim objektima (subjektima) (strani ključ). Ove "veze" su primarni ključevi u referentnim tabelama. Ali više o tome kasnije...

Razlika između priručnika i linka izražena je u tome što referentne tablice mogu biti nezavisne i nezavisne (to jest, kada čitate podatke nekih priručnika, općenito možete razumjeti semantiku), a tabele linkova gotovo nikada.

Imenici se mogu podijeliti u nekoliko tipova. To su statičke, statičko-dinamičke i dinamičke reference. Naravno, teško se može nazvati apsolutno statičnom referentnom knjigom, jer se sve na ovom svijetu može promijeniti. Ili skoro sve.

Statička referenca- imenik, podaci o objektima, subjektima, linkovima u kojima se ili nikada ne mijenjaju nakon početne izmjene, ili su tako rijetko modificirani da se to može zanemariti.

Primjer takvih imenika je lista mjeseci sa imenima i brojevima, lista dana u nedelji, lista godišnjih doba, lista okeana, itd...

Tablica 1. Primjer statičkih direktorija

- direktorij, koji pohranjuje podatke o linkovima, ako su veze referentne prirode. Takva referenca može sadržavati strane ključeve.

Većina dobar primjer postojaće tabela sa medicinskim podacima kao što je težina. Spisak osoba kojima se meri težina ne menja se često. Ali podaci o njihovoj težini mogu se mijenjati svaki dan. Statičko-dinamički priručnici su jedine referentne knjige u kojima možete svjesno ponoviti bilo koju informaciju. Drugi primjer bi bio vodič za plate prema nazivu radnog mjesta (po šifri posla).

Tablica 2. Primjer statičko-dinamičkih direktorija

Dinamički direktoriji- to su tabele, podaci o objektima, subjektima, linkovi u kojima se često mijenjaju i koriste se u drugim tabelama. Od statičkih direktorija se razlikuju samo po učestalosti modifikacije podataka u njima.

Primjer takvih tabela bi bile liste projekata. Naime, podaci o otvaranju ili zatvaranju projekata mogu se nalaziti u samom imeniku projekata, što je u većini slučajeva netačno i narušava integritet. S druge strane, ako pohranite historiju promjena za otvaranje i zatvaranje (suspendiranje) projekata, možete dobiti redundantnost podataka. Integritet podataka i redundantnost dugo će se boriti jedno s drugim, baš kao zimi i ljeto.

Tablica 3. Primjer dinamičkih direktorija

Slika 2. Tipovi direktorija

Tabele veza mogu se podijeliti u dvije vrste.

to priručnik-sveža(odmah ćemo pojasniti da referenca-link nije referenca, već je tako imenovana jer u njoj postoje polja koja čine referencu, ali se ne mogu istaknuti u referenci). Tablica koja pohranjuje strane ključeve, podatke koji nisu referenca i polja koja sadrže podatke koji čine referencu, ali se ne mogu odvojiti u zasebnu referentnu tablicu.

Primjer link-reference knjige će biti tabela platnih transakcija. Ili tabela sa podacima o fudbalskoj utakmici.

Tabela 4. Primjer paketa priručnika

I hrpa(da, samo gomila). Ovo je tablica koja pohranjuje samo strane ključeve i podatke koji se ne mogu klasificirati kao reference, kao što su datum ili vrijednosti logičkih polja.

Primjer paketa će biti automatska tablica evidentiranja terminala za obradu podataka.
Inače, lako je pretpostaviti da se vezivanja gotovo nigdje ne koriste, jer najčešće postoje podaci koji se mogu upisati u bazu podataka, ali nisu sadržani u referentnim knjigama, pa je nemoguće povezati strani ključ s njima.

Tabela 5. Primjer paketa

Neophodno je razjasniti koja su to polja koja čine referentnu knjigu, ali se ne mogu izdvojiti u posebnu tabelu sa referencama. Primjeri takvih polja su polja "komentar", "pritužba", "opis", "prijedlog". Jednom riječju, ako date popularan primjer, onda polje "poruka" u tabeli baze podataka bilo koje društvene mreže ...

Slika 3. Vrste ligamenata

2. Generalizacija klasifikacije

2.1. Klasifikacija u tabelarnom obliku

Pogled na tablicu	Opis	Primjeri	Prednosti (+)	minusi(-)
Statička referenca	Table. Podaci iz njega su uzeti za druge tabele. Iz reference u drugim tabelama može se koristiti samo primarni ključ. Statički direktorij bi trebao sadržavati informacije koje se ili uopće ne mijenjaju, ili se mijenjaju tako rijetko da se mogu zanemariti. Statička referenca se poziva (strani ključ) kada trebate dobiti nazive, oznake, norme, kvantitativne ili kvalitativne pokazatelje. Ostalo.	Imenik (imena i brojevi) mjeseci. Imenik skladišta i radionica preduzeća. Priručnik o pravilima igre.	Ponekad zamjenjuje sistemske funkcije DBMS omogućava fleksibilniji rad sa nekim podacima. U slučaju da se rijetko mijenjaju informacije, upozorava na ozbiljne posljedice.	Korištenje tablice s bilo kojom strukturom može vas usporiti ako tablica zamijeni sistemsku pohranu. Moram pisati dodatne funkcije i obradu za datu tabelu, koji nisu uvek pravilno optimizovani. U nekim slučajevima nije moguće optimizirati.
Statičko-dinamička referenca	Table. Podaci iz njega su uzeti za druge tabele. Iz reference u drugim tabelama, ne možete koristiti strani ključ ove reference, ali možete koristiti primarni ključ.	Plata prema referenci posla. Priručnik (veličina cipele, težina, visina, veličina glave) fizioloških parametara. Imenik (menadžeri, kompanije) koji sadrži kompanije i menadžere kojima te kompanije služe i koje uzimaju u obzir.		Referenca, odvojena od referentne knjige-sveža, ne nestaje nigdje i nema nikakvu relacijsku vezu koja bi joj omogućila da se pretvori u statičku ili dinamičku referencu. To znači da je uvijek suvišno.
Dinamički direktorij	Table. Podaci iz njega se često uzimaju za druge tabele. Iz reference u drugim tabelama može se koristiti samo primarni ključ. Dinamička referenca treba da sadrži informacije koje se često mijenjaju.	Referentna knjiga klijenata. Imenik dobavljača. Imenik izvođača radova. Referentna knjiga menadžera kompanije. Imenik radnika. Priručnik studenata.	Omogućava vam pohranjivanje dinamičkih podataka, istovremeno omogućavajući nedvosmisleno referenciranje na njih.	Najčešće se akumulativni tip ne dijeli, što stvara određenu redundantnost.
Link reference	Table. Podaci iz njega ne mogu biti sadržani u drugim tabelama, ali se podaci u drugim tabelama mogu kreirati na osnovu njih.	Platne transakcije. Prodaja. Međufaktorska kretanja. Raspored prevoza.	Omogućava izvođenje fleksibilne normalizacije prema šemi "Referentna veza" = "Povezivanje" + "Statičko-dinamička referenca".	Referentna veza nakon normalizacije pretvara se u vezu i minimizira redundantnost podataka bez utjecaja na integritet, međutim, nije djeljiva i ne može se optimizirati prilikom arhiviranja u trenutnoj tablici.
Bunch	Table. Podaci iz njega ne mogu biti sadržani u drugim tabelama, ali se podaci u drugim tabelama mogu kreirati na osnovu njih. Tablica ne može sadržavati tuple čije su vrijednosti atributa nedjeljive i nisu jedinstvene.	Automatska evidencija grešaka u programu. Dnevnik zahtjeva servera. Tragiranje rezultata. Izvještaji o istovaru i utovaru komponenti. Automatski sigurnosni izvještaji.	Grupiranje minimizira redundantnost podataka bez utjecaja na integritet.	Akumulacija je nedjeljiva tablica. Teško je optimizirati.

Tabela 6. Klasifikacija

2.2. Klasifikacija u šematskom obliku

Slika 4. Šema klasifikacije tabela u relacionim bazama podataka na osnovu integriteta podataka i redundantnosti

3. Neki komentari o primjeni klasifikacije

3.1. Primjena klasifikacije pri normalizaciji tabela

Proces normalizacije, ako ne uzmete u obzir neke faze (Ali uzmite u obzir rezultate ovih faza!) - ovo je uobičajeno "cijepanje" tablica na manje tablice sa stvaranjem relacijskog odnosa između njih direktno ili putem međusobne tabele (odnos više-prema-više). Relacijski odnos ne mora uvijek značiti relacijski odnos!

Pretvaranje dinamičke ili statičke reference u statičko-dinamičku referencu i povezivanja u skup, kao što je statičko-dinamička referenca u premoštenu referencu, nije ništa drugo do dijeljenje tablica. Odnosno, transformacija jedne vrste tabela u drugu kroz klasifikaciju prikazanu iznad kako bi se izbjegla redundantnost podataka - tako se može definirati normalizacija (jedna od opcija definicije).

Na primjer. Neka postoji baza podataka u kojoj je jedina operacija modifikacije podataka dodavanje. U ovom slučaju, postaje neučinkovit svaki put kada promijenite bilo koji pojedinačni atribut entiteta, "kopirajte" ostatak vrijednosti atributa u drugu tuple. U ovom slučaju se koristi NULL ili kreiranje statičko-dinamičke reference, gdje se opisuje više atributa iste semantike ili jedan atribut, a samo se strani ključ s primarnim ključem sekvence duplicira. Ista metoda se može koristiti u tradicionalnoj šemi modifikacije podataka uz ažuriranje i brisanje podataka.

Zaključak

Ovu klasifikaciju sam kreirao na osnovu zapažanja u dizajnu baza podataka, kao i na osnovu teorije koja se čita o dizajnu u relacionom DBMS-u. Mojim prijateljima i poznanicima, koji proučavaju disciplinu "baze podataka" i bave se dizajnom baza podataka, a za mene je ova klasifikacija ozbiljno pojednostavila "život" i omogućila u mnogim situacijama da unapred odaberem najprikladniju i, kako se kasnije ispostavilo , ispravan pogled tabele za pohranjivanje određenih podataka u njega.

Klasifikacija se može proširiti dijeljenjem postojeće vrste u njemu u podvrste (možda čak i dodavanjem novih vrsta). Takođe, ova klasifikacija je pokazala da je u nekim situacijama bolje ne koristiti jednu ili drugu vrstu tabela. Bolje je rjeđe koristiti neke tipove tabela iz ove klasifikacije (dinamičke referentne knjige). I pokušajte zamijeniti neke drugima (priručnici-sveženja sa paketima).

Nadam se da će ova klasifikacija pomoći ikome drugom prilikom savladavanja discipline "Baze podataka" i prilikom dizajniranja baza podataka u relacionom DBMS-u.

Prije kreiranja sa pomoć od Microsofta Pristupni stolovi, obrasce i druge objekte koji čine bazu podataka, potrebno je posvetiti vrijeme fazama dizajna baze podataka.

Glavne faze dizajna baze podataka su:

· Određivanje svrhe kreiranja baze podataka;

· Definisanje tabela koje baza podataka treba da sadrži;

· Definisanje obaveznih polja u tabeli;

Definicija polja sa jedinstvene vrijednosti u svakom unosu;

· Definisanje odnosa između tabela.

Određivanje svrhe kreiranja baze podataka

Prvi korak u dizajniranju baze podataka je definiranje svrhe baze podataka, kako će se koristiti i koje informacije treba sadržavati. Znajući to, možete odrediti koje će informacije biti pohranjene u tablicama i u poljima tablice. Baza podataka mora ispunjavati zahtjeve onih koji će s njom direktno raditi. Da biste to uradili, potrebno je da odredite teme koje baza podataka treba da pokriva, izveštaje koje treba da izdaje, analizirate dokumente koji trenutno koristi se za pisanje podataka, poređenje baza koja se stvara podataka sa dobro dizajniranom bazom podataka kao što je ona. Svrha ove baze podataka je da se dobije što više informacija o klijentu, odnosno prezime, ime, patronime, adresa, broj telefona, kao i usluga koja se mora obaviti za ovog klijenta.

Određivanje tabela koje baza podataka treba da sadrži

Određivanje tabela potrebnih u bazi podataka može biti najteži dio procesa dizajna baze podataka, budući da su rezultati koje baza podataka mora proizvesti izvještaji, obrasci i tako dalje. - ne daju uvijek potpunu sliku strukture tabela po kojima su kreirane. Ne morate da koristite Microsoft Access da biste dizajnirali svoje tabele. Najbolje je prvo dizajnirati strukturu na papiru. Prilikom izrade tabela preporučuje se da se vodite sledećim osnovnim principima: 1) Informacije ne treba da se dupliraju u tabeli ili između tabela. S tim u vezi, tabele u relaciona baza podaci se razlikuju od tabela u aplikacijama koje rade sa tabelama u tekstualni format kao što su urednici tabele... Podaci pohranjeni u samo jednoj tabeli ažuriraju se samo u toj tabeli. Ovo je efikasnije i, osim toga, eliminiše mogućnost dupliranja zapisa koji sadrže različite informacije. Na primjer, dovoljno je jednom snimiti adresu i broj telefona svakog klijenta, u jednu tabelu 2) Svaka tabela treba da sadrži informacije samo o jednoj temi. Kada svaka tabela sadrži informacije samo o jednoj temi, možete raditi s informacijama o svakoj temi neovisno o drugim temama. Na primjer, adresa klijenta se čuva odvojeno od narudžbi tog kupca, što omogućava brisanje jednog zahtjeva uz zadržavanje informacija o klijentu. Ova baza podataka sadrži sedam tabela: stambena organizacija, stambena zgrada, stan, stanari, podaci o stanarima, usluga, podaci o izvršenoj usluzi.

Određivanje obaveznih polja u tabeli

Svaka tabela sadrži informacije o određenoj temi, a svako polje u tabeli sadrži određenu činjenicu o temi tabele. Na primjer, tabela "Stanovnici" sadrži polja prezime, ime, patronim, a specifična činjenica je posebna osoba, na primjer, Ivanov Ivan Ivanovič.

Prilikom sastavljanja polja za svaku tabelu treba uzeti u obzir sljedeće osnovne principe:

· Svako polje mora biti povezano sa temom tabele;

Tabela mora sadržavati sve potrebne informacije;

· Podatke treba raščlaniti na najmanje logičke jedinice.

Definiranje polja sa jedinstvenim vrijednostima u svakom zapisu

Za povezivanje informacija pohranjenih u Microsoft Accessu različiti stolovi- na primjer, za povezivanje službenika za pasoš sa svim njenim klijentima - svaka tabela baze podataka mora sadržavati polja ili skup polja koja jedinstveno identificiraju svaki zapis. Takvo polje ili skup polja naziva se primarni ključ. Na primjer, tabela “Stambena organizacija” je povezana sa tabelom “Stambena zgrada” relacijom jedan-prema-više; stoga, tabela “Stambena zgrada” ima sekundarni ključ “Broj organizacije”, a primarni ključ “Kuća broj".

Definiranje odnosa između tabela

Nakon što razbijete informacije u tabele i identifikujete ključna polja, morate odabrati način na koji će Microsoft Access ponovo spojiti povezane informacije. Da biste to učinili, trebali biste definirati odnose između osnovnih tabela Microsoft podaci Pristup. Postoje veze: jedan prema mnogo, mnogo prema mnogo (rijetko se koristi).

Ovo poglavlje govori o tablici podataka koja stvara niz kao rezultat funkcije sto(ova funkcija se ne može ručno unijeti u ćelije). Tabela podataka je brz i lak način za izvođenje analize šta ako za složene međusobno povezane proračune zasnovane na formulama. Ova funkcija vam omogućava da promijenite jednu ili dvije formule ulaza i prikažete koji su rezultati. Poglavlja i već su dali primjere tablica podataka koje su korištene u sprezi s funkcijama baze podataka.

Preuzmite bilješku u formatu ili primjere u formatu

Analiza „šta ako“ na osnovu jedne tabele varijabli

Na sl. 21.1 u ćeliji B6 koristi se funkcija PMT, koja indirektno ovisi o vrijednosti ćelije B2. Ako promijenite godišnju stopu, PMT će ažurirati vrijednost u ćeliji B6. Cilj je da se istovremeno vidi kako će se mijenjati mjesečna uplata po pet različitih godišnjih stopa. Iako se to može učiniti pisanjem formule, funkcija Table može biti korisna iz dva razloga:

• Tabele podataka su brže od rješenja zasnovanih na drugim formulama.
• Tablice podataka su lakše za korištenje, a vrijeme za kreiranje formule je smanjeno.

Da kreirate tabelu podataka:

1. Kreirajte naslove A9: B9. U ćeliju B10 unesite formulu = B6. U ćelije A11: A15 unesite vrijednosti godišnje stope za analizu. Istaknite raspon A10: B15.
2. Prođite kroz meni PODACI –> Šta ako analiza –> Tabela podataka da otvorite dijalog Tabela podataka, ili pritiskom i držanjem Alt taster, pritisnite Y, Y, T uzastopno (nakon pritiskanja Alt, savjeti će se pojaviti u meniju).
3. Budući da analizirate uticaj godišnje stope, molimo vas da u polje uključite vezu do nje Zamijenite vrijednost red po red(sl.21.2). Ti pričaš Tabela podataka, zamijenite vrijednost iz ćelije B2 u procesu izračunavanja PMT-a i umjesto toga zamijenite vrijednosti iz raspona A11: A15 u formuli.
4. Kliknite OK.

Rice. 21.2. Prozor dijaloga Tabela podataka

Ako odaberete raspon B11: B15 i pogledate traku formule, vidjet ćete tablicu formule niza s referencom na ćeliju B2. Funkcija Table se ne može uneti sa tastature; automatski se generiše kada se koristi dijaloški okvir Tabela podataka.

Rice. 21.3. Funkcijska tablica se može unijeti samo pomoću dijaloškog okvira Tabela podataka

Na sl. 21.4 ćelije u rasponu E3: I3 sadrže različite formule koje se direktno ili indirektno odnose na broj prodatih komada (u ćeliji B3). Koristeći Tabela podataka možete izvršiti analizu šta-ako na pet formula. Štaviše, svi su zasnovani na istoj varijabli koja se nalazi u rasponu D4: D12.

Rice. 21.4. Jedna varijabla Tabele podataka može raditi na nekoliko formula; za uvećanje slike kliknite na nju desni klik miša i odaberite Otvorite sliku u novoj kartici

Dvije varijable u tabeli podataka

U sljedećem primjeru, zadatak je pronaći minimalnu vrijednost na osnovu dva kriterija. Za to se koristi Tabela podataka na osnovu dvije varijable (slika 21.5). Stavite formulu na lijevo gornji ugao Tabele podataka(u našem primjeru - u ćeliji F8) i unesite customize u dijaloški okvir Tabela podataka kao što je prikazano na sl. 21.5.

Rice. 21.5. Tabela podataka sa dvije varijable

Već ste vidjeli drugi primjer (slika 21.6). Koristio je formulu niza. Na primjer, u ćeliji F9: = INDEX ($ C $ 2: $ C $ 15; PRETRAGA ($ E9 & F $ 8; $ A $ 2: $ A $ 15 & $ B $ 2: $ B $ 15; 0 )). Na osnovu rješenja Tabele podataka lakše i brže.

Rice. 21.6. Upotreba Tabele podataka, kao alternativa VLOOKUP-u u dva parametra

Još jedna napomena Tabele podataka: postoji opcija koja vam omogućava da onemogućite automatsko ažuriranje Tabele podataka, dok će ostale formule biti automatski preračunate. Ako se vaš fajl "uspori", prođite kroz meni FILE –> Opcije, idite na karticu Formule i izaberite opciju automatski, osim za tabele podataka(sl.21.7). Kad god želite da ažurirate proračune u Tabela podataka, pritisnite F9.

Rice. 21.7. Onemogućite automatski proračun Tabele podataka

Ovaj članak pruža smjernice za dizajn baze podataka. Korisnik će naučiti kako odlučiti koje su informacije potrebne i kako distribuirati podatke po tabelama i kolonama, a također će istražiti odnose između tabela. Prije nego što kreirate bazu podataka ili počnete raditi s ozbiljnim bazama podataka, trebali biste pročitati ovaj članak.

U ovom članku

Terminologija baze podataka

V microsoft office Access 2007 organizira podatke u stolovi- skupovi redova i kolona, ​​slični papirima računovođe ili Microsoft knjizi Office Excel 2007. Jednostavna baza podaci se mogu sastojati od samo jedne tabele. Većina baza podataka uključuje više tabela. Na primjer, jedna tablica može pohraniti informacije o proizvodu, druga može pohraniti informacije o narudžbi, a treća može pohraniti informacije o kupcima.

Svaka linija je također imenovana snimanje, a svaki stupac ili tip elementa se također poziva polje... Zapisi vam omogućavaju da kombinujete podatke. Polja su zasebne stavke podataka - tipovi stavki za svaki red. Na primjer, u tabeli Proizvodi svaki red ili zapis sadrži informacije o jednom proizvodu. Svaka kolona ili polje pohranjuje specifične informacije o proizvodu, kao što su naziv ili cijena.

Ispravna struktura baze podataka

Proces kreiranja baze podataka zasniva se na određenim principima. Prvi je uklanjanje duplikata (ili suvišnih) podataka jer zauzimaju prostor i povećavaju vjerovatnoću grešaka i kvarova. Drugi princip se tiče važnu ulogu tačne i potpune podatke. Ako baza podataka sadrži netačne podatke, svi izvještaji koji kombinuju podatke će također sadržavati netačne informacije. Ovo može dovesti do prihvatanja pogrešne odluke na osnovu izveštaja.

Ispravna struktura baza podataka podrazumijeva:

• distribucija podataka po tematskim tabelama kako bi se smanjila količina dupliranih podataka;
• Dodajte podatke u Access koji su neophodni za kombinovanje informacija sadržanih u tabelama;
• sposobnost održavanja i praćenja tačnosti i integriteta podataka;
• Usklađenost sa zahtjevima obrade podataka i izvještavanja.

Razvojni proces

Proces razvoja baze podataka uključuje sljedeće korake.

• Određivanje svrhe kreiranja baze podataka

To vam omogućava da se pripremite za sljedeće korake.

• Pronalaženje i organiziranje podataka koji su vam potrebni

Treba prikupiti sve podatke koji se trebaju pohraniti u bazi podataka, kao što su nazivi proizvoda i brojevi narudžbi.

• Distribucija podataka po tabelama

Organizirajte stavke podataka u grupe ili teme, kao što su "Proizvodi" ili "Narudžbe". Za svaku temu će biti kreirana tabela.

• Pretvaranje stavki u kolone

Odredite koje podatke želite da pohranite u svakoj tabeli. Svaka stavka podataka bit će unesena u posebno polje i postati kolona u tabeli. Na primjer, tabela Zaposleni može sadržavati polja kao što su prezime i datum zapošljavanja.

• Postavljanje primarnih ključeva

Odaberite primarne ključeve tablica. Primarni ključ - Kolona koja jedinstveno identificira svaki zapis, kao što je kod proizvoda ili narudžbe.

• Kreiranje odnosa između tabela

Analizirajte sve tabele i odredite kako se podaci u jednoj tabeli odnose na podatke u drugim tabelama. Dodajte polja u tabele ili kreirajte nove tabele da kreirate potrebne odnose.

• Poboljšanje strukture

Provjerite ima li u strukturi vaše baze podataka grešaka. Kreirajte tabele i dodajte neke uzorke zapisa podataka. Analizirajte svoje rezultate. Izmijenite strukturu po potrebi.

• Primjena pravila normalizacije

Primijenite pravila normalizacije da provjerite da li su tablice pravilno strukturirane. Izmijenite tabele po potrebi.

Određivanje svrhe kreiranja baze podataka

Preporučljivo je na papiru zapisati svrhu kreiranja baze podataka: zadatke, metode korištenja i popis korisnika. Za malu bazu podataka za rad od kuće možete definirati sljedeće jednostavan cilj: "Baza podataka kupaca sadrži informacije o klijentima i koristi se za slanje poruka Email i izvještaji“. Prilikom kreiranja složenije baze podataka za veliki broj korisnika, na primjer u organizaciji, opis cilja može se sastojati od nekoliko pasusa; morate odrediti vrijeme i metode korištenja baze podataka od strane raznih korisnika... Glavni zadatak je komponovati Detaljan opis svrhu kreiranja baze podataka kako bi se na nju mogli referirati tokom procesa dizajna. Prisustvo opisa omogućava praćenje postavljenih ciljeva u procesu donošenja odluka.

Pronalaženje i organiziranje podataka koji su vam potrebni

Proces pronalaženja i organiziranja informacija koje su vam potrebne treba započeti snimanjem dostupnih informacija. Na primjer, možete snimiti narudžbe iz glavne knjige ili sačuvati podatke o klijentima iz ormarića za dosije. Skupiti Potrebni dokumenti i napravite listu tipova podataka (na primjer, listu polja u obrascu). Ako ne koristite kancelarijski materijal, zamislite da želite da kreirate kancelarijski materijal za snimanje informacija o klijentima. Koje podatke želite snimiti? Koja polja trebate popuniti? Definiraj potrebnih elemenata i navesti ih. Pretpostavimo da su podaci o klijentima pohranjeni u ormaru za dosije. Analiza kartica otkriva da sadrže informacije kao što su ime korisnika, adresa, grad, država, poštanski broj i broj telefona. Svaki od ovih elemenata može postati stupac u tabeli.

Kada pripremate listu, ne morate težiti da joj prvi put date kompletan izgled. Sve treba zabilježiti moguće opcije... Ako je baza podataka namijenjena za više korisnika, pitajte ih za njihove prijedloge. Spisak se može naknadno ispraviti.

Zatim definirate tipove izvještaja ili distribucija koje želite pokrenuti iz baze podataka. Na primjer, možda želite pokrenuti izvještaj o prodaji proizvoda po regijama ili sažetak izvještaja o inventaru proizvoda. Možda ćete želeti da kreirate e-poruke adresirane na klijente koji sadrže prodaju ili posebne ponude... Razmislite o strukturi izvještaja, definirajte je izgled... Koje informacije trebate uključiti u izvještaj? Navedite informacije koje su vam potrebne. Slijedite iste korake za e-poštu i druge izvještaje.

Definiranjem strukture izvještaja i mailinga možete identificirati stavke koje želite uključiti u bazu podataka. Pretpostavimo da želite da klijentima omogućite pretplatu ili odjavu na redovni bilten i da budete u mogućnosti da odštampate listu pretplatnika. Da biste zabilježili ove informacije u tabeli kupaca, dodajte kolonu za slanje e-poruka. U ovom polju možete odabrati Da ili Ne za svakog kupca.

Za slanje e-mail poruka klijentima mora se snimiti još jedan podatak. Ako kupac pristane da prima poruke e-pošte, morat će zabilježiti svoju adresu e-pošte. Stoga ćete morati pohraniti adresu e-pošte za svakog kupca.

Pogodno je napraviti prototip svakog izvještaja ili liste klijenata za štampanje i odrediti koje stavke podataka su potrebne za njihovo generiranje. Na primjer, analiza pisma otkriva nekoliko elemenata. Ako želite uključiti pozdrav u slovo - na primjer, niz "d". ili "Ms." - potrebno je da kreirate odgovarajuću stavku. Osim toga, pismo obično počinje standardnom frazom "Dragi gospodine Jegorov", a ne "Dragi gospodine Vladimire Jegorov". Stoga se prezime mora čuvati odvojeno od imena.

Važno je zapamtiti da se podaci moraju podijeliti na minimalni elementi... Ime treba podijeliti na dva dijela: ime i prezime, kako bi prezime bilo dostupno za korištenje. Na primjer, da biste sortirali izvještaj po prezimenu, morate ga spremiti u posebna polja. Općenito, ako želite sortirati, pretraživati, izračunavati ili izvještavati o pojedinačnim stavkama podataka, ove stavke bi trebale biti pohranjene u odvojenim poljima.

Navedite pitanja na koja želite da dobijete odgovore koristeći bazu podataka. Na primjer, koliki je bio obim prodaje za pojedinačni proizvod u prošlom mjesecu? Gdje su klijenti koji najviše obećavaju? Ko isporučuje najprodavaniji proizvod? Lista moguća pitanja omogućava vam da definirate dodatne stavke podataka za zapis.

Nakon prikupljanja podataka, možete preći na sljedeći korak.

Distribucija podataka po tabelama

Za distribuciju podataka po tabelama, istaknite glavne grupe ili teme. Na primjer, nakon pretraživanja i organiziranja podataka za bazu podataka o prodaji proizvoda, može se sastaviti sljedeća lista:

Glavne grupe su proizvodi, dobavljači, kupci i narudžbe. Stoga ima smisla kreirati četiri tabele, po jednu za informacije o proizvodu, dobavljaču, kupcu i narudžbi. Iako ova lista nije potpuna, možete početi s ovim osnovnim tabelama. Lista se može dopunjavati dok se ne dobije željenu strukturu Baza podataka.

Kada prvi put pogledate preliminarnu listu stavki, možda ćete pomisliti da ima smisla staviti sve stavke u jednu tabelu umjesto kreiranja četiri tabele, kao što je prikazano u prethodnom primjeru. Ovaj odjeljak objašnjava zašto je ovaj pristup neučinkovit. Pogledajte tabelu na ilustraciji.

V u ovom slučaju svaki red sadrži podatke o proizvodima i dobavljačima. Pošto jedan dobavljač snabdeva razni proizvodi, njegovo ime i adresa se moraju ponovo unijeti. Istovremeno, prostor na disku se koristi neefikasno. Pametnije rješenje je pohraniti informacije o dobavljačima u posebnu tablicu dobavljača i povezati tu tablicu s tablicom proizvoda.

Drugi problem sa ovakvom strukturom baze podataka nastaje kada je potrebno promijeniti podatke o dobavljaču. Pretpostavimo da želite promijeniti adresu dobavljača. Pošto za dobavljača postoji mnogo redova, korisnik može neke od njih preskočiti. Ovaj problem također možete riješiti tako što ćete pohraniti adresu dobavljača na jednu lokaciju.

Prilikom dizajniranja baze podataka, trebali biste nastojati da svaku stavku podataka sačuvate jednom. Ako su podaci duplirani (na primjer, adresa zasebnog dobavljača), stavite ih u posebnu tabelu.

Na kraju, pretpostavimo da Coho Winery isporučuje samo jedan proizvod i želite da ga deinstalirate, a da pritom zadržite ime prodavca i informacije o adresi. Kako mogu izbrisati zapis o proizvodu, a da sačuvam podatke o dobavljaču? To je nemoguće. Budući da svaki red sadrži podatke o proizvodu kao i podatke o dobavljačima, nije moguće brisati te podatke odvojeno jedan od drugog. Da biste razdvojili ove podatke, trebate kreirati dvije tabele, jednu za informacije o proizvodu i jednu za informacije o dobavljačima. U ovom slučaju, brisanjem zapisa o proizvodu neće se izbrisati podaci dobavljača.

Nakon što odaberete temu za tabelu, morate biti sigurni da kolone u toj tabeli sadrže podatke samo za tu temu. Na primjer, tabela proizvoda treba da sadrži samo informacije o proizvodima. Budući da se adresa dobavljača odnosi na podatke o dobavljaču, a ne na podatke o proizvodu, ona mora biti pohranjena u tabeli dobavljača.

Pretvaranje stavki u kolone

Da biste odredili kolone u tabeli, morate odlučiti koje informacije želite da pratite za tabelu. Na primjer, možete uključiti kolone Ime, Adresa, Grad / Država / Poštanski broj, Pošalji e-poštu, Predmet i Adresa e-pošte u tablicu kupaca. Svi redovi sadrže isti skup kolona, ​​tako da možete pohraniti odgovarajuće informacije za svaki red. Na primjer, kolona "Adresa" sadrži adrese klijenata. Svaki zapis sadrži informacije samo o jednom kupcu, a polje za adresu sadrži adresu tog kupca.

Početni skup kolona za svaku tabelu može se dopuniti novim kolonama. Na primjer, zgodno je pohraniti ime i prezime kupca u odvojene stupce kako bi se olakšalo sortiranje, pretraživanje i kreiranje indeksa. Adresa također ima nekoliko komponenti: adresu, grad, državu, poštanski broj i državu, koje je najbolje čuvati u posebnim kolonama. Na primjer, ako želite pretraživati, filtrirati ili sortirati po području, trebate pohraniti informacije o području u posebnu kolonu.

Također bi trebalo odrediti koje vrste podataka će biti pohranjene u bazi podataka: nacionalne ili međunarodne. Na primjer, ako planirate da skladištite međunarodne adrese u bazi podataka, bolje je koristiti kolonu Region umjesto Država, jer se ova kolona može koristiti za određivanje regiona u vašoj zemlji i regiona u drugim zemljama. Na isti način biće moguće pohraniti u polje Poštanski broj poštanski brojevi različite zemlje.

Donja lista pruža nekoliko savjeta za kreiranje kolona.

• Nemojte uključivati ​​izračunate podatke u svoju tabelu

Rezultate proračuna ne treba pohranjivati ​​u tabele. Umjesto toga, možete izvršiti proračune u Accessu kad god želite da dobijete rezultat. Na primjer, pretpostavimo da izvještaj o naručivanju proizvoda prikazuje međuzbirove za naručene proizvode u svakoj kategoriji. Međutim, tabela ne sadrži kolonu za međuzbirove. Umjesto toga, tabela uključuje kolonu za naručene proizvode u kojoj je pohranjena količina svakog proizvoda. Sa ovim Pristup podacima izračunava međuzbirove svaki put kada se izvještaj odštampa. Sami međuzbrojevi se ne pohranjuju u tabeli.

• Rastavite informacije na minimalne logičke komponente

Možda bi se činilo boljom idejom kreirati uniformna polja za pohranjivanje punih naziva ili naziva proizvoda zajedno s njihovim opisima. Međutim, kombinovanje različitih podataka u jednom polju otežava njihovo dalje pronalaženje. Informacije treba raščlaniti na logičke komponente. Na primjer, možete kreirati zasebna polja za ime i prezime, ili za naslov, kategoriju i opis proizvoda.

Nakon kreiranja kolona u tabelama, možete odabrati primarni ključ za svaku tabelu.

Postavljanje primarnih ključeva

Svaka tabela mora sadržavati kolonu ili skup kolona za jedinstvenu identifikaciju svakog reda u tabeli. U pravilu, za ove svrhe, jedinstven identifikacioni broj npr. šifra zaposlenika ili serijski broj... U bazi podataka takve informacije se nazivaju primarni ključ stolovi. U Accessu se primarni ključevi koriste za brzo povezivanje podataka iz više tabela i njihovo prikazivanje korisniku.

Ako tabela ima jedinstveni identifikator, kao što je broj proizvoda, koji jedinstveno identifikuje svaki proizvod u katalogu, može se koristiti kao primarni ključ tabele, ali vrednosti za tu kolonu moraju biti različite za sve zapise. Primarni ključ ne smije sadržavati duple vrijednosti. Na primjer, ne biste trebali koristiti imena ljudi kao primarni ključ jer nisu jedinstvena. U istoj tabeli mogu postojati dva zapisa sa istim imenom.

Primarni ključ uvijek mora biti važan. Ako kolona dozvoljava nedodijeljenu vrijednost ili vrijednost koja nedostaje, ne bi se trebala koristiti kao komponenta primarnog ključa.

Vrijednost primarnog ključa se ne smije mijenjati. U bazi podataka sa više tabela, primarni ključ jedne tabele može se koristiti kao referenca u drugim tabelama. Ako se primarni ključ promijeni, promjena se mora primijeniti na sve reference na taj ključ. Korištenjem primarnog ključa s konstantnom vrijednošću, manja je šansa da se ne sinkronizira s drugim tabelama.

Često se kao primarni ključ koristi proizvoljan jedinstveni ključ. numerička vrijednost... Na primjer, možete dodijeliti jedinstveni broj narudžbe svakoj narudžbi kako biste jedinstveno identificirali narudžbu. Ovaj broj se ne može promijeniti.

Ako ne možete da izaberete kolonu ili skup kolona koji će se koristiti kao primarni ključ, možete koristiti kolonu sa tipom podataka Brojač. Kada koristite takvu kolonu, Access automatski dodeljuje vrednosti. Ovaj kod ne sadrži informacije; nema opis niza koji predstavlja. Vapid kodovi su idealni za korištenje kao primarni ključ jer se ne mijenjaju. Primarni ključ koji sadrži stvarne informacije niza, kao što je telefonski broj ili ime korisnika, podložniji je promjenama jer se stvarne informacije mogu promijeniti.

Kolona Counter je pogodan primarni ključ. Šifre proizvoda se nikada ne podudaraju.

U nekim slučajevima, potrebno je koristiti dva ili više polja kao primarni ključ tabele. Na primjer, za tablicu detalja narudžbe koja pohranjuje stavke za narudžbe, možete koristiti dvije kolone u primarnom ključu: kod narudžbe i kod proizvoda. Primarni ključ sa više kolona naziva se kompozitni primarni ključ.

U bazi podataka prodaje možete kreirati stupac brojača za primarni ključ svih tabela: ItemID za tablicu artikala, OrderID za tablicu narudžbi, CustomerID za tablicu kupaca i VendorID za tablicu dobavljača.

Kreiranje odnosa između tabela

Nakon distribucije podataka po tabelama, morate ih moći kombinirati. Na primjer, obrazac ispod uključuje informacije iz više tabela.

Ovaj obrazac sadrži podatke iz tabele kupaca,

Zaposleni,

narudžbe,

Proizvodi

I informacije o narudžbi.

Access je sistem upravljanja relacionim bazama podataka. U relacionoj bazi podataka, informacije se distribuiraju u odvojenim, tematski organizovanim tabelama. Veze između tabela se koriste za kombinovanje podataka.

Stvorite odnos jedan-prema-više

Razmislite sljedeći primjer: Baza narudžbi proizvoda sadrži tabele dobavljača i proizvoda. Dobavljač može isporučiti bilo koji broj proizvoda. Stoga, za svakog dobavljača iz tabele dobavljača, tabela proizvoda može sadržavati veliki broj proizvodi. Stoga je odnos između tablice dobavljača i tablice proizvoda odnos jedan prema više.

Za kreiranje odnosa jedan-prema-više u strukturi baze podataka, dodajte jednostrani primarni ključ u višestrana tablicu kao dodatni stupac. V ovaj primjer trebate dodati stupac koda dobavljača iz tablice dobavljača u tablicu proizvoda. Access tada može koristiti šifru dobavljača iz tabele proizvoda da pronađe dobavljača za svaki proizvod.

Kolona koda dobavljača u tabeli proizvoda naziva se strani ključ. Strani ključ je primarni ključ druge tabele. Kolona ID dobavljača u tabeli proizvoda je strani ključ jer je i primarni ključ tabele dobavljača.

Osnova za povezivanje tabela je kombinovanje primarnog i stranog ključa u parove. Ako ne možete definirati tablice sa zajedničkim stupcem, kreiranje odnosa jedan-prema-više osigurava da je zajednički stupac potreban za dvije tablice.

Stvorite odnos mnogo-prema-više

Razmotrimo odnos između tablica proizvoda i narudžbi.

Jedna narudžba može uključivati ​​više proizvoda. Na drugoj strani, poseban proizvod može biti sadržano u nekoliko naredbi. Stoga, za svaki unos u tablici narudžbi, može postojati više unosa u tablici proizvoda i obrnuto. Ova vrsta odnosa naziva se odnos više-prema-više. Imajte na umu da je važno sagledati obje strane kako biste otkrili odnos mnogo-prema-više između tabela.

Teme dvije tabele — narudžbe i proizvodi — povezane su relacijom „mnogo-prema mnogima“. Ovo je problem. Zamislite što se događa ako kreirate odnos između dvije tablice dodavanjem polja koda proizvoda u tablicu narudžbi. Da bi narudžba sadržavala više proizvoda, svaka narudžba u tabeli mora sadržavati više unosa. U tom slučaju, informacije o narudžbi moraju se ponoviti u svakoj liniji naloga, što može dovesti do neefikasne strukture tabele i netočnih podataka. Ista poteškoća nastaje i kod kreiranja polja sa šifrom narudžbe u tabeli proizvoda - postoji nekoliko zapisa za svaki proizvod u tabeli. Kako riješiti ovaj problem?

Rješenje je da se kreira treća, tabela za premošćivanje, u kojoj je odnos više-prema-više podijeljen u dvije relacije jedan-prema-više. Primarni ključevi dvije tabele se ubacuju u treću tabelu. Kao rezultat, sve instance relacije su pohranjene u trećoj tabeli.

Svaki unos u tabeli detalja narudžbine predstavlja poseban element narudžbenice. Primarni ključ tabele sastoji se od dva polja - stranih ključeva tabele naloga i proizvoda. Nije moguće koristiti samo polje sa šifrom naloga za primarni ključ ove tabele, jer jedan nalog može sadržati više elemenata reda. Šifra narudžbe se ponavlja za svaku stavku, tako da ovo polje ne sadrži jedinstvene vrijednosti. Također nije moguće koristiti samo polje sa šifrom proizvoda, jer jedan proizvod može biti uključen u više narudžbi. Međutim, korištenje dva polja vam omogućava da dobijete jedinstvenu vrijednost za svaki zapis.

U bazi podataka prodaje proizvoda tabele narudžbi i proizvoda nemaju direktnu vezu. Oni su povezani indirektno preko tabele detalja narudžbine. Odnos više-prema-više između narudžbi i proizvoda predstavljen je u bazi podataka sa dva odnosa jedan-prema mnogo:

• Tabele sa informacijama o narudžbi i narudžbi su povezane u odnosu jedan prema više. Svaka narudžba sadrži više stavki, ali svaka stavka je pridružena samo jednoj narudžbi.
• Tabele sa informacijama o proizvodima i narudžbama povezane su u odnosu jedan prema više. Svaki proizvod može biti povezan s više stavki u redovima, ali svaka stavka je povezana samo s jednim proizvodom.

U tabeli detalja narudžbe možete definirati proizvode za jednu narudžbu. Također možete definirati narudžbe za određeni proizvod.

Nakon kreiranja tabele sa detaljima narudžbine, lista tabela i polja može izgledati ovako:

Stvaranje odnosa jedan na jedan

Sljedeći tip odnosa je odnos jedan na jedan. Pretpostavimo da želite da zadržite Dodatne informacije o proizvodu koji se rijetko koristi ili na koji je primjenjiv mali broj proizvodi. Budući da se ove informacije rijetko koriste i njihovo pohranjivanje u tablicu proizvoda zahtijeva kreiranje dodatnog praznog polja za sve proizvode na koje se ne odnosi, bolje je ove podatke staviti u posebnu tabelu. Kao i kod tabele proizvoda, ID proizvoda se koristi kao primarni ključ. Podtabela i tabela proizvoda imaju odnos jedan-na-jedan. Postoji jedan zapis za svaki unos tabele proizvoda u dodatnoj tabeli. Prilikom definiranja ove vrste odnosa, obje tabele moraju sadržavati jedno polje.

Ako trebate stvoriti odnos jedan-na-jedan u vašoj bazi podataka, razmislite o spajanju podataka u jednu tablicu. Ako je ova opcija neprihvatljiva, na primjer zbog praznih polja, koristite donju listu da definirate odnos u strukturi baze podataka.

• Ako su tablice povezane istom temom, odnos se može kreirati korištenjem zajedničkog primarnog ključa.
• Ako su predmet i primarni ključevi tabela različiti, trebali biste odabrati bilo koju od tablica i umetnuti njen primarni ključ u drugu tablicu kao strani ključ.

Definiranje odnosa između tabela pomaže da se osigura da su tablice i stupci ispravni. Ako postoji odnos jedan prema jedan ili jedan prema više, tabele moraju sadržavati dijeljene kolone... Ako imate odnos više prema mnogo, potrebna je treća tabela.

Poboljšanje strukture

Nakon kreiranja potrebnih tabela, polja i relacija, trebali biste popuniti tabele uzorcima podataka i izvršiti razne operacije s njima: kreiranje upita, dodavanje novih zapisa, itd. Ovo će otkriti mogući problemi- na primjer, možda ćete morati dodati dodatni stupac ili podijeliti jednu tablicu na dvije kako biste izbjegli dupliranje podataka.

Provjerite može li se baza podataka koristiti za dobivanje odgovora neophodna pitanja... Kreirajte nacrte obrazaca i izvještaja i provjerite da li prikazuju željene informacije. Provjerite ima li u bazi podataka duplih podataka i uklonite te podatke ako je potrebno.

Kada počnete da radite sa svojom bazom podataka, možete identifikovati oblasti za poboljšanje njene strukture. Možete obratiti pažnju na sljedeće tačke:

• Nedostaju obavezne kolone. Ako neki stupci nedostaju, trebali biste odrediti koji od njih postojeće tabele možete dodati podatke. Ako se podaci odnose na drugu temu, možda ćete morati dodatni sto... Kreirajte kolonu za svaku stavku podataka koju želite pratiti. Ako se podaci ne mogu dohvatiti iz drugih kolona proračunima, može biti potrebna nova kolona.
• Prisustvo kolona čiji se podaci mogu dobiti iz postojećih polja proračunima. Ako se podaci mogu izračunati iz drugih kolona — na primjer, cijena s popustom se može izračunati na osnovu maloprodajne cijene — preporučujemo da izbjegavate korištenje dodatnih kolona.
• Prisustvo ponavljajućih podataka u tabelama. U ovom slučaju, trebate podijeliti tabelu na dvije tabele i povezati ih u odnosu jedan-prema-više.
• Dostupnost stolova sa veliki iznos polja, ograničen broj evidencije i prazna polja u pojedinačne evidencije... U ovom slučaju, možda će biti potrebno promijeniti strukturu tabele kako bi se smanjio broj polja i povećao broj zapisa.
• Razbijanje svakog podatka na minimalne komponente. Ako želite da koristite stavku podataka za izvještavanje, sortiranje, pretraživanje ili izračunavanje, treba je staviti u zasebnu kolonu.
• Prisustvo u koloni podataka koji se odnose na temu tabele. Ako kolona sadrži podatke koji nisu relevantni za temu tabele, treba ga staviti u drugu tabelu.
• Relacije između tabela predstavljene zajedničkim poljima ili trećom tablicom. Zajedničke kolone su potrebne za kreiranje odnosa jedan-na-jedan i jedan-prema-više. Treća tabela je potrebna za kreiranje odnosa više-prema-više.

Poboljšanje strukture tabele proizvoda

Pretpostavimo da se svi proizvodi u bazi podataka mogu kategorizirati u nekoliko općih kategorija, kao što su pića, začini ili riblji proizvodi. Tabela proizvoda može sadržavati polje koje označava kategoriju proizvoda.

Pretpostavimo da je nakon analize i poboljšanja strukture baze podataka odlučeno da se sačuva ne samo naziv kategorije proizvoda, već i njegov opis. Ako dodate polje za opis kategorije u tablicu proizvoda, opis bi se morao ponoviti za svaki proizvod u posebnoj kategoriji, a ova odluka nije racionalna.

Racionalniji pristup je postaviti kategoriju kao posebnu temu za praćenje u bazi podataka, kreirati zasebnu tabelu sa sopstvenim primarnim ključem. Tada se primarni ključ tabele kategorija može dodati u tabelu proizvoda kao strani ključ.

Duplicirane grupe treba identifikovati prilikom analize strukture tabela. Pretpostavimo da tabela sadrži sljedeće stupce:

• kod proizvoda
• Šifra proizvoda1
• Šifra proizvoda2
• Šifra proizvoda3

U ovom slučaju proizvodi se ponavljaju grupe kolona koje se međusobno razlikuju samo po broju u nazivu stupca. Ako su kolone numerisane na ovaj način, treba revidirati strukture tabele.

Ova struktura ima nekoliko nedostataka. Prije svega, postoji gornja granica za broj proizvoda. Nakon prekoračenja ove granice, dodajte u tabelu nova grupa kolone, a ovaj zadatak je teško izvršiti.

Još jedan nedostatak je da ako je broj proizvoda za pojedinog dobavljača manji od maksimalnog, neke kolone će biti prazne. Ali najozbiljniji nedostatak ove strukture je komplikovanje mnogih zadataka, kao što je sortiranje ili kreiranje indeksa u tabeli prema kodu ili nazivu proizvoda.

Ako imate duple grupe, razmislite o dijeljenju jedne tablice na dvije. U gornjem primjeru, bolje je kreirati dvije tabele, jednu za dobavljače i jednu za proizvode, i povezati ih pomoću koda dobavljača.

Primjena pravila normalizacije

Sljedeći korak u kreiranju baze podataka može biti primjena pravila normalizacije podataka (ili samo pravila normalizacije). Ova pravila vam omogućavaju da provjerite ispravnost strukture tabela. Proces primjene ovih pravila na strukturu baze podataka naziva se normalizacija baze podataka ili jednostavno normalizacija.

Preporučuje se normalizacija izvršiti nakon unosa svih elemenata podataka u bazu podataka i kreiranja preliminarne strukture. Svrha ovog procesa je provjeriti da li su stavke podataka ispravno raspoređene po tabelama. Međutim, normalizacija ne dozvoljava provjeru valjanosti samih stavki podataka.

Pravila normalizacije se primjenjuju sekvencijalno; u svakoj fazi, usklađenost baze podataka sa jednim od tzv. normalne forme. Postoji pet normalnih oblika. Ovaj članak opisuje prva tri oblika jer su dovoljni za većinu baza podataka.

Prva normalna forma

Prvi normalan oblik sadrži pravilo da svaka ćelija na raskrsnici reda i stupca u tabeli mora sadržavati jednu vrijednost, a ne listu vrijednosti. Na primjer, polje Cijena treba da sadrži samo jednu vrijednost cijene. Ako postoji ćelija na raskrsnici reda i kolone, ona mora sadržavati samo jednu vrijednost.

Drugi normalni oblik

Drugi normalni oblik zahtijeva da svaka kolona izvan ključa mora ovisiti o cijelom stupcu ključa, a ne o njegovom dijelu. Ovo pravilo se primjenjuje ako primarni ključ ima više stupaca. Pretpostavimo da tabela s primarnim ključem kolona ID-a narudžbe i ID-a proizvoda sadrži sljedeće stupce:

• Šifra narudžbe (primarni ključ)
• Šifra proizvoda (primarni ključ)
• Ime proizvoda

Ova struktura ne odgovara drugom uobičajenom obliku, jer naziv proizvoda ovisi o šifri proizvoda, ali ne ovisi o šifri narudžbe; stoga, ova kolona ovisi samo o dijelu primarnog ključa. Kolona s nazivom proizvoda treba ukloniti iz tabele. Mora biti uključen u drugu tabelu (tabelu proizvoda).

Treći normalni oblik

Treći normalni oblik zahtijeva da kolone bez ključa ne samo da zavise od cijelog primarnog ključa, već i da budu neovisne jedna od druge.

Drugim riječima, svaka kolona koja nije ključ bi trebala ovisiti samo o primarnom ključu. Pretpostavimo da tabela sadrži sljedeće stupce:

• Šifra proizvoda (primarni ključ)
• Preporučena maloprodajna cijena
• Popust

Recimo da je popust baziran na preporučenoj maloprodajnoj cijeni. U ovom slučaju tabela ne ispunjava zahtjev trećeg uobičajenog obrasca, jer kolona s popustom koja nije ključna ovisi o drugoj neključnoj koloni (kolona preporučena maloprodajna cijena). Zahtijevanje da kolone budu neovisne jedna od druge znači da promjena bilo koje kolone koja nije ključna ne bi trebala utjecati na druge stupce. Ali ako se promijeni vrijednost u stupcu maloprodajne cijene, vrijednost popusta bi se promijenila u skladu s tim, kršeći pravilo. Stoga, u ovom slučaju kolonu popusta treba premjestiti u drugu tabelu u kojoj je kolona maloprodajne cijene ključna.

Dodatne informacije

Za više informacija o dizajnu baze podataka pogledajte sljedeće knjige.

• Hernandez, Michael J. Dizajn baze podataka za MereMortals: Praktični vodič za dizajn relacionih baza podataka, drugo izdanje. Addison-Wesley Professional. 2003.
• Fleming, Candace C. von Halle, Barbara. Priručnik za projektovanje relacionih baza podataka. Addison-Wesley Professional. 1989.
• Riordan, Rebecca M. Dizajniranje efikasnih sistema baza podataka. Addison-Wesley Professional. 2005.

Odnosi se na Access 2007 i novije verzije

Svaka tabela sadrži informacije o drugoj temi, a svako polje u tabeli sadrži zasebne informacije o temi tabele. Na primjer, tabela sa podacima o klijentima može sadržavati polja s nazivom kompanije, adresom, gradom, državom i brojem telefona. Kada dizajnirate polja za svaku tabelu, imajte na umu:

Svako polje mora biti povezano s temom tabele.

Tabela treba da sadrži sve potrebne informacije.

Informacije bi trebale biti raščlanjene na najmanje logičke jedinice (na primjer, polja Ime i Prezime, a ne opće polje Ime).

4. Postavljanje pojedinačne vrijednosti za svako polje

Da bi Microsoft Access povezao podatke iz različitih tabela, kao što su podaci o kupcima i narudžbe kupaca, svaka tabela mora sadržavati polje ili skup polja koji će postaviti pojedinačnu vrijednost za svaki zapis u tabeli. Takvo polje ili skup polja se zove glavni ključ.

5. Definiranje odnosa između tabela

Nakon distribucije podataka po tabelama i definiranja ključnih polja, trebate odabrati šemu za povezivanje podataka u različitim tabelama. Da biste to učinili, morate definirati odnose između tabela.

6. Ažuriranje strukture baze podataka

Nakon dizajniranja tabela, polja i relacija, potrebno je preispitati strukturu baze podataka i identificirati moguće nedostatke. Preporučljivo je to učiniti u ovoj fazi, dok tabele nisu popunjene podacima.

Da biste provjerili, potrebno je kreirati nekoliko tabela, odrediti odnose između njih i unijeti nekoliko zapisa u svaku tablicu, a zatim vidjeti da li baza podataka ispunjava zahtjeve. Također se preporučuje da kreirate nacrte izlaznih obrazaca i izvještaja i provjerite da li oni pružaju informacije koje želite. Osim toga, potrebno je isključiti sva moguća dupliranja podataka iz tabela.

7. Dodavanje podataka i kreiranje drugih objekata baze podataka

Ako strukture tablica ispunjavaju zahtjeve, tada možete unijeti sve podatke. Tada možete kreirati bilo koji upite, obrasce, izvještaje, makroe i module.

8. Korišćenje alata za analizu u Microsoft Accessu

Microsoft Access nudi dva alata za poboljšanje dizajna baze podataka. Čarobnjak za analizu tablice ispituje tabelu, ako je potrebno, predlaže novu strukturu i odnose, a također je uklanja.

Performance Analyzer ispituje cijelu bazu podataka, daje preporuke za njeno poboljšanje, a također ih implementira.

Kako se razvijaju samostalni dijelovi aplikacije, preporučljivo je prenijeti ih korisniku kako bi provjerili njihovo funkcioniranje i dobili mišljenje o potrebi unošenja određenih izmjena. Nakon što se kupac upozna sa radom aplikacije, gotovo uvijek ima dodatne prijedloge za poboljšanje, bez obzira na to koliko je preliminarna studija projekta detaljna. Korisnici često otkriju da neke od tačaka o kojima su govorili kao veoma važnim i neophodnim u procesu postavljanja zadataka zapravo ne igraju značajnu ulogu u praktičnoj upotrebi aplikacije. Prepoznavanje potrebnih promjena u ranoj fazi razvoja aplikacije može značajno smanjiti vrijeme za naknadnu doradu.