Kad se modeluje baza, neophodno je pre toga uočiti sve entitete, entitete poveznike i korektno izvršiti normalizaciju. Da ne teorišem previše, možeš kreirati tabele šifarnike koje će sadržati, npr., dva atributa(id(PK),naziv) i u tabele poveznike ćeš spram potrebe vršiti evidenciju tih šifri, gde može i nastati složeni primarni ključ.
Npr:
# - Primary Key
$ - Foreign Key
Kontinent(#id_kontitnet, naziv_kont)
Države(#id_države, #$id_kontinent, naziv_drž) - predpostvka da dve države mogu imati isti naziv na različitim kontinentima (možda i ne postoji!?!), a id_kontinent referencira ka svojoj baznoj tabeli "Kontinent".
Rasa(#id_rasa, naziv_rase)

Tabela poveznik između njih bi mogla izgledati ovako:
Psi(#$id_države, #$id_rasa)

Dakle, složeni ključ se sastoji iz dva atributa koja istovremeno referencijaju ka svojim baznim tabelama, tj. šifarnicima, možeš uočiti da nismo stavili atribut id_kontinent, jer on već referencira u tabeli "Države", iz prostog razloga da ne bi došlo do redudanse. Tu možeš napraviti upit (ugnježdeni ili prirodno spajanje) na osnovu kojeg ćeš dobiti određen set podataka sa nazivom rase, nazivom kontinenta i nazivom države.

Istina je da će se upit brže izvršiti ako se spajanje vrši po atributu koji je numeričkog tipa, sa manje karaktera, nego neki string koji ima npr. 20 karaktera.

BTW, ne znam da li je primer dobar da ti da odgovor na tvoje pitanje s obzirom da sam nabrzinu odgovorio, ali verujem da ako nije već će neko kompetentan reagovati.

Mene upravo ovo zanima. Jos kad bih pronasao negde da je ovo zapisano 'crno na belo', u nekoj knjizi pa da idem ;) ...

Relaciona shema bi bila nekako ovako:

[att_img]

(gde god se vidi, na nekoliko mesta: opis, naziv, vrsta, ... moglo b da se uzme za PK, ali ja sam ipak odabrah NUMERICKI ID)

Upit bi bio otprilike ovako:

Ako radis na SQL Serveru prvo sto ces uociti na BOL kada budes citao o relacijama (kandidatima za PK, FK) je da stavis sto je moguce manje polje, jer sto je manje polje brze je izvrsavanje. Ovo mozes i sam testirati nad par tabela. Ja sam svojevemeno uporedjivao performance GUID i int kao IDENTITY i razlike su znacajne bile u korist obicnog int. Idealno bi bilo kada bi radio samo sa prirodnim 'kljucevima' ali problem koji nastaje sa njima je sto prirodni kljucevi niti su nekad kratki, niti su iz jednog 'polja', pa zato u praksi je teze raditi sa njima (valjda ce jednog dana RDBMS proizvodjaci skontati da relacije ne treba da se mapiraju na polja nego na entitete, a sam tip tih relacija interno sam RDBMS da vodi). Otiso ja malo u off topic :)
Nego kod tog dizajna koji si odlucio ja bi najpre utvrdio kog obima ce se koristiti taj program i koliko podataka ce se skladistiti, jer iako su nazivi dugacki, ako su podaci u tabelama reda par hiljada, mislim da se u vecini 'osrednjih' upita nece toliko osetiti to ubrzanje sa char na int, tj. veorvatno u benchmarku hoce ali u realnom radu, najveci bottleneck su komunikacija sa bazom i prosledjivanje podataka front endu. I za kraj jedino sto bi te savetovao je da ako vec stavis int autonumber za PK, onda dodelis indexe i nazivima.

PS. Kakav to program pravis? Zanimljivo da me je upravo jedan drug zamolio da mu namestim jedan program za kategorizaciju pasa, posto mu je potreban prilikom izlozbe pasa.

Hvala na objasnjenu. Indekse jesam dodelio i nazivima.

Gledajuci dijagram, ne vidim da si nesto lose logicki uradio, deluje OK.

Jedan predlog imam, ako nije kasno. Budi kosistentan u imenovanju atributa. Na primer, u nekoliko tabela imas atribut 'Broj'. kTo je verovatno neki broj 'rekorda' (autonumber?). Sta tu ne valja?

U tabeli Grupa, imas polje 'Broj' i to ti je PK. U redu, ako samo ovu tabelu posmatras.
U tabeli sekcija, ima spolje 'Broj' koje nije ni u kakvoj vezi sa Grupa.Broj. Imas zatim vezu Sekcija.Grupa_ID = Grupa.Broj
Zar nije bilo lakse da u tabeli Grupa, odmah kazes 'Grupa_ID'? Ovako, Grupa_ID je Grupa_ID svuda osim u maticnoj tabeli.

Isto i za atribut koji zoves ID u maticnim tabelama - Region.ID = druge_tabele.Region_ID, Rasa.Id = druge_tabele.Rasa_ID

Toplo preporucujem da se atributi koji se migriraju u druge tabele zovu isto u SVIM tabelama.

I koristi JOIN operator umesto WHERE. WHERE sluzi da se postavi uslov, a ne da se povezu dve tabele (mada moze). Za povezivanje tabela sluzi JOIN. Razlog? Ako bas nista drugo, onda jasnoca pisanja i razumevanje 'koda'

Ako ne radis u Accessu, malo formatiranja ne bi skodilo, na primer ovako:

Ne, nije kasno. Model koji sam prikazao je tek jedna skica.


Ovo je dobar savet. Promenicu svakako. Slazem se da treba stvoriti naviku da se stekne stil imenovanja atributa.


Takodje dobar savet. Da budem iskren, kako i ne radim nista profesionalno sa bazama podataka nisam ni znao kako se
JOIN koristi, ovako imam neku sliku, pa cu istraziti u tom pravcu.


Primer sam upravo testirao u Accessu (bio mi je pri ruci), i on je formatizovao po svome, a ja sam samo odradio neki lagani
copy&paste uz malo dorade.

Hvala za upit! Koristice mi svakako.