Ja bih jednostavno - u dve tabele. U tabeli uplata da postoji kolona "tip". Treću tabelu napravi samo sa tipovima uplate, pa veži na "tip" tabele uplata. Onda lako sabiraš, filtriraš...

Bila je slična tema. http://www.elitesecurity.org/t373152-0#2388034

Mislis da napravim tabelu "Uplata" u kojoj bi bio "Datum uplate" i "Tip uplate" i drugu tabelu "Tip" u kojoj bi bila "Vrsta uplate" i "Iznos uplate"?

Hvala kolega Getsbi. Sad cu je prostudirati ;)

I moraš imati i tko ti je uplatio

Ovako nekako.

U tu srednju tabelu pišeš i zaduženja i uplate.

Zaduženje:

Iznos: Datum:
-1000,00 01.01.11

Uplata

Iznos: Datum:
200,00 02.01.11

Desnu tabelu popuni prvo, tu upiši sve moguće vrste (nazive) transakcija tipa "zaduženje", "uplata rate", uplata u celosti", "gotovina" ili šta ti već treba.

Onda popuniš prvu tabelu članova. Te dve se uglavnom dalje ne menjaju.

Vrlo je jednostavno za napraviti i kasnije jednostavno za sabiranje, oduzimanje, filtriranje...

Jedini problem koji vidim je taj da neko mora da vodi računa o tome na koliko rata će neko da plati, pa šta posle kad ne plati neku ratu, kako to pronaći. Možda da u tabelu članova stavite polje sa napomenom gde bi pisali recimo "odobreno plaćanje na 5 rata po 200 KM".

Onaj problem, možda je rešenje da se odmah kod zaduženja onome što date na rate odmah popunite tabelu uplata ovako:

Iznos: Datum:
-200,00 01.01.11
-200,00 01.02.11
-200,00 01.03.11
-200,00 01.04.11
-200,00 01.05.11

Odnosno zadužite ga po mesecima _unapred_. Kako on bude plaćao, a posle protoka 01.05.11 zbir mora da mu bude na nuli. Tako nađete ko kasni sa uplatom i koliko.

Ovako, napravio sam kostur.

Tabela clanovi ce sadrzavati sve podatke o clanovima koji su potrebni.
Tabela ClanoviDomacinstva ce biti popunjena podatcima o bracnom drugu, djeci, osobama u skrbnistvu nositelja domacinstva.
Tabela Uplate, vezana sa tabelama Clanovi i TipUplate, ce vuci podatke o vrsti uplate iz tabele TipUplate i sadrzavati ce podatke o IznosuUplate za odredjeni TipUplate i DatumuUplate
Tabela TipUplate ce sadrzavati podatke o svim tipovima uplate koje je moguce izvrsiti.

Sto se tice placanja na rate. Godisnja clanarina je 10E. Omoguceno je placanje odjednom i placanje na rate. Na rate ne ide mjesecno, nego kako ko plati. recimo, danas placa 2E, sljedeca 2-3 mjeseca nista, onda donese 5E i tako sve dok ne plati iznos godisnje clanarine koji iznosi 10E. Znaci nema tacno po mjesecima i moze se platiti do kraja godine.

Ono je bitno da se moze putem kverija dobiti spisak onih koji su platili kompletnu clanarinu, one koji su platili samo dio clanarine i one koji nisu platili nista.

Hvala puno na smjernicama!


_{[Ovu poruku je menjao sensei dana 11.11.2011. u 10:57 GMT+1]}

Danas sam se konsultovao sa profesorom po pitanju seminarskog i sada imam dvojbu.
Naime, radi se o nosiocima domacinstva i clanovima domacinstva.
Za pretpostaviti je da ce neko dijete, koje je danas recimo clan domacinstva, sutra biti nosioc svog vlastitiog domacinstva.
Pa sam u dvojbi, da li uzimati razlicite podatke za nosioce i za clanove, pa kad clan postane nosiocem unijeti mu i preostali dio podataka,
ili druga opcija, po meni jednostavnija,
da se za sve unesene osobe u bazi podataka uzimaju isti podatci. Kasnije kad neko postane nosiocem domacinstva iz lookup wizarda ga dodjeliti kategoriji nosioca i obrnuto.
Sta mislite?
Hvala puno

U relacionoj teoriji to se zove uloga (rolename). Svi su članovi, samo pojedinci imaju posebnu ulogu. Mislim da je druga opcija osim što je jednostavnija i logičnija.

Prepravio sam, sada imam samo jednu tabelu "Clanovi" u kojoj se cuvaju podatci o svim clanovima.
Naisao sam na jedan problem, pa ako me mozete uputiti na moguce rijesenje istoga.
Naime, baza podataka bi trebala da vodi evidenciju o cijelim obiteljima. Cim nosioc domacinstva postane clanom, njegov bracni partner i djeca se takodjer unose u bazu sa svim trazenom podatcima.
E sada, ako samo imam jednu tabelu u kojoj drzim clanove, kako da odredim ko je ciji clan obitelji?

Kako da za nakog clana znam ko mu je otac, majka, ko su mu djeca i sl ako je sve u jednoj tabeli?

Hvala vam puno, ovo me jako buni.

Može putem hijerarhije i dodatnih atributa (kolona). Unesi u polje za pretragu foruma reč hijerarhija. Bilo je tema vezanih za taj pojam. A možda će neko imati vremena da pogleda prikačeni fajl. Ja sam u gužvi.

Citao sam na ovom forumu o tome, kako ste mi i preporucili, kao i na nekoliko drugih izvora koje sam nasao na netu.
Nekako mi se to sve cini prekomplicirano. Ja sam na faxu, druga godina, i na predmetu "Uvod u baze podataka" pored teoretskog dijela koji moramo savladati, jeste i seminarski rad u accessu 2007.

Da li postoji neko jednostavnije rijesenje osim hijerarhije i denormalizovanja?

Kojim bi vi putem rijesili sljedeci problem?

Naziv teme jese Religijski klub.

Baza treba da vodi evidenciju o:
Svim clanovima kluba.
Clanovi se dijele na dvije vrste:
1. Nosioci domacinstva (Osobe koje su glava obitelji i koji s vremenom mogu postati "obicni" clanovi domacinstva)
2. Clanovi domacinstva (Sinovi, kcerke i sl. koji s vremenom mogu postati nosioci domacinstva)
Ovo mi je bas nejasan dio. Da clanovi ne mogu mjenjati statuse (sad nosioc, sad "obicni" clan) najlakse bi mi bilo voditi ih u dvije tabe i zavrseno. Ovako, stvarno ne znam kako da odradim tabelu. Imam osjecaj da je prilicno jednostavno, ne vjerujem da bi dao za seminarski na uvodu u baze nesto high advanced, ali opet... :(

Uplatama članarine od 2011 godine pa dalje. Clanarina se placa u iznosima od 5, 10 i 15E i moze se palacati na rate. Sistem placanja na rate je postavljen tako da placanje ne ide mjesecno (kao npr. tel racuni), nego kako ko plati. Danas placa 2E, sljedeca 2-3 mjeseca nista, onda donese 1E i tako sve dok ne plati iznos godisnje clanarine za jedan od tri "paketa" koja je odabrao (5,10,15). Znaci nema tacno po mjesecima i moze se platiti do kraja godine.

Uplatama raznih dobrovoljnih priloga. (Humanitarne akcije, prilozi za ovo/ono)

Ako sve u vezi domaćinstva mora u jednu tabelu onda hijerarhija kako sam predložio. Ako to nije uslov onda više tabela relacijski povezanih. U svakom slučaju nemožeš i evidenciju članova i evidenciju članarina, priloga i ostali istorijat voditi u istoj tabeli. Samo sam u jednom momentu razumeo, da je intencija da sve u vezi fizičkih lica koja čine domaćinstvo bude u istoj tabeli.

Nemamo nikakvih ogranicenja po pitanju organizacije baze/tabela/relacija i sl. Nase je da posjetimo crkvu, i upoznamo se sa sistemom kako bi mogli napraviti sto vjerodostojniji model baze za datu temu. Mom cimeru npr. je tema seminarskog rada "Auto skola".

Ja sam u pocetku planirao ovako napraviti tabele:
tblClanoviNosioci - tblClanoviNosiociID, tblClanoviID, brClKnjizice, Ime, Prezime, JMBG ...
tblClanovi - tblClanoviID, Ime, Prezime, JMBG ...
Ove dvije tabele bi sadrzale iste podatke o clanovima, samo sto bi djelile njihovu ulogu clanova na nosioce i obicne. Bile bi povezane relacijom i lako bi znao ko je ciji clan obitelji.

Ali s obzirom da mi je profesor na zadnjim konsultacijama spomenuo da "obicni clan" sutra moze postati nosiocem domacinstva, ne vidim kako to mogu odraditi sa dvije tabele, kako "prebaciti" nekog sina koji se sutra zeni i osniva vlastitu porodicu u tabelu nosioca domacinstva?
Pale su mi je na um dvije opcije:
1. Da ubacim Yes/No polje gdje bi vodio da li se taj sin odvojio od svog oca ili nije. Ako se odvojio, to bi se vidjelo na formi njegovog oca i ostalih clanova njegove sada "bivse" obitelji. Njega bi onda ponovo unio kao nosioca domacinstva, kao novog clana.
2. Da stavim opciju "Obrisi clana obitelji". Obrisem sina koji zasniva svoju porodicu iz baze i onda ga ponovo uvedem kao nosioca obitelji.

Sto se tice uplata, to planiram voditi u posebnoj tabeli
tblUplate - tblUplateID, nazivUplate, iznosUplate, datumUplate

Ako te priloge daje domaćinstvo, a ostali članovi se vode u evidenciji zbog visine priloga, onda bi to moglo otprilike ovako:



Znači dve tabele. Domaćinstvo i Čllan. PK su DomacinstvoID i ClanID. Preneseni ključ je DomacinstvoID. Veza je jedan prema više na strani Clan. "Nosioc" je uloga ili rolname koje sam pominjao i može da bude tvoj predlog: tip Yes/No. Kad se sin oženi ili ćerka uda, tada menjaju domaćinstvo i menja im se DomacinstvoID. Ukoliko je to domaćinstvo postojalo u prvoj tabeli, tada se samo ažurira druga tabela. Ukoliko je to novo domaćinstvo u parohiji, a čine ga već postojeći parohijani, tada se dodaje novo domaćinstvo u prvoj tabeli. Tako se izbegava upisivanje istog lica dva i više puta. Ženi se može menjati prezime uz promenu DomacinstvoID, a muškarcu dodavati ili oduzimati status nosioca uz promenu DomacinstvoID. Treća tabela je evidencija uplata koju si predvideo ali mora nositi informaciju koje domaćinstvo je izvršilo koju uplatu. Više je na strani Uplata.

Ja to tako vidim na osnovu iznetih informacija.


_{[Ovu poruku je menjao Getsbi dana 16.11.2011. u 22:47 GMT+1]}

Hvala ti puno na ovom modelu kolega Getsbi. Mislim da ce ovo raditi super.

Izmjenio sam tabele i relacije po tvom uputstvu i daje rezultate kakvi meni trebaju. Puno ste mi pomogli.

Jos cu malo istestirati, pa javim rezultate i eventualne probleme :)

Jos jednom hvala puno ;)

Istestirao sam model rijesenja koji mi je predlozio kolega Getsbi, sve je super i radi odlicno.

Zanima me, da li mogu dizajn forme napraviti ovako kao u uploadovanom primjeru:
Putem forme "Domacinstvo" unosimo novu porodicu u bazu. Generise se novi ID, i unosimo adresu i telefon. Na istoj toj formi i za isti DomacinstvoID, unosimo podatke nosioca obitelji.
Da li mogu staviti ogranicenje da "Nosioc Yes/No" polje ne moze biti "NULL" prilikom unosa nove obitelji i njenog nosioca?

Postaviti dugme na formu koje ce sluziti za unos nove porodice, to sam istestirao i radi.

Kako dodati clana neke porodice, i kojom metodom je najbolje "vući" PorodicaID broj kada dodajemo obicnog clana?
Da li je moguce to uraditi, bez da onaj ko radi za bazom mora pamtiti PorodicaID argument i ponovo ga unositi. Ili npr. kod unosa clana obitelji i odabira tipa srodstva (sin ili kcer), da se prezime automatski preslika u polje predvidjeno za njega?

Mislim da je zadatak pretezak za seminarski rad druge godine programiranja. Strasno je sto je uopste postavljen takav zadatak, a jos strasnije sto profesor to ne vidi. Evo sta sam sve uspoeo da uradim tabeli Clanovi:

1. Usao sam u tabelu Clanovi i svim postojecim rekordima u koloni SrodstvoID dodelio vrednost 'Supruga' Znaci, ima 6 rekorda i svi su supruge i sto je najgore, svako je svakom zena!
2. Onda sam isto uradio za kolonu Nosioc. Sve sam proglasio za nosioce.
3. Osobu iz rekorda ClanoviID = 7, sa JMBG = '9888777777777' sam dodelio domacinstvu 1 kao muza i nosioca naravno, jer svi su nosioci.

Znaci, jedna ista osoba moze se pojaviti u vise domacinstava odjednom, u istom momentu. Za Boziji zakon ne znam, ali gradjanski zakon sigurno to ne dozvoljava. Niti je dobro da svako svakom bude supruga. A moglo bi biti ponegde i supruga sa muskim imenom, ili muz sa zenskim imenom. Mislim da katolicka crkva jos uvek to ne dozvoljava, da muz i zena budu isog spola. Ali tvoja baza to dozvoljava. Ni profesor ni crkva nece biti srecni, pazi sta radis

Baza podataka za tvoj slucaj, mora da obezbedi sledece uslove:

1. Svaka osoba sme pripadati samo jednoj porodici.
2. Svaka porodica mora imati tacno jednog nosioca. Nosioc moze biti ili muz ili zena.
3. Muz i zena moraju biti odgovarajuceg pola.
4. Najvise jedan clan porodice moze biti proglasen za muza ili zenu
5. Broj dece i ostalih clanova nije ogranicen.
6. Maticni broj gradjana mora biti jedinstven, ukoliko ga imamo.

Problem je sto se to ne moze lako obezbediti, barem ne u Accessu. Moraces mnogo da programiras. Ponesto moze i bez programiranja, evo ti liste:

1. Uvedi kolonu 'Spol',
2. 'BracniDrug', neka budu tipa number, integer i dozvoli samo dve vrednosti (NULL,1). Napravi unique index (Nosilac,BracniDrug) => bice najvise jedna bracni drug za svakog nozioca
3. Kolonu 'Nosilac' promeni da bude tipa number,integer i dozvoli samo dve vrednosti (NULL,1). Napravi unique index (DomacinstvoID,Nosilac) => imaces najvise jednog nosioca po domacinstvu
4. Sada ostaje da Nosilac i Barcni drug ne mogu biti istog pola. To moras programiranjem, na Before_Update eventu za formu kroz koju se unose clanovi.
5. Prvi clan svakog domacinstva koji se unese, mor abiti i nosilac. I to moras da programiras, na BeforeUpdate
6. Dodaj kolonu 'MojNosilac' koja ce za svakog clana sadrzaiti ClanID onoga ko je noislac njihove porodice. Za samog nosioca, stavis da je MojNosilac = ClaID - nosilac je nosilac sam sebi. I ovo mora da se programira, na isi onaj BeforeUpdate.
7. stavi UNIQUE index na JMBG, i dozvoli da JMBG bude prazan.
8. Stavi unique index po Br-Cl_knjizice, uz dozvolu da clanska knjizica ne postoji

Potpuno je OK da sa ovom listom odes do profesora i kazes "Ovo su uslovi koaj ovakva baza mora da zadovolji. Kako da ja to isprogramiram i postignem?" Imas potpuno pravo da pitas ovakvo pitanje, jer tehnike kojim se ovo postize gotovo sigurno nisu bile na predavanjiuma. Da jesu, ne bi bilo ovakvih zadatka.

Zakacicu ti primer koji pokazuje da dosta moze da se uradi i bez koda, ali ne pokusavaj da ga poturis kao svoj. Ne zato sto ja cuvam autorska prava, nego zato sto ce te profesor pitati kako si to napravio pa neces znati da odgovoris i onda si u problemu.

Zakaceni primer radi skoro sve sto je navedeno u listi. Zajaceni primer ne garantuje da ce nosilac i brcni drug biti razlicitog pola. Teorijski ovo deluje privlacno, ali je zato jako tesko napraviti dobar korisnicki interfejs - na primer, za kolone Nosilac, Bracni Drug ne mozete koristiti Check box.....

Zadatak koji ste dobili svakako izlazi iz okvira seminarskog rada nivoa Vašeg obrazovanja i u potpunosti se slažem sa kolegom Zidarom. Takođe radi lakše pomoći bilo bi dobro da se informacije o problemu navedu u prvom postu a ne tek što kažu sedmog dana.

Problem se ne može u potpunosti rešiti na nivou modeliranja baze već se mora i malo programirati.

U prilogu Vam dostavljam model koji po meni najviše sužava potrebu za kodiranjem. Nažalost nemam vremena da stignem da Vam apliciram ali pogledajte u primeru koji je neuređen. Primenio sam u modelu tip veze Generalizacije i specijalizacije kao osnovu. Pravilnim odabirom selekta u formama možete zadovoljiti sva ograničenja o kojima je kolega Zidar govorio.

@ Zidar
Sve što si rekao u vezi zadatka i profesora stoji. Ovo što si iskazao u šest rečenica treba da stoji u prvom postu na početku teme. Te rečenice se odnose na članove i nosioce, a potrebni su takođe iskazi vezani za finasijski deo priče. Zadatak mora da bude definisan iskazima.

Primer jednog drugačijeg poslovnog problema.

Napraviti informacioni model za videnciju osnovnih podataka o leku, za potrebe apotekarske ustanove.

Poslovna pravila:
1. Potrebno je voditi evidenciju o svim lekovima sa sledećim osnovnim atributima: Komercijalni naziv, Hemijski naziv, Doziranje, Dejstvo, Neželjeni efekti.
2. Svaki lek se koristi za lečenje najmanje jedne vrste indikacija (bolesti). S druge strane, za svaki lek potrebno je dati kontraindikacije (u kojim slučajevima se ne sme koristiti) kojih može biti više.
3. Svaki lek pripada samo jednoj primarnoj grupi lekova (npr. antibiotici, analgetici, antipiretici itd.). Lek proizvodi jedan i samo jedan proizvođač.
4. Lek se pakuje u više oblika (npr. tableta, sirup, injekcija, prašak itd.).
5. Za svaku vrstu pakovanja leka potrebno je voditi evidenciju o količini i sastavu.
6. Lek može a ne mora imati zamene, a takođe lek može biti zamena drugim lekovima iz iste grupe.


Kada se ovako postavi zadatak, onda nema dilema. U suprotnom se sve svodi na to, ko je koliko razumeo postavljača teme i da li se ranije susretao sa istim poslovnim problemom.
Nešto šira uputsva oko toga kako se definiše poslovni problem postoje u Top temi: Ako dolazite prvi put na forum ili vam treba gotova baza podataka, procitajte ovo: http://www.elitesecurity.org/t...a-baza-podataka-procitajte-ovo


Ovo sam naravno napisao zbog novopridošlih članova foruma. Zidar to odavno zna.

Ispricavam se sto sam, sto zbog neiskustva u ovome, sto zbog toga da sam postao prije nego sam se detaljno informirao i upoznao sa sistemom koji radim, lose postavio temu. :(

Plan i program predmeta Uvod u Baze podataka jeste takav se predju osnove o kreiranju tabela, formi upita, reporti i sl. i u toku tog rada, svaki student samostalno radi bazu nekog sistema cime zele simulirati realne uvjete prilikom izrade projekta. Moj zadatak jeste da idem do vjerske sluzbe, upoznam se sa njihovim sistemom rada i pokusam na osnovu toga uraditi informacioni sistem.
Ne mora, a i ne moze :) , seminarski rad mene kao studenta pokriti kompletan sistem rada crkve niti biti profesionalan kao sto bi ga radila neka softverska firma, ali ono sto moja baza pokrije treba da radi tacno i mora biti konzistentno i neprovrijecno. Dakle bez rusenja baze na netacan unos, bez karaktera u JMBG ili telefon polju, dupliciranja podataka, jedna osoba clan vise familija itd.

Malo sam razmisljao o tome da drugacije postavim zadatak. Ovo o "nosiocu i obicnom clanu" sam dobio nakon razgovora u crkvi, ali sve mi se cini da je ova podjela u softveru na "Nosioc i Obicni clan" nepotrebna i da bez potrebe usloznjava projekat.
Mislim da bi jednostavnije bilo da se uplata clanarine vodi po porodici i to bez interne podjele porodice na "Nosioc i Obicni clan". Dakle porodica nekog ID-a, npr. ID = 12 je platila clanarinu za 2011 godinu. Ko je platio ili zaradio te novce (muz ili zena, ili neko od njihove dijece mi ne izgleda kao bitan podatak ni crkvi a kamo li mom profi :) )
Takodjer, izbacio bih iz seminarskog i dio ko je kome muz-zena-dijete.
Nakon ovoga, crkva bi i dalje imala podatke o tome ko je clan koje porodice i njeno brojno stanje, koje porodice su platile ili nisu platile clanarinu.

Ovim bi izbjegao komplikacije oko toga da:
1. Svaka porodica mora imati tacno jednog nosioca. Nosioc moze biti ili muz ili zena.
2. Muz i zena moraju biti odgovarajuceg pola.
3. Najvise jedan clan porodice moze biti proglasen za muza ili zenu
i sam sebi u mnogome olaksao zavrsetak rada.

Ono sta bih morao osigurati jeste da:
1. Svaka osoba moze pripadati samo jednoj porodici.
2. Broj clanova porodice nije ogranicen.
3. Baza bude sifrirana (Samo radnik sa korisnickim imenom i sifrom moze otvoriti bazu)
4. Baza vodi vodi evidenciju o
- svim clanovima podjeljenim po porodicama
- Uplatama članarine
- Uplatama dobrovoljnih priloga
5. Baza omoguci pretragu po:
- Skolskoj spremi
- Regijama
- Godistu(+18 (biracko tijelo za izbore u odborima))
- Clanarini (platio, nije platio, po godinama, po regijama)
- Zanimanju
- Socijalno stanje (1-5) ocjene koje ce crkva voditi interno i sluziti se njima za odabir familija kojima treba pomoc.


Ne znam kako vam se cini ovako postavljen zadatak?
Ja cu poceti sa izradom baze po ovome sto sam napisao, pa ako budem imao vecih problema javim se opet.
Zelim vam svima zahvaliti sto ste mi otvorili oci i ukazali na neke stvari o kojima nisam ni razmisljao pri izradi ili testiranju uradjenog.
Hvala na pomoci!

Napokon, prava stvar:


Da se razumemo, nisi ti nista kriv. Ti si uradio ono sto je trazeno - otiso u crkvu i precizno uhvatio zahteve, pa i one koji se tesko realizuju. Ovo sto smo ti mi rekli - sta ne valja i sta ne moze - trebalo je da kaze profesor ili mentor. I nijedno resenje koje si dobio nije pogresno. I Getsbijevo, i Zoranovo i moje, i delovi resenja na pocetku, sve to stoji i vazi i moze da se napravi da radi valjano. Najvaznije je da si stekao iskustvo u postavljanju pitanja i definisanju zadatka. Opis zadatka je OK, ali na kraju moras da zavrsis sa listom parvila. Bukvalno lista, numerisane recenice, u bilo kom redosledu, a svaka iskazuje neko cvrsto nedvosmislno pravilo. Nesto od toga se pokrije shemom baze, nesto kroz ogranicenja (constraints u SQL ili validation rules u Accessu), na nivou kolone ili na nivou tabele. A nesto se i odbaci, kao nerealno ili previse komplikvan (puno rada amala dobit). Postoje i medjutabelarna ogranicenja, na primer foreign key (relationships u Accessu). Postoje medjutabelarna ogranicenja koja se ne mogu resiti uz pomoc relationships, nego se mora programirati. Sve si to imao priliku da osetis uzivo i to je dobro iskustvo.

Sad si tek na kraju procesa analize. Jako je tesko i retko se desava da iz prve dodjes do resenja. Ako se i desi, velika je sansa da si nesto prevideo. ZNas ono, 'it looks too good to be true'. Rezultat surovog procesa kroz koji si prosao je pojednostavljeni zadatak, koji moze da se uradi, i da zaista radi.

kako ovde kazu, 'well done, lad, go ahead and good luck!'

Zdravo kolege,
Ovako, uradio sam tabele i relacije po novom, pojednostavljenom projektu.
Cilj je da baza bude normalizovana do trece normalne forme.

Da li bi mogli baciti oko na relacije, tabele i ogranicenja u tabelama pa da vidimo da li sam to dobro odradio i da li mi je sta promaknulo.
Sto se tice Referencijalnog Integriteta (Kod mene ukljucen u svakoj relaciji), i Kaskadnog Update i Deleta (Kod mene nigdje nije ukljucen), moram priznati da ih ne razumijem bas najbolje i da nisam 100% siguran gdje trebam ukljuciti koje polje. :(
Hvala puno

Referencijalni integritet - čuva bazu od unosa pogrešnih podataka i obezbeđuje korektno povezivanje objekata, odnosno da se nikad ne pojavi siroče ili zapis u tabeli deteta kome ne odgovara ni jedan zapis u roditeljskoj tabeli.
Dodatne opcije u Accessu su :
Cascade Update Related Fields - kaskadno ili lančano ažuriranje povezanih polja
Cascade Delete Related Fields - kaskadno ili lančano brisanje povezanih polja

Recimo da neka porodica treba da se obriše iz nekog razloga. Biće obrisani svi članovi i njihove uplate.
U tvom primeru omogući ove dve opcije od Porodica prema Clanovi i od Porodica prema Uplate. Potom obriši prvi zapis u tabeli Porodica. Videćeš efekat u odnosu na stanje kad ove opcije nisu uključene.
Ovo se kasnije koristi kroz forme za ažuriranje i brisanje, te uprošćuje postupak.

Hvala kolega Getsbi.
Ukljucio sam kaskadno ažuriranje i brisanje povezanih polja od tabele Porodica prema Clanovi i Porodica prema Uplate.

Da li neko zna zasto svaki put kada otvorim bazu i pogledam Ralationships otvore mi se dvije tabele za regiju, Regija i Regija_1, iako izbrisem Reija_1 tabelu i sacuvam promjene na relaciji?

U tabelama sam stavio:
input maske za telefonske brojeve i datume rodjenja (Kad uradim forme planiram iskodirati da iz maticnog broja izvucem datum rodjenja osobe),
validaciju spola na M ili Z (Lookup wizard sa ponudjenim opcijama),
JMBG ogranicio na 13 i "Indeksiran(No Duplicates)",
provjeru ispravno unesenog emaila "Is Null Or ((Like "*?@?*.?*"))",
strucna sprema sa lookup wizardom sa ponudjenim opcijama od najnizeg do najviseg stepena obrazovanja,
Imena i prezimena sam stavio na velicinu 25 i kao "indeksirana (Duplicates OK)"

IznosUplate polje je formata Currency sa dodatkom skracenice BIH valute na kraju broja (KM)

Da li bi po vasem misljenju jos nesto trebalo ograniciti/staviti kao indeksirano i slicno?

Da li preporucujete da podatke o tome da li je neko zaposlen ili nije i da li je u dijaspori ili ne, vodim kao Yes/No polja ili nekako drugacije? Da li bi bilo bolje da napravim lookup wizard sa Zaposlen/Nezaposlen izborom, i za dijasporu isto tako sa Da/Ne izborom iz padajuceg menija?

Hvala!

Imaš nepotrebne duple veze. Raskini prvo veze sa Regije1 i TblUplate1, pa onda obriši tabele. U suprotnom ih Access sakrije za trenutni prikaz, a svaki sledeći put prikaže model u celosti.

Lookup wizard nije nikakva zastita integriteta podataka. Na primer, za strucnu spremu, bolje je da napravis tabelu tblStrucnaSprema i onda je povezes sa tabelom Clanovi.

Isto tako, input mask niej niakva zastita. U stvari, to je sveukupno losa ideja, ali ako bas volis neka ti input mask-a. Jedno je bitno - input mask, kao i lookup wizard nema nikakve veze sa integritetom podataka. Integritet se stiti relacijama i validacionim pravilima. Relacije: strucna sprema u tabeli Clanovi mora da dolazi iz tabele tblStrucnaSprema, kao sto si uradio sa regijama. Validation rules: Clanovi.Pol moze uzeti samo vrednosti M ili Z, sto si lepo definisao u validation rule. Neka lookup wizarda bna koloni 'pol', olaksava unos, ali NE cuva integritet. To radi validation rule. I za e-mail si lepo postavio ograicenje u validation rule.

Da li treba postaviti ogranicenja ene zavisi od naseg misljenja. Kad mislis da si napravio tabele, otvori svaku u design modu i za svaku kolonu postavi sebi pitanje: da li se moze ovde postaviti neko ogranicenje? Pazi, rekao sam SVE tabele, SVE kolone. Pogledaj tabelu Uplate. Ima li smisla uneti uplatu od 0 KM ili -15 KM? Da li se ocekuje da neko uplati na primer 25 hiljada KM?

O, i nedostaje ti jedna cela tabela. Gde vodis zaduzenja? S cim sce se uporedjivati uplate? Treba ti tabela Zaduzenja, gde ces upisivati za svaku godinu koliko treba da plati svaka porodica. Kad to imas, ond alako uporedis sumu zaduzenja sa sumom uplata i vidis ko koliko i za sta duguje.

U zivotu ces uglavnom raditi evidencije uplata, u knjigovodstvu, trgovini, bankarstvu. A tamo mora sve da stimuje - zaduzenje i uplate, to ti je jedna celina i nikada se ne posmatra samo jedna komponenta.

Srecne

Shvatio sam ovo oko integriteta, nasao sam dobar tutorijal o ogranicenjima same tabele kao i njenih polja i upravo iscitavam i dotjerujem tabele.

Ali ne razumijem ovo oko tabele zaduzenja.
Kako to treba da funkcionise?
Da li se za svaku porodicu pocetkom npr. 2013 godine mora unijet zaduzenje clanarine za tu godinu? Sta ako u bazi ima 1000 porodica?
Takodjer, imaju tri tipa clanarine, tri razlicite cijene.

Upravo tako. Za svaku porodicu pocetkom godine se unes zaduzenje clanarine za tu godinu. Sata ako u bazi ima 1000 porodica? Cemu sluze kompjuteri, ako ce neko da otvori program i rucno unosi zduzenja? Napravi se kveri koji to uradi. Pogledaj kako radi APPEND query u Accesu. Napravis ovakav SELECT kveri: "izlistaj sve porodice i za svaku porodicu pokazi koliko bi trebalo da plati clanarinu sledece godine, za svaki tip clanarine". Kad kveri proradi - vraca korktno ono sto treba - onda se rezultati tog kverija unesu u tabelu zaduzenja. Na tabeli Zaduzenja imas ogranicenej da svaka porodica za jednu godinu moze imati tacno jedno zaduzenje za svaki tip zaduzenja.

To ti je kao u maloprodaji. Na pocetku godine prodajes clanarinu porodicama i izdajes im fakturu. Kad dodelis zaduzenja zasto ne bi odstampao pismo za svaku porodicu, ili pripremio e-mail i poslao, na kome pise 'Za godinu 2013 vase zaduzenje tip 1 iznosi x dinara, zaduzenje tip 2 iznosi y dinara i zaduzenje tip 3 iznosi z dinara". Onda oni to tokom godine placaju, sto se pedantno upisuje u tabelu Uplate. Mozes im na pola godine i na krauju godine poslati izvestaj o stanju - "Draga porodico x, zaduzili smo vas ovoliko, a uplatili ste toliko, Molim da doplatite razliku...". Tekst je naravno drugaciji ako su preplatili, onda kazes "da li da vam vratimo novac ili da vam cuvamo visak uplate za sledecu godinu, pa ce vam zaduzenje biti manje". One adrese, postanske i e-mail, koje cuvas u bazi treba necemu da sluze - komunikaciji sa korisnikom. Ako ovo stvarno napravis, tvoja ce te crkva promovisati u sveca jer ces im mnogo olaksati posao.

Posto je crkva u pitanju, mozes pored rodjendana da pamtis i imendan, pa da im saljes cestitke. Ako je pravoslavna crkva u pitanju, pamtis kad je slava, pa dajes svestenicima listu kuca gde treba otici da se blagosilja dom pre slave, a domacinu saljes cestitku za slavu. Kompjuteri su cudo Bozije, samo se treba setiti.

Ovako,
napravio sam tabelu "ClanarineZaduzenja" (UplataID, PorodicaID, TipUplateID, Iznos, Datum).
napraviuo sam APPEND Query "TipUplate" gdje sam dodao (Uplata ID iz tabele Uplate APPEND TO UplataID, PorodicaID iz tabele Uplate APPEND TO PorodicaID, Iznos iz tabele Uplate APPEND TO Iznos, OpisUplate iz tabele TipUplate APPEND TO TipUplateID)
Kao kriterij u Queriyju sam stavio "Clanarina A 2011" Or "Clanarina B 2011" Or "Clanarina C 2011" i nakon pregleda Queriya u Datasheet pogledu uredno mi ispise ID Uplate, ID Porodice, Tip Uplate i Iznos Uplate.
Nakon sto pokrenem Query i on popuni tabelu ClanarineZaduzenja, polje gdje bi trebao biti opis uplate mi ostane prazno, iako imam Lookup wizard kada kliknem na njega i mogu odabrati sta zelim. Ostali IDjevi i Cijena Clanarine je ispisana u redu.
Problem je sto nikako ne mogu izdvojiti porodice koje Nisu platile, pokusa sam sa Is Null, =0 i slicno, ali nije radilo kako treba.

Ako sam dobro razumio, korisnik baze bi trebao unijeti u bazu novi tip uplate (Clanarina A 2012 u iznosu od 10KM, Clanarina B 2012 u iznosu od 15KM, Clanarina C 2012 u iznosu od 20KM), nakon toga pokrenuti APPEND query koji bi pretrazio bazu da li ima uplata za sljedecu (2012)godinu i svakoj porodici koja nema uplatu, staviti dug u vrijednosti clanarine.
Kako cu ja znati koja porodica treba platiti koji paket (A,B,C), da li moran u tabeli Porodice staviti i polje TipClanarine sa izborom A,B, ili C paketa?
Da li za svaku godinu treba dizajnirati poseban APPEND query?
Mozes li mi malo detaljnije objasniti na kojem bi sistemu to sve trebalo raditi?

Stavit cu primjer ovoga sto sam uradio, da li sam na "pravom putu".

I bez gledanja u primer, na dobrom si putu. Tacno tako, na pocetku godine korisnik programa pokrene append query koji svakoj porodici dodeli njeno zaduzenje.
Ako porodice pripadaju razlicitim kategorijama clanarine, onda to mora negde da pise, najbolje u tabeli gde cuvas porodice. Ond akveri odatle cita kome treba kakvu clanarinu zaduziti.
Ni slucajno. Query treba da napravis tako da te pita za koju godinu zelis zaduzenje (parameter query) i to je to.

Zdravo,
Dugo me nije bilo, imao sam parcijalne ispite pa sam rad na bazi malo zapostavio dok to prodje :)

Ovako,
Malo sam izmjenio bazu, clanarinu sam odvojio od ostalih uplata. Stavio sam screenshot relacija pa mozete vidjeti.
Mislim da je ovako bolje.
Razlog za ovo je bio sljedeci.
Da ne bi uvijek unosio novi zapis u tabelu tipa: Uplata A 2009, Uplata B 2009....Uplata A 2010... i trazio to po lookup wizardu, smatrao sam za jednostavnije da imam jednu tabelu gdje cu cuvati samo podatke o vrstama clanarine i njihovoj cijeni.
Takodjer, ovako imam i historijsku nit, recimo da se promjeni cijena clanarine A koja iznosi npr 50 i poraste na 60, znati cu da je proslih godina cijena iznosila 50 i placala se 50, a od ove godine se placa 60.

Napravio sam Append kveri da izvuce podatke od prosle godine kako bih znao ko je na kojem paketu clanarine.
Ne razumijem neke stvari oko append kverija:
Kad pokrenem kveri, kupim podatke od prosle godine, kako bi znao ko je na kojem paketu i koliko treba platiti, i onda mi kveri stavi u tabelu zaduzenja stavi tu proslu godinu, npr 2009, a ja treba da ih zaduzim za 2010?
Kad pokrenem append kveri, on popuni tabelu podatcima. Ako ga ponovo pokrenem on doda jos podataka, jel to OK, da se tabela uvijek iznova puni i puni, ili se moraju brisati prethodni podatci?
Kako na tabeli Zaduzenja staviti ogranicenje da svaka porodica za jednu godinu moze imati tacno jedno zaduzenje za svaki tip zaduzenja?


Ako mozete samo pogledati i primjer baze u accessu i dati mi vas utisak o uradjenom poslu, savjet ili sugestiju za neke greske kojih sigurno ima bio bih vam mnogo zahvalan. Osjecam da nesto fali, ali ne znam sta:(

Hvala puno.

<sub>[Ovu poruku je menjao sensei dana 08.12.2011. u 12:18 GMT+1]

[Ovu poruku je menjao sensei dana 08.12.2011. u 15:20 GMT+1]</sub>

Mislim da baza koju si zakacio ne odgovara dijagramu relacija koji si dao u poruci. Posto vec kacis razne verzije baze, molim te da im das razlicita imena, recimo Klub_01, Klub_02 itd, svaki put povecaj verziju za jedan, inace se ne mozemo snaci sta je sta. U svakom slucaju, zakaci bazu koja odgovara dijagramu, ne mozemo nista d auradimo bez toga.

Ne razumijem kako mislis da ne odgovara dijagramu relacija koji sam zakacio uz bazu? Napravio sam printscreen relacija te baze.

Ime sam popravio, dao sam mu naziv KLUB_01.

U bazi sam, pored opend kverija koji mi sluzi da zaduzim clanove za narednu godinu, napravio i nekoliko drugih koji mi sluze za pretragu clanova koji su platili clanarinu, i slicno.

Evo moj primjer.
Napravljeno je da je uplata na nivou domacinstva.
Nisam sve procitao pa ne znam.
Ukoliko nije tako onda u tabelu tbl_transakcije treba dodati i polje clanId iz tabele Tbl_domacinstva i povezati onda ove dvije tabele.

Hvala puno na tgrudu, ali promijenuli smo nekoliko stvari od pocetka ove teme. Ne vodim u bazi vise ko je nosioc domacinstva i slicno jer je prekomplikovano za izvesti a nista ne dobivam s tim. Njima i onako nije bitno ko je taj novac zaradio, jer uplate ne idu individualno nego po domacinstvima. Hvala na primjeru koji si okacio, drago mi je vidjeti nacine ogranicenja u tabelama i poljima.

Ako imas vremena i nije ti problem, mozes li pogledati primjer baze koji sam okacio?

Pa napravio si sve u principu sto i ja stim sto ja ne praktikujem kljuc automatski brojac.
Ima doduse nekih korekcija sto treba napraviti:
Tabela Porodica:
U nju treba prebaciti polja iz tabele clanovi i to:
regijaId
GodinaUclanjenja
BrojClKnjizice
Adresa
Telefon

Samim tim sepokazuje da tabela regija treba biti vezana za porodicu odnosno za adresu stanovanja odnosno da svi clanovi stanuju na istoj adresi.
U tvom slucaju gore navedena polja bi morao popunjavati za svakog clana ponaosob iako su podaci isti.
Tabele zaduzenja i uplate su potpuno iste sto znaci da moze biti jedna tabela napr da se zove promet sa dodatnim poljem koje bi imalo obciju duguje ili potrazuje.
U tvom slucaju to bi bilo:
1.-Zaduzenja
2.-Clanarina
3.-Dobrovoljni prilog za djecu
4. -Dobrovoljni prolog za crkvu
5.-Jos neka druga donacija ili zaduzenje itd..

Ovim poljem u tabeli promet i sa kodnom tabelom vrsta prometa sa navedenim stavkama rijesio si se dviju kodnih tabela Tip uplate i tip clanarine.
Ako jos dodas i polje godina onda ti netreba niti tabela clanarine godine.

Pozdrav i sretan rad.

Tek sam poceo raditi u Accessu, i nije mi bas najjasniji nacin baratanja s novcem i pojmovima duguje/platio/po godinama.
Kolega Zidar mi je dao jedan prijedlog, i mislim da on radi dobro. To je ono sa dvije tabele, gdje se u jednoj vode zaduzenja a u drugoj ko je platio, sto mogu saznati kalkulacijama izmedju njih.

Da li ja ako napravim (kako savjetujes) tabelu "Promet" u kojoj ce biti sljedeci podatci:

Tabela Promet:
1. PrometID
2. PorodicaID
3. VrstaPrometaID
4. Iznos
5. Datum

Tabela VrstaPrometa:
1. VrstaPrometaID
2. NazivPrometa (Lookupwizard sa opcijama: zaduzenje, clanarina, dobrovoljni prilog i sl)


Mogu ovakvim nacinom jednostavno, bez puno programiranja, saznati putem kverija:
ko je platio clanarinu i za koju godinu
ko duguje clanarinu i za koju godinu
koliko clanarine je uplaceno po godinama
koliko clanarine se duguje po godinama
koliko je prikupljeno novca za neku dobrotvornu akciju
i slicno?

Hvala!

_{[Ovu poruku je menjao sensei dana 14.12.2011. u 09:00 GMT+1]}

Da napomenem da si zaboravio jos dodati godinu.
To polje znaci za koju godinu je zaduzenje i za koju godinu je uplata jer nemora uplatiti u tekucoj godini tu godinu.


ko je platio clanarinu za koju godinu ces dobiti jednostavno ako u queryu- odaberes kriterij godina.
Ukoliko si napravio kodnu tabelu koju sam preporucio i nakacio je na polje vrsta prometa ID onda bi po ovom polju bio kriteri 1 or 2 stim da bi dodao samo jedan uslov pa bi to izgledalo ovako:
Isplata:iif(vrstaPrometaID=1;Iznos*-1;Iznos)
Znaci odabtao bi polja za Query:
PorodicaID (GroupBy)
Isplata (Sum)-Novo polje koje sam gore naveo
Godina (Where)

ko duguje clanarinu i za koju godinu- i ovo imas u istom Query-u

koliko clanarine je uplaceno po godinama
za ovo ti isto tako treba sum Query sa poljima.
Iznos (Sum)
Godina(GroupBy)
koliko je prikupljeno novca za neku dobrotvornu akciju
Sum Query sa poljima:
Iznos(sum)
VrstaPrometaID(Where) =3
Primjer dobrovoljni prilog za djecu.
Ako hoces po godinama dodas i polje godina koje bi bilo GroupBy.

Hvala na brzom odgovoru.
Njima je clanarina najbitnija, i problem kod clanarine je pored toga sto je imaju tri vrste i taj sto se njena cijena s vremena na vrijeme mijenja.
Dakle, baza bi morala osigurati da, ako clanovi placaju clanarine od 2000- 2011 godine po cijenama od: 10, 15 i 20KM, a sljedece godine se to promjeni i bude 30, 35 i 40KM, se sacuva historijska nit o placanju. Dakle ako se promjene cijena clanarine, da mi za prosle godine ostanu uredni podatci o tome kolika je bila visina clanarine i o njenom placanju. Zbog ovog razloga mi se cini za bolje da odvojom clanarine i tipove clanarine od ostalih uplata (dobrovoljnih priloga, pretplata na novine i sl) u zasebne tabele. CIm dodjem sa faxa kuci, pokusat cu ovaj tvoj nacin.

Kad sam razgovarao s njima, ovako su mi rekli: Nama je najbitnije da znamo:
ko je platio clanarinu i za koju godinu
ko duguje clanarinu i za koju godinu
Kad otvorimo neku porodicu da znamo sve sta je uplatila (clanarinu, dobrovoljne priloge, pretplate na noviune i sve ostalo)
koliko clanarine je uplaceno po godinama
koliko clanarine se duguje po godinama
koliko je prikupljeno novca za neku dobrotvornu akciju

Onda za polje godina moras napraviti kodnu tabelu koja bi imala dva polja:
Godina
IznosPretplate.
Ovo je dovoljno ukoliko svi pretplatnici imaju isti iznos pretplate a ukoliko nemaju trebas uvesti polje kod pretplatnika grupa pretplatnika.

Imaju tri vrste pretplate: A, B i C, i trenutne cijene su ovakve.
A = 10KM
B = 15KM
C = 20KM

Od cega ovise vrste pretplate.
Jel se odnose na pojedina domacinstva ili.....

Pretplate su po domacinstvima. Dakle, dodje porodica, uclani se i sama odabere koju tarifu zeli placati. Valjda su neke vjerske usluge jeftinije ako je veca tarifa... U glavnom porodica sama bira koliko ce placati clanarine, moze bilo koju od ove tri tarife odabrati. Najvise ih placa tip A.

Onda u tabelu porodica dodaj jos jedno polje a to je tip uplate sa kodnom tipovi uplate.

Napravio sam bazu po savjetima koje si mi dao. Zalijepit cu je ovdje da vidis, nadam se da nisam nista profulao :)

Sve mi je prilicno jasno, osim dijela koji radi s novcem-uplatama.

Da li ja moram za svaku narednu godinu zaduziti sve clanove clanarinom za nju i voditi im to kao dug kako bi znao ko mi je platio a ko nije? Npr: sada da zaduzim sviju za 2012 godnu iznosom clanarine koji trebaju platiti?

Da li u tabeli TipClanarine vodim evidenciju cijene clanarine za svaku godinu? Npr: A = 10 KM za 2010 godinu, A = 10 KM za 2011 godinu, A = 12 KM za 2012 godinu itd.

Hvala!

Sve si dobro napravio.
Samo ti netreba tabela Clanarine godine.
Dodaj samo u tabelu uplate jos jedno polje a to je godina.
Tu ces upisivati za koju godinu se vrsi uolata ili clanarina ili pak zaduzenje.
Jos bi ti predlozio a ti ces znati dali treba, u tabeli porodica polje datumIsclanjenja.


Ovo mozes a i nemoras.
Kodom se moze rijesiti ali naravno lakse je ako zaduzis sve clanove iznosom na pocetku godine.
Nemoras sada ni razmisljati o tome, bitno je da je rjesivo.

U kodnoj tabeli tip clanarine mozda dodas jos jednu opciju a to je Donator i bez iznosa.
Ili ako hoces mozes dodati cijelo polje TipClana pa ima 2 opcije Donator i clan.
Pomocu ovoga i godine razduzenja sto sam predlozio razdvajas clanove od donatora i bivsih clanova.

Uradio sam ovako, i sad radim kverije.
Mislim da cu se snaci sa pretragama:))

Palo mi je nesto na um. Ima li iko prijedlog kako da vodim porodice? Mogu po prezimenima, uzimati prezime onoga ko je glava obitelji. U porodici moze biti različitih prezimena i to mi ne smeta:) Kako da ih pretrazujem, jer mi nema smisla da to budu IDjevi a ima puno porodica sa istim prezimenom:)



_{[Ovu poruku je menjao sensei dana 21.12.2011. u 07:52 GMT+1]}

U bazi imam posebnu tabelu u kojoj cuvam podatkje o skolskoj spremi:
1. I Stepen četri razreda osnovne
2. II Stepen - osnovna škola
3. III Stepen - SSS srednja škola
4. IV Stepen - SSS srednja škola
5. V Stepen - VKV - SSS srednja škola
6. VI Stepen - VS viša škola
7. VII Stepen - VSS visoka stručna sprema
8. VII-1 Stepen - Specijalista
9. VII-2 Stepen - Magistratura
10. VIII Stepen - Doktorat

Znam kako napraviti kveri koji ce pitati korisnika da unese pojam koji zeli pretraziti, ali, da se ne bi ovoliko kucalo u parametru, da li je moguce napraviti da na formi za pretragu ima padajuci meni (lookup wizard) preko kojeg se moze izabrati neki od ovih pojmova i nakon sto se odabere zeljena sprema, da kveri pretrazi bazu i izbaci sve one koji imaju tu strucnu spremu?

Mozda ovako

Hvala puno. Upravo to mi treba. Kako se zove ovaj nacin pravljenja formi i kverija kako bi mogao dodatno progooglati o njemu? Nije mi bas najjasniji VBA kod :( Kako si ovo napravio?
Hvala jos jednom!

<sub>[Ovu poruku je menjao sensei dana 27.12.2011. u 17:44 GMT+1]

[Ovu poruku je menjao sensei dana 28.12.2011. u 10:18 GMT+1]</sub>

Zna li neko kako se zove ovaj nacin pravljenja formi i kverija koji je kolega SLOJ.1973 izbacio, kako bi mogao dodatno progooglati o njemu jer mi nije bas najjasniji nacin kako se ovo prvi :(

Otvori formu u design modu, klikni na properties i pročitaj u polju Default View koji je tip forme u pitanju. U list box-u ćeš naći i ostale tipove formi.

Imam tabelu "Porodice" gdje drzim podatke o porodici (Adresa, kucni telefon itd) i posebnu tabelu "Clanovi", gdje su personalni podatci o clanovima. Ove dvije tabele su povezane preko "PorodicaID" polja.
Poceo sam praviti forme, i zamislio sam to na sljedeci nacin.
Prvo unosim podatke o porodici, kada zavrsim, na formi "Porodice" kliknem na dugme "dodaj clana porodice" i otvori mi se forma "Clanovi" sa ID-jem "Porodice" koju sam upravo unosio, tako da znam koji clanovi pripadaju kojoj porodici.
Kako da izvedem da mi se ID od "Porodice" prenese na formu "Clanovi"?
Ovo mi je jako bitno.
Hvala vam puno!

Bilo ko? Savjet? :(

Okaci to sto si odradio pa da vidimo sta se tu moze odraditi.

Dve tabele.
Porodica: (PorodicaID, Prezime, adresa, stabilni telefon....)
Clan: (PorodicaID, ClanID, Ime, mobilni telefon.....)
Veza: Porodica prema Clan, jedan prema više.
Glavna forma ima za izvor tabelu Porodica, a podforma ima za izvor tabelu Clan. Formu i podformu povezuješ osobinama Link Child Fields i Link Master Fields, popunjavajući polje PorodicaID.

Pogledaj kako se pravi forma i podforma. Ima u Top temama.

Izvinjavam se sto nisam postao ranije, ali forum mi je otvaralo jako sporo tako da nisam mogao:(

Evo primjera.
Ono sto meni treba jeste:
Prvo unosim porodicu i njene podatke. Kad zavrsim sa tim podatcima, da mogu kliknuti na dugme "Dodaj clana" i da mi otvori formu clanovi u add modu i sa IDjem porodice koju sam upravo unio.

Ako ima neko elegantnije rijesenje recite.
Hvala vam puno!

Ne znam zasto, ali opet nisam uspio uploadati file. Cak sam kreirao novi sa samo dvije tabele i dvoje forme kako bih bio laksi, ali nije uspjelo:(

Nadam se da iz napisanog u proslom postu razumijete koji je moj problem i sta zelim.

Najelegantnije rešenje je da počneš onako kako sam napisao u prethodnom svom postu. Potom da galvnu formu (nad tabelom Porodica) postaviš kao Single Form, a podformu (nad tabelom Clan) postaviš kao Datasheet. Onda ti nije potrebno posebno dugme za DodajClana. Jednostavno će biti i dodavanje novih i ažuriranje prethodno unetih. Pogledaj primer na koji sam te uputio.
3) Dobar primer za: način povezivanja tabela, pravljenje forme i podforme, kreiranje izračunatih polja na formi ......
http://www.elitesecurity.org/t267874-1-Aplikacija-access-pitanja

Znam napraviti formu i podformu, to mi nije problem. To sam i uradio, na tabeli Porodice sam u podformu stavio da vuce podatke iz jednog kverija i prikazuje mi samo Ime, Prezime i Mob clanova te porodice.
Tabela clanovi ima puno polja i nikako mi se ne uklapa lijepo da na tabeli porodice drzim sva ta polja, plus, tu su i slike clanova.

Ja sam zamislio ovako:
Forma Porodice:
na njoj ce biti sve info o porodici,
subforma koja prikazuje Ime, prezime i mob svakog clana porodice
subforma koja prikazuje uplate porodice sortirana on najnovije uplate prema starijima.

na formu Porodice bi bila dva dugmica, jedan za dodavanje novog clana i drugi za dodavanje nove uplate

Napravio bih posebnu formu za clanove i posebnu za uplate koje bih pozivao klikom na dugmice koji se nalaze na formu Porodice

Problem mi je da napravim dugme "Dodaj novog clana" koje ce kada se klikne na njega, otvoriti formu Clanovi u add modu za ID porodice na kojoj se bilo u trenutku kad se kliknulo na dugmic. Isto tako i za uplatu.

Slazem se da je ovo daleko lakse i jednostavnije, ali estetski ne mogu ga nikako lijepo uklopiti ...

Predpostavljam da nisi dobro povezao formu i podformu. U suprotnom podforma bi filtrirala samo one članove porodice koji imaju ID u glavnoj formi i po defaultu bi bila u Add modu. Zakači ti ipak tvoj .mdb fajl pa će možda FOX028 ili neko drugi imati vremena da pogleda.

Ako ti dugmad nisu neophodna onda ih izbegavaj, jer nad njima moraš da pišeš VBA kod, koji opet treba izbeći ako nije nužan.

KOliko vidim, forma i subforma rade dobro. Bio bih zahvalan kad bi mogli naci malo vremena i pogledati rad jer uskoro trebam predavati seminarski pa .....
Hvala vam puno.

I ima li neko prijedlog, osim ovoga oko otvaranja forme za dodavanja clanova, kako da ograncim da jedna porodica moze maksimalno jednom platiti neku godinu. Da je u pitanju samo jedan tip clanarine, lako bi to rijesio, ovako, gdje imaju tri razlicite clanarine, bas me buni?
Hvala!