UVOD U ACESS

 

 

 

Analiza i projektovanje

Prije nego što krenemo sa Access-om neophodno je izvršiti detaljnu i opsežnu analizu sistema za koji želimo napraviti bazu. Rečeno stručnim jezikom: «Vršimo analizu realnog sistema i njegovo prebacicanje u informacioni sistem»

Naime radi se o koraku koji većina ljudi preskače, međutim trebalo bi da bude obrnuto, jer od njegovog kvaliteta zavisi uspjeh realizacije i implementacije kompletne baze.

 

Pod analizom se podrazumjeva sljedećih nekoliko koraka koji su preporučeni na svim «Information Technology» fakultetima i preporučen u Microsoft programu certficiranja za baze podataka.

 

1.     Projektovanje opšte strukture sistema

        Prva faza u kojoj projektant upoznaje problem tj. šta mu je zadatak. Najbolje je razgovarati sa osobom čije zanimanje «automatizujete». U ovoj fazi je neophodno raspoznati «entitete» podataka (entitet-skup međusobno zavisnih podataka o nečemu ili nekome). Npr: podaci o studentima, podaci o ocjenama, podaci o kupcima i sl.)

2.     Projektovanje strukture podataka (dijelovi i osobine entiteta)

        U ovoj fazi potrebno je raspoznati osobine entiteta tj. od kojih podataka se sastoji npr. entitet «studenti» (Broj indexa, Prezime, Ime i sl)

3.     Projektovanje tabela i relacija (veza)

        Nakon definisanja potrebnih grupa podataka sljedeći korak je u nekom od DBMS alata (konkretno Access) izvršiti formiranje tabela (koje su u stvari samo elektronske verzije naših entiteta) i njihovih međusobnih relacija (ipak radi se o relacijskim bazama podataka)

4.     Testiranje polja (Unošenje testinih podataka i provjera ispravnosti istih)

        Definisanje pojedinačnih polja u tabeli, njihovih tipova podataka i funkcija koje se brinu za provjeru ispravnosti unesenih podataka (npr. u polje u koje je predviđeno da se unese datum i sl.)

5.     Projektovanje formi za unos i pregled podataka

        Nakon završetka posla sa tebalama slijedi formiranje formi za unos podataka. Ustvari, to su objekti koje će krajnji korisnik i da vidi.

6.     Izrada sistema menija

        Svaka aplikacija mora da ima kvalitetno izrađen sistem menija kako bi navigacija i kretanje kroz istu bilo što lakše i inituivnije.

7.     Dodatno testiranje baze u realnim radnim uslovima

        Faktor koji bi svaki programer baze trebao da uzme u obzir (prije distribucije) jeste simuliranje rada. Danas na tržištu postije tzv. «stres»alati koji taj dio posla znatno olakšavaju.

Projektovanje opšte strukture sistema

Za potrebe vježbi ćemo koristiti jednu zamišljenu bazu za «on-line shop» (naravno u mnogo slabijoj varijanti nego što bi to bila prava baza). Nakon analize (tj. prvog od 7 koraka) smo zaključili da bi jedna on line prodavnica trebala da ima minimalno 3 entiteta koja su povezana direktno odnosno indirektno. To su:

1.     Kupci

2.     Artikli

3.     Narudžba

 

Na slici ispod se vide ti entitei i njihove relacije, koje ćemo objasniti kasnije.

Napomena: Navedena šema će se kroz vježbe dograđivati sa dodatnim elementima kako to bude zahtjevalo gradivo. Kao što se vidi radi se o polaznoj osnovi za formiranje sistema u Access-u.

        

                                    

Slika 2. Entiteti i njihovi međusobni odnosi

                

Šema je formirana u programu Microsoft Visio 2002. Visio omogućava da se na osnovu grafičkih elemenata (UML  modeliranje) napravi slika sistema prije njegove implementacije u npr. Access-u. Projektovanje ide toliko duboku da je moguće izvršiti definisanje polja, tipovava podataka, relacija i sl. Nakon toga je moguće iz šeme generisati gotovu bazu.

Na vježbama se ne radi tako, ali se slike modeliranja sistema prikazuju u Visiu, kako bi se studenti postepeno privikavali na predmet sa treće godine «Softverski injižinjering».

Takođe šema iz Visia je mnogo prihvatljivije i sa mnogo više detalja nego šema tabela i relacija u Access-u.

Naravno mi ćemo kompletnu bazu na vježbama nakon modeliranja u programu Visio uraditi u Accessu-u. Također, sav dalji rad na projektu će biti Access baziran, ali se studentima ostavlja na volju da sami istražuju i upoznaju nove alate i modelere tipa Visio, Rational Rose, Bold for Delphi i sl.

Napomena: Svaki studenti, DL i redovan, će na osnovu projekta sa vježbi stećeno znanje primjenjivati na svojim seminarskim radovima, što je i i cilj VJEZBI

Slika 3. Radno okruženje Microsoft Visio 2002

Projektovanje strukture podataka

Entiteti projekta

 

Prvi entitet je «Kupci». Analizom je utvrđeno da isti ima sljedeće osobine (tj. polja u kasnijim tablicama).

§  KupacID (PK – Primarni ključ)

§  Prezime

§  Ime

§  Telefon

§  E_mail

§  Adresa

§  Grad

 

Napomena: Polje koje je primarni ključ je vrlo bitno u svakoj tablici. To je podatak koji jednoznačno i nedvosmisleno identifikuje tekeći zapis u entitetu (kasnije u tabeli). To su vrijednosti koje ne smije i ne mogu biti duple (u tabeli je teoretski moguće da se nađu dvije osobe – ili više njih, sa istim imenom ili čak prezimenom). Da bi se rješio taj problem neophodne je u entitetu prepoznati šta je to što je jedinstveno. Ako takav elemenat ne postoji, neophodno ga je simulirati ili ubaciti.

Teoretski je moguće da se u «kupcima» desi osoba sa istim ličnim podacima (navedenim gore u listi). Zbog toga samo ubacili polje KupacID (ID – identification) koje će biti jedinstveno za svaki zapis u entitetu.(broj za svakog kupca će biti generisan po nekom šablonu i biti će jedinstven). Npr. (kao matični broj građanina).

 

Entitet projekta

 

Drugi entitet su «Artikli». Analizom je utvrđeno da isti ima sljedeće osobine (tj. polja u kasnijim tablicama).

§  ArtikalID (PK – Primarni ključ)

§  Naziv

§  Cijena

 

Kao i u prethodnom slučaju neophodno je formirati polje koje je jedistveno. Nakon analize je zaključeno je da najbolje uvesti ArtikalID kao primarno polje, tu su još naziv i cijena.

 

 

Treći i finalni entitet (u ovoj fazi projekta) su «Narudzba». Analizom je utvrđeno da isti ima sljedeće osobine (tj. polja u kasnijim tablicama).

 

§  NarudzbaID (PK – Primarni ključ)

§ 

KupacID (FK – Vanjski ključ)

§  ArtikalID (FK – Vanjski ključ)

§  Količina

 

Ovo je entitet koji treba najbolje shvatiti. Logično je da svaki kupac treba da naruči određeni artikal (ipak radi se o on-line prodavnici). Kao i u prethodnim slučajevima neophodno je da entitet posjeduje jednoznačno polje za svaki zapis «NarudzbaID». Sljedeće što nam je potrebno jeste da znamo «ko je izvršio kupovinu» i «šta je kupio». Ta dva podatka se nalaze u Kupcima i Artiklima i nije potrebno da ručno unosimo te podatke kada oni već postoje u drugom entitetu. Dabi postali dostupni u Narudzbama neophodno je da dodamo primarna polja iz Kupaca i Artikala jer preko njih imamo pristup ličnim podacima o kupcu i detaljima u vezi artikla koje je kupio.

 

Napomena: Kada u entitet dodajemo polja koja su primarni ključevi u drugim entitetima tada se oni nazivaju FK – vanjski ključevi, što oni u stvari i jesu. Vanjski ključevi prema podacima koji se nalazi van entieta (konkretno u našem slučaju van Narudzbi).

 

 

Slika 4. Finalne veze