Racunanje u access-u

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?

Potpis

https://mzahorjanski.wixsite.com/mzahorjanski
https://www.fiverr.com/miroljubzahorja?up_rollout=true
https://www.youtube.com/@miroljubzahorjanski

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.

Potpis

http://biske.rs

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

Potpis

https://mzahorjanski.wixsite.com/mzahorjanski
https://www.fiverr.com/miroljubzahorja?up_rollout=true
https://www.youtube.com/@miroljubzahorjanski

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?