Koliko max polja u Access tabeli

[b4b]

Koliko polja prilikom dizajniranja jedne tabele moze da se stavi. Meni bi trebalo oko 200. Da li je to moguce (ne mislim na slogove koji se upisuju u tabelu, nego na ukupan broj razlicitih polja u tabeli )

 

[grunf]

U Accessu je max. 255 polja (kolona) za 1 tabelu.
Mada treba da provjeriš malo dizajn tvoje tabele, tj. da li ti je toliko polja neophodno u 1 tabeli ili možeš da je rastaviš na više tabela, uvedeš malo relacija među njima, i sl.

Grunf

 

[veljkoz]

Koliko polja prilikom dizajniranja jedne tabele moze da se stavi. Meni bi trebalo oko 200. Da li je to moguce (ne mislim na slogove koji se upisuju u tabelu, nego na ukupan broj razlicitih polja u tabeli )

200 polja? To je previse, pa ne znam sta da pravis...
Trebalo bi da razbijes to u vise tabela, prvenstveno da bi olaksao odrzavanje baze, a i smanjio ponavljanje podataka (npr. ako imas ljude koji rade po firmama i drzis informaciju za svaku firmu, podaci o firmi ce se ponavljati kod svakog ko tamo radi). Zamisli da treba da izmenis telefon firme - morao bi da nadjes gde se sve pominje, pa svuda da menjas... mislim, ima toliko mana, da ne mogu svega ni da se setim

 

[grunf]

Ne znam o čemu se konkretno radi, ali ipak postoje neke specifične stvari za koje je najbrže riješiti problem jednom ovakvom tabelom od 200-tinjak polja... recimo, razne vrste upitnika, anketa sa dosta različitih pitanja i slično...

Naravno da nisam pristalica ovakvih stvari i ukoliko se ikako može potrebno potrebno je normalizovati podatke, ali postoje primjene gdje se to jednostavno ne može... Konkretno: radio sam jedan upitnik za prikupljanje podataka, koji za pacijanta skuplja nekih 140 vrijednosti iz raznih nalaza, tipa opšti podaci, ultrazvuk, EEG, TCD... i nisam našao pametan način da organizujem podatke drugačije osim u jednu veliku tabelu...

 

[mirzallica]

Ne znam o čemu se konkretno radi, ali ipak postoje neke specifične stvari za koje je najbrže riješiti problem jednom ovakvom tabelom od 200-tinjak polja... recimo, razne vrste upitnika, anketa sa dosta različitih pitanja i slično...

Naravno da nisam pristalica ovakvih stvari i ukoliko se ikako može potrebno potrebno je normalizovati podatke, ali postoje primjene gdje se to jednostavno ne može... Konkretno: radio sam jedan upitnik za prikupljanje podataka, koji za pacijanta skuplja nekih 140 vrijednosti iz raznih nalaza, tipa opšti podaci, ultrazvuk, EEG, TCD... i nisam našao pametan način da organizujem podatke drugačije osim u jednu veliku tabelu...

Sve to si mogao podeliti prema tome koji doktor postavlja odredjenu dijagnozu, pa si mogao imati tabelu npr. (uvo-grlo-nos) itd (sigurno neces mesati ginekoloske podatke sa podacima vezanim za pritisak). Inace, ako se radi o bazi, vise od 10 ili max 15 atributa po tabeli nije dobro i takva baza nije dobra, sigurno...

 

[Minja]

Pazi kad u firmi imamo solidan informacioni sistem koji prati rad cele fabrike i ni pod razno nema tabele od 200 kolona . Budalastina....

 

[mirzallica]

Pazi kad u firmi imamo solidan informacioni sistem koji prati rad cele fabrike i ni pod razno nema tabele od 200 kolona . Budalastina....

Eto, bas tako... Smisao baze podataka je da se smanji redundantnost, a to se bas i postize time da se poseduje veci broj tabela sa po 10-ak atributa npr. koje su medjusobno povezane, a ne jedna sa 200 atributa...

 

[Mare]

Za ovakve ljude je excell, a ne access, jer ocigledno nisu ni culi za pojam relacione baze podataka.

Jedna rec normalizacija.

 

[Mare]

evo samo jedan deo iz knjige prof. Veljovica o tome. 1, 2 i 3-ca normalna forma su najbitnije ali ni ostale ne treba zaboraviti. Jednio tako moze da se napravi dobra RBP

Postupak normalizacije
Prilikom definisanja atributa, kao {to je re~eno, pristupa se modeliranju podataka odozdo nagore (Bottom Up). Ovaj pristup veoma je prihvatljiv za po~etnike u ovoj oblasti, jer polazi od opipljivih informacija definisanih na dokumentima i u kartotekama. Osnovu za ovaj na~in modeliranja podataka ~ine analiza funkcionalnih zavisnosti i postupak normalizacije.
U okviru aktivnost "2.3.3.Postupak normalizacije" uklanjaju se sve strukture koje stvaraju redundansu podataka, pa je slogan normalizacije: Jedna ~injenica na jednom mestu.
Pravilno izveden postupak normalizacije podataka omogu}uje korektno izvo|enje aktivnosti "3. Aplikativno modeliranje", koja ima strukturu kojom osigurava da u radu sa njom ne}e biti ne`eljenih anomalija, kao {to su, npr., uni{tavanje odre|enih podataka ili neuskla|enost izme|u memorisanih podataka kao posledica a`uriranja baze podataka.
Drugim re~ima, postupak normalizacije predstavlja transformaciju po~etnog entiteta u jednu ili vi{e korektnih entiteta ili veza u kojima su svi atributi potpuno funkcijski zavisni od klju~a, a me|usobno funkcijski nezavisni.
Da bi se mogao opisati postupak normalizacije, treba prethodno opisati pojam funkcijske zavisnosti.
Ako je svakoj vrednosti atributa A u relaciji R priklju~ena samo jedna vrednost atributa B u istoj relaciji, onda je atribut B funkcijski zavisan od atributa A asocijacijom tipa 1.
Funkcijska zavisnost se mo`e definisati izme|u slo`enog klju~a (vi{e atributa) i jednostavnog atributa.
Ako se svakom paru vrednosti atributa A i B relacije R mo`e priklju~iti ta~no jedna vrednost C iste relacije, tada je atribut C funkcijski zavisan od sastavljenog atributa A i B.
Potpuna funkcijska zavisnost se defini{e na osnovu definicije funkcijske zavisnosti.
Atribut B je potpuno funkcijski zavisan od atributa A iste relacije, ako je funkcijski zavisan od atributa A, a ne od nekog sastavnog dela atributa A.
Na osnovu ovako izvedenih definicija na primeru entiteta OSOBA bi}e pokazan postupak normalizacije kroz definisanje prve (1NF), druge (2NF) i tre}e (3NF) normalne forme.

Definisanje prve normalne forme (1NF)

Mo`e li se na osnovu posmatranja entiteta OSOBA (sa slike 3.40) uo~iti gre{ka?
Zbog lak{eg razumevanja, treba prevesti entitet OSOBA u tabelu sa definisanim primercima (koristi se i termin instance).

Problem je u atributu "Isplate". U prethodnim poglavljima u vezi sa entitetima i atributima nagla{eno je da sva imena moraju biti u jednom primerku, tj. da se u jedan atribut ne mo`e smestiti vi{e isplata.
S obzirom na to da nije poznato koliko isplata treba zapamtiti, koliko je prostora za to potrebno i {ta raditi ako ima vi{e isplata nego prostora, to onda ovakva tabela kr{i prvu normalnu formu. Da bi se popravila prethodna tabela, treba na neki na~in ukloniti atribute isplate iz entiteta OSOBA. Jedan od na~ina je da se to uradi prikazan je na slici 3.42.


Po{to je otkrivena grupa podataka koji se ponavljaju i od njih stvoren novi entitet ISPLATA, time je u~injen prvi korak prema normalizovanom modelu.
Kao jo{ jedan primer vezan za definisanje prve normalne forme, treba navesti slu~aj koji se naj~e{}e pojavljuje - vi{ezna~na upotreba istog atributa, gde se jednim atributom, npr., "Dat_zap ili Dat_odlaska" (slika 3.44) defini{u dve ~injenice.

Dakle, problem je u atributima: 'dat_zap ili dat_odlaska' koji predstavljaju jednu od dve ~injenice, po~etak rada u firmi i prestanak rada u firmi. Ne postoji mogu}nosti da se otkrije {ta taj datum predstavlja, kao {to ne postoji mogu}nost da se zapamte oba datuma, iako su, mo`da, oba poznata. Re{enje nije u tome da atribut mo`e da sadr`i dve ~injenice, ve} da postoje dva atributa koji govore o po~etku i zavr{etku rada.
Stoga je potrebno da se ugrade dva atributa koji nose dve razli~ite informacije (sl. 3.46. i sl. 3.47.) prikazuju izvedenu 1NF za ovaj slu~aj.


I u primeru sa sl. 3.40. i sl. 3.44. pogre{na re{enja ne zadovoljavaju prvu normalnu formu. Menjaju}i strukturu, sasvim sigurno, jedan se atribut pojavljuje samo jednom u entitetu i nosi samo jednu ~injenicu.
Dakle, prva normalna forma je ispunjena ako svaki od atributa entiteta ima jedno zna~enje i ne vi{e od jedne vrednosti za svaki primerak. Ako je sigurno da svi entiteti i atributi ne nose vi{e ~injenica, model zadovoljava prvu normalnu formu.
Ovi elementi su ugra|eni i u ERwin CASE alatu koji prihvata bilo koje ime za definiciju entitetat ili atribut, ali postoje ograni~enja:
 ERwin }e obavestiti o ponovnom kori{}enju imena entiteta, zavisno od postavke opcije o jedinstvenom imenu.
 ERwin }e obavestiti o ponovnom kori{}enju imena atributa, osim ako je to ime uloge (Rolename). Kada je pridru`eno ime uloge za atribut, mo`e biti kori{}eno u razli~itim entitetima.
 Erwin ne}e dozvoliti ulazak prenesenih klju~eva u entitet vi{e nego jednom, osim ako mu je dodeljeno ime uloge svaki put.
Spre~avaju}i da se vi{estruko koristi isto ime, ERwin vodi korisnika da svaki podatak smesti ta~no na jedno mesto.
Me|utim, potrebna je dalja analiza, jer prva normalna forma nije dovoljna pa se prelazi na definisanje druge normalne forme.

Druga normalna forma (2NF)

Definicija druge normalne forme je slede}a:
Entitet A zadovoljava drugu normalnu formu ako zadovoljava prvu i ako svaki atribut koji nije klju~ potpuno zavisi od primarnog klju~a.
Za opis ove definicije poslu`i}e primer vi{estrukog pojavljivanja istih ~injenica.
Ako bi se na primeru (slika 3.48) u entitet ISPLATA stavio atribut ' Datum zaposl.' mo`e se uo~iti da ovaj atribut zavisi od dela klju~a entiteta ISPLATA (Sifra osobe), a ne od celog klju~a entiteta ISPLATA.

Da bi se zadovoljila druga normalna forma potrebno je prebaciti atribut 'Datum zaposl.' u entitet OSOBA. Dakle, entitet kr{i drugu normalnu formu ako podatak mo`e biti prona|en kada se zna samo deo klju~a entiteta.
Mo`e da nastane gre{ka druge normalne forme ako se postavi neki atribut nekorektno, a ne postoji algoritam koji bi bez dodatnih informacija, pored onih u modelu, otkrio gre{ku. U entitetnom dijagramu Erwin ne mo`e znati da ime koje je dodeljeno atributu mo`e predstavljati listu objekata.
Na osnovu korekcija sprovedenih u okviru 2NF pristupa se definisanju tre}e normalne forme.

Tre}a normalna forma (3NF)

Definicija tre}e normalne forme je slede}a:
Entitet zadovoljava tre}u normalnu formu ako svaki atribut koji nije klju~ zavisi od klju~a, ~itavog klju~a i ne slu`i ni~emu drugom osim klju~a.
Na primer, bila bi povre|ena tre}a normalna forma ako se u entitet ISPLATA ugradi atribut 'Suma isplata'. 'Suma isplata' zavisi od atributa 'Isplata' i mo`e se izra~unati.
Pored ovih formi postoje i ~etvrta i peta i Boyce-Codd-ova forma, a njihova upotreba zavisi od skupa transakcija koje treba izvr{iti i ovde se ne}e razmatrati.
Mora se naglasiti da iskusni projektanti ve} razmi{ljaju u 3NF .
Na osnovu prethodno izvedenih aktivnosti (slika 3.32) u slede}em koraku treba definisati atribute.

za ostatak kupite knjigu

prof. dr. Alempije Veljovic

M O D E L I R A N J E
PROCESA I PODATAKA

 

[grunf]

Hvala na održanim predavanjima, pogotovo Maretu... Vrlo korisno... Hvala, Mare, care... Slušao sam relacione baze i položio ih prije 10-tak godina, (a 2 odlične knjige prof. Veljovića sam nabavio prije 2 godine), ali nije na odmet podsjetiti se malo, naročito kad ti neko ovako autoritativno (fontom cca. 26 px) napiše magičnu riječ "normalizacija"!

Elem, profesionalno se bavim bazama podataka i projektovanjem IS-ova zadnjih 6 godina, i spomenuo sam samo 1 specifičan slučaj a vi ste navalili k'o muve bez glave sa normalizacijom... Pokušavam da pomognem čovjeku (i da razumijem šta ga je to natjeralo na tabelu sa 200 polja?), ali me očito niste razumjeli...

Rekoh već da u praksi postoje pojedini slučajevi koji se ne mogu racionalno normalizovati (zapravo mogu, ali se time ništa ne dobija)...

Konkretno ("tražili ste gledajte"), slučaj ovog mog doktora - znači nije u pitanju običan karton pacijenta, već slučaj skupljanja podataka za doktorsku disertaciju, a ako ti kažem da samo detaljan ultrazvučni pregled (u ovom slučaju neurološki) pacijenta može imati i do 50-tak različitih parametara vjerovatno ćeš se iznenaditi...
Znači, 1 pacijenta opisuješ sa, recimo, 150 potpuno različitih "parametara" - od kojih je najveći dio brojčane vrijednosti (podaci sa raznih nalaza, izmjerene vrijednosti na ultrazvuku, EEG-u, TCD-u,...), i za to i dalje tvrdim da nema racionalnog načina normalizacije niti da bi se s tim dobilo nešto po pitanju smanjenja redundantnosti podataka... Uzgred, radi se o samo par stotina pacijanata (zapisa)...

Zašto ovo ne riješiti 1 tabelom u u Excelu? Naravno da može (i često se radi jer je lako izvoditi eksport i razne statističke proračune nakon toga), ali je zgodno zbog kontrole unosa podataka postaviti neku najobičniju masku u Accessu i iz nje "puniti" tu tabelu...

Eto, toliko... I dalje bih volio da nam b2b kaže o čemu se radi u primjeru sa početka, tj. tabeli od 200 polja...

 

[veljkoz]

E, kad postavis stvari na takav nacin, onda je to sasvim druga prica

 

[Deleted member 1735]

JA imam jedan slican problem,naime hocu da u napravim knjigovodstveni program koji ce izdavati fakture sa jeli spiskom artikala koji je odredjeni kupac kupio.E sad na fakturi su standardni podaci o kupcu tipu placanja itd i ja to sve stavljam u jednu tabelu u jednu kolonu i imam max 10 polja,E sad problem nastaje kada treba da dam operateru da izabere koliko artikala treba da stavi na fakturu :
za svaki artikal pored sifre treba da stoji i kolicina ,pojedinacna cena i rabat (ostatak podataka kao sto su merna jedinica , stopa pdv-a se cuva u tabeli o artiklima) sve u svemu ima za jedan artikal max 5 podataka sto nije problem dodati na onih 10 sa osnovnim podacima o fakturi ali problem lezi u tome kada operater izabere 10 ili 20 artikala sa svaki po 5 posebnih podataka sto mi se ne cini logicnim da se stavlja u jednu zajednicku tabelu za fakture i da imam otvorena polja za svaki artikal posebno.Mislio sam da otvorim novu tabelu sa spiskom artikala koji bi pored uobicajenih imali i sifru fakture na kojoj se nalaze.Da li bi ovo prestavljalo resenje ?

 

[G-D]

JA imam jedan slican problem,naime hocu da u napravim knjigovodstveni program koji ce izdavati fakture sa jeli spiskom artikala koji je odredjeni kupac kupio.E sad na fakturi su standardni podaci o kupcu tipu placanja itd i ja to sve stavljam u jednu tabelu u jednu kolonu i imam max 10 polja,E sad problem nastaje kada treba da dam operateru da izabere koliko artikala treba da stavi na fakturu :
za svaki artikal pored sifre treba da stoji i kolicina ,pojedinacna cena i rabat (ostatak podataka kao sto su merna jedinica , stopa pdv-a se cuva u tabeli o artiklima) sve u svemu ima za jedan artikal max 5 podataka sto nije problem dodati na onih 10 sa osnovnim podacima o fakturi ali problem lezi u tome kada operater izabere 10 ili 20 artikala sa svaki po 5 posebnih podataka sto mi se ne cini logicnim da se stavlja u jednu zajednicku tabelu za fakture i da imam otvorena polja za svaki artikal posebno.Mislio sam da otvorim novu tabelu sa spiskom artikala koji bi pored uobicajenih imali i sifru fakture na kojoj se nalaze.Da li bi ovo prestavljalo resenje ?

Auh bre covece, stavljaj malo cesce tacke i zareze .
Inace, odgovor na tvoje pitanje je "dabome".
Slucaj faktura-artikli predstavlja klasicnu situaciju koja se resava relacionom bazom podataka.

 

[Mare]

Uh, kako je moguce da se bavite ovom oblasti a da ne znate resenje ovakve stvari.... ali dobro sve se uci.

Koristite ErWin mnogo ce vam biti lakse da projektujete bazu, ili Rational Rose...

 

[b4b]

Mare, hvala na predavanju ali nije trebalo. Problem je bio sledeci: Imam formu na kojoj je tabela. Vrste su meseci (12), dok su kolone dani (31).

Ispod nje su pitanja vezana za konkretnog coveka. U toj tabeli treba da se belezi kada je on dosao u posetu. Formular mora da izgleda tako. Meni je ideja da to napravim tako sto cu napraviti vise tabela po mesecima.
evo kako izgleda forma. E sad, forma mora da se otvara svaki put kada klijent dodje, i da se unese inicijal radnika u odgovarajuce polje (mesec, dan)

Predlozi?

 

[Mare]

Mare, hvala na predavanju ali nije trebalo. Problem je bio sledeci: Imam formu na kojoj je tabela. Vrste su meseci (12), dok su kolone dani (31).

Ispod nje su pitanja vezana za konkretnog coveka. U toj tabeli treba da se belezi kada je on dosao u posetu. Formular mora da izgleda tako. Meni je ideja da to napravim tako sto cu napraviti vise tabela po mesecima.
evo kako izgleda forma. E sad, forma mora da se otvara svaki put kada klijent dodje, i da se unese inicijal radnika u odgovarajuce polje (mesec, dan)

Predlozi?

Trebalo je (i vise od onoga, mnogo vise, zapravo, sta smeta sto sam napisao neke osnovne stvari?) ali niko ne cita tako da je dzaba inace evo resenja problema (bar ovog dela koji je ovde naveden) u ERWin-u. Naravo mozes odmah u accesu da napravis isto ili da uradis forward engineering. Preko SQL upita resi kako ce izgledati forma, to valjda nije problem.

U principu 3 proste tabele.

 

[b4b]

Hvala na resenju. :wave:
Usput, jel zna neko kako se u accessu (vba) radi sa stringovima? konkretno korisnik treba da unese ime, prezime i datum rodjenja, a da se u tabelu zapamti 1.,3. slovo imena i 1.,3. slovo prezimena?

 

[G-D]

konkretno korisnik treba da unese ime, prezime i datum rodjenja, a da se u tabelu zapamti 1.,3. slovo imena i 1.,3. slovo prezimena?

Koristi funkciju Mid( ). Zajedno sa Left() i Right() predstavlja osnovne funkcije za baratanje stringovima u VB/Access.

 

[b4b]

:wave: Hvala