Citat:
Datasheet, Text 50, nedostatak validacije unosa posledice su pocetnog stadijuma baze.
Ovo znaci da si jos uvek u fazi implementacije, da implementacija nije zavrsena. Sta mu to znaci implementacija modela podataka? Nista drugo nego "fizicko kreiranje tabela, odredjivanje podesnih data tipova, postavljanje veza (relacija)izmedju fizickih tabela u sitemu koji ce se koristiti za smestaj podataka (u tvom slucaju Access)". dakle, prodji onovo kroz SVE tabele, kroz SVA polja i vidi da li imas sve sto ti treba i da li tip polja odgovara. Budi siguran da polja koja ces povezati relacijama imaju identican tip podataka. text 50 i text 5 nije isto, mada bi verovatno radilo, sto se smatra slaboscu Accessa.
Citat:
Pitanje:
Zasto je korisno imati PK na svim tabelama (ili vecini), pogotovo u intersection tabelama. Nije problem da ih ubacim (npr. Redni broj), ali mi nije jasna svrha u konkretnom slucaju?
PK, zajedno sa FK je osnova garancije integriteta podataka. PK sprecava duplikate i jedinstveno odredjuje svaki red u tabeli. cela relaciona teorija je zasnovana na postojanju PK u svakoj tabeli. A Access jeste dobrim delom relaciona baza. i tvoja shema izgleda prilicno dobro, cak neverovatno dobro za nekoga ko jos uvek ne razume cemu sluzi PK. Da nisi shemu prepisao od negde?
U intersekcionim tabelama, PK NE SME da bude neki izmisljeni autonumber ili redni broj. U intersekcionim tabelama PK je SLOZEN. Intersekcion tabela ima 2 roditelja, i oni imaju svaki svoj PK, recimo PK1 i PK2. intersekciona tabela mora da sadrzi kolone koje u parent tabelama cine PK1 i PK2. Onda je PK intersekcione tabele kombinacija svih kolona koje cine PK1 i PK2.
Na primer, imas tabele Projekti i Klijenti. neka su njihovi PK ProjektID i KlijentID. Onda imas intersekcionu tabelu ProjektiKlijenti gde pokazujes koji klijent je ucesnik u kom projektu. Tabela ProjektiKlijenti mora da ima kolone ProjektID i KlijentID. PK za tabelu ProjektiKlijenti je kombinacija dve kolone (ProjektID i KlijentID). posto je to PK, on je po definiciji UNIQUE. To ti garantuje da se u tabelu ProjektiKlijenti jedan klijent moze uneti samo jednom za jedan odredjeni projekt. Kako da garantujes da se uvek unese samo onajklijent koji zaista postoji i samo onaj projekt koji zaista postoji? To garantuje FK - foreign key. To je ono sto vidis u Accessu pod imenom 'relationship' - ona linijica koja spaja tabele. I uvek mora imati "Enforce Data Integrity=YES". Bez toga je besmisleno uopste govoriti o PK ili 'relacijama'. Jos conceptualni jedan bug u Accessu. I sve ovo bez i jedne linije koda.
Baza podataka ne zna niti treba da zna kako ce i koje aplikacije da joj pristupaju. baza mora da ima ugradjen mehanizam za zastitu od prljavih i nelogicnih podataka. Taj mehanizam cine PK, FK, default values, data validation za polja i cele tabele, required property za polja. Sve ovo moze da se postigne i kroz aplikaciju, ali uz mnogo vise truda i rada i ogromne mogucnosti greske koju neces ni primetiti. Ko garantuje da sutra nece doci drugi programer, koji ce pretpostaviti da je integritet obezbedjen u samoj bazi i zanemariti proveru integriteta u aoplikaciji? Sta je sa slucajevima kad korisnici idu direktno u tabele da nesto promene ili dodaju ili obrisu?
Citat:
-Problem pogresnog unosa koji si pomenuo resavam obicno upotrebom combobox-a koji se poziva na isto to polje, bez ogranicenja na listu.
AKo vec nema ogranicenja na listu, znaci da se moze uneti i sta nije u kombo boksu. Otkud znas da to sto je uneto nije pogresno? U prethodnom paragrafu smo objeanili kako se problem losih podataka izbegava. Podaci se stite i odrzavaju na nivou tabela, a ne aplikacijom.
Ako si prepisao neciji rad, neka si, barem je dobar rad. Ali se potrudi da razumes o cemu se radi i cemu sve to, na duzi rok. U protivnom, imaces mnogo nevolja.
:-)
Popunjavanje baze sa desna (n) u levo (1) ?
