Racunanje u access-u

U fajlu koji cu da zakacim probao sam da dam nekakvu relaciju izmedju gore pomenutih pojmova, nadam se da ce stvari biti malo jasnije sada.

Dakle, kada uzorak stigne u prijemno odeljenje,

svrstava se u odredjenu "Vrstu uzorka" i odredjuje mu se "Tip uzorka".
Za definisani "Tip uzorka", firma radi definisane parametre koji se svrstavaju u dve "Vrste ispitivanja": hemijski parametri i mikrobioloski parametri. Ove dve "Vrste ispitivanja" se odnose samo na usluge koje pruza moja firma. Naravno, odredjeni Pravilnik koji propisuje kvalitet datog tipa uzorka, propisuje i druge grupe "vrste ispitivanja" (recimo vrsta ispitivanja "Radioaktivnost") koje moja firma ne radi (u tom slucaju angazuje se podugovarac).
U okviru "Vrste ispitivanja" Pravilnik propisuje "Parametre" ispitivanja koje treba odrediti da bi se dala nekakva ocena o ispravnosti uzorka.
Pomenuti "parametri" odredjuju se primenom odgovarajucih "Metoda" ispitivanja. Naravno, odredjeni "Parametar" moze se odrediti primenom nekoliko razlicitih "Metoda" ispitivanja.
Svaka od pomenutih "Metoda" ima svoje "Varijable" cijim eksperimentalnim merenjem i racunskom obradom se dobija vrednost odredjenog parametra.

Hijerarhijski odnos bi bio sledeci:

Vrsta uzorka >> Tip uzorka >> Parametar >> Metode >> Varijable

"Vrsta ispitivanja" predstavlja nekakve grupe srodnih parametara (koje se obicno rade u jednoj laboratoriji). Pa tako mogu biti: hemijske, mikrobioloske, radioloske, fizicke, elektricne itd.

U najkracim crtama, korisnik kaze "zelim hemijsku analizu" to znaci da treba odraditi sve parametre koji pripadaju hemijskoj vrsti ispitivanja, a te parametre propisuje Pravilnik o kvalitetu tog proizvoda.

Evo zakacicu i jedan Pravilnik o kvalitetu (u pitanju je hrana za zivotinje)

Pa tako, clan 19 Pravilnika propisuje koje parametre soja (Tip uzorka) mora da ispunjava da bi bila ispravna za zivotinjsku upotrebu, pa tako stav 3) istog clana kaze da "da ne sadrži više od 10% vlage". To znaci da je "parametar" ispitivanja "Sadrzaj vlage".
E sada, taj parametar "Sadrzaj vlage" mozemo odrediti gravimetrijskom metodom (susenje na odredjenoj temeraturi, pa potom merenje mase). Tu sada imamo "varijable" na primer:

-m1 - masa praznog suda
-m2 - masa punog suda pre susenja
-m3 - masa punog suda nakon susenja

pa kada izmerimo ove varijable i primenimo formulu, dobicemo vrednost za parametar "Sadrzaj vlage"

dakle:

%vlage=(m3/(m2-m1))*100

Evo, mislim da je ovo bilo bas slikovito (ovako se radi inace u praksi)

Pozdrav

Pun pogodak! Excel faj 'kategorizacija' je odlican. Tvoje zapazanje da se Vrsta Ispitivanja doda na TipUzorka kao atribut je tacno. Ono sto smo zvali Vrsta Ispitivanja u ansoj shemi, preimenovacemo u Vrsta Uzorka. Cela hijerarhija vrsts uzorka -> tip uzorka -. parametri-> metore -> varijable lepo je pokazana u Excel fajlu.

Zakaceni pravilnik je takodje koristan. Navodi me na zakljucak da u tabeli Parametri treba da dodamo i granice prihvatljivosti - minimalne i maximalne dozvoljene vrednosti. pfretpostavljam da se parametri mogu izraziti brojevima. Ako ima nekih parametara koji se izrazavaju opisno, onda bi trebalo te opise prekodirati u brojeve, da ne bismo mesali tipove podataka u jednoj koloni.

Ako stignem danas prepravicu shemu baze. Iz dosadasnje diskusije trebalo bi da je ocigledan metod crtanja sheme , sa prenosenjem PK, a sada su napokon poznati i odnosi izmedju entiteta, barem na strani pravilnika i sifranika. Iz ovoga sledi da bi Zliki mogao i sam da pokusa da prepravi shemu baze. Nije obavezno, li je lepo pokusati, ja cu svakako napraviti izmene cim stignem danas.

Iskreno, ja ne umem ovo da korigujem. Probao sam, ali mi neide, malo sam se pogubio oko ove glomazne seme.
Molim da neko ovo odradi ako moze.

Hvala

Evo je korigovana Access baza. Znam da izgleda komplikovano ali ne umem da je uprostim a da ne izgubim nesto od integriteta. Cini mi se da bi mogla jedna od tabela da se ukloni potpuno, ali o tom potom. Ne vidim kako bi mogli da pojednostavimo kljuceve a da ne narusimo integritet, to bi mogao neko ko se razume u normalizaciju da nam pomogne.

Elem, evo baze. Sad moze Zliki da pokusa da unese podatke na strani sifranika i laboratorija, bar nesto, da imamo s cim da probamo.

Onda moze da se zamisli da je stigao zahtev i da vidimo da li moze baza to da prihvati. Ako moze, mi smo na konju. Ako ne, nesto ce da se popravlja. u svakom slucaju ne vredi programirati nista u ovom momentu dok ne utvrdimo da baza zaista moze da prihvati podatke koje imamo i da iz baze mozemo da izvadimo nekakvu razumu blisku informaciju. Pazi ovo 'u bazu ide podata' a 'iz baze izlazi informacija'. cool, eh :-)

Da se i ja malo uključim u raspravu što se tiće minimalne i maksimalne vrijednosti u tablicama.
Da se pazi da nema opisnih vrijednosti u njima kao što kaže Zidar, jel kasnije kod izlaznih listi stvara problema.

Imao sam takavo iskustvo u ispravljanju takvog programa za analizu vode.

sve je bilo ok za kemijske elemente gdje min i max bio neki broj
ali desilo se da su kod "Mutnoca_vode" pisali, zuta, smeđa itd.....
i tu je sve padalo kod izračunavanja vrijednosti dal udovoljava kriteriju ili ne

Hvala na komentaru, dobro zapazanje.

Pa, vrednosti parametara su uglavnom numericke (kazem uglavnom) posto se radi o kvantitativnoj analizi. Naravno ima i opisnih (kod kvalitativnih analiza) napr. "nema" ; "bez"; "pozitivno" ; "negativno" sto je narocito izrazeno kod mikrobioloskih analiza itd.

Takodje, nesto sto nisam rekao a bitno je, IZVESTAJ O ISPITIVANJAU KAO I SVO OSTALI FORMULARI MORAJU BITI CIRILICNI (svi zvanicni reporti). Znam da je bez veze ali je neophodno.

Jos nesto, koristimo verziju Access 2003.

Probao sam da unesem podatke. Evo zakacicu bazu koju je Zidar poslao sa podacima koje sam uneo.
Neki delovi su jako dobri, neki opet nejasni. Postavka modela nije idealna, potrebne su dodatne korekcije. Opsti utisak, ovo stvarno moze da bude fantasticno odradjeno.
E sada, mislim da smo zaboravili bitnu stvar a to je UZORKOVANJE. Nigde se ne spominju podaci o izvrsenom uzorkovanju (Zapisnik o uzorkovanju).
Takodje, zaboravili smo da u model ubacimo UGOVORE SA KORISNICIMA. Nesto ranije sam pricao o tome.

Veoma veliki problem, za sada, predstavlja definisanje VrsteIspitivanja. Jos uvek je to tabela tblVrsteIspitivanja, mislim da je treba izbaciti, ali moram dobro da razmislim.

Onaj deo modela gde su sifrarnici, dobro je po meni odradjen. Unos ide glatko i bez problema.

Deo sa laoratorijama u ugovorima eksternim mi malo skripi, nije mi bas sve jasno, pogledacu detaljno.

Generalno, jos nije to to, ali napredujemo (doduse jako sporo, ali valjda to tako i treba da bude dok stvari ne "legnu" na svoje).

Pogledacu sve detaljno ponovo. Mislim da cu uspeti da uprostim model, vec imam neke ideje koje moram da proverim.

OK, toliko za sada

Juce nisam bio tu, a pokusao sam dva puita da posaljem odgovor i oba puta je nestao !?

Ovako, idemo redom:


Pa imamo onu tabelu gde se pominje 'uzorkivac' i zahtev za uzorkovanje, tu cemo da ubacimo zapisnik. Zapisnik ce biti predstavljen verovatno skupom atributa u toj tabeli.

I ovo je kao reseno, samo se ne vidi. Tabela u kojoj se registruje Zahtev za ispitivanjem moze da sadrzi skup atributa koji opisuju ugovor. Pretpostavka je da za svaki zahtev sledi ugovor. Ako nije tacno, kazi pa cemo razmotriti. Sam ugovor je verovatno tipski formular koji mora da potpisu direktori. kao takav, ne moze se menjati. Znaci, mi treba da cuvamo u bazi verovatno skeniranu sliku tog ugovora. Sliku moze da napravi svaki skener, a i moderniji forto-kopir aparati prave odmah PDF koji moze da se e-mailom posalje (sa kopir aparata) recimo administratoru baze koji ce sliku da ubaci u bazu.


Taman posla da to izbacimo sada. Toliko smo se mucili da to ubacimo. To nam izmedju ostalog definise sta koja laboratorija moze da radi. ako te ensto buni, kazi pa da vidimo moze li se nekako razresiti.


Taj deo se nece nigde videti, nikakv kod to nece obradjivati. jednostavno, ako definises da je neka laboratorija 'externa' onda samo takva laboratorija moze da ima onaj externi ugovor. Baza ce sama da se pobrine da ti ne dozvoli da uneses lokalnu laboratoriju u tabelu gde idu externi ugovori.


Sve kako ide normalno. problem je kad ljudima dosadi analiza ili odluce da se nesto mora uraditi sto se vidi, sto pre. Do sada smo resavali krupne stvari. Sad mozemo da se posvetimo detaljima koji su mozda i bili pomenuti negde tokom procesa, ali smo ih svesno ili nesvesno ignorisali u korist 'vaznijih' stvari.

Poenta je da jos uvek ne mzoe da se sedne i pocne da se programira.

Pogledacu sta si uneo pa da vidimo dalje.

Evo koje izmene sam napravio, onako na brzinu:

1) u tabeli Varijable dodao sam kolonu "OpisVarijable". m1 i m2 ne znace mi nista, ali ako kazes da je m1 = masa uzorka pre susenjai m2 = masa uzorka posle susenja, onda je jasno da je m1-m2 = tezina vode koja je isparila pri susenju i formula dobija smisao.

2) dodao sam OLE polje za ugovor u tabeli Zahtevi

3) dodao sam u tabelu NalogZaUzorkovanje OLE polje za zapisni, datuim naloga, datum izvrsenja

Umesto ovih OLE polja mnogi ce savetovati da se cuva putanja a da su fajlovi na disku. Kako hoces, bolje je u bazi nego na disku, ali jede vise prostora i zna da bude sporije ako se kveriji nepazljivo sastave. SELECT * FROM TabelaSaOLEPoljem ce biti jako sporo. Kad predjete na Access 2007, mgu da se koriste Attachment polja, koja su malo manje zahtevna nego OLE.

Ne vidim nista sto smeta. Sigurno kojekuda treba dodati atribute, sad je vreme za detaljisanje.

Pojednostavljenje modela je moguce ali zavisi od toga st se precizira zahtevom. Ako zahtev ne navodi koji ce se parametri odredjivati, nego samo 'vrstu ispitivanja' a parametre odredjujete na osnovu nekog zakona, onda tabela tblZahteviParametri moze da nestane. Verovatno se u zahtevu ne precizira ni metoda, onaj pekar koji trazi ispitivanje brasna to radi zato sto mora po zakonu, i verovatno on samo hoce 'hemijsko i mikrobiolosko ispitivanje brasna, hleba i mleka, sa svim parametrima koje zakon zahteva i metodama koje su propisane'. Tako, ove dve tabele, tblZahteviParametri i tblZahteviMetode verovatno mogu da se izbace. Tabela tblZahteviTipoviUzoraka bi se vezala za tabelu tblVrednostiVarijabli. tblVrednostiVarijabli mora d aostane bas ovakva kakva je, da se ne izbacuju kolone ni da se ne smanjuje broj kolona u PK. Inace cete moci da ubacite u tblVrednostiVarijabli i verijable koje uopste ne idu uz ono sto je trazeno da se odradi. Naravno da vi to ne biste uradili, ali ne radi se o tome sta biste uradili, nego sta se moze nenamerno ili namerno upisati u bazu. baza mora sama da se stiti od losih podataka.

Verovatno cemo morati da ubacimo i tabelu koja pamti rezultate. kad externe laboratorije rade nesto, onda od njih dobijete rezultate - izracunate parametre. Ne vidite varijable, ali moze da bude poznata matoda i svakako ime parametra. naci, ne bi uvek u svim tabelama bili svi podaci zastupljeni. tblVrednostiVarijabli se popunjava samo kada vase interne laboratorije rade analize (a to je verovatno najcesce)

To ce sad da bude interesantan posao.

Jos jedna vazna stvar mora da se odradi. varijable moraju da se uvrste u formule i da se posle sve izracuna upotrebom EVAL funkcije. na pocetku diskusije pokazali smo kako se to moze odraditi ako tabele nisu normalizovane. Sad imamo normalizovane tabele, treba nam metod za konstruisanje izraza koji ce ici u EVAL. Ako vam to na primer odradi korektno domaci_a_nas, mogli bi da ponudite coveku stalni posao i da vam odrzava aplikaciju i ceo sistem. Nema smisla da onakav majstor trosi vreme na birou. Ovo sto pokusavas da napravis je OGROMAN sistem i nije moguce predvideti gde ce sve to stici i sta ce buducnost doneti. Za tako nesto je potreban covek u kuci ko ce to da radi. Nikakvi konsultani nece to moci d aurade, ma kako bili pametni i/ili skupi. ne salim se , za ovo vam treba ne dobar nego odlican programer pri ruci i na raspolaganju svaki dan.

Evo najnovija verzija. Dodao sam modul i dve funkcije koje pomazu da se izracuna vrednost parametra za varijable koje su sacuvane u bazi za konkretan zahtev. Imate komentar u kodu i dva-tri test primera, da se vidi da ovo radi.

Promenio sam tip podataka za izmerene vrednosti varijabli - sada je Number Single, nije vise tekst. Verovatno i vrednost parametara treba da bude numericki tip.

Ako ne moze veliki sistem koji pokriva celu firmu, moze barem od ovoga da se napravi lep kalkulator za proracune u laboratoriji. A onda ga prodate vladi Srbije koja kroz Narodnu Skupstinu progura zakon da se proracuni moraju raditi bas ovim proramom....

Mislim da ovd enegde treba i da zavrsi moja uloga. Sad sledi razrada detalja.

Ajd da probam da uprostim malo.

U 99% slucajeva prica sa zahtevom se svodi na: "trazi se mikrobioloska i/ili hemijska analiza uzorka". Znaci onaj pekar, naravno, trazi mikrobiol i/ili hem analizu pritom nema pojma koji su parametri potrebni a kamoli kojim se metodama odredjuju (njega to i ne interesuje, njemu je bitno da ima izvestaj u kojem pise misljenje da je proizvod zdravstveno ispravan).
E sada, postoje i korisnici (znatno manji broj) koji tacno zele da se odrade odredjeni parametri. Recimo, klijenta interesuje sadrzaj gvozdja u sircu i niti jedan drugi parametar. Ili donesu ljudi mleko i traze da se odradi parametar sadrzaj mlecne masti i nista vise.
Znaci, potrebno je odraditi nekakvu varijantu da se podrze oba koncepta.
Evo zakacicu nas formular zahteva na osnovu koga cu dati poblizu sliku o ovome.

Druga varijanta uproscavanja je da se potpuno izbace varijable iz modela (sto mi se ne svidja, moram priznati) vec da se u bazu upisuju gotovi rezultati analize parametara. Ovo mi nije bio cilj, ali ukoliko ce pomoci da se odradi posao brze, ucinicemo to.

Baza onakva kakva je podrzava obe varijante. To se resava programiranjem. ako dodje peakr i trazi "hemijsku i mikrobiolosku analizu" i to je 99% slucajeva, onda na formi gde se registruje zahtev uneses zahtev, pa za zahtev uneses po jedan rekord za hemiju i jedan rekord za mikrobiolosku analizu. Podrazumeva se da ce se odraditi odredjena grupa parametara, koju pekar ne zna i ne interesuje ga, ali vi znate. Onda kliknete na dugme i dugme dodeli uzorcima iz ovog zahteva sve potrebne parametre, metode, varijable. Ako je u pitanju korisnik iz grupe 1% i trazi samo gvozdje u sircetu, onda treba da postoji posebna forma koja dozvoljava unos u sve tabele, duboko koliko treba.

Nema svrhe izbacivati varijable, onda nemas nista u stvari.

Eto, vec si u fazi kad se razmislja o programu - kako uneti podatke u bazu u raznim slucajevima (obican korisnik ili onaj sa specijalnim zahtevom). Bazu (tabele) ne interesuje kako su podaci uneseni i odakle stizu. Za zahtev, imacete formu za registrovanje, pa formu za potvrdjivanje, pa formu z aunos rezultata, pa formu za definisanje zahteva za uzorkovanje i tako dalje. Otprilike za svaku, ali bas svaku tabelu u shemi trbece jedna ili dve forme. neke od formi ce biti povezane kao forma-subforma, neke ce biti nezavisne. Trebace dugmici da bi se moglo skakati sa jedne na drugu. i naravno, izvestaji.

Ali pre toga da se dodefinisu atributi. Ono sto imamo je goli minimum. neke tabele nece trebati vise atributa, dosta im je sta imaju. Ali neke ce trebati jos. Korisnik, Zahtev - to syu radne tabele i trebace im kojekevih kolona.

Pozto programiranje trazi obracanje paznje na mnogo vise detalja, predlazem da zaista angazujete nekoh iskusnog programera da vam pomogne. Pozeljno da taj neko bude u istom gradu, da mozete da se sretnete lice u lice. Nemojet da se zavaravate da ce toneko uspeti amaterski da uradi, pored redovnog posla, onako usput. Ovo je vrlo ozbiljan sistem i trazi osobu posvecenu projektu puno radno vreme. Ako nema para - too bad. I auto kupis ako imas para, ako ne, ides autobusom. Pitajte IBM ili neku veliku firmu koliko para traze za nesto ovakvo. cak i kad im ponudite shemu baze, da samo odrade aplikaciju. Mnoooogo. Nije to bez razloga.

Srecan rad

Nije me bilo neko vreme, tu sam ponovo.

Hvala na iskrenim odgovorima.

Imam nekoliko nejasnoca oko dodavanja atributa tabelama. O cemu se radi:

pa formulari zahteva odnosno zapisnika o uzorkovanju nisu identicni, razlikuju se zavisno od vrste uzorka. 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.

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?

Pozdrav

Odlicno pitanje, znaci da napredujes sa anlizom

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.



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....

Hvala, hvala, pa trudim se zaista. Uh, bice ovde jos dosta pitanja, verujem. Znam da je ovo bio veliki problem, ozbiljno cu analizirati obe opcije, pa cemo da vidimo.
Nakon ovoga, ne bismo trebali da imamo problema oko definisanja atributa za ostale tabele, bar se nadam.

A ono, naravno, pa razmisljam i o aplikaciji. Imam u glavi i kako bi zeleo da sve to izgleda, ali otom potom..

Bacam se na analizu sada.

Pozdrav