[ burce @ 06.04.2009. 16:53 ] @
moze li mi neko pomoci ?


problem: imam tabelu "osoba" koja treba sadrzati, izmedju ostalog i podatke o roditelju(majka, otac) date osobe , a roditelj takodje mora pripadati tabeli "osoba". kako ovo realizovati a da se ne narusi ref integritet, da li je potrebno koristiti neka ogranicenja pri realizaciji ili autoreferencijalni integritet? Primer tabele: osoba (jmbg(pk),<ostali atributi>)


resenje mozete predstaviti u vidu ERmodela,SQL-a ili relacije. Ja sam pocetnik, pa bi mi ova pomoc dobro dosla, hvala unapred. Pozzz
[ momsab @ 06.04.2009. 17:29 ] @
za PK ja bih stavio neki autoID, JMBG je ipak veliki broj
sto se roditelja tice, mozes da probas sa dve veze OSOBA <-> OSOBA npr (2 spoljna kljuca su u stvari primarni kljuc odredjenih osoba)

Code:
OSOBA (ID {pk}, JMBG {unique},.... majka {fk-OSOBA}, otac {fk-OSOBA})


tako nekako, jes' da ovo gore nije napisano po propisu ali valjda kontas sta sam napisao
[ burce @ 06.04.2009. 19:35 ] @
mislis da uzmem da mi se ovaj pk iz tabele OSOBA prostire kao strani kljuc u istoj tabeli dva puta (za oca i majku), tj da referencira na istu tabelu OSOBA?
[ momsab @ 06.04.2009. 19:50 ] @
da, ukratko receno

moraces da postavis ogranicenje (u bazi ili aplikaciji koja sa njom radi) da dete ne moze biti starije od roditelja
[ burce @ 06.04.2009. 20:28 ] @
hvala na odg ...

I jos jedno pitanje : kako bi otprilike izgledao deo SQL upita u kome bi postavio to ogranicenje i jos neka (da majka mora da je zenskog pola, otac muskog)? gde tacno treba da navedem to ogranicenje unutar CREATE TABLE naredbe ili u nekom triggeru koji ce se pokretati pre insertovanja?
[ Zidar @ 06.04.2009. 20:51 ] @
je li tabela zadata da tako izgleda ili ti pokusavas da je napravis nekako?
[ burce @ 06.04.2009. 21:03 ] @
ja pokusavam da je napravim nekako a da ne narusim referencijalni integritet i normalne forme, pa mi je ovaj nacin pao na pamet, rado prihvatam svaki ispravan i jednostavniji nacin. Realni sistem je u stvari maticna sluzba i u okviru projekta (u pitanju je seminarski rad) mi je potrebno da izradim bazu podataka koja bi funkcionisala na principima poslovanja maticne sluzbe, pa mi je zapelo kod tebele OSOBA koja bi trebala sadrzati podatke o roditeljima koji, ako se ne varam, moraju biti takodje iz tabele OSOBA da ne bi doslo do redudanse.
[ Zidar @ 06.04.2009. 21:36 ] @
Probaj da definises uslove integriteta, ali logicno, pusti teoriju. Evo pretpostavki:
1) Dete je osoba.
2) Dete ima dva roditelja, koji su takodje osobe.
3) Majka je roditelj zenskog pola.
4) Otac je roditelj muskog pola.
5) Roditelji moraju biti stariji od deteta.
6) Roditelji moraju biti uneseni u tabelu, pre nego sto se dodele detetu

Ovi uslovi u praksi ne bi prosli, ali su za seminarski sasvim dovoljni.

CREATE TABLE Osobe (ID int, Pol varchar(1), Majka int, Otac int, DatumRodjejna DateTime)

Potrebni CONSTRAINTS:
ID = PRIMARY KEY, nema razloga da to ne bude maticni broj, ali nema veze, neka je samo UNIQUE a potrebe zadatka

FK_Majka: moze biti bilo koji ID koji postoji u tabeli i da je zenskog pola i da je ID(majka) > ID(Osoba)

FK_Otac: moze biti bilo koji ID koji vec postoji u tabeli i da je muskog pola i da je ID(Otac) > ID (osoba)

U oba slucaja imas self-referencing, ali po dve kolone - ID i Pol. Pokusaj sam da napravis FK, pokazi nam dkle si stigao, pa cemo pomagati ako bas zapne.

U praksi, dete bi moglo da ima dva, jednog ili ni jednog roditelja (podaci nepoznati, beba nadjena u korpi ispred opstinskih vrata i slicno). Takodje, nije dovoljno reci da roditelji budu stariji od deteta. Mora postojati neka razumna bioloska razlika u godinama, recimo 12 godina ili nesto slicno (ovo se jako tesko odredjuje i u praksi)
Dalje, JMBG je sasvim dobar PK. To je uvedeno pre 40 godina i valjda do danas svi imaju taj broj i broj mora da je jedinstven. Ako ga svi imaju i jedinstven je - eto ga PK. To sto bi mozda integer bio 'brzi' i uzeo 'manje prostora' ostavi za DB administartora da misli. Ti postavljas logicki model. JMBG sadrzi u sebi i datum rodjenja pa se lako uspostavlja kontrola unosa datuma rodjenja. Lose bi bilo reci 'ako imam JMBG ne treba mi datum rodjenja' jer bi se greskom mogao uneti ispravan JMBG, ali koji pripada nekom drugom, poznatom ili nepoznatom. Postojanje oba podatka, datum rodjenja i JMBG smanjuje verovatnocu greske.



[ burce @ 07.04.2009. 02:32 ] @
hvala Zidar, predlozio si mi jos neka od ogranicenja koja mi nisu pala na pamet :), mislim da je ovo sto si naveo dovoljno za seminarski, samo jos da ga prevedem u SQL sintaksu. stavio sam da mi je id autoinc da bi mogao da kontrolisem redosled unosa (roditelji unesen pre deteta).

probao sam da resim ovaj problem pomocu CHECK klazule u CONSTRAINT-u , medjutim, u MySQL-ovom manuelu sam saznao da nije podrzana u MySQL-u, u kojem treba da mi je baza :( , da li postoji neka druga alternativa da realizujem ovo , osim preko triggera koji ce se pokretati pre unosa ?
[ Zidar @ 07.04.2009. 14:40 ] @
Ne mogu da ti pomognem oko MySQL, ali sigurno ima ko moze. Vazno je da imas logiku, ostalo je tehnika. Neki od uslova se mogu resiti kao CHECK, neki kao FOREIGN KEY, a neki traze triger - sve zavisi od sistema koji koristis.

Srecan rad