Citat:
mkaras: Za početak moraš da se upoznaš sa osnovama računovodstva. Tek onda ćeš moći da sagledaš barem deo problema koji treba da budu rešeni. Do tada mani se ćorava posla
OK, racunovodstvo je "must" za bilo sta ozbiljno, ali za ovako jednostavniji primjer, ne mora odgovor biti mani se corava posla. Momak nije napisao niti koja je svrha baze, u pogledu da li je komercijalni program, ili nije, niti bilo sta drugo. Od necega se mora krenuti.
Ni to samo racunovodstvo nije toliko komplikovano, barem sto se tice osnovnih pojmova i stvari. Problem su poslovni procesi razlicitih firmi, te odgovor na njihove potrebe. Standardni pojmovi sta su racuni(fakture), sta je kalkulacija, sta su rabat i marza, to se sve jednom nauci, i nema se sa tim problema. Kad bi nekad samo bilo sve tako jednostavno.. :)
Sto se tice samog odgovora na temu:
Citat:
biske86: Pozdrav svima, poceo sam da pravim bazu za STR pa mi je potrebna pomoć. Pre svega da razjasnim cilj ovog projekta. Pokusavam da napravim bazu u koju ću unositi artikle, kolicinu, nabavnu i prodajnu cenu artikla. Pored toga treba potrebno je s' vremena na vreme da izvršim popis i tu nailazim na najveće probleme pri dizajniranju tabela. Dodatno da bi se sve poklapalo potrebno je pratiti stanje veresije kao i stanje pazara tj. koliko para gazda uzme na kraju dana iz kase. Naravno postoje i rashodi. Rashod bi na primer bio ako ne prodamo danas dva hleba i moramo da ih bacimo.
Prvo sto moras je krenuti od realnog pogleda u svijetu, koju svrhu baza ispunjava, te sto vise u detalje unaprijed odrediti sve potrebne operacije i zahtjeve nad njom (ovo podrazumijeva prikupljanje business rules-a ). Nakon toga sastavljas model, te opet od zahtjeva zavisi i nacin na koji ces je modelirati. Normalizacija se podrazumijeva za relacione baze, problem oko performansi i denormalizacije ti je za sve manje upotrebe zanemarljiv, i najvaznije je da sto bolje cuvas integritet podataka (da te ne bunim - to jednostavno znaci da izvrsis pravilnu normalizaciju - po mogucnosti i do 4. i 5. normalne forme, i da nista vise ne diras).
Entiteti koje treba da odredis isto moraju oslikavati realno stanje, i ono sto ti je potrebno moras da saznas analizom.
- Da li baza treba da pamti podatke ulaznih racuna (kao broj racuna, ko je dobavljac i slicno)?
- Da li ima kakve potrebe za evidencijom kupaca?
- Ostali napredniji zahtjevi koji mislim da su ovdje potpuno nepotrebni, ali samo da navedem sta bi se moglo uraditi: cjenici, narudzbenice, detalji knjigovodstva itd...
Strucni termin za ovo oko bacanja hljeba je kalo / rastur. Moze se napraviti kao obicni rashod na fiktivni racun kalo/rastur, ali o tome malo kasnije... Stanje veresije - mislim da je potrebno uvesti evidenciju kupaca (ako to program treba da radi), a kao jedno od rjesenja - dovoljno je u neku tabelu prodaje, kakva god ona bila, staviti polje koje oznacava da li je stavka prodaje placena. Sto se tice popisa, ne razumijem sta zelis sa tim? Unos robe na lager ide preko dobave, roba sa lagera se mice prodajom. Ako se vodi ta evidencija, kakav je popis potreban? Ja koliko shvatam kod tebe je popis == prodaja; ali opet i kasno je, mozda sam samo pospan :))
Mislim da ti je jedan od pocetnih problema u ovome sto zelis da sve rjesis sto jednostavnije. Zelis da imas lager artikala, ali ne zelis pamtiti dobavljace, niti racune nabave. Zelis kasu, ali ne zelis racune prodaje (opet kazem, ovo nisam dobro ni razumio sta zelis).
Citat:
Ovo je postavka problema. Odatle se vidi na za početak moram da imam sledeće tabele: tblArtikal, tblNabavka (ulaz), tblPopis, tblVeresija, tblKasa (pazar) i tblRashod.
Tabela artikala je svakako potrebna. Nabavku mozes zvati tako, mozes je zvati i ulazni racuni, svejedno, uradis onako kako najbolje oslikava potrebe. E sad, popis pretpostavljam da regulise lager na izlazu, pa mislim da je bolji naziv Prodaja. Za veresiju sam vec rekao, kao atribut u tabeli prodaje, a posto si od rashoda nabrojao samo kalo/rastur, to bi rjesio fiktivnim kupcem sa tim imenom. Tabela kasa moze ostati kao jednostavno rjesnje za gledanje koliko je novca uzeto iz iste, ali vrijednost ukupnog pazara u nekoj rel. bazi mora biti dinamicki izracunat, nema spremanja u neku tabelu ili polje. Jedini izuzetak ovome pravilu su performanse. Jedno od mogucih rjesenja je da nakon bilo koje transakcije spremas staro i novo stanje, tako da ne moras praviti upit nad cijelom bazom podataka, samo sto bi se javio taj novi problem redudanse podataka.
Rijec i o nazivima samih tabela: ja nikad ne upotrijebljavam Hungarian notation za imena tabela. Iste je jako jednostavno prepoznati da su tabele, ovaj nacin obiljezavanja sa tbl je staro naslijedje. Druga stvar su stored procedure i triggeri, kod njih uvijek koristim Hungarian notation radi mogucnosti isih imena kao i tabele (a i ovo je rijetko). Ipak, samo navodim svoje misljenje, ti radi kako tebi odgovara najbolje.
Citat:
Problem se javlja kad vršim popis jer sam jednom na primer uneo 10 komada smokija čija je cena 13 dinara a onda unesem 15 komada smokija po 14 dinara. Kada izvršim popis vidim da na tezgi imam 17 komada smokija. Znači iz dve nabavke imam 25 komada smokija. Od ovih 17 smokija očigledno je da su 15 iz druge ture a 2 iz prve. Gazda kaže da kad je doneo drugu turu smokija koja je poskupela tj. 14 dinara onda onih dva smokija koji su preostali se ne prodaju više po staroj ceni već po novoj od 14 dinara i to mi mnogo koplikuje stvar prilikom popisa. Ima li neko ideju kako da rešim ovaj problem.
Ovo se rjesava samom normalizacijom odnosa Artikla i Nabave. U jednoj dobavi neces imati isti artikl sa dvije razlicite cijene. Jedna dobava (nabava, whatever) je u biti jedan racun. Na jednom racunu mozes imati vise artikala, a jedan artikl moze biti na vise racuna dobave. To je
n:m veza, koja se rjesava dodavanjem nove tabele. U tu novu tabelu se smjestaju detalji - mozemo je nazvati detalji nabave. Znaci, da ponovim - sad su u pitanju nabave tri tabele: Artikl, DetaljiNabave, Nabava. U nabavi drzis podatke o datumu, dobavljacu, i ostalim podacima, nema stranih kljuceva. U DetaljimaNabave atributi su ti ArtiklId (FK), NabavaId (FK), Kolicina i CijenaNabave. Prodajnu cijenu drzis u tabeli Artikl, koja nema nikakve veze sa Nabavom, osim u slucaju da zelis praviti automatsku kalkulaciju kroz program. Prodajna cijena se mjenja rucno (govorim opet prema ovome sta tebi treba), znaci - gazda mjenja kako mu pase. Stanje na izlazu sa lagera je isto, samo sto imas tabele Artikl (ona ista od maloprije naravno), DetaljiProdaje i Prodaja. Prica je potpuno simetricna, cijena po kojoj je neki artikl prodan se zapisuje u DetaljeProdaje, tu se vise nikad ne mjenja, mjenja se samo prodajna cijena u tabeli Artikl, koja govori po kojoj ce se cijeni artikl prodavati kada dodje trenutak prodaje (znaci, koji ce se iznos preslikati u DetaljeProdaje). Nakon prodaje cijena u tabeli Artikl moze ostati ista, a moze se i promijeniti. Ona cijena po kojoj je prodano, u tabeli DetaljiProdaje, nikad se ne mjenja. U tabeli Prodaja mozes povezati i neku tabelu Kupci, medju kojima moze biti i kupac Kalo/Rastur, te mozes dodati atribut da li je neka "prodaja" placena ili ne (znaci - veresija).
Citat:
Bazu ću razvijati samostalno i kad je završimo postaviću je na uvid svim članovima foruma. Pozdrav
Eto, de odgovori na navedena pitanja, prvenstveno ovo sto mi je nejasno, pa ako budes znao okaci i sliku baze podataka neka stoji...
Pozdrav!
My programs don’t have bugs, they just develop random features.