Citat:
bakasoka:
Citat:
JMBG - najbolje da zaboraviš da tako nešto postoji.
Znam za to, u realnosti i praksi, ali u školskim zadacima insistiraju da se, ako je to moguće, jedno polje tabele (ili više polja) identifikuje kao Primary key...(ne znam zašto, pretpostavljam da je to da se pokaže da smo shvatili da PK mora biti jedinstvena vrednost...)
U svari je sam stvar vremena kada će ti postati problem to što ti je neko polje koje ima značenje PK. Bolje je za PK uvesti polje bez značenja, na primer autoincrement.
Svako polje koje ima značenje kad tad može da promeni značenje (ili vrednost) a menjanje vrednosti PK je nešto što ne treba da se radi.
Gledaj to ovako: svaka tabela ima primarni ključ i prirodni ključ. Svrha primarnog ključa je da jedinstveno identifikuje jedan slog tabele i samo to. Prirodni ključ takođe jedinstveno identifikuje jedan slog tabela li sam ključ ima i neko značenje, predstavlja neko svojstvo entiteta opisanog u slogu.
Primarni ključ i prirodni ključ mogu da budu isti ali je bolje da je primarni ključ bezznačenjski (pomenti autoinkrement). To ti omogućava da u bilo kom trenutku možeš da menjaš prirodni ključ tabele ali inegritet baze nećeš narušiti jer su tabele u relaicjama preko primarnog ključa, koji, pošto nema nikakvo značenje, praktično ikad nećeš morati da menjaš.
Na primer u tabeli klijent (usput dobar je običaj da se tabele nazivaju u množini jer sadrže više entiteta iste vrste) imaš poilje Klijent_JMBG koje ima ulogu primarnog ključa a ujedno je i prirodni ključ. Bolje je da uvedeš novo polje ID koje je autoinkrement i da ono postane PK, a da polje Klijent_JMBG bude samo Unique (čime se obezbeđuje da je i ono jednoznačno). AK bi se nakad desilo da drava odluči da sredi loš sistem JMBG i počne da menja JMBG, bazi to neće smetati, jer JMBG nije PK i možeš slobodno da ga menjaš.
U stvari, prirodni ključ može biti i složen i obuhvatati više polja, što tek nije dobro da se koristi i za Primarni ključ. Primarni ključ treba da bude jedno polje (mada ne mora) jer to MNOGO olakšava rad sa bazom. Složeni PK je recept za ogromne komplikacije. Čim u tabeli imaš složen prirodni ključ, to je znak d atreba odmah d auvedeš posebno namensko polje za PK da izbegneš da ti taj složeni ključ bude primarni. U svom primeru imaš par tabela u bazi koje su upravo takve i koje prosto vište da dobiju polje ID koje je autoinkrement i koje je PK.
Ako usvojiš ovo sa uvođenjem polja koje se zove ID, nema značenje i služi samo kao PK, to prvilo možeš da uvedeš na sve tabele jer ti na svakoj treba PK. Ako to uradiš, kasnije u razvoju aplikacije koja radi sa bazom možeš napraviti razne automatske mehanizme koji će lako raditi sa svakom tabelom jer će znati da svaka tabela ima polje ID koje je primarni ključ.
Citat:
Citat:
Recimo, iz dijagrama, potencijalni kupac se interesuje samo za autora ali ne i za konkretno delo. Zašto tamo nema datuma - recimo potencijalni kupac se interesuje za više dela, pa onda promeni mišljenje. U tvojoj bazi je večito zainteresovan samo za neke autore. Kako zamišljaš da obavestiš potencijalnog kupca da imaš nešto da mu ponudiš? Recimo imaš od autora X 3 slike, ali kupac nije zainteresovan ni za jednu od njih, nego za neke druge slike od istog autora koje ti planiraš da otkupiš.
Ta tabela je informativnog karaktera, ti u svakom slučaju kupcima nudiš sve što imaš, ali je dobro znati (ima ljudi koji stvarno kupuju samo Janoša Mesaroša...šta god da je naslikano).
Planiram da bazu implementiram u C#-u, pa sam mislila da mi na formi izađe interesovanje nekog klijenta, ukoliko specifično postoji...ta informacija može da stoji i u napomeni tabele Klijenti (ali ovako bih imala i pregled sveukupnih interesovanja klijenata, pa bi vlasnik galerije znao šta je traženo i šta da juri)...ako se interesovanje klijenta promeni, jednostavno ga promeniš i u svojoj bazi...
Citat:
Kupovina i prodaja treba da budu jedna tabela. Treba ti neki status dela (kod dobavljača, kod kupca, u galeriji...).
Molim te da mi ovo malo pojasniš, ako nije problem...Zašto kupovina i prodaja treba da budu jedna tabela?
Ne moraju da budu jedna tabela li u tvomslučaju nema razloga da ne budu jer obe tabel imaju potuno istu strukturu samo im se naziv razlikuje.
Da krenemo od kupaca, dobavljača, klijenata... tu ti imaš više tabela i nepotrebno si zakomplikovala. Kupac, dobavljaš, klijent, šta god, sve se to može svesti na isto: id, naziv (ime), adresni podaci, kontakt podaci. Dobro je da ti svi oni budu u istoj tabeli jer se zaista radi o potpuno istim podacima. Postoji samo razliku tipu (kupac, dobavljac, klijent).
Još ako kažeš dapostoji mogućnost da isti entitet može d abude i u svojstvu kupca i dobavljač ai klienta to samo upućuje da svi moraju biti u sitoj tabeli a to da li je neko kupac, dobavljač ili klijent treba da se naznači nekim svojstvom tabele, jer nema nikakvog smisla da iste podatke moraš da unosiš u više tabela smao zato što je neko i kupac i dobavljaš i klijent ili šta već. To sve treba da se unese u jednu tabelu.
Ja bih recimo uveo ili tri logička polja kao identifikatore kupac, dobavljač i klijent pa ako neko spada u datu grupu njemu staviš logičku jedinicu. Tako isti entitet može biti u više tih grupa. Mana tog pristupa je da, ako ti se pojavi četvrti tip, odna moraš da menjaš strukturu tabele. Ako to očekuješ onda ti treba tabela sa listom tipova i jedna M-N tabela za vezu kontakta sa tipovima. Ako ti treba pojasnjenje te strukture, reci.
Ako svaki tip ima neka specifična svojstva onda to možeš rešiti kao što si već delom i rešavala: uvedeš dodatne tabele za ta svojstva i povežeš ih 1-1 vezom sa osnovnom tabelom za kontakte.
Kad sko kod specifičnosti ti si opred tabele dobavljač uvela dve tabele za fizička i pravna lica jer si pravilno prepoznala specifična svosjtva za te tipove entiteta. Međutim, ovo kako si uradili je nepraktično. Jednostanvije je da u tabeli dobavljaci uvedeš polja Naziv1 i Naziv2 pa da se popunjavaju prema potrebi - negde ime i prezime, negde naziv ili šta već.
Ovo kako si ti napavila JESTE BOLJE, ali zahteva da aplikacija zna da se sa tim pozabavi tkaoda ne moraš da pravi posebno pregled fizickih a posebno pravnih lica vec da mozes sve da ih vidis kao jednu tabelu (jer oni suu paogramu svi dobavljaci, da li su fizicka ili pravnalica, manje je važno). Moguće je raditi ovako kakosi ti planirala i u ozbiljnijim apliakcijama se tako i radi, ali mislim da je to previse komplikovano za nivo apliakcije koju ti planiras da uradis.
Citat:
Citat:
Grafike su vrlo slične slikama samo što ih može biti više, recimo serija od 50 komada.
Slažem se da, ali nije isto da li kupiš Autorski otisak ili prvi ili 50-ti...nije ista cena, ni kvalitet otiska i moraju zasebno da se vode.
Ipak, realno je da ako ima više kopija istog dela, da imaš neku vezu između njih čak i ako ih vodiš kao sasvim zasebna dela. Za očekivati je da ako imaš 50 kopija iste grafike ne prikazuješ to kao 50 dela nego kao jedno delo u 50 kopija. Zamisli da na osnovu ove baze praviš web shop i da treba da prikažeš sliek svih dela koja su u ponudi. Šta bi ti rekli posetioci sajta ako bi morali da listaju tri strane sliak jednog te istog dela zato što ima 50 kopija?
Ja bih u bazi predvideo da pod novim ID evidentiram samo različito delo. Znači ako imaš autorski otisak to je jedno deloa ako imaš kopiju tog autorskog otiska to je drugo delo (i opet terba da postoji veza između njih da bi neko kome je možda original preskup video da može jeftinije da kupi kopiju). Ali ako imaš 50 kopija, onda je to sve jedno te isto, vodi se pod istim ID samo se vodi i količina.
Čim si pomenula autorsko delo i kopiju, eto ti još jednog svojstva koje treba da imaš u tabeli dela, da možeš da razlikuješ autorska dela od kopija.
Citat:
Citat:
Tabela tehnika, potpuno bez veze. Izgleda da si je stavio samo da popuniš normu po broju tabela. Ako je vezana za samo jedno delo i ima samo jedan prikaz dela, zašto ta dva polja nisu deo tabele delo. Ako si hteo da pokažeš da znaš normalizaciju, nisi uspeo. Ima nekog smisla da napraviš šifarnik tehnika (ulje na platnu, pastel, ...) pa da onda u delo staviš id tehnike, ali prikaz dela nema smisla sklanjati iz tabele delo.
Moja ideja je bila sledeća:
TblTehnika: je slabi objekat tabele delo, može biti Ulje, Akvarel, Crtež, Pastel,Grafika, Kombinovana, a čitala sam savete da je bolje Prikaz dela (sliku(fotografiju)),odnosno putanju do fajla u kojem se nalazi fotografija, odvojiti u zasebnu tabelu u bazi..
Ako jedno delo može da bude rašeno samo jednm tehnikom onda ovo kako si napravila nema smisla. Dovoljno je da tabela tehnika sadrži popis mogućih tehnika a da se u tabeli Delo u namensko polje upisuje kojom tehnikom je rađeno to delo.
Ako pak može da se desi da je jedno delo rađeno sa više tehnika, tabela tehnika treba opet da sadrži samo popis mogućih tehnika a da uvedeš novu tabelu za M:N vezu kojom bi dela povezivala sa primenjenim tehnikama. U stvari ova tvoaj tabela tehnika je po strukturi ta MN tabela a fali ti tabela sa listom svih tehnika.