Zaduženje u blok-serijama a razduženje pojedinačno i još ponešto

Pozdrav svima na forumu a posebno ljudima koji nesebično ulažu sebe i svoje vrijeme za rješavanje naših problema.
Svaka čast i skidam kapu.
Otvorio sam ovu temu sa ovakvim naslovom ( da bi bilo što direktnije navedeno gdje sam zapeo) i to je uglavnom moj najveći problem što se tiče ove baze , ali imam ja njih još. Sve ću ih navesti pa ko može nek pomaže. Iz tog razloga moj prvi post u ovoj temi će biti „malooo“ veći ali nadam se da to neće biti problem jer želja mi je i da ja vama pomognem da bi što brže razumjeli moje molbe i želje a i moderator foruma predlaže- što opširnije.
Pa da krenem prvo sa onim što znam, a to je da imam želju da napravim bazu za evidenciju kodiranih plombi kojom bih olakšao rad svojim drugarima na poslu (radim u Elektrodistribuciji) a i kojom bih dobili pregledniju bazu i sigurniju jer je evidencija tih plombi jedna od značajnijih stavki za poslovanje firme.
Do sada je to rađeno u Excelu pa vam ne moram ni pisati kako je to funkcionisalo.
E sad sa Access-om (2007) sam prvi put počeo nešto raditi prije 2-3 mjeseca i to ne intezivno ali uspio sam nešto „sklepati“ što sam i okačio i uglavnom je to do sada u skladu sa mojim zamislima. Naravno svaki predlog za poboljšanje prihvatam.
Okačiću sliku forme na osnovu koje će se ,nadam se , lakše razumjeti moji silni problemi.
Evo prvo da krenem od ED broja ( 1 na slici). ED broj je jedinstven tj. samo se može jedan potrošač sa svojim podacima (ime,broj brojila, adresa)nalaziti pod jednim ED brojem i ne postoje dva ista ED broja u sistemu u Elektrodistribuciji.
Međutim između ostalog može doći i do sledećih situacija vezano za jedan ED broj:
- može doći do promjene imena potrošača
- do promjene adrese
- do promjene broja brojila (recimo prilikom redovne zamjene brojila)
E sada, to se sve može desiti a da se ne mjenjaju brojevi plombi koje su ugrađene kod tog potrošača tj. na tom ED broju osim u slučaju kada se mjenja brojilo ili kada se vrši kontrola .
Uglavnom da ja to ne zapetljavam, moja je zamisao da što se tiče situacije br. 1 sa slike ako je to moguće, da se prilikom unosa novog ED broja, ako on već postoji u bazi, pojavi poruka tipa „ Unešeni ED broj već postoji u bazi“ čijim potvrđivanjem na OK će se izbaciti podaci u istoj formi za tog potrošača (ime,adresa,broj brojila) kao i podaci o već postavljenim plombama kod tog potrošača. Vidjećete da se sada kada se unese već postojeći ED broj pojavi u subformi podaci o plombama ali mi se ne pojavi ime potrošača i ostalo i isto tako ne mogu „listati“ plombe ukoliko ih ima više za tog potrošača a ja bih želio ako je to moguće da mi se pojave svi podaci ( i za potrošača i za plombe ) i da ih ja tada mogu promjeniti i zapamtiti ( recimo, desi se zamjena brojila kod tog potrošača na tom ED broju i sada kada se unese ED broj Acess meni izbaci poruku da taj ED broj već postoji i izbaci mi podatke vezane za taj ED broj a ja onda vršim promjenu broja brojila i plombe koja je postavljena na prošlom brojilu jer je ista na terenu potrgana i ona me više ne interesuje tj nije mi više bitna dok sve ostale plombe kod tog potrošača(npr. na osiguračima,letvi itd.) koje su još uvijek tamo i koje su neoštećene ostaju u bazi). Tako isto ako dođe do promjene imena, adrese isl. da ih i ja mogu promjeniti i zapamtiti.
Jer kad ih bude u bazi 1000 i više ja ih nikada neću tu listati ,značajno mi je samo da znam ako je novi potrošač kojeg nema u bazi unose se podaci za njega i pamte a ako je potrošač koji već postoji u bazi onda se prema potrebi za njega mjenjaju podaci i pamte.
Što se tiče situacije broj 2 (na slici) volio bih da mi ovde na ovoj subformi bude prikazan podatak broja sloga od ukupnog broja slogova. To mi je bitno jer sada kada ukucam ED broj nemam uvid koliko ima plombi postavitih na tom ED broju ( znam jedino ako ću listati na dugmad ali pošto će sa ovom bazom da rade uglavnom žene operateri onda im sve treba dobro naglasiti kako se ne bi mogle zeznuti, bez uvrede).
Situacija broj 3, tj moja želja br 3 je da kada prilikom unosa broja plombe (na mjestu 3 sa slike) se pojavi prezime kontrolora koji je tu plombu zadužio da li u polju br 4 ili da napravimo novo polje br 5 (na slici).
U stvari ako bi to moglo onda ne bi trebalo ni ostaviti mogućnost da operater unosi kontrolora nego da se on automatski pojavljuje na ovoj subformi. Ovo je sada povezano sa mojim problemom koji je u naslovu teme a to je zaduženje i razduženje plombi po kontrolorima.
Problem se sadrži u sledećem. Kontrolori zadužuju plombe u serijama od po 25 kom. ili 50 kom. i različitih boja. Ja imam prijedlog forme (okačio sam sliku) šta bi trebala da sadrži ( izbacio sam da se ne vidi polje ID_Zaduženja jer mi nije potrebno u formi). Trebalo bi nekako ( a ja to nemam pojma kako) da se kontrolor zaduži unosom početnog i završnog broja te serije(npr. od 6375 do 6400) a da se u stvari on zaduži sa svakim brojem pojedinačno zbog razduženja koje će biti kasnije tj da se automatski razduži za plombu recimo 6380 kada je ugradi i kada ona bude unešena u bazu da je ugrađena kod potrošača NN na brojilu broj xx
E sada trebalo bi na osnovu primjera moje forme da se naprave tabele za zaduženje i razduženje(Jedna ili dvijeili kako već treba ) i ja mislim tabela za Boje plombe pa da se sa Lookup poljem izabira boja u formi za zaduženje.
Jooj - zaboravio sam. Trebala bi biti još jedna labela i polje koje bi nam govorilo na formi koliko taj kontrolor trenutno ima zaduženih plombi kod sebe (označeno sa 1), jer se može desiti da on ima kod sebe 6 plombi i da izvrši zaduženje nove serije od 25 kom. pa da bi se imalo uvida da on kod sebe ima 31 plombu a kad se razduži za nekoliko plombi da se za toliko smanji i stanje plombi kod njega.
Već sam naveo ranije da prilikom unosa plombe u subformu Plombiranje bi bilo dobro da se automatski prikazuje koji kontrolor ju je zadužio i trebalo bi da se on razduži isto za tu plombu tj da mu se trenutno stanje njegovih plombi koje ima još kod sebe umanji za tu plombu. On praktično plombe razdužuje tako što ih ugrađuje na mjerno mjesto potrošača tj. ne vraća ih u firmu pa da bi se razduživale. Ustvari svaka plomba ima dvije naljepnice sa svojim kod brojem , jednu lijepi na mjesto gdje je plombirao a drugu na zapisnik koji dostavlja u firmu i na osnovu tih zapisnika i naljepnica operater vrši unos podataka u bazu.
Ljudi ja sam ovo baš razvukao ali sam htio da navedem sve svoje „želje“ jer pretpostavljam da se one lakše mogu rješiti u hodu nego da se naknadno nešto mora prepravljati.
Primjetiće te da sam pretragu po raznim stavkama išao sa parametarskim upitima pa onda izvještaj na osnovu njih. Meni zadovoljava ovaj način ali prihvatam i prijedloge za nešto drugačije.
Za sada toliko - pozz.

---

Srećko Šojić: "Polako s plaćanje...".

Uporedivši tekst kojim iskazujete šta želite i model baze koju ste prikačili može se zaključiti da model treba korigovati barem kao u prillogu i na slici...

---

potrošači, brojila i plombe


Sličan problem sam i sma imao samo za neke druge potrebe pa cu vam dati kratak opis:

1. Mesto merenja je mesto gde se nalazi ugradjeno plombirano brojilo. Ima svoje podatke (adrsu, mesto, grad...) koji se mogu menjati (promena naziva ulica i sl. što je kod nas ko dobardan) ali se ne smeju brisati. Na tom mestu se nalaze potrošači i može ih biti više (zgrada) a može se meriti i zajednička potrošnja koja nije vezana za fizičko lice već za skupštine zgrade i sl. ili čak za distribuciju. Potrošač u sistemu se vodi sa svojim Id i ima svoje podatke koji se mogu menjati (adresa, ulica, ...) i za njega ne treba brisati stare podatke (istorija mora uvek da postoji)
2. Brojilo ima svoje podatke koji se takodje mogu menjati (broj, snaga, adresa...). Ni podaci za brojila ne smeju se brisati jer se brojilo može pojaviti na nekoj drugoj adresi i za nekog drugog potrošača. Potrošač je vlasnik brojila i može da zahteva njegovu zamenu (sam kupuje novo), popravku, baždarenje i mkože da ga upotrebi na nekom svom drugom objektu ili čak i da ga proda drugom potrošaču, tako da je ono "živo" dok se ne uništi.

Mora postojati tabela veze izmedju potrošača i brojila. Jasno je da jedan EDbroj odgovara samo jednom brojilu ali to ne znači da potrošač ne može imati više brojila na svoje ime!

3. Svako brojilo je plombirano najmanje sa jednom plombom a pored toga i plombiraju se i drugi delovi ormana gde se ono nalazi tako da broj plombi na odredjenom mestu gde se brojilo nalazi varira. Postoji mogućnost da se prilikom rada na terenu neke plombe i oštete tako da ne mogu biti upotrebljene za plombiranje i one se moraju vratiti na razduženje. Za svaku upotrebljenu plombu mora se znati mesto gde je upotrebljena (ne mora biti samo za brojilo!).

Za vodjenje evidencije o plombiranju mora postojati tabela gde se plomba nalazi i za koju svrhu je upotrebljena (za brojilo, za MTK, za distributivni deo ormana ...). Treba voditi računa da ako je plomba upotrebljena za brojilo onda može da se napravi veza potrošač-brojilo-plomba a ako ne onda se plomba vezuje za mesto gde je upotrebljena a ne za potrošača odnosno brojilo (najčešće su to zajednički delovi ormana i uredjaji kojima raspolaže samo distribucija a ne i potrošači na toj adresi.)

Manipulacija sa plombama (zaduženje, razduženje i dr.) je standardna stvar i sa time se ne treba previše opterećivati.

U tom smislu treba malo i Zoranov model doraditi da odgovara.

Još malo o plombiranju

Mislim da ovaj problem treba razdbvojiti na dva dela

1. Evidencija plombi (ulaz izlaz, zaduženje, razduženje i dr.). Jasno je da ako se plombe upotrebljavaju na mernim mestima a upotrebljavaju se da se ne može govoriti o razduženju u serijama već samo pojedinačno. U ovom delu treba da se nalaze i podaci lici koje mogu da rade sa plombama (zadužuju, vraćaju i sl.) Ovo je klasična evidencija gde još treba dodati i delove za razna izveštavanja kao i izveštaje o stanju - broju plombi. TZreba da ima i deo koji se zove popis i koji u svakom trenutku može da da podatke o plombama u magacinu.

2. Evidencija upotrebe plombi. U ovom delu se za izuzete plombe iz magacina pravi dokumentacija o njihovoj upotrebi: mesto gde je upotrebljena, za koju namenu, ko je upotrebio, kada i sl. Obratite pažnju da se ne mora obavezno plomba vezati za ED broj. Jasno je da ako se upotrebi za ED broj da se radi o potrošaču sa svojim brojilom i da se u tom slučaju uspostavlja veza plomba-mesto-potrošač-brojilo. To bi značilo da postoji lista plombi, koja se upotrebljava na mestu merenja na kome se a ne mora nalaziti potrošač sa ED brojem i brojilom. Praktično to znači povezivanje tri ili možda čak i četiri forme za obradu podataka uz prethodno prilagodjavanje modela.

Povezivanje tri i više formi u access-u a da to iole bude lako za korišćenje i na odredjen način intuitivno za negog peru magacionera (do verzije 2007 za nju ne znam) nije baš jednostavno ali to neka bude tema za sebe.

Uh, izvinite na ovolikom filozofiranju ali su ovo praktični problemi

Mikijeva radionica – crtić : „Hm, čemu ovo služi. Usto i ne radi.“
Šalim se naravno.
Prvo hvala Zoranu za tako brzo reagovanje i upuštanje u moj problem. Dao si prijedlog baze i ja je danas razmatram i posmatram i probavam i na kraju zaključim da sa mojim dostignutim znanjem o Access-u je ovo prijedlog koji me je zbunio da se sada prisjećam kako se zovem . Opet šala ...

Prijedlog je vjerujem dobar i možda je to način da se riješi prvenstveno problem zaduženja i razduženja plombi i svih ostalih problema ali ne znam zašto imam osjećaj da bi ovo proradilo da tu treba dosta VBA kodova a ja sam tu ZERO.

Ipak ja sam pokušao nešto barem uraditi sa ovim prijedlogom. Počeo sam da unosim podatke u tabelu pa sam prilikom unosa došao do nekakvih zaključaka:
1. Tabela Brojilo – da li je potrebna i što. Tu bi se znači unosili brojevi brojila i svakom broju bi se dodao ID broj. Toga ima dosta ( oko 22000)i ona se ne bi odmah sva unosila u bazu već u hodu kako se koje plombira a onda kada se unese neki veći broj kako operater da zna njegov ID prilikom unosa podataka u tabelu -ED broj
2. Da li ima potrebe razdvajati podatke u dvije tabele ( pitam jer ne znam da li je to možda uslov da bi se moglo realizovati ono sve što sam opisao u svom prvom postu). Po meni ED broj potrošača je osnova oko koje se sve treba dalje graditi, jer je on jedinstven, znači ne mogu biti dva ista ED broja u elektrodistribuciji i za svaki ED broj je vezano samo jedno brojilo i jedan potrošač (ime), jedna adresa, dok na tom ED broju može biti postavljeno više kodiranih plombi (za brojilo,pancer,ploču, ukl sat itd). Svaka postavljena kod plomba ima svoj broj,datum postavljanja, razlog, mjesto gdje je postavljena i ime kontrolora koji ju je postavio.
E sada situacije koje se mogu dogoditi kod jednog ED broja je : da dođe do promjene naziva potrošača, promjene imena mjesta, promjene brojila pa samim tim bi bilo potrebno uraditi i promjenu broja kodirane plombe i svih njenih podataka koji su vezani za nju (datum postavljanja, razlog, mjesto gdje je postavljena i ime kontrolora koji ju je postavio) recimo na tom zamjenjenom brojilu i na panceru itd. gdje je god bilo potrebe da se skine stara prilikom zamjene brojila.
Baza nam služi prvenstveno da imamo evidenciju trenutnog stanja na terenu ( trenutnih plombi koje se nalaze na tom i tom mjestu i ko ju je postavio) te sam zato ranije naveo da mi nije prvenstveno potrebno da imam podatak koja je plomba bila prije recimo zamjene brojila tj da bih moglo tako da se napravi da staru plombu ili bilo koji drugi podatak na aktivnom ED broju jednostavno „prepišemo“ sa novim podatkom. Ne kažem da ne bi bilo dobro imati i stare podatke ali ne znam koliko to onda komplikuje već komplikovanu situaciju.
U slučaju da je potrebno da se dođe do ranijih podataka za neki Ed broj (staro ime, broj brojila itd ) to se uvijek može provjeriti u aplikaciji kojom se radi u elektrodistribuciji jer tamo ostaje svaka takva promjena.

3. Prilikom unosa podataka dalje u tabelu primjetio sam da nemam tabele za unos imena kontrolora te u tabeli Plomba ne znam odakle povlačim tj uzimam broj plombe tj PlombaID kad nemam nigdje gdje se zaduži broj plombe pa da dobijem taj ID (nema veze između tabele ZaduženjePlombi i tabele Plomba

To su samo neka moja zapažanja koja naravno ne moraju biti ispravna jer ne znam kako je to Zoran zamislio dalje da se realizuje i naravno imam razumjevanja i znam da je čovjek napravio veliki posao za kratko vrijeme i možda bez dovoljno potrebnih informacija i naravno da je ovo vjerovatno kostur koji treba razrađivati dalje i na tome mu ponovo puno hvala.

Ja bih se opet vratio onom mom primjeru. Nadam se da on nije uzalud napravljen i da se i od njega može iskombinovati ono gore što sam mislio. Znam da je sve moguće napraviti osim naravno „drvenog šporeta“ a može i on ali samo za jednokratnu upotrebu. Taj moj primjer (izgled i tako to) zadovoljava potrebe ako bi se moglo napraviti i integrisati zaduženje i razduženje i još one sitnice u njega.
Pozz.

PS: Evo prikačiću kako je to rađeno u Excelu. VBA kod i sve to je napravio jedan kolega iz druge RJ. Ovde je samo dio da se može vidjeti kako je to bilo rješeno ali zbog obima podataka i svačeg nečeg (nema izvještaja, pretraga otešana itd. ) mislim da bi to bilo bolje u Access-u. Slažete se, zar ne ?

---

@mpaja
Hvala što si se javio i iznio svoje poglede na probleme vezane za ovu temu
Vidim da si dobro upućen oko problematike plombiranja i uopšte obavljanja ovih poslova kod potrošača. Sve što si naveo stoji ali moja zamisao vođenja ove evidencije pojednostavljuje malo stvari.
Već sam u prethodnoj poruci naveo nešto od toga.
Zamisao mi je da ta baza bude presjek trenutnog stanja na terenu što znači da ako imamo aktivnog potrošača (regularnog, prijavljenog itd) on ima svoj ED broj.
Svi mogući podaci o njemu se nalaze u aplikaciji sa kojom radimo u distribuciji. Tamo se nalazi i sva njegova istorija od kad je prijavljen sa svim promjenama (imena, brojila, ulice itd) ali u toj aplikaciji nije predviđeno evidentiranje kod. plombi.
Ja sam mislio da napravim bazu trenutnog stanja na terenu a ako me baš interesuje istorija potrošača onda to vidimo u navedenoj aplikaciji.
Pošto postoji ED broj koji je jednoznačno određuje potrošača mislio sam da za njega vežem sledeće podatke:ime potrošača,mjesto i broj brojila (nisu mi značajni drugi podaci o brojilu jer njih imam u aplikaciji).
Zatim kao što sam to napravio u formi za unos plombiranja (na slici iz prvog posta) da imam jednu subformu u kojoj bih unosio podatke o postavljenim kodiranim plombama za taj ED broj a na njemu može biti plombirano više stavki tako da bi svaki broj plombe za sebe vezao sledeće podatke:broj plombe (koji je isto jedinstven), datum kad je plombirano, ko je plombirao, šta je plomb. i razlog i napomena ako ima. Znači dešava se da na jednom ED broju bude 5-6 i više plombi.
E sada situacije koje se mogu dogoditi vezano za ED broj su : može doći do promjene imena potrošača, naziva ulice, i zamjene brojila ( pošto se i ta stavka nalazi u formi za unos EDbroja) a situacije što se tiče podataka u subformi su da može doći do promjene podataka : broja plombe (recimo za to brojilo i glavne osigurače itd ) a samim tim treba promjeniti i ostale podatke koji su vezani za taj broj plombe koji se mjenja a to su datum pl., ko je pl.,Šta je plombirano - ostaje jer on to praktično preplombirava , i razlog plombiranja se isto može mjenjati.
Znači ja bih nekako trebao imati mogućnost da promjenim te podatke i prilagodim ih stvarnom stanju na terenu. Pretpostavljam da bi čuvanje starih podataka samo dodatno izkomplikovalo stvar.
Meni ti podaci ne trebaju jer ako je neka plomba potrgana zbog zamjene brojila ona više i nije tamo nego je tamo nova pa ako mi dođe kontrola iz Javnog preduzeća i kaže našli smo kod tog i tog potrošača taj i taj broj plombe, želimo da znamo ko je stavio, kad i zašto ja imam te stvarne podatke u bazi a tamo se i neće moći naći plomba koja je potrgana prilikom zamjene brojila niti brojilo koje je bilo ranije. Ako trebam neke detaljnije podatke o zamjeni brojila ( da se vidi koje je bilo staro brojilo to imam u aplikaciji pod tim ED brojem).
Sve ove promjene što se tiče plombiranja su popraćene posebnim zapisnicima na kojima stoji praktično sve šta je rađeno i to se odlaže u arhivu. Sa tih zapisnika se i unose podaci u bazu tako da i tu imamo određenu sigurnost ali naravno da se ne bi oni listali tu je baza koja daje brze podatke.
Bitno mi je da u ovoj mojoj bazi imam tačnu evidenciju koji kontrolor je koje i koliko plombi zadužio i koliko trenutno ima kod sebe "nerazduženih" tj ne postavljenih plombi.
@mpaja dobra je primjedba da plomba ne mora uvijek biti postavljena na nekakav ED broj ali i to se može rješiti tako da ako plombiraju ormar u zgradi sa više brojila ( što je rijedak slučaj) može se ta plomba vezati za ED broj zajedničke potrošnje te zgrade.
Zato mislim da koncept i idejno rješenje dijela baze koju sam ja napravio valjda nije toliko loš još kada bi se moglo rješiti to zaduženje u blokovima i razduženje pojedinačno i još ono "malo" što sam naveo.
Pozz.

---

Mislim da je postavljeni zadatak isuvise komplikovan da bi se resavao na forumu. Zadatak je dinamicke prirode. Trazi se da se prati zivot jende plombe. Takav zadatak se ne moze resiti standardnim postupkom normalizacije. Normalizacija lepo radi za staticke sisteme, gde se stvari ne menjaju kroz vreme, za dinamicke sisteme ne daje kompletno resenje.

Staticki sistemi su sitemi gde se prate dokumenti - narudzbe, fakture, racuni, prijemnice, otpremnice. To je ono sto Zoranov model veoma dobro pokriva. Toliko dobro da je model Zoran s razlogom generalizovao model. U pravim uslovima Zoranov model se moze primeniti kao sablon. Problem je kako prepoznati da li su uslovi pravi. Za to su potrebne godine iskustva, koje Zoran ima a postavljac pitanja ocigledno nema. Opasno je primeniti sablon bez razumevanja. Kako rece Marfi "gresiti je ljudski, ali da se stvarno zabrlja, potreban je komjuter"

Dinamicki sistemi prate dogadjaje, zapsiuje se kad se nesto dogodilo. U ovom zadatku, realni sitem, onaj koji posmatramo, jes okruzenje u zivotu jedne plombe. Taj sistem cine ga objekti i subjekti i njihove interakcije. Objekti su plombe i ono sto postavljac pitanja zove ED, kontrolori su subjekti. Interakcije ismedju subjekata i objekata su dogadjaji u realnom sistemu.

Opisimo ukratko zivot jedna plombe, tako sto cemo navesti najvaznije dogadjaje koji se mogu desiti. Plomba se negde napravi - dogadja 1. Dogadjaj 1 oznacava ulazak plombe u sistem, radjanje plombe. Zatim se plomba dodeli kontroloru, cime se on 'zaduzi', i to je dogadjaj 2. Kontolor plombu moze da postavi na neki ED, i tako se 'razduzi', sto je dogadjaj 3. Kontrolor moze da napusti posao ili se penzionise, a da nije razduzio sve plombe. U tom slucaju kontrolor vraca plombe u magacin - to je dogadjaj 4. Dogadjaj 4 nije pomenut u opseznom opisu problema, ali je nekako logicno ocekivati da se i takve stvari desavaju s vremena na vreme. Postoji i dogadjaj 'trganje plombe'. To se desava kad se plomba, namerno ili nenamerno, pokida. To je dogadjaj 5. POkidna plomba se vise ne moze korsititi. Ovo znaci da dogadjaj 'trganje plombe' znaci i smrt plombe. Ona se vise nece pojaviti niti upotrebiti. I to je manje vise sve. Kako da napravimo informacioni sistem koji omogucuje da se prati zivot jedne plombe? Setimo se , informacioni sistem cine baza podatak i aplikacija.

Pocnimo od baze podataka. treba nam baza koja adslikava realni sitemsto je moguce bolje. Postupak koji koristimo da generisemo shemu baze podatka za staticke sisteme ne daje rezultate u ovom slucaju. Postupak normalizacije nije pogresan i nigde nisam kazao da ga ne treba primeniti na dinamicke sisteme, taman posla. Za modelovanje dinamickih sistema, postupak normalizacije jeste neophodan, ali nije i dovoljan. Znaci, ono sto je Zoran ponudio nije pogresno, to jeste ispravan prvi korak i bez tog koraka se ne moze. Zoran je postavio temelj i mi treba da nastavimo da gradimo kucu na tom temelju. Kuca bez temelja ne moze da se gradi, ali sam temelj ne predstavlja kucu, nije dovoljan.

Muka je sto vecina programera ima problem da razume i normalizaciju, a kamoli sad nesto povrh toga.

Aplikacija bi trebala da radi sto manje, a da baza radi sto vise. Muka je sto Access ne moze da podrzi sve ono sto nam treba da bismo pravilno modelovali dinamicki sistem. Ako radimo u Accesu, neke stvari moracemo da uradimo na nivou aplikacije. Tu nam treba programiranje, ne neko expertsko, ali veoma solidno. Rekordseti, gradjenje SQL izraza kroz VB kod, pisanje i pozivanje korisnickih funkcija, te stvar ce nam trebati. Zakljucak je da ovo nije posao za pocetnika noti nesto sto se uci na forumu. Prva pomoc se uci na dvednevnom tecaju, a za medicinske nauke treba pet godina, pa jos nekoliko ako hocete da budete hirurg. Ovde pricamo o nivou hirurga. Znaci, morate da budete solidan doktor za Access da biste mogli da pokusate ovu hirurgiju.

Stoga ce prica, koja mozda sledi, biti za one koji i inace znaju puno, a hoce da nauce nesto vise. Prica i nije bas potpuno nova, bar na ovom forumu. Pricali smo o slicnoj situaciji kad smo govorili od zaduzenju i razduzenju osnovnih sredstava. Ovaj put se nadam da cela stvar izgleda jednostavnije, da se dozvoli da aplikacije kontrolise neke uslove, jer je u Accesu prekomplikovano da sve kontrolisemo na nivou tabela.

Da li da nastavimo ili ne?

još malo o plombiranju

Savet: uradite od početka onako kako treba ili nemojte uopšte raditi. Zoran je dao solidan temelj koji samo malo treba još ojačati a zašto to je Zidar odlično objasnio.

Plombe i njihova upotreba nose u realnom svetu i druge stvari i nije baš tako jednostavno reći "ako nema ED broj vezujem je za opšte potrošače" odnosno kućni savet zgrade ili sl. Morate misliti na pravne posledice toga i odgovornosti. Šta se dešava ako vam je neko iz bilo kojih namernih ili nenamernih, dobrih ili loših pobuda oštetio plombu i pokrene se postupak za recimo kradju struje koja se sada sankcioniše kao krivično delo? Da li u tom slučaju odgovaraju ljudi koji uopšte nisu ni znali da je neki monter Žika nešto prčkao oko njihovog brojila ili ormana i plombirao ga, razdužio se a vi lepo sve to ubacili u sistem a onda neki kontrolor našao da je neko izvršio nedelo i šta onda?

Kao što Zidar reče mora se odslikati realni svet i baratati sa podacima. Podaci nikada nisu stari i uvek postoji veza izmedju njih!

Aplikacija koja bi ovo sve podržavala nije amaterska i nije za početnike. Pretpostavljam da bi Zoranu ili Zidaru trebalo bar mesec dana da je doteraju da radi onako kako treba uz svo njihovo znanje i iskustvo a za vas je savet da počnete sa nečim malo jednostavnijim što nema ili ima jako malo posledica po široke narodne mase t.j. potrošače jer verujte mi na reč uvek se nešto iskomplikuje ako se ne uradi kako treba.

Ljudi, ne znam šta da Vam kažem.
Pogotovo na pitanje da li da nastavimo ili ne. Ja bih naravno žarko želio da se ovo nastavi.
Znam i svjestan sam da ste svi sa velikim iskustvom i znanjem što se tiče baze podataka i da sam ja na nivou "prve pomoći" ili bar "medicinske sestre" dok sam svjestan da ste vi na nivou "doktora" i "hirurga".
Strah me je i žao bi mi bilo jedino da nisam možda uspio da vam objasnim svoju zamisao te baze. Meni to barem opet ( da li zbog mog nedovoljnog znanja) ne izgleda tako drastično komplikovano da bi neko sa velikim iskustvom barem pokušao nešto rješiti.

Sada ovo LUPAM čisto da vidim da li bi se to moglo ovako rješiti.
@zidar je tu moju bazu opisao kao bazu dinamičke prirode sa životom jedne plombe od rađanja do smrti ali ja bih tu preskočio recimo rađanje i počeo od događaja br 2. a to je zaduženje plombe na kontrolora. Možda griješim ali to bi bilo zaduženje neke robe u magacin koji se zove kontrolor Marko Marković, i imao bih toliko magacina koliko imam kontrolora ( ili to može i drugčije zbilja ne znam). Znači u tom magacinu postoji nekakvo stanje robe koje se može znati u svakom trenutku. Kada kontrolor postavi plombu (tj. proda robu na komad iz magacina) stanje u magacinu se smanji za tolkio koliko je prodao. On je tu robu ( plombe) prodao potrošaču i to više komada istom potrošaču ali na različite adrese ( a adrese su djelovi mjernog mjesta) i za to ima evidenciju šta je, kome, gdje, kada i zbog čega prodao.
Postoji dakle jedan potrošač koji ima svoje stalne adrese (djelove mjernog mjesta, jer uvijek ima neko brojilo, pancer, ploču itd.). Za svaku tu adresu je dobio po jedan komad robe iz magacina Marka Markovića. Kada mu dosadi ( prevedeno potroši robu) na nekoj adresi on ponovo za tu adresu kupi i zavede robu iz magacina MM. Pošto je prethodnu robu potrošio, nje više nema (kontrolor zamjenio brojilo i potrgao staru plombu) na njeno mjesto kupuje drugu.
Priznajem da nisam razmišljao o situaciji koju je naveo @zidar a to je ako kontrolor ode u penziju sa zaduženim plombama , ali da li može biti neki način da se on razduži sa napomenom - vraćeno (neki status) pa da se za taj isti set plombi zaduži drugi kontrolor.

Takođe što se tiče @mpajine primjedbe za "ako nema ED broj vezujem je za opšte potrošače" ja sam naveo da bi je vezali za potrošača koji ima svoj ED broj a zove se Zajednička potrošnja zgrade.
A što se tiče pravne strane ovog čina plombiranja i odgovornosti to je oblast daleko kompleksnija od ovog svega ali to ne bi trebalo biti problem kod ove baze. Baza služi da znamo ko je kada i zašto postavio tamo plombu i za to postoji pisani dokument u arhivi - zapisnik sa opisom svega šta je rađeno, sa naljepnicom plombe i sa potpisima kontrolora i potrošača čije je mjerno mjesto ( naglašavam oba potpisa). Ukoliko dolazi do namjerne zamjene plombe ( zamjene brojila po nalogu itd) opet se pravi zapisnik sa svim. E sada ako je plomba potrgana (bez naloga) tu se priča razvija u više pravaca, jer ona može biti potrgana zato da bi potrošač nešto odradio i stekao materijalnu korist ili recimo može biti potrgana od strane namćor komšije da bi napakostio drugima. Ali niko ne može dežurati kraj svake plombe pa samim tim ako se nađe takav slučaj to je onda predmet istrage drugih organa ( policije i pravosuđa) da utvrde ko je to uradio kao i kod svakog drugog krivičnog djela (pljačke kioska idr.). Tu kontrolor ne može imati nekakvu odgovornost. Njegova odgovornost je ako se pod ispravnom plombom nađe nepravilnost a tu plombu on postavio a mi to vidimo u bazi.
Mi u slučajevima potrgane plombe od starne potrošača nakon sve procedure ponovo plombiramo to mjesto naravno sa zapisnikom i prodajemo robu iz magacina MM samo je drugi razlog prodaje.
To bi okvirno bilo to , opet kažem, ispravite me možda griješim ali da li je ovo išta više dinamično od recimo prodaje piva iz magacina potrošaču koji ima više adresa i da se ima evidencija o tom.

Dao sam primjer u Excelu kako smo to do sada vodili, gdje ima jedna stranica zaduženjai gdje se unose plombe od-do, jedna stranica analize gdje se vidi koliko je plombi zadužio i koliko ima kod sebe i jedna stranica gdje se unosi sam čin plomb. i gdje unosom broja plombe automatski se pojavljuje ime kontrolora i on se razdužuje za jenu plombu u kartici analiza. Ovakav način sam pokušao izbjeći i to riješiti bazom da bi se izbjegla redudandnost podataka tj. ako bi trebalo kod jednog potrošača unijeti više plombi onda svaki put treba ponavljati i njegov ED ,ime,mjesto itd. Zbog toga veličina fajla se povećava, otežana je pretraga teže je unositi podatke itd i ja sam htio to poboljšati i od toga ne odustajem.

Zbog toga bih volio da se ova tema nastavi jer mošda neko ima zamisao i rješenje da napravi nešto od onog mog početnog primjera.
Još jednom kažem, žao bi mi bilo ako sam svojim neumjećem da dokažem jednostavnost svoje zamisli skrenuo tok ove teme i od nje napravio komplikovanost do bola.
U svakom slučaju, da li neko pokušao da mi pomogne ili ne ( a smatram i ove dosadašnje odgovore kao veliku pomoć i hvala na tom, jer svaka rasprava je korak do rješenja - pozitivnog ili negativnog nije bitno jer rješenje je rješenje) ja i dalje smatram da je ovo najbolji forum na prostorima EX-Yu a i dalje i želim vam svaku sreću u daljnjem radu i ne odustajem od Vas.
Pozz

---

Granica sistema je suština i ona određuje koliko i dokle će se ići. Predlaganjem prvog modela bio sam rastrgnut s jedne strane željom da se pomogne a s drugom da se uradi kako treba. Pravo resenje je resenje koje pomogne. Ćesto granica sistema predstavlja ograničavajući faktor. Koliko sam shvatio pokretača teme on se dosta ograničio od realnog sistema i postavio je granicu na svoj način, da li je dobro ili ne, odgovor je i sam postavljač dao, kao i kolege @mpaja i @Zidar.



O ovome Vam je kolega @Zidar dosta rekao. Ja bih samo dodao da predloženi model predstavlja zadovoljenje pravila modeliranja sa što manje programiranja ("Najbolji kod je bez kodiranja" - @Zidar).

Pretpostavio sam vašu reakciju te sam s toga upriličio primer do nivo prototipa. Prilikom toga sam malo korigovao model, ali i dalje držeći se ideje da ostane okosnica nekog budućeg.



U ovom modelu sam označio žutom bojom entitete koji bi možda trebalo da se zovu drugačije.
Plombiranje -> RazduzenjePlombe
MjestoPlombiranja -> MjestoRazduzenja
RazlogPlombiranja -> RazlogRazduzenja

U tim tabelama kojima nisam promenio ime ubacio sam n-torke koje ukazuju zašto bi trebalo promeniti nazive entiteta.
Npr. u tabeli RazlogRazduzenja ima oštećenje plombe ...

E sada ako je to tako tada entitet Plombiranje bi bio RazduzenjePlombe i u tom slučaju, model bi mogao i dalje da se optimizuje generalizovanjem entiteta ZaduzenjePlombe i RazduzenjePlombe u generalizovan entitet Dokument sa entitetom diskriminacije VrstaDokumenta... O ovome sam već govorio u drugim temama.

---

Samo kratko da se nadovežem na Zoranovu konstataciju oko neophodnosti postavljanja granice sistema. Ono što se često zaboravlja kada se analizira neki poslovni problem, koji treba automatizovati bazom podataka, je funkcionalno modelovanje. Njime se definišu aktivnosti, potom ulazi (najčešće informacije ali ne samo one), kontrole (zakoni, pravila, propisi), izlazi (takođe najčešće informacije) i mehanizmi (najčešće osobe sa potrebnim kvalifikacijama koje obavljaju navedene aktivnosti.

Da se u slučaju ovog poslovnog problema pošlo redom, u jednom momentu bi se kroz dekompoziciju aktivnosti shvatilo da li je to statički ili dinamički sistem, već u zavisnosti od toga da li će neki budući entitet menjati svoje stanje kroz vreme i događaje.

Jedan od svetlih primera, kojeg se sećam na ovom forumu, a da je pravilno postavljen od početka granicama sistema je projektovanje informacionog sistema biblioteke, kolege Ivana Biševca (biske86). http://www.elitesecurity.org/t337481-0-Biblioteka-baza-podataka

Sve o funkcionalnom ali i o informacionom modelovanju može se pročitati iz knjige Razvoj informacionih sistema i baze podataka, Alempije Veljovic, 246 strana, PDF format. http://www.cafe022.com/mybb/ra...lempije-veljovic-246-t-37.html

Na ovu knjigu smo Zoran i ja više puta upućivali.

Na kraju da pozovem Zidara da nastavi sa izlaganjem na temu dinamičkih sistema.

_{[Ovu poruku je menjao Getsbi dana 23.08.2011. u 15:45 GMT+1]}

---

U prethodnom postu pomenuh, moje viđenje i stigoh da uradim.

---

OK, nastavicemo sa pricom. Trenutno sam u mnooogo velikoj guzvi na poslu, pa verovatno danas necu moci mnogo da uradim, ali bice u toku dana sutrasnjeg svakako. Poci cemo od poslednjeg modela koji je Zoran postavio. Model zadovoljava sva pravila normalizacije i tu nema sta da se prigovori. Ipak, postoje pitanja na koje takav model ne moze da odgovori. Nije do Zorana, do samog metoda modeliranja je. Metod modeliranja ne daje mogucnost da se na zadovoljavajuci nacin prate promene u sistemu.

Kao u matematici, algebra (osnovbne operacije, polinomi, trigonometrija, transcedentne funkcije) nije dovoljnan za resavanje nekih problema iz fizike, ponekad je potrebna matematicka analiza (izvodi i integrali). Matematicka analiza (calculus) je razvijen da bi se resili problemi iz fizike koji se bave kretanjem, brzinom i ubrzanjem. Obicna algebra nije dovoljna. Ovo ne znaci da je algebra jednostavna ili manje vredna od analize, niposto, samo znaci da ze razlicite probleme potrebne su razlicite tehnike. Matematika je veoma stara nauka, preko 5,000 godina i postoje resanja za mnogo prakticnih problema. Relaciiona teorija i relacione baze podataka postoje tek 30-40 godina i tek mali deo onoga sto realnom svetu treba je razresen. Mi se ovde bavimo necim sto u dosadasnjoj teoriji nije razreseno. Izraz 'dinamicki sistem' zato nigde necete naci u literarturi, jer literature o tome nema. Ja sam ga izmislio za nase potrebe, jer mi se cini da najbolje opisuje prirodu problema koji pokusavamo da resimo. Strpite se koji sat ili do sutra, pa idemo dalje.

Cela prica se moze svesti na nekoliko recenica. U najkracem:

1. Kontrolori zaduzuju plombe.
2. Kontrolori razduzuju plombe

Ovo se moze predstaviti ovako:

sto daje ovu shemu tabela:

Dodajmo malo detalja:
1.A Kontrolori zadzuuju plombe, odredjenog dana.
2.A. Kontrolori razduzuju plombe odredjenog dana tako sto ih ugrade na merno mesto (EDBroj).
Ocigledan uslov: 3.) Moze se razduziti samo plomba koja je zaduzena.
Izmenjene recenice i dodatni uslov daju ovo:



Posto razduzenje podrazumeva da se zna gde je to plomba razduzene, u stvari ugradjena, modelu treba dodati jos jednu tabelu. Ovo sve kod Zorana postoji, samo se teze vidi jer ima mnogo drugih tabela koje su vazne, ali ne za ovako pojednostavljenu sliku.



To je u sustini ono sto Zoranov model pokriva, ako eliminisamo detalje i formalnosti. Detalji i formalnosti jesu vazni, za fizicku implementaciju. Na ovom nivou, mozemo bez njih.

Zoranov model podrazumeva da dogadaj zaduzenja i dogadjaj predstavljamo dokumentima, koje nazivamo Zaduzenje i Razduzenje, sto je potpuno ispravno. To se sa moje sheme ne vidi, ali to je to. Ovde mozemo da stanemo i da zavrsimo posao. Sa ovakvim modelom moguce je napraviti ono sto je pokretac teme trazioo - bazu koja omogucuje da se zaduzuju kontrolori i da se prati razduzenje (ugradjivanje). Potrgane plombe ignorisemo, razduzenje bez ugradjivanja takodje ignorisemo.

U svakom momentu mozemo da napravimo kveri koji uporedjuje zaduzene i razduzene plombe. Sve plombe koje nisu razduzene, a imamo ih u zaduzenju, mozemo da prebrojimo. To daje odgovor na pitanje 'ko ima koliko plombi'.

Problem dodeljivanja plombi u paketima je problem unosenja rekorda u tabelu Zaduzenja. Nije nam potrebna nikakva posebna tabela za ovo, iako je Zoran i to predvideo svojim modelom. S obzirom da verovatno o toj akciji postoji dokument, Zoran je verovatno u pravu.

Dakle, moze i Zoranov model, ako se ogranicimo na dva moguca dogadjaja, zaduzenje i razduzenje. Preporucujem da co.marac ovde zastane i napravi bazu i aplikaciju po Zoranovom modelu. Modelovanje dinamickog sistema pokazaceo kao nesto sto se moze primeniti tamo gde su uslovi stroziji, gde su granice sistema sire.

Ja cu da ispricam kako to moze da ide a onda da vidimo moze li Zoran to da uklopi u svoj model. ako moze, bilo bi to sjajno, dobili bismo ozbiljan model za ozbiljne igrace.



<sub>[Ovu poruku je menjao Zidar dana 23.08.2011. u 21:51 GMT+1]

[Ovu poruku je menjao Zidar dana 23.08.2011. u 22:02 GMT+1]</sub>

Vec smo opisali zivot jedne plombe kroz niz dogadjaja. Dogadjaji dovode do prmene stanja. Doagadjaji u zivotu jedne plombe mogu se predstaviti dijagramom promene stanja. Ovali predstavljaju stanja kroz koja moze proci plomba. Strelice predstavljaju dogadjaje ili akcije koji dovode do promene stanja.

Dijagram promene stanja ne dovodi do sheme baze podataka, kao sto to radi dijagram objekti-veze. Dijagram promene stanja nam kazuje da cemo za svaku akciju ili dogadjaj morati da imamo posebnu proceduru za unos podataka. AKo znamo gde i kako s eu relanom sistemu odvijaju dogadjaji, mozemo da zakljucimo i koliko aplikacija nam treba.

Sa dijagrama vidim da mi treba procedura/forma za unos podataka o zaduzenju. Onda vidim da mi treba procedura/forma za unos podataka o postavljanju plombe na merno mesto. treba mi i procedura za upisivanje podataka o nelegalno potrganim plombama, ako se takav slucaj desi. Naravno, legalno skidanje plombe da bi se promenio strujomer ili nesto legalno radilo, treba nam i to. Ako se kontrolor razduzuje tako sto vrati plombe u magacin, i to nam treba. Sve ove akcije en moraju s eodvijati na jednom mestu, pa o tome treba razmisliti. Ja zamisljam web aplikaciju, tako da kad kontrolor ode na lice mesta i ugradi/potrga formu, to moze preko Iphon-a ili Blackberry teklefona da uradi preko interneta. Zaduzenje i vracanje u magacin mogu da postioje u lokalnoj magacinskoj aplikaciji, ne mora da idu na internet na primer.

Treba nauciti dve stvari: 1) tehniku crtanja dijagrama 2) da uocimo dinamiku u sistemu i prenesemo je na dijagram
Tehnika je laka - imamo smao dva simbola, oval za stanja i strelice za diogadjaje. Ako smo vredni, mozemo na strelicama da opisemo dogadjaje. Drugi deo je utuvimo u glavu da se sve menja i da da se promene vide kao prelazak posmatranog objekta/entiteta iz stanja u stanje. Kao u matematici, algebra funkciju predstavlja sa y = f(x) a analiza kaze y' = dy/dx. treba da naucimo da ne posmatramo stvari u jednom trenutku, nego kroz vreme. Sa y = f(t) prelazimo na y' = dy/dt. Uz malo vezbe, valjda ce i to da krene.

Sve je to lepo, ali sta da radimo da dobijemo shemu baze podataka? Kroz dosadaasje iskustvo na dinamickim sistemima, izgleda da se sve radi na isti kalup. Svi dinamicki sistemi gde se prati jedan entitet izgleda da imaju istu strukturu. Biblioteka, rentanje automobila i video kaseta, osnovna stredstva, plombe, vodomeri - svi imaju gortovo identicnu strukturu tabela. Ako bi usvojili genericke nazive kolona i tabela, jedna ista struktura bi se bukvalno mogla prenositi sa projekta na projekat. tko bar za sada izgleda, dok neko pametniji od mene ne izadje sa matematickim dokazima i resenjima.

Kad smo pre nekoliko meseci imali temu o pracenju osnovnih sredstava, dali smo jednu prilicno kompletnu ail i i veoma komplikovanu sliku. Sad cemo pokusati da pojednostavimo pricu. Necemo na silu gurati bas sva ogranicenja na nivo tabela, posto Access ne moze da podrzi sve sto nam treba. Sto moze, ici ce kroz tabele, relacije i Vlidation Rules. Sto ne moze, ici ce kroz forme i kod.

To zahteva novi post, sutra, sada moram da idem.

Uvek sam voleo nešto izazovno i za mene nepoznato...

---

Pre novog posta odradio sam bazu po modelu Dokument i uradio sam model procesa IDEF0 metodom iz kojeg se mogu naslutiti budući entiteti, naravno sa onim informacijama koje smo dobili do sada.

---

Jedna sugestija u vezi funkcionalnog modela. Pošto se na prvom nivou u 3. aktivnosti "EVIDENTIRANJE POTROSACA I ED BROJA" već pominje potrošač, što je u redu, predlažem da se aktivnosti 1.3 na drugom nivou promeni naziv u "EVIDENTIRANJE LOKACIJA I BROJILA". Ovo bi bilo u skladu sa realnošću, jer je lokacija starija od potrošaća. Prvo se napravi stambena zgrada sa instalacijama i brojilima, a onda se kupoprodajom usluge vezuje brojilo i potrošač preko ED broja.

---

Red je da se i ja kao pokretač ove teme javim mada pretpostavljam da ste svjesni da ovo trenutno ode izvan okvira mog razumjevanja vaše diskusije.
Ljudi moji svaka čast.
Drago mi je što se ovo ovako razvija jer nisam ja tu više bitan, drago mi je jer vidim da se probava pronaći rješenje za neku novu situaciju i neki novi problem koja do sada nije bio, drago mi je jer iz ovoga će mnogi drugi doći do nekih novih saznanja i iz tih razloga želio bih da samo tako nastavite.
Ja ću polako to sve da pratim a zadržaću se kao što mi je savjetovao @Zidar na onom modelu baze od Zorana i nju ću pokušati da „svarim“ i grafički prilagodim operaterima, da napravim nešto upita, izvještaja ...
S toga ako ne budem često dalje postovao nemoj te mi zamjeriti , ja sam tu, a i ne bih htio nešto prekidati svojim ne doraslim upadima.
Pozz.

---

Ako ste se uhvatili u koštac s time da aplicirate neki poslovni proces nije loše da pogledate jedan od puteva rešavanja problema http://www.elitesecurity.org/t166884-0#2720176.
U diskusiji koja je pokrenuta prikazane su metode koje mogu poslužiti i drugima, kao što ste dobro uočili.
U to ime da nastavimo dalje, pa uvažavam predlog kolege @Getsbi-ja da izmenim naziv procesa. Inače imenovanje objekata je najteži posao kojim sam se susreo u analizama.
A vama kolega @Co.marac šaljem male izmene i dodatke.

---