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

Pitanje u vezi primarnih i spoljnih kljuceva...

[es] :: Baze podataka :: Pitanje u vezi primarnih i spoljnih kljuceva...

[ Pregleda: 4510 | Odgovora: 13 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

Gorex
Srbija

Član broj: 290200
Poruke: 16
*.ptt.rs.



Profil

icon Pitanje u vezi primarnih i spoljnih kljuceva...27.12.2013. u 00:14 - pre 124 meseci
Pozdrav svima,

Zeleo bih da postavim jedno ili vise pitanja :) konkretno okacio sam sliku da bih stvar bila jasnija. Naime pri prevodu u relacioni model, koji je manje
vise sablonski, kad sam prevodio ovaj model u relacioni, pitao sam se sto konkretno u agregaciji "polozio" se agregiraju 3 primarna kljuca,
posto isti posao mozemo da uradimo kada bih napravili spoljne kljuceve tj da svaki od tih kljuceva pokazuje na jedan entitet "student,profesor,predmet"
.Konkretno sama primena vise primarnih kljuceva me buni posto ne znam cemu svrha kada mozemo da upotrebimo spoljne kljuceve(foreign key)
za povezivanje entiteta, a da ti spoljni ukazuju na primarne u istim...Konkretno evo u agregaciji ili bilo kojom vezom vise prema vise posto se
u takvim vezama pravi nova relazija sa spoljnim kljucevima. Nadam se da ce iko razumeti moje pitanje :) Unapred Hvala...




 
Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 6275

Sajt: pedja.supurovic.net


+1570 Profil

icon Re: Pitanje u vezi primarnih i spoljnih kljuceva...27.12.2013. u 11:10 - pre 124 meseci
A sad preformuliši i napiši razumljivo...
 
Odgovor na temu

captPicard
programer
more i planine

Član broj: 216084
Poruke: 1119



+19 Profil

icon Re: Pitanje u vezi primarnih i spoljnih kljuceva...27.12.2013. u 12:11 - pre 124 meseci
Ako sam te dobro shvatio, evo primjer zašto:

Tablica:
Citat:
Radnici
----------
Sifra PK
Poduzece PK
Ime
Prezime


Primjer podataka:
Citat:
1 1 Ivo Ivić
2 1 Pero Perić
1 2 Eva Ević
2 2 Zima Zimić



F
 
Odgovor na temu

dusans
Stojanov Dušan
Pančevo

Član broj: 9551
Poruke: 1343
*.sftl.be.



+311 Profil

icon Re: Pitanje u vezi primarnih i spoljnih kljuceva...27.12.2013. u 13:17 - pre 124 meseci
Tabela Polozio treba da izgleda ovako:

Code:

StudentID
PredmetID
ProfesorID
Datum_isp
Ocena_pred


Kolone StudentID, PredmetID i ProfesorID su ti spoljni kljucevi na tabele.
Ove tri kolone takodje grade primarni kljuc, ali to je primarni kljuc Polozio tabele a ne ovih stranih tabela.
Samo postojanje primarnog kljuca u tabeli Polozio nije neophodno ali je zgodno zbog
same prirode primarnog kljuca - ne dozvoljava duplikat (polozenog ispita).
Ne znam sta ti tu nije jasno i kako/zbog cega bi radio drugacije.

Pozdrav!
 
Odgovor na temu

Gorex
Srbija

Član broj: 290200
Poruke: 16
*.ptt.rs.



Profil

icon Re: Pitanje u vezi primarnih i spoljnih kljuceva...27.12.2013. u 19:04 - pre 124 meseci
Ok, jasno mi sad svrha vise primarnih kljuceva. Ali sad prevod u relacioni bih bio ovakav:
Polozio(StudentID) references Student(StudentID)
Polozio(PredmetID) references Predmet(PredmetID)
Polozio(ProfesotID) references Profesor(ProfesorID)

Da li je ovako? Posto ako imamo ovako nesto:
Code:

Student:
BrDos# | ImePrezime_stud | JMBG | Adresa  | Datum_rodjenja|
1            Pera Peric     1234     Resavska 10.09.1989
2            Jovan Jovic    4432     Resavska 10.09.1990
3            Nikola Nikolic 3213     Resavska 10.09.1991
------------------------------------------------------------------
Profesor:
ProfesorID | ImeProfesora |
1                Aleksandar
2                Petar
3                Jovan
-------------------------------------------------------------------
Predmet:
SifraPredmeta| NazivPredmeta|
1                    Matematika
2                    Programiranje
3                    BazePodataka
-------------------------------------------------------------------
Polozio:
StudentID | PredmetID | ProfesorID | Datum_isp | Ocena_pregled
      1   |       1     |      1   | 23.09.2013|       8
      1   |       2     |      1   | 23.09.2013|       9
      1   |       3     |      1   | 23.09.2013|       7
----------------------------------------------------------------------

Ovde mi sad sistem dozvoljava da napravim ovako nesto. Ali kako da napravim da jedan profesor samo moze da ukazuje na jedan predmet ili na dva ukoliko mozda neki od njih predaje dva :), posto ovde ispada da jedan profesor moze da predaje sve predmete, ovde sam imao 3 predmeta , ali sta ako ih imam 10, mogao bih da stavim da jedan profesor moze da predaje 10 predmeta, kako da napravim da u tabeli "Polozio" ne dozvolim da je ovako nesto moguce , posto mozes da pogresis pri kucanju i da stavis slucajno pogresan Id Predmeta ,Pogresan Id Profesora i da prodje kroz sistem. Kako da se prevazidje ovakav problem? :) Hvala Unapred svima koji pomognu!!!
 
Odgovor na temu

_owl_

Član broj: 318
Poruke: 1043
*.dynamic.sbb.rs.



+3 Profil

icon Re: Pitanje u vezi primarnih i spoljnih kljuceva...27.12.2013. u 19:25 - pre 124 meseci
U modelu koji si dao nema nikakve (dodatne) veze između profesora i predmeta koja bi označavala koje predmete profesor može da predaje.
Owl
 
Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.100.46-69.q9.net.



+79 Profil

icon Re: Pitanje u vezi primarnih i spoljnih kljuceva...02.01.2014. u 15:51 - pre 124 meseci
Citat:
Ok, jasno mi sad svrha vise primarnih kljuceva

Ne radi se o 'vise primarnih kljuceva' nego se u tvom slucaju 'primarni kljuc sastoji od vise kolona' {StudentID, ProfesorID, PredmetId}.

Ima i situacija kad imas vise od jedne kombinacije kolona u tabeli takvih da svaka od njih moze biti primarni kljuc (jedinstveno odredjuje red u tabeli), ali ova tvoja situacija to nije. Evo primer tabele koja ima vise kljuceva (onda ih zovemo alternativni kljucevi). Imas recimo tabelu PeriodniSistemElemenata= {Naziv, RedniBroj, AtomskaTezina}. Svaka od tri kolone jdinstveno odredjuje redove u tabeli. I svaka moze da se proglasi da je primarni kljuc (PRIMARY KEY). Za druge dve koje nismo odabrali za PK, moramo da stavimo UNIQUE CONSTRAINT. PK je samo jedan, proizvoljno izabran kljuc iz skupa alternativnih kljuceva. Ako tabela ima samo jedan kjuc onda je to istovremeno i primarni kljuc. Ako ima vise kljuceva, onda je svejedno koji proglasimo primarnim, svi imaju istu logicku funkciju i podjednako su vazni. Vazna je osobina jedinstvenosti, nije vazno kakao zovemo kljuc.

Da se vratimo na tvoju tabelu,

POLOZIO= {StudentID, PredmetID, ProfesorID, Datum_isp, Ocena_pred}
Potrebno je da definises sledeca ogranicenja:

PRIMARY KEY = {StudentID, PredmetID, ProfesorID};
FK1 : Polozio(StudentID) references Student(StudentID);
FK2 : Polozio(PredmetID) references Predmet(PredmetID);
FK3 : Polozio(ProfesotID) references Profesor(ProfesorID);
CHECK : Ocena_pred>5;

Ovaj CHECK ce spreciti da se uense ocena 5 za studenta koji je polozio ispit, jer su prolazne ocene 6,7,8,9,10 ali ne i 5. Naoko sitnica, ali veoma vazna.

Inace, kad u tekstu definises tabelu treba da navedes 3 stvari:
1. Smisao tabele
2. Zaglavlje tabele
3. Ogranicenja

Ovako bi to bilo u tvom slucaju:
1. Smisao tabele: "Student [StudentID] je polozio ispit iz predmeta [PredmetId] kod profesora [ProfesorID] na dan [Datum_SIp] i dobio ocenu [Ocena_Pred]."

2. Zaglavlje tabele:
POLOZIO= {(StudentID, int) , (PredmetID, int), (ProfesorID, int), (Datum_isp, date), (Ocena_pred, int)}

3. Ogranicenja:
PRIMARY KEY = {StudentID, PredmetID, ProfesorID}
PRIMARY KEY = {StudentID, PredmetID, ProfesorID};
FK1 : Polozio(StudentID) references Student(StudentID);
FK2 : Polozio(PredmetID) references Predmet(PredmetID);
FK3 : Polozio(ProfesotID) references Profesor(ProfesorID);
CHECK : Ocena_pred>5;

Na ovaj nacin si svima koji treba da rede sa tabelom POLOZIO dao strasno mnogo korisnih informacija. Ovo opisivanje tabele definisanjem smisla, zaglavlja i ogranicenja treba da bude sastavni deo dokumntacije. Znaci, u dokumentaciju ide tvoj dijagram objekata i veza, i zatim za svaku tabelu kazes ove tri stvari. Svikoji budu nesto radili sa tvojm bazom bice ti beskrajno zahvalni.





 
Odgovor na temu

Getsbi

Član broj: 124608
Poruke: 2828



+45 Profil

icon Re: Pitanje u vezi primarnih i spoljnih kljuceva...02.01.2014. u 19:44 - pre 124 meseci
@ Zidar
Dobar primer sa tabelom PeriodniSistemElemenata za alternativne ključeve. Dodao bih još pored punog naziva elementa i Simbol.

[Ovu poruku je menjao Getsbi dana 03.01.2014. u 07:19 GMT+1]
 
Odgovor na temu

Gorex
Srbija

Član broj: 290200
Poruke: 16
*.ptt.rs.



Profil

icon Re: Pitanje u vezi primarnih i spoljnih kljuceva...21.01.2014. u 15:25 - pre 123 meseci
Da to je sve ok, tabela polozio je agregacija tj u agregaciji imamo sifru studentid,predmetid i profesorid.
Ali sta ako napisemo ovako:

Code:

Tabela profesor 
1 | Petar|
2 |Mitar |
itd...
Tabela Student
1 |Nikola|
2 |Jovan|
Tabela Predmet
1 |Matematika|
2 |Fizika        |

E sad u tabeli Polozio imamo
SifraS|SifraPre|SifraProf|Datum     |Ocena|
1       |     1    |   1  |01.01.2014| 8 |
1       |     1    |   2  |01.01.2014|10|



E ovde je problem sto u tabeli Polozio imamo da je student pod sifrom 1 polozio predmet pod sifrom 1 kod porfesora pod sifrom 1
datuma 01.01.2014 sa ocenom 8. A sad dole istog studenta, polozio predmet 1 kod drugog profesora 2 istog dana sa ocenom 10
znaci ukoliko je u tabeli
POLOZIO= {(StudentID, int) , (PredmetID, int), (ProfesorID, int), (Datum_isp, date), (Ocena_pred, int)}
PRIMARY KEY = {StudentID, PredmetID, ProfesorID}
Onda mozemo da uradimo ovako nesto kao sto je gore prikazano, zato sto nam je PK= {StudentID, PredmetID, ProfesorID} i konbinaciom kolona dobijamo potpuno novi PK. Sad u realnosti ovo je prakticno nemoguce. Ako bih mogao neko da objasni detaljno ovo...

I samo da pitam kako bih napravili relaciju od kardinalnosti (1,1) <-> (1,1) posto nigde nisam video da je neko pravio relaciju sa
ovom kardinalnoscu. Obicno je to (0,1)<->(1,1)


Izvinjavam se malo kasnim sa porukom imao sam dosta obaveza pa nisam stizao
Unapred hvala...
 
Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.100.46-69.q9.net.



+79 Profil

icon Re: Pitanje u vezi primarnih i spoljnih kljuceva...21.01.2014. u 18:45 - pre 123 meseci
Citat:
..Sad u realnosti ovo je prakticno nemoguce...

Ako je realnost takva da je nemoguce da jedn student polaze isti ispit kod dva profesora, onda tvoje relacije treba tu realnost verno da predstave.
Mislim da ti nedostaje nekoliko relacija:

Predikat Profesor [SifraProf] predaje predmet [SifraPred] ima relaciju definisanu ovako;
ProfesorPredmet:{SifraProf, SifraPred}, PK :{SifraProf, SifraPred},
Relacija ProfesorPredmet dozvoljavaa vise profesora predaje isti predmet.

Student slusa jedna predmet kod tacno jednog profesora (realnost o kojoj pricamo). Predikat bi bio:
Student [SifraStud] slusa predmet [SifraPred] kod profesora [SifraProf] , sto daje relaciju:
StudentSlusaPredmete = {SifraStud, SifraProf, SIfraPred},
PRIMARY KEY {SifraStud, SifraPred} -> svaki ispit student slusa tacno jednom
FOREIGN KEY (SifraProf, SifraPred) REFERENCES ProfesorPredmet(SifraProf, SifraPred) -> ispist slusa samo kod onog profesora koji taj ispit i predaje (vise profesora moze da predjae isti ispit, ali je samo jedan od njih dodeljen nasem studentu)


Ako hoces da kazes "Student moze da polozi ispit tacno jednom" onda brises profesora iz relacije Polozio, ovako:
POLOZIO= {(StudentID, int) , (PredmetID, int), (Datum_isp, date), (Ocena_pred, int)}
PRIMARY KEY = {StudentID, PredmetID}
FOREIGN KEY (StudentID, PredmetID) REFERENCES StudentSlusaPredmete (SifraStud, SIfraPred)

Na osnovu relacije POLOZIO znamo da je student polozio ispit [SifraIsp]. Iz relacije "StudentSlusaPredmete " znamo da predmet [SIfraPred] studentu predaje profesor [SifraProf], posto student slusa (i polaze) ispit samo kod jednog profesora.


Citat:
I samo da pitam kako bih napravili relaciju od kardinalnosti (1,1) <-> (1,1) posto nigde nisam video da je neko pravio relaciju sa
ovom kardinalnoscu. Obicno je to (0,1)<->(1,1)


Malo si nezgrapno napisao kardinalnosti. Pise se
1 : (0,1) = jedan prema nula ili jedan (postoji u tabeli "roditelj" ali ne mora da psotoji u tabeli "dete"
1 : 1 jedan prema jedan

1:1 imas na primer ako imas relacije
Radnici: { [SifarRadnika],[Ime],[Prezime],[DatumRodjanja]} PK (SifraRadnika)
i
Plate { [SifarRadnika], [Plata]} PK (SifraRadnika)

1:1 je logicki uslov. Fizicki, danasnji RDBM sistemi ne pruzaju mogucnost da se to izvede. Radnik prvo mora da postoji u tabeli Radnici, pa mu se onda dodeljuje plata. Ako je uslov da ne sme da bude ni jedan radnik u tabeli Radnici koji nema platu, onda se mogu spojiti relacije Radnici i Plate, ovako:
Radnici: { [SifarRadnika],[Ime],[Prezime],[DatumRodjanja],[Plata]}

Medjutim, razlog za razdvajanje relacija jest poverljivost podataka - ne zelimo da svi koji imaju pravo d avide tabelu Radnici vide i njihove plate. U praksi se obicno razdvoje tabele, aonda se zabrani pisanje (INSERT) direktno u tabelu Radnici. Zatim se napravi stored procedure kojoj se posalju parametri (@SifarRadnika,@Ime,@Prezime,@DatumRodjanja,@Plata} pa procedura odradi u jednoj transakciji

BEGIN TRANSACTION
INSERT INTO Radnici (@SifarRadnika,@Ime,@Prezime,@DatumRodjanja
ISERT INTO Plate (@SifarRadnika, @Plata)
COMMIT

Naravno da onaj ko treba da unosi podatke u tabele dobije pravo da izvrsava stored procedure.

Druga opcija je da se cuva plata u tabeli radnici, i da se svima zabrani citanje iz te tabele. Onda se naprave views, jedan koji pokazuje plate, drugi koji ne pokazuje, pa se daju permissions na views onima koji smeju da vide jedno ili drugo.




 
Odgovor na temu

Gorex
Srbija

Član broj: 290200
Poruke: 16
*.ptt.rs.



Profil

icon Re: Pitanje u vezi primarnih i spoljnih kljuceva...22.01.2014. u 13:10 - pre 123 meseci


Prijatelju, prvo da ti se zahvalim na odgovorima, vidi se da zelis da pomognes i na tome ti hvala!!!
Ako treba sta da se plati nije problem

Samo da se vratim na ovaj primer...

Ovde su PK ujedno i FK posto referenciraju na profesora i na predmet jel tako?
Citat:
Predikat Profesor [SifraProf] predaje predmet [SifraPred] ima relaciju definisanu ovako;
ProfesorPredmet:{SifraProf, SifraPred}, PK :{SifraProf, SifraPred},
Relacija ProfesorPredmet dozvoljavaa vise profesora predaje isti predmet.




Da li ovde SifraStud ujedno i FK posto mi deluje da nije povezan s tabelom student jel sam u pravu ili gresim?

Citat:
Student slusa jedna predmet kod tacno jednog profesora (realnost o kojoj pricamo). Predikat bi bio:
Student [SifraStud] slusa predmet [SifraPred] kod profesora [SifraProf] , sto daje relaciju:
StudentSlusaPredmete = {SifraStud, SifraProf, SIfraPred},
PRIMARY KEY {SifraStud, SifraPred} -> svaki ispit student slusa tacno jednom
FOREIGN KEY (SifraProf, SifraPred) REFERENCES ProfesorPredmet(SifraProf, SifraPred) -> ispist slusa samo kod onog profesora koji taj ispit i predaje (vise profesora moze da predjae isti ispit, ali je samo jedan od njih dodeljen nasem studentu)


A sad sve sam ovo stavio na papir i povezao na kraju opet slican problem

Code:

TabelaProf
SifraProf|Ime|Prezime|
  1       |Pera|Peric|
  2       |Mika|Mikic|
  3       |Steva|Stevic|
---------------------------------
TAbelaPredmet
SifraPred|NazivP|
   1      |Matematika|
   2      |Fizika    |
   3      |Hemija    |
----------------------------------
ProfesorPredmet
SifraProf|SifraPred|
    1       |      1    |
    1       |      2    |
    2       |      2    |
    2       |      3    |
    3       |      1    |
----------------------------------
Student
SifraStud|ImePrezime|
      1     |Nikola_Nikolc|
      2     |Ana_Anicic   |
      3     |Jovan_Jovic  |
-----------------------------------
E sad kod slusa predmet mislim da imamo slican problem
SlusaPredmet
SifraStud|SifraProf|SifraPred|
      1     |      1     |      1     |
      1     |      3     |      2     |
------------------------------------
SifraProf ovde nije PK tako da mozemo da stavimo u tabeli da bude ovako. Opet bih u sistemu doslo do mesanja podataka
SifraProf 3 u tapeli ProfesorPredmet predaje predmet pod sifrom 1, a ovde imamo sifru predmeta 2.
Zar onda ne bih bilo bolje da smo u trabeli ProfesorPredmet dodali jos jedan kljuc SifraPP koji bih bio PK i u tabeli SlusaPredmet 
imali bi samo SifruStud i SifruPP gde  ta sifra referencira tabelu ProfesorPredmet. Sta vi mislite o tome?


Unapred svima hvala koji izdvoje svoje dragoceno vreme i pomognu!!!
 
Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.100.46-69.q9.net.



+79 Profil

icon Re: Pitanje u vezi primarnih i spoljnih kljuceva...23.01.2014. u 14:59 - pre 123 meseci
Pitanje:
Citat:
Opet bih u sistemu doslo do mesanja podataka
SifraProf 3 u tapeli ProfesorPredmet predaje predmet pod sifrom 1, a ovde imamo sifru predmeta 2.



Odgovor:
Ovako smo definisali relaciju StudentSlusaPredmete:
Code:

StudentSlusaPredmete = {SifraStud, SifraProf, SIfraPred}, 
PRIMARY KEY {SifraStud, SifraPred} -> svaki ispit student slusa tacno jednom
FOREIGN KEY (SifraProf, SifraPred) REFERENCES ProfesorPredmet(SifraProf, SifraPred) 

Primeti FOREIGN KEY. FK ne dozvoljava da se studentu dodeli kombinacija (SifraProf, SifraPred) koja ne postoji u relaciji ProfesorPredmet.
Stoga nije moguce da bilo kom studentu dodelis kombinaciju Profesor = 3 Predmet = 2 ako takva kombinacija ne postoji u relaciji ProfesorPredmet. Znaci, FK sprecava da dodje do 'mesanja podataka'
 
Odgovor na temu

Getsbi

Član broj: 124608
Poruke: 2828



+45 Profil

icon Re: Pitanje u vezi primarnih i spoljnih kljuceva...24.01.2014. u 06:04 - pre 123 meseci
Citat:
Zidar...
Code:

StudentSlusaPredmete = {SifraStud, SifraProf, SIfraPred}, 
PRIMARY KEY {SifraStud, SifraPred} -> svaki ispit student slusa tacno jednom
FOREIGN KEY (SifraProf, SifraPred) REFERENCES ProfesorPredmet(SifraProf, SifraPred) 

....


Poslovno pravilo, tvrdnja ili iskaz: "svaki ispit student slusa tacno jednom", važi za dobre studente. U Evropi je mahom zastupljena Bolonjska deklaracija. Insistira se na nekoj vrsti aktivnosti u nastavi kroz prikupljanje predispitnih obaveza. Ukoliko student ne položi ispit (pet ispitnih rokova u školskoj godini), obavezan je dogodine da ponovo sluša isti predmet.

Znači, PK je suviše krut i ne odgovara realnosti. Trebalo bi uvesti atribut "SkolskaGodina". Druga stvar je ako je ovo samo teoretski primer.
 
Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.100.46-69.q9.net.



+79 Profil

icon Re: Pitanje u vezi primarnih i spoljnih kljuceva...24.01.2014. u 19:44 - pre 123 meseci
Getsbi je u pravu, naravno da student moze da polaze isti ispit vise puta, stoga cela prica vazi za jednu konkretnu godinu.
Medjutim, kako pokretac teme nije naveo nikakve pocetne uslove, niti opis problema koji se resava, slobodni smo da pretpostavimo sta god hocemo

To sto nismo dobili nikakav opis problema koji se resava niti ogranicenja, veci je problem nego sto se predpostavlja. Ljudi jednostavno nekako naprave E-R dijagram i to je to - sva dokumentacija. Primetite da u poslednje vreme insistiram da se umesto gledanja u tabelu navede predikat koji tabela predstavlja. Desilo se u ovom primeru da smo naveli predikat "Student [SifraStud] kod profesora [SifraProf] slusa ispit [SIfraPred]" uz ogranicenje "svaki student moze da slusa ispit tacno jednom". Ispalo je da ogranicenje mozda nije dobro postavljeno.

Znaci, kada pricamo o shemi baze podataka, treba navesti:
a) opis problema koji se resava
b) recenice koje povezuju entitete - na osnovu kojih smo nacrtali E-R dijagram

Za SVAKU tabelu (relaciju) u bazi treba navesti:
c) predikate koji definisu tabelu (relaciju)
d) ogranicenja koja se na svaku tabelu (relaciju) - FK,PK,UNIQUE, CHECK ili ih bar iskazati recima govornog jezika.

Tek posle toga mozemo da pricamo o E-R dijagramu i mozda normaliziaciji. Sama tabela, bez predikata i ogranicenja ne daje dovoljno ulaznih podatka da bi se o njoj ozbiljno diskutovalo.

U svakom slucaju, svrha posta je bila da objasnimo zasto ne mozemo da studentu dodelimo profesora i predmet ako taj profesor ne predaje dati predmet.

 
Odgovor na temu

[es] :: Baze podataka :: Pitanje u vezi primarnih i spoljnih kljuceva...

[ Pregleda: 4510 | Odgovora: 13 ] > FB > Twit

Postavi temu Odgovori

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