Centar za edukaciju-BiH

Predmet:Update podataka

---

Cesto puta sam procita na forumima kako neko pita nakoji nacin da izvrsi update 'kako oni kazu' iz nekog Querya u neku tabelu.
Pod broj jedan podaci su smjesteni iskljucivo u tabelama a u Query je samo uslov postavljen sta da se izcita od podataka iz tabele.

Kako smo rekli podaci se uvijek nalaze u tabelama i ja licno ne vidim razlog zaso bi neke podatke prebacivao iz jedna tabele u drugu.

Prvo je pitanje ako imate dvije tabele koje imaju ista polja zasto ce vam dvije.
Primjer:
Tabela osoblja
Tabela Gostiju
Tabela Komitenata
Tabela dobavljaca itdd.

U ovom primjeru vidiomo da se sve tabele odnose na osbne podatke.
Dovoljno je napraviti jednu tabelu i u njoj dodati polje status.
1-osoblje
2-gosti
3-dobavljaci

Evo jos jedan primjer:
Ulaz-Izlaz
Skoro svi prave 2 tabele i to je mozda uredu jer ovdje se i nemoraju poklapati sva polja ali sta je sa detaljia ulaza i izlaza.
Kod njih su polja identicna.
Znaci dovoljno je samo jedno dodatno polje u kome cemo biljeziti dali je ulaz ili izla.
U ocom slucaju je lakse izracunati stanje robe i sve ostalo.
Kada vrsimo unos podataka na formama ovo polje se moze unositi automatski po defaultu tako da ga korisnik i ne vidi.
E sad ako vi i dlje smatrate da neke podatke trebate prebaciti iz jedne tabele u drugu na osnovu nekoga kriterija ja bih vam preporucio radje da zapisete negdje u tabelu sam kriterij.

---

Predmet:Re: Najcesce greske koje pracimo.

---

Srdačan pozdrav i još jednom puno uspeha u radu.
Pridružujem se zapažanju najčešćih grešaka i dodao jednu sugestiju kod ULAZA i IZLAZA.
Početniku je možda lakše da ima polja KOLICINA, ULAZ (ulazna cena), IZLAZ (izlazna cena) jer kasnije kroz upite i izveštaje lakše može da se snađe i da jednostavnom operacijom KOLICINA * (ULAZ - IZLAZ) dobija pozitivne i negativne vrednosti, pod uslovom da je Default vrednost, ovih polja, u tabeli postavljena na nulu.
Ova moja sugestija je samo pogled iz ugla početnika.
POZDARAV

Predmet:Re: Update podataka

---

Mislim cak i da nije lakse.
Bas tu nastaju problemi kada hocemo poslije racunati stanje ili nesto drugo.
ovo:
KOLICINA * (ULAZ - IZLAZ)
Ne ide bas zgodno sami znate.
Posto se ulaz i izlaz nalaze u razlicitim tabelama sada ako na nekom artiklu nemamo izlaza robe imat cemo null polje u kqery-u te nam racunica nece biti dobra.
Tu moramo pribjeci uslovu iff pa to joc komplikuje situaciju.

O ovom slucaju koji sam ja predlozio imao bi sledece u tameli

Sifra	Status	kolicina	cijena
01	ulaz	25	3,00
01	izlaz	10	4,00

Dovljno je sumirati Query i oduzeti izlaz od ulaza.
Pozitivno ili negativno lako dobijemo dovoljno izmnoziti sa -1.

Eto to je moje misljenje.
Ima li ko jos kakvih komentara.

---

Predmet:Re: Update podataka

---

Kad je u pitanju ULAZ-IZLAZ, mogao bih se složiti sa iznetim mišljenjem. Razlog je, da je to u stvari neki promet robe ili novca, te se stavljanje na lager i oduzimanje, kao i dotok na račun i odliv sa račana dešava u okviru jednog magacina ili jednog računa.
Treba obratiti pažnju na deo modelovanja koji se zove logički ili konceptualni. Radi se o tome da se pre nego se pristupi pravljenju tabela, kolona, vrsta i relacija, valja posvetiti logičkom projektovanju baze podataka na nivou entiteta, atributa, torki i veza.
Najčešće je loša praksa zanemarivanje takozvanog informacionog modelovanja i izbegavanje pravljenja takvog modela. Uz korišćenje nekog od alata ili makar samo na papru postiže se da se ceo poslovni problem razmotri, razloži, proanalizira i grafičko-tekstualno prikaže.
Tu dolazimo do toga da u većini poslovnih problema nećete osoblje, goste, komintente i dobavljače držati u jednoj tabeli ili eventualno dve. Razlog su poslovna pravila koja će vas na to naterati. Gosti mogu da konzumiraju uslugu i za nju plaćaju. Treba ih izdvojiti i vezati za entitet "Evidencija pruženih usluga", kao konzumenta. Dobavljači i komintetnti (poslovni partneri ili ma šat god to značilo) ne bi trebalo da su u vezi sa prethodno pomenutim entitetom, kao što gosti ne treba da budu u vezi sa entitetom "Evidencija nabavljene i utršene robe".
Osoblje treba da bude poseban entitet jer ima specifičnu funkciju u poslovanju. Na taj način neće vam se dogoditi da se neko od osblja zaduži za noćenje u hotelskoj sobi niti da vam gost nabavi dimljenu pršutu. Neće vam se dogoditi da dobavljač menja peškire u sobi 302 ili da poslovni partner bude odgovoran za prebukiranu sobu.
Drugo, samo dobavljače i komintente možemo podeliti na pravna i fizička lica. Za goste i osoblje to nije moguće.
Dakle, smatram da ****lje na početku razmotriri funkcionalsnost osobe u odnosu na poslovni problem i ne opteretiti jedan entitet sa suviše poslovnih pravila, iz kojih se kasnije teško možemo izvući bez dodatnog kodiranja. SQL iskazi su mnogo jednostavniji i manje zahtevni.
I da ponovim još jednom, važno je dobro promisliti o poslovnom problemu koji obrađujemo i crtati ga na papru ili elektronski. Nema apsolutnih pravila. Započeću sutra jednu temu oko informacionog modelovanja, normalnih formi i načina realizacije istih u Access-u.

---

Predmet:Re: Update podataka

---

Evo ja cu predociti zadnji moj primjer koji sam radio.
Radi se o Uglju.
Imam dobavljace (Rudnike) i Kupce i naravno operatore.
Svi podaci su mi u jednoj tabeli.
E sad za dobavlace imam i dodatnu tabelu koja je je 1-1 sa ovom tabelom i u njoj su mi polja koja se ne odnose na kupce i Osoblje.
Jos i za dobavljace imam i tabelu asortimana odnosno artikala koji oni proizvode.
Oni imaju svoje arikle kao i svaka firma.
napr:
sitni
Orah
Kocka itd.
pored ovoga asortimani se svrstavaju u 2 grupe ligniti i mrki.
Dok ih kupci svrstavaju drugacije odnosno prema kaloricnoj moci.
Ovu tabelu koristim isto kao i sve kodne tabele.
U njoj imam Polje opcija:
U njemu je:
1-Kada je kupac
2-Kada je dobavljac
3-Kada je operator
0-Ako je izbrisan
Bilo gdje da koristim kao lukap ovu tabelu koristim je sa odredjenim uslovom iz ovog polja.
Da napomenem da ovo radi godinama iako se jos radi na tome jer imamo doradu aplikacije u cilju poboljsanja cijelog procesa.
Skoro je kupljene el. vage pa se vrsi analiza vlage pepela i ostalih sastojaka u uglju.
Posto sve nije ni na istom mjestu bazu imam i na sql-u a i u mdb.

Da napomenem da ne smatram da je neispravno praviti vise tabela sve dotle dok se ne desi ono kao sto naslov govori update.
Prenosenje podataka iz tabele u tabelu steti bazi.
Bolje je dodati polje pa ih nekako naznaciti.
Evo primjera ako treba zapisati podatke na osnovu nekog kriterija a da datumom unosa ili nekim drugim nemozemo osigurati da ce po istom kriteriju biti isti broj podataka.
Napravi se tabela kriterija koja u kojoj imaju polja:
datum pokretanja opis i id polja.

---

Predmet:Re: Update podataka

---

Slažem se da je moguće i tako kod nekih poslovnih procesa uz dodatno vođenje računa o kako kažeš "Polje opcija". Cilj mog komentara je bio da ukaže da entitet OSOBA

"...Primjer:
Tabela osoblja
Tabela Gostiju
Tabela Komitenata
Tabela dobavljaca itdd..."

i nije baš uvek najpogodniji za gornji skup i da to zavisi od veličine poslovnog procesa koji se obrađuje. U redu je ako baš svi članovi skupa imaju ista polja, kao što kažeš, ali to nije uvek slučaj. Nešto oko specijalizacije i generalizacije će biti reči u temi koju sam najavio.

Recimo, da ostanem kod hotela. Nije svejedno da li se readi samo o budućem programu za potrebe recepcije hotela (bukiranje soba), programu za praćenje (bezbednost lica u hotelu), ili pak programu za praćenje celokupnog hotelskog poslovanja. Ukoliko se problematika proširi na program za praćenje poslovanja lanca hotela, tačka posmatranja se izmešta još više.

I da ne ispadne da je ovo filozofiranje, pokušajte da zamislite lanac hotela koji ima objekte u različitim zemljama sa različitim uslovima poslovanja. Znači cilj mi je bio da ukažem, da u nekim slučajevima nema jasnog pravila (jedna ili više tabela).

Što se tiče "Update podataka iz tabele u tabelu", tu imam identična iskustva sa tobom. Takav kod je u redu samo za jednokratnu upotrebu prilikom razvoja aplikacije ili u nekom momentu održavanja.
Sama aplikacija ne bi trebala da ima ugrađenu takvu mogućnost.

---