Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Pomoć oko dizajna baze

[es] :: Access :: Pomoć oko dizajna baze

Strane: 1 2 3 4

[ Pregleda: 11460 | Odgovora: 64 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

Carduel
Carduel Spanic
Croatia

Član broj: 93224
Poruke: 84



+1 Profil

icon Re: Pomoć oko dizajna baze19.01.2018. u 22:19 - pre 75 meseci
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]
Prikačeni fajlovi
 
Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 6275

Sajt: pedja.supurovic.net


+1570 Profil

icon Re: Pomoć oko dizajna baze20.01.2018. u 01:17 - pre 75 meseci
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.




 
Odgovor na temu

Carduel
Carduel Spanic
Croatia

Član broj: 93224
Poruke: 84



+1 Profil

icon Re: Pomoć oko dizajna baze20.01.2018. u 01:18 - pre 75 meseci
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?

 
Odgovor na temu

Carduel
Carduel Spanic
Croatia

Član broj: 93224
Poruke: 84



+1 Profil

icon Re: Pomoć oko dizajna baze20.01.2018. u 01:26 - pre 75 meseci
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. :)
 
Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 6275

Sajt: pedja.supurovic.net


+1570 Profil

icon Re: Pomoć oko dizajna baze20.01.2018. u 08:15 - pre 75 meseci
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.
 
Odgovor na temu

izonic
ishab zonic
Tuzla

Član broj: 38128
Poruke: 591
109.175.112.*

Sajt: www.icentar.ba


+2 Profil

icon Re: Pomoć oko dizajna baze21.01.2018. u 11:02 - pre 75 meseci
Evo moje tabele.
Ako ste zainteresirani dat cu obasnjenje za svako polje.
zxz
Prikačeni fajlovi
 
Odgovor na temu

Carduel
Carduel Spanic
Croatia

Član broj: 93224
Poruke: 84



+1 Profil

icon Re: Pomoć oko dizajna baze21.01.2018. u 13:10 - pre 75 meseci
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]
 
Odgovor na temu

Zidar
Canada

Moderator
Član broj: 15387
Poruke: 3085
*.dsl.bell.ca.



+79 Profil

icon Re: Pomoć oko dizajna baze21.01.2018. u 14:12 - pre 75 meseci
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.
 
Odgovor na temu

Carduel
Carduel Spanic
Croatia

Član broj: 93224
Poruke: 84



+1 Profil

icon Re: Pomoć oko dizajna baze21.01.2018. u 16:36 - pre 75 meseci
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. :)









Prikačeni fajlovi
 
Odgovor na temu

Getsbi

Moderator
Član broj: 124608
Poruke: 2828



+45 Profil

icon Re: Pomoć oko dizajna baze21.01.2018. u 20:01 - pre 75 meseci
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.

Prikačeni fajlovi
 
Odgovor na temu

Carduel
Carduel Spanic
Croatia

Član broj: 93224
Poruke: 84



+1 Profil

icon Re: Pomoć oko dizajna baze21.01.2018. u 23:14 - pre 75 meseci
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...?
 
Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 6275

Sajt: pedja.supurovic.net


+1570 Profil

icon Re: Pomoć oko dizajna baze21.01.2018. u 23:21 - pre 75 meseci
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.


 
Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 6275

Sajt: pedja.supurovic.net


+1570 Profil

icon Re: Pomoć oko dizajna baze21.01.2018. u 23:33 - pre 75 meseci
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.


 
Odgovor na temu

Carduel
Carduel Spanic
Croatia

Član broj: 93224
Poruke: 84



+1 Profil

icon Re: Pomoć oko dizajna baze22.01.2018. u 01:11 - pre 75 meseci
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.
 
Odgovor na temu

izonic
ishab zonic
Tuzla

Član broj: 38128
Poruke: 591
109.175.119.*

Sajt: www.icentar.ba


+2 Profil

icon Re: Pomoć oko dizajna baze22.01.2018. u 17:02 - pre 75 meseci
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]
zxz
Prikačeni fajlovi
 
Odgovor na temu

Carduel
Carduel Spanic
Croatia

Član broj: 93224
Poruke: 84



+1 Profil

icon Re: Pomoć oko dizajna baze22.01.2018. u 19:22 - pre 75 meseci
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.
 
Odgovor na temu

izonic
ishab zonic
Tuzla

Član broj: 38128
Poruke: 591
109.175.119.*

Sajt: www.icentar.ba


+2 Profil

icon Re: Pomoć oko dizajna baze22.01.2018. u 20:02 - pre 75 meseci
Evo Primjer sa tree kontrolom.
Naravno ovo je samo primjer i treba ga zavrsiti ukoliko se prihvati .

zxz
Prikačeni fajlovi
 
Odgovor na temu

izonic
ishab zonic
Tuzla

Član broj: 38128
Poruke: 591
89.146.169.*

Sajt: www.icentar.ba


+2 Profil

icon Re: Pomoć oko dizajna baze25.01.2018. u 21:12 - pre 75 meseci
Zakacio sam samo bazu.
Izvinjavam se.
Evo primjer.
zxz
Prikačeni fajlovi
 
Odgovor na temu

Carduel
Carduel Spanic
Croatia

Član broj: 93224
Poruke: 84



+1 Profil

icon Re: Pomoć oko dizajna baze31.01.2018. u 19:42 - pre 74 meseci
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
 
Odgovor na temu

Getsbi

Moderator
Član broj: 124608
Poruke: 2828



+45 Profil

icon Re: Pomoć oko dizajna baze01.02.2018. u 05:41 - pre 74 meseci
Evo ovde imaš prilično dobro objašnjeno:https://support.office.com/sr-...4f-946c-442e-8bd2-be067361987c
 
Odgovor na temu

[es] :: Access :: Pomoć oko dizajna baze

Strane: 1 2 3 4

[ Pregleda: 11460 | Odgovora: 64 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.