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

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.

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

Potpis

Mislim, dakle smislicu nesto.

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.

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.

Potpis

http://zoraneremija.wix.com/eremijacv

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

Potpis

Mislim, dakle smislicu nesto.

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?

Potpis

http://zoraneremija.wix.com/eremijacv

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.

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.

Potpis

http://zoraneremija.wix.com/eremijacv

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

Potpis

http://zoraneremija.wix.com/eremijacv