[ Carduel @ 16.01.2018. 18:40 ] @
Pozdrav svima,

zamolio bi iskusne znalce za pomoć oko rješavanje dizajna baze za praćenje kupovine stolova u glavnim školama i podružnih školama.

Razmišljao sam da bi za to trebao 3 tablice (gl. škole, podružne škole i inventar).

Glavne škole imaju svoj unikatni ID broj i ostale generalije (naziv, adresa, mjesto, ...) a i isto tako i podružne škole imaju svoj unikatni ID broj i ostale generalije. Na kraju i svaki stol (inventar) ima svoj unikatni broj.

U toku godine glavne škole kupe određeni broj stolova a isto tako i podružne škole.

Htio bi povezati tablice tako da mogu dobiti neke izvještaje tipa koliko neka glavna škola kupi stolova pojedinačno, koliko 1, 2, 3, ... podružna škola kupi stolova pojedinačno, koliko neka glavna škola sa nekom svojom podružom školom kupi zajedno, itd... Ako bi glavna škola kupila 10 stolova a jedna podružna škola 5 da na izvještaju mogu dobiti spisak tih stolova po inventarnom broju.

Npr.

Glavna škola
1. stol broj A001
2. stol broj A002
3. stol broj A005
...
1o. stol broj A15

Područna škola
1. stol broj A003
2. stol broj A004
3. stol broj A006

Svaki stol ima svoj unikatni broj ne može biti A001 u glavnoj školi i u podružnoj. Ili u glavnoj ili u nekoj od podružnih škola.

Razmišljao sam ovako:

tablica gl. škole
gl_skola_id (123, 234, 345, ...)
naziv (prva gimnazija, druga gimnazija, treća gimnazija, ...)
adresa

tablica područne škole
ps_id
naziv
adresa
gl_skola_id

tablica inventar
inventar_id ili inventarni broj
naziv
gl_skola_id
ps_id

Da li bi na ovaj način mogao dobiti ovo što mi treba ili mora biti reorganizacija stavki iz tablica.

Pitao sam i neke kolege pa su mi rekli da bi oni sveli sve škole u jednu tablicu pa bi stavili da li se radi o gl. školama ili podružnoj gdje bi taj odabir izdvojili u treću tablicu. Ovo me totalno zbunjuje pa bi bio zahvalan ako bi netko mogao pomoći.

Srdačan pozdrav







[Ovu poruku je menjao Carduel dana 16.01.2018. u 22:26 GMT+1]

[Ovu poruku je menjao Carduel dana 16.01.2018. u 22:40 GMT+1]
[ Getsbi @ 16.01.2018. 22:26 ] @
Da li u okviru jedne glavne škole postoji više podružnih škola?
Ako je odgovor „Da” onda bi model mogao da izgleda ovako.
[ Carduel @ 16.01.2018. 23:03 ] @
Upravo tako Getsbi, unutar glavne škole postoji više područnih škola.

Ovdje se pojavljuje više glavnih škola od kojih svaka ima svoje područne škole.

Npr. škola 1 ima 3 područne škole, škola 2 ima 5 područnih škola, škola 3 ima 2 područne škole, itd...

U toku godine škola 1 i njene 3 područne škole kupuju stolove koji imaju unikatni inventarski broj i taj se broj samo jedanput pojavljuje i ne može biti u dvije glavne škole niti dvije područne škole. Znači samo jedna ustanova ga može imati.

Ako ga je kupila škola 1 taj stol pripada samo njoj i ne može biti niti u bilo kojoj podružnici te škole niti u drugim glavnim školama niti njihovim podružnicama.

Htio bi napraviti report koji bi mi dao izvještaj koliko je koja glavna škola kupila inventara u trenutku kad pregledavam ili izvještaj koji bi mi ispisao koliko je pojedina područna škola kupila inventara ili skupni izvještaj glavna škola plus njene podružne škole.

Primjer skupnog izvještaja za školu 1

Škola 1

1. stol 123 - datum kupovine - cijena
2. stol 124 - datum kupovine - cijena
3. stol 125 - datum kupovine - cijena
4. stol 126 - datum kupovine - cijena

podružnica 1
1. stol 127 - datum kupovine - cijena
2. stol 128 - datum kupovine - cijena

podružnica 2
1. stol 129 - datum kupovine - cijena
2. stol 130 - datum kupovine - cijena

podružnica 3
1. stol 153 - datum kupovine - cijena
2. stol 243 - datum kupovine - cijena

Ukupno: ukupna cijena

Primjer pojedinačnog izvještaja (bilo glavne škole ili podružnice)

Škola 3

1. stol 546 - datum kupovine - cijena
2. stol 548 - datum kupovine - cijena
3. stol 598 - datum kupovine - cijena
4. stol 601 - datum kupovine - cijena

ili

Područna škola 1 (koja pripada glavnoj školi 3)

1. stol 333 - datum kupovine - cijena
2. stol 361 - datum kupovine - cijena
3. stol 346 - datum kupovine - cijena
4. stol 278 - datum kupovine - cijena

To bi tako izgledalo u praksi :) ali u bazi ne znam :).

Da li ovaj tvoj model može dati mogućnost da dobijem ovakve izvještaje? Ne zamjeri mi pošto ne vidim u dubinu problema. :)

I hvala ti puno na brzom odgovoru.

lp









[ Predrag Supurovic @ 16.01.2018. 23:28 ] @
Možda može prostije, umesto dve tabele GlavaSkola i podrucna skola uvedes smao jednu tabelu Skola koja ima primarni kljuc SkolaID i dodatno polje GlavnaSkolaID

Glavne skole u SkolaId imaju svoj ID a GlavnaSkolaID ostaje prazno

Podrucne skole imaju svoj ID u SkolaId a u GlavnaSkolaID imaju SkolaId od glavne skole.


Nakon toga tabela osnovno sredstvo se vezuje sa tabelom Skola samo po kljucu SkolaId.


[ Carduel @ 17.01.2018. 00:32 ] @
Pozdrav Predraže,

pokušao sam napraviti ovaj savjet koji si napisao i to nekako ovako izgleda. Da li sam to napravio kako ste zamislili?

Primjer baze o školskom inventaru

Isto tako sam pokušao napraviti što je Getsbi postavio ali sam očito nešto pogriješio pa kad unosim podatke sav mi inventar ide na podružne škole. Ne mogu ništa staviti na glavne škole. Dobivam upozorenje Indexed pa sam tu mijenjao Yes (No Duplicates), Yes (Duplicates OK) ali nešto mi nije išlo. :(

Očito je do mene. :)

lp





[ Getsbi @ 17.01.2018. 07:09 ] @
Slažem se sa Predragom da je njegovo rešenje jednostavnije. Što se mog modela tiče i tvojih problema sa njim evo u čemu je problem.
U tabeli „Osnovna sredstva” preneseni ključevi: „GlavnaSkolaID” i „PodruznaSkolaID” su numerici sa osobinama Required=Yes i Indexed=Yes(Duplicates OK). Kad sredstvo pripada glavnoj školi, u koloni „PodruznaSkola” unosiš nulu. Za sredstva iz podružnih škola to polje će imati adekvatnu vrednost.
Ako se inventarski brojevi numerici (nemaju slova)onda je najbolje da polje „InventarskiBroj” bude AutoNumber(Increment).
Ako su inventarski brojevi sa nekim slovima, odnosno nizovi karaktera, moraćeš da obezbediš pravilo za kreiranje i nuđenje za unos. Takvo pravilo bi koristilo standardnu funkciju Str() nad brojevima primarnih ključeva škola i neki brojač.
Svakako da je prva varijanta jednostavnija.
Druga varijanta je za slučaj da inventarski broj mora da se prepozna vizuelno bez uvida u elektronsku evidenciju.
[ Carduel @ 17.01.2018. 11:19 ] @
Inventarski brojevi su kombinacija slova i brojeva. U slučaju da se ne koriste slova čini mi se da ne bi mogao staviti AutoNumber u polje InventarskiBroj pošto brojevi su uvijek različiti i nisu u nizu. Npr. škola kupi 3 stola, jedan je broj 123456, drugi 458326, treći 456213.

Getsbi, zamolio bi te jedno pojednostavljeno objašnjenje prve i druge varijante. Pošto se baš ne kužim u sve dijelove accessa pogubim se dok čitam postove. Koju varijantu da koristim i zašto? Da li mi pojednostavljuje neka od njih izradu formi, upita ili nešto treće?

U praksi bi to izgledalo ovako. Neka škola kupi određen broj stolova. Preko forme za unos inventara ili direktno u tablici bi zaveo da je broj stola 123456 i upisao vrstu stola.

Onda bi napravio formu za unos glavnih škola i područnih škola ili opet direktno u tablici unosio. U slučaju da unosim područne škole trebao bi imati na formi mogućnost izbora kojoj glavnoj školi ta područna škola pripada (combo box, list box).

I na kraju da povežem neku od škola (glavnu ili područnu) sa tim nekim kupljenim stolom kojeg sam prethodno unio u tabelu inventar.

Da li razmišljam na ispravan način ili sam promašio koncept? :)
[ Getsbi @ 17.01.2018. 13:22 ] @
U jednoj tabeli može samo jedno polje da bude Autonumber. Ono obezbeđuje unikatnost (jedinstvenost) i ne može da se ponovi bilo da je na polju primarnog ključa ili na nekom drugom polju.
Na tebi je da se odlučiš gde ćeš da ga koristiš.
Primarni ključ ne mora po defaultu da bude Autonumber. Može biti Number, Long Integer i da se kontroliše iz forme za unos tako što na polju SkolaID u osobinu Default value upišeš:
= Nz(DMax("[SkolaID]";"tbl_skole");0) +1
To isto važi i za invetarski broj ako je samo broj bez slova.

Ako kažeš da su inventarski brojevi kombinacija slova i brojeva onda moraš da osmisliš kako taj inv.broj treba da izgleda za pojedino osnovno sredstvo.
Na primer za stolove da bude S41001.

S-stolovi
4-skola
1-pripadnost glavnoj skoli
001 – brojač od 1-999 za tu školu

Ili neki drugi primer. U savkom slušaju s41001 je string. Za njegovo pravljenje trebaće ti Access-ove standardne funkcije kao što su STR(), Val() i gore pomenuta Dmax().
Zato je jednostavnija varijanta da ti inventarski broj bude numerik koji će da kontroliše aplikacija sa prvom funkcijom koju sam ti predložio i da korisniku smanji mogućnost pogrešnog unosa.
[ Carduel @ 17.01.2018. 18:28 ] @
Getsbi:

Samo jedna napomena vezano za stolove je da oni dođu predefinirani prilikom kupnje. Znači njihov unikatni broj (naš jmbg) definira prodavač i nema duplikata. I kao takve ih unosim u tablicu inventar. Svaki prodavač ima svoj prefiks:

Npr.

- Firma Drvostil (DR-MS-001 - drvostil mali stol 001, ....DRVS001 - drvostil veliki stol 001, DROS001 - drvostil okrugli stol 001, DROVS001 - drvostil ovalni stol 001).

- Mita namještaj (MN-MS-001, MNVS001, MNOS001, MNOVS001, ...)

- Namještaj Ikonić (NI-MS-001, NIVS001, NIOS001, NIOVS001, ...)

Svi ovi brojevi inventara nisu autonumber nego kako se kupe i ove firme ne proizvode samo za škole kao kupce nego i za druge firme koje mogu kupiti te stolove.

itd... Kad se gleda sa strane prodavača oni su autonumber idu rastućim redom npr. DRMS001, DRMS002, DRMS003, ...DRMS053, e sad kad kupujemo možemo kupiti 2, 3, 12, 35, 42 broj stola. A ovdje ne zanima me numeriranje od strane prodavača nego samo kako se zove i koliko je kojih stolova kupljeno od njega.

Stolovi se znači dijele na male, velike, okrugle, ovalne...

Da li ima potrebe stavljati ove oznake u novu tablicu prodavač gdje bi stavili DR - dvostil, MN - mita namještaj, NI - namještaj iković itd... kao da otvorim i novu tablicu vrsta stola pa da upišem mali, veliki, okrugli, ovalni?

Pa možda ne bi bilo loše da znam koliko je koja škola od koga kupila ovih stolova?!

Možda bi onda i mogao proći autonumber na nekoj poziciji?!



[Ovu poruku je menjao Carduel dana 17.01.2018. u 19:44 GMT+1]

[Ovu poruku je menjao Carduel dana 17.01.2018. u 20:04 GMT+1]
[ Getsbi @ 17.01.2018. 19:17 ] @
Malo si me doveo u zabludu sa terminom inventarski broj. To što spominješ je proizvodni broj. Inventarski brojevi sa inventarskih lista su nešto što zadaje vlasnik osnovnih sredstava. Zato sam tupio oko dva moguća načina.
Kažeš ovako „Stolovi se znači dijele na male, velike, okrugle, ovalne...” Ako se radi samo o stolovima i ako je lista iscrpljiva (desetak elemenata) onda ima smisla da elemente liste staviš u novu tabelu i prilikom unosa biraš ih iz Combo box-a. Ako nije, dodaj novu kolonu u postojeću tabelu sredstava i nazovi je recimo „Tip”, pa unosi ručno tu karakteristiku.
[ Predrag Supurovic @ 17.01.2018. 19:36 ] @
Citat:
Carduel:
pokušao sam napraviti ovaj savjet koji si napisao i to nekako ovako izgleda. Da li sam to napravio kako ste zamislili?

Primjer baze o školskom inventaru


Ovo je datoteka u nekom accdb formatu koji ne znam šta je.


Inače što se tiče id i inventarskog broja, namesti da je primarni kljuc ID i da je autoinkrement a inventarskki broj upisuj u posebno polje. Tabel povezuj po primarnim kljucevima. možda ti u ovom slučaju to niej neophodno ali je dobro da se navikavaš da ti ID bude polje koje nema nikakvo drugo značenje do primarnog ključa sloga.



[ Carduel @ 17.01.2018. 19:40 ] @
Malo sam pobrkao inventarski vs proizvodni broj. :)

Uglavnom, taj proizvodni broj je unikatan (nema dva ista) i on se zavodi u tablicu inventar.

Isto tako proizvođači imaju svoje inicijale koji su opet unikatni. Npr. Firma Drvostil - inicijal DS, Namještaj Ikonić - inicijal NI i ti inicijali odmah ukazuju o kojem se proizvođaču radi.

Te inicijale oni ubacuju u proizvodni broj npr. DSMS123321. Kad ovo rasčlanim dobijem DS, MS i 123321. DS je oznaka proizvođača, MS oznaka vrste stola a 123321 broj pod je proizveden.

Sad ako bi napravio tablicu prodavač/proizvođač (ovdje više nema grananja u bazi, bitan je naziv firme od koga su kupljeni stolovi) i u nju stavio id i naziv ne bi morao zapisivati ovaj tekstualni prefiks DSMS po kojem bi mogao identificirati prodavača/proizvođača jer će taj prefikst svakako biti u tablici inventar kao DSMS123321. Jer ovdje je samo bitno od koga je kupljeno u tablici prodavač/proizvođač.

Pokušat ću to sve pospojiti u bazi pa ću okačiti u post.

Hvala puno Getsbi na pojašnjenjima.

Predrag:

Okačio sam bazu iz Access 2016 verzije pa je zato taj format.

Hvala i tebi puno na pomoći.
[ Carduel @ 17.01.2018. 21:41 ] @
Citat:
Getsbi:
Malo si me doveo u zabludu sa terminom inventarski broj. To što spominješ je proizvodni broj. Inventarski brojevi sa inventarskih lista su nešto što zadaje vlasnik osnovnih sredstava. Zato sam tupio oko dva moguća načina.
Kažeš ovako „Stolovi se znači dijele na male, velike, okrugle, ovalne...” Ako se radi samo o stolovima i ako je lista iscrpljiva (desetak elemenata) onda ima smisla da elemente liste staviš u novu tabelu i prilikom unosa biraš ih iz Combo box-a. Ako nije, dodaj novu kolonu u postojeću tabelu sredstava i nazovi je recimo „Tip”, pa unosi ručno tu karakteristiku.


Radi se samo o stolovima i lista je iscrpljiva sa 2 - 3 elementa. Znači tablela tip i vežem je za tip u tabeli inventar. :)

Da li je đak uspio nešto naučiti? :D ili sam opet promašio. :)

Sviđa mi se ta opcija da iz combo box-a odaberem vrstu stola. :)
[ Predrag Supurovic @ 17.01.2018. 23:14 ] @
Citat:
Carduel:
Isto tako proizvođači imaju svoje inicijale koji su opet unikatni. Npr. Firma Drvostil - inicijal DS, Namještaj Ikonić - inicijal NI i ti inicijali odmah ukazuju o kojem se proizvođaču radi.

Te inicijale oni ubacuju u proizvodni broj npr. DSMS123321. Kad ovo rasčlanim dobijem DS, MS i 123321. DS je oznaka proizvođača, MS oznaka vrste stola a 123321 broj pod je proizveden.

Sad ako bi napravio tablicu prodavač/proizvođač (ovdje više nema grananja u bazi, bitan je naziv firme od koga su kupljeni stolovi) i u nju stavio id i naziv ne bi morao zapisivati ovaj tekstualni prefiks DSMS po kojem bi mogao identificirati prodavača/proizvođača jer će taj prefikst svakako biti u tablici inventar kao DSMS123321. Jer ovdje je samo bitno od koga je kupljeno u tablici prodavač/proizvođač.


Ne bih se ja time opterećivao. Ako već imaš tabelu s aproizvođačima onaj ko un4ese sto u bazu mora svakako da to poveže sa proizvođačem. Ako proizvdni broj može damu pomogne super, ali to je samo na interfejsnom novu: ako iz tog broja može da se pretpsotavi proizvođač na masi za unos mu predložiš tog proizvođača da ne mora sam da traži.


[ Carduel @ 18.01.2018. 00:45 ] @
Proizvođač je bitan da se zna koliko je kojih stolova neka škola kupila od njega, da se znaju proizvodni brojevi za svaki stol a sve ostalo se može izbaciti.

Baš se radujem radu na pravljenju ove baze. Danas ili ovo dana pokušat ću sam ovo napraviti i popuniti tablice sa nešto podataka da vidim kako to funkcionira zajedno.

Gledao sam po internetu neke kurseve pa sam stao na lynda.com pa me zanima ima li tko kakvog iskustva što se tiče kvalitete ovih kurseva za access.

Isto tako ovdje ima dosta toga https://www.youtube.com/user/ProgrammingMadeEZ/videos.







[ Predrag Supurovic @ 18.01.2018. 00:55 ] @
Za proizvođače treba da uvedeš posebnu tabelu.
[ Carduel @ 18.01.2018. 11:07 ] @
Predraže, Getsbi, koliko je ovo složen projekt s obzirom šta mi treba?

[ Predrag Supurovic @ 18.01.2018. 13:40 ] @
Zavisi koliko ti hoće[ da ga usložiš.

Recimo, ja bih mesta izdvojio u posebnu tabelu a možda i adrese, uopšte uzevši adrese i ostali kontakti su sistem za sebe.



Pre svega, moraš da sebi napišeš projekti zadatak, to jet da opišeš koje podatke eliš da držiš u bazi, koji su odnosi između tih podataka ikakve izveštaje želiš da dobiješ. Na osnovu toga možeš da isplaniraš i samu bazu a i aplikaciju.


[ Carduel @ 18.01.2018. 14:05 ] @
Ma ne bi išao pretjerano u širinu da se ne pogubim i ovako sam izgubljen :D

Znači škole (glavne i podružnice) kupuju od proizvođača nekoliko vrsta stolova koji imaju svoj jedinstveni proizvodni broj, koji su kupljeni nekog datuma i imaju neku cijenu.

Unos podataka o školama, proizvođačima i inventaru (stolovima)

I na kraju izvještaji koliko je koja škola kupila stolova, koji su im proizvodni brojevi, datum kupovine, cijena.

I skupni izvještaj glavna + njene područne škola. Tražilica preko ID broja škola u potrebnim formama ili autonumbera.

Pokušat ću to napraviti pa okačiti na forum da pogledate. Otekao mi je mozak od razmišljanja. :D Imam dojam ako se nešto propusti u zadatku da sve izmakne kontroli.
[ Zidar @ 19.01.2018. 19:20 ] @
Resenje je u ovoj recenici:
Citat:
Znači škole (glavne i podružnice) kupuju od proizvođača nekoliko vrsta stolova koji imaju svoj jedinstveni proizvodni broj, koji su kupljeni nekog datuma i imaju neku cijenu.


Svaka imenica predstavlja nesto ili nekoga koga hoces da pratis u bazi - entitet je rec koja se cesto koristi. Glagoli oznacavaju ili atribute entiteta ili veze/ transakcije izmedju entiteta.
Data recenica se moze rasclaniti ovako:
Code:

Skole => entitet Skola
Mogu da budu glane i podrucne. => entitet TipSkole (Glavna, Podrucna)
Svaka podrucna skola pripada nekoj glavnoj skoli => ovo je hijerarhija, to cemo malo detaljnije da razmotrimo.
Glane i podrucne skole su medjusobno povezane. Svaka podrucna skola pripada btacno jednoj glavnoj skoli. 

Proizvodjaci => entitet Proizvodjac

Stolovi => entitet Sto
jedinstveni proizvodni broj => atribut entiteta Sto
Stolovi mogu da budu razlicitog tipa =>  entitet TipStola

Proizvodjaci proizvode stolove <=> veza ismedju stolova i proizvodjaca.

Skole kupuju stolove od proizvodjaca na neki datum i placaju neku cenu => transakcija Kupovina
Atributi transakcije Kupovina ( Skola, Proizvodjac, Sto, DatumKupovine, CijenaKupovine)
[\code]

Entite skola je interesantan, jer je hijerarhija. Glavne skole su kao roditelji, a podrucne skole su im  kao deca. Podrucne skole ne mogu imati svoje pod-skole, znaci hijerarhija je tacno dva nivoa duboka. To se modelira lako:

Code:

Skola  TipSkole    GlavnaSkola ImeSkole            Adresa
------ ----------- ----------- ------------------- ----------
'GS1', 'Glavna ',  NULL        'Glavna skola 1',   'adresa x'
'PS1', 'Podrucna', 'GS1',      'Podrucna skola 1'  'adresa y'
'PS2', 'Podrucna', 'GS1',      'Podrucna skola 2'  'adresa z'
'GS2', 'Glavna',   NULL        'Glavna skola 2',   'adresa u'
'GS3', 'Glavna',   NULL        'Glavna skola 3',   'adresa w'
'PS3', 'Podrucna', 'GS3',      'Podrucna skola 3', 'adresa w'

Moraju se postaviti ogranicenja:
1) Atribut Skole je Primary Key za tabelu.
2)  TipSkole = 'Glavna' <=> GlavnaSkole IS NULL - na nivou tabele napises [TipSkole] = 'Glavna' EQV GlavnaSkola IS NULL.

Ogranicenje 2) zahteva da glavne skole nemaju roditelja, a da podrucne skole moraju imati roditelja.

Uocimo da:
Glavna skola 'GS1' ima dve podrucne skole - PS1 i PS2.
Glavna skola GS2 nema ni jednu podrucnu skolu.
Glavna skola GS3 ima jednu podrucnu skolu - PS3

Interesantna je i tabela Kupovine. Na primer, zabelezili smo ovo:
Code:

RbTransakcije Skola IdStola  BrojKomada   JedinicnaCena DatumKupovine
------------- ----- ------- ----------- --------------- -------------
            1 GS1   Sto01             2          100.00 20170922
            2 GS1   Sto02             2           15.00 20170925
            3 PS1   Sto02            20           15.00 20170925
            4 PS2   Sto02            30           17.00 20170925
            5 GS3   Sto01             3          120.00 20171003

(5 row(s) affected)


Glavne skole placaju racune, pomocne ne mogu da plate. Kako bi izgledao kveri koji izlistava koliko kojih stolova treba da plate glavne skole, i koliko treba da plate. Na primer:
GS1: 1 Sto01 +2 Sto02 + 20 Sto02 + 30 Sto02 , pa onda i cene puta kolicine.Primetite da za PS1 i PS2, za isti ID stola imamo razlicitu cenu. Ocigledno je da nam treba informacija o tome koja glavna skola placa za koju podrucnu skolu....


Srecan rad :-)






[ Carduel @ 19.01.2018. 22:19 ] @
Zahvaljujem Zidar na iscrpnom tekstu.

Molim te ako bi mi mogao reći kako da napravim ovaj upis [TipSkole] = 'Glavna' EQV GlavnaSkola IS NULL.

Taj izraz na nivou tabele na žalost ne razumijem i ne znam gdje se to upisuje. Da li se to radi preko Query > SQL pa zalijepim ovaj upis?

Isto tako ovaj dio tabele mi nije jasan. Da li su atributi svi naslovi (Skola, TipSkole, GlavnaSkola, ImeSkole, Adresa)? Da li se ovdje izbacuje autonumber SkolaID i stavlja atribut Skola koja je primary key?


Code:
Skola  TipSkole    GlavnaSkola ImeSkole            Adresa
------ ----------- ----------- ------------------- ----------
'GS1', 'Glavna ',  NULL        'Glavna skola 1',   'adresa x'
'PS1', 'Podrucna', 'GS1',      'Podrucna skola 1'  'adresa y'
'PS2', 'Podrucna', 'GS1',      'Podrucna skola 2'  'adresa z'
'GS2', 'Glavna',   NULL        'Glavna skola 2',   'adresa u'
'GS3', 'Glavna',   NULL        'Glavna skola 3',   'adresa w'
'PS3', 'Podrucna', 'GS3',      'Podrucna skola 3', 'adresa w'


Pokušao sam posložiti entitete i njihove atribute po uputama pa sad ne znam jesam li to dobro uradio.

[Ovu poruku je menjao Carduel dana 19.01.2018. u 23:46 GMT+1]

[Ovu poruku je menjao Carduel dana 19.01.2018. u 23:47 GMT+1]

[Ovu poruku je menjao Carduel dana 20.01.2018. u 00:05 GMT+1]
[ Predrag Supurovic @ 20.01.2018. 01:17 ] @
Ja bh samo savetovao da polje Skola ne bude primarni ključ nego samo Unique a da se za primarni ključ uvede polje ID koje je autoincrement.

I čim imaš polje tip to znači da ti treba i tabela sa listom tih tipova.



[ Carduel @ 20.01.2018. 01:18 ] @
Zaboravio sam još nešto prilikom definiranja projektnog zadatka koja se odnosi na popravak stolova.

U slučaju da se polomi ploča stola potrebno ga je dati stolaru da ga popravi. Stolar bi zapisao datum kad bi dobio stol na popravak, njegov proizvodni broj i školu čiji je stol te kontakt osobu te škole. Po završenom poslu bi upisao datum završetka, opis i cijenu svog rada. Za svaki stol se posebno upisuju ovi podaci. Ako neka škola donese 3 stola na popravak, stolar svaki stol zavodi posebno (datum prijema, proizvodni broj, školu, kontakt osobu, datum završetka, opis, cijena).

Razmišljam o ovoj situaciji pa mislim da trebam napraviti tablicu stolar koja će biti u vezi sa tablicom skole i tablicom stolovi.

Da li u ovom povezivanju treba "prijelazna" tablica (npr. Izvrseni radovi) kao što je bio slučaj Proizvodjaci > Transakcije > Skole?

Potrebna je tablica Stolar.

Code:
Stolar
-------
StolarID
Naziv


Code:
U tablicu Skole se dodaje novi atribut kontakt osoba.


I sad ostaje prijem stola, popravak i završetak. Da li se ovdje radi o još tri dodatne tablice?

[ Carduel @ 20.01.2018. 01:26 ] @
Citat:
Predrag Supurovic:
Ja bh samo savetovao da polje Skola ne bude primarni ključ nego samo Unique a da se za primarni ključ uvede polje ID koje je autoincrement.

I čim imaš polje tip to znači da ti treba i tabela sa listom tih tipova.



Svaka škola ima svoj ID broj, on je Unique i sastoji se od 13 brojeva. Svaka podružna škola ima ID broj koji se razlikuje u zadnje 2 ili 3 cifre, nisam 100% siguran. Npr. glavna škola 4272186280002 a podružna škola 4272186280022. Na ovaj način bi se moglo utvrditi kojoj glavnoj školi pripadaju podružne škole.

Samo što ne znam da li je bolje, pametnije,... raditi sa ID autoincrement ili pomoću 13 znamenkastog ID broja?!

Odgovor na ovo pitanje znaju ljudi od zanata, za mene je ovo preteško.

Čim se pojave dvije različite mogućnosti odmah nastanu problemi pa se javljaju pitanja zašto ovo zašto ono. :) Rekao bi dječja posla. :)
[ Predrag Supurovic @ 20.01.2018. 08:15 ] @
Nisi me razime. Svaka tabela mora da ima PRIMARNI ključ Za primarni ključ najbole je koristiti neko generičko polje koje nema ama baš nikakvo drugo značnje osim da bude primarni ključ. Najpraktičnije je da to bude autoincrement. Ja takvo polje naziva ID. Tabele se povezuju preko primarnih ključeva.

Ako škola ima jedinstveni ID BROJ kao jedno od svojstava, to je onda PRIRODNI ključ. Razlika u odnosu na priamrni je da prirodni ključ ima značenje. Prirodni ključ može da služi i kao primarni ključ ali je bolje da se to ne radi, već samo prirodni ključ treba podesiti da bude unique.

Dakle, u tvom slučaju ja bih udeo polje ID koje je autoinkrement i primarni ključ i polje ID_BROJ koje je samo unique.
[ izonic @ 21.01.2018. 11:02 ] @
Evo moje tabele.
Ako ste zainteresirani dat cu obasnjenje za svako polje.
[ Carduel @ 21.01.2018. 13:10 ] @
Izonic:

Hvala na pomoći.

Ako ti nije problem volio bi pročitati tvoje objašnjenje.

Predrag:

Na ovoj stranici imaju objašnjenja o kojima si govorio.

Ključevi

[Ovu poruku je menjao Carduel dana 21.01.2018. u 14:31 GMT+1]

[Ovu poruku je menjao Carduel dana 21.01.2018. u 14:32 GMT+1]
[ Zidar @ 21.01.2018. 14:12 ] @
Q: [quote][TipSkole] = 'Glavna' EQV GlavnaSkola IS NULL[/q]

Ovako:
1) Otvoris tabelu u Design modu
2) Otvoris "Table properties" prozor
3) Imas tamo "Table Validation Rule"
4) tamo ukucas bukvalno ovo: [TipSkole] = 'Glavna' EQV [GlavnaSkola] IS NULL


Sto se tice ID autonumber ili ne, sve dok je Skola unique, to moze da prodje. Medjutim, treba biti veoma oprezan sa upotrebom Autonumber. Vrlo lako moze da se desi da pobrkas absolunto sve podatke a da nisi ni svestan. Upotrebu autonumber za "povezivanje tabela" mogu sebi da priuste samo stare kuke, 50+, kao Zonic ili Predrag S. jer znaju sta rade. Za sve ostale - kloniti se Autonumber, jer cete dobiti laznu sliku o integritetuu podataka. Svrha PK i FK NIJE da se "povezu tabele". Svrha je da se zahteva da vrednost u nkom polju date tabele (dete) mora postojati u nekoj drugoj tabeli (Roditelj tabela). Moguce je da neki kveriji rade brze ako je JOIN po intgere koloni, ali je sito tako moguce, i cesce se desava, da se faktura skole X dodeli skoli Y i da nista u bazi na to ne ukazuje. NEmam sad vremena, ali bih mogao u ponedeljak da malo ovo pojasnim.
[ Carduel @ 21.01.2018. 16:36 ] @
Uspio sam! Hvala Zidar. :)

U Access 2016 su stavili Property Sheet pa jedva nađoh. :)

Evo i sličica za nekog poput mene da se lakše snađe.

Citat:
Svrha PK i FK NIJE da se "povezu tabele". Svrha je da se zahteva da vrednost u nkom polju date tabele (dete) mora postojati u nekoj drugoj tabeli (Roditelj tabela). Moguce je da neki kveriji rade brze ako je JOIN po intgere koloni, ali je sito tako moguce, i cesce se desava, da se faktura skole X dodeli skoli Y i da nista u bazi na to ne ukazuje. NEmam sad vremena, ali bih mogao u ponedeljak da malo ovo pojasnim.


Zidar, bilo bi odlično da ovo pojasniš. Iskreno, mislio sam da je dovoljno PK i FK i gotova stvar. Ali očito sam krivo mislio kao i uvijek kad su baze u pitanju. :)









[ Getsbi @ 21.01.2018. 20:01 ] @
U principu veza dve tabele PK-FK može da bude jaka (identifikujuća), kada zapis u podređenoj tabeli i identifikaciono i egzistencijalno zavisi od zapisa u nadređenoj tabeli. Ovo se rešava u Access-u složenim ključem, forsiranjem referencijalnog integriteta, kaskadnim brisanjem, kaskadnim ažuriranjem i automatskim postavljanjem osobine Requred=Yes. Primer Račun i Stavka. Stavka ne može da se identifikuje niti može da egzistira bez znanja o Računu. U tabeli Stavka primarni ključevi su i StavkaID i preneseni RačunID. Čim su oba polja primarni ključevi nema duplikata ni u jednom polju. Ili primer Banke i filijale. Ista priča.

S druge strane veza može da bude slaba (neidentifikujuća) i to obavezna i neobavezna. Obaveznu rešavate u Access-u tako da na polje FK stavite osobinu Required=Yes, a neobaveznu Required=No. U oba slučaja preneseni ključevi nisu deo primarnog ključa. U prvom slučaju je dovoljno da forsirate referencijalni integritet. Primer Vozilo i Registracija. Registracija ima PK RegistracijaID. VoziloID je preneseni ključ i on nije deo primarnog ključa u tabeli Registracija. Ali to polje postavite kao zahtevano (Required=Yes).

Ako je veza neidentifikujuća i istovremeno neobavezna, tada je još labavija pa se preneseni ključ tretira kao nezahtevani (Required=No). Praktično se veza poštuje ali ne mora svako polje prenesenog ključa da bude popunjeno. Primer recimo Ugovora i Otpremnice. Roba može da bude poslata kupcu po nekom ugovoru, a može i na blef, pa ako se kupac „upeca” tim bolje. Otpremnica ima svoj PK OtpremnicaID. U ostalim kolonama koje nisu PK nalazi se i UgovorID koji je ovde FK (preneseni ključ).

Za pojačavanje i slabljennje veze u Access-u se koriste ili ne koriste validaciona pravila i slične stvari u programskom kôdu.

Što se tiče prirodnih i veštačkih ključeva, ovde sam preferiaro ove druge radi lakoće razumevanja iako je registracija (Vš 021-TN) bila dobar kandidat za PK. Neki entiteti nemaju dobre kandidate za ključeve dok ih drugi imaju i više od jednog. Uzmite primer Mendeljejevog periodnog sistema hemijskih elemenata. Odlični prirodni ključevi su i Hemijska oznaka i Atomska težina, a ako baš hoćete i Redni broj elementa prema kojem se raspoznaju. To hemičari bolje znaju. Ako imate dobrog kandidata za prirodni ključ, odnosno da je Unique ili jedinstven nemojte bežati od njega. Veštački su vam uvek na raspolaganju.

Ove navedene veze nisu jedine, ali čine 90% poslovnih pravila u realnom svetu. Izvinjavam se na dužini, ali učinilo mi se da će pomoći.
[ Carduel @ 21.01.2018. 23:14 ] @
E ovo tek ne kontam! :) Onaj osjećaj kao da ti netko pokuša na kineskom objasniti nešto a ti ništa ne kontaš. :D

Getsbi, Zidar, Predrag, Zonic ma vi ste kraljevi, koje Vi samo znanje imate. Impresioniran sam!

Treba li ovo u ovu moju tužnu bazu podataka, ovi složeni ključevi?

Može li mi netko objasniti na nekom najjednostavnijem primjeru ove složene ključeve, kako oni funkcioniraru međusobno, kako sprječavaju duplikate, itd...?
[ Predrag Supurovic @ 21.01.2018. 23:21 ] @
Citat:
Zidar:
Sto se tice ID autonumber ili ne, sve dok je Skola unique, to moze da prodje. Medjutim, treba biti veoma oprezan sa upotrebom Autonumber. Vrlo lako moze da se desi da pobrkas absolunto sve podatke a da nisi ni svestan. Upotrebu autonumber za "povezivanje tabela" mogu sebi da priuste samo stare kuke, 50+, kao Zonic ili Predrag S. jer znaju sta rade. Za sve ostale - kloniti se Autonumber, jer cete dobiti laznu sliku o integritetuu podataka.


Rekao sam najpraktičnije je, nisam rekao da je obavezno koristit Integer autoincrement.

Ne znam na šta misliš da se sa autoincrement mogu da se pobrkaju podaci. Jedina nezgoadija je što su sve veze neznačenji brojevi pa kad otvoriš tabelu direktno u bazi ti brojevi ti ne znače mnogo već uvek moraš nekako da ih povezuješ sa drugim poacima da bi ih prepoznavao.

Kad se prirodni ključ koristi kao PK onda je obično i prepoznatljivo njegovo značenje i to je obično osnovni razlog zašto neko koristi Prirodni ključ za PK.

Međutim, korišćenje prirodnog ključa kao PK je vrlo često prizivanje problema. Čim je prirodni ključ to znači da ima neko značenje, a ako ima značenje postoji uvek verovatnoća da se vresno promeni, da se značenje promeni, ili, da se pojavi neka druga komplikacija sa njegovim tumačenjem. Kada koristiš veštački ključ kao PK taj problem je isključen, jer veštački ključ nema značenje, jedina mu je svrha da jednoznačno identifikuje slog tabele.


Primer prvi: recimo da neko pravi tabelu osoba i uzme broj lične karte, što je prirodni kluč, kao primarni ključ. Greška je mnogima (ali ne svima) očigledna, jer se broj lične karte menja, pa kad neko promeni ličnu kartu, treba u tabeli da mu se to promeni a promena vrednosti koaj je primarni ključ nije baš naivna niti poželjna.

Slično je i sa navedenim primerom korišćenja registarske tablice kao identifikatora vozila zato što su tablice promenljive.


Primer drugi: programer koji malo razmisli će da zaključi da broj lične karte ne može da koristi kao primarni ključ pa će umesto toga da iskorsiti drugi prirodni ključ: matični broj. Mnogi će se zakleti da je matični broj jedinstven i nepromenljiv jer to tako treba da bude ali će kad-tad saznati da to u praksi nije tako i eto problema istih kao i sa brojem lične karte.

Kod vozila, neko će umesto registarskog brojq da uzme recimo broj šasije kao prirodni i primarni ključ. Broj šasije je zaista teško promenjiv ali nije nepromenljiv, dakle, može da se desi da se i on promeni, pa ni to nije dobar identifikator vozila.

E zato treba uvesti veštački ključ kao primarni ključ i otkačiti se zavisnosti od pravila vezanih za brojeve ličnih karata i matičnih brojeva, registarkih tablica, brojrva šasija i slično.

Primer treći: jedan od entiteta u ovoj bazi o kojo pričamo su stolovi i rečeno je da svaki sto ima id broj koji mu dodeljuje proizvođač i koji je jedinstven i stoga je on kao prirodni ključ uzet za primarni.

Međutim, šta ako se desi da dva proizvođača nekako pogode pa uvedu isti id broj za svoje stolove (koji su naravn različiti proizvodi) i naprave preklapanje? Šta ako se pojavi neki novi proizvođač koji dodeljuje iste id brojeve kao neki drugi proizvođač? Mi svakako ne možemo proizvođačima da namećemo kakve će oni id brojeve da dodeljuju svojim proizvodima. Možemo samo da preuzmemo id brojeve onakve kakvi su.

Stoga, otkačimo se od id broja kao primarnog ključa, uvedemo svoj inteni ključ koji će imati ulogu PK i postajemo potpuno nezavisni od toga kakav id broj ko dodeljuje svom proizvodu. Id broj čuvamo u bazi jer, ako po pitanju nekog stola (recimo radi reklamacije), kontaktiramo proizvođača on će nam tražiti i taj svoj id broj da bi znao o kom se stolu radi jer taj id broj njemu nešto znači.

Sve se to svodi na isto: dobro je steći naviku da se za primarne ključeve ne koriste prirodni ključevi.


Citat:

Svrha PK i FK NIJE da se "povezu tabele". Svrha je da se zahteva da vrednost u nkom polju date tabele (dete) mora postojati u nekoj drugoj tabeli (Roditelj tabela).


Povezivanje je opštiiji pojam i obuhvata sve vrste povezivanja i ne znači obavezno i da slog sa određenom vrednoti mora postojati u roditeljskoj tabeli (mada se najčešće očekuje i zahteva da postoji). U praksi to u stvari može da bude i prilično složeno pitanje. Da nije tako, onda ne bi pstojali LEFT I RIGHT JOIN nego samo INNER JOIN.

[ Predrag Supurovic @ 21.01.2018. 23:33 ] @
Citat:
Carduel:
E ovo tek ne kontam! :) Onaj osjećaj kao da ti netko pokuša na kineskom objasniti nešto a ti ništa ne kontaš. :D


Getsbi ti je sve manje-više objasnio na srpskom (štaviše izenađen sam u kojoj meri je uspeo da izbegne korišćenje engleskog).

Nezgodacija svake profesije je što mora da uvodi neki svoj rečnik da bi se efikasno ljudi sporazumevali. Da bih ih razumeo moraš da naučiš taj rečnik. Ako ne razumeš neki pojam ili izraz, gugl ti je pod rukom.

[ Carduel @ 22.01.2018. 01:11 ] @
U mom slučaju ne može da se desi da dva proizvođača daju isti proizvodni broj, znači svaki stol će imati jedinstveni proizvodni broj i ne može da dođe do preklapanja. Jedino ne znam da li će problem da napravi to što su ti proizvodni brojevi kombinacija brojeva i slova.

Citat:
Primer treći: jedan od entiteta u ovoj bazi o kojo pričamo su stolovi i rečeno je da svaki sto ima id broj koji mu dodeljuje proizvođač i koji je jedinstven i stoga je on kao prirodni ključ uzet za primarni.

Međutim, šta ako se desi da dva proizvođača nekako pogode pa uvedu isti id broj za svoje stolove (koji su naravn različiti proizvodi) i naprave preklapanje? Šta ako se pojavi neki novi proizvođač koji dodeljuje iste id brojeve kao neki drugi proizvođač? Mi svakako ne možemo proizvođačima da namećemo kakve će oni id brojeve da dodeljuju svojim proizvodima. Možemo samo da preuzmemo id brojeve onakve kakvi su.


Nije problem jezika Predraže nego ovaj drugi dio što se Googla. Do mene je! O sebi sam pričao ne o Getsbiju. Možda si krivo razumio. Sve ok.
[ izonic @ 22.01.2018. 17:02 ] @
Objjasnjenje za bazu nakacenu u postu na ovom linku
https://www.elitesecurity.org/t498139-1#3809677

Sto se tice primarnog kljuca odnosno autonuber polja, stavio sam ga iz razloga sto nisam bio siguran dali ce onaj koji unosi
biti primoran da unese neku skolu koja i nema bas njen id broj.
Ukoliko se to nece desavati onda se ovo polje ID moze izbrisati a proglasiti polje SkolaID primatnim kljucem.
Naravno to treba uraditi u Tabeli T_Skole i u tabeli T_Stolovi.
U tabeli T_Stolovi moze se prepraviti polje SkolaID.
U tabeli T_KontaktOsobe moze ostati autonumber.

Tabela T_Skole
U ovoj tabeli mislim da treba objasniti polja.
Ukoliko Ostavimo ID kao primarni kljuc onda u polju PripadnostID upisujemo 0 za glane skole a za podrucne skole upisujemo id od glavne skole.
Isti je postupak ukoliko se izbrise ID autonumber.
Onda bi se u PripadnostID Pisao kljuc iz polja skolaId.
Polje StatusID se isto tako moze izbrisati ali ja nisam smio bojeci se da me necete razumjeti.
U ovo polje se upisuje dali je Glavna skola ili podrucna a to se moze zakljuciti i na osnovu polja PripadnostId pa mislim da je visak sto se mene tice ali eto ako volite da imate motzete ga vuci.
Nepotreban unos.
Polje KontaktID Preneseni kljuc iz tabele kontakata gdje se upisuju podaci o osobi za kontakt.
Ukoliko ima vise osoba za kontak za pojedine skole onda ovo polje treba izbrisati i u tabeli kontakata ubaciti strani kljuc od tabele T_Skole.
Ukoliko je samo jedna osoba onda ovo polje se veze 1-1 za tabelu kontakata.

Polje PripadnostID daje nam podatke dali je skola zatvorena ili je u funkciji.
Polje DatumU treba da se unosi automatski i to je datum unosa rteda podataka.

Tabela T_Stolovi
Objasnit cu samo 2 polja jer mislim da se ova ostala znaju cemu sluze pa da ne piskaram.

StatusId polje koje odredjuje status osnovnog sredstva odnosno stola Pa moze biti u funkciji otpisan na popravci itd. kako zelite da podijelite odnosno kako nalaze dosadasni rad.
SkolaID Govori ko je vlasnik odnosno u kojoj skoli se nalazi dato osnovno sredstvo.
Kntak osobe mislim da nije potrebno objasnjavati.

Jos nesto ovako moje vidjenje.
Ukoliko se ovsje radi o desetak glavnih skola i koje imajo po 5 do 10 podrucnih skola onda bi se ovo moglo napraviti da se podaci o skolama prikazuju u tree kontroli i da se tu bira skola a onda bi se samo unosila osnovna sredstva za izabranu skolu.
Mislim da bi to lijepo funkcionisalo.
U prilogu slike tabela.
skole

stolovi



[Ovu poruku je menjao izonic dana 23.01.2018. u 18:18 GMT+1]
[ Carduel @ 22.01.2018. 19:22 ] @
Svaka škola ima ID broj i nema unosa bez tog broja.

Citat:
Sto se tice primarnog kljuca odnosno autonuber polja, stavio sam ga iz razloga sto nisam bio siguran dali ce onaj koji unosi
biti primoran da unese neku skolu koja i nema bas njen id broj.
Ukoliko se to nece desavati onda se ovo polje ID moze izbrisati a proglasiti polje SkolaID primatnim kljucem.
Naravno to treba uraditi u Tabeli T_Skole i u tabeli T_Stolovi.
U tabeli T_Stolovi moze se prepraviti polje SkolaID.
U tabeli T_KontaktOsobe moze ostati autonumber.


Nije mi palo na pamet da može biti u funkciji, otpisan ili na popravci. Ovo mi se jako sviđa :) Hvala ti na ideji.

Citat:
StatusId polje koje odredjuje status osnovnog sredstva odnosno stola Pa moze biti u funkciji otpisan na popravci itd. kako zelite da podijelite odnosno kako nalaze dosadasni rad.
[ izonic @ 22.01.2018. 20:02 ] @
Evo Primjer sa tree kontrolom.
Naravno ovo je samo primjer i treba ga zavrsiti ukoliko se prihvati .
[ izonic @ 25.01.2018. 21:12 ] @
Zakacio sam samo bazu.
Izvinjavam se.
Evo primjer.
[ Carduel @ 31.01.2018. 19:42 ] @
Molio bi eksperte ako bi mogli da mi malo pojasne izbor tipa podataka za povezivanje tabela.

npr. ID broj škole pa upisujem ga u tekstualnom tipu a ne numeričkom.

- autonumber - number
- text - text
- itd...

Kad koristiti numerički tip, kad tekstualni,...

Hvala unaprijed
[ Getsbi @ 01.02.2018. 05:41 ] @
Evo ovde imaš prilično dobro objašnjeno:https://support.office.com/sr-...4f-946c-442e-8bd2-be067361987c
[ Carduel @ 21.02.2018. 23:05 ] @
Pozdrav svima,

molio bi za pomoć vezano za ovaj primjer ali posmatran sa strane stolara.

Nešto razmišljam ovako, kada škola pošalje neki stol u stolariju da se popravi nameću se tu neke tabele ali mi problem predstavlja kako locirati pravu tabelu od koje posmatramo događaj.

Imao bi tabele:

stolar (ime i prezime: marko marković, petar petrović)
stolovi (proizvodni broj: 1234, 2345)
servis (datum servisa, usluga, odgovorna osoba škole koja potpisiva tu uslugu: 22.2.2018, poliranje i bojenje, direktor škole Nikola Šop)
škola (id broj, naziv, odgovorna osoba: 1234567890123, oš Branka Ćopića, direktor škole Nikola Šop)

Ovdje gledam ovo sa strane stolara pa ne mogu da shvatim da li je stolar glavna tabela ili servis? Molio bi nekoga da mi ovo pojasni.

Na netu sam našao i ovaj primjer sa slike:



pa mi nije jasna ova veza manufacturer - model - car.

Kako je ispravno razmišljati kada su baze u pitanju ili da auto ima više modela ili da model ima više auta???

Ili još jedna kombinacija da proizvođač ima više modela koji opet imaju više auta???

Hvala Vam puno na strpljenju i pomoći.

lp



[Ovu poruku je menjao Carduel dana 22.02.2018. u 03:52 GMT+1]
[ Getsbi @ 22.02.2018. 06:21 ] @
U konkretnom slučaju oko automobila, odgovor bi bio da proizvođač proizvodi više modela automobila i to svaki model u više tipova, u ovom slučaju tabela (Car), koji se mogu razlikovati po vrsti ugrađene opreme, boji itd.
[ djoka_l @ 22.02.2018. 08:46 ] @
Na konkretnom primeru koji si postavio u pitanju je rent-a-car agencija.
Car je tabela gde se za konkretan automobil čuva registarski broj, kilometraža itd.
Model sadrži naziv modela, šifru modela i cenu dnevnog najma. Na primer, rent-a.car ima 10 automobila Opel Insignia (svi imaju drugačiju kilometražu, registarsku tablicu), ali postoji jedan slog u Model jer jer cena iznajmljivana na nivou modela, a ne pojedinačnog automobila.

U tabeli Manufacturer (koja je potpuno nepotrebna u postojećem modelu) nalaze se podaci o proizvođaču automobila, recimo Opel, Mercedes, Fiat. Ovo bi imalo smisla, kada bi, recimo, postojali ovlašćeni servisi, pa da znaš kod koga da šalješ na servis.
[ Carduel @ 27.02.2018. 20:52 ] @
Pozdrav svima,

molio bi pojašnjenje vezano za slučaj ako imamo više proizvoda, koje treba sačuvati u bazi, sa različitim imenima polja (field name) na koji način se to ispravno uradi?

Gledao sam neke primjere pa u prvom slučaju ako sve ostavimo u jednoj tablici pojavljuju se previše null vrijednosti (previše null vrijednosti - ne znam koliko je to općenito dobro kod baza?!), drugi slučaj da se u tablici product ostave zajednička imena polja a ostala da se prebace u tablicu productdetail pa sve do toga da se ti detalji postavljaju pojedinačno po tablicama (detaljna razrada).

Ako možete da navedete neki jednostavan primjer i pojasnite ova tri slučaja kad je šta dobro.

Hvala svima



[Ovu poruku je menjao Carduel dana 27.02.2018. u 23:45 GMT+1]
[ @ 28.02.2018. 18:47 ] @
Citat:
da se u tablici product ostave zajednička imena polja a ostala da se prebace u tablicu productdetail pa sve do toga da se ti detalji postavljaju pojedinačno po tablicama (detaljna razrada).


Upravo tako. U jednoj tabeli cuvas podatke koji su zajednicki za sve proizvode, a onda zasebne tabele u vezi 1:1 za svaku grupu proizvoda sa poljima koja su specificna samo za tu grupu.
Na primer tabela prevozna sredstva sa podacima koji se vode za sva sredstva, a onda u vezi 1:1 tabele Putnicka, Motocikli, kamioni...
sa podacima koji su specificni za pojedinu grupu. Ima dosta primera na forumu, ali trenutno ne uspevam da nadjem ni jedan reprezentativan
[ Carduel @ 28.02.2018. 19:44 ] @
Znači veza je 1:1 prevozna sredstva : putnička, motocikli, kamioni...

Pošto su polja različita za te detalje kako se rješava forma za unos kada se unosi novo prevozno sredstvo?

Da li tu ima neki combo box ili nešto drugo što će pozvati neku formu ili subformu samo za to prevozno sredstvo, neki vb kod?

Ili jednostavno napraviti cijeli popis pa popuniti samo neka polja (zajednička) i ovisno od detalja nekog prevoznog sredstva?

[ @ 01.03.2018. 10:13 ] @
Ima vise nacina. Na primer forma i podforme sa svojstvom visible na false, pa kad na formi izaberes vrstu iz comba automatski postaje visible odgovarajuca podforma. Nemam sad vremene, ako stignem postavicu veceras
[ Carduel @ 01.03.2018. 15:32 ] @
Citat:
Dexxxl : Ima vise nacina. Na primer forma i podforme sa svojstvom visible na false, pa kad na formi izaberes vrstu iz comba automatski postaje visible odgovarajuca podforma. Nemam sad vremene, ako stignem postavicu veceras


Hvala puno Dexxxl.

Svaki primjer je dobro došao jer vizualno mogu vidjeti kako to izgleda a to mi je puno zgodnije nego kad je opisno.

Mislio sam da je ovo jednostavnije ali kako napredujem sve više se divim ljudima od struke, koje znanje treba imati da se čovjek uhvati u koštac s ovim.
[ Dexxxl @ 02.03.2018. 19:54 ] @
Malo kasnim, ne stizem zbog obaveza, sto poslovnih, sto kafanskih :)
Evo dva primera
[ Carduel @ 02.03.2018. 21:14 ] @
Hvala puno Dexxxl.

Nije ništa od glavu, kafanske obaveze se ne smiju propuštati. :)
[ Carduel @ 04.03.2018. 22:23 ] @
Pozdrav svima,

u slučaju da ne koristimo za PK autonumber tip podatka nego neki drugi kako možemo postaviti provjeru unosa da nas access upozori da u bazi već imamo unešen taj podatak?



[ Getsbi @ 05.03.2018. 15:18 ] @
Za ispitivanje i proveru unesenih podataka i dobijanje poruke na ekranu u vidu: „Ovaj zapis već postoji” treba će ti poznavanje VBA programskog jezika. Evo nešto slično što kod mene radi u jednoj aplikaciji.
Code:
Private Sub BrojPrijemnice_BeforeUpdate(Cancel As Integer)
    Dim Baza        As Database
    Dim Sl_Zagl     As Recordset
    Dim Usl_Zagl    As String
    Dim Nova_sifra  As Long
    
    If IsNull([BrojPrijemnice]) Or [BrojPrijemnice] = 0 Then
         MsgBox "Morate uneti broj prijemnice", vbCritical, "Pažnja"
         Me![BrojPrijemnice].SetFocus
         Exit Sub
    End If
       
    Nova_sifra = Me![BrojPrijemnice]
    
    If IsNull(DLookup("[BrojPrijemnice]", "Prijemnica", "[BrojPrijemnice]=" & Nova_sifra)) = False Then
        Me![BrojPrijemnice].Undo   ' Poništava vrednost unetog polja
        DoCmd.RunCommand acCmdUndo ' poništava unos sloga
        Cancel = True
        MsgBox "Pod šifrom  " & Nova_sifra & "  imate unete podatke", vbCritical, "Pažnja"
        DoCmd.FindRecord Nova_sifra 'nađe i prikaže slog sa šifrom koja je pokušana da se duplo unese
                                     ' varijanta kada su dostupni svi slogovi, a ne samo novi.
    End If
   ' ..............
   ' ...............
   ' ........
End Sub

[ Carduel @ 29.04.2018. 22:56 ] @
Pozdrav svima,

zamolio bi iskusne kolege za jedno pojašnjenje vezano za dobavljače i kupce.

Primjetio sam da se koriste dvije varijante:

1) Podaci o dobavljačima i kupcima idu u jednu tabelu.
2) Podaci o dobavljačima i kupcima idu u dvije tabele (tabela dobavljač i tabela kupac).

Pošto ovo ne razumijem najbolje možete li mi reći koje su prednosti i nedostaci ovih varijanti.

Gledao sam Northwind bazu podataka i u njoj se koristi varijanta broj 2 (posebno dobavljači, posebno kupci).

lp
[ Predrag Supurovic @ 30.04.2018. 08:12 ] @
Ako ti jedan klijent nikada neće biti i kupac i dobavlač onda mogu dve tabele. Ako klijent može da bude i kupac i dobavljač onda u jednu.

[ djoka_l @ 30.04.2018. 08:52 ] @
Kada bi postojalo rešenje koje je uvek bolje, onda bi svi radili na taj način.
Nekako, krećeš iz sredine.

Zamisli da imaš situacije:
1. Ogroman broj kupaca, mali broj dobavljača (zamisli, na primer telekom firmu, imaju stotine hiljada "kupaca" a samo nekoliko stotina dobavljača. Šta bi bilo da se i kupci i dobavljači drže u jednoj tabeli. Zamisli situaciju da treba da napraviš izveštaj o dobavljačima, a u tabeli ti je samo jedan procenat slogova ili manje vezan za dobavljače).
2. ogroman broj dobavljača a mali broj kupaca (na primer fabrika automobila sa hiljadama kooperanata, a imaju samo veleprodaju koja ima nekoliko dsetina auto-kuća koje su kupci, pa dalje plasiraju u maloprodaju).
3. postoji umeren broj i kupaca i dobavljača i većinom se pojavljuju i kao kupci i kao dobavljači.
4. postoji puno kupaca dobavljača, ali se uglavnom javljaju ili kao kupci ili kao dobavljači.

Možda o kupcima imaš malo podataka, a o dobavljačima znatno više. Da li onda gurati mnogo NULL polja u jednu tabelu koja je zajednička za kupce i dobavljače?

Dizajn tabele je rezultat sistem analize i ne postoje unapred najbolja rešenja za svaku moguću situaciju.
[ Predrag Supurovic @ 30.04.2018. 10:27 ] @
Dobro de ne treba preterivati, čim Carduel ovo pita sigurno se radi o nekom jednsotavnom slučaju.

Čak i kada je složen, nema razloga da se redudatno uinosi isti komitent dva puta. Problem raznorodnih podataka zavisno od tipa komitenta se rešava odvahanjem speicičnih podataka za svaki ti u posebne table a a srodni podaci se ostavljaju u osnovnoj tabeli. Kada ti trebaju podaci o kupcima onda uzmes osnovu tabelu i povezes je sa tabelom sa podacima o kupcima. Kad ti trebaju podaci o dobavljacima ,onda, opet, uzmes osnovnu tabeli i povezes je sa tabelom sa podavima o dobavljacima.

Ako je baza baš tolika da i filtiranje po tipu predstavlja zahtevan posao onda radis nemarnu redundansu u neke privremene tabele da izbegnes cesto filtriranje.
[ djoka_l @ 30.04.2018. 11:07 ] @
Naravno da se slažem sa tobom, Peđa.
Možda nisi čitao od početka ovu temu, ali je postavljač krenuo sa primerom stolarske radnje, čiji su dobavljači fabrike i radionice za izradu nameštaja, a kupci proizvoda i usluga škole.
U ovom slučaju, praktično se nikada jedan entitet neće naći u ulozi i kupca i dobavljača.

Naravno, neke zajedničke podatke može držati u istoj tabeli, ali ima smisla razdvojiti specifične uloge u dve tabele.
Inače, kada sam rekao da kreće iz sredine, ovo nije prvo takvo pitanje, pa sam zato to spomenuo. Već je bilo pitanja, tipa šta je bolje da li ovo ili ovo, a da nije opisan konkretan problem.
Zato mi se čini da Carduel ima pogrešan utisak da postoje neki trikovi i prečice u dizajnu baze, a da nije svestan procesa sistemske analize.

Ovde se na mnogo mesta mogu naći pitanja tipa: Zašto mi je ovaj upit spor?
Na to svi graknu, zato što je dizajn loš (što je najčešće tačno). A odgovor na pitanje: Šta je dobar dizajn, može biti vrlo jednostavno - to je takav dizajn gde se rezultati upita dobijaju brzo.
Ne pravi se dizajn baze po nekakvom šablonu, već se pravi na osnovu pretpostavke na koji se način koriste podaci iz baze, koji su potrebni izveštaji, koje su procedure, kako se kreću informacije kroz firmu i koje su to informacije, pa se na osnovu toga modeluje i baza.
[ Carduel @ 30.04.2018. 15:58 ] @
Hvala Vam na odgovorima, meni i jeste najveći problem što ne razumijem tu logiku stvari pa nemam pojma odakle bi krenuo. Najviše me rasturi često korišten termin u prepisci a to je: "koristi se ovisno od situacije" i onda sam donji 100%. :D

Ovo je pitanje nevezano za moju temu nego me zanimalo pošto je kolega napravio nekakve 3 tablice i dobavljače i kupce strpao sve u jednu.

A pošto nemam pojma o tome ako možete još koju rečenicu da napišete o ovome.

1) Da li Null vrijednosti usporavaju upite, izvještaje, ...?
2) Evo tek sad primjetih da se podaci dupliciraju ako su dvije tablice a jedna je firma i dobavljač i kupac.

Nekako mi se čini da je previše ovoga tipa može i ovako a može i onako, a može i ....

Hvala još jednom.
[ Branimir Maksimovic @ 30.04.2018. 16:21 ] @
Pa izdvojis info i stavis samo id u te dve tabele. Usteda sa dve tabele je u tome sto ti ne treba uslov vise. Ne znam koliko imas tih stvari i koliko su ti slozeni upiti...
[ Carduel @ 30.04.2018. 19:00 ] @
Ma to su klasični slučajevi, nešto malo dobavljača cca 5 - max 20 i veći broj kupaca što fizičkih što pravnih osoba.
[ Carduel @ 02.05.2018. 00:45 ] @
Citat:
Predrag Supurovic:
Ako ti jedan klijent nikada neće biti i kupac i dobavlač onda mogu dve tabele. Ako klijent može da bude i kupac i dobavljač onda u jednu.



Predraže, mogu Vas zamoliti da postavite jedan primjer u accessu kad i dobavljači i kupci idu u jednu tabelu?


[ Predrag Supurovic @ 02.05.2018. 07:18 ] @
Ne radim u accessu tako da ništa od toga.

No, primer je jednostavan. Uzmeš običnu tabelu sa komitentima i u nju dodaš polje TIP_KUPCA koje je skup sa mogućim vrednsotima "K" za kupca i "D" za dobavljača, a možeš da uvedeš i još neke tipove, ako zatreba.

Ako baza nema skup tip polja, onda napraviš drugu tabelu koju veže sa tabelom komitenti 1:M vezom, pa u toj dodatnoj tabeli dodeljuješ statuse komitenta. Bitno je da obezbediš da jedna komitent može da ima i status kupca i status dobavljača istovremeno, odnosno i vše drugih statusa ako ih uvedeš.


[ Carduel @ 02.05.2018. 19:13 ] @
Napravio sam to ovako:

Baza komitenti

Ako bi htjeli dodati i fizičke osobe u ovu bazu kako bi onda to sve izgledalo?

lp
[ Carduel @ 06.05.2018. 23:48 ] @
Čitao sam malo na netu o ovome pa sam naišao na neke ideje da se i kupci i dobavljači stave u jednu tabelu pa da se vežu tebele kupci - računi i dobavljači - nabavke i da se na taj način može znati šta je tko u tim odnosima (K ili D).

Šta mislite o tome?

[ Predrag Supurovic @ 07.05.2018. 02:23 ] @
Pa tkao se i radi nego je dboro da u samoj tabeli imas tipove, odnoso tabelu tipova kao M stranu na komitentima tako da kada korisniku nudis da izabere nekog komitenta iz liste mozes da filtriras komitente tako da prikazes na primer samo kupce ili samo dobavljace.