Kiro je vrlo lepo opisao proces u auto servisu. iz Kirinog opisa sledi da ti trebaju u stvari dve aplikacije:
1) na izlazu iz magacina, gde mehanicar preuzima delove
2) na recepciji Auto servisa, gde se
a) kreira radni nalog (onaj koji mehanicar uzme i id s njim da preuzme delove)
b) kreira se racun za klijenta, a na racunu pise rad (izvrsene usluge, servis) + delovi
Naravno, obe aplikacije gledaju u istu bazu podataka (back end), koji je naravno Access
Kakva treba da bude baza podataka da bi podrzala ovaj proces? Ocigledno je da treba tabela sa klijentima (ime, prezime, adresa, telefon). Zatim treba tabela sa delovima. Pa onda tabela sa uslugama (servisima) koja sadrzi ServisID, potrebno vreme i mozda cena usluge, ako nije strogo po satu. Posto delovi i usluge nisu isto, naravno da ce biti u odvojenom tabelama. Onda treba tabela RadniNalog, koja sadrzi datum, IDnaloga, ID klijenta. Za svaki radni nalog, postojace jedan ili vise servisa i (nula, jedan ili vise) delova. To daje jos dve tabele, RadniNalogUsluge i RadniNalogDelovi.
Kako ce da izgleda racun? U zaglavlju podaci o klijentu i radnom nalogu. Onda dve detaljne sekcije: usluge i delovi, dakle neka vrsta UNION. Da li ce racun biti tabela ili kveri, zavisi od mnogo detalja koje mi ovde ne znamo, ti ih znas, pa odluci. Verovatno ce ti trebati barem tabela za zaglavlje racuna, sa DatumRacuna i IDracuna i status (nije jos placen, placen, ponisten i slicno)
Sve u svemu, rad je rad a delovi su delovi i ne treba ih mesati. Moguce je da postoji veza izmedju delova i usluga. Na primer, za uslugu 'Zamena ulja' mehanicar moze da trebuje ulje, ali ne i gume ili razvodnu kapu ili ne daj boze diferencijal

Ako je tako, onda je potreban jos jedan set tabela, koje definisu 'recepturu', to jest odredjuju koji delovi idu uz koju uslugu. U praksi, verovatno da postoje usluge sa strogo definisanom recepturom, ali i usluge gde to nije definisano bas precizno.
Da te ne zamaram dalje, imas dosta materijala za razmisljanje.
Srecan rad!