Poceo sam da pravim bazu u koju bi se unosili projekti za elektro radove na objektima. Postavio sam nekoliko tabela: tblVlasnik, tblProjekat, tblStavkeProjekta i tblDetaljiStavke, a s druge strane imam tabele: tblMaterijali i tblAktivnosti.
Za odredjenu aktivnost je potrebno da se utrose odredjeni materijali iz tabele tblMaterijali. S obzirom da se aktivnosti ponavljaju od projekta do projekta, definisao sam novu tabelu tblSastavnica koja ce trajno cuvati informaciju koja aktivnost je povezana sa kojim matarijalima.
E sad kad se krene u popunu projekta, prvo se navede vlasnik, pa se zatim da ime projektu, a zatim je potrebno da se izborom stavke projekta (koja ustvari predstavlja jednu od aktivnosti) povuku u tabelu tblDetaljiStavke svi materijali koji su potrebni za realizaciju te stavke, odnosno aktivnosti i onda je potrebno samo da se unesu potrebne kolicine.
POMOC: Da li je struktura koju sam ja postavio dobra i ako je dobra kako povezati tblSastavnica i tblDetaljiStavke
Povezao sam ti tblaktivnosti i tblStavkeProjekta preko IDAktivnosti. Tako ćeš dobiti ono što si hteo. Inače trebalo bi u tblSastavnica proglasiti obe postojeće kolne za kombinovani ključ i dodati polje kolicina, da se zna koliko materjala ulazi u koju aktivnost. To nisam uradio jer bih morao da raskidam veze i praznim tabele, jer primarni ključevi moraju biti određeni pre punjenja podataka. Valjalo bi još dodati i tabelu sa jedinicama mere i povezati je sa tblMaterjali.
U tblSastavnica ne mozemo dodati kolicinu jer se ona za pojedinu aktivnost mijenja od projekta do projekta (kolicina zavisi od velicine konkretnog objekta), spisak materijala potrebnih za realizaciju odredjene aktivnosti je fiksan (mada se i taj spisak moze mijenjati, npr uvodjenjem novih materijala za odredjenu aktivnost). Ne znam samo da li ce naknadna promjena spiska materijala (ili brisanje nekog materijala) za odredjenu aktivnost uticati na projekte koji su uradjeni npr. prije godinu dana kada se koristio stari spisak.
Sto se tice praznjenja tabela to nije nikakav problem, ja sam unio podatke samo radi testiranja.
Ostaje jos jedno pitanje: Kako u tabeli tblDetaljiStavke dobiti one materijale koji su vezani za aktivnost koja je odabrana u tblStavkeProjekta.
Da li mozda definisati na formi, da se kod izbora aktivnosti, svih materijali koji su definisani za tu aktivnost u tblSastavnica prekopiraju u tblDetaljiSTavke ili mozda da se napravi neki query.
fahre: U tblSastavnica ne mozemo dodati kolicinu jer se ona za pojedinu aktivnost mijenja od projekta do projekta (kolicina zavisi od velicine konkretnog objekta), spisak materijala potrebnih za realizaciju odredjene aktivnosti je fiksan (mada se i taj spisak moze mijenjati, npr uvodjenjem novih materijala za odredjenu aktivnost).
Onako kako si ti postavio model inplicira da jedna aktivnost može sadržati više proizvoda, odnosno da jedan proizvod može učestvovati u više aktivnosti i to je sasvim u redu. Zbog toga i postoji tblSastavnica. Problem je što se za sada nezna učešće jednog u drugom. Kada postaviš kolicinu kao vezu moći ćeš svaku novu aktivnost da specificiraš kroz sastavnicu jer je jasno da "Nabavka materijala i postavljanje instalacija u kupatilu" nije ista u stanu A i stanu B. Osim što ne mora da bude upotrebljena ista vrsta i količina materjala aktivnost ne mora ni da traje podjednako dugo. Zato ti je i potreban šifarnik aktivnosti koji će biti mnogo više razuđen i specifičan, a ne tako uopšten.
Citat:
fahre: Ne znam samo da li ce naknadna promjena spiska materijala (ili brisanje nekog materijala) za odredjenu aktivnost uticati na projekte koji su uradjeni npr. prije godinu dana kada se koristio stari spisak.
Upotrebljene šifre se nikad ne brišu i to ćeš morati da obezbediš kroz aplikaciju određenim zabranama.
Citat:
fahre: Ostaje jos jedno pitanje: Kako u tabeli tblDetaljiStavke dobiti one materijale koji su vezani za aktivnost koja je odabrana u tblStavkeProjekta.
Preko ključa IDStavke projekta(tblStavkeProjekta) odnosno IDstavke (tblDetaljiStavke). Koristi upite kad god ti nešto treba.
Odgovor na zadnje pitanje je da će ti trebati verovatno i nešto VBA koda mada nije isključeno da to rešiš sa append query.
Ako je zadatak samo praćenje projekta bez skidanja količina iz magacina, praćenja cene koštanja proizvoda i usluga, praćenja dobavljanja proizvoda, onda je ovakva struktura dovoljna. Ako je u pitanju ovo drugo onda si bojim se tek na počrtku mnogo većeg modela.
Posto nije cisto knjigovodstvo, nego vodjenje dokumentacije o gradjevinskim radovima, moram malo da se umesam. Ipak sam ja Zidar po profesiji :-)
Fahre je dobro poceo, Getsbi jos bolje pomogao. Getsbijev rezon je OK, ali ima prostora za poboljsanje.
Ima upload uz poruku, ali preporucjem da ko zeli da razume data model, procita poruku.
Da rezimiramo problem:
1. Gradjevinska firma izvodi projekte za neke vlasnike (klijente).
2. Projekt je neki posao koji se satoji od vise aktivnosti - izgradnj/adaptacija nekog objekta
Iz nekog razloga, aktivnosti na projektu nazivamo Stavke Projekta.
3. Svaka aktivnost ima podrazumeva ugradnju odredjenih materijala.
Skup materijala koji se zahtevaju za datu aktivnost nazivamo Detalj Stavke.
4. za svaku aktivnost postoji 'receptura' - koji materijali ce se utrositi.
Recepturu za aktivnosti zovemo Sastavnica.
5. Koliko se materijala trosi, to receptura ne definise, to zavisi od konkretne stavke
Usvojimo simbol za relaciju -----< kao JEDAN ------< VISE.
Iz do sada recenog ocigledne su hijerarhijske (jednoznacne, jednosmerne) relacije:
1. ==> Vlasnik ima vise projekata ==> (Vlasnik ---< Projekat)
2. ==> Projakt ima vise stavki (aktivnosti) ==> (Projekat ----< Stavke)
3.1 ==> Stavka ima detalje stavki ==> Stavka -----< Deatlji Stavke
Imamo i dve relacije koje nisu jednoznacne
3.2 ==> Stavka Projekta zahteva ugradjivanje jednohg ili vise materijala ==> (Detalji Stavke ------< Materijali)
3.3 ==> Svaki materijal moze biti u vise stavki ===> Materijal ------< Detalji Stavki
4.1 ==> Svaka aktivnost u recepturi ima jedan ili vise materijala ==> Aktivnost ----< Materijal
4.2 ==> svaki amterijal moze biti deo recepture za jednu ili vise aktivnosti ===> materijal---< Aktivnosti
Relacije (3.2,3.3) i (4.1,4.2) se realizuju 'tabelama u preseku'
Sve je ovo Fahre lepo zapoceo, a Getsbi poboljsao.
Gde je moje poboljsanje? Zakaceno na poruku, ali vredi procitati objasnjenja:
1. Izbacio sam kolonu IDStavkeProjekta (koja je PK kod Getsbija). Zasto? Nije potrebna, jer kombinacija kolona (IDAktivnosti, IDProjekta) jednoznacno odredjue svaki red u tabeli tblStavkeProjekta. Ako dodamo vestacki PK, postoji opasnost da zaboravimo da osiguramo jedinstvenost (IDAktivnosti, IDProjekta). No to i ne bi bilo toliko strasno, dodmo UNIQUE index i mi smo OK. Problem je u nastavku:
Vestacki PK, IDStavkeProjekta , je prenesen u tabelu Detalji stavke, pa je vrlo tesko videti kojoj aktivnosti u stvari detalj stavke pripada. Zasto je vazno znati kojoj aktivnosti pripada detalj? Pa da bismo znali koji materijal iz recepture da dodelimo stavki projekta i da se to lepo vidi.
Da ne duzim, predlazem model ovako:
tblValsnik: (IDvlasnika = PK, NazivVlasnika)
tblProjaket: (IDProjekat = PK , NazivProjekta, IDVlasnika)
tblStavkeProjekta (ja bih je radije nazvao AktivnostiProjekta ali nema veze), kao (IDProjekta,IDAktivnosti,RBStavke), PK cine sve tri kolone
tblDetaljiSTavke: (IDProjekta, IDAktivnosti, RBStavke, IDMaterijala, Kolicina, Cena), PK = (IDProjekta, IDAktivnosti, RBStavke, IDMaterijala) Zasto ovde Cena? Da se zapamti po kojoj ceni smo prodali materijal za zadati projekat. Cena se menja vremenom i ne zelimo da se cena svih projekata iz proslosti promeni kada u tabeli MAterijali promenimo tekucu cenu.
tblSastavnica: (IDAktivnosti,IDMaterijala) , PK cine obe kolone. Svrha ove tabele je da cuva tekucu 'recepturu' za aktivnosti koje dodeljujemo projektima.
tblMAterijal (IDMaterijal = PK,NazivMaterijala,JedinicaMjere, TekucaCena) TekucaCena = tekuca cena materijala, menja se kroz vreem i dodeljuje se Detaljima Stavke.
Osnovne operacije na modelu:
- Kreiranje novog projekta: INSERT INTO tblProjekat ... jednostavna formica ce ovo da uradi, sa lookup na tblVlasnik
- Dodeljivanje stavki: INSERT INTO tblStavkeProjekta .... forma i subforma. Glavna forma frmProjakt, subforma frmSTavkeProjekta_Datasheet, ima lookup na tblAktivnosti
- dodeljivanj materijala aktivnostima ****** VAZNO*****
: za svaki red iz tblStavkeProjekta, odraditi APPEND kveri koji radi otprilike ovako
INSERT INTO tblDetaljiStavke (IDAktivnosti, IDmaterijala, Cena)
SELECT tblSastavnica.IDaktivnosti, tblSastavnica.IDMaterijala, tblMaterijal.TekucaCena
FROM tblSastavnica
JOIN tblMaterijal ON tblMaterijal.IDMaterijal = tblSastavnica.Materijal
WHERE tblSastavnica.IDAktivnosti = tblDetaljiStavke.IDAktivnosti
Ovo moze da odradi funkcija koja se poziva posle unosa aktivnosti u tabelu tblStavkeProjekta. Tako nesto ti je i Getsbi predlozio. Ja sam dodao prenos cene u igru. Na ovaj nacin se tekuca cena dodeljuje detalju stavke. Ako se kasnije promeni cena u tabeli Materijali, nece se promeniti nista u tabeli DetaljiStavke. Materijali koji se prenose su samo oni koji se u tom momentu nalaze u tabeli Sastavnica. Dakle, ako se sastavnica menja kroz vreme, tako sto se raznim aktivnostima dodaju ili oduzimaju materijali, to nece imati efekta na projekte iz proslosti.
Za laksi rad na gradjenju aplikacije, preporucujem da napravis jedan monster view (query) koji ce da poveze sve tabele modela osim Sastavnice. Na tom kveriju mozes da pretrazujes i vuces podatke za sve zamislive reporte i read-only forme.
Proizvodnja i knjigovodstvo su zaista oblasti koje bolje poznajem od građevinarstva. No sve jedno. Uvek se ima šta naučiti. Ono u vezi IDStavkaProjekta nije moja ideja. To sam zatekao i pokušavao da shvatim krajnji cilj, odnosno da sagledam buduću aplikaciju. Sad mi je jasnije zašto Fahre neće kolicinu u sastavnici. Model je OK.
E da, uvrstio sam model u klekciju pod nazivom Praćenje projekta.
Pozdrav.
[Ovu poruku je menjao Getsbi dana 01.06.2007. u 17:44 GMT+1]
povezivanje relacijama
