Niste se baš potrudili da proučite ono što su Vam iskusni forumaši preporučili prije godinu dana na forumu Baze podataka. Inače sad Vam ne bi bio naročiti problem da postavite osnove baze. Ono što je tipična početnička greška je kretanje od aplikativnog modelovanja, odnosno odmah se krene na izradu aplikacije, što je čini mi se i kod Vas slučaj. Međutim nije to tolko strašno, svi su u početku tako pokušali, pa i ja. Veća je greška ne poslušati one koji su to već prošli.
Osnove se postavljaju najprije Funkcionalnim modelovanjem, a kao njegov osnov je opis samog poslovnog procesa u nekoliko rečenica. Znaci ne:" Treba da vodim podatke o ...,i da dobijem to i to... ", već poslovnih procesa. Pokušajte to da nam opišete, pa ćemo se potruditi da Vas uvedemo u način razmišljanja pri modelovanju baze a dalje ćete sami uz korišćenje dostupne literature i primjera.
Ps. Ako mozete konvertujte bazu u Access 2003, odnosno .mdb

Da Vam malo olakšam.
Očigledno je da radite u nekoj građevinskoj firmi i želite da osmislite neku bazu koja bi Vam olakšala posao, međutim iz navoda nije jasno kom sektoru radite. Da li ste neki referent u tehničkoj podršci gdje vodite računa o vozilima ili u kadrovskoj službi gdje vodite podatke o zaposlenima ili nešto treće....
Najprije se određuju granice posmatranog sistema. U tom ograničenom sistemu neke informacije, odnosno dokumenti dolaze spolja (van tog sistema,iz neke druge službe, od nekih lica van posmatranog sistema)-ulazne informacije, u nemu se ti podaci pod dejstvom nekih zakona i propisa-kontrola,u procesima koji se u njemu dešavaju i koje izvršava neko ili nešto -mehanizmi transformišu i obrađuju da bi na izlazu iz tog sistema proizvelo neke nove informacije i dokumente koji iz tog sistema izlaze- izlazne informacije. Znači kao takav (izolovan)posmatrajte realni sistem za koji želite napraviti bazu i opišite nam ga.

Radim u građevinskoj firmi kao tehničar transporta i građevinskih mašina. Moj posao se ogleda u tome da trebam da vodim računa o tehničkoj ispravnosti vozila, registraciji vozila, isteku raznih atesta za vozila, ispravnosti tahografskih uređaja odnosno i tome kada se vozilo treba uputiti na baždarenje taho uređaja, zatim vođenje evidencije o polisama osiguranja i isteku istih, vođenje evidencije kasko osiguranja za ona vozila koja isto poseduju... Sve ovo poseduju i građevinske mašine, osim taho uređaja.
Takođe je moja obaveza i da vodim evidenciju kada i kom vozaču ističe lekarsko uverenje, vozačka dozvola... Među vozačima ima i onih koji nemaju stalno zaposlenje već ugovor o obavljanju privremeno povremenih poslova sa važenjem od mesec dana koji se po potrebi produžuje ili ne.

Vodim evidenciju o karakteristikama vozila i osnovnim podacima zaposlenih u mom sektoru.


Polise osiguranja, ateste, uverenja o baždarenju tahografa dobijam od III lica, odnosno to su ulazne informacije. Ugovore o radu i produženje istih dobijam iz kadrovske službe.

Izbacuje mi grešku kada hocu da konvertujem u Access 2003.

Ono što smo saznali u prvom objašnjenju grafički možemo predstaviti kao na slikama u prilogu. Ako sam pogrješio u terminima ispravite me. Saznali smo osnovne ulazne informacije i ko je odgovoran za prikazane procese. Nemamo za sada još podatak o izlaznim informacijama ali smo krenuli da kopamo temelje. Sjutra ću Vam postaviti dodatna pitanja da bi smo išli dalje u modelovanju.

Da krenemo dalje. Namjerno sam proces imenovao "Tehničkim sredstvima" jer se radi o više vrsta. Da li u svom sektoru pored vozila,građevinskih mašina i prikolica imate još nekih sredstava koje bi se mogle svrstati u ovu grupu?
Sam proces "Vođenje podataka o tehničkim sredstvima", po mom viđenju stvari mogao bi se podjeliti u više podprocesa a to su:
-Evidentiranje tehničkog sredstva
-Kontrola tehničke ispravnosti
-Osiguranje i registracija
-Vođenje evidencije upotrebe
-Evidentiranje oštećenja i otpis
Pa da postavimo dodatna pitanja o svakom podprocesu.
Evidentiranje tehničkog sredstva:
- Iz kog dokumenta se unose podaci o tehničkom sredstvu( servisna knjižica i sl.)
-Da li sva sredstva imaju neko jedinstveno i nepromjenjivo obilježje(broj šasije i sl.)
-O kom broju sredstava se radi?
Kontrola tehničke ispravnosti:
-Ko kontroliše tehničku ispravnost? Postoji li posebna služba- Radionica,tehnička podrška?
Da li se vrše dnevni(prije upotrebe),nedeljni,periodični pregledi ispravnosti? Šta se kontroliše, ko ga vrši i da li to negdje evidentira?
-Za koja sredstva je potreban atest i kako se odvija proces dobijanja atesta?
- Pretpostavljam da se koriste i analigni i digitalni tahografi?
-Ako tehničku ispravnost kontrolišu i utvrđuju spoljni partneri da li se tačno zna ko su i da li se evidentiraju?
Ko upućuje sredstvo na tehnički pregled?
Osiguranje i registracija:
-Da li imate ugovire sa tačno određenim osiguravajućim kućama?
-Kako se vrši registracija i osiguranje za građevinske mašine i prikolice?
Evidencija upotrebe:
-Da li jedno sredstvo duži,vozi,održava i za njega odgovara 1 ili više zaposlenih i da li jedan zaposleni duži više sredstava.
-Može li se angažovati na sredstvu zaposleni koji ga ne duži?
-Šta prethodi angažovanju sredstava, odnosno na osnovu čega se angažuju?
-Da li se koristi putni-radni nalog i ko ga izdaje? Gdje se evidentira?
-Da li se evidentiraju i čuvaju podaci sa tahografa i na koji način.
-Da li vodite evidenciju o potrošnji goriva i maziva? Kako se njime zadužuju sredstva?
-Gdje se čiste sredstva nakon upotrebe i ko ga vrši?
-Da li za upotrebu sredstava trebaju odgovarajuće dozvole. Pretpostavljam da ne može svak biti angažovan na svakom sredstvu.
- Da li se i na koji način razdužuje sredstvo nakon upotrebe? Kako teče ovaj proces?
Oštećenje i otpis:
-Šta se dešava pri udesu-oštećenju sredstva? Kako teče ovaj proces.
-Na koji način se vrši otpis sredstva, šta mu prethodi, koji dokumenti prate i kako se odvija ovaj proces?
-Postoji li starosno ograničenje za upotrebu sredstava?
Vođenje podataka o zaposlenima
I ovaj proces će imati svoje podprocese ali za sad samo da postavimo nekoliko pitanja:
- Da li su u Vašem sektoru zaposleni o kojima vodite evidenciju samo vozači ili ima i drugih struka( mehaničari, vulkanizeri...)
-Da li Vi potražujete radnike ili Vam ih šalju bez Vašeg zahtjeva. Kako teče ovaj proces.
-Za šta je bitno ljekarsko uvjerenje i koja je periodičnost obnavljanja. Pretpostavljam da je to propisano zakonom. Kojim? Postoji li starosno ograničenje za upravljanje sredstvima?
-Koje dozvole,sertifikati su potrebne za upravljanje kojim sredstvima?
-Šta se dešava u slučaju gubitka prava upravljanja, vozačke dozvole?
-Kako se planira angažovanje radnika?
- Šta se dešava kada su na odmoru, bolovanju?

Potrudite se da precizno odgovorite na data pitanja. Ako se neki dokument pojavljuje ,a vezan je za neko od pitanja naglasite nam koji. Nemojte žuriti, odgovori trebaju biti što precizniji.

_{[Ovu poruku je menjao nenadmarkoni dana 27.02.2015. u 11:39 GMT+1]}

Za sada nemam, to su mi za sada jedina sredstva.


- Podaci o tehnickim sredstvima se unose iz servisne knjizice i to osnovni podaci o vozilima i masinama.
- Imaju invetarni broj, broj šasije i broj motora koji su jedinstveni.
- Imam 40 terenih vozila, 20 prikolica, 20 putarskih vozila, 21 putničko vozilo ( broj ovih vozila je pomenljiv jer se kupuju nova ili se stara rashododaju)


- Tehnicku ispravnost kontroliše referent tehničke ispravnosti a popravke na vozilima i otklanjanje eventualnih kvarova otklanja servisna radionia.
- Radi se periodični pregled vozila na svakih tri meseca ( provera signalizacije, upravljačkog sistema...) i pravi neki kao izveštaj za svako vozilo.
- Atest je potreban za vozila na koja se vrši neka nadogradnja, na primer prilikom ugrađivanja plina u vozilo, ili primer koji sam skoro imao je taj što smo na jedno vozilo ugradili dizalicu nosivosti 1t. Prilikom svakog od tih nadograđivanja atest dodeljuje ili auto moto savez ili neka druga ovlašćenja kuća.
- Da, neka vozila imaju analogni tahograf a neka digitalni tahograf. Baždarenje tahografa radi ovlašćeni servis, i za analogni tahograf uverenje važi godinu dana i za digitalni 3 godine. Svako uverenje ima svoj broj, podatke vozila, datum kada je izvršeno i do kada važi.
- Teretna i putarska vozila se na svakih 6 meseci voze na vanredni tehnički pregled i to u 99,99% radi jedan isti servis.


- Sredstvo upućuje referent tehničke ispravnosti a ponekad i ja.



- Imamo ugovor sa tačno određenom kućom, Dunav osiguranje.
- Registracija i osiguranje mašina se vrši isto kao i za vozila, samo što se mašine ne voze na tehnički pregled.



- Na žalost, zbog vrste posla, jedan zaposleni duži vozilo ali ga ne koristi isključivo samo on, već više njih koristi to jedno sredstvo.
- Može.
- Svakodnevno se izadaju putni nalozi i isti evidentiraju sa sledećim podacima: broj putnog naloga, Ime i prezime vozača, relacija.
- Sredstva se angažuju na osnovu trebovanja koje šalju rukovodioci službe održavanja i gradnje. Za svaki posao se trebuje određena vrsta i broj vozila i mašina.
- Evidenciju potrošnje goriva vodi koleginica.
- Podaci sa tahografa evidentira koleginica koja za to koristi specijalizovani softver koji pomocu skenera očitava parametre sa taholistića ili pomoću uređaja za očitavanje digitalnih tahografa.
- Sredstva čiste, odnosno samo operu vozači odnosno rukovaoci građevinskih masina, na puromatu u sklopu firme.
- Za upravljanje vozilima potrebno je posedovanje C, D ili E kategorije.
- Sredstvo se razdužuje samo kada zaposleni napušta posao ili menja radno mesto.


- Pri udesu sačinjava se zapisnik, slikaju se oštećenja i uzima izjava zaposlenog.
- Otpis sredstva ili rashod je proces sa kojim nemam dodirnih tačaka ali raspitaću se kako funkcioniše taj proces.
- Starosno ograničenje za sredstvo ne postoji.



- Od zaposlenih imam: vozače, rukovaoce građevinske mašine, vozače i rukovaoce na privremenim poslovima, referente...
- U suštini ja pošaljem zahtev za produženje ugovora kada zaposlenom istekne a direktor daje odobrenje da li će se istom produžiti.
- Bez važećeg lekarskog vozač ne može da vozi kamion jer je to tako definisamo zakonom o saobraćaju. Lekarsko može da važi maks 3 godine a lekar može da ga izda i na rok važenja od godinu dana ako proceni da zaposleni treba ranije na kontrolu iz bezbednosti. Lekarsko za rukovaoce važi godinu dana. Starosno ograničenje ne postoji.
- Za upravljanje kamionima potrebne su C,D i E kategorije vozačke dozvole ( na primer vozač bez E kategorije ne sme da vozi kamion sa prikolicom).
- U slučaju gubitka dozvole vozač se preraspodeljuje na druge poslove ili se šalje na odmor.
- Angažovanje radnika se planira na osnovu trebovanja koje sam spomenuo.
- Nakon povratka sa odmora, bolovanja ili vikenda kada nisu radili, vozaču se izdaje potvrda od kada do kada nije upravljao vozilom, jer je vozač po zakonu osaobraćaju dužan da kod sebe u svakom trenutku ima putne naloge ili potvrde za poslednja 6 dana.

Nadam se da sam sve napisao, ako primetim da sam nesto izostavio dodacu.

Kvadrat sa slike iz mog predzadnjeg posta predstavlja cjelokupan realni sistem za koji se projektuje baza podataka, a to je posao ( koji ćemo u narednom periodu analizirati i razložiti na radne procese) koji je vezan za Vaše radno mjesto. Strogo je ograničen samo Vašim poslom. Svi poslovi, informacije i dokumenti van njega, pa makar to bile informacije i dokumenti od ili ka koleginici sa druge strane istog radnog stola su van njega i predstavljaju ulazne odnosno izlazne informacije. Ja nemam pojma o Vašem poslu i sve informacije vezane za njega možete dati samo Vi. Sam razlog ove teme je da Vas uvedemo u način razmišljanja pri projektovanju baze podataka pa je zbog toga bitno da Vi shvatite poentu ovih strelica i kvadratića odnosno analize realnog sistema kroz Funkcionalno modelovanje primjenom IDEF0 standarda. Znači, svaki dokument, svaka informacija, sve osobe, oruđa i radna mjesta koja ne pripadaju realnom sistemu koji se preslikava, moraju biti van projektovanog modela i od njih ili ka njima mogu voditi samo ulazne odnosno izlazne strelice. Nasuprot tome, svi dokumenti, informacije, osobe, oruđa, zakoni,propisi i pravila, radna mjesta itd. koji su u tom sistemu moraju se uzeti u obzir i ne smiju se previdjeti jer kasnije ubacivanje je prilično komplikovano. Kao što ste vidjeli kreće se od jednog kvadratića koji predstavlja cjelokupan realni sistem za koji se projektuje baza i određuje njegovu širinu. Kasnije se taj generalizovani proces dekompozicijom razlaže na podprocese koji se u njemu javljaju, pa se svaki taj proces dalje razlaže sve dok se ne dođe do primitivnih procesa koji prema definiciji daju samo jedan izlaz. Tada se prelazi na Informaciono modelovanje. Da li Vam je jasna poenta? Za pojedine stavke će trebati dodatna objašnjenja da bi smo ih pravilno unijeli u model a to ćemo sjutra. Za sada je bitno da dobro pročitate ovo što sam napisao i da to razumijete. Ako nešto nije jasno pitajte.

Sada mi je sve mnogo jasnije i još bolje shvatam onu vašu sugestiju gde ste mi rekli da je greška što sam odmah počeo sa izradom aplikacije.
Značiće mi mnogo to što ću sa nekim iskusnijim da razvijam bazu jer ću brže savladati te neke osnove i načine razmišljanja prilikom izrade baza.
Izvini što odgovaram malo kasno na pitanja jer zbog posla ne stižem.

Prema informacijama koje ste dali, a i prema onome što sam ja iz toga saznao napravljen je Funkcionalni model primjenom CASE alata BPWin i prikazan na slikama u prilogu. Kvadratići predstavljaju procese koji se javljaju u sistemu koji modeliramo. Strelice sa lijeve strane su ulazne informacije koje se u tom procesu koriste. Strelice sa desne strane su izlazne informacije-dokumenti koji iz tog procesa proizilaze. Sam proces ima vremensku dimenziju, tj. potrebno je neko vrijeme da se proces izvrši. Strelice sa gornje strane su kontrole ili uslovi koji taj proces kontrolišu( Npr. Mora se najprije evidentirati vozilo da bi se evidentirao tehnički pregled koji je nad njim izvršen). Strelice sa donje strane su mehanizmi koji u tom procesu učestvuju-izvršavaju ga a sami se u njemu ne troše.
U prilogu je i BPWin fajl pa iskusniji mogu da ga koriguju i daju svoje viđenje.
Ako razumijete predstavljeni model molio bih Vas da ga verifikujete ako je ispravan ili da date primjedbe za korekciju, pa da pređemo na Informaciono modelovanje.
Za informaciono modelovanje dokumenti koje bi trebalo skenirati a Vi ste ih u objašnjenju pomenuli su :

Servisna knjižica sa podacima koji se evidentiraju (prvi list)
Izveštaj referenta tehničke ispravnosti o periodičnom pregledu
Atest
Uverenje o baždarenju tahografa
Ako postoji neki dokument kojim vozač duži vozilo i prema kome ga razdužuje
Putni nalog
Trebovanje službe održavanja i gradnje
Zahtjev za produženje ugovora
Potvrda o neupravljanju vozilom

ps. Šta je posao referenta?

_{[Ovu poruku je menjao nenadmarkoni dana 28.02.2015. u 19:20 GMT+1]}

Malo ću detaljnije da pogledam funkcionalni model koji ste postavili pa ću reći da li ima potrebe nešto ispraviti.
Što se tiče skeniranja dokumenata, to ću uraditi u ponedeljak na poslu i postaviti.
Posao referenta tehničke ispravnosti je:

- kontrola tehničke ispravnosti vozila i sačinjavanje izveštaj o periodičnom pregledu
- vođenje evidencije o registraciji vozila
- registracija vozila i mašina (kad smo kod registracije, referent mora da dobije ovlašćenje da u ime firme može da registruje vozilo i tom ovlašćenju se nalazi marka i tip vozila kao i broj motora i šasije. U suštini, referent ili ponekad ja, otkucamo to ovlašćenje i direktor ga samo potpiše. Postaviću i taj dokument u ponedeljak.
- organizovanje obavljanja 6-mesečnog tehničkog pregleda za sva teretna vozila
Ovo nisam spomenuo... politika firme a i nas u sektoru transporta je da sva vozila na svakih 6 meseci vozimo na vanredni tehnički pregled iz bezbednosti i dodatne kontrole ispravnosti.
- potpisivanje tehničke ispravnosti na putnom nalogu
- izdavanje putnih naloga
( pogledaću u ugovoru šta je još u opisu posle referenta teh.ispravnosti pa ću dopuniti odgovor)

Tek sam kasnije vidio ovu Vašu poruku. Ne znam koliko će Vam moje iskustvo značiti jer ga i ja nemam baš puno. Ni ovaj model koji je urađen sigurno nije najtačniji ali važno je da shvatite poentu modelovanja prije izrade same aplikacije. Volio bih ako @Zoran.Eremija ima vremena da da svoje viđenje modela čisto da vidite šta znači razlika u iskustvu što se tiče ovoga. A ukoliko želite da više naučite o projektovanju informacionog sistema preporučio bih Vam knjigu prof. Alempija Veljkovića u prilogu. Unijećemo izmjene prema onome što ste dodali. Idemo dalje...

Ne dozvoljava upload. Imate knjigu na http://tutoriali.org/Razvoj_in...h_sistema_i_baze_podataka.html


_{[Ovu poruku je menjao nenadmarkoni dana 28.02.2015. u 23:44 GMT+1]}

Bilo bi baš super ako bi se pomenuti @Zoran.Eremija uključio, i da nam svojim iskustvom još više pomogne.
A dok se on ne uključi mi ćemo raditi onoliko koliko znamo. :)

Hvala na preporučenoj literaturi.




_{[Ovu poruku je menjao mario.po dana 02.03.2015. u 13:42 GMT+1]}

U prilogu su skenirani dokumenti kao po dogovoru.

Juče sam bio zauzet pa nisam stigao da se javim.
Kad malo pogledam ova dokumenta čini mi se da je osnovni cilj Vašeg posla ustvari planiranje angažovanja sredstava i ljudstva za buduće poslove, planirane trebovanjem službi održavanja i gradnje, a ne evidentiranje njihovog angažovanja. Jesam li u pravu? Ako jesam onda je moguće da funkcionalni model treba postaviti drugačije.

U pravu ste. Meni je baza podataka prvohodno potrebna kako bi u svakom trenutku mogao za određena vozila na primer da odštampam brojeve šasije i motora, da vidim kom vozilu i mašini u kom mesecu ističe registracija, važenje tahografa, osiguranja, koje vozilo poseduje atest i za šta, da mogu za vozilo iz baze da odštampam zahtev za kontrolu tehničke ipravnosti, da evidentiram eventualnu saobraćajnu nezgodu, odšampam zapisnik,zatim da vidim kada radnicima na ugovoru isti ističe, kada zaposleni mora na lekarski pregled... U tom slučaju mislim da je onaj funkcionalni model u redu.
A ako uz sve to uspemo i da odradimo planiranje angažovanja ljudstva i sredstava bilo bi fantastično.

Već sam pomenuo da se pri preslikavanju realnog sistema, tj. Funkcionalnom modelovanju preslikava kompletan sistem koji je ograničen onim prvim kvadratićem(Konteksnim diagramom), i da se njegovom dekompozicijom trebaju spomenuti svi procesi koji su u njega uključeni. Kasnije se analizom dokumenata i detaljnih zahtjeva, analizom slucajeva upotrebe i toka podataka ovaj proces upotpunjuje i kroz informaciono modelovanje dobija se model baze koji bi trebao da isprati sve poslovne procese. Aplikativnim modelovanjem i programiranjem neke funkcije sistema je moguce automatizovati, a neke ne. Dobro osmisljena i organizovana baza podataka i aplikacija trebalo bi pored toga da omoguci unos samo realnih podataka i kontrolu unosa kroz razna ogranicenja. Ono sto je osnovna funkcija funkcionalnog modelovanja je da omoguci da buduca baza i aplikacija prati realni sistem.

Na ovu sugestiju u vezi planiranja su me naveli datumi na trebovanju. Vidim da je izdato 27.2 a trebuje se za 02.3 sto znaci da bi i Vi trebali prema njemu da planirate sredstva i ljudstvo. E sad planovi ko planovi znaju da funkcionisu poMarfijevom zakonu :"Ako ista ima sanse da krene naopako, krenuce naopako i to u najgorem trenutku", pa se i mi moramo tako postaviti prema tome i uvjek imati alternativu, tj vozila i ljudstvo u pripravnosti.

Upravo tako. Trebovanje se uvek daje danas za sutra, ili ako se ne radi vikendom onda u petak za ponedeljak. Najveći problem je taj što izvršenje planiranog danas za sutra zavisi od mnogo faktora, i često se ne ispoštuje u celosti, odnosno u 80-90% se vrše promene ujutru ili u toku dana, što je jako frustrirajuće, ali takva je priroda posla.

Malo sam prekomponovao Funkcionalni model.

Trebalo bi da je sada funkcionalni model u redu. Sledeca aktivnost je izdvojiti primitivne procese ( poslednje u hijerarhiji) i za svaki proces identifikovati kandidate za entitete. Pokusati identifikovati njihove atribute, tip podatka i tipove veza.
Prethodno Vi pogledajte funkcionalni model, pa razmislite za svaki primitivni proces da li postoji neki dodatni zahtjev ili dokument koji nismo pomenuli. Ako postoji takav dokument skenirajte ga.

Nastavite sa ovim modeliranjem, ali molim vas da zastanete kad dodjete do dizajna tabela i veza medju njima. Ovo sto gradite je veoma dinamicki sistem, parte se promene kroz vreme. Postojeca literatura, i na srpskom i na engleskom opisuje samo sluccajeve gde se radi o statickim sistemima - ne prate se promene nego samo trenutno stanje. Ako ignorisete cinjenicu da je sistem dinamicki i modelujete ga kao staticki ulecete u probleme. Podaci ce biti nepouzdani, nelogicni i u krajnjem neupotrebljivi. Ako ne postoji sistem koji korektno tretira dinamiku procesa (promene kroz vreme), onda su fizicki kartoni vozila/vozaca (tehnicka knjizica?) mnogo bolji metod nego bilo sta na kompjuteru.

Ako neko moze da iskopa temu koja je bila slicna ovoj, nesto o vozilima ko duzi koje vozilo, ko od koga preuzima. Tu smo prvi put nesto probali da pokazemo kako se prate promene.

U vasem konkretnom slucaju, ne prate se promene samo za vozila i masine, prate se i za vozace i mnogo toga drugog.

Ovo ni pod razno nije pocetnicki zadatak, ako se zeli ispravno resenje. Nije nemoguce napraviti sistem koji izgleda da radi sta se trazi, ali tu ide silno programiranje da bi se sprecile nelogicnosti u podacima. Na primer, vozilo zaduzio neko ko ne radi u firmi vec dve godine. Ili, datum zdravstvenog pregleda je ranije od datuma rodjenja. Ili, neko je zaduzio vozilo koje je odavno otudjeno. Neka mi niko ne kaze da se to ne moze desiti. Setite se samo koliko ste puta citali u novinama da se racuni za komunelije salju na adrese srusenih zgrada, ili se salju korisnicima koji su odavno odjavljeni, ili cak preminuli. To se desava svuda, ne samo na Balkanu. Svi slucajevi kojih se ja secam su u stvari iz Nemacke i USA.

Hvala na sugestiji. Ideja je bila da se pokaže važnost onoga što prethodi samoj izradi aplikacije, i na koji način se radi: uočavanje radnih procesa i prevod uočenog u grafički prikaz. Metodologija koja je korišćena za analizu je jedna od standardnih- IDEF0 . Sličan pristup ima i Strukturna sistemska analiza, a postoje i nestandardne metode. U daljem tekstu zelim da pokretaču teme prenesem( koliko to mogu i umijem) ono što sam ja do sada naučio i usvojio. Jedno od tih usvojenih znanja je i praćenje dinamike procesa kroz vrijeme koje ste u nekoliko tema prikazali pa ćemo pokušati i to da prikažemo. Jedna od komplikovanih stvari je ta što način obezbjeđivanja tog praćenja neće moći da se izmodelira kroz ERWin.
Imam trenutno obaveza pa ću pokušati večeras da krenemo dalje sa uočavanjem entiteta koji se javljaju u pojedinim procesima.
Tema koju ste pomenuli mislim da je http://www.elitesecurity.org/t...davanje-serijskih-brojeva-bazu

_{[Ovu poruku je menjao nenadmarkoni dana 04.03.2015. u 18:18 GMT+1]}

Idemo dalje. Kao sto sam rekao , primitivne procese(poslednje u hijerarhiji) iz Funkcionalnog modela potrebno je izdvojiti i za svaki identifikovati osnovne entitete koji se u njemu javljaju. Obzirom da se su sami procesi povezani, pojedini entiteti će se pojavljivati u više procesa. Pošto je ova aktivnost detaljno opisana u predloženoj knjizi,a to poglavlje nije preopširno prenijeću ga ovde za one koje mrzi da je pročitaju knjigu.
Za aktivnost "Identifikacija kandidata za entitete" polazi se od objekata posmatranja. Objekt posmatranja je sve što se može jednoznačno identifikovati, pa samim tim i izolovati iz okoline i opisati. Tako je objekt posmatranja i "entitet". Entitet je osoba, stvar, događaj, pojam (realni ili apstraktni) koji je od trajnog interesa tj. nešto što se želi pojedinačno posmatrati. Za potrebe definisanja ER dijagrama, na primer, mogu se posmatrati sledeći objekti, i to: -fizički objekti (vozilo, mašina,...),osobe, mesta (adrese, koordinate na karti,...), organizacije (preduzeća, zavod,...), grupe/klase/tipovi (tip proizvoda, klasa poslova,...), ugovori, potraživanja (narudžbe, fakture,...), prenos/ premeštaj (stvari, vozila, novca,...), pridruženje (zadatak - osoba, vozila, vožnja,...), pripadnost/članstvo (komponente - sastavi,...) i dr. Za navedene moguće entitete treba: odrediti prikladne radne nazive; napraviti grupe entiteta (ako ih je više od 15); po grupama, tražiti dodatne entitete (posmatrati najvažniji entitet); po potrebi, rearanžirati grupe. Kako se entiteti opisuju preko svojih osobina, tj. atributa, to se identifikacija atributa može izvesti i na sledeći način. Treba poći od postavke da svaki atribut u jednom trenutku vremena ima neku vrednost, zatim analizirati tu vrednost i na osnovu toga proširiti listu entiteta na sledeći način: Na osnovu prethodne analize strukture teksta, imenicu po analogiji smatrati entitetom .Na osnovu sličnosti ATRIBUTA koji mogu pripadati entitetu, uočava se značajna razlika (sličnost), što može da ukaže na to da je reč o različitim (istim) objektima. U toku identifikovanja entiteta, za svaki tip entiteta mora postojati jedan atribut (ili grupa atributa) koji jedinstveno identifikuje konkretni entitet u okviru tog tipa. Atribut koji identifikuje drugi tip entiteta je entitet. Entitet je i atribut koji je istovremeno i atribut drugog entiteta. Na osnovu pasivne i aktivne uloge veze mogu se definisati odgovarajući tipovi entiteta npr. : RUKOVODI- RUKOVODILAC, RUKOVOĐEN - ODELJENJE, NARUCUJE- KUPAC , NARUCEN - PROIZVOD .Na osnovu atributa na dokumentima takođe se mogu identifikovati entiteti : BOJA - BOJA CEGA?-PROIZVOD , STAROST- STAROST CEGA? - RADNIK, DATUM -DATUM CEGA? -NARUDZBE . Na osnovu interesa posmatranja, atribut može biti entitet, a može biti i atribut entiteta, što zavisi od interesovanja, odnosno od toga koji se deo realnog sveta i koji pogled na njega želi predstaviti. Npr., ako je osnovni objekt od interesa-kuća, onda je entitet-kuća, a atribut-ulica, a ako su od interesa-ulice onda su atributi-kuće npr.: Entitet "KUCA" -Atributi (ulica ,kucni broj ,godina izgradnje ,broj spratova, broj stanova) ;Entitet "ULICA" -Atributi (broj kuca levo ,broj kuca desno ,duzina kolovoza ,sirina kolovoza ).

Kako rečeno da primjenimo na našem modelu?

Krenućemo od prvog procesa sa Funkcionlnog modela: 1.1 Evidentiranje tehničkog sredstva. Pokretač teme je u prvom javljanju naveo:

Najprije je uočeno da navedeni entiteti imaju sličnosti u nazivima i atributima te da se mogu grupisati u jedan generalizovani entitet :"Tehnička sredstva", koji je u posmatranom procesu ujedno i dominantni entitet., dok na drugu stranu imaju i svoje osobenosti te se mogu posmatrati i kao posebni entiteti koji bi bili specijalizanti tog generalizovanog entiteta. Obzirom da je jedan od glavnih ciljeva projektovanja da se izbjegne redudantnost(ponavljanje podataka), primjenom pravila normalizacije , sve zajedničke atribute potrebno je smjestiti u generalizovani entitet , a one koji su osobeni za pojedine vrste ostaviti u posebnim entitetima. Šta bi se dešavalo kada bi sve smjestili u jedan entitet? Pojedina polja bi za pojedine vrste ostajala prazna npr: za Putnicko vozilo ostala bi prazna polja: nosivost, broj osovina..., za Teretno vozilo polja: broj sjedista...,prikolice: broj motora,broj sjedista...čime bi se bespotrebno gubio prostor na disku i opterećivao sistem.
Ovo pravilo se u praksi ponekad ignoriše. Obično se očekivani broj zapisa uzima kao mjerilo, pa bi za mali broj zapisa ovakav pristup više opterećivao sistem nego prazna polja.
Neki navedeni atributi takođe se mogu posmatrati kao entitet, npr: "...vrsta(teretno,putničko,putarsko...). Ove tri tačke ukazuju na to da ih može biti još, a može se posmatrati i kao atribut, gdje se to polje kroz svojstvo polja Validation rule, i Lookup field defniše da može da prikaže i prihvati samo definisane vrijednosti. Sve zavisi od pogleda i budućeg očekivanja da li će se ovi podaci proširivati novim i odlučuje se da li će se posmatrati kao atribut ili poseban entitet.
Neki od navedenih atributa kao što su: registarska oznaka, broj polise osiguranja, datum početka osiguranja... su promjenljivi kroz vrijeme te ne samo što ukazuju na poseban entitet, već ukazuju i na poseban proces- proces osiguranja i registracije.
Ovi entiteti će kao podređeni biti povezani sa dominantnim entitetom Tehničko sredstvo, odnosno u njima će postojati strani ključ iz ovog entiteta koji će ukazivati o kom sredstvu je riječ. Oni će biti opisani u posebnim procesima.
Atributi: Vrsta,Marka,Tip su takođe atributi koji mogu biti kandidati za entitete. Opet po pravilima normalizacije podatak koji se uzastopno u više zapisa ponavlja npr: prikolica,prikolica,prikolica...ukazuje na to da taj podatak treba smjestiti u zaseban entitet, a njegovu vrjednost prenijeti povezivanjem sa primarnim kljuem tog entiteta kao FK(Strani-uvezeni ključ drugog entiteta,tabele). Uz to može se posmatrati i povezanost ovih atributa npr. Jedan Proizvođač(Marka) može proizvoditi više Vrsta: Mercedes-Teretna vozila(Actros, Atos), putnička(C220, E190), pa i gradjevinske mašine što ukazuje da ako se posmatraju kao entiteti ne samo što definišu Tehničko serdstvo, već se i međusobno definišu.
Šta će od navedenog ostati kao atribut, a šta prerasti u entitet zavisi od interesa onoga ko posmatra sistem. Ja mogu da dam samo predlog a da li će to odgovarati Vama morate sami procjeniti na osnovu Vaših interesa. Takođe od detaljnih zahtjeva i predviđanja budućih potreba zavisi i da li će se dodati još neki pojam. Predlog u grafičkom obliku rađen u ERwin-u ako stignem večeras.

Da bi @mario.po shvatio o čemu pričam napravio sam tri modela za proces Evidentiranje tehnickog sredstva (u prilogu). Prvi model je slučaj generalizacije-specijalizacije gdje se zajednički atributi u generalizovanom entitetu, a oni koji su svojstveni za pojedine vrste u specijalizovanim entitetima. Takođe su radi prethodno izloženog povezani i entiteti Proizvođač(Marka), Vrsta(Tip) i Model. U specijalizovane entitete je prenešen i atribut VrstaTehničkogSredstva koji bi zbog Check konstante u njemu obezbjeđivalo da se u specijalizovanim entitetima mogu naći samo ona TehničkaSredstva koja pripadaju toj Vrsti.
U sledećem modelu je prikazana druga varijanta gdje su svi atributi svih VrstaTehnickogSredstva smješteni u jedan entitet.
U trećem je u pomoćnim tabelama prikazan tzv. sistem paralelnog označavanja koji u svojoj strukturi ima : IDBroj, Klasifikacioni broj, Standardizovan naziv i Sifru. Obzirom da se radi o malom broju zapisa preporučio bih drugu (treću)varijantu.
Ako može @mario.po da napravi popis atributa- ono što unosi iz servisne knjizice razvrstan po vrstama tehničkog sredstva da bi znali koje atribute da unesemo. Podaci o osiguranju i registraciji ne idu u to.

Kucao sam odgovor na desktop računaru i baš kada sam hteo da pošaljem restartuje mi se računar najverovatnije zbog pada napona... Poludeo sam... Ne mogu da verujem... Ajmo sad sve iz početka...

Prvo da se izvinim što nisam neko vreme bio aktivan, ali od silnih obaveza nisam mogao da stignem. Pročitao sam vaše postove i pozabavio se funkcionalnim modelom koji je postavio @nenadmarkoni. Mislim da su sva dokumenta obuhvaćena ali ako nešto primetim da nedostaje napisaću.



TERETNA VOZILA: Invetarni broj, Marka, Tip, Godina proizvodnje, Broj osovina, Nosivost, Masa, broj motora, broj šasije, snaga motora, zapremina motora, datum prve registracije, tip tahografa, vrsta motornog ulja, dimenzije pneumatika,

PUTARSKA VOZILA: Invetarni broj, Marka, Tip, Godina proizvodnje, Nosivost, Masa, broj motora, broj šasije, snaga motora, zapremina motora, datum prve registracije, tip tahografa(analogni, digitalni, bez tahografa), vrsta motornog ulja, dimenzije pneumatika,

PUTNIČKA VOZILA: Invetarni broj, Marka, Tip, Godina proizvodnje, broj motora, broj šasije, snaga motora, zapremina motora, datum prve registracije,, vrsta motornog ulja, dimenzije pneumatika

PRIKOLICE: Invetarni broj, Marka, Godina proizvodnje, Nosivost, serijski broj

GRAĐEVINSKE MAŠINE: Invetarni broj, Vrsta, Marka, Tip, Godina proizvodnje, broj motora, broj šasije, serijski broj, snaga motora, zapremina motora, težina, vrsta motornog ulja, dimenzije pneumatika,

Ne znam samo da li proces Evidentiranje tehničkog sredstva formirati ovako sa 4 entiteta ili ipak formirati sa tri entiteta ( Vozila, Mašine, Prikolice)? Na sledeći način:

VOZILA: Invetarni broj, Marka, Tip, Vrsta (Teretno, Putarsko, Putničko) Godina proizvodnje, Broj osovina, Nosivost, Masa, broj motora, broj šasije, snaga motora, zapremina motora, datum prve registracije, tip tahografa, vrsta motornog ulja, dimenzije pneumatika.

PRIKOLICE: Invetarni broj, Marka, Godina proizvodnje, Nosivost, serijski broj

GRAĐEVINSKE MAŠINE: Invetarni broj, Vrsta, Marka, Tip, Godina proizvodnje, broj motora, broj šasije, serijski broj, snaga motora, zapremina motora, težina, vrsta motornog ulja, dimenzije pneumatika

U ovom drugom slučaju javljalo bi se dosta praznih polja, kao na primer to da putničko vozilo nema tahograf, broj osovina...

Setio sam se još jedne stavke koju nisam spomenuo, a to je da nisu sva vozila u našem vlasništvu, već imamo neka vozila koja su na lizingu koji ističe određenog datuma, ili će se možda desiti da neko vozilo nabavimo na lizing.

Za koji proces je bitno sto je vozilo na lizing? Potrebno je odobrenje za registraciju posto se vodi na lizing kucu, je li tako? Sta jos? Sve cemo smjestiti u jednu tabelu-entitet pa cemo uslovima u tabeli ograniciti unose. Koji je broj vrsta gradjevinskih masina koje se mogu javiti u sistemu? Mislim da se i VrstaGradjevinskeMasine moze smatrati entitetom.

Upravo to, bitno je zbog registracije a i zbog datuma isteka na lizing jer se u tom slučaju prilikom registracije menja i saobraćajna dozvola.
Imamo sledeće vrste građevinskih mašina:Bager točkaš, bager guseničar, Buldozer, Finišer, Glodalica, Grejder, mašina za bankine, mašina za obeležavanje, mlin za kamen, utovarivač, rovokopač, kombinirka, mini bager, sejačica, mlin za kamen, traktor, Valjak. To su vrste mašina koje za sada koristimo.

Za proces 1.1 Evidentiranje tehnickog sredstva urađen je model u prilogu. Baza je eksportovana iz ERWina u Access zbog onih koji ne koriste ERWin i u njemu malo doradjena. U pojedinim poljima postavljena su ograničenja. Da li još neko ograničenje treba postaviti ili popraviti postavljena nek prosudi @mario.po. Znači treba da prođete kroz svako polje tabele i vidite da li tip polja koji sam postavio odgovara onome što se u njih unosi. Da li uneseno ograničenje odgovara stvarnom stanju i da li se za neko polje može dodati još neko ograničenje? Da li se kod u validaciji tabele slaže sa stvarnim stanjem? U validaciji tabele je postavljeno da se za izabranu VrstuTehnickogSredstva može ili ne unijeti odrađena polja. Kad smo već kod toga, da li za Prikolice trebaju podaci : Masa, NajvecaDozvoljenaMasa, DatumPrveRegistracije, DimenzijePneumatika i pretpostavljam da imaju BrojŠasije( Ako nemaju onda se BrojSasije ne može uzeti za primarni ključ tabele TehnickoSredstvo) . Ako nemaju u validaciji tabele treba i to dodati.
Pogledajte malo pa se čujemo u nedelju ili ponedeljak da nastavimo ili da ispravimo ako nešto nije dobro. Pokušajte da unesete probne vrednosti u tabele. Najprije se unose vrijednosti u pomoćne tabele(Šifarnike) pa tek onda u tabelu TehnickoSredstvo.

Za prikolicu bi trebalo da moze da se unese datum prve registracije, dimenzija pneumatika i broj šasije.
Međutim, stavio bi da primarni ključ bude invetarni broj jer svako sredstvo u firmi mora da ima invetarni broj ( od stolice do kamiona), kao i to da invetarni broj bude requried.

Kada popunjavam tabelu dobijam grešku. Slika greške u prilogu. Kreirao sam formu za unos podataka jer se tako bolje vidi šta sam u koje polje uneo. Primetio sam da se greška javlja kada unesem vrednost u polje Tezina i onda se prebacim na sledece polje, a kad pomenuto polje ostavim prazno onda se greska ne javlja. Isto se desava i sa poljem broj sedista, broj mesta za stajanje. Koliko vidim mislim da nisam nigde prekršio validation rules prilikom unosa podataka.

Upravo upozorenje koje Vam se javilo je upozorenje na ogranicenja koja smo unijeli. Za teretno vozilo se me moze unijeti tezina jer se moze unijeti samo za masine, broj sedista i broj mesta za stajanje je tipican podatak za putnicko vozilo,kombi,autobus( svi su u kategoriji putnicko). Ne znam koja su to putarska vozila i sta treba da bude ograniceno u toj kategoriji. Za teretno umjesto tezina mozete unijeti masu i najvecu dozvoljenu masu. Tako sam shvatio i tako uneo u ogtanicenje.

Pomenuto ogranicenje nalazi se u validation rule tabele. Mozete mu pristupiti tako sto cete otvoriti tabelu u design mod-u ,desni klik- properties, polje validation rule.

Sto se tice primarnoj kljuca. Prvo pravilo je da mora da jedinstveno identifikuje zapis, a drugo da je nepromjenjiv kroz vrijeme. Sta ako dodje novi direktor i zeli da se izvrsi novo inventarisanje sa novim inventarskim brojevima itd... Broj sasije u normalnim uslovima po zakonu ne bi smio da se izmjeni.

Nisam znao za ovo ogranicenje u validation rule tabele, zato sam se i zbunio kada sam dobio grešku. Super opcija. Taman kada se naprave forme za unos podataka, ta polja koja su na primer nepotrebna izbace se iz same forme i ne moze da dolazi do javljanja pomenute greske.
I ako se invetarni brojevi nisu menjali jos od trenutka kada su uvođeni, imate pravo, nikada se ne zna kome sta moze da padne na pamet pa odluci da promeni nacin evidentiranja sredstava, dok broj šasije nije sklon izmenama. Tako da, ostavljamo da primarni ključ bude broj šasije. :)

Što se tiče ostalih postavljenih ograničenja mislim da je sve OK. Mada, kada malo bolje razmislim, na saobraćajnoj dozvoli teretnog vozila ima podatak o nosivosti vozila, masi vozila i ukupnoj masi koja je jednaka zbiru nosivosti i mase.

Putarsko vozilo je vozilo koje se koristi za prevoz radnika koji na primer rade na sanaciji kolovoza. Po zakonu mora da poseduje tahograf, često ga svrstavaju u kategoriju polu-teretnog vozila ili čak i teretnog vozila. U njemu se najčešće mogu prevoziti 6-8 osoba + vozač. Evo slike jednog tipa putarca Slika

_{[Ovu poruku je menjao mario.po dana 08.03.2015. u 15:35 GMT+1]}

Zbir mase i nosivosti je najveca dozvoljena masa, a taj podatak imate. Sad kada ste shvatili ogranicenje mozete ga upotpuniti i izmjeniti prema stvarnim podacima. U prevodu zanci: kada je VrstaTehnickogSreddtva=Teretno vozilo ne smije se unijeti Tezina,BrojSedista,BrojMestaZaStajanje,... i tako za sve vrste.
Sto se tice buduce forme, za odabranu Vrstu moze se ograniciti polje koje se ne unosi da bude Enabled=False i tada mu se nece moci pristupiti. Otom potom...mozda forma nece uopste izgledati ovako :-)

Kad smo malo razjasnili ono što smo uradili, i ustanovili da je to otprilike to ( može se o tome još razmišljati npr. Dimenzije pneumatika mogu biti osnovne-preporučene i dodatne koji se takođe mogu postaviti zar ne? Kod nekih sportskih modela naprijed su jedni a nazad drugi pneumatici :-) itd.) ,da pređemo na sledeći proces " 2 Kontrola tehnicke ispravnosti". Njega smo razložili na dva podprocesa 2.1 Evidentiranje periodičnog pregleda i 2.2 Evidentiranje kontrole tehničke ispravnosti. Sve kontrole tehničke ispravnosti možemo podjeliti u nekoliko vrsta :
-Pregled prije upotrebe koji se evidentira na radnom nalogu pri upućivanju na radni zadatak
-Periodični pregled koji vrši Referent tehničke ispravnosti uz još par članova kao komisijom za bezbjednost saobraćaja i evidentira se na obrascu Zapisnika.
-Redovni tehnički pregled koji je propisan zakonom i preduslov je za registrovanje tehničkog sredstva i koji vrši specijalizovana ustanova a kao potvrdu tehničke ispravnosti izdaje neko Uvjerenje-potvrdu( trebali bi znati kako izgleda taj dokument ako je moguće)
-Vanredni tehnički pregled koji je proceduralno isti kao i redovni ali nije obavezan.
Naveli ste da periodični pregled vršite na svaka tri mjeseca, a vanredni tehnički pregled na svakih šest. Predpostavljam da se redovni tehnički pregled radi na svakih godinu dana.
Ono što nismo naveli je šta se dešava u slučaju da se umjesto ispravnosti ustanovi neispravnost? Opet pretpostavljam da se za manje tehničke probleme sredstvo upućuje u tehničku radionicu preduzeća a za veće kvarove u ovlašćeni servis ( naročito kada se radi o novom sredstvu koje je uz to i kasko osigurano i pod lizingom)
U tim slučajevima javlja se ona vremenska dimenzija - promjene kroz vrijeme koju je pomenuo @Zidar. Ukoliko je vozilo upućeno na otklanjanje neispravnosti ne može se uputiti na radni zadatak. Neke neispravnosti se rješavaju u hodu-brzo , dok je za neke potrebno značajno vrijeme. Zbog toga će morati da se prati raspoloživost sredstva kroz promjene stanja koje može doživjeti .
@mario.po sada se koncentrišite na ove procese i kako oni teku. Da li se javljaju još neki dokumenti ( Zahjev za vršenje tehničkog pregleda, zahtjev za servisiranje, zahtjev radionici za popravku-otklanjanje sitnih neispravnosti, zamjenu pneumatika...) i ako se javljaju skenirajte ih i priložite. Da li se zapisnik o periodičnom pregledu zavodi na neki način i kako se čuva?
Kako se čuva potvrda-uvjerenje o vanrednom, redovnom tehničkom pregledu i ako može skenirajte primjerak.

Što se tiče procesa Kontrola tehničke ispravnosti vozila meni su najpotrebnije sledeće stvari:
- informacija o tome kada je poslednji put vršen periodični tehnički pregled tehničke ispravnosti vozila (koji se radi na svaka 3 meseca) i kada bi trebalo da se vrše naredni
- da mogu da štampam pomenuti zapisnik za vozila
- informacija o tome kada je poslednji put vršen 6-mesečni tehnički i kada bi trebalo da se vrši naredni (i da mogu da štampam izveštaj o tome koje vozila u kom mesecu treba da vrše vanredni tehnički pregled). Ovaj vanredni tehnički pregled nismo u obavezi da radimo, ali mi ga radimo kao da nam je obavezan.

Redovan tehnički pregled se vrši onda kada se vozilo i registruje (na svakih godinu dana), odnosno nekoliko dana pre nego što bi trebalo vozilo registrovati. Potvrdu o tehničkoj ispravnosti (kada vozilo prodje tehnički pregled) kolega zajedno sa svim ostalim dokumentima odnosi u policiju prilikom registracije vozila i isti se kod nas ne zadržava pa ne mogu da ga skeniram.

Pošto imamo sopstvenu radionicu, sve kvarove koje možemo otkoniti otklanjamo u našoj radionici, a sve kvarove za koje nismo u mogućnosti da otklonimo, šef radionice upućuje vozilo u neki od servisa sa kojima sarađujemo, tako da sa tim ja nemam dodirnih tačaka. Kada se vozilo popravi, dobijam usmeno obaveštenje da je vozilo ponovo na raspolaganju (pokušavao sam da ih naučim da tu informaciju dobijam e-mail-om jer onda imam pisani trag ali nažalost to nikako ne uspevam).

Zapisnik o periodičnom pregledu arhiviramo u registratorima, odnosno za na primer mesec januar sva vozila su u jednoj fascikli koja je u registratoru, i tako za svaki naredni periodični pregled. Popvrda o izvršenom vanrednom tehničkom pregledu čuva se u dosijeu vozila ( primer potvrde u prilogu).

Čini mi se da je obrazac zapisnika standardni obrazac. Pitanje je svrhe štampanja tog zapisnika jer je dokument koji, čini mi se ,ovjeravaju potpisima tri člana komisije. Možda je svrsishodnije čuvanje skenirane slike tog zapisnika a da se u bazi čuva podatak koji je rezultat pregleda te ako je utvrđena neispravnost unijeti opis te neispravnosti a dokument koji se može štampati može biti propratni dokument sa opisom kvara prema radionici.
Pitanje je koliko Vam je bitno evidentirati ko su ta tri člana koji su vršili periodični pregled? Ako Vam je to bitno može se evidentirati. Ko su u suštini pored Referenta ostala dva člana?


Koliko sam ja pročitao MUP dozvoljava da potvrda o tehničkoj ispravnosti pri registraciji može biti stara do 30 dana, ali dobro....


Koliko razumijem Vi ste odgovorni za vozilo dok ono ne ode u radionicu, pa ste opet za njega odgovorni kada se vrati, ali ne znate šta se sa njim u međuvremenu dešava ni gdje je? Upisuje li se šta u servisnu knjižicu, dobija li se kakav račun ili potvrda šta je rađeno? Čuva li se to u dokumentaciji-dosijeu vozila.Da li opet neko pregleda sredstvo kada se vrati sa popravke.


Ovde mi je opet nelogičnost. Koliko shvatam odradite periodični pregled za sva tehnička sredstva u januaru, pa u aprilu, pa julu... i to se čuva odvojeno od ostalih dokumenata iz dosijea vozila?
Za vanredne i redovne tehničke preglede čini mi se da je i podatak "Ko je vršio taj pregled" bitan. Znači da bi trebali da čuvamo i podatak o spoljnim saradnicima?

Kako otprilike za sad treba da izgleda ovaj proces u prilogu. Dodaćemo ono što još budemo saznali. Ovde nema Lookup pogleda jer svakako dizajniramo BE baze, padajuće liste ćemo dodati na FE, a bio sam ih postavio da bi @mario.po bilo jasnije o čemu se radi.

Jeste standardan, nego taj zapisnik ja imam u Word-u (tako nasledio od kolege) i na svakih 3 meseca štampam za sva vozila, pa sam mislio da može da se odradi da isti štampam iz Access-a, ali kad malo bolje razmislim i suštini i nema potrebe da gubimo vreme na to.

U pravu ste, ovako je najbolje.

Nije mi bitno evidentiranje članova komisije. Nisu uvek isti članovi. Pored referenta od članova obično budem ja i šef radionice ili rukovodilac mehanizacije.

Upravo tako. Kada nam se desi da na primer na 15 vozila ističe registracija istog dana, onda tehnički pregled počnemo da radimo i po nedelju dana pre isteka registracije.

Ja raspolažem vozilom dok je ispravno, odnosno upućujem ga na rad i njime koordiniram, kada se pokvari i vozilo uđe u radionicu, za njega odgovara šef radionice, u slučaju da kvar ne može da otkloni radionica šef radioncie me obaveštava da vozilo mora u drugi servis i ako je moguće voziti vozilo do servisa ja dodeljujem vozača koji će to da uradi, kada se popravi, šef radionice me obaveštava o tome i opet mi je na raspolaganju. Tako da ja u svakom trenutku znam gde je vozilo i šta se sa njim dešava.

Upravo tako. Čuva se odvojeno od ostalih dokumenata iz dosijea vozila jer nam tako traži policijski inspektor koji dolazi u kontrolu. Da, trebali bi da čuvamo podatke o spoljnim saradnicima.

Štampaće se obrazac iz aplikacije, ali će on i dalje biti u Word-u. Ne samo njega već i ostale obrasce možete pokrenuti,otvoriti i odštampati komandom iz aplikacije. Ostale članove komisije možemo čuvati kao i spoljne saradnike i evidentirati ko je učestvovao u periodičnom pregledu. Ono što me sad zanima je kad se štampa ovlašćenje za registraciju (prije nego krene na tehnički ili kad prodje tehnički)i kako to ide kada je sredstvo pod lizingom? Ako mogu primjeri dokumenata.

Štampaće se prazan obrazac iz aplikacije, ali će on i dalje biti u Word-u. Ne samo njega već i ostale obrasce možete pokrenuti,otvoriti i odštampati komandom iz aplikacije. Ostale članove komisije možemo čuvati kao i spoljne saradnike i evidentirati ko je učestvovao u periodičnom pregledu. Ono što me sad zanima je kad se štampa ovlašćenje za registraciju (prije nego krene na tehnički ili kad prodje tehnički)i kako to ide kada je sredstvo pod lizingom? Ako mogu primjeri dokumenata.

Imamo još jednu logičku grešku u opisu. Rekli smo da se Redovni tehnički pregled radi na godinu dana, vanredni na šest mjeseci a periodični na tri. Ovo bi značilo poklapanje tih pregleda. Prije će biti da: Redovni se rade na godinu dana, to je ok. Međutim vanredni se radi na polovini tog perioda između dva redovna pregleda a periodični na polovini između redovnog i vanrednog. Griješim li?
To otprilike znači da se za godinu dana izvrši jedan redovni, jedan vanredni i dva periodična.

Proces registracije kada je vozilo kupljen na lizing je sledeci:
- izvrši se tehnički pregled
- na tehničkom se dobija potvrda ispravnosti vozila ( isto kao i za vozila koja nisu na lizing)
- potvrda o tehničkoj ispravnosti vozila dostavlja se lizing kući koja na isti treba da stavi pečat
- obzbeđuje se polisa osiguranja i dokaz o uplaćenoj polisi se dostavlja lizing kući
- ovlašćenje lizing kuće da korisnik može u ime lizing kuće da registruje vozilo
- Kada se sve to završi sledi odlazak u policiju gde se nosi potvrda o tehničkoj ispravnosti vozila, kopija polise osiguranja, potvrda iz banke o uplaćenim taksama, saobraćajna dozvola, ovlašćenje lizing kuće.

Mislim da ovo nisam spomenuo... Registraciju vozila vrši referent tehničke ispravnosti, i prilikom registracije vozila (i onih koja su na lizing i onih koja nisu) izdaje mu se, na memorandumu, ovlašćenje da u ime firme može da registruje vozilo u kome se navodi proizvođač i marka vozila kao i broj motora i šasije.

Periodični tehnički pregled je u prevodu vizuelni ili preventivni tehnički pregled vozila (vidi se šta se sve kontroliše u zapisniku koji sam već priložio), i prema zakonu smo dužni da isti obavljamo na svaka tri meseca. U slučaju da se desi da baš tog dana kada vozilo ide na tehnički pregled u ovlašćenu kuću (na vanredni ili redovni) treba uraditi i periodični pregled, onda, kada vozilo završi tehnički pregled, u zapisniku za periodični pregled evidentira da je sve u redu. Ovom pregledu se ne predaje neki veliki značaj, jer to je samo vizelni pregled za koji smo u obavezi da imamo zapisnik (nadam se da me razumete).

Ok. Sad znamo kako funkcionišu periodični pregledi. Ovlašćenje za registraciju ćemo štampati iz forme tehničkog sredstva ( ne znam gdje bi ga drugo smjestili). Trebaće nam memorandum firme u word formatu i primjer kako izgleda ovlašćenje. Za tehnički pregled nam znači nije bitno što je vozilo na lizing, to nam je jedino bitno kao informacija u bazi zbog registracije. Ići ćemo proces po proces uz kontrolu onoga što smo uradili. Pokušaću da kombinujem @Zidar-eve i @Zoran.Eremija principe ( Iako su dva potpuno različita načina rada), odnosno ono najbolje što sam od njih naučio pa ćemo vidjeti da li će to ići. Zbog informacija koje su nam potrebne o partnerima ubacio sam još jedan proces u funkcionalni model "Evidentiranje poslovnog partnera" gdje ćemo evidentirati sva pravna i fizička lica a inforamcije o fizičkim licima će se posle koristiti i u Evidentiranju zaposlenih... Ove informacije će nam trebati pri modelovanju procesa Evidentiranja tehničkog pregleda pa ćemo se prebaciti i uraditi prvo njega.

Evo malo pogledajte model u prilogu i access fajl. Nisam znao koje Vam inforamacije trebaju za PravnoLice pa sam stavio samo NazivPravnogLica. Sjutra ćemo ako stignem da napravimo FE baze , prelinkujemo tabele, napravimo nekoliko upita i probamo da napravimo forme za unos Partnera da bi vidjeli da li to radi kako treba prije nego krenemo dalje. Do tada pogledajte da li Vam treba još neka informacija za pravna i fizička lica da bi i to ubacili, a iskusniji ako mogu neka pregledaju ima li kakvih nelogičnosti u tabelama ili grešaka. ;-)

@mario.po evo malo se zabavljajte, pogledajte kako je šta urađeno probajte da unosite podatke, pogledajte kod i forme u DesignView, probajte da shvatite zašto se šta dešava. Pokušajte i da unesete neke nelogične podatke... na formi TehnickoSredstvo onemogućena su polja za određene vrste tehničkog sredstva prema onome što smo stavili u ograničenju pa vidite da li je to dobro. Unos tehničkog sredstva je preko fome TehnickoSredstvoLista a Partnera preko PartnerLista. Iz njih se otvaraju ostale forme. Šifarnicima se pristupa duplim klikom na padajuću listu. Neće me biti na forumu do ponedeljka...
Prije svega potrebno je da prelinkujete tabele tamo gdje ste raspakovali BE fajl, to se radi preko Linked Table Manager-a , čekirati sve tabele i obavezno čekirajte polje Always prompt for new location, pa pronađite mjesto gdje ste raspakovali BE.

Primer ovlašćenja u prilogu.


Baš mi se sviđa kako izgleda baza za sada :) Moraću baš lepo sve da pogledam kako je urađeno jer ima dosta stvari za koje nisam znao da tako mogu da se urade. Naučiću baš dosta od vas, i mogu vam reći da se mnogo više nauči ovako na priremu sa nekim ko to zna da radi nego na raznim tutorijalima i priručnicima.
Imam nekoliko pitanja, ako vam nije problem da mi malo pojasnite.
- Zašto ste stavili da prilikom unosa pravnog i fizičkog lica partner ID bude broj od 12 cifara? Kako ste uradili to da automatski za svaki nov unos partenra na taj definisan broj dodaje prvi sledeći?
- Da li može samo malo pojašnjenje oko toga kako funkcioniše ovo oko dodavanja pravnog i fizičkog lica? Da li se kao fizičko lice unosi radnik firme odnosno na primer vozač ili...?
Pravno lice bi trebalo da bude firma sa kojom na primer saradjujemo (bilo da se radi o kupovini vozila, vršenju tehničkog itd)? Ako sam u pravu, onda bi za pravno lice trebalo još uneti broj računa, matični broj i PIB.

Kada hoću da unesem karakteristike tehničkog sredstva izbacuje mi grešku This recordset is not updateable.

Evo probajte sad. Bio sam greškom postavio Recordset Type na Snapshot i Record Lock na All record. Sada je postavljeno na Dynaset i No lock.
Ključ koji sam postavio je govoreći ključ, upotrebljava se kada ne postoji dobar kandidat za PK. Način rada ovog ključa je svojevremeno odlično objasnio @Zoran.Eremija pa dok pronađem u kojoj temi je to objašnjavao.Ako ne pronađem objasniću. Radim sa Office 2003 pa ako može konverzija u .doc fajl.

Konvertovao sam ovlašćenje u .doc fajl.

Nije moralo da bude 12 cifara, moglo je i 10 pa i manje. Prvih 4 cifre predstavlja najveću tj. tekuću godinu koja je definisana u polju godina gdje je kao defaut vrijednost postavljeno da čita najveću godinu iz tabele Godina. Sledeće 3 cifre predstavljaju ono što je određeno diskriminatorom( u ovom slučaju to je VrstaPartneraID), obzirom da je ovde definisano da se mogu javiti samo 2 pojavna oblika mogli smo staviti da bude jedna umjesto 3 cifre. Ovako kako je postavljeno može se definisati 999 vrsta da ih nismo ograničili. Sledećih 5 cifara je redni brojač koji je definisan da daje sledeći broj sve dok su Godina i VrstaPartneraID isti. Kada se promjeni neki od ova dva parametra on počinje od početka. I ovde je moglo biti manje cifara jer nećete godišnje unositi ovde omogućenih 99999 zapisa. U polju Broj koje je skriveno, i vidi se kao i polja Godina, VrstaPartneraID i polje ID, samo kada smo u Design prikazu, definisano je da kombinuje ove podatke u jednu cjelinu koja se programski u pozadini dodaje u polje PartnerID kada dodajemo novi zapis.

Ovde mogu da se unesu sva pravna i fizička lica bez obzira da li su radnici, saradnici ili šta već. Da li će neki saradnik sjutra biti radnik i obratno ne znamo. Kada se desi da promjeni ulogu regulisaćemo kroz druge forme i upite. O tom potom. Dodaćemo polja koja ste naveli.

Evo na brzinu i proces evidentiranje zaposlenog. Za sada sam postavio jedino atribut BrojRadneKnjizice jer ne znam šta bi sve trebalo da budu osnovni podaci o radniku. Odnos relacija između tabela FizickoLice i Radnik je 1:0;1 . Još ćemo doraditi.

Da predjemo dalje na proces 3.2 Vodjenje dokumentacije zaposlenog. Osnovni uslov da bi zaposleni bio to što je, je Ugovor o radu. Ovaj ugovor moze biti: na neodredjeno i na odredjeno što znači da se može obnavljati. Ugovor bi trebao da se vodi pod nekim brojem.Ono sto Vi nazivate privremeno-povremeni poslovi mislim da se ne razlikuju od ostalih. Razlika je sto je u jednom trenutku obim poslova pojacan pa se pored Zaposlenih na neodređeno zapošljavaju radnici koji su na određeno. Da li je ovim ugovorom regulisano i raspoređivanje na određeno radno mjesto ili se pored njega pravi i Rješenje o raspoređivanju? Datum ugovora ne mora da se poklapa sa datumom postavljenja. Rekli ste da od zaposlenih imate Rukovaoce GM, Vozače i Referente.Dodaćemo ovde i Vaše radno mjesto jer će nam trebati na dokumentima. Radno mjesto bi trebalo da je definisano i uslovlkeno uslovima za to radno mjesto: školska sprema, određena kategorija vozačke, sertifikat-licenca za rukovaoca...šta još? Od dokumtacije vodite još podatke o :
vozačkim dozvolama
Na vozačkoj su definisane kategorije za koje je vozač sposoban-osposoblken. Vozač može da stiče i gubi kategorije. Vozačka ima rok važenja, vodi se pod nekim brojem, zamjenjuje se drugom sa drugim brojem.
Ljekarsko uvjerenje
Za vozače ovo uvjerenje traje 3 godine ili kraće.
Za rukovaoce 1 godinu ili kraće.
Licenca ili kako se već zove za rukovaoce. O ovome treba dodatno objasnjenje
Uslov za obavljanje posla na definisanom radnom mjestu je posjedovanje važećih navedenih dokumenata. Kada zaposleni ostane bez nekog od ovih dokumenata šalje se na odmor (Da li štampate rješenje o odsustvu?), ili se raspoređuje na drugo radno mjesto ( Da li u okviru Vašeg sektora ili prelazi u druge sektore? Da li se štampa rješenje o preraspoređivanju?)
Zaposleni može biti u zavisnosti od važenja ovih dokumenata raspoloživ ili ne za obavljanje određenih poslova. Da li se dešava. da naprimjer zaposlenom istekne ugovor na određeno, on nastavi da radi a novi ugovor se naknadno štampa. Što se tiče ostalih dokumenata nadam se da ne rizikujete tolilo?

Svaki ugovor ima svoj broj i datum.

U suštini, ugovor o privremeno-povremenim poslovima (PPP) je ugovor na određeno.

Ovim ugovorom se definiše i raspoređivanje na radno mesto. Na primer sklapa se ugovor o PPP za rukovaoca građevinskih mašina i posao tog radnika će znači biti rad sa građevinskim mašinama.

Traži se određen stepen stručne spreme, vozačka dozvola određene kategorije, diploma ili sertifikat za rukovaoca, i na primer može se desiti neka specijalna dozvola, kao na primer, ADR (koji već poseduju neki vozači) koji je potreban kako bi vozač mogao da upravlja cisternom koja prevozi opasan materijal, u našem slučaju naftu.

Upravo tako. Što se tiče podataka sa vozačke bitno mi je za koje kategorije je ista izdata (da, kao što ste rekli mogu da se dodaju ili oduzmu kategorije), broj vozačke, datum važenja, koja policijksa uprava je istu izdala.

Za vozače lekarsko traje maks 3 godine a dešava se da se izda i na kraći period. Za rukovaoce se izdaje na godinu dana i bar do sada nisam imao slučaj da je isto izdato na kraći rok, što ne znači da nije moguće.

Da bi radnik obavljao poslove rukovaoca mora da poseduje diplomu, sertifikat ili kurs za istog.

Kada na primer, vozač ostane bez dozvole za upravljanje kamionom, šalje se na odmor ili na korišćenje prekovremenih sati, a u slučaju da je iskoristio odmor i da nema prekovremene sate, preraspodeljuje se na drugo radno mesto, pa čak i van sektora transporta. Kada se dešava ta preraspodela, onda se šalje zahtev da se zaposleni na određeni period preraspodeli na druge poslove, nakon čega zaposleni dobija rešenje o preraspodeli na određeni period. Nakon isteka tog perioda zaposleni se vraća na svoje radno mesto.

To se ne dešava, odnosno ne bi smelo da se dešava i o tome se baš vodi računa. O svim dokumentima koji imaju neki rok važenja striktno se vodi briga i ne ulazimo u nikakav rizik tog tipa.
Iskoristio bi i da napomenem, da na svakih 3-4 meseca šaljemo zahtev policijksim upravama (svakoj policijskoj upravi posebno) za proveru izrečenih mera zabrane upravljanja motornim vozilom, kako ne bi došli u situaciju da vozač upravlja vozilom a da mu je izrećena mera zabrane.

Ovo do sad što smo uradili može se reći da su bili statični podaci. Od ovog procesa kreće dimamika, podaci su promjenljivi. Do sada ste vjerovatno pohvatali osnovne pojmove i svrhu prethodno rečenog pa ćete od sada malo aktivnije uzeti učešća u daljem radu. Javiću Vam se privatnom porukom za dogovor o daljem radu.
Ono što je odrađeno u FE je bio samo primjer jer se radi o procesima kojim se unose podaci o dva osnovna učesnika u cijeloj aplikaciji: tehničkim sredstvima i licima(pravnim i fizičkim), da bi shvatili odnos između FE i BE baze.Dalje ćemo nastaviti samo sa projektovanjem BE baze dok ne zaokružimo sve procese.

_{[Ovu poruku je menjao nenadmarkoni dana 19.03.2015. u 09:23 GMT+1]}

Jesam. Jasnije su mi mnogo stvari. U poslednje vreme sam non-stop na poslu pa nemam toliko vremena da se još više posvetim učenju baza ali dobro, koristim svaki slobodan trenutak da to savladam.

Važi.

Kao što sam rekao ovaj proces će biti malo komplikovaniji. Mogući istek važenja dokumenta uslovljava raspoloživost za angažovanje zaposlenog. Da li sertifikat za rukovaoca ima neke svoje specijalnosti, nešto kao što su kategorije kod vozačke dozvole. Sigurno se ne obučava svaki rukovaoc za svaku mašinu. Da li su pomenute specijalne dozvole vezane za vozačku dozvolu? Na primjer vozač ne može imati ADR dozvolu ako već nema dozvolu E ili C kategorije.
U prilogu logički model ovog procesa za ono što do sada znamo.
@mario.po već sam Vam poslao privatne poruke sa instrukcijama, obavještenje o njima imate u vrhu ove stranice ispod prostora za logovanje.
ps. Napravio sam logičku grešku u prethodno zakačenim fajlovima, izvinjavam se i evo novih fajlova

_{[Ovu poruku je menjao nenadmarkoni dana 21.03.2015. u 11:28 GMT+1]}

Nema, bitno je da zaposleni poseduje sertifikat za rukovaoca a onda se tokom rada obucava za odredjenu masini ili je vec dosao za rad sa masinom sa kojom ima iskustva.

I sustini jesu. Sve masine i vozila ucestuju manje ili vise u saobracaju, tako da je bitno da onaj ko njima upravlja poseduje makar B kategoriju. Za onog ko poseduje ADR bitno je da poseduje i C kategoriju jer kamionom cisternom non-stop ucestvuje u saobracaju.

Moraću da konsultujem @Zidar-a.
Htio sam u ovom procesu da primjenim Vaše praćenje promjene stanja, međutim u ovom slučaju nemamo klasično praćenje promjene stanja. U suštini postavljaču teme je bitno da, u procesima vezanim za angažovanje radnika i sredstava, zna da li je radnik raspoloživ ili ne za angažovanje. Neraspoloživost zbog isteka dokumenta se koliko shvatam skoro nikada ne dešava jer se prati rok važenja dokumenta i prije tog isteka se reaguje. Da kažemo, što se ovog procesa tiče, "najčešći " slučaj je privremena zabrana upravljanja određenom kategorijom, ili eventualno gubljenje dokumenta. Mnogo veći uticaj na raspoloživost će imati odsustvo radnika iz raznih razloga koje ćemo obraditi u procesu "Vođenje evidencije odsustva". Zanima me Vaše mišljenje da li, obzirom da su 2 pojavna oblika ( raspoloživ i neraspoloživ) primjeniti Vaš način praćenja promjena?
Što se tiče dokumenata, u specijalizantima sam izdvojio dokumente koji se po opisu postavljača teme trebaju pratiti, ali sam ostavio prostor da se dodaju i drugi dokumenti ako se kasnije javi potreba za njihovim evidentiranjem. U VrstiDokumenta definisaću da prvih 5 VrstaDokumentaID budu rezervisani za specijalizante i to ograničiti u Validation Rule tabele. U tabeli Dokument takođe se dešavaju promjene. Dokument kojem je istekao rok važenja ili je izgubljen zamjenjuje se novim. Taj novi dokument mora nositi veći datum izdavanja od prethodnog. Da li i ovde treba dodati RBr i StariRBr da bi obezbjedili ovaj uslov?
Imamo i zavisnosti u specijalizantima. Za radna mjesta Vozač i Rukovaoc uslov je posjedovanje vozačke minimum B kategorije. Vozač kamiona mora imati C kategoriju a vozač kamiona sa prikolicom i šlepera E. Ne znam da li imaju autobus ,za njega je potrebna D kategorija. Vozač cisterne sa opasnim materijama mora imati minimum C kategoriju , a ukoliko se radi o cisternama sa poluprikolicom E kategoriju i uz to ADR dozvolu koja ima, koliko sam pročitao, određene klase (nešto slično kao kategorije kod vozačke). Je li u Srbiji nešto izmjenjeno kategorisanje na vozačkoj dozvoli ( C,C1, E, E1....)? Možemo li ovo obezbjediti u tabelama? Ako postavim da se u ADR dozvoli bilježi podatak o vozačkoj dozvoli za koju je vezana, šta kada istekne njen rok i zamjeni se novom? Tad bi morao da se ovaj podatak zamjeni novim i to možemo izvesti UpdateQuery-jem. Šta ako vozač dobije zabranu upravljanja za tu kategoriju? Tad je i ADR dozvola bez efekta. Ljekarsko uvjerenje se izdaje u zavisnosti od radnog mjesta. Vozačima na maksimum 3 godine, rukovaocima na maksimum 1 godinu. To znači da se u ovim tabelama validnost mora usloviti RadnimMesto-m, odnosno Ugovorom. Model koji prati ovo razmišljanje na logičkom nivou u prilogu.

Mogu li da se javim sutra ili prekosutra, danas zaista ne mogu da stignem. Zbog zauzetosti nisam pratio detaljno temu, trebace mi malo da se upoznem. Otvorio sam PDF u poslednjoj poruci i ne zigleda lose.

Naravno. Nigdje ne zurimo. Hvala na javljanju.

Imamo i autobus, ali se on skoro i ne koristi.

Nemamo cisternu sa poluprkolicom, tako da nije obavezeno da vozac cisterne poseduje i E kategoriju. U nasem slucaju vozac poseduje ADR za prevoz opasni odnosno zapaljivih i eksplozivnih materija.[/quote]

Odavno je bilo, napravio sam varijantu resenja pre mesec dana, ali nikako da postavim na forum.

U primeru se vidi kakao se prati vazenje vozackih dozvola i registracije vozila. Pracenje vozila, gde je, ko ga duzi, je u tabeli PracenjeVozila. Uz standardne promene stanja imamo i nesto sto dosad nismo imali: uslove da ako je vozilo 'Na Putu' onda u tom momentu mora da vazi vozacka dozvola vozaca ali i da je vozilo registrovano. Za ostale situacije, vozac, broj dozvole, datumi registracije i vazenja dozvole nisu obavezni, ali ni zabranjeni.

Ovo je validation rule na nivou tabele "PracenjeVozila":


Verujem da ce Nenad ovo moci da razume i raspetlj, te da pokusa neki interfejs da napravi. Korisnik ne bi trebao da vidi ni jedno od onih polja koje citaju vrednosti iz prethodnog reda. To smo ptravili ranije, u nekoj slicnoj temi.

Za neupuceno oko, tabela PracenjeVozila izgleda totalno nenormalizovano, sa mnogo podataka koji se prenose iz drugih tabela, naoko bespotrebno. To se samo tako cini, jer je sve kontrolisano upotrebom FOREIGN KEY, to jest Access Relationships. Tabele su prvo dovedene u Boyce-Codd NF (3+) pa smo onda dodavali kolone iz drugih tabela da bi uspostavili dodatna ogranicenja. Ako kazemo "Vozac ne sme da podje na put ako mu tada ne vazi dozvola" onda je jasno da tabele PracenjeVozila mora dnekako da "vidi" da li vazi vozacka dozvola. Da bi to postigli, relationship ne povezuje samo kolone Vozac, nego i kolone VaziOd i VaziDo iz tabele VazenjeVozackeDozvole. U VazenjeVozackeDozvole nismo stavili za koji tip vozila dozvola vazi

Za sada toliko, pa kad stignem da se javim sledeci put.

:-)

Odavno je bilo, pa sam i ja ispao iz teme, morao bih i ja da se podsjetim sta smo htjeli, hehehe. Zahvaljujem @Zidaru na javljanju. Ne znam koliko je još i @mario.po zainteresovan za produženje teme, čini mi se da je odustao, a i ja sam malo u drugim obavezama pa ako se stigne( naravno ako je mario još zainteresovan).

Hvala @Zidaru na javljanju.



Zainteresovan sam i dalje... U poslednje vreme samo neke obaveze i gužva na poslu, pa nikako da stignem da ponovo pokrenem temu.