Dodavanje serijskih brojeva u bazu

Pozdrav. Imam bazu uradjenu u accessu za evidentiranje ulaza i izlaza materijalnih sredstava. Imam tabelu skladista, tabelu materijalnih sredstava koja sadrzi nomeklaturni broj, jedinicu mjere sredstva i naziv. Pored ovih tabela imam i tabelu skladista, tabelu stavke gdje evidentiram ulaze i izlaze sredstava. Do sada funkcionise sve kako treba. Napravio sam dosta upita koji mi pomazu kod razlicitih izvjestaja. Posto se radi o tehnickim sredstvima i motornim vozilima pojavi mi se jedan problem. Treba da evidentiram i serijske brojeve tih sredstava, godinu proizvodnje i dr. koja ulaze ili izlaze iz pojedinih skladista. Treba da znam u svakom trenutku koje serijske brojeve sredstava imam na kojem skladistu, koja imam na stanju ili koja nemam na stanju i da mogu pratiti njihovo kretanje Ako me ko moze usmjeriti u kom smjeru da krenem dalje i kako rijesiti ovaj problem.

Možda ti ovaj link pomogne:http://thedailyreviewer.com/of...e-to-make-it-indexed-106176552

---

Ovo nije jednostavan problem i ne moze se resiti na 'standardan' nacin. Iz onoga sto si napisao, deluje da znas sta radis, deluje da su tabele razumno postavljene. To je OK, ali nazalost nije dovoljno. Ne pije vode za "Treba da znam u svakom trenutku koje serijske brojeve sredstava imam na kojem skladistu" i "i da mogu pratiti njihovo kretanje".

Obecao sam pred Novu godinu da cemo razgovarati na forumu o problemima koji se ne mogu resiti tako sto se baza dovede u trecu normalnu formu, i ovo je jedan od tih. Daj mi dan dva da razmislim pa cemo nesto da pokusamo. U medjuvremenu opisi obicnim jezikom sta se desava i sta hoces da pratis.

Cini mi se da ti treba odgovor na ovo dugacko pitanje: Kako se to krecu tehnicka sredstva i vozila iz magacina u magacin, sta se desava kad su van magacina, na terenu - da li se i to prati, sta se desava kad idu na redovan remont ili vanrednu opravku, sta se desava kad treba vozilo ili tehnicko sredstvo otpisati, zbog starosti kad je ukradeno, unisteno ili pokvareno do te mere da se ne isplati popravljati ga.

Veliki deo problema pokusacemo da resimo na nivou tabela. Ali, bice to prilicno komplikovana struktura tabela, pa ce biti neophodno i programiranje i to industrijskog kvaliteta. Bice posla za sve, za projektante baze kalibra Zorna i Getsbija ali i za programere kalibra Trtka i njegovog drugara Nikole iz Kragujevca i svih drugih koje neopravdano nisam pomenuo.

Spremite se, uskoro polecemo

Tema nije jednostavna, ali da nije neresiva postvaicu vam model baze koji sigurno funkcionise prema zahtevima koje ste opisali. Obratite paznju na entitete PredmetPoslovanja, OsnovnoSredstvo (nemojte da vas zbuni naziv Osnovno sredstvo mogao je da se zove i SerijskiBroj, kada sam ga definisao bio je takav trenutak inspiracije). Takodje obratite paznju na entitete Dokument, DokumentStavka, DokumentStavkaSredstvo i VrstaDokumenta. Vrstom dokumenta separirate dogadjaj tj razvrstavate razlicite vrste dokumenata kojima upravljate predmetima poslovanja i od nje zavisi da li nesto na nekoj Lokaciji (skladiste, magacin, Zidareva njiva...) menja stanje ili ne.

Overom svake te vrste dokumenta Vi tada odstupate odradjujete transakcije i menjate kolicinsko stanje u entitetu StanjeMagacina ili ako je to neko sredstvo koje ima serijski broj u entitetu OsnovnoSredstvo.

Kao sto vidite kolega Zidar je bio u pravu nije bas jednostavan model, ali znam zasigurno da je potvrdjen u praksi...

---

Poprilicno je tesko konkretno bilo sta reci bez strukture baze.
Jedino sto se moze reci a to je da pri prvoj evidenciji materijalnog sredstva moras evidentirati godinu proizvozdnje i serijski broj.
Pored ovoga po meni treba evidentirati i datum pocetka ekploatacije odnosno koristenja jer se od tog datuma sve racuna.
Ostalo nista nebi bilo problem sem sto bi pri svakom ulazu ili izlazu ili pak bilo kakoj evidenciji sredstva treba dodati i polja sa ovim podacima koja su vjerovatno ispustena pri kreiranju baze.
Ostalo se nista nebi mijenjalo u strukturi bar po ovome sto je napisano.
Opet napominjem bez strukture baze ovo je puka teorija.

---

Prije svega hvala na brzim javljanjima. Evo jos poneko moje razmisljanje i pitanje. Ja sam isto tako razmisljao kao i izonic da prilikom prvog evidentiranja sredstva upisujem serijske brojeve, god. proizvodnje i druge podatke koji mi trebaju. To bi znacilo da prilikom evidentiranja „ULAZA“ ili „IZLAZA“ moraju postojati i ova navedena polja, sto opet iziskuje prepravku forme i tabele za knjizenje, odnosno polja za evidenciju ovih podataka. Da li bi se svi ovi podaci mogli smjestiti u tabelu materijalnih sredstva ili bi bilo bolje da otvorim novu tabelu gdje bi serijske brojeve, god proizvodnje, broj sasije ili motora, mogao povezati na osnovu nomenklaturnog broja sredstva sa tabelom materijalnih sredstava

Ovo deluje veoma razumno. Ako je samo to u pitanju, problem je resen.

medjutim, nejasno mi je nesto drugo. STa znaci ulaz-izlaz materijalnog sredstva? Da li se to desava samo kada kupis kamion (marterijalno sredstvo?) pa je to kao 'uslo' u magacin, a izlaz je kad ga otpises? Sta predstavlja STanje materijalnih sredstava? Broj kamiona/tenkova/bagera? Ili nesto drugo?

Ili pokusavas da pratis gde se koje vozilo nalazi u kom momentu, kada radi ili kada sedi u nekoj garazi (magacin?), gde se vec zatekne?

Znaci na radi se samo o motornim vozilima, nego i o drugim tehničkim sredstvima kao npr. kompjuteri, telefoni. kopir aparati i dr. Sam ulaz moze biti nabavka novog sredstva od nasih dobavljaca-firmi partnera ili premjestanje iz jednog magacina u drugi. Izlaz moze da bude otpis zbog dotrajalosti ili neceg drugog, zatim moze da bude zbog kretanja samog sredstva unutar firme, jer postoji vise lokacija sa vise lica koja duze ta sredstva. Zbog toga mi je sve ovo potrebno da u datom momentu znam gdje se i kod koga odredjeno sredstvo nalazi kao i to da znam koliko cega ima "UKUPNO" i koliko cega na kojoj lokaciji ili koliko koje lice duzi tih sredstava. Imam cesta pomjeranja tih sredstava i ja to zovem ulaz ili izaz. Ja imam dilemu kako evidentirati te serijske brojeve i dr. i kako evidentirati kretanje sredstava sa svim podacim (ser.broj, broj motora, boj sasije i model dr.)

Ako pogledate model koji sam postavio u prethodnom postu kao i generisanu bazu videcete da je uglavnom sve obuhvaceno sto ste naveli, eventualno za motorno vozilo koje bi mogli da dodate kao specijalizovani entitet Vozilo od entiteta OsnovnoSredstvo ili kao specijalizovani entitet PredmetPoslovanja sa onim atributima koja su bitna za vozilo.

Tako nesto sam svojevremeno uradio za DaimlerChrysler znaci entitet Vozilo kao specijalizovani entitet od entiteta PredmetPoslovanja buduci da njihov realni sistem ima malo specifican odnos prema vozilima koja prodaju.

Mozda bi u vasem slucaju bila bolja varijanta da entitet Vozilo bude specijalizovani entitet od entiteta OsnovnoSredstvo.

---

@ Dado: Imas dakle DVE dileme. Prva, kako da cuvas serijske brojeve vozila. Druga, kako da pratis kretanje osnovnih sredstava kroz firmu.

Prva dilema je ovde:

Druga dilema je opsiana ovde:

Osnaovna sredstva delis na barem dve kategorije: 1) velike masine i vozila - imaju serijski broj, 2) sitnije srtvari (telefoni, kopir masine, kompjuteri, stampaci itd.) koji mozda imaju a mozda i nemaju serijski broj. Ne interesuje za sada te potrosni materijal (papir, so za posipanje puteva, gorivo, mazivo, sijalice, toalet papir, spajalice, municija za heftalice, fascikle itd). I hoces da pratis u jednom istom sistemu zajedno 1)velike masine i vozile i 2) sitnije stvari (telefoni, kompjuteri, printeri, forokopiri itd.)

Prvu dilemu ti je resio Zonic i Zoran - serijski broj vodis u tabeli gde vodis osnovna sredstva, neka se zove OsnovnaSredstva. Taj serijski broj je i veoma dobar kandidat za PK takve jedne tabele, ali ljudi vole da uvedu neki autonumber. Necu da se svadjam, ako imas autonumber za pK, neka ga. Znaci, Serijski broj ide u tabelu gde se osnovno sredstvo upisuje tacno jednom. Serisjski broj treba da bude, ako je iakko moguce, NOT NULL (Required u Accessu) i da bude UNIQUE. UNIQUE svakako, cak i ako su NULL vrednosti dozvoljene. To Accesu moze, unique indeksi zanemaruju NULL vrednosti po defaultu.

Za sada imamo ovakvu tabelu
OsnovnaSredstva: {OsnSredID autonumber, SerijskiBroj UNIQUE, Opis NOT NULL, Tip NOT NULL kao ('voizlo','kancelrijska oprema')}

Da probamo dilemu 2 - kako pretiti ULAz i IZLAZ. Pokazacemo jedna nacin, koji moze da prodje, iako ostavlja puno otvorenih pitanja. Kako lepo rece Zoran, oprobano u praksi i uglavnom se moze osloniti na ovu logiku.

U tabelu OsnovnaSredstva mozes, da dodas jos dve kolone - DatumNabavke i DatumOtpisa, sa ogranicenjem da je [DatumNabavke] < [DatumOtpisa]. Time bi naoko resio deo druge dileme, zapisao si ulaz i konacan izlaz. To je kao kad maticar upise u krstenicu datum rodjenja i datum smrti.

OsnovnaSredstva (atribute i ogranicenja originalnih kolna ne ponavlja zbog ustede prostora):

OsnovnaSredstva: {OsnSredID autonumber, SerijskiBroj , Opis , Tip, DatumNabavke NOT NULL, DatumOtpisa NULL}
Sadam oramo da vodimo racuna da podaci imaju smisla -ne moze se otpisati sredstvo pre nego sto je nabavljeno. Stoga:
OsnovnaSredstva: (CHECK: DatumNabavke < DatumOtpisa WHEN DatumOtpisa NOT NULL)

Ostaje probelm da se resi ono izmedju. Gde se kada nalazilo koje materijalno sredstvo. Najprostiji zahtev je da znas za sadasnji trenutak kod koga se nalazi osnovno sredstvo. Mogao bi da pokusas da dodas kolonu Zaduzio = ID radnika koji trenutno duzi osnovno sredstvo. Tako bi znao ko duzi osnovno sredstvo u svakom trenutku. Dobro, i DatumZaduzenja. Onda znas ko duzi trenutno ovo osnovno sredstvo i od kada. Ali ne znas ko je duzio osnovno sredstvo pre toga, ali te to mozda i ne interesuje. Imali bi dakle ovako tabelu:

OsnovnaSredstva: {OsnSredID autonumber, SerijskiBroj , Opis , Tip, DatumNabavke , DatumOtpisa, Zaduzio NULL, DatumZaduzenja NULL}
OsnovnaSredstva: (CHECK 1: DatumNabavke < DatumOtpisa WHNE DatumOtpisa NOT NULL)
Ako je sredstvo zaduzeno mora se znati ko duzi i od kada. Ako nije zaduzeno, ne sme pisati ni datum zaduzenja
OsnovnaSredstva: (CHECK 2: (DatumZaduzenja i Zaduzio su ili ona NULL ili nijedan nije NULL))
Naravno, datum zaduzenja mora biti veci ili jednak od DatumNabavke:
OsnovnaSredstva: (CHECK 3: (DatumZaduzenja >= DatumNabavke))
I naravno, ne moze se zadusiti sredstvo koje je otpisano:
OsnovnaSredstva: (CHECK 4: (Kad je DatumOtpisa NOT NULL ond moraju biti (Zaduzio = NULL AND DatumZaduzenja = NULL)))

kao sto vidis, tabela raste, dodajemo nove kolone, po dve zajedno is njima raste i broj ogranicenja koje ce garantovati da su podaci kvalitetni. Kakva vajda od baze podataka u kojoj pise da je kamion otpisan 1996 godina, ali ga jos uvek duzi Zika a ne zna se od kada, dok za datum nabavke pise 2001 godina?

Zasto sam rekao da ovakav nacin nije najbolji? Pa upravo zbog ovih ogranicenja koja se jednostavno moraju uspostaviti, iance ode mast u propast. Ogranicenja na tabeli se u Accesu tesko psotavljaju ako su iole slozenija. CHECK 1 se lako psotavlja (table design, properties, validation rule). Ostala ogranicenja su komplikovanija da se postave. Cak i ako uspemo da ih postavimo kao logicki izraz koj je FALSe ili TRUE, ostaje problem da ih upisemo u ValidationRule. Mislim da je limit 1024 karaktera i ako nista, zbog toga verovatno nevemo moci da postavimo ova pravila. Ako mislite da cete lako u aplikaciji postaviti ova ogranicenja, varate se grdno. Zasto ljudi ipak prihvataju ovakvo resenje? Iz dva razloga. Prvo, malo ljudi zna za bolje resenje. Drugo, ako i znamo, nije lako da se odradi.

Zavrsni udarac: mozemo da pokazemo koji radnik duzi koje sredstvo. A sta ako niko ne duzi ovo sredstvo? Ono se nalazi ili u nekom magacinu, ili je otpisano. Da dodamo jos dve kolone Magacin, DatumUlaskaUMagacin uz ogranicenje da ako postoji (Zaduzio,DatumZaduzenja) onda ne sme da postoji (Magacin,DatumUlaskaUMagacin). I naravno, ako je stvar otpisana, ne sme da postoji (Magacin,DatumUlaskaUMagacin). Recimo da ito postavimo nekako. Pogledajmo na sta lici tabela:

OsnovnaSredstva: {OsnSredID autonumber, SerijskiBroj , Opis , Tip, DatumNabavke , DatumOtpisa, Zaduzio NULL, DatumZaduzenja NULL, Magacin NULL, DatumUlaskaUMagacin NULL}
OsnovnaSredstva: (CHECK 1: DatumNabavke < DatumOtpisa kad DatumOtpisa NOT NULL)
OsnovnaSredstva: (CHECK 2: (DatumZaduzenja i Zaduzio su ili ona NULL ili nijedan nije NULL))
OsnovnaSredstva: (CHECK 3: (DatumZaduzenja >= DatumNabavke))
OsnovnaSredstva: (CHECK 4: (Kad je DatumOtpisa NOT NULL ond moraju biti (Zaduzio = NULL AND DatumZaduzenja = NULL AND Magacin = NULL AND DatumMAgacina = NULL)))
OsnovnaSredstva: (CHECK 5: (DatumUlaskaUMagacin >= DatumNabavke))
OsnovnaSredstva: (CHECK 6: (DatumUlaskaUMagacin i Magacin su ili ona NULL ili nijedan nije NULL))

I sve ovo pre nego sto smo dodali ostale kolone koje su vazne za osnovno sredstvo (vidi Zoranov model). Posto su sva navedena ogranicenja nad jednim redom u atbeli, teorijski je moguce postaviti ih. U praksi, u nekom drugom sistemu (MS SQL, ORACLE i slicno) MOGUCE je postaviti ova ogranicenja, ali u Accesu je to fizicki nemoguce zbog ogranicenja u broju karaktera u Table Val;idation Rule. Mozda bi kroz JEt moglo da se kaze neko ALTER TABLE ADD CONSTRAINT.... (Boze sacuvaj gde smo zabasali;-) ali se posle to ne moze videti niti editovati (i ako moze, vrlo tesko), prakticno, u Accesu nemoguce. Pa sta, kazacet, skinem SQL Express i uradim to tamo.

Namece se jos jedno pitanje: Ako je nako duzio kamion od 12 Marta 2008 do 10 januara 2011 i onda kamion odlazi u magacin. Brisemo sve iz (Zaduzio, DatumZaduzenja) i upisujemo (Magacin = 'm1', DatumUlaskaUmagacin = #10 januar 2010#). Ko garantuje da cemo tacno upisati datum ulaska u magacin? Sa ovako definisanom tabelom, ni u SQL serveri ni u ORACLE to nije moguce odraditi bez trigera. E sad odosmo i u trigere. Sto je mnogo, mnogo je. Ovako mozemo do sutra, stalno ce se pojavljivati neko novo ogranicenej koga se nismo setili do malopre.

A i preksrisli smo neko tamo pravilo normalizacije koje kaze: svaka kolona u tablei sme da zavisi samo i samo od PK. Ako kolone zavise jedna od druge to nije dobro. Zasto? Zato sto je tesko garntovati integritet (istinitost) podataka. Zato sto smo narusili pravilo normalizacije moramo da se vadimo kroz CHECK constraints.

I sva ova nevolja i rabota da bi videli gde se u samo ovom momentu nalazi koje sredstvo. Nikakva istorija, nista. A toliko mogucnosti za greske i naravno - malverzacije. Zamislite da ne znate gde vam se nalazi kamion ili buldozer. Ili tenk. Kako cemo ponovo da ratujemo ako ne znamo gde nam je tenk?

Rekoh, moze ovako, ali da se vodi racuna o ogranicenjima.

Moze li nekako drugacije? Moze, ali je veoma razlict pristup, nije jednostavan i sve je toliko novo da nema ni velikih iskustava. Ako hocete da budete pioniri novijh metoda ili da naucite nesto sto ce biti norma za deset godina, mozeo da pokusamo.

Ko je za?

Po meni je u pitanju aspekt posmatranja. Dok nemamo ili ne dobijemo sva poslovna pravila, možemo samo da u model inkorporiramo svoja viđenja poslovnog problema.

Možemo recimo da posmatramo tako da je osnovno srdstvo u žiži interesovanja.

Ili recimo da je kretanje sredstava i potrošnja materjala i sitnog inventara od interesa za korisnika.

Kako god, neophodna su prvo poslovna pravila. Evo ovde sam pre neki dan dao primer kako ta pravila treba da budu napisana.
http://www.elitesecurity.org/t419234-PMOV-problem-oko-agregacije

I naravno, glasam za Zidarev predlog da nešto naučimo.

_{[Ovu poruku je menjao Getsbi dana 13.01.2011. u 22:04 GMT+1]}

---

Pomeramo se u pravom smeru :-)

Getsbijev model je za nijansu bolji od onoga koga sam opisao i rekao da nije dovoljno dobar. Objasnicemo zasto za trenutak i ukazati na slabosti koje nastaju usled zanemarivanja pravila koja nam niko nije kazao pa ih kao ne znamo. Zanemaricmo potrosni materijal, dovoljno je komplikovano i bez toga. Tabela KretanjeSredstava iz donjeg dijagrama izgleda dakle ovako:

KretanjeSredstava: {EvidencijaID autonumber, OsnovnoSredstvoId, RadnikID, DatumZaduzenja, DatumRazduzenja}

Odlicno, to nam i treba - imamo sve sto nam treba i sve sto zelimo da znamo, za sada. Ko je zaduzio, od kad do kad. Tabela mnogo elegantnije izgleda nego monstrum iz moje poslednje poruke.

Nazalost, model nije dovoljno detaljno definisan. Ne dostaju ogranicenja, koja mogu da dosdu iz poslovnih pravila, ali i na osnovu zdravog razuma. Niko nam nece reci da mora biti DatumZaduzenja <= DatumRazduzenja. Ali necemo zbog toga izostaviti to ogranicenje. Valjda smo nekakvi profesionalci. Kad narucim casu vode u kafani ne kazem kelneru da hocu da bude u cistoj casi, cista casa se ocekuje i stoga se ne spominje u zahtevu. Tako i ovo. Nesto moramo da vidimo i sami. Znaci ovako bi isla nekakva specifikacija tabele:

KretanjeSredstava:
{EvidencijaID autonumber, OsnovnoSredstvoId int, RadnikID int, DatumZaduzenja DateTime NOT NULL, DatumRazduzenja DateTime NULL}
CHECK (DatumZaduzenja <= DatumRazduzenja OR DatumRazduzenja IS NULL)
FK na tabelu Radnici
FK na tabelu SonovnaSredstva

Evo test podatka koji zadovoljavaju definiciju tabele

Radnik 1 je zaduzio sredstvo 1 10 Decembra, vratio ga 15 Decembra. Onda je Radnik 2 to sredstvo preuzeo 18 Decembra i jos ga drzi. Mogu da pretpostavim da je izmedju 15 dec i 18 Dec sredstvo bilo u magacinu. Oops, postavljac temeima nekoliko magacina, u kom magacinu je bilo to sredstvo 1?

Nisat me ne sprecava da unesem novi red u tabelu i dobijem ovo:

Pazi sad, sredstvo 1 se nalazi jos uvek kod radnika 2, ali u bazi pise da ga je 21 Dec preuzeo radnik 3 i da ga jos drzi. Kod koga je kamion?

Model je znaci dobar, u smislu da sadrzi maximalnu mogucu kolicinu informacija (ko drzi kamion od kada do kada), ako zanemarimo problem vise od jednog magacina. Nekompletnost modela se ogleda u nemogucnosti postavljanja ogranicenja koja ce spreciti neistinite unose u tabelu, namerno ili nenamerno. na kraju krajeva, relaciona baze je uredjeni skup podataka, a uredjenost proistice iz postavljanja ogranicenja (PK, UNIQUE, FK, CHECK, NULL NOT NULL, DEFAULT). Sto vise ogranicenja na bazi, to bolji podaci. pa makar nam i ne kazali sve u zahtevu.

4:51 je popodne, moram kuci, ali nastavicemo sutra.

Pitanje je, kako spreciti situaciju koju imamo, da dva coveka duze isti kamion u nekom preklapajucem vremenskom intervalu. Jedno resenje je - kodom na front endu. OK, ali nije lako ni tako. Kako drugacije moze?

Za one koji imaju strpljenja, evo price o pracenju promena stanja sitema ili entiteta u relacionim bazama podataka. Prica je dugacka, prvi deo, teorijski je u zakacenom PDF fajlu. Ostatak cu napisati u ponedeljak. Za one koji zele da vide kako to u praksi izgleda, zakacena je Access baza u kojoj je primenjeno ono sto smo opisali, i jos ponesto sto cemo tek opisati. kad zavrsimo pricu, trebalo bi da bar jos neko bude u stanju da malo istrazuje u ovoj oblati, a mozda se ponesto moze i u praksi primeniti.

U bazi, tabela StatusChanges je ono gde upisujemo stvarne promene. ValidState Changes je ono gde smo definisali sta su dozvoljene promene. Pogledajte dijagram relacija i Validation Rule za tabelu StatusChanges. Ako ne razumete, ne mari, pokusacu da objasnim u ponedeljak.

Lepo se zabavljate preko vikenda

Izvinjavam se za nepisanje danas. :-(

Kad covek ostari onda ga ceo dan drze po sastancima i nista ne moze da radi. Danas smo imali sastanak od 9 do 3. Sto je mnogo, mnogo je. I stara drzava je propala kad je pocelo puno da se sastanchi, nece valjda i ova...

Sutra (utorak) ako Bog da.

Evo jos 22 strane texta :-)

Otvorite PDF i idite na starnu 7. Tu pocinje novi deo. Access baza je potpuno nova i prati text od strane 7 pa nadalje.

:-)

Staro:
Nikako me ne pusta Access da zavrsim unos novog reda u tabelu PromeneStanja?
Mislim da sve dobro unosim.

Edit:
Kad sam dosao na posao, procitao sam pazljivije pdf txt i naravno radi ;)
Nisam obratio paznju na:
str13
"Pravilo-a 5,6: Ako je NovoStanje = 3 onda mora postojati vrednost [KoKoristi],
a ako NovoStanje <>3 onda ko koristi MORA biti NULL. Ovo se postize tako sto
se otvori tabela u design modu, otvori se properties dijalog za tabelu i
upise se Validation Rule za tabelu:"

Mada se bi onda i na str10 umesto moze trebalo pisati mora?:
5.
KoKoristi moze biti NULL, osim kad je NovoStanje = 3 (sredstvo je u
upotrebi), jer zelimo da znamo ko koristi sredstvo

I jedno pitanje :)
Zasto nije dozvoljena promena 3->3?
- Recimo da nisu vozila vec kompjuteri, prenece se iz jednog odeljenja na drugo, nece ici u magacin? Ili ako je primer na vozilu - vozac je dovezao autobus na more i tamo ih je sacekao drugi vozac koji ce ga voziti nazad?


_{[Ovu poruku je menjao joojant200 dana 19.01.2011. u 08:36 GMT+1]}

Promena 3->3 nije dozvoljena jer je nisam upisao u DozvoljenePromene. Ako se to u stvarnosti desava i to je normalan proces u tvojoj formi, sasvim je OK da u tabelu DozvoljenePromene uneses 3->3.

Dozvoljene promene ti kontrolises 100%. jedino sto MORA da postoji to je ono 1->1 zbog prevog reda. sve ostalo je kako ti postavis. Crtanje dijagrama samo pomaze da se pokazu sve moguce promene. I ni u kom slucaju nije sitna da se tabela DozvoljenePromene ne sme menjati.

Problem je malo kada imas na pocetku neke dozvoljene promene, pa odlucis da vise nisu dozvoljene. Ocigledno je da ih ne mozes obrisati iz tabele DozvoljenePromene, ako su makar jednom upotrebljene, zbog FK. Ali ih mozes oznaciti (nova kolona u DozvoljenePromene) da su 'neaktivna' pa ih ne dozvoljavas nekako na nosu. U MS SQL moglo bi i ovo da se sredi, da su promene dozvoljene nekada a nekada nisu, verujem da je u Accesu mnogo komplikovano, ali vredi sitrazivati. Obicna normalizacija je kao algebra, ovo sto smo pokazali su izvodi i integrali, a kontrola dozvoljenih promena kroz vreme bila bi neka jos visa matematika, ne zanm s cime da je uporedim.

Inace, oni dijagrami, to iam u UML i zove se State Transition Charts. Medjutim, svi primeri u UML knjigama su o tome kako je dugme ili mis kliknut ili nije. Pa posle kazu na zapadu ne prepisuju kad pisu knjige....

cut iz pdf
___
"........, mozemo za dan-dva da predjemo na programiranje." :)


Tema je totalno zanimljiva, otvorio si mi oči TOTALNO....

Jedva čekam da vidim majstorije u programiranju.

Mogu samo konstatirati....Zidar...RESPECT

Sta sve covek moze da uradi za jedno pre podne

Zakacio sam nesto sto lici na kao nekakvu aplikaciju. Ne preporucujem da se samo kopira ili se proba nakalemiti na svoje resenje bez razumevanja i puno puno opreza. Moze i bolje i svakako lepse, moj cilj je bio da bude jednostavno, cisto i jasno koliko je moguce. I da ne traje dugo , ipak sam na poslu...

Ja sam se namucio citajuci Aleksovu knjigu i pokusao sam ovde da olaksam razumevanje interesantne materije. Uzivajte, i cuvajte za istoriju. Ovo ce se u knjigama na nasim jezicima pojaviti tek za nekoliko godina.


Srecan rad

P.S. temu sam upisao u "Bivse TOP teme", iako nikad nije bila TOP, da se ne zagubi

Pimjetio sam prije neki dan da ovde ima jedan propust, ali eto mislio sam da necu biti jedini koji je to primjetio. Sebi sam rekao: "Ako se niko ne bude javio moracu da reagujem!", pa eto to i cinim:

U tabeli PromenaStanja primarni kljuc je slozen i sastoji se od (PK(SerijskiBroj, NovoStanje, DatumPromene))

tako da nije moguce da jedno vozilo zaduzi Pera i ode do grada, vrati auto u garazu, zaduzi Mika i ode do grada, vrati auto u garazu, pa da ga ponovo zaduzi Pera...

SerijskiBroj-----StaroStanje-----NovoStanje-----DatumPromene------DatumStarogStanje-----KoKoristi----Rb-----StariRb
---------------------------------------------------------------------------------------------------------------------
12345--------------1---------------1-----------26.01.2011------------26.01.2011----------------------1---------1--
12345--------------1---------------2-----------26.01.2011------------26.01.2011----------------------2---------1--
12345--------------2---------------3-----------26.01.2011------------26.01.2011-------------1--------3---------2--
12345--------------3---------------2-----------26.01.2011------------26.01.2011----------------------4---------3--



12345--------------2---------------3-----------26.01.2011------------26.01.2011-------------2--------5---------4--

Drugi covjek ne moze da zaduzi vozilo, pa mislim da nebi bilo lose da se uvede i vremenska odrednica kako bi i Mika mogao da ode do grada :)