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.

Da nastavim pricu o zivotu plombe. Poceli smo od dijagrama promene stanja. Brojevima smo oznacili ovale.

Slika predstavlaj graf. Graf ima temena, cvorove (ovali na slici) i grane (strelice na slici). Strelice ukazuju na smer promene stanja, pa kazemo da je graf orjentisan. Svaka strelica ima pocetni cvori zavrsni cvor.

Dijagram govori mnogo o precesu. Vidimo na primer, da se iz stanja "u magacinu" moze preci u stanje "Zaduzen kontrolor", i obratno. Iz stanja "Zaduzen kontrolor" mozemo ici i u stanje "Ugradjena plomba" ali ne i u "potgrana legalno" ili "potrgana ilegalno". Stanja "kontrolor skinuo plombu" i "plomba potrgana ilegalno" su finalna stanja. Iz njih ne izlazi ni jedna strelica. Ako bi mogao jedan kontrolor da preda drugom kontroloru plombe, i tako se razduzi, ond bismo imali strelicu koja ide iz "zaduzen kontrolor" nazad u isti oval.

Primetimo da neke akcije zahtevaju cuvanje i dodatnih podataka. Na primer, ako plomba predje u stabje "Zaduzen kontrolor" jasno je da zelimo da znamo koji kontrolor je zaduzen za konkretnu plombu.

Za opis samog dijagrama u bazi trebace nam dve tabele. Jedna ce da cuva lsitu mogucih stanja, a druga moguce promene stanja.


Dve tabele su u vezi, u relaciji, ovako:


Ovim smo definisali vazna ogranicenja u sistemu. Samo unapred dozvoljene promene su dozvoljene.

Sad mozemo da predjemo na glavnu tabelu, gde cemo pratiti promene stanja.

Za pracenje promena stanja, ovakva tabela bi dobrodosla:



Ovo bi bio neki dnevnik, koji vodi sef kontrolora. Iz tabele (dnevnika) vidimo da je:
1) u magacin uslo 7 plombi na dan 3/1/2011 (Stanje 1 = "usla u magacin")
2) na dan 3/10/2011 plombe 1,2, i 4 su predate kontroloru Ziki, a plomba 2 je predata kontroloru Peri
3) dana 3/15/2011 plomba 3 je ugradjena na uredjaj ED5555. Plombu je ugradio onaj ko ju je prethodno zaduzio.
4) dana 4/15/2011 plombe 1 i 3 su ugradjene na ED12345 i ED8002. Ugradio ih je onaj ko ih ju je prethodno zaduzio.
5) dana 4/15/2011, plomba 4 je vracena u magacin. Vratio je onaj ko ju je zaduzio.
6) dana 6/18/2011 utvrdjeno je da je plomba 2 potrgana sa mesta na koje je bila postavljena. To je konstatovao kontrolor Laza.
7) dana 9/10/2011 kontrolor Mika je legalno skinuo plombu 3, sa mesta nakome je bila postavljena.

Ako sortiramo tabelu po (Plomba, datumStanja) mozemo da vidimo istoriju zivota svake plombe.


Sta jos mozemo da vidimo iz nase tabele PreomeneStanja, ovako kakva je?

Iz pokazane tabele, Moguce je napisati kverije koji pokazuju, izmedju ostalog:
1. koje plombe su u magacinu =>one cijje polednje stanje je 1
2. koje plombe su nerazduzene (jos uvek su kod kontrolora) => one cije poslednje stanje je 2
3. koje plombe su ugradjene => one cije poslednje stanje je 3
4. koliko plombi ima koji kontrolor => pogledaj nerazduzene plombe (tacka 2.), pa prebroj po kontrolorima

Nazalost, tesko je napisati kveri koji direktno daje odgovor na postavljena pitanja. Treba nam prvo pomocni kveri koji pokzuje poslednja stanja za svaku plombu, qryPoslednjeStanjePlombi. Namerno ne pisem taj kveri, to za sada ostavljam citaocima ;-) . Iz kverija qryPoslednjeStanjePlombi direktno dobijamo odgovore na pitanja kao sto su 1,2,3. Za tacku 4. treba nam

Pitanje 4. je ono sto je postavljac teme pitao na pocetku. To, i mnogo vise, moze da se dobije iz predlozene tabele. Ali, kveriji nisu jednostavni. Zato smo i rekli da ovo nije za pocetnike. Medjutim, kveriji se jednom napisu i posle vas ne boli glava. Mnogo veci problem je je sto se lako gresi pri upisu u ovakvu tabelu. Da se ne bi bas mnogo gresilo, moramo da postavimo neka ogranicenja. O tome u sledecem postu.




<sub>[Ovu poruku je menjao Zidar dana 25.08.2011. u 23:10 GMT+1]

[Ovu poruku je menjao Zidar dana 25.08.2011. u 23:13 GMT+1]

[Ovu poruku je menjao Zidar dana 25.08.2011. u 23:18 GMT+1]</sub>

Svaka čast na ovakvoj razradi puta (života) plombe.
Obuhvaćene su sva situacije koje se mogu desiti sa plombom.
Još dolazim sebi (pokušavam vas pratiti ali vi odoste)
Pozz

Nisam zaboravio na temu, ne stizem da napisem valjan post. Od petka sam ga tri puta pisao i bacao u kos. Ako Bog da, danas ce biti ensto.

Evo nas nazad na temi. Poslednje sto smo pokazali je bile tabel u kojoj s evodi dnevnik zaduzenja i razduzenja plombi. Da bi sve radilo kako treba, tabela je malo slozenija.


Tabela PromeneStanja se povezuje sa ostalim tabelama ovako:



Ova slika je vazna jer je univerzalna. Ako zamenite res 'Plomba' sa na primer 'Automobil' dobicete shemu tabela koje prate automobile u rental firmi, ili knjige u biblioteci, ili osnovna sredstva, sta bilo. Znaci, ovaj deo sheme je univerzalan po strukturi. Naravno da su za automobile i plombe dijagrami promene stanja razliciti. Te razlike se svode na popunjavanje tabela Stanja i DozvoljenePromeneStanja. Znaci, ne menjamo strukturu baze, menjamo podatke.

Posto je ovaj deo sheme univerzalan, onda moze Zoran da vidi da li bi ovo islu ili ne uz njegov model.

Za lakse razumevanje, doajmo slike strukture indeksa i validacije na nivou tabele za PromeneStanja.




Mi nismo jos zavrsili. Shema relacija se moze kompletirati dodvanjem table za Kontrolore i MernaMesta.



Ova shema vise nije univerzalna. Dodali smo dve tabele, Kontrolori i MernaMesta, koje kontrolisu sta se unosi u odgovarajuce kolone u PromeneStanja. Nije dovoljno da se kontrolise sta se unosi, nego i kada se unosi. Merno mesto ima smisla unesti samo kada smo usli u stanje "plomba ugradjena', a ne smemo ga uneti an primer kad udjemo u stanje "kontrolor zaduzio plombu'. Slicno razmisljanje vazi i za Kontrolore. U nekim situacijam, obavezno je uneti kontrolora, a u nekim se nikako ne sme uneti kontrolor. Sta gde sme i kada, to najbolje zna onaj ko razvija sistem. Ovaj do moze da se ostavi za front end, a moze i da se resi na nivou tabela. Pokazacemo kako se resava na nivou tabela. U pocetko ce verovatno biti lakse da se to radi na front endu. Ako nist drugo, ono zato sto Access ne nudi prevelike mogucnosti za validaciju na nivou tabele. U MS SQL, to bi bile CHECK CONSTRAINTS, koje u Accessu iamo nesto malo kroz field validation rule i jos manje kroz table validation rule. To cemo da ostavimo za sutra.

Sada kratka rekapitulacija.

Rekapitulacija:
1. Kreirati tabele kao u primeru (bez podataka)
2. Dodati kljuceve i relacije kao u primeru.
3. Za tabelu PromeneSTanja ne zaboraviti validaciju DatumStarogSTanja <= DatumSTanja na nivou tabele (table ValidationRule).

Priprema podatka :
1. Nacrtati diagram promene stanja. Bar jedno stanje mora biti pocetno. Pocetno stanje je on iz koga izlazi jedna ili vise strelica a ne ulazi ni jedna.
2. Popuniti tabelu Stanja. Svaki cvor dijagrama dobija jedan redu u tabeli Stanja.
3. Popuniti tabelu Dozvoljene PromaneStanja. Za pocetno stanje staviti PocetnoStanje = ZavrsnoStanje. Za ostala stanja, uneti podatke saglasno dijagramu.

Unos podataka:
1. Za svaku plombu, prvi red uneti Stanje=StaroStanje=1 , datumStanja=DatumStarogStanja
2. Za svaki sledeci red, prepisati u StaroStanje vrednost iz kolone Stanje iz prethodng reda za posmatranu plombu. Upisati DatumStarogStanja iz kolone DatumStanja iz prethodnog reda za posmatranu plombu.

Ima mnogo kucanja i lako se gresi pri unosu, ali ce vas Access spreciti da unesete gluposti. Pokazacemo posle vikenda kako se programski sakriva kompleksnost modela i kako je u stvari i nije posebno tesko.

Zaboravio sam da zakacim Access fajl.



<sub>[Ovu poruku je menjao Zidar dana 01.09.2011. u 22:52 GMT+1]

[Ovu poruku je menjao Zidar dana 01.09.2011. u 23:25 GMT+1]</sub>

Posebni uslovi

Univerzalna slika se prilagodjava konkretnom zadatku tako sto se u tabelu PromeneStanja dodaju kolone i dodjemo nove tabele u shemu. U nasem slucaju, dodatni uslovi su:

1. za neka stanja potrebno je upisati kontrolora => kolona PromeneStanja.Kontrolor
2. za neka stanja potrebno je upisati merno mesto, brojilo => kolona PromeneStanja.MernoMesto

Pre svega, merno mesto i brojilo moraju da pripadaju skupu dozvoljenih vrednosti. To nam daju relacije na slici:



Medjutim, to nije dovoljno. Rekli smo da "Nije dovoljno da se kontrolise sta se unosi, nego i kada se unosi. Merno mesto ima smisla unesti samo kada smo usli u stanje "plomba ugradjena', a ne smemo ga uneti an primer kad udjemo u stanje "kontrolor zaduzio plombu'. Slicno razmisljanje vazi i za Kontrolore. U nekim situacijam, obavezno je uneti kontrolora, a u nekim se nikako ne sme uneti kontrolor."

Da resimo problem kontrolora.
Stanje 1: plomba usla u magacin - ne treba kontrolor. cak i ako je kontrolor vratio plombu u magacin, mi znamo ko je imao tu plombu pre vracanaj, pa nam ne treba upis
Stanje 2 - kontrolor zaduzio plombu - koji kontroor? => treba kontrolor
Stanje 3 - plomba ugradjen - plombu moze da ugradi samo onaj ko ju je zaduzio, znaci znamo kontrolora, pa ga ne treba upisivati
Stanje 4 - plomba potrgana ilegalno, culi smo od kontrolora - kojeg? => treba kontrolor
Stanje 5 - plombu legalno skinuo kontrolor - koji? (Plombu Postavio Zika a skinuo je Mika) => treba kontrolor

Imamo dve grup stanja: (1,3) - ne treba, ne sme kontrolor i (2,4,5) gde je kontrolor obavezan. Ovo se svodi na dva iskaza koje treba da posmatramo jednovremeno:
"Plomba je u stanju (2,3,5)", "Kontrolor postoji". Ako zelimo da budemo formalni, ond
"Stanje IN (2,3,5)" i "Kontrolor IS NOT NULL".
Oba iskaza mogu biti TRUE ili FALSE, sto nam daje 4 moguce kombinacije:


Pogledajmo napisane kombinacije i oznacimo koje su valjane a koje ne:


Dve kombinacije su valjane, oznacili smo ihsa DA. Znaci, valana je kombinacija 1 OR kombinacija 4.To bi u validaciji na nivou tabele zapisali ovako nekako:


Kako vec imamo jedan ulov na nivou tabele (DatumStanja >= DatumStarogStanja), mora da vazi stari ualov AND ovaj novi , imamo:


Ovde treba biti pazljiv, Access ne dozvoljava da se baz lako napise ovaj izraz. Sa novim ogranicenjem, ne mozemo vise upsivati kontrolore gde hocemo, nego gde smemo. Takodje ih ne mozemo obrisati kad ih unesemo. Jos uvek mozemo da promenimo kontrolora, pa plombu vise ne duzi Mika nego Zika. Za sada, i to mora da se odradi na front endu.

Mozemo istu logiku i isti postupa primeniti i na MernaMesta, i dobiti jso slozeniji izraz u tabel validation rule. Access nas ogranicava na 255 karaktera mislim, pa bas i nema puno mesta za manevrisanje. Zato smo kazali na pocetku da se dodani problemi resavaju na front endu.

Jos jedan uslov se za sada ne moze odraditi na nivou tabela. Jedan kontrolor moze imati bezbroj plombi. Ali, jedno merno mesto u datom trenutku moze imati samo jednu plombu. To isto mora u kodu.

kad pogledamo koliko stvari mora u kodu da se resi, onda s eisplati pomuciti s ei sto je moguce vise uslova resiti na nivou tabela. Ostaje dovoljno mesta za programiranje, i predovoljno.

Opet malo o plombama, da ne bude zabune

Zidar je odlično postavio stvari s jednom malom nepreciznošću.

Jedno merno mesto može imati više plombi. Npr: na brojčaniku, na poklopcu klema, na MTK brojilu, na poklopci šina itd...

To treba uzeti u obzir

Da li sam dobro razumeo?!?!
1. Da li je jedno merno mesto jednoznačno označeno EDBroj-em? Ako je to tako onda kojem mernom mestu ili EDBroj-u pripada mesto plombiranja MTK brojilo? Ovo pitam iz razloga tog što kod mene u zgradi postoji ormar koji u sebi ima 5 brojila i svako ima svoj EDBroj tj u ovom slučaju 5 mernih mesta, a samo jedan MTK uređaj (ovo slučajno znam jer sam imao problema sa tim MTK)?!?
2. Ako jedno merno mesto može imati više plombi, a to znači da može imati više mesta plombiranja. Da li tada jedno merno mesto može imati 2 puta isto ime mesta plombiranja (ili kako sam u modelu imenovao MjestoRazduzenjaPlombe)? Npr: ID=13, Naziv="Zaštitna plastika".

ps: @Zidar da razjasnim prvo ovo pitanje pa ću odgovoriti vezano za model koji ste predložili u odnosu na model koji sam postavio.

Evo da ja uskočim barem sa ovim tehničkim djelom što se tiče načina plombiranja
Prvo odgovor na pitanje broj 1:
Tačno je da je jedno mjerno mjesto jednoznačno označeno ED brojem.
Kod nas a vjerujem da je tako svagdje u zgradama gdje ima više brojila ( više ED brojeva) postoji uvijek prijavljeno i brojilo od zajedničke potrošnje (rasvjeta stubišta, lift itd) i ono ima svoj ED broj. Tome mjernom mjestu uvijek pripada i uklopni sat ili MTK (gdje ga ima) koji je zajednički za sve stanare tako da je mislim riješena dilema kojem ED broju pridružiti plombu kojom je plombiran uklopni sat u zgradi.
A sada u vezi pitanja br 2:
Takođe postoji mogućnost da jedno mjerno mjesto može imati više puta isto ime mjesta plombiranja npr. na jednom mjernom mjestu se plombira recimo zaštitna plastika ali ako je ona velika da bi se dobro plombirala ( isključila mogućnost bilo kakvog pristupa mjerenju a da se ne ošteti plomba a to se može uraditi ako je plombirana jednom plombom a postoji mogućnost da se sa druge strane popuste vijci i ona zakrene te tako se pristupi mjerenju) mora se plombirati sa još plombi tako da jedno mjerno mjesto može imati više plombi koje su plombirale samo tu zaštitnu plastiku ili šta već.
Pozz

Jos malo o plombama

Mislim da su kolege shvatile da cak i brojilo koje ima jedinstven ED broj moze imati vise plombi na sebi (zastitni pokopac klema i recimo plastika brojcanika). Obratite paznju da se plomba moze upotrebiti a da ne bude vezana za ED broj a to je slucaj kada se plombira nemereni deo razvodnog ormana ili bolje receno onaj deo gde je glavni napojni kabal spojen na lokalni razvod ormana (tu nema ED broja, nema potrosaca koji se moze zaduziti - cak ni zajednicka potrosnja). Na tom delu se moze nalaziti vise plombi a najmanje jedna.

Sto se tice MTK uredjaja ili ukopnog sata on se napaja preko ovog dela ormana sto znaci da se njegova potrosnja ne racuna u zajednicku potrosnju zgrade odnosno ne pripisuje se potrosnji ukoliko se radi o pojedinacnom brojilu (kucno brojilo na primer). Osigurac za ovaj uredjaj se nalazi u nemerenom delu i nije dostupan potrosacima sto znaci da cemo imati bar jednu plombu za osigurac MTK+plombu za poklopac klema MTK+plomba za plastiku displeja sto sve zajedno cini bar 3 plombe koje ne pripadaiju "nikome" odnosno na zaduzenju su distribucije a ne vezuju se za konkretnog potrosaca.

Sve ovo se nalazi na jednom mernom mestu koje ima svoj adresni kod, ulicu i broj, Ptt broj, mesto i dr. sto znaci da na jednom mernom mestu imamo n plombi koje mogu da pripadaju potrosacima i m plombi koje ne pripadaju potrosacima odnosno pripadaju distribuciji.

Idemo dalje!

Mali primer

Merno mesto ima sledece podatke:

kod 12344
ul. Pere Perica
br. 12
slovo: c
PTT: 18230
mesto: Niš

i ostali dodatni podaci

Ovo su podaci koji relevantni i dovoljni za on oga ko se brine da izvrsi isporuku energije, da izvrsi naplatu, da dostvi obaveštenja i sl. Očigledno je da je merno mesto vezano za objekat za koji se vrši isporuka energije i po pravilu svaki objekat ima svoj napojni kabal koji se na jednom kraju vezuje u objektu a na drugom na distributivnu mrezu. Nije mi poznat slučaj da dva objekta koriste jedan isti napojni kabal čak i u Bgd.

Sledeće.

Na jednom mernom mestu se može nalaziti više potrošača (firme, pojedinci, zajednica) koji imaju svoje jednoznačne ED brojeve što znači da su ti potrošači legalno priključeni na distributivnu mrežu i da postoji ugovorna obaveza sa uslovima za isporuku el. energije. Nije ograničeno koliko se može potrošača naći na jednom objektu odnosno mernom mestu.

Na istom mestu se nalazi i instalacija i oprema koja ne pripada potrošačima odnosno pripada distribuciji i preko nje se vrši isporuka energije (priključne kleme, razvod i dr.). Obratite paznju da MTK nije u vlasnistvu potrosaca i da potrosac ne može sa njim raspolagati iako isti kupuje i ugradjuje i "poklanja " distribuciji. Sa MTK raspolaže i sa njim upravlja distribucija a potrošač može samo da ga vizuelno kontroliše i da se žali na ispravnost. Takav je princip i za ostale uredjaje koji se nalaze kod potrošača

Za sve ostalo važi ono što su kolege ranije odgovorile

Jos jednom idemo dalje!

Da li se iz navedenog moze zakljuciti da merno mesto ima jedinstveni identifikacioni kod "12344" i da u stvari merno mesto ima jedinstvenu adresnu identifikaciju a ne EDBroj?

Jos malo o mernom mestu i ED broju

Postoji jedinstvenost za merno mesto. Kod koji se nalazi uz njega moze biti PAK kod ako se preuzima od PTT ili ga daje lokalna distribucija jer negde nema PK kodova. ED broj je takodje jedinstven i on odredjuje ugovornog potrošača (jedan ugovor jedan ED broj!).

Na jednom mernom mestu može biti više potrošača sa ED brojevima ali se ne može pojaviti jedan potrošač sa ED brojem na više mernih mesta.

Obratite pažnju da potrošač (npr Z. Eremija) može imati više ED brojeva i da oni mogu da se nalaze na istom mernom mestu a mogu biti i na različitima. Nema ograničenja koliko jedno lice (Z. Eremija) može imati ED brojeva, t.j. ugovora za isporuku el. energije.

Primer: Z. Eremija ima dva stana u istom objektu odnosno dva ED broja na jednom mernom mestu (recimo stanovi u prizemlju i na spratu objekta) i ima garažu (novi ED broj) koja se nalazi u drugom objektu samim tim i na drugom mernom mestu. To praktično znači da Z. Eremija ima tri ugovora za isporuku energije, od kojih su dva na istoj adresi - istom objektu a treci se nalazi u drugom objektu odnosno drugom mernom mestu.

Kada distribucija kontaktira Z. Eremiju može da mu šalje dokumente (račune, obaveštenja i dr.) na adresu koju on dostavi distribuciji koja uopšte ne mora da bude a može biti ista adresa na kojoj se vrši isporuka energije.

Primer: Z. Eremija ima dva stana i garažu u BGD a živi u Jagodini i dostavlja adresu za slanje dokumentacije u Jagodini za sva tri ugovora i sve vezano za te ugovore mu dolazi na tu adresu (ta adresa u JA nije merno mesto!). Naravno da neka od adresa gde se nalazi i merno mesto može biti i adresa na koju se dostavljaju dokumenti

Nastavak sutra!

P.S. Izvinjavam se g. Eremiji zbog korišćenja imena.

_{[Ovu poruku je menjao mpaja dana 06.09.2011. u 19:14 GMT+1]}

Iz ovog izvedeneog se moze zakljuciti da ED broj je kristalno jasna velicina kojom upravlja elektrodistribucija, ali merno mesto mogu zakljuciti da nije jednoznacno odredjeno nekim jedinstvenim brojem kojim upravlja elektrodistribucija, vec moze da prezume kazivanje i oznacavanje nekog drugog sistema pa recimo kao sto navodite PAK kojim upravlja PTT. Da li je tvrdnja tacna?

Ostala pravila koja ste naveli su kristalno jasna.

Adrese i plombe

Tacno je ovo sto g. Eremija kaze. Jedinstveni kodovi se tek sada počinju uvoditi u zemlji srbiji za svaku adresu a dok to zaživi proći će još dosta vode Savom. Kako je bilo do sada? Distribucija je naravno imala sve potrebne podatke za merna mesta (ulica, broj, mesto, PTT broj itd) i sama dodeljivala jedinstveni kod za to merno mesto (postojao je neki automatizam) i u bazi je svaka adresa imala neki svoj kod koji je bio jedinstven za distributivno područje. U Srbiji ima više distributivnih područja i nisam baš siguran da postoji jedinstvenost na nivou cele Srbije ili bolje rečeno moguće je da se pojavi isti kod u dva distributivna područja a da označava različite adrese gde se vrši isporuka energije.

NA netu ima elektroistok mogućnost da svaki potrošač može pogledati svoj račun Nije loše da se pogleda može se ponešto zaključiti kako funkcioniše

Idemo dalje

To sam i pretpostavljao ali rekoh da ipak neko ko poznaje realni sistem potvrdi. Znači merno mesto je labavo određeno, tumačećim atributima, a ne nekim jedinstvenim brojem ili ID-om. Dok doćekamo da proteće vode Savom moramo se snalaziti. Dobro sada su stvari jasnije.
Daklem budući da je to tako onda model koji sam predložio a u prilogu sam ga malo proširio može da zadovolji potrebe postavljača teme. Možda neki od atributa ili entiteta još nedostaje, ali kao koncept može da podrži sve ranije rečeno.

A sada u vezi pitanja koje je kolega @Zidar postavio. Koncept koji je ponudio kolega @Zidar je sasvim drugačiji i sa uvažavanjem pravila koja su izrečena od strane učesnika u ovoj temi, koja treba ispoštovati, može da bude jedno od rešenja. Koncept koji sam ja predložio zasnovan je na što bližem preslikavanju realnog sistema tj. preslikavanju dokumenata koji bi morali kao dokaz-trag da postoje, kojim bi se potvrdila učinjena radnja.
Svakako da ovaj koncept „dokumenta“ dobija punu snagu primenom vrste veze generalizacija i specijalizacija, gde je entitet Dokument generalizovani entitet, a specijalizovani entiteti su ZaduzenjePlombe, RazduzenjePlombe, PromenaBrojila i PromenaPotrosaca. Već iz sada postavljenog modela može se zaključiti da postoje još specijalizovanih entiteta (npr. PromenaAdreseMernogMesta itd...), ali to bi izašlo iz okvira pomoći...

Ovako postavljen model u velikoj meri preslikava realni sistem te spajanje koncepta koji je kolega @Zidar predložio i ovog drugog koncepta ne bi imalo smisla.

Koji je bolji? I jedan i drugi imaju svoje prednosti i mane. U dugogodišnjoj praksi često sam bio u dilemi. Nekako, kako vreme odmiče sve više, pred sobom, zagovaram koncept koji sam predložio.



Eto kako sam ja video vaš naziv teme "Zaduženje u blok-serijama a razduženje pojedinačno i još ponešto".

_{[Ovu poruku je menjao Zoran.Eremija dana 08.09.2011. u 13:39 GMT+1]}

Zoran je u pravu. Ponudjeni model veoma dobro odslikava posmatrani sistem i bez prevelike nuzde ne treba ga manjati. Oba modela postizu priblizno iste stvari.

Pokazimo kako su to modeli slicni, i gde se razlikuju.
1. Promena stanja: (Plomba Zaduzena) -->(Plomba Razduzena) modelovana je sa cetiri tabele

ZaduzenjePlombe ---< BrojPlombe ---< RazduzenejPlombe >----- RazlogRazduzenjaPlombe

Ovo znaci da se ne moze razduziti polmba koja nije zaduzena. To je isto ono sto je u 'Zidarevom' modelu postignuto matricom dozvoljenih promena stanja. (model nije stvarno Zidarev, zato sam stavio navodnike, ja bih ga nazvao'model Alexa Kuznetsova'). Elem, Alexov model dopusta i druge dogadjaje sa plombom - kidanje, legalno skidanje, vracanje u magacin. Zoranov model tom postize tabelom RazlogRazduzenjaPlombe. Ako za svaku akciju postoji odredjeni dokument, pretpostavka je da ce dokumenti biti uneseni prvo u tabelu Dokument, pa onda dodate u ZaduzenjePlombe, pa u Plombe i najzad u RazduzenjePlombe. Broj tabela da se prati zivot plombe je u ovom slucaju ispao otprilike isti. Alexov model je jaci u postavljanju ogranicenja

Problem moze da nastane u tabeli Dokumenti, u kolni DatumDokumenta. Nista nas ne sprecava da unesemo DatumDokument za razduzenje da bude pre nego je DatumDokumenta za zaduzenje. Moze se cak uneti i dokument za razduzenje, a da prethoidno uopste nema zaduzenja. Ovo bi moralo da se resi na nivou aplikacije. Ovo pominjem ne da bih kritikovao model, nego zato sto verujem da bi vecina to zaboravila i oslonila se na korisnika da unese korektne podatke. Ukoliko se uvek oslonimo na korisnika da unese korektne rezultate, onda nam ne trebaju nikakva ogranicenja. Cesto je nemoguce ili veoma tesko postaviti ogranicenja na nivou tabela, ali ne treba ih stoga ignorisati - uvek postoji kod gde se moze i mora dodati sve sto nam u modelu nedostaje.

2. Promene Brojila i Promene Potrosaca
Ono sto me prijatno iznenadilo je da u atbelama PromenaBrojila i promenaPotrosaca vidim Alexov model. Tabela PromeneBrojila izgleda ovako:


Trojka (BrojBrojilaPrethodni BrojBrojilaNovi DatumPromene) se nalazi i u Zidarevom objasnjenju Alexovog modela, u prethodnim postovima, u tabei PromeneStanja. Da bi sve radilo kako treba, potrebno je uvesti ogranicenja koja traze da
1. BrojBrojilaPrethodni u tekucem redu bude jednak vrednosti BrojBrojilaNovi u prethodnom redu.
2. DatumPromene bude u rastucem redosledu - da DatumPromene u svakom redu bude veci nego DatumPromene u prethodnom redu

Prvi uslov se postize kombinacijom FOREIGN KEY i UNIQUE ogranicenja. Za drugi, treba nam kolona DatumPrethodnePromene, da bude jednak Datumpromene iz prethonog reda i onda jednostavno stavimo da je DatumPromene>DatumPrethodnePromene. A to sve imate objasnjeno u u prethodnim postovima.

Hvala svima na strpljenju, nadajmo se da ce zbog ovoga struja biti bar malkice jeftinija.

:-)