Odlicno pitanje, znaci da napredujes sa anlizom
Citat:
Prakticno, za svaku vrstu uzorka se definisu posebni zahtevi odnosno zapisnici o uzorkovanju.
Kako ovo resiti? Da li nas model podrzava ovako nesto? Da li su potrebne zasebne podtabele za svaku vrstu uzorka ponaosob?
Moze da se resi na dva nacina:
a) tipizacijom => za svaku vrstu uzorka radi se posebna tabela koja sadrzi tacno one atribute koji se traze za tu vrstu uzorka. Ta tabekla je u vezi 1:1 sa tbelom ZahtevVrstaUzorka, gde je ZahtevVrstaUzorka roditelj druga tabela je dete. dakle, 1 : 1 ali nsu obe jedinice iste, nego nesto kao 1 Zahtev ---> 1 red u tabeli atributa za tu vrstu zahteva. Dobre strane = ako se razume o cemu se radi, puna kontrola nad tipovima podataka z apojedine atribute. Losa strana: sta ako se nseto promeni u skupu atributa, doda se novi atribut =. menjajnje strukture tabele => menjanje svih kverija i progranma i reporta koji koriste tu tabelu. I tako za N tabela koje pokrivaju N vrsta uzoraka. A tek kad se doda noav vrsta uzorka... znam da se nove vrste uzoraka en dodaju svaki dan, ali tim gore. za 10 godina ce neko dodati novu vrstu. Ko ce za 10 godina od danas moci da preprogramira aplikaciju da bi se prihvatila nova vrsta uzorka?
b) jedna tabela, u koju se za razlicite vrste uzoraka unose razlicitei atributi. Dobra strana: fleksibilnost. Moze da se doda nova vrsta uzorka u billo kom momentu i da se za svaku vrstu uzorka dodaju novi atributi po volji. Programi, kveriji, forme i reporti ne moraju da se menjalu ni malo. Losa strana: nikakva kontrola nad tipovima podataka i ogranicenjima za atribute. Kako garantovati da ce brojne vrednosti biti bas brojevi, da ce vrednosti biti iz propisanih opsega i slicno.
Losa stvar u oba slucaja je sto ne postoji mehanizam da se garantuej da ce se rekord ili rekordi na child strani uopste uneti. Pazi, veza je 1:1 a ne 1: (1 ili 0). Ni jedan SQL sistem, pa ni Access ne garantuej obaveznu kardinalnost tipa "roditelj mora imati tacno N dece, N>0". To mora da se resi kodom i na srecu kod je jednostavan i elegantan i svaki programer ce uzivati da radi na takvom zadatku.
AKo pazljivo razmotris dobre i lose strane, mozes da zakljucis koji bi pristup bio bolji. Moze se desiti da ti se ucini da je jedan pristup bolji i kad udjes u praksu zakljucis da je drugi ipak bolji. Desava se, niko nije genije pa da sve previdi unapred. A ne mora da se desi. Znaci, dobra analiza opcija i potencijalnihe dobiti i stete je obavezan korak. Uz malo srece, doci ces do pravog resenja.
Citat:
Tako na pr. za uzorke otpadnih voda, upisuju se temper vode i temp vazduha, postrojenje, recipijent itd.
Kod uzoraka namirnica, upisuju se objekat, uzorkovana kolicina, uzorkovano iz kolicine, nacin pakovanja (originalno ili ne) itd.
Kod uzoraka vazduha, upisuju se: punkt, protok vazduha (m3/h), temp vazduha, pritisak vazduha, vlaznost vazduha itd.
primer za varijantu 1:
Naprave se tabele za svaku vrstu uzorka:
CREATE TABLE ZahtevVrstaUzorka_OtpVoda
(ZahtevBR as text PRIMARY KEY REFERENCES ZahtevVrstaUZorka
, VrstaUzorka as text CHECK VsratUzorka = 'Otpadna Voda'
, temparatura das ecimal
, postrojenej as text
, recipijent as text
)
CREATE TABLE ZahtevVrstaUzorka_Namirnica
(ZahtevBR as text PRIMARY KEY REFERENCES ZahtevVrstaUZorka
, VrstaUzorka as text CHECK VsratUzorka = 'Namirnica'
, objekat as text
, [uzorkovana kolicina] as decimal
, [uzorkovano iz kolicine] as decimal
, [nacin pakovanja] CHECK ancinpakovanja IN ('originalno','nije originalno')
)
I tako dalje za svaku vrstu uzorka. U programu treba napraviti subformu za svaku od ovih tabela i te subforma automatski dodeljivati master formi ZahtevVrsteUZoraka
Evo primer za varijantu 2. Treba da se uradi ovo:
1) kreirati tabelu VrstaUzorkaAtributi, koja za svaki tip uzorka definise atribute koje treba u zahtevu prikupiti. Ovako:
VsrtaUzorkaAtributi (VsrtaUzorka, Atribut, Redosled) PK: (VrstaUzorka,Atribut) FK: REFERENCES VrstaUzorka.VrstaUzorka
(nadam se da razumes pseudo sintaksu kojom opisujem tabele) Podaci u tabeli bi izgledali ovako:
VrstaUzorka Atribut Redosled
-------------------------------------
'Otpadna Voda' , 'temperatura vode', 1
'Otpadna Voda', 'Postrojenje', 2
'OtpadnaVoda','Recipijent', 3
'Namirnica', 'Objekat', 1
'Namirnica', 'Uzorkovana Kolicina', 2
'Namirnica', ''Uzorkovano iz kolicine', 3
'Namirnmica','Nacin Pakovanja', 4
'vazduh','Punkt', 1
'vazduh', protok vazduha', 2
'vazduh',' temperatura', 3
'vazduh','pritisak', 4
'vazduh','vlaznost', 5
Ovo je tabela na strani pravilnika. Jos nam treb tabela na strani Zahteva za uzorkovanje, koja za svaki uzorka, saglano vrsti treba da sadrzi sve nabrojane atributa plus vrednosti. program bi mogao da po zadavanju vrste uzorka automatski prepise iz tabele VrstaUzorkaAtributi prepise sve atribute u tabelu ZahtevVrstaUzorka. Onda se ceka korisnik da unese vrednosti.
Vrlo brzo ce s epostaviti pitanje opste strukture programa. Tu dolaze Zidareva teorema koja kazu
Teorema 1: "Svaka relacija parent: child se u aplikaciji pretvara u form:subform kombinaciju, gde je parent form a child je subform"
Teorema 2: "za parent tabele tabelu treba imati alat za pretrazivanje jer je za UPDATE i DELETE neophodno pronaci rekord na d kojim se zeli odraditi zadata operacija"
Ovo znaci da treba nacrtati sehmu tabela i pogledati sta su roditelji a sta su deca. Ako su relacije visestepene, treba redom napraviti parove forma-subforma za svaki stepen. Onda treba pozivati parove najviseg nivoa i na njih zakaciti parove nizeg nivoa.
Ovim formalnim pristupom se izbegava mozganje o samom procesu rada - to smo obvili kd smo razradjivali shemu baze podataka (tabele i odnosi medju njima). Na taj nacin smo proces rada u stvari zapisali u samu shemu (za onoga ko ume da gleda i razume sta smo radili) pa nam je sada lakse, ne moramo ponovo da idemo detaljno kroz proces.
Ovo sve ce nam dati grubi kostur, to jest konstrukciju nase zgrade - aplikacije. Raspored soba i boja plocica moze da se detaljise kasnije pa i da se menja kasnije, tokom zivota aplikacije.
Uh, zalazimo u programersku teritoriju....