Procackao sam malo po foromu, postoji sjajan primer sa popup kalendarom i kalkulatorom. U principu, treba mi nesto slicno samo gde bi se umesto brojeva koristile promenljive.

Stvarno ocekujem da ova tema zainteresuje nekoga.

Pozdrav

Trebalo bi napisati dovoljno inteligentan VBA kod, koji će tekst iz Memo polja „Obracun“ tabele „tblParametar“, pretočiti u univerzalnu funkciju. Znači da razume i rasčlani iskaz tipa a3=b3/(v1+30,254*v2).
Access je ipak alat koji je orjentisan ka bazama podataka, s predpostavkom da se promenljive nalaze u tabelama i nad njima izvršavaju fiksne računske operacije. Ove operacije se inače realizuju delom kroz VBA kod, delom putem SQL-a i standardnih matematičkih funkcija: Sum, Avg, Min, Max........ i pridruženih operatora.

Moram Getsbia demantovat tj ispraviti

Ako u textbox8 unesemo (5+6+5)-(2*2.3)
a želimo da izračuna u u textiznos onda koristimo funkciju EVAL
znači na klik dugmeta ili , exit text8

textiznos=Eval(textbox8)

naravno da matematički izraz mora biti dobar, mislim na zagrade

Pozdrav

Izvini Trtko, mozes li na primeru da mi ovo pojasnis, ne znam za ovo a cini mi se interesantnim. Molim te

Pozdrav

Evo probao sam, pa ovo je sjajno, radi perfektno sa brojevima.
Kako bih sad mogao da ubacim promenljivu.
na primer>

da umesto izraza (2+5)/(24+6)

unesem (x+5)/(24+6)

pa da mi on trazi vrednost promenljive x, i nakon unosa mi izracuna jednacinu.

Molim za pomoc, ovo mi je jako bitno da resim.

Hvala puno na odgovorima i jednom i drugom.

Ovo sad na grubo objašnjavam

Pa morao bi deklarirat x,y,z,a1,a2,b2....itd (sve one koje misliš koristit u formulama) kao public varijablu u nekom modulu

i njima pridodjeljivat vrijednosti iz tablica , tako bi s njima mogao računat

Nisam gledao tvoju bazu, ako stignem pogledat ču.

To ti je samo moja ideja, a ti si malo razmisli kako da to najbolje napraviš

hmmmmm , čini se da neče iči ni s deklaracijom varijabli

probat čemo to kasnije riješit

deklarisi ih kao tekst

Koliko vidim, postoji nekoliko varijanti da resim problem:
1. Da kreiram tabele za svaki parametar posebno (tblParametar1_Racun;tblParametar2_Racun itd.), da potom kreiram popup forme za unos varijabli, pa da mi na click popuni vrednost za rezultat.
2. Da kreiram excell fajlove sa zadatim izracunavanjima. Onda prozovem fajl (na neki click), otvori se excell dokument (tacno odredjeni), ja unesem promenljive, dobijem rezultat, i isti ubacim u access.

Ova prva varijanta mi se vise svidja, mada imace dosta posla. Drugo, kad se pojavi neki novi parametar, moracu da kreiram novu tabelu, forme itd., sto sam hteo po svaku cenu da izbegnem, ali po svemu sudeci to nije moguce

Molim za vase misljenje

Hvala vam na dosadasnjim odgovorima.

Pozdrav

Ovaj EVAL je jako opaka stvar-funkcija. Kako proširuje vidike tako i sputava.
Može li se napraviti da Tekstualno polje posle promene vrednosti dobije format novčane jedinice???

otprilike u obliku:

Me.Tekst0.Value = Eval(Me.Tekst0)
Me.Tekst0.Format.Current

Pozdrav

Gorancho
Naravno da se može, sve što se može setirati podesiti i napraviti
kad editiraš formu i njene objekte, boje, formati objekata itd... to sve možeš
napraviti i iz VB koda

Priznajem da ranije nisam primetio funkciju EVAL(). Biće veoma interesantno napraviti koliko toliko univerzalno Access rešenje za zlikijev problem.

Vidim da tema postaje interesantna, hvala vam za trud i dosadasnje odgovore. Posto je tako, probacu jos malo da pojasnim stvari. Ko sto sam ranije pisao, u bazi sam definisao tip materijala. Za svaki tip ispituju se tacno odredjeni parametri (shodno propisima). Svaki parametar ispitivanja izrazava se nekom numerickom vrednoscu (ukoliko se radi o kvantitativnim ispitivanjima ili ti merenjima) ili opisnom-tekstualnom vrednoscu (kvalitativna ispitivanja). Da bi dosli do konacnog rezultata ispitivanja, koristimo vrednosti dobijene eksperimentalnim putem (numericke vrednosti), koje, preko tacno definisanih izraza za izracunavanje, prevodimo u konacni rezultat ispitivanja.
Znaci, da bi sve bilo "crno na belo", lab. prikuplja, belezi i arhivira sve eksperimentalne podatke vezane za odredjeni parametar. To znaci da bi dosli do konacne vrednosti rezultata ispitivanja za neki parametar, nama je potrebno da eksperim. odredimo ili izmerimo 2,3,4 pa i vise promenljivih. Ono sto je ovde sigurno, to je da se za svaki parametar unapred zna koje se promenljive odredjuju (mere) i koji se mat. izraz koristi za izracun. konacnog rezultata.

Izgleda da ti nedostaje jos jedna tabela - gde cuvas vrednosti a,b,c itd. koje ce formule da koriste. Ti si napravio tabelu gde cuvas formule - tekst formule za svaki "Tip". primeru koji si dao, imas nesto sto se zove 'Tip1' i to nesto ima tri parametra. Svaki parametar ima svoju formulu koaj ima u sebi neke varijable. Recimo da ona prica sa EVAL i proradi, ostaje pitanje odakle dolaze varijable za formule?

Nisam nogo koristio EVAL, isuvise je otvoreno i tesko se pronalaze greske. Ali, mozes da probas ovo: koristis svoju formulu kao sablon, pa kad dobijes zive brojeve za parameter odnekud, onda ih sa REPLACE zamenis u formule. Na primer, dao si formulu a1=(b1-c1)/b2. "a1" je ocigledno rezultat, on sa desne strane je formula. (Gde ces da ga cuvas rezultat, u kojoj tabeli, u kojoj koloni?). Varijable su b1, c1, b2. AKo si dobio b1 = 5.7 , c1 = 3.2, b2 = 0.6 onda nekako u formuli zamenis slova brojevima i dobiejs string recimo ovako:

a1 = (5.7 - 3.2) / 0.6 Onda to posaljes u Eval, ovako Eval ("(5.7 - 3.2) / 0.6 ") Oops, ispade da ti a1 samo smeta :-)

Usput, ovo sam dobio u immediate prozoru:

? Eval ("(5.7 - 3.2) / 0.6 ")
4.1666666666666666666666666667

Evo kako REPLACE moze da pomogne u gradjenu eval stringa:

? replace("a1 / b2","a1","7.5")
7.5 / b2

? replace("7.5 / b2","b2","-0.23")
7.5 / -0.23

Sada, kako znas z svaku formulu koliko puta treba da radis REPLACE. Ima smisla sve staviti u nekakvu genericku funkciju, kojoj posaljes oblik formule, recimo "(a1+b2-c3) / (d+f)" i naravno saljes niz varijabli (1.2,1.5,7.12,-3.4) Naravno, redosled varijabli u nizu je bitan, nekako treba da ih mapiramo na formulu. Po pozicijama? Kao matricu? Kao SQL tabelu?

Suvise je pitanja na kja se tesko moze dati odgovor. ja bih rezultate merenja trpau bazu, a onda iz Excela pozivao podatke koji sede u bazi i vrsio kompleksna izracunavanja. Ovo nije za sam Access.

Nesto mi je bila poznata tema, kad ono bilo je nesto slicno na SQL forumu. Evo pa vidi:

http://www.elitesecurity.org/t...rmula-za-izracun-iznosa-tabeli

Sjajno, hvala na odgovorima. Ovo sa upotreboma replace funkcije mi je danas palo na pamet. Probao sam to da razradim malo. Evo poslacu primer uz ovu poruku. Al pre toga da pojasnim malo ideju. Znaci, kreirao sam novu tabelu tblObracun, koja sadrzi polje FORMULA (u koje se upisuje kakva god se zeli formula), 10 polja sa nazivom O, 10 polja sa nazivom t i 10 polja sa nazivom X. U polja sa nazivom "O" upisujem oznake promenljivih iz formule, u polja sa oznakom "t" upisujem tekstualno objasnjenje oznaka i u polja sa oznakom "X", eksper. vrednosti promenljivih.
Napomena: Polja sa oznakom "X" imaju kod za after update event, kde se koristi funkc. REPLACE.
Kada se unesu potrebne promenljive (njihove vrednosti) pritiskom na cmd. dugme dobija se zeljeni rezultat u polju REZULTAT.

PROBLEM: Kada za vrednosti promenljivih upisujem decimalne brojeve (sto je cest slucaj u praksi) program prijavljuje gresku. Ocigledno je negde greska u tipu podataka. To nisam jos uspeo da sredim, pa vas molim da neko ovo malo doradi.

Znaci, ova tabela bi bila (u prvobitnoj verziji baze, Primer1) vezana za tabelu tblParametar u relaciji 1 prema 1 (mada kad malko bolje promslim, moze da bude i u relaciji jeda prema vise posto se pojedini parametar moze odrediti preko vise razlicitih metoda odredjivanja).

Toliko, hvala vam na odgovorima. Jos ednom vas molim da neko doradi ovaj primer koga cu sada da zakacim.

Pozdrav

A evo ga i u ne zipovanom obliku

lepo ti radi i sa decimalama. problem koji imas nisu decimale nego redosled izvrsavanja programskih koraka.

Imas 10 polja u koje se unose vrednosti. stavio si na After Update za svako polje da se radi REPLACE. To znaci samo tada. Ako odes pa promenis jednu vrednost samo, ne diras ostale, dobijes gresku jer se izraz za EVAL ne izracunava dobro. Ovo znaci da bi svih 10 Aftre_Update eventa morali da se izvrse svaki put kad kliknes dugme za obracun. I moras da se pobrines o praznim celijama - ako nemas O9 i X9 program ce da pukne.

Kod na dugmetu treba da izgleda ovako:

Procitaj komentar i resi se OnError Resume Next linije.

Da se pobrines o NULL vrednostima (prazne celije) tvoje UPADTE procedure treba da izgledaju ovako:


Ja sam ti popravio kod malo, tek da proradi. Ti se pobrini za ostalo.

Medjutim, ima jedan problem. Sta ces kad bude vise od 10 parametara? Ovo bi moglo lepo da se normalizuje, pa da na formi imas subformu umesto 50 text boxova. I ceo proracun bi bio na jednom mestu, a ne na 10 mesta.

Hvala na ispravkama i objasnjenjima.
Ideja sa podformom mi se svidja, mada moram priznati to isprva nisam probao da izvedem. Ova varijanta mi se cinila laganijom i brzom cisto da ustanovim da li mi je kompletna ideja bila dobra. Cini se da jeste, sto je bitno, radi.
Sad cu probati sa podformom da odradim, pa cu prikaciti rezultat.
Mada, nije kraj problema. Naime namece se jos jedan problem. Sustina je u tome sto mi su pojedini parametri ispitivanja zavisni jedni od drugih (kod vecine slucajeva to nije tako, ali ima i izuzetaka koji komplikuju stvar). Na primer ovako:
imam npr. "Tip1" za koje radim parametre

Parametar1
Parametar2
Parametar3
Problem je sto je Parametar3=[Parametar1]+[Parametar2]

Nadam se da si shvatio problem.

Hvala jos jednom na odgovorima, ovo mi puno znaci.

Pozdrav

Evo kako sam ja to resio (na primitivan nacin) sa formom i subformom. Obracun radi, samo nije elegantno resenje.
Molim vas da mi malo korigujete kododove.

Pozdrav

Ako radi, predlazem da se zaustavis gde si. Problem koji resavas u stvari glasi: "kako modelovati u bazi podataka formule sa promenljivim brojem parametara od kojih su neki parametri medjusobno zavisni" To nije tako lako. Svaki problem koji resimo samo ce otvoriti neki novi problem i nikad kraja. Zato predlazem da stanes upravo ovde gde si. Sto se tice medjusobno zavisnih parametara, to ti je kao kalkulisano polje u kveriju. Ako je parametar p3 = p1 + p2 jednostavno nemoj ni da cuvas P3 u tabeli, neka ostane NULL, cuvaj samo p1 i p2 i promeni formulu.

Umesto da formula kaze na primer

R = (p1*3 + sqrt(p2)/p3 , gde je p3 = 9p1+p2)

mozes da je napises kao

R = (p1*3 + sqrt(p2)/(p1 + p2)

I ono sa subformom uzmi sa zrnom soli. Naravno da bih aj to napravio tako, ali ja sam Zidar i ja bih to uradio od samog pocetka, na na kraju kad imam nesto sto radi. Ono sto ti nisam rekao je da bi konverzija ulaznih podataka u EVAL bila komplikovanija i tesko razumljiva i podlozna greskama. Ako nesto zaista treba normalizovati ja to obicno insistiram veoma zestoko ovde na forumu, u nadi da ce onaj na drugoj strani generalno prihvatiti normalizaciju kao metod. U ovom slucaju bi insistiranje na normalizaciji bilo vise dogmatsko nego prakticno. Ti radis neki inzenjerski posao, ispitivanje materijala u nekoj laboratoriji i baze podataka nisu tvoja primarna oblast i struka. Ako nemas vise od 10 mogucih parametara i vec si postavio 30 kontrola na formu (izgleda veoma uredno i lepo) onda ne moras bez preke potrebe da komplikujes zivot.

Nije samo stos strpati parametre u normalizovanu tabelu, stos je smisliti dobar matematicki model za celu pricu, a to nije lako. Onda treba videti kako taj matematicki model moze da se spakuje u relacionu bazu podataka, i to slabasnu, kao sto je Access. Ovo ce verovatno da ukljuci hijerarhije i teoriju grafova a tu accessov SQL nije mnogo jak. A to znaci prepisibanje iz baze u nizove, pa manipulacija nizovima i tako dalje. Da li si spreman za to?

Slazem se s tobom. Kao sto si lepo primetio, tako je, radim u laboratoriji koja se bavbi ispitivanjem hem. sastava i fizickih karakteristika odredjenih materijala. Moj posao je da ekper. vrednosti nekakvih varijabli pretocim u rezultat (najgrubljim recima), stoga je jako bitno da imam lagan i pouzdan mehanizam za mat. izracunavanje. Takodje, jako je bitno da je sve na jednom mestu (da imam tzv. sledljivost vrednosti), i da nema dupliranja podataka (odnosno da razlicite sluzbe ne unose iste podatke). Prakticno, ideja je da se uzorak "proprati" od momenta ulaska u lab. pa do izdavanja izvestaja o ispitivanju krajnjem korisniku usluga.

I za kraj, molim te za odgovor na jos jedno moje pitanje koje glasi. Kako cu iz tabele tblTip da appendujem odredjeni rekord u tabelu tblTip1 ali tako da mi se sa tip rekordom kopiraju i odgovarajuce vrednosti iz podtabela?
Molim te za nekakav primercic

Hvala puno

Pozdrav

Uh, mnogo dilema i trilema. Jedno je sigurno. Na ovom forumu provodim dosta vremena proucavajuci i uceci iz vasih primera. Kod mene to ide jako sporo, obzirom da nisam u toj bransi i da sam jako skucen sa slobodnim vremenom. OD ovih par godina kako pratim ovaj forum, naucio sam mnogo, ali tek sada sam u stanju da shvatim koliko ja ustvari nepoznajem ovu materiju. Potrebno je mnogo zelje, htenja, vremena i volje da bi se ovde napravilo nesto ozbiljno. Ono u sta sam siguran je da vremena imam volje, zelje i htenja (znanja jako malo), vreme mi manjka, ali ga mogu obezbediti. Znaci, da, spreman sam za znatno ozbiljniji rad na ovom polju. Ipak bih da nastavim sa razradom ovog problema dalje i dublje, da pronadjem neko elegantnije i pouzdanije resenje.
E sad, postavlja se pitanje da li je to stvarno nuzno? Pa u sustini nije, ali nije ni ovo dosad bilo (pa mogao sam da vrednosti ukucavam u digitron pa da u bazu upisujem rezultat, pa nije mi ni baza bila potrebna, radio bih kao i do sad )

hvala ti na odgovorima

Pozdrav

Ovo je vec ozbiljno pitanje, iako suvise generalno. Naoko, odgovor je prost - generalno - append query. Sastavis kveri koji ti pokazuje sve ono sto bu hteo da prebacis u ciljanu tabelu. Onda taj kveri pretvoris da bude append kveri, on te pita 'U koju tabelu hoces da append ovo?', ti odgovoris i kad izvrsis kveri podaci odose gde treba.

Medjutim, ozbiljno pitanje je - a zasto bi ti uopste prebacivao podatke iz neke tabele u neku drugu, pa jos i podtabela umesana? Ako se baza podataka postavi dobro, onda nema potrebe za prebacivanjem iz tabele u tabelu.

Ti dakle vrsis neka merenja i ispitivanja materijala. Svako merenje daje neke podatke. U sledecem koraku nesto radis (racunas) sa izmerenim podacima. Kako sad izgleda baza podataka koja prati materijal na prolasku kroz laboratoriju?


Za ovako nesto potrebna je ozbiljna baza. A ne mora da bude komplikovana. Meni izgleda da se posao moze modelovati nekako ovako:

Laboratorija ispituje uzorke.
Uzorci stizu od korisnika usluga.
Na svakom uzorku se moze raditi jedan ili vise eksperimenata (ispitivanja).
Svako ispitivanje daje kao rezultat neke vrednosti (experimentalni podaci)
Na vrednosti dobijene ispitivanjem priemnjuju se zadate formule.
Rezultati formula i sirovi experimentalni podaci se prikazuju na izvestajima.

Sve recenice osim poslednje kazuju koje tabele moras da imas u bazi podataka. Svaka imenica jeste tabela. Svaka recenica u kojoj se pominju imenice koje su ranije definisane u tekstu, moze ali i ne mora da postane vezna tabela. Ovako nekako:

Uzorak =. imaces tabelu Uzorci sa nekim atributima koji opisuju uzorak, naprimer (Uzorak, DatumUzorka, Materijal, KorisnikUsluge)
Korisnik usluga -=> tabela Korisnici, sa nekim atributima, na primer (KorisnikUslughe, Ime, prezime, Adresa, telefon)
Eksperimeti => ovde ti trebaju dve stvari. Prvo, spisak svih eksperimenata koji se mogu arditi u vasoj laboratoriji, ovo dolazi iz nekog pravilnika, (Eksperimet, Materijal). drugio je eksperimet izvresn na konkretnom uzorku. O tome malo kasnije.
Vrednosti koje proizvede exsperimet = za svaki eksperimet pravilnikom je definisano koje ce se velicine dobiti na izlazu, dakle (Eksperiment, Materijal, MerenaVelicina, MernaJedinica)
Eksperimenti izvedeni na konkretnom uzorku: (Uzorak, Materijal, Eksperimet, DatumEksperimeta)
Dobijene vrednosti za izvedene eksperimente na konkretnim uzorcima: (Uzorak, Materijal, Eksperimet, DatumEksperimeta,MerenaVelicina,IzmerenaVrednost)

Ovo sto sam napisoa moze da se nacrta na papiru i to je otprilike to. Nemamo dovoljno detalja o tome sta radis, recenica "radim u laboartoriji" ne govori bas mnogo. Ako tvoja baza podataka izgleda otprilike ovako, onda si OK. A ne izgleda, jer u najmanju ruku nemas dobijene vrednosti u oslednjoj tabeli, ti imas eksperimet i vrednosti u jednoj tabeli (onih 10 merenja). A verovatno ti fali i pravilnik u bazi.

Kad spakujes podatke u tabele, onda mozemo da se bavimo problemom izracunavanja po formulama. U tvom slucaju, poceo si od kraja - od formula, ili si nama pokazao samo taj deo. Zato sam rekao da je mozda vreme da stanes gde si. U protivnom, verovatno ces morati da mnogo toga sto si napravio bacis i krenes iznova, bez garancije da ce to da te negde i odvede.

:-)

OK majstore. Pa evo sta sam ja dosad odradio. Prilozicu uz poruku. Nesto kasnije cu odraditi i objasnjenja prikaza. Kao sto ces videti, jos uvek se nigde ne pominju nikakvi uzorci, nalozi, izvestaji itd... To ce doci tek kasnije.

Pozdrav

Nista ne pomaze, nazivi tabela su suvise kripticni. Pogresan je pristup da 'uzorci, nalozi, - to ce doci kasnije'. Ne moze da dodje kasnije. To je osnova onog sto radis - meris nesto na nekim uzorcima. Prema tome, dve stvari su sustina tvoje baze i tvog posla - sta se meri i uzorci na kojima se to nesto meri. Sta se meri je definisano nekakvim pravilnicima. To se cini da si kao nesto resio, mada ne vidim zasigurno, nazivi tabela i kolona mi ne govore nista. Ako ne uvodis konkretne uzorke u igru, negio te samo interesuje izracunavanje, onda je Excel mnogo bolje resenje.

Moras da imas nesto sto se zove konceptualni model, logicki model - sliku na parcetu papira, koje ces tabele da imas i cemu se one da sluze.
Podaci da dodju kasnije, ali konceptualni model moras da imas. Ti si neki inzenjer i imas inzenejrsku logiku. Moze li da se gradi objekat a da nemas projekat? Model podataka je tvoj idejni projekat. To ti je temelj. Aplikacija i racunanje je nadgradnja. A nadgradnje nema bez solidne osnove - temelja.

OK, evo ga jedan model kako ceo proces ispitivanja izgleda.

Kasnije cu dodatno pojasniti stvari..

Pozdrav

OK, ovo je dobar pocetak. Sad to sto je nacrtano treba da se ispise recenicama, na srpskom jeziku. Za svaku akciju na dijagramu treba dodati ko je sprovodi. Treba napisati na posebnom listu papira za svaku akciju sa dijagrama, sta je input (materijali, dokumenti, pravilnici, propisi) a sta output (dokument, materijal, rezultat). Ako jos dodas koji input stize od koga i koji output ide kome, dobices celu pricu. Vecina procesa sa dijagrama uzima input od prethodnog procesa na dijagrami i svoj output predaje sledecem procesu. Ali, sigurno ima jos inputa i outputa koji nisu ocigledni sa dijagrama, avazni su u praksi. To ti daje pricu o makroprocesu koji tvoja baza podataka treba da podrzi. Tu pricu ti naravno znas, ali nije svrha da se dokumentuje proces zbog samog dokumantovanja. Svrha je da jojs neko razume tvoj posao i da ti pomogne da napravis bazu podataka. Jos ne spominjem aplikaciju nigde, to dodje kasnije.

Svrha je dakle da se iz detaljnog opisa procesa (sta se radi, ko to radi, sta ulazi, sta izlazi i kome se daje) izvuku recenice koje ce ti dati sve entitete umesane u proces i njihove relacije. Iz toga ti slede tabele. Neki entiteti bice tabele, ali i neke relacije medju njima postace tabele. Onda proveris da li tako napravljene tabele zadovoljavaju bar tri normalne forme i popravljas dok ne dobijes nesto u cemu prepoznajes opisani proces, a zadovoljava formalne uslove relacione teorije (normalne forme).

Kad si dobio dijagram baze podataka (tabeel i relacije) onda pogledas u tu sliku i primenis Zidareva pravila za projektovanje aplikacija i dobijes kostur - ono sto ces morati da imas. Negde u toj slici bice i onaj korak kad racunas sta treba da uizracunas na osnovu onoga sto si izmerio u laboratoriji i uneo u bazu. Srecan rad

A sad evo ga i opis aktivnosti celokupnog procesa.

Pozdrav

Zidar, nastavljamo dalje? Vidm, nema te.

Strpljenj malo molim , Zidar ne radi vikendom, a posto se javljam s posla, ponekd me teraju nesto i da radim

Usput ja bas nisam razumeo da ciu ja napraviti sve one stvari koje sam naveo. To je uputsvo kako, a ideja je da ti sam to probas. Dobar ti je opis procesa. Uocio si i neke kljucne reci u recenicama. Sad pokusaj da nacrtas recenice. Kako? Ovako: http://www.csc.lsu.edu/~chen/chen.html
S leve strane imas Papers Download i izaberi peti odozgo, zove se "English Sentence Structure and Entity-Relationship Diagram". Na srpskom se to zove MOV (Model Objekti-Veze) dijagrami ili slicno. U sustini, recenice se crtaju, subjekat i objekat su pravougaonici, kutije, a predikat je linija koja ih spaja. To treba da te dovede do prve iteracije data modela. Obicno je ta prva iteracija veoma dobra, ne treba mnogo da se stigne do zadovoljavajuceg resenja.

Srecan rad

Pretpostavljao sam da ne radis vikendom, to radimo samo mi entuzijasti. OK hvala na pohvali, stvarno dajem sve od sebe. Malo su mi jasnije neke stvari, idemo dalje.
Pogledam link, procitam, probam pa se javim.
Hvala na podrsci, mnogo mi znaci

Pozdrav

Evo ga jedan primer, kako po meni treba da izgledaju tabele i relacije medju njima. Nesto kasnije dacu detaljan opis zasto sam bas ovako postavio. Obzirom da sam bio na putu a tamo nije bilo neta, ovo je cisto pocetak, da se pokrenem sa mrtve tacke.

Pozdrav

Malo je prebrzo za tabele. generalno nije lose ali je strasno nekompletno.
Logicke greske:
- vrsta analize dozvoljava slobodan unos, zar ne psotoji propis koji definise vsrte nalize? Mogu da unesem 'cvrstoca na pritisak' iako se radi o uzorku cokolade i zeli se kolicina secera
- za bilo koju analizu mogu d aunesem bilo koje parametre i primenim bilo koju metodu, mislim mogu da upisem sta god hocu, nist me ne sprecava

Proceduralne greske:
- svaka tabela ima Autonumber. cemu sluzi autonumber/ BAs nista drugo nema da definise red u tabeli?
- dupliranje podataka: tblZapisnik ima ID_Korisnik i Korisnik. Damli su Korisnik i ID_Korisnik u nekoj vezi?
Gadan ovaj Autonumber


Kao sto rekoh, suvise je rano za fizicke tabele. Kad sam te uputio na Pete Chena, nije bilo bez razloga. Iz opisa koji si dao za proces, treba nacrtati logicku shemu baze podataka, pa je onda malo pogledati, proanalizirati i popraviti sta treba. Tek onda ide prva iteracija za fizicke tabele.

OPis procesa koji si dao se moze iskoristiti za planiranej aplikacije. Pogledaj detaljno sve korake i vid u kom koraku koja informacija nastaje. Tada se informacija ima upisati u bazu podataka. U nekim koracima neko treba i da vidi nek informacije. Na tom mestu treba aplikacija da poakze neke poglede podataka ili pripremi stampane izvestaje.

Evo zakacio sam kako ja vidim logicku shemu. To je prva, veoma uopstena iteracija. ti bolje poznajes proces i problem koji resavas, pa ces umeti to bolje da uradis. Tabele koje si napravio nalaze se u opstoj semi, ali ti nedostajku druge. Relaciona shema ne sme da izgleda kao hijerarhija, onda garantovanionesto nedostaje.

Evo ga nekakav pregled zaduzenja (po proceduri), razvrstan po ucesnicima procesa.

Pozdrav

Evo jos malo dodatnih informacija koje ce pojasniti stvari, nadam se

Dobro, prvi opis procesa bio je dobar, ovahj je jos bolji. Medjutim, koja je svrha imati dva opisa koji podjednako dobro opisuju proces? Ideja je da se ovo sto si uradio u drugom opisu, detaljno po ucesnicima, da se to nacrta. Crta se "who does what" dijagram, ili "ko radi sta u ovom procesu". POdeli se list papira na onoliko traka koliko ima ucesnika u procesu. Trake mogu biti vertikalne ili horizontalne, nema veze. Svaki ucesnik u procesu ima svoju traku. U trake se upisuju radnje koje ucesnici u procesu izvrsavaju. Onda se radnje povezu strelicama, koja iz koje dolazi. Radnje s eoznacavaju kutijama, a tacke odlucivanja rombovima ili slicnim oblikom.

Ja sam bio dobar i nacrtao shemu, onako kako sam razumeo opise. Ti svakako bolje razumes dsta si hteo da kazes pa mozes saglasno i da popravis crtez.

Cemu sluzi ovaj crtez:
a) da se lakse vidi ko sta radi ko kome sta predaje (nema veze sa bazama podataka, jos uvek, ali je lepo imati
b) da se zvezdicom oznce radnje na crtezu gde smo zamislili da nako od ucesnika unosi ili cita podatke iz baze podataka

Ako oznacimo zvedicom radnje koje ce imati neku interakciju sa bazom podataka, mozemo da onda dopisemo i detalje pored zvezdica, na primer: u koju tabelu se unose podaci, iz koje tabele (kverija) se izvlaci izvesatj ili pregled). To nam daje ospi izgled SISTEMA koji gradimo. REc SISTEM se odnosi na bazu podataka i SKUP vise aplikacija (programa) koji ce toj bazi da pristupaju. Program koji ce da koristi sekretarica i program koji ce da koristi lekar higijene nisu isti. Za svakog korisnika treba napraviti njegov program, prilagodjen njemu. Ako ima zajednickih elemenata, dobro je da se urade u jednom programu, istetsiraju i primene, pa se onda prenesu u drugi.

Da li je ovo lako da se uradi? Ni najmanje. Isto kao sto nije lako da se uradi alaiza koju vi tamo radite. Da bi vrsio nalizu, covek ide u posebnu skolu ili fakultet. Isto je i sa programiranjem i gradjenjem SISTEMA za pracenje proizvodnih procesa. A ovo sto vi radite jeste proizvodni proces. Vas proizvod je rezultat analize, papir na kome pise sta ste nasli u uzorku da li je uzorak ispravan za ljudsku upotrebu. veoma vazan proizvod i veoma vazan proces. Da li biste dozvolili da tako vazan proces rade priuceni ljudi? Verovatno ne. Zasto onda svi veruju da mogu da grade informacione sisteme, bez ikakve odgovarajuce obuke i iskustva?

Kad stavis zvezdice na crtez, nisi gotov. Onda sledi planiranje i dizajniranje svih tih programa koje treba napisati. Rezultat tog procesa je shema aplikacije, sa svim formasma, dugmicima, kverijima, izvestajima, strukturom izvestaja. Onda s tim ides kod programera i nadas se da ce nesto biti uradjeno. Svaki drugi pristup je osudjen na propast.

BRAVO MAJSTORE!!! Mislim da si zaista dobro predstavio citav proces. U sustini, to jeste to.
Samo imam par napomena, mozda sam ih ranije rekao ali nije zgoreg podsetiti se.
Imamo sledece klijentske pristupne lokacije:

1. Prijemno odeljenje (1 racunar, najverovatnije, mozda i 2)
2. Lekar higijene (1 racunar)
3. Hem. lab. (1 racunar)
4. Mikrobiol. lab. (1 racunar)
5. Finansije (1 racunar)

to bi bila tehnicka podrska.

Bitan momenat, slanje naloga laboratorijama od strane lekara higijene. Pa, po dosadasnjoj praksi, uz uzorak koji ulazi u lab. stize i nalog za ispitivanjem. Znaci deo uzorka ideo u Mikrobiol. lab. sa nalogom za MB lab. dok preostali deo uzorka ide u hem. lab. sa nalogom za hem. lab. Znaci, ukoliko korisnik trazi da se radi i hem i mb (sto je obicno slucaj), lekar higijene kreira dva naloga sa istom sifrom. Do sada su to bila bukvalno dva papira. Sada, mislim da to nema potrebe. Nalog se kreira elektronskim putem.
Isto vazi za Nalog za fakturisanje (kreirace se elektronski)
Takodje, sto se tice zahteva korisnika, od sada cemo beleziti i najnebuloznije zahteve, ipak, i takvi, predstavljaju odlicne statisticke pokazatelje trzista.
Ista prica vazi i za odbijene uzorke (ukoliko su prosli prijem)

Lica - analiticar, lab. tehnicar, sef laboratorije javljaju se u obe laboratorije i tu nema razlike u postupanju sa uzorcima i odgovornoscu.

Toliko za sad.

Ostadoh duzan da ti pokazem sta sam ja odradio do momenta dok nismo ponovo sagledali celu pricu. Mislim da ceo sistem treba da ima neku vrstu sifrarnika, gde bi se tacno definisali svi parametri.

Mozda odavde proistekne neka ideja.

Pozdrav

Mislim da me ne razumes. Niam ja taj koji ce da pravi sistem. Ja ti samo dajem savete kako se u principu ovo radi, a koje ti odlucio da ignorises. Prvo sam ti rekao da napravis bazu podataka kako valja. Poslao si nekompletno resenje. Onda si napravio ostatak baze, ne vezujuci je za prvi deo i sagradio aplikaciju. Nisam ti to rekao, ali nigde ne pise da moras da me slusas.

Najnoviju bazu koju si napravio nis pravio po postupku koji sam ti predlozio. Dijagrame sam crtao ja, ne vidim da si ih usavrsio, niti dijagram baze podataka niti dijagram procesa. Ali si zato pozurio i napravio 'aplikaciju'. Ako ti kazem da to sto si uraduio nece raditi kako valja, razocaraces se, pa bolje da cutim, ionako neces poslusati. Da si radio po savetima, izbegli bi mnogo nepotrebnog posla. Ovako, sad prvo mora da se ispravi sta si izbrljao, pa da se mozda nastavi. ja za to nemam vremena.

Srecan rad

Oh, polako majstore. Pogresno si me razumeo. Naravno da nisam ni mislio da mi ti pravis sistem (da sam to hteo, angazovao bih te i platio ti uslugu). Ovih nekoliko zadnjih postova koje sam poslao, trudio sam se da saljem bilo kakve dodatne info koje bi pogle da se bolje sagleda ceo proces. Kao sto sam ranije rekao, mislim da si odlicno sagledao citav proces, ali po meni, uvek ima nekih dodatnih info koje mogu da budu korisne.
U tu svrhu, u zadnjem postu, poslao sam nekakvu aplikaciju koji sum radio do momenta dok te nisam kontaktirao. Pa naravno da ona ne radi kako treba, ne bih te ni kontaktirao u suprotnom, ali mozda moze da pruzi iole nesto korisno, nekakvu ideju mozda, nista vise.Samo iz tog razloga sam je zakacio. Nisam ni ocekivao da ces oko nje da se bavis.
Molim te, bez ljutnje, stvarno se trudim da dam svoj maksimum. Silno vreme smo utrosili i ti i ja, steta je da ovo sad napustimo.

Pozdrav

Ja se izvinjavam, bio sam preostar, nepotrebno. Dodje to s godinama, ali to nije razlog da se bude neprijatan. Moja greska.

Uradio si nesto dakle ranije, stekao nekakvo iskustvo, to je OK. Sad imas priliku da uradis to valjano. Nacrtaj svoje dijagrame za proces i za bazu podataka. Onda nam to ili pokazi pa da vidimo da li iam detalaj koji se trebaju popravljati u delu sa bazom podataka. Dijagram procesa ne mozemo da popravljamo, to mozes ti, ali ako nam prilozis i proces uz dijagram baze (moze iAccess tabele), mozda nesto uocimo pa popravimo.

Rano ti je u ovom moemntu za ideje o 'kako treba da izgleda aplikacija'. Prvo da vidimo na diajgramu procesa gde je sve potrebana interakcija s podacima. Gde se ocejkuje unos u tabele, a gd se ocekuej citanje iz tabela. Onda cemo da vidimo da li treba sve staviti u jednu aplikaciju, pa svko izabere sa glavnog meniaj dugme koje ga vodi gde mu treba, ili svako ima svoju aplikaciju koju koristi. tehnicar na priejmu ima jednu potrebu, lekar drugu, a sef laboratorije i analiticar imaju trecu potrebu. Tehnicar u laboratoriji ima neku trecu potrebu, a i sekretarica moze da ima potrebu za necim iz baze ili aplikacije.

Uh, pa mozda bih i ja trebalo da se izvinem sto se nisam vise udubio u celu pricu i tako ti tracio vreme. OK, idemo dalje.
Da budem iskren, nakon tvojih opaski, latio posla i ceo dan posmatram onaj logicki model procesa koji si kreirao nesto ranije. Jos uvek je to za mene velika zbrka, igra reci i formulacija recenica itd. Ali mislim da sam nesto pametno iskopao pa te molim da pogledas ovaj WORD dokument i das svoj sud. Izneo sam neke predloge koji, moguce je, i nisu ispravni ali cini mi se da vredi pogledati, te stoga se jos ne upustam u kreiranje modela konkretnih tabela, mada su vecinom vidljive.

Hvala na strpljenju

Pozdrav

Ovo je vec bolje. Moj opis procesa ne moze da bude bas tacan, zato stalno ponavljam da moras da uradis svoje dijagrame.
Iz dijagrama koji si dao vidim:

1) analiza se radi na uzorku koji je doneo korisnik.
2) uzorak se nekako kategorizuje (tipizira) i za svaki tip uzorka odredjuju se propisani parametri, po definisanim metodama.
3) Kada se na parametar uzorka primeni odredjena metoda, dobiju se neke varijable.
4) na uzorku se mere neke konkretne vrednosti i to ulazi u rezultate analize

Ne vidim jaku vezu izmedju onog sto zoves 'konkretni parametri' i ( 'propisani parametri' i 'varijable'). cemu odgovaraju konkretni parametri, propisanim parametrima ili varijablama koje se mere? A mozda fali neka kutijica na slici?

Ne umem da ubacim sliku u poruku pa sam pripremio 2 PDF fajla. Prvi, LAb_Z.PDF pokazuje sliku koju si ti dao, sa malo drugacije poredjanim objektima. Sve veze su onakve kako si ti napravio.

Drugi fajl je moj pokusaj da odgovorim na pitanje "u kakvoj su vezi mereni rezultati i propisi - da li meris varijable koje su definisane u propisima ili sta?". Nesto mora da ti kontrolise sta meris za koji tip uzorka. Ako ti je tip uzorka voda ne mozes da meris cvrstocu na zatezanje. Ako ti je uzorak cement, verovatno ne meris uglene hidrate i masti.

Dopuni dakle ovaj dijagram pa mozemo dalje - da napravimo prvi pokusaj prevodjena dijagrama objekti veze u tabele.

Dugujes jos jedan dijagram - kartu procesa sa zvezdicama na mestima gde se ockuje interakcija sa bazom.

Kad imamo tabele i dijagram procesa, onda svakoj zvesdici dodelimo tabelu u koju se unose podaci i/ili iz koje se citaju podaci. I eto nam osnove za aplikacije (mnozina)

Onda mzoemo svaku zvezdicu (tacku interakcije korisnika s bazom) da naliziramo detaljno, to ce nam dati uslove za radionicki crtez svakog programa ponaosob. programi ce se sastojati iz formi, kverija, izvestaja. Naravno da treba dalje svaku formu, kveri, izvestaj definisati. Tek posle ovog koraka mozes da pocnes da pises programski kod i pravis forme i reporte. Upozorio sam te na pocetku da je posao dug i mukotrpan i ima mnogo da se radi pre nego sto se dodje do konkretnog programiranja.
[img]Terminologija_Z.pdf
[/img]

Nadam se da si jos na mrezi. Molim te da mi ponovo posaljes ova dva pdf. fajla. Uopste ne vidim pravougaonike i rombove kao ni linije, samo vidim teks, pa ne mogu dobro da procenim model.

I odmah da probam da ti odgovorim na pitanje:
Zakon i Pravilnici o kvalitetu su ti u kojima se prave tipovi (ili kategorije) namirnica ili predmeta opste upotrebe ili bilo cega drugog
Tako na primer:

- krema za ruke, krema za lice, puder, ili karmin ili ono rumenilo (ili kako se vec zove) sve su to proizvodi svrstani u tip "sredstva koja duze vreme ostaju na kozi" a Pravilnik o zdravstv. ispr. predmeta opste upotrebe (Sl.list SFRJ br. 26/83) to definise. U tom tipu proizvoda, isti PRavilnik propisuje da se odredjuju sledeci parametri (ucio si nekad hemiji):
-Pb
-Cd
-Cr
-Ni
-As
-Hg

i da su dozvoljene vrednosti tih parametara (lupam ove vrednosti, ne znam ih napamet) i njihove jedinice mere

-max. 20 mg/kg
-max. 2 mg/kg
-max 50 mg/kg
-max 50 mg/kg
-max 5 mg/kg
-max 2 mg/kg

Takodje, jedan drugi Pravilnik propisuje metodu po kojoj se ovi parametri odredjuju u datom tipu uzorka (proizvoda).

Laboratorije mogu da koriste i druge metode (ne vezano od Pravilnika). Koriste se standardne metode (JUS, ISO, BS, ASTM, EPA, AWWA itd.), modifikovane standardne metode ili inerne metode kuce.
No, pricu oko meoda nebih sirio dalje. Isuvise je kompleksna.

Ma najbolje je da pogledas ipak onu moju aplikaciju koju si kritikovao. Mislim da ce ti biti malko jasnije. Samo, nemoj da gledas resenja software-a i koncepciju baze vec gledaj kako sam klasifikovao proizvode. Ima tamo na startup formi cmdbutton "kopiraj tip". Pa preko njega se ubaca novi proizvod na osnovu starog proizvoda a aoba pripadaju istom tipu proizvoda. Isti tip, karakterisu isti parametri, mogu se samo razlikovati njihove propisane vrednosti.


_{[Ovu poruku je menjao zliki dana 30.10.2008. u 18:26 GMT+1]}

OK, promenio sam format, nije PDF nego je dsada PNG. Nadam se da ce da radi.

Sto se tice pitanja, nije vazno da razumem kako se uzorci i amterijali tipiziraju (klasifikuju). To je OK deo. Ono sto sam pitao jeste;

Na shemi vidim da ce svaki uzorak koji se donese biti svrstan u neki tip. To je OK.
Vidim i da za uzorak postoji nesto sto se zove 'Konkretni parametri' i vezano je za Uzorak.

Uzorak ce postati tabela, im joj je Uzorci. tabela Uzorci imace kolonu 'Tip' koja ce uzimati vrednosti iz tabele TipoviUzorka. Postojace i tabela KonkretniParametri, koja ce imati kolone Uzorak i Parametar i KonkretnaVrednost. To je sve OK.

Sta ne vidim jeste odakle dolaze vrednsti za kolonu Paramtar u tabeli KonkretniParametri. Ja ZNAM i ti ZNAS da to dolazi negde iz pravilnika, koji ce biti predstavljen tabelom PropisaniParametri (TipUzorka, Parametar). Ja znam da se za materijal 'kremu za ruke' odredjuju olovo (Pb), kadmijum (Cd) i hrom (Cr). E, ne postoji nists u shemi sto ce me spreciti da unesem recimo parametar 'cvrstoca na savijanje' u tabelu KonkretniParametri.

U shemi mora da postoji nesto sto ce da kaze 'ako je tip uzorka = ""sredstva koja duze vreme ostaju na kozi" onda se u tabelu KonkretniParametri mogu unesti samo vrednosti gde je naziv parametra iz skupa (Pb, Cd, Cr,Ni, As, Hg). To sto ti znas i znas sta treba uraditi, mora da zna i baza podataka.

Mislim da razumem i sta su varijable. U aplikaciji koju sam kritikovao, mnogo su vrednije tabele. Iz tabele SifranikParametri, za IdParam = 5, ID_Tip = 2, naziv = Voda, Naziv_Pun = sdrzaj vode, imas varijable Masa punog suda, masa praznog suda, masa osusenog suda, i to sve dva puta, pa to se unese u formulu i formula da jedan broj, koji je konkretna vrednost za parametar 'Sadrzaj vode' za konkretan uzorak. Ako zelis da zapsujes negde vrednosti varijabli koje ulaze u proracun parametara, imaces razlicitu shemu od one koju imamo. Sifranici nece moci da se organizuju kao jedna tabela. bar dve a mozda i vise je potrebno, ako hoces da baza bude korektno napravljena. Da li je baza korektno napravlejna, kazace nam proces normalizacije. To je konfuzan proces i zelim da ga pojednostavim maksimalno, a jedan od nacina je da se nacrta shema objekata i veza i da se to pretvori u shemu tabela. Teorijski, a i iz iskustva, takva shema tabela je veoma blizu da ispunjava pravila normalizacije.

Ato insistiram na ovom delu. Ako se ovaj deo iskarabuzi, ne vredi raditi aplikaciju jer se kuca ne pravi od krova nego od temelja. Krov bez temelja zove se nadstresnica ili sator u najboljem slucaju. Ponekd, i za krace vreme, u nuzdi, moze da se zivi i u satoru, ali na duzi rok to neide, jel' da?

To sam pokusao da uradim u crtezu u terminologija_2.png

Pa, mislim da bi bilo neophodno da se vrednosti varijabli upisuju u bazu da bih imao sledljivost do rezultata ispitivanja. Osim toga, Radna lista laboratorije je i zamisljena da se u nju popunjavaju vrednosti varijabli za svaki pojedinacni parametar. (to se zaista i radi svakodnevno). Nisam ni sumnjao da ce sifrarnici biti vrlo komplikovani. Po mom misljenju, organizacija sifrarnika je kljucna za ceo sistem.

Pogledao sam tvoju zadnju semu, mislim da je ok. Drago mi je da lagano ulazis u sustinu procesa rada laboratorije.
Obzirom da je danas petak, imam dva naredna dana da probam da odradim nesto ozbiljnije. Hteo bih, ukoliko nam podje za rukon, da zakljucno sa danasnjim danom zaokruzimo pricu oko sheme procesa, osecam da smo blizu, pa da probam, tokom vikenda, da odradim sledeci korak (mislim da znam koji je ali necu da trcim, molim te da mi das neke smernice).
Drago mi je sto insistiras da se ove uvodne radnje stvarno odrade kako treba, to mi mnogo znaci, steci cu stvarno sveobuhvatnu sliku o procesu projektovanja i izrade jednog sistema.


Pozdrav




_{[Ovu poruku je menjao zliki dana 31.10.2008. u 12:25 GMT+1]}

E bas mi je drago :-) medjutim, svrha ove diskusije nije da ja razuemem sustinu procesa rada laboratorije. Sustina je da ti razumes sustinu procesa izrade sheme baze podataka na osnovu opisa procesa. Mozda i uspemo u tome, samo ako ne zuris. Jos je rano za 'nesto ozbiljnije', pogotovo ako to 'nesto ozbiljnije' zamislajs da bude nekakav kostur programa. Za to jos absolutno nisi spreman i ne gubi vreme. Razumem tvoje uzbudjenje, ali te molim d abudes strpljiv jos koji dan.

Da pokazem kako ovaj rad jos nije u fazi za nesto ozbiljno, dajem novu shemu.

OK, ne zurim.
Video sam semu. Mislim da to jeste to definitivno.

Sta sad?

Tako je i prethodna izgledala 'definitivna' OK, i meni s ecini da je blize. Sad shemu pretvaramo u tabele.

Imamo dakle shemu Terminologija_3. Strelice na shemi pokazuju smer citanja recenica koje smo zapisali na shemi. Dodao sam ono od cedga smo poceli - formule u koje se ubacuju izmerene varijable da bi formule dale konkretne vrednosti parametara.

Nisam upisao kardinalnost, sta je na strani 1 a sta na strani vise. Generalno, na pocetku strelice je strana 1 a na kraju je strana 0, 1 ili vise, zavisno od situacije. Ni ova sehma nije finalna, ali je blizu. Blizu u smislu da sto je na shemi ne ocekujem da se promeni. Nije finalna jer nije sbeve na shemi sto imamo u dijagramu procesa. Nema lekara koji overava dokumente, niti analiticara/sefa labopratorije koji overava dokumenta. A nedostaje i sekeretarica. Vidis sta sve nedostaje......



Da se dogovorimo oko nekih pravila:
1) Imena tabele bice imenice u mnozini, recimo s aprefixom tbl. Dakle, tblKorisnici, tblZahtevi, tblUzorci i slicno. Ako ce baza biti u SQL ne mora tbl.
2) Necemo koristiti Autonumber za PK ako bas ne moramo
3) prenosicemo ceo PK iz roditelj tabela u child tabele (Ovo je zato sto pravimo jos uvek konceptualni model, logicki model. Za fizicku impelmentaciju mozda i prihvatimo poneki autonumber i ponesto skratimo.)


Prevodjenje se radi tako sto sve kutije na shemi postaju tabele, i neki od rombova, videcemo koji, ako zatreba. U ovom momentu tabele su imaginarne, jos ih ne kreiramo u Accessu. Jos uvek su samo kutije na nekoj shemi ili

U prvom koraku, svaka tabela treba da ima samo jednu ili dve kolone, koliko za PK.

Ja cu da pretpostavim da uzorke mogu doneti samo registrovani korisnici. Ako neko sa ulice useta i donese flasicu sa vodom, a nije registrovan korisnik, morace da se registruje, pa tek onda da se primi uzorak. Ovo je OK ako je vecina korisnika registrovana i redovno dolaze da traze ispitivanja. Ako nije tako, onda mozda i ne treba tabela Korisnici. ja cu da produzim kao da treba.

Ako je tabela tblKorisnici, neka ima samo jednu kolonu, Korisnik (nemoj da dodajes ono ID, dovoljno je korisnik). Ako je tabela tblZahtevi, iamces verovano neki delovodni broj zahteva, to vec imas u nekoj knjizi, pa uzmi to ime. recio, BrojZahteva. Zahtev se otvara za odredjenog korisnika, pa dodajemo i kolonu Korisnik, dakle:

tblKorisnici (Korisnik, PK)
tblZahtevi(BrojZahteva PK, Korisnik NOT NULL REFERENCES tblKorisnici.Korisnik) Rec REFERENCES znaci da ce se postaviti relacija sa tabele tblKorisnici na tabelu tblZahtevi.

Uz svaki zahtev moze da dodje jedan ili vise uzoraka pa dobijamo tblUzorci (BrojZahteva, BrojUzorka) U prvom koraku moramo da dodelimo uzorku TipUzorka, uzorak ne moze da postoji bez tipa, pa imamo dakle tblUzorci (BrojZahteva PK, BrojUzorka PK, TipUzorka NOT NULL) Ovo je absolutni minimum kolona koje moramo da definisemo. Posle cemo da dodajemo gde nam jos sta treba. Bolje je nesto zaboraviti, nego trpati kolone bez razmisljanja. Proci cemo kroz model jos nekoliko puta dok ne bude spremno za fizicku izradu tabela. Ovo mora ovako jer ucis postupak. Ako ne ucis postupak, onda ispada da ti ja pravim model i to ce momentalno da se zaustavi.

Sad moram da radim nesto, ja sam ipak na poslu ;-) pa mozes da nastavis sam. Parti strelice na shemi i tim redom pokusaj da napravis tabele. prenosi PK iz starije tabele u sledecu, da ne bi zigubio logiku. Pokusaj, ne moras da uapes. Onda mozes tabele da nacrtas, Visio je dobar alat za to, a moze i POwrPoint. Moze i Access. Access u ovoj fazi nije preporucljiv, jer Access zahteva da se znaju tipovi podataka, koje mi jos uvek ni ne spominjemo. Za sada baratamo samo pojmovima, idejama, nazivima kolona. Sat ce one fizicki biti, nevazno je u ovom momentu. Sad se fokusiramo da npravimo kostur baze - osnovne tabele i njihove relacija (PK - primay key, FK - Foreign Key = ono sto u Accesu zovu 'relacije medju tabelama')

Tvoj je zadatak za preko vikenda, da od sheme Terminologija_4 napravis kostur baze podataka, kao logicki model. Posle ces videti kako ce aplikacija sama od sebe da proizidje iz baze podataka. Mislim da ces moci da lako resis deo sa pravilnicima: tip uzorka ima parametra, parametar ima metode, metode imaju varijable i jednu ili vise formula (ti znas, je ne)

Ako je uzorak odredjenog tipa, onda moze imati rezultate samo za one parametre koje su definisane za dati tip. Parametri ce biti ozracunati formulama i varijablama koje se definisu za taj tip. Ovaj deo mozes da probas pa da vidimo u ponedeljak. Ocekujem dakle generalnu shemu tabela sa minimalnim brojem kolona. Onda u ponedeljak to mozemo da pogledamo, prokomentarisemi i mzoda ispravimo. Ond alsedi dodavanje ostalih kolona. Pa onda malo testiramo logiku, pa ond afizicki kreiramo tabela. E onda tek moze aplikacija.

Srecan rad



_{[Ovu poruku je menjao Zidar dana 31.10.2008. u 18:54 GMT+1]}

Evo mog pokusaja.

Izgleda da si lepo preveo model Terminologija-4 u tabele, prvi korak. Medjutim, u modelu je bila jedna greska. Tabela Formule se ne nalazi gde bi trebalo. Trebalo bi da bude:
1) Metoda ima formulu (jednu ili vsie, pitanje za tebe).
2) Formaula koristi varijable (barem jednu, uglavnom vise)
Kad se varijable ubace u formulu, dobijemo vrednost parametra.

Ako je jedna formula po metodi, onda ne treba uopste tabela za formule. Ako je vise, ond atreba da bude Metoda roditelj a formule (mnozina) da budu deca, a svaka formula da ima svoj skup varijabli (jedna ili vise

Razresi ovo, pa mozemo dalje. Ono sto odmah vidim je:
- ne vidi se u tabeli Uzorci kojoj laboratoriji je dodeljen uzorak,. Ako postoji veza sa LAB na Uzorci, onda je Lab FK za Uzorci i moar se kolona LAb pojaviti u atbeli Uzorci (bas kao sto sis tavio TipUzorka). Isto s eodnosi na vezu lab - Rezultat

- veza Uzorci - Konkretni parametri ne ogranicava konkretan parametar na tip uzorka. ip uzorka moze da bude 'voda' a u konkretne parametre mogu da se unesu 'cvrstoca na zatezanje' i 'cvrstoca na savijanje'. Treba Tip uzorka spustiti u tabelu Konkretni parametri.

Ovo se sve desava jer nisi definisao PK u tabelama jasno i nis ga preneo n child tabele, genralno. I na desnoj starni, gde su pravilnici, ispada da varivabla zavsii od metode sto nije tacno. Varijabla zavisi od para (metoda, parametar). Svaka metoda ima jedan ili vise parametara, a svaki od tih parametara ima svoje varijable. To mora da bude reflektovano na shemi. Najlakse se to postize tako sto s ePK iz parent tabele prenosi u Child tabeliu, kao FK.

Probaj da ispravis navedene greske. na shemi ti ne vidim nazive tabela i envidim koje su kolone PK a koje su FK. To ti je enposredni zadatak.

Posle toga cemo dodati i ostale atribute, koji nisu PK niti FK.

Evo, probao sam. Ovako mi je bilo lakse da nacrtam, ne moj da se obazires sto je radjeno u accessu. Ne trcim, samo mi je bilo lakse za crtanje. A i verovatno, nisam sve odradio kako treba.

Pozdrav

Vrlo dobro. Da te en mucim dalje, evo ti model koji je jako blizu onoga sto ti treba. Bice jos zackoljica, ali glavne stvari su tu. amlo sam prepravio tabele. Nisi me razumeo kad sam kazao 'treba prenositi PK iz parent u child tabele', ali nema veze. Ti si strucnjak za rad laboratorije, a ovo drugo je nkog drugog posao.

Elem, ovako:

Pocetak rada:
1. Korisnik podnosi zahetv i upisujemo zahtev u knjigu (tabelu)
2. Uz zahtev stize uzorak, pre ili kasnije. Onaj deo gde sef laboratorije organizuje uzorkovanje, potpuno je izbacen iz modela. isto tako i overavanje i potpisivanje izvestaja. To je izbaceno.
3. Uzorak pripada nekom tipu uzoraka. I to cemo da upisemo u tabelu tblUzorci uz BrojUzorka.
4. iz slike ispada da cemo svaki uzorak dodeliti tacno jednoj laboratoriji (Ako nije tacno, eto zackoljice. Voda moze i hemijsku i u mikrobiolosku laboratoriju. Sta onda?)

5. Evo je strana sa pravilnicima:
5a) za svaki tip uzorka odredjuju se neki parametri.
5b) parametri se odredjuju po nekakvim metodama
5c) da bi se dobila vrednost parametra, mere se varijable
5d) varijable se ubacuju u formulu, rezultat je konkretna vrednost parametra i to se cuva u tabeli

6. Konkretni rezultati:
6a)Za svaki uzorak, ispituju se parametri koji odgovarajun tipu tog uzorka.
6b) Konkretni parametri mogu se ispitivati samo proisanim metodama
6c) tako sto se mere vrednosti za varijable koje odgovaraju toj metodi,
6d) varijable se ubacuju u formulu, rezultat je konkretna vrednost parametra i to se cuva u tabeli

Primeti da je 5d) i 6d) identicna recenica. Ako imamo formule, onda teorijski ni ne moramo da cuvamo u tabeli rezultate formule koja je f(var₁, var₂,...Var_n). To moze da nam vrati kveri. teorijski, da, ali u praksi mi ipak izracunamo nekako rezultate formula i onda ih cuvamo u tabeli tblKonkretniParametri.

Potpuno je eliminisana tabela tblRexzultati. Sta su rezultati ispitivanja amterijala? Nista drugo nego konkretne vrednosti nekih parametara koje smo odredjivali za dati uzorak. proizilazi da je nasa tabela tblKonkretniParametri ujedno i tabela rezultata. Ako nas interesuje ko je i kada overio/kontrolisao ispitivanje i dao misljenej o ispravnosi vode, to nekako mozemo da povezemo sa ovom tabelom ili sa samim uzorkom i gotovo. Ovo je poslednji logicki problem, uz onaj sa dodeljivanjem uzorka laboratoriji (jednoj ili vise). Kad to razresimo, nas modekl je spreman za sledeci korak - konkretizacija atributa (datumi, opisi, ko je radio, kada, ko je potpisoa i slicno)

Da bi bili sigurni da je sve OK, igracemo se malo sa modelom posle dodavanja atributa. probacemo rucno da unesemo nesto podataka i da simuliramo relane situacije. ako, dosao neki Zika i doneo uzorak. Sta se desava sa uzorkom i akko se to odrazava na nasu abzu podataka, sta se gde unosi u kom momentu. To ce nam otkriti ako ima falinki. Ako taj tets prodjemo bez problema ili ispravimo sta vidimo, vrlo je verovatno da ce aplikacija biti korektno napravljena. Ima metod kako se sa sheme baze podfataka prelazi na shemu aplikacije, sve u svoje vreme. To ti je cuveni Zidarev metod koji niko osim njega ne koristi, jer niko ni ne zna da metod postoji, iako metod gotovo uvek pali.

Pre nego sto se bacimo na testiranje, mislim da je vreme da malo zakomplikujem stvari (nisam hteo ranije to da radim dok ne udarimo neke osnove, mislim da je sada pravo vreme).

Prvo, da razmotrimo pricu oko zahteva korisnika. Imamo dve varijante:
1) Korisnik zahteva analizu i sa sobom poneo uzorak - Postupak: ukoliko korisnik nije sam sacinio pisani zahtev, popunjava se nas interni obrazac zahteva za ispitivanjem na kome se naglasava da je korisnik sam doneo uzorak (upisuju se podaci o uzorku).
2) Korsnik zahteva analizu - Postupak: ukoliko nije sam sacinio zahtev, popunjava se interni obrazac zahtev za ispitivanjem. Organizuje se uzorkovanje i sacinjava se Zapisnik o uzorkovanju.

Po vazecoj proceduri, prvi u nizu nternih obrazaca je Zapisnik o uzorkovanju i on, kao takav, ima svoju nedvosmislenu sifru.
Zahtev za ispitivanjem moze biti dokument u slobodnoj formi (korisnik ga donosi popunjen) ili pak u definisanoj formi (nas interni definisani obrazac), te kao takav, nema svoj definisani broj. Kada lab primi zahtev, to ne znaci da ce doci do ispitivanja (zahtev se odbija)
Kako je nas zadatak da evidentiramo i najdebilniji zahtev (da kazem najneobicniji), atribut BrojZahteva treba da ostane, te treba uvesti nov atribut - razlog odbijanja, ukoliko dodje do odbijanja zahteva).

Zapisnik o uzorkovanju:

E ovde se prica malo komplikuje. Naime, zaapisnik o uzorkovanu je interni definisani obrazac kuce ciji sadrzaj (atributi) zavisi od VRSTE UZORKA. Posto je definisani obrazac, on ima svoju nedvosmislenu sifru (koja zavisi od vrste uzorka).

Evo o cemu se radi:

Naime, svi uzorci koji stizu u lab mogu se svrstati u nekoliko definisanih vrsta uzorka. To su:

- Namirnice (Hem i/ili MB)
- Vode za pice (Hem i/ili MB)
- Predmeti opste upotrebe (Hem i/ili MB)
- Otpadne vode (Hem i/ili MB)
- Mineralne vode (Hem i/ili MB)
- Recne vode (Hem i/ili MB)
- Kaloraze (Hem i/ili MB)
- Imisija vazduha (Hem)
- Aerosediment (Hem i/ili MB)
- Zemljiste (Hem)
- Otpadni materijali (Hem i/ili MB)
- Brisevi (MB)
- Emulzije (MB)

Na jednom zapisniku se beleze podaci samo o jednoj vrsti uzorka. Pa na pr. ukoliko uzorkujem 3 vode za pice pisacu ih na jednom zapisniku, a ako uzorkujem i dve namirnice, onda cu pisati na sledecem itd.

Sifra zapisnika o uzorkovanju zavisi od vrste uzorka (za svaku vrstu uzorka krece od jedinice za prvi zapisnik u toj godini) i obavezno sadrzi prefiks vrste uzorka kojoj dati uzorak pripada (Detaljno uputstvo za oznacavanje uzoraka dacu kasnije kada se dogovorimo).

Da zakljucim:

- Zahtev za ispitivanjem moze biti u proizvoljnoj formi ali svakako ga treba evidentirati i dodeliti mu sifru
- Zapisnik o uzorkovanju je definisan obrazac (dokument) koji sadrzi svoju nedvosmislenu sifru koja zavisi od vrste uzorka

Iz svega recenog, pretpostavljam da cemo mrati malo da korigujemo model baze i dodamo par tabela.

Nisam hteo da previse zakomplikujem pricu na pocetku, hteo sam zaista da idemo korak po korak. Cela prica jeste zaista kompleksna i zahtevna.
Bice jos mnogo mnogo dodatnih informacija.

Toliko za sada

Pozdrav

Naravno, iz svega gore recenog, namece se prakticno pitanje.
Da li je pametnije da se urade za zasebne baze za stvaku od navedenih vrsta uzoraka ili da to bude u jednoj bazi?
Takodje, znatne komplikacije (mozda i ne) ocekujem kasnije oko kreiranja izvestaja o ispitivanju, ali otom potom, trudicu se da ih na vreme predocim.

Vazi. Primedbe su ti na mestu. To smo i imali na pocetku u opisu procesa, ali sam to izbacio iz inicijalnog modela. Priemtio sid a nedostaje, znaci da pratis sta se desava i znas sta hoces. To je dobro.

Ajdemo jedno po jedno:


A) pisani zahtev ili interni obrazac
Bazi je nebitno da li postoji gotov pisani zahtev ili se popunjava obrazaxc na licu mesta. Ako postoji opisani zahtev i korisnik ga je doneo, nije lose da se taj zahtev sacuva negde u bazi. Skenira se i graficki fajl se cuva u bazi, ili bar filaname i path. A moze da se cuva u bazi i nekakv delovodni broj pod kojim se zavodi taj pisani zahtev u knjizi poste. Ja sam nekad radio u jednom vodovodu koji je iamo laboratoriju. Dolazili su ljudi i donosili uzorke bunarske vode ili iz lokalnih vodovoda, nepovezanih na nas sistem. Svi ti zahtevi nisu izli direktno u laboratoriju, nego u nekakvu prijemnu sluzbu koja je sve to zavodila kao postu i stavljala u fascikle i ormane. Kad se tako psoat zevede, dodeli se broj i zapise u gornejm desnom uglu, onda tek papir moze da ide u laboratoriju, a u knjizi poste se zapise da je papir otisao u laboratoriju. Tamo laboratorija zavede zahtev u svoju knjigu zahteva (nasa tabela ZahteviZaISpitivanje)m kopira ili prepise intersantne podatke sa originalnog lista i onda originalni list vrati sluzbi koja arhivira postu. kad se napravi analiza i spremni su rezulatti i 'misljenej o ispravnosti' onda se sva ta piama proslede opet arhivnoj sluzbi koja ih zavede sa 'pozivom na broj originalnog zahteva', spakuje u kovertu, zalepi marku i posalje korisniku. elem, ako na originalnom zahtevu postoji neki broj, treba ga upisati kao dodatni atribut. Moze se upisati i 'tip broja' = (broj postojeceg zahteva, broj internog obrasca). Tu cemo imati mali sukob sa normalnim formama, jer ce taj 'tip broja' zavisiti ne samo od PK za tabelu nego i samog broja, ali o tom potom, nije tako starsno ovo narusavanje tamo neke normalne forme, ali c izazvati probleme u programiranju. Rekoh, o tom potom, da ne detaljisemo sada, rano je, dovoljno je da se zna i da se ne zaboravi kasnije.

B) korisnik doneo uzorak vs. nije doneo uzorak
Postojeci model dozvoljava da se registruje zahtev a da uzorak ne mora da psotioji. Kardinalnostrelacije Zahtevi : Uzorci = 1: (0 ili X, X>=1) Ona nula na desnoj strani zanci 'moze postojati zahtev a da nema uzorka'. bez da uradimo ista, to mozemo d apostignemo dodavnajm atrinuta DatumZahteva u tabelu Zahtevi atributa DatumUzorka u tabelu Uzorci. Ako nam se DatumZahteva razlikuje od DatumUzorka, znaci da uzorak niej donesen uz zahtev. Ako nas interesuje koji zahtevi nemaju uzorke u datom momantu, dovoljno je raditi 'unmatched query' koji vraca 'zahteve koji nemaju ni ejdan uzorak'.
Postojeci model ne pominje zahtev za uzorkovanje. Zahtev za uzorkovanje sledi iz zahteva za ispitivanje. Ako se dozvoljava najvise jedan zahtev za uzorkovanje po zahtevu za ispitivanje, mogli bi da tu informaciju smestimo nekako u tabelu Zahtevi(za ispitivanje). Vidis, mozda bi trebalo d apreimenujemo tabelu u 'tblZahteizaIspitivanje', bila bi jasnija shema baze podataka. Medjutim, jedan zahtev za ispitivanje mzoe pokrivati vise uzoraka, pa ce nam svakako trebati neko dodatno mesto. Ja predlazem da u table ZahteviZaIspitivanje ni ne spominjemo uzorak, da li ga ima ili nema, niti zahtev za uzorkovanje. Dodajmo jos jednu tabelu ZaahteviZaUzorkovanje. ZahteviZAUzorkovanej bi imao FK na tabelu ZahteviZaIspitivanje. Dalje bi isle tabele koje prate postupak uzorkovanja koji sprovodi laboratorija. To je nekako nevazana grana glavne sheme baze podataka. Zasto? Pa kad jednom dobijes uzorak, u principu te ne interesuje kako si do njega dosao. Tvoj glavni posao je ispitivanje uzoraka. sad, slatka je para i od uzorkovanja, ali politika moze da se promeni pa firma akze 'zahtev bez usorka se ne prima' i preporuci korisniku da se obrati firmi 'Uzorak Eng' koja se bavi uzorkovanjem. korisniku je svejedno kome ce da plati, ali ako firmu 'zorak Eng' poseduje i vodi svastika sefa laboratorije, nije svejedno sefu laboratorije A nasoj bazi opet svejedno. parvi posao pocinje tek kad s uzorka donese, be zobzira na to ko je uzeo uzorak. Podrazumeva se da je uzorak uzet u svakom slucaju na korektan nacin.

Drugo pitanje
U principu, ovo je lako. Isprogramira se pravilo za oznacavanje sifre uzorka i gotovo. Ako s epravilo nekad promeni, promeni se i deo programa koji to radi. Novo pravilo ne bi smelo da narusi jedinstvenost potojecih podataka.

Interesantnije je pitanje koje nisi direktno psotavio, ali se da pretpostaviti: Koje to podatke o uzorku zelis da cuvas? Da li su ti podaci isti za sve uzorke ili s erazlikuju, od tipa do tipa (tip uzorka = vrsta uzorka). Zavisno od dogovora na ovo pitanje doci ce podpitanja. jedno je sigurno podpitanje: da li je lista tipova uzoraka fiksan i ako nije koliko se cesto menja, koliko cesto dodajete novi 'tip uzorka (vrstu)'. ovo lici na sloceno pitanje. ne mozete tek tako dodati 'ispitivanje cementa' vasoj listi. stoga pretpostavljam da se to ne desav bas cesto, da dodate novu vrstu uzorka. Ovo moze ali i ne mora da bude znacajno za dalje, videcemo.

OK. Prvo, opet moramo da ustanovimo terminologiju. Po mojoj klasifikaciji, tip uzorka' i vrsta uzorka nisu isto.
Pa pod terminom "Tip uzorka" smatram razlicite uzorke u okviru jedne vrste. Na primer. brasno, so, secer, paprika, kruske, limun, sok, pivo, vino su tipovi uzorka u okviru vrste NAMIRNICE itd. Ove termine sam onako uveo (mozemoda uvedemo i drugojacije) cisto da bismo se lakse razumeli.

Dalje, lepo si ono primetio, pa prava lavina se pokrece tek onda kada prijem primi uzorak. Naravno, nas ne interesuje odakle je uzorak, bitno je da se posao odradi i posalje se korisniku izvestaj o ispitivanju sa fakturom. To je sustina posla.

Sto se tice vrste uzorka (namirnice, vode, itd.), te se stvari rade vec 30-tak godina. Uglavnom se na nabrojanim vrstama uzorka i zastiva citav posao laboratorije, znaci te stari su fiksne (naravno uvek moze doci do izuzetaka). E sada, drugo je pitanje tip uzorka (znaci u okviru jedne vrste uzorka). I kada govorimo o tipu uzorka, mala je verovatnoca da ce i tu nesto bitno da se menja, daleko je verovatnije da se kupi neka novija oprema, sto iziskuje novu metodu ispitivanja, sto se radi iz dva razloga-da se poboljsa kvalitet analize odredjenog parametra ili pak da se uvede ispitivanje nekog novog parametra u odredjenom tipu uzorka koji do tada nije radjen. Recimo, lab je kupila spec. aparat kojim ce se omogociti analiza pojedinih metala (As, Se, Sb ...) koje do sada nismo radili iz tehnickih razloga itd.

Uzgred, u proslom postu, naceo si jednu veoma zanimljivu temu a to je ARHIVIRANJE PODATAKA. Obzirom da se ovim procesom proizvodi veliki broj dokumenata (koji se cuvaju u papirnom obliku, samo se za jedan uzorak cuva oko 10-15 listova papira, znaci idu 1 zahtev, 1 ili vise zapisnika, protokol prijema, 3 naloga, 2 radne liste, 3 izvestaja, 1 misljenje) interesuju me tvoji predlozi za najelegantnije cuvanje i arhiviranje istih, odnosno da li i ovaj segment treba (sto bi bilo jako pozeljno) ubaciti u celu ovu pricu.

Prilazem excell file sa pobrojanim atributima iz nekih od dokumenata koji se javljaju u proceusu. Uocices odmah da se veliki broj podataka ponavlja (sto je razlog bespotrebnog gubljenja vremena na prepisku).

Pozdrav

Napravio sam neke izmene. Tabelu tblZahtevi sam 'izbacio' iz procesa, ostala je po strani, a zato sam ubacio novu tabelu tblProtokolPrijema (Protokol prijema uzoraka, sto se i spominje u opisu procesa). U ovu tabelu bi se upisivali svi podaci o uzorcima bilo da je korisnik doneo uzorak ili je uzorkovanje naknadno izvrseno. Takodje, u tblZahtevi bi se upisivali podaci ne samo o zahtevima za ispitivanje vec i podaci o Ugovorima za ispitivanje, jer se lab. ispitivanja vrse po ova dva osnova, sto jasno stoji kasnije i na prvoj glavnoj strani konacnog izvestaja o ispitivanju.

Prakticno, svi zahtevi koji stignu, bili bi evidentirani u bazi (bilo da su izvodljivi ili ne) dok bi proces bio nastavljen tabelom tblProtokolPrijema na koju bi se nadovezivali podaci u uzorcima.

Inace, ovi protokoli se zaista i vode na Prijemnom odeljenju za svaku od gore navedenih vrsta uzorka posebno.


Dalje mislim da ne bi bilo lose (razmislicu ponovo) da se u celu pricu ubaci jedna kodna tabela na pr. tblParametri_Sifrarnik (ili neki drugi naziv) a evo i zasto. Pa desava se jako cesto da se isti parametar ispitivanja (samo pod malo drugojacijim nazivom) javlja pri ispitivanju velikog broja namirnica (ovde je jako izrazeno). Na primer, jako cesto se radi sadrzaj vode, e sada negde se parametar zove sadrzaj vode, negde sadrzaj vlage, negde sadrzaj suve materije (kad oduzmes vlagu dobijes suvu mat.) a u stvari je sve to odredjivanje vode (i obicno se radi istom metodom uz neznatne modifikacija). Ono sto je bitno, cena parametra je ista u svim namirnicama bez obzira kako se parametar zove.
Pa tako, broj ukupnih parametara koji se uopste odredjuju je znatno manji (parametri su jasno definisani) nego sto se cini u prvom momentu.
Razmatram dalje

Pozdrav



_{[Ovu poruku je menjao zliki dana 06.11.2008. u 14:09 GMT+1]}

1)
E stani malo. Ovo je vazno. Vrste uzorka (materijala) nigde nismo do sada pomenuli. To nije dobro. Imamo dakle vezu 'Vrsta materijala' : 'Tip Uzorka za tu vrstu'
Nekako mi se cini da nam vrsta materijala nedostaje u modelu. Ali to prvo moramo da razresimo na onoj shemi gde smo crtali kutije i rombove, pa tek onda u tabelama.

2)
Ovo samo znaci da taj korak, 'prijem zahteva, sa ili bez uzorka' mora da se detaljno izanalizira, to jest da se nacrta flow chart - sve ono sto si opisao, da se graficki prikaze. Da te obradujem, to cemo otkrivati i za sve ostale korake koji su nacrtani na glavnom dijagramu procesa. Ovaj slucaj smo primetili samo zato sto smo kao hteli d akrenemo od pocetka. Zamisli akd budemo analizirali proces unosa varijabli koje emere u experimentima ....


3) Dobro je da su vrste i tipovi za vrste prakticno nepromenljivi. Ako s enesto promeni, to je dodavanje novog tipa, sto je lakse srediti nego dodavanje nove vrste na primer. Ovo moze da bude znacajno kasnije.

4)
Pusi masti na volju. Moze sve ali nam to nije glavni cilj. Mnogi od ovih dokumenta ce prestati da postoje uvodjenjem baze podataka. Mislim, postojace, ali kao izvestaj odstampan na osnovu podataka iz baze. Dosada su dokumenti u procesu bili nosioci podataka i mesto gde se podaci cuvaju (podaci su na formularu, a formular u fijoci u ormanu). Debele knjige protokola bi trebalo da nestanu, njih treba da zameni baza podataka. Dokumente koje je doneo korisnik mozemo da skeniramo i cuvamo negde u bazi (ili na disku, a baza cuva pokazivac - filena me & path - na graficke fajlove koji ce zameniti dokumente. Dokumenti koje je doneo neko (externi dokumenti) naravno nece biti unisteni, i dalje ce se cuvati u nekoj fijoci u nekom ormanu.U slucaju potrebe, uvek moze da se izvrsi provera - da li se baza i fijoka slazu. Nikad se nece sloziti 100%, ali ce bar biti 'brzi' rad.

Bilo bi korisno da na glavnom dijagramu procesa dodas dokumente koji ucestvuju u trenutnom procesu - da vidimo gde se sta koristi, lakse ce na biti da se snadjemo.

Tvoj neposredni zadat nije da menjas postojecu shemu baze podataka, nego da:

1) nacrtas detaljan flow chart, kako szans i umes o tome sta se desava na priejmnom odeljenju, sta radi tehnicar, a sta radi korisnik, akda postoji uzorak i kada ne postoji uzorak. Nije bitna forma, sad nam je bitna sustina. Moze i tekstulni opis. aj cu ond ato da pretvorim u dijagram. usput, ako budes nekad placao konsultatnta da ti napravi bazu podataka, ovako nekako treba da ide proces, kao ovo sto mi sad radimo. Ti das objasnjenje u tekstu, ili dijagramu, kako znas i umes, a konsultant to onda lepo nacrta. I onda ti konsultatnt pokaze ono sto ti znas i sam, ali nije bilo lepo nacrtano ;-) i naravno ti to skupo platis.

2) da se promeni shema baze podataka, da se uvedu nove tabele - to cu ja da uradim, kad ti obezbedis detaljan flow chart ili opis onoga sto se desava.

Alo ti se cini da trazim nesto sto si vec rekao, moze biti. Ali, ova prepiska je zamena za razgovor. Sto se razgovara mora da se stavi na papir, kao zvanicni dokument.

Kako rekoh, nije ti to posao, barem ne u ovom momentu. Pre bih rekao ovako: tblZahtevi nije nazvana bas kako treba. Razumljivije je da se zobe 'tblProtokolPrijema'. Ako malo pogledas, obe tabele imaju istu svrhu - da registruju podatke o prijemu zahteva. Ako s eti podaci upis=uju u knjigu 'Protokol Prijama' ne smeta da se i tabela zove tako.


Prvu recenicu smo razjasnili. Zahtev se uopisuje u protokol. Treba nam tabela (ili skup tabela) da igra ulogu protokola.
Druga recenica je zanimljiva. Zasto se vode zasebni protokoli? U cemu se razlikuju jean od drugoga? Moze biti da je razliak samo u naslovu i da je jedini razlog vodjenj razlicitih knjiga da zahtevi budu grupisani zajedno. Ako se u razlicite protokole upisuju sustinski razliciti podaci, onda to treba da znamo. Na primer, lista ispistivanja za razlicite vrste materija nije sustinski razliciti podatak. Sadrzaj liste izpitivanja moze razlicit, znaci sta cuvamo unutar liste. Ako lista kao objekt postoji u svim protokolima, onda su protokoli strukturno identicni.

Usput, sta je zapisnik a sta protokol? Excel fajl sa atributim pokauje Zahtev za ispitivanjem i zapisnika o uzorkovanju, pa si naveo 3 primera. Sta je od toga protokol? Ako nijedno od toga nije protokol, u kakvoj su vezi ti dokumanti sa protokolom? Da li je protokol knjiga?

Ima mnogo vise dupliranaj unosa negos to si oznacio

Evo me ponovo, nisam bio kraj interneta. Saljem ti doc file sa nekim objasnjenjima.

Eto ti sad. Ispade da prvi kontakt i prvi korak u celoj prici radi Lekar Higijene. Nigde se jos ne pojavljuje onaj tehnicar sa prijema. Ovo znaci da nas diagram procesa nije tacan i da ga treba ispraviti. To ce da povuce i ispravku sheme baze podataka. Auch, to boli.. Medjutim, deluje i ako da se udaljavamo od teme. Da li hocemo sistem koji ce primarno da omoguci da se evidentiraju analize i formule izvuku iz baze podataka (tako je pocela tema neako), ili sistem koji prati papirologiju? Vidis, proveli smo 50% vremena crtajuci veliki sistem i kao praveci logicki model baze. Onda smo jos toliko vremena proveli proucavajuci detalj 'korisnik dostavlja zahtev'. Saznali smo mnogo o tome,tolik da se i glavna slika promenila. U kom pravcu mi idemo? Sad razumes zasto su ovakvi poslovi veliki i dugo traju i kostaju mnogo, cak i kad se ne isplacije novac konsultantu. Svako malo ba zabasamo u neki pravac gde nismo hteli da idemo.

Svaki zahtev evidentiramo recimo u tabeli Zahtevi. Mozemo d aimamo atribut Status, sa vrednostima ('odbijen','prihvacen'). Ako je 'prihvacen', moze dalje da bude neki atribut koji kaze kome je zahtev dodeljen, na primer ('interna(nas) laboratorija','externa (podugovorena) laboratorija'). Ja sam se abs pitao sta ce nam tabela Laboratorije, ako u njo stoji samo jedan red - nasa lboratorija. Mada i u tom slucaju ima stavri koje su mnogo olaksane na srani programiranja ako cuvamo tsj jedan jedini red. Kad ono vidis, ispade da cemo cuvati vise laboratorija, externih, i definisacemo sta koja moze da radi. To sve nas model koji imamo lako moze da podnese. Naravno, treba da unacimo vrste ispitivanja, da budu 'parent' za tipove uzoraka. I onda cemo imati i vezu "Laboratorija-Vrsta" koja ce nam kazati ko sta moze da radi (prepisemo iz pravilnika)

Usput, nevezano za baze podataka, jedno polu-privatno pitanje: da li vasa firma moze za odredi sastav namirnica? Na primer, donesem domaci keks i neko izracuna koliko u 100 grama ima belancevina, masti zasicenih i nezasicenih, koliko secera, skroba i koliko celuloze (fibers) i tako to. Znas ono sto se vidi na svakoj kutiji cerealija. Ko to u Srbiji radi?

Da ne kazes da samo zanovetam a nista ne radim, evo promenjene glavn sheme (attachment uz poruku). Videsces da sam dodao Vsrte ispitivanja, onako kako sam ja shvatio, ispravi me ako nije tako.

U tekst ubacujem detaljniju sliku onoga sta se desava na prijemu zahteva i predlazem neka pravila. Evo slike:

Ovako predlazem pravila:
1) Podaci o korisniku se drze u tabeli Korisnik (ili tblKorisnik, svejedno u ovom momentu)
2) Tabela Zahtev ima delovodni broj zahteva, ID korisnik da se zna ko je podneo zahtev, kada je zahtev podnesen, status zahteva i ko je odredio status zahteva
Ovo implicira da bi nam dobro dosle tabele gde cuvamo vrednosti statusa i gde cuvami pokazivac na osobe koje imaju pravo da menjaju status zahteva.
3) Na osnovu zahteva se moze zakljuciti da treba izvrsiti jedno ili vise ispitivanja. stoga, ispitivanja koja idu uz dati zahtev idu u zasebnu tabelu Ispitivanja. Samo dve kolone - broj zahteva i koja vrsta ispitivanja.
Vrsta ispitivanja sme biti samo iz skupa propisanih, koji cuvamo u atbeli Vrsta Ispitivanja. Za svaku vrstu izpitivanja postoje tipovi uzoraka (moje shvatanje) i to je definisano u tabeli Tipovi Uzioraka za Odredjenu Vrstu Ispitivanja (donji desni ugao slike)
4) Uzorak koji ide uz ispitivanje moze i ne mora da postoji u momentu podnosenja zahteva. Ako uzorak postoji, u tabelu Uzorci upisemo datum uzimanja uzorka (pitamo korisnika kad je uzeo uzorak ili ako ne znamo, upisemo datum zahteva i napisemo da je uzorak uzeo korisnik. Automatski se kreira nekakav RbrUzorka.)
Ako korisnik nije doneo uzorak, mi pravimo zahtev za uzimanje uzorka i kreiramo zapis o tome u tabeli Zahevi za Uzorkovanje. Ako je uzorak uzet na osnovu zahteva za uzorkovanje, upisacemo to u tabelu Uzorci, ako ne, ostavicemo prazno. Ili vec nenkako cemo to d arzaresimo - iammo dva izvoraq za uzorke - direktno od korisnika i na osnovu organizovanog zahteva. Videcemo kasnije kako ovo moze da se resava.
5) celo ispitivanje se dodeljuje nekoj od laboratorija, koje su akreditovane za odredjena ispitivanja. Ovde se sad mogu dodavati detalji i dalje razradjivati odnos lokalnih i externih laboratorija, podugovora i slicno, a da to ne narusi ostatak slike. Zato o tome treba nacrtati posebnu sliku koja ima dodir sa ovom slikom samo u jednoj tacki - tabela LAboratorije.

Ovim smo pokrili vecinu zahteva za pracenjem papirologije, brem u pocetnoj fazi. Ovakva detaljnija analiza treba da se izvrsi i za proces rada u laboratoriji, overu postupaka i slicno. Jos jedna anliza potreban je za proces izdavanja i overavanja rezultata, ko sta potpisuje i gde cuvamo informaciju o tome ko je i kada potpisao.



_{[Ovu poruku je menjao Zidar dana 11.11.2008. u 00:07 GMT+1]}

Izvinjavam se, nije me bilo nekoliko dana, sada sam tu.

No, da ti odgovorim na poluprivatno pitanje iz predhodnog posta u vezi sastava keksa. Odgovor je, DA, ni bas to i radimo i to rutinski (svakodnevno), osim u keksu, propisi predvidjaju da se ti parametri rade u velikom broju uzoraka. Najveci broj uzoraka koji nam stize na analizu tog tipa su uzorci obroka (obicno su to celodnevni) iz vrtica za decu, menzi, restorana itd. Ne znam da li sam to gore naveo, ovakvi uzorci kompletnih obroka zovemo tzv. "kaloraze" odnosno uzorci u kojima se ispituje kalorijska vrednost proizvoda.

Sto se tice novog modela, nisam ga detaljno pogledao, ucinicu to sto pre, pa cu reci sta mislim.

Pozdrav

Hvala za odgovor na poluprivatno pitanje PItacu te jos toga, verovatno na privatni mail.

Izgleda mi da ove sheme koje cratm postaju sve teze za razumevanje. Evo varijanta koja je mozda laksa za razumevanje. Nacrtao sam kao neke pseudo tabele, sa neophodnim atributima. BOLD atributi cine logicki Primary Key i po pravilu se prenose na zavisne tabele, barem u ovoj fazi analize.

Cak i kad dodje do implamantacije videces da cemo sve atribute koji se sada ponavljajun iz tabele u tabelu morati ionako da ponovimo. Ne brini za prekucavanje i prepisivanje, to Access sam radi ako se forme i subforme pravilno povezu ( a moze da se koriste i subdatasheets, na slican nacin)



Predlazem da proucis shemu, kreiras mozda tabele u Accessu (nisu vazni data tipvi, ostavi da sve bude default, text 50) i pocnes da unosis neke podatke. U prvih 30 sekundi ces videti koji atributi nedostaju. Sta nedostaje, zapisi negde i nastavi da radis. Nemoj da dodajes nista na shemu, nikakva nova polja,. Sad proveravamo samo logiku i da li su tabele dobro povezane. Kasnije cemo lako da dodamo sta nedostaje od atributa.

Probao sam nesto da odradim, imam problem oko povezivanja predlozenih tabela, pa te molim, koriguj ove moje brljotine.
Ocekujem ispravku s tvoje strane, pa da lagano, tokom vikenda probam da sagledam ceo model detaljno.

Pozdrav

Probacu da ti posaljem nesto na mail.

OK, kreirao si tabele, nije mala stvar, 21 komad

Evo 'povezao' sam ih. Uoci da vecina tabela ima Primery key koji se sastoji od vise kolona. Nemoj da te ispaljuju dunsteri kako treba to da zamenis sa nekavim ID, da bi se lakse pisali kveriji. Izgubices ono sto se zove 'referencijalni integritet podataka'. Ako nemas referencijalni integritet, onda kvalitet podataka zavisi iskljucivo od programa. Veruj mi na rec, to nije ni izfdaleka dovoljno. Ja sam jedan od njih, programera i znam koliku stetu mogu da naprave ;-)

Ako pogledas shemu tabela, uocices da su tabele na rubovima slike sa jednostavnim PK. Te tabele treba prvo da uneses, one koje nisu deca nego su samo roditelji (korisnici, lekari, uzorkivaci, kontrolori, laboratorije, vrste ispitivanja)

Onda unesi podatke tabele koj cine grupu 'Pravilnici' - tiovi uzoraka, parametri, metode, varijable. Neka te ne plasi naoko nepotrebno dupliranje podataka - u najnizoj tabeli, verijable, imas sve sto si uneo u bilo koju tabelu iznad. Access ce verovatno da poveze tabele automatski preko subdatahseeta, pa onda ne moras da kucas ponovo podatke koji s eprepisuju iz parent tabele. U svakom slucaju, ovo unosis jednom i nikad vise.

Ostale tabele su 'radne tabele' (Zahtevi, zahtevana ispitivanja, vrste uzoraka za zahtevana ispitivanja, zahtevani parametri i zahtevane metode). Njih u ovoj fazi mozes da popunjavas takodje koristeci subdatasheets. kasnije, kad sistem udje u produkciju, operativne tabele ce biti u stalnoj upotrebi.

Programeri ce na kraju morati da ti naprve forme i subforme za operativne tabela. Takodje ti treba program koji ce da koriste u laboratoriji da bi uneli vrednosti varijabli. Zanci, ukupno dva programa. i verovatno jedan za pregledanje onoga sto imamo u bazi. To i nije mnogo, s obzirom na slozeni proces koji se zeli podrzati ovom bazom.

@ Zidar

Rekao bih da si zakačio pogrešan fajl (odnosno onaj isti koji je zliki postavio), jer ne vidim složene ključeve.

Neka mi bude dozvoljeno da te dopunim .

Ident broj ili identifikaciona šifra predstavlja skup znakova pomoću kojih se identifikuju zapisi tabele ne ulazeći pri tom detaljnije u strukturu sadržaja tih znakova.
Nazvati kolonu samo ID kao identifikacioni broj ne znači mnogo i čak šta više može stvoriti zabunu ako isti naziv postoji u svakoj tabeli. Ali ako se kaže Parametar_ID, Lekar_ID, Korisnik_ID, Kontrolor_ID bez želje da se unapred nametne Data Type već da se ukaže da je ta kolona jedinstveni identifikator predmetne tabele koja će imati još kolona, odnosno njen Primarni ključ, onda to svakako ima smisla. Pogotovo što je vrlo uočljivo u VBA kodu ili SQL izrazu.

I jedsno pitanje.

Ako tabele: tblKorisnici, tblLekari, tblUzorkivaci, tblKontrolori, tblTehnicariAnaliticari ....pretenduju da budu šifarnici (kodne tabele, referentne tabele ili kako god...), a ostanu samo sa po jednom kolonom, koja je garancija da neće doći do situacije da se dva lekara ili kontrolora isto zovu i prezivaju? Ili još bolje pitanje. Koje se vrednosti predviđaju za unos u ove tabele sa jednom kolonom?

Getsbi je u pravu, zakacio sam istu bau koju je poslao Zliki. Evo nove.

Getsbi ej u pravu i za ostale stavri, sve ce to da se resi u svoje vreme. U ovom momentu mi je vazno da se shvate odnosi (relacije) medju tabelama. Vidis, tu jeengleski ispao korisniji nego srpski. U relacionoj teoriji Codd definise 'relation' = tabela, a kasnije se dodaje 'relationship = odnos izmedju tabela. Neko to preveo na srpski i jedno i drugo kao 'relacija', mzode je bolja rci 'relacija-tabela' i 'relacija odnos' da se zna o cemu se prica. I cela teorja je dobila ime ne po 'relationships' nego po 'relation'.

Naravno da ce sifranci imati vise od jdne kolone. Licno nisam pobornik da se bilo kakva imena prave sa sufiksima -ID, _Kod i slicno, ali sta ces kad smo navikli tako. I tacno je, postojanje nekakvog vestackog ID ne garantuje jedinstvenost, bas kao i autonumber kolone. Uvak moze da se napise:

INSERT INTO Sifranik (ID, Ime) VALUES ('id_1",'Zidar')
INSERT INTO Sifranik (ID, Ime) VALUES ('id_2",'Zidar')

Ako je ID primary key, upravo smo ubacili ime = 'Zidar' pod dva trazlicita ID. Da li je to isti Zidar? Ko zna.... Ispade da ni postojanje dve kolone ne garantuje jednoznacnost. Medjutim, posto su ovi sifranici u ovom slucaju sa relativno malo rekorda, mozemo da zahtevamo da korisnik 'zna sta radi i nece uneti gluposti'. Mnogo je veca verovatnoca da se gluposti unesu u tabele nizeg nivoa na hijerarhijskoj lestvici, pa smo za tu svrhu predvideli visekolonske kljuceve.

A Zliki je rekao cini mi se da postoje stroga pravila kako se grade kodovi za neke od stavri kojima se bavimo. Verujem da vrste ispitivanja imaju zakonom propisane kodove pa ne moramo da izmisljamo nista. Za tipove uzoraka ne znam, ali me ne bi cudilo da postoji nesto u zakonu ili bar u praksi. u svakom slucaju ne neki bezimani brojevi. Ostavimo to za kasnije. Pitanej kodiranja nije vise ni problem relacionih baza, nego problem koji vsaka nauka i industrija resava na svoj neki nacin. Na primer, u autoindustriji postoji VIN - broj vozila, koji u sebi sadrzi oznaku proizvodjaca, maraku, tip, godinu i jos kojesta - znaci VIN je nakakva slozena, izracunarata, vrednost. Isto kao i JMBG - sadrzi datum rodjenja, opstinu i neki slucajan broj plus kontrolnu cifru. A znamo da teorijski nista ne bi trebalo da bude slozen podatak, nego da se atomizira. Yeah, right! Pazi da ne razbijam JMBG na sastavne delove Ali mogu da uradim sto niko ne radi: da nekeko uporedim datum rodjenja sa JMBG. Na taj nacin ne moze meni da se dodeli JMBG mog brata. Osim ako mi je brat blizanac. A malo je verovatno da ce se nekom greskom meni dodeliti JMBG nekoga ko je rodjen na isti dan kao ja (a da nije brat blizanac). I ako naravno proverim na nivou tabele check digit, ona je veoma verovatno da je korektan JMBG broj dodeljen pravoj osobi. Znaci ima smisla da postoji neka logika u dodeljivanju identifikatora i kodova, bar moze da se proveri ako nismo sigurni.

Ne znam da li je ovo bitno u celoj priči oko baze ali sam osetio potrebu da raščistimo sa ovim. Naime, svaka relacija je tabela ali svaka tabela nije relacija već treba da zadovilji neke uslove. Ti uslovi su:
1. Sve vrednosti podataka jednog atributa moraju biti istog tipa.
2. Redosled n-torki u relaciji je proizvoljan.
3. Svi atributi unutar jedne relacije moraju imati različita imena.
4. Unutar jedne relacije ne smeju postojati dve identične n-torke.

Odatle potreba u srpskom jeziku za dva termina.

@ biske86
Ova četiri navedena uslova stoje.

Ovo je iz Vujaklije: Relacija (lat. relatio) odnos, veza, poslovna veza
Srpski prevod za englesku reč relation je veza.
Srpski prevod za englesku reč relationships je odnos ili povezanost.
Kako Zidar kaže cela teorja je dobila ime ne po 'relationships' nego po 'relation'.
Dok se ovi Zidarevi termini 'relacija-tabela' i 'relacija odnos' ne ustale najvažnije je da u glavi pravimo razliku

P.S. Bilo je već rasprave oko ovga na matičnom forumu Baze podataka.

Samo da konstatujem, nove korigovane baze jos uvek nema, molim te da je posaljes.

Sto se tice sifriranja situacija je sledeca>
- Sve vrste uzoraka imaju svoju sifru, odnosno razlicite slovne oznake (jos jednom napominjem da se napravi razlika izmedju vrste i tipa namirnica, videti neki od gornjih postova)
- Svi tipovi uzoraka u okviru iste vrste uzorka, imaju identicnu sifru (istu slovnu oznaku)

- Sve metode ispitivanja imaju svoju jedinstvenu sifru

- Sva ovlascena lica (lekari, uzorkivaci, tehnicari analiticari) takodje, imaju svoju jedinstvenu sifru

- Parametri sipitivanja vec mogu da se ponavljaju. Pa tako, sadrzaj olova mozete da radite u jabukama a mozete i u
zemljistu na primer itd (ali naravno ne mozete da radite akusticnost ili refleksiju).


Pozdrav

_{[Ovu poruku je menjao zliki dana 18.11.2008. u 09:01 GMT+1]}

E bas mi se ne da da zakacim promenjenu bazu. Evo da probam opet. Izgleda da je uspelo.

Off topic, kad englesko 'relation' prevedemo sa 'relacija' i msilimo na relationship, to se u jeziku zove 'reci koje su lazni prijatelji' - kad rec zvuci slicno a ima razlicito znacenje u dva jezika. Termin 'lazni prijatelji' sam prvi put video u jednom clanku u politici koji je napisao Ivan Klajn. Uzeo je za priemr engleskur ec 'eventually' koju mi prevodimo sa 'eventualno'. eventualno na srpskom znaci 'moze da se desi, ali verovatno nece' i koristi se u smislu "verovetno se nece desiti, ali ako se desi, bicemo spremni (za svaki ebentualnost ;-)" . Na engleskom eventually znaci "desice se sigurno, pre ili kasnije, garantovano ce se desiti". Joj razlike
Mani se desilo da prvi posao u Kanadi ponudim '"za par stotina dolara" to jest za "couple hundred dollars". I na kraju ispostavim racun na $460. Covek me gledao zabezeknuto i rekao otprilike "u redu, platicu, ali rekao si PAR". na engleskom 'couple' znaci 'TACNO dva', kao par cipela, bracni par i slicno, dakle ni manje ni vise, nego tacno DVA.

Evo upravo razmatram bazu koju si poslao, akcenat je na externim laboratorijama trenutno.

Pa ovako, ukoliko korisnik zeli nekakvo ispitivanje koje mi nismo u stanju da odradimo, trazi se laboratorijama koja to moze (lab podugovarac), sa njom sklapamo ugovor o podugovaranju usluga (postoji procedura). E sada, najlaksi put da se to odradi je sledeci: lepo odete na sajt ATS-a (akreditaciono telo Srbije) i tamo imate spisak svih akreditovanih organizacija sa svim neophodnim podacima

Kao prilog ovde, zakacicu nekakav Obim akreditacije neke od laboratorija sa sajta cisto da vam pruzim nekakvu predstavu o tome kako se vrsi klasifikacija, znaci koji tipovi uzorka, koji parametri ispitivanja, koje metode ispitivanja itd.

Jos nesto, naime tabela tblUgovoriExterne je ostala cini mi se nepovezana sa tabelom tblZahtevVrsteIspitivanja. Takodje, smatram da nam nedostaje jos jedna tabela Ugovori (mislim na ugovore sa korisnicima) jer, ko sto sam ranije rekao, osnova za ispitivanje moze biti zahtev ili ugovor ili pak oba. Pa prema tome, imali bismo skracenu proceduru kod ugovora odnosno odmah bismo isli na nalog za uzorkovanje. Tabela tblNalogZaUzorkovanje se ne pominje direktno u proceduri, ali to jeste nakakav sastavni logicni deo, pa neka ostane za sada (uzorkovanje se i vrsi prema nekakvom planu uzorkovanja koji neko odobrava ili ne). Ostalo mi deluje OK za sada.

Pozdrav

_{[Ovu poruku je menjao zliki dana 19.11.2008. u 14:17 GMT+1]}

Uvek covek nesto zaboravi ;-)

Evo, dodao sam vezu tabele Ugovori sa zahtevom i laboratorijom. Morao sam da malo promenim grupu tabele, ako odstampas relacije i uporedis sa prethodnom verzijom vieces razliku. Izbacio sam kolonu Korisnik iz tabele Ugovori, Korisnika znamo kroz broj zahteva. Gde cuvamo ugovor? U tabeli Ugovori kao image, PDF ili nesto drugo. Tvoja je odgovormost da u samom dokumentu koji se cuva sve pise kako pise i u bazi (korisnik, broj zahteva itd)

Pretpostavka je da jedan zahtev moze zahtevati vise vrsta ispitivanja. Svaka vrsta moze biti dodeljena nekoj laboratoriji. Ovo znaci da sve lboratorije moraju biti unesene u bazu, u tabelu Lab. Kolona Externa u tabeli Ugovori i veza na tabelu Laboratorije garantuje da se ne moze napravitri ugovor sa laboratorijom koja nije Externa.

Iz PDF-a koji si zakacio, pretpostavljam da je ono sto mi zovemo VrsteIspitivanja u prvoj koloni tabele, (Predmet ispitivanja materijal/proizvod)

Ne znam sta bi bili tipovi uzoraka.

Parametri su izlistani u koloni a kolona: (Vrsta ispitivanja ili karakteristika koja se meri (opseg merenja; merna nesigurnost))


Metode je ocigledna. (Metoda ispitivanja (pravilnik, standard, validovana metoda)


Da li sam u necemu pogresio?

Kako bi se ovo kodiralo u nase tabele?


Ne vidim u nasem modelu mesto gde bismo cuvali kolonu (Oblast ispitivanja). Gde bi to doslo, recimo kao atribut? Parametar? Vrsta uzorka?

Jos jednom da se vratim na ugovore. Postoje u ovom slucaju dve vrste ugovora. Svaka od vrsti ugovora je definisana zasebnom procedurom i posmatra se kao zaseban proces koji je naravno, usko povezan sa ovim procesom koga ovde obradjujemo. Dakle situacija je ovakva:

1. slucaj
Ugovaranje se ostvaruje izmedju nas (izvrsilac usluge) i klijenta (potrazivac usluge). Ugovori ovog tipa su ulazni dokumenti, kao i zahtevi za ispitivanjem, u ovom procesu, s tom razlikom sto se ugovorom naravno jasno precizira dinamika, placanje, vrsta ispitivanja, tipovi uzorka itd. unapred. Preispitivanje ekonomske, pravne, tehniceke itd. strane ugovora izvodi se po drugoj proceduri tako da je ovde taj korak izbegnut. Inace, vecina poslova moje firme bazira se na ugovorima, zahtevi su znatno manje zastupljeni.

2. slucaj
Mi smo potrazivac posla a druge externe akreditovane laboratorije su izvrsioci usluge
Ovo je zaseban proces opisan posebnom procedurom. I ovaj deo je, cini mi se, jako dobro opisan u modelu.


Posto se ovi ugovori vode u zasebnim evidencijama, potrebno je svakako to i ovde napraviti. Naravno, necemo ulaziti u detalje ugovora ali neki osnovni atributi su neophodni.

ok evo paralele.

Ono sto se zove "predmet ispitivanja materijal/proizvod", kod nas bi se zvalo "tip uzorka" (znaci hrana za zivotinje, brasno, secer, kikiriki itd.)
Njihovo "Oblast ispitivanja" - nase "Vrsta ispitivanja"
njihovo "Vrsta ispitivanja ili karakteristika koja se meri" - nase "Parametar"

Ovo oko metoda je jasno

Dakle, imamo razlicite tipove uzorka u kojima se rade odredjeni parametri i to odredjenim metodama.

E sada, ono sto smo ispustili u modelu, a neophodno je zbog ovde interne klasifikacije u mojoj firmi, jesu "VRSTE UZORAKA".

Ako se pogledas neki od gornjih postova, videces da smo to razmatrali.

Pa bi cela prica trebala da ide ovako.

Dakle, stigne mi recimo uzorak paprike. Po internoj klasifikaciji, paprika pripada vrsti "NAMIRNICE" te ce oznaka zapisnika, izvestaja osnosno uzorka imati prefiks "H" (cirilicno N). Dalje, paprika pripada tipu "povrce" a u tom tipu uzorka pravilnik okvalitetu propisuje da se rade mikrobioloska vrsta ispitivanja, hemijska vrsta ispitivanja, radioaktivnost vrsta ispitivanja itd. a odgovarajuci parametri su (za hemijsku vrstu ispitivanja na pr. sadrzaj olova, sadrzaj kadmijuma, sadrzaj zive, sadrzaj arsena), za mikrobiol. recimo sadrzaj ukupnih koliformnih bakterija, sadrzaj fekalnih bakterija itd.
Potom, napr. sadrzaj olova moja lab moze da odredjuje primenom dve razlicite metode (izabiramo pogodniju a moze i korisnik da zahteva metodu itd.)

E sada, ukoliko korisnik trazi na primer da se u paprici odredi radioaktivosti, moja kuca to ne radi pa se ukoliko korisnik zeli, angazuje laboratorija podugovarac (sa kojom mi imamo sklopljen ugovor o saradnji) da ona odradi taj posao za nas.

Jos jednom, ovo za "VRSTE UZORAKA" treba ubaciti u model jer mi je neophodno, a to su:

-namirnice
-predmeti opste upotrebe
-otpadne vode
-recne vode
-mineralne vode
-vode za pice
-brisevi predmeta
-emulzije
-zemljiste
-otpadni materijal
-imisija vazduha
-sedimentatori
-kaloraze
-emisija vazduha
-buka

i ja mislim da je to sve od vrsti koje su zastupljenje, provericu jos jednom.

OK, dok smo jos tu:

=> pretpostavljam da je jedan ugovor po jednom zahtevu. U tom slucaju ceo ugovor jeste atribut tabele Zahtevi. Mzoe da se cuva kao image- kao OLE polje - ceo dokument, a moze i da se razbije na nekakve atribute koji opisuju ugovor, to jest zahtev. Ako moze biti vise ugovora izmedju vase laboratorije sa istim klijentom po osnovu istog zahteva, onda treba jos jedna tabela, child za tabelu Zahtevi.


nema komentara na ovo, za sada ostaje kako jeste.



OK. Ovako cemo da uradiomo; daj mi hijerarhiju svih ovih nivoa, ukljucujuci i 'vrstu uzoraka'. nesto kao:

Vrsta Uzoraka => vrsta ispitivanja => tip uzorka => metode => patametri ili vec kako ide. Za svaki nivo daj neki primer, po mogucstvu povezan sa prethiodnim nivoom. Moze i u excelu. Ovo zato sto isam siguran vise da li sam dobro ukapirao hijerarhiju. Ubacicemo "Vrste Uzoraka", samo treba da vidimo gde tacno.

Ostalo je tehnika i mehanika

Usput, koju verziju Access imate?

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