[es] - Logicki problem u projektovanju baze

protech_v2
protech_v2
Novi Sad

Član broj: 12426
Poruke: 169
*.eunet.yu

+12 Profil

Logicki problem u projektovanju baze

^{07.10.2004. u 21:52 - pre 237 meseci}

Konkretan problem, mada mi odgovor znaci puno prvenstveno konceptualno:

imam tabelu klijenata, tabelu proizvoda i treba mi tabela izdatih racuna (prakticno obavljene prodaje) iz koje i naknadno trebaju da se stampaju racuni sto znaci da treba da pored ID-a klijenta sadrzi i sve proizvode koje je klijent tom prilikom kupio.
Znaci imam jedan record u tabeli racuna koji treba da sadrzi NEPOZNAT broj ID-a proizvoda i posebno informacije o kupljenoj kolicini za svaki tako da ne dolazi u obzir samo dodavanje npr 10 mesta za kupljene proizvode

Kako da to resim? Jedino sto mi je palo napamet je da imam polje koje je niz sa ID-evima proizvoda koji su kupljeni i jos jednu tabelu u sa kolicinama koje su kupljene, ali cini mi se jako lose i mora da postoji "normalno" resenje?

Pretpostavljam da je to cesta situacija, pa da ce mi neko reci "iskusno" kako se to radi

Hvala!

Odgovor na temu

_owl_

Član broj: 318
Poruke: 1043
*.vdial.verat.net

+3 Profil

Re: Logicki problem u projektovanju baze

^{07.10.2004. u 22:55 - pre 237 meseci}

Treba da napravis jos dve tabele racun i stavke_racuna. Tabela racun bi sadrzala sve podatke koji su vezani za sam racun (tipa id_klijenta, id_racuna, datum_izdavanja, bla_bla_bla) dok bi tabela stavke_racuna imala kolone id_racun, id_proizvod, kolicina, naplacena_cena, bla_bla)

Owl

Odgovor na temu

_owl_

Član broj: 318
Poruke: 1043
*.vdial.verat.net

+3 Profil

Re: Logicki problem u projektovanju baze

^{07.10.2004. u 22:57 - pre 237 meseci}

Zaboravih da primetim da ti izgleda nikad nisi cuo za postupak koji se zove normalizacija. Pogledaj po forumu ima bar jedno desetak postova u kojima se nalaze linkovi ka relevantnoj dokumentaciji (koja inace predstavlja osnovu za bilo koje projektovanje baza podatka).

Owl

Odgovor na temu

protech_v2
protech_v2
Novi Sad

Član broj: 12426
Poruke: 169
*.eunet.yu

+12 Profil

Re: Logicki problem u projektovanju baze

^{08.10.2004. u 00:00 - pre 237 meseci}

Naravno da sam primenio normalizaciju, ali problem nije u tome - odgovor koji si mi dao mi nije pomogao zato sto takvim resenjem nista ne dobijam - verovatno nisi shvatio pitanje, mozda nisam dobro objasnio:

ja treba za svaku prodaju da imam po jedan takav racun koji treba da sadrzi unapred nepoznat broj stavki tj. proizvoda ukljucenih u njega, plus informacije o naplacenoj ceni i kolicini za svaku od tih stavki

znaci kako u okviru recorda u tabeli racuni da imam navedene kupljene proizvode ili kako drugacije to da resim - ovako kako si ti rekao (primenjujuci Level 1 normalizaciju i odvajajuci stavke racuna) bi znacilo da za svaki racun imam po jos jednu tabelu, a to je definitivno lose resenje jer bi za 1000 racuna imao dodatnih 1000 tabela (!)

Odgovor na temu

Simke
Marko Simic
Sandfield Associates (Solution
Developer)
Novi Zeland

Član broj: 1158
Poruke: 751
*.dialup.xtra.co.nz

ICQ: 71578686
Sajt: www.sandfield.co.nz

Profil

Re: Logicki problem u projektovanju baze

^{08.10.2004. u 06:48 - pre 237 meseci}

Nisi shvatio sta ti je _owl_ rekao.

Imas DVE tabele, Invoice i InvoiceItem. Invoice je header - znaci broj racuna, ko je kupac, datum itd. InvoiceItem sadrzi artikle koje je kupac kupio - jedan rekord po artklu, znaci one-to-many odnos. Sto znaci da za svaki racun imas jedan ili vise rekorda u InvoiceItem tabeli, ne posebnu tabelu (?).

All beer is good. Some beer is better.

Odgovor na temu

jablan

Član broj: 8286
Poruke: 4541

+711 Profil

Re: Logicki problem u projektovanju baze

^{08.10.2004. u 08:27 - pre 237 meseci}

Ako radiš sa MS SQL Serverom, uz njega dobijaš sample bazu koja se zove Northwind. U njoj je upravo ono što ti treba (kupci, dobavljači, proizvodi, narudžbenice). Pogledaj tamo kako se to radi.

Odgovor na temu

gosha
Zemun

Član broj: 2384
Poruke: 589
*.smin.sezampro.yu.

+40 Profil

Re: Logicki problem u projektovanju baze

^{08.10.2004. u 09:56 - pre 237 meseci}

Citat:

protech_v2: Naravno da sam primenio normalizaciju, ...

Na bih ja rekao da si primenio normalizaciju.
Pozabavi se ti jos malo literaturom.

Pozdrav Goran.

NAPOMENA:Ovo je dobronamerna poruka. :)

JokeJunky :)

Mrzim sublimirane marketinske poruke.

Odgovor na temu

gosha
Zemun

Član broj: 2384
Poruke: 589
*.ppp-bg.sezampro.yu

+40 Profil

Re: Logicki problem u projektovanju baze

^{08.10.2004. u 10:33 - pre 237 meseci}

Pošto imam malo vremena da pojasnim kako bi tekao tok normalizacije.

Imam racun koji sadrži sledeće podatke:
IDRacuna, Broj, Datum, Partner i koji sadrži jednu ili više stavki.
OVDE SE VEĆ VIDI RELACIJA JEDAN-VIŠE

Ukoliko bih pokušao da stavim stavke u kolone tabela bi izgledala:
IDRacuna, Broj, Datum, Partner, IDProizvod1, Kolicina1, Cena1, IDProizvod2, Kolicina2 ... i dokle ovo ? (NIKO NE ZNA)
GREŠKA: NARUŠAVANJE PRVOG PRAVILA NORMALIZACIJE (KOLONE KOJE SE PONAVLJAJU TREBA ODVOJITI U POSEBNU TABELU)

Ukoliko bih pokušao na drugi način, a to je da za svaku stavku računa ponavljam
podatke o zaglavlju računa. Tabela bi izgledala ovako:
IDRacuna, Broj, Datum, Partner, IDProizvoda, Kolicina, Cena
OVIM SE NARUŠAVA TREĆE PRAVILO NORMALIZACIJE (KOLONE KOJE NISU KLJUČEVI U TABELI I NE ZAVISE OD PRIMARNOG KLJUČA TABELE TREBA IZDVOJITI U POSEBNU TABELU).
U ovom slučaju Kolicina i Cena zavise od IDProizvoda, a ne od IDRacuna.

Konačno rešenje:
Tabela Racun
IDRacun, Broj, Datum, IDPartner ....

Tabela RacunStavke:
IDStavke, IDRacun, IDProizvod, Kolicina, Cena ...

U prethodnoj poruci si rekao da bi morao da imaš tabelu stavki za svaki račun.
Ne moraš jer ćeš preko IDRacun izvući stavke za odgovarajući rn.

Nadam se da sam bio jasan.

Pozdrav Goran.

JokeJunky :)

Mrzim sublimirane marketinske poruke.

Odgovor na temu

protech_v2
protech_v2
Novi Sad

Član broj: 12426
Poruke: 169
*.eunet.yu

+12 Profil

Re: Logicki problem u projektovanju baze

^{08.10.2004. u 16:28 - pre 237 meseci}

Hvala vam puno na trudu, sinoc sam otpao po netu i gledao tutoriale i kad sam malo bolje razmislio nije mi bilo jasno sta mi nije bilo jasno

Presudno je verovatno to sto sam pocetnik pa nemam rutinu - normalizaciju sam primenio kad sam izdvojio tabele klijent, racun i korisnik, a ovo me zbunilo jer sam non-stop gledao dijagram u kome su stavke (atributi) postavljeni vertikalno i stalno sam imao u glavi kako tako nikako ne mogu imati proizvoljan broj stavki

debil Mozda sam ipak previse radio juce

Resenje mi je odmah postalo jasno kad sam skinuo DBDesigner i primenio many-to-many na racune (koji su one-to-many povezani sa klijentom) i sa proizvodima pa kad je sam razdvojio tabele i napravio pomocne...

Izvinjavam se _owl_u sto sam tako pozurio da kazem da nije u pravu

Uglavnom, naucio sam svasta juce i danas, a ako ovo cita neko od pocetnika, ima jako dobar i kratak tutorial o ovim stvarima na

http://www.utexas.edu/its/wind...tabase/datamodeling/index.html

Odgovor na temu