Citat:
anakin14: Getsbi, to sto si napisao prvi put cujem od nekoga da predlaze da tabele pozicije nekog dokumenta ujedinim u neku tabelu zbog komplikovanosti... Pa upravo se tako i komplikuje jedna tabela! Access je relaciona baza i poenta je da tabele zbog lakseg unosa i pregleda rasclanjavas na podtabele, a moj primer ne da je prost nego nije ni blizu komplikovanoj bazi i upravo sam zbog toga i trazio pomoc, da unapredim bazu a ne da je spustim na nivo srednje skole...ovo je dobronamerna kririka.
Nisam shvatio da su to tabele nekih dokumenata. Ukoliko si zamislio da Nabavka, Pozicija nabavka, Prodaja, Pozicija prodaja predstavljaju dokumente, onda O.K. Razradi ih kao dokumente. Verovatno sam krivo shvatio jer si pominjao i neke pojmove finansijskog knjigovodstva što me je dovelo u zabludu da se radi o kompleksnijem programu u kojem će se voditi i drugi dokumenti tipa Izvodi žiro računa, blagajne i ostalo. U takvom slučaju savetujem da se svi dokumenti drže u dve tabele DokumentZaglavlje i DokumentStavke ili baš ako hoćeš pozicije. Uz to bi išla i tabela VrstaDokumenta koja je nadređena prethodnim dvema. Ono što je svakako bezbolnije od posebnih vođenja cenovnika je tabela PrometRobe u kojo bi se beležila sva dešavanja iz onih dokumenata koja se tiču kretanja robe, obzirom na postojanje i onih dokumenata koja ne utiču na robni promet. Ne delim modele na srednjoškolske ili nedaj bože visokoškolske već prosto na efikasne i manje efikasne. Ovi drugi kasnije zahtevaju mnogo više rada pri programiranju, mnogo više dodatnih akcionih query-ja, a i izvore podataka za izveštaje je teže napraviti. Raščlanjivanje na podtabele kao i grupisanje kolona u zajedničku tabelu je proizvod razumevanja poslovnog problema i nema mnogo veze sa preterivanjem u jednom ili drugom smeru. Uz poštovanje pravila normalizacije tabela, razumevanje poslovnog problema bi trebalo da iznedri kvalitetan model.
Citat:
anakin14: 1) kako da u nekoj tabeli postavim kolonu u kojoj korisnik nece moci da unosi podatak vec je podatak automatski i to . Proizvod neka dva druga polja u istom slogu recimo vrednost = kolicina puta cena, a kako da ta vrednost bude u tabeli nabavka a da bude jednaka proizvodu svih kolicina i cena u pozicijama nabavke pod tom sifrom nabavke?
Ovo se ne radi u tabelama. Moguće je eventualno u Query-jima. Mada ni to ne savetujem prečesto jer se izračunate vrednosti sasvim lako dodaju na izveštajima i nepotrebno ih je skladištiti u bazu podataka. Ovo su kako si dobro primetio relacione baze podataka, a ne dimenzione, gde postoje takozvane tabele činjenica i tabele dimenzija. Tamo je dozvoljena, čak i poželjna denormalizacija tabela, radi ostvarivanja posebnih vrsta upita za buduće izveštaje koji ne prate transakciju podataka već njihovu analitiku. U takvim bazama se u upitima grade izračunata polja koja se upotrebljavaju za analizu.
Citat:
anakin14: 2) kako da u tabeli roba stavim kolonu stanje u kojoj je vrednost takodje automatska i daje zbir svih ulaza i izlaza to jest zbir svih kolicina sa pozicija prodaje i nabavke a da pritom kolonu kolicina u poziciji prodaje validiram da ne moze za taj slog u zavisnosti od sifre robe biti veci od stanja iste robe u tabeli roba? Puno hvala
Kolona stanje je takođe izračunata vrednost i ne može se uvesti u tabele, bar ne na onaj način kako to tražiš. Takođe bi se moglo u Query-ju rešiti takav zahtev. Ovaj zahtev oko validacije količine robe je sasvim u redu i to se rešava u aplikaciji prilikom unosa u polje količina, koristeći neki od mogućih događaja nad poljem unosa koje Access nudi, a VBA podržava.
Pitanja vezana za izračunata polja karakteristična su za ljude koji su dugo radili u Excelu. No sve jedno brzo ćeš shvatiti razliku jednog i drugog alata.
Veruj mi da su mi saveti dobronamerni, bar koliko i tvoji.
Dodatak: Evo linka ka temi koja obrađuje pitanje kafića
http://www.elitesecurity.org/t133029
a ovde je grupa tema koje će ti biti interesantne:
http://www.elitesecurity.org/t165367-Magacin-Maloprodaja-Kafic
[Ovu poruku je menjao Getsbi dana 15.11.2007. u 17:38 GMT+1]