Zadatak koji imas je takve vrste da se to ne radi na molbu i drugarski a ponajmanje je dobar za ucenje, jer je kompleksan. Nije problem resiti sve zahteve koje imas, samo sto je to prilicno obiman posao.

Zadatak ti i nije baš jednostavan, ali nedavno je bila tema "Teorija vs. praksa" (ne ona top tema,
koja ima slično ime, nego druga). Tu se radilo o sportskim timovima, igračima, sudijama i utakmicama...
Nije baš isto, ali možda ti pomogne.

Pozdrav,

slažem se sa brokerom, ako je komerzijalizacija u pitanju i oko kompleksnosti.

Dalje, mislim da lica, bilo da su sudije, tužioci, advokati, ..., uopšte ne treba identifikovati na osnovu JMBG broja nego, dodeliti im neki ID, koji će biti jedinstven.

Kroz prava pristupa će se dodeliti koji sudija ima pravo kojim podacima, a moglo bi na osnovu tog ID broja i broja predmeta, odnosno, sudija pristupa onim predmetima koji su mu dodeljeni.

Za modelovanje baze, pretpostavljam da znaš, bitna je ispravna normalizacija, odnosno, uočiti prave entitete i enitete poveznike, izvršiti je do kraja i na taj način, izbeći probleme koji mogu nastati kasnije, recimo redudansa, ...
Koliko vidim, može biti više baznih tabela iz kojih će se stvarati relacije.

BTW, pogledaj ...

Da li si ti isti covek koji je pre godinu dana pitao ovo:
http://www.elitesecurity.org/t142542-0#930361

,ili ovo:
http://www.elitesecurity.org/t151326-0#987641

Brzo napredujes ;)

Hvala, trudim se, a i fax mi pomaže.

Hvala vam svima, a najviše tebi loshmiscg, mislim da je to upravo ono što mi treba. Jedino sada ne stignem sve pogledati jer sam na poslu.

Nadam se da ću uskoro i ja moći nekome da vratim uslugu. Stvarno mi je drago da sam postao član ovog foruma.

Ako još ko ima kakvu ideju, savjet ili prijedlog uvijek mi je dobrodošao.

Zašto? JMBG je sasvim dobar kandidat za ključ. Ako se isti JMBG javlja na više mesta, to će biti u različitim relacijama i onda nema problema.

@Fanta: Bilo bi dobro da napraviš bazu i da onda sa njom eksperimentišeš, postavljaš upite koji su ti potrebni, tako ćeš najbolje videti šta mora da se menja, dodaje i slično.

Po meni, dizajniranje baze podataka je umetnost, svaki umetnik to može odraditi na svoj način i da on bude relevantan.
JMBG može biti dobar kandidat za ključ jer je jedinstven za svako lice, ali ima trinaest cifara i po mom iskustvu bolje je taj identifikator svesti na što manji broj.

U praksi sam nailazio na situacije da za lice upišu validan JMBG(ispravan), Ime, Prezime, ..., ali da ustvari to nije JMBG za to lice, jednostavno, desi se greška, gužva, potrebno je brzo odraditi unos, ... Znači, dobije se Ime i Prezime, ali netačan JMBG broj. Ovako, na osnovu jedinstvenog identifikatora dobijemo podatke o npr. licu gde vidimo i JMBG i ostale generalije, tad ukoliko neki podaci nisu ispravni mogu se izmeniti.

Primer:
recimo, bankarski šalterski radnici nemaju vremena da proveraju JMBG, pa se desi previd, recimo
umesto 2606985856589 upišu 2607985856589, Ime, Prezime, ... Šta se desi, sledeći put kad dođe to
lice i kad ga trži na osnovu JMBG -a desi se greška. Da bi se to izbeglo uvodi se broj kreditne
kartice, npr., koji može biti isti ili manji broj (po ciframa).
Kao i normalizacija, tako i identifikatore treba svesti na što jednostavniji nivo, što može biti olakšica u stvaranju relacija.

Možda nisam u pravu i, ako nisam, voleo bih da mi to neko i kaže, jer, tad ću naučiti nešto što nisam znao.
Hvala unapred.

@loshmiscg
U pravu si da je jmbg prilicno dugacak, ali ni broj kreditne kartice nije mnogo kraci - mislim da je 8 ili 13 karaktera 8 ako pravno ili fizicko lice ima maticni broj, a 13 ako fizicko lice nema maticni broj. Plus kontrolni broj i plus sifra banke.


Neki ID bi odradio coveku posao.
Pozdrav

Slažem se, dodeli se neki ID lica na osnovu kojeg dobijemo informacije o generalijama, da li je fizičko ili pravno lice, kontrolni broj, šifra banke, broj žiro računa, stanje, etc.

Možda u tim kompleksnim sistemima, a i manjim, sistem sam dodeljuje ID licu, automatski, tako da se ne može desiti greška kao sa unosom JMBG. Službenik unosi samo ostale generalije, između ostalih i JMBG. Pa, čak ako je došlo do greške u generalijama taj automatski dodeljeni ID je validan identifikator lica i kad se uoči greška, lako se izmeni i ne utiče na podatke koji su već uneti u bazu.

Kao što si rekao, postoji više ispravnih načina, tako da nije pitanje da li si u pravu ili nisi, već se radi o finesama. Osim ovoga što si naveo, stoji i argument da ako se već uvode veštački identifikatori, dobra je praksa da se onda koriste svuda zarad konzistentnosti.

Stranac može biti učesnik u sporu ali on nema JMBG.

Zbog toga bi moglo napraviti jednu baznu tabelu, npr. Stranke, gde će postojati atribut kao jedinstveni identifikator lica (UNIQUE), Ime, Prezime, JMBG, ...

Iz tog entiteta bi mogle nastati tabele Sudije, Advokati, ..., gde bi taj jedinstveni identifikator iz entiteta Stranke u ovim entitetima postao spoljašnji ključ, čime bi se obezbedio referencijalni integritet.
Zato što advokati, sudije, etc., ujedno mogu biti i stranke u nekim sporovima, a na taj način bi se izbegla redudansa.

Pretpostavimo da svaki advokat iz advokatske komore ima neku svoju "licencu" i broj, pa bi entitet Advokati mogao ovako izgledati: ID_Advokata, ID_Stranke, ... Tad bi atributi ID_Advokata, ID_Stranke predstavljali složeni ključ, s tim što ID_Stranke je spoljašnji ključ koji referencira entitetu Stranke.
ID_Advokata, ID_Stranke bi se mogao postaviti i kao UNIQUE, jer advokat može imati samo jedan svoj identifikacioni broj koji ga identifikuje u advokatskoj komori. Znači, samo jedan slog za tog advokata, jer u principu advokat ne može imati dve licence, samo pretpostavka.

BTW, ako je stranac, verovatno ima svoj JMBG koji je napravljen po "zakonu" iz te države, ako se poklapa sa "naših" trinaest cifara, mogao bi se upisati. Ako ne, verovatno stranca možemo identifikovati na osnovu podataka iz pasoša. Tako da se entitetu Stranke može i dodati neka alternativa za JMBG, recimo broj pasoša, etc.

Predpostavljam da si ovde hteo da kazes da se ID_Advokata moze postaviti kao UNIQE (i usput NOT NULL), odnosno da je ID_Advokata kljuc.

Tada po definiciji par atributa (ID_Advokata, ID_Stranke) ne moze biti kljuc!

Ovako predlozena tabela 'Advokati' ima dva kandidata za kljuc i to su zasebno ID_Advokata i zasebno ID_Stranke.

Ovakav model tabela Advokati i Stranke nije dobar za modelovanje pocetnog problema jer:
- Foreign key izmedju tabela Advokati i Stranke se na ovaj nacin tumaci: Advokat je specijalna stranka.
- Cinjenica iz posta pocetnog problema je da stranka moze biti:
1. tuzilac,
2. tuzeni.
Dakle: Advokat nije stranka!, pa nemamo ni relaciju (foreign key) izmedju tabela Advokati i Stranke sa tumacenjem '... JE ... '




<sub>[Ovu poruku je menjao chachka dana 07.11.2006. u 00:04 GMT+1]

[Ovu poruku je menjao chachka dana 07.11.2006. u 00:04 GMT+1]</sub>

@chachka
Hvala što si se ubacio sa svojim argumentima.

Da, ID_Advokata da bude UNIQUE NOT NULL.

U redu, prihvatam argument i slažem se s njim, prevideo sam, izvinjavam se na netačnosti.

OK, samo za primer sam uzeo ADVOKATI i STRANKE, nisam ulazio u navedeni pocetni post, nego samo sam hteo prikazati referencijalni integritet. Može se to odraditi sa enitetima STRANKA - PREDMETI!?!
(id_BrojPredmeta,Tužilac,Tuženi,OdvjetnikTužioca,OdvjetnikTuženoga,Sudac)
Tuzilac - referencira ka entitetu STRANKA preko ID_Stranke;
Tuzeni - referencira ka entitetu STRANKA preko ID_Stranke;
Advokat tuzioca - referencira ka entitetu ADVOKATI preko ID_Advokata;
Advokat tuzenoga - referencira ka entitetu ADVOKATI preko ID_Advokata;
Sudija - referencira ka entitetu SUDIJE preko ID_Sudije;

Da li će u tom slučaju doći do redudanse podataka, odnosno, ako hipotetički pretpostavimo da advokat je u nekom sporu stranka i ima svog zastupnika? Dakle, isti podaci iz entiteta ADVOKAT bi se unosili u entitet STRANKA!?!

Pozdrav.

Pravo je kompleksno područje, ništa nije crno bijelo, možda ste i u pravu, možda je to i komplicirano za mene, ali na takvim stvarima sam se uvijek i naučio raditi, jeste da me je tražilo vremena, ali nakon toga su mi mnoge druge stvari bilo jednostavnije. Samo što sam ovaj put se izgubio u potpunosti u tome i lutam kao u magli

Da pojasnim još neke stvari:

-U predmetu stranka može imati advokata, ali isto tako može i zastupati samoga sebe, bez advokata.
-Sličan je slučaj i sa advokatima, samo što on može biti zaveden kao stranka, ali ujedno i da zastupa samoga sebe (isto se odnosi i na sudiju)

Isto tako loshmiscg nedostaju ti i umiješaći, koji kao što sam rekao znaju se pojaviti na strani tuženoga ili tužitelja,koja je točno njihova uloga baš ni ja ne kužim(raspitaću se), osim što mogu biti s jedne ili s druge strane. A umiješaći mogu biti stranke, mogu biti advokati (da li ih sud tretira kao stranke ili advokate, to ni meni još nije jasno, raspitacu se i za to, pa cu vam javiti), a isto tako u početnom postu sam stavio da čak i oni mogu,doduše veoma rijetko, unajmiti svog advokata.

Ali iskreno čitajući vašu prethodnu temu koju je postavio Zidar(nisam još došao do kraja) shvatio sam neke stvari(još jednput hvala loshmiscg).

A i kad sam vidio još načine na koje sve zapisujete na papir, kako podatke veze i relacije obrađujete i o njima razmišljate, shvatio sam i da sam ja još uvijek veliki amater i da još imam puno toga za naučiti, ali zato smo ovdje zar ne?

Nisi rekao sta tu smatras kljucem.
1. Ako je kljuc samo id_BrojaPredmeta, onda se ne pokrivaju sledec stvari:
- U jednom predmetu moze biti vize tuzilaca
- U jednom predmetu moze biti vise tuzenika
- Jednog tuzioc moze zastupati vise odvjetnika
- Jednog tuzenika moze zastupati vise odvjetnika
- Na jednom predmetu moze raditi vise sudaca
- ...?
2. Ako je kljuc kombinacija vise polja, onda gornji entitet nije ni u 2NF.




Stranka JE osoba.
Sudac JE osoba.
Odvjetnik JE osoba.
Umijesac JE osoba. (Svedok?)

Ovu listu atributa, (id_BrojPredmeta,Tužilac,Tuženi,OdvjetnikTužioca,OdvjetnikTuženoga,Sudac), sam preuzeo od Fante, nisam je sam kreirao.

(Id_BrojPremeta,DatumPodnošenjaTužbe,PredmetSpora,Tužilac,Tuženi,OdvjetnikTužioca,OdvjetnikTuženoga,Sudac)!?!
Hipotetički, rastavio bih:
# - Primary key
$ - Foreign Key

entitet PREDMET (#Id_BrojPremeta,DatumPodnošenjaTužbe,PredmetSpora,$Sudac(ID_Sudija))
#Id_BrojPremeta (UNIQUE NOT NULL),
$Sudac - mogućnost suđenja u drugim sporovima

entitet PREDMET_UCESNICI (#Id_BrojPremeta, #$Tužilac(ID_Stranka), #$Tuženi(ID_Stranka), #$OdvjetnikTužioca(ID_Advokat), #$OdvjetnikTuženoga(ID_Advokat))
#Id_BrojPremeta = može biti više aktera predmeta - stranaka, advokata ( ne UNIQUE )
//evidentira se više učesnika predmeta, ali ne dozvoljava se dupliranje sloga

Dalje, trebalo bi možda ubaciti i jednu tabelu gde bi se vodila evidencija ročišta (#Id_BrojPremeta,#RB_rocista, Datum_Rocista, ishod, ..., šta već treba), gde bi se ročište identifikovalo spram #Id_BrojPremeta,#RB_rocista!?!

@chachka
Komentar !?!


Izgleda da ipak i nije tako loš primer za učenje.

u tome i je problem.

poanta svega je upravo to da je glavni Id svega Id_predmeta ili laički rečeno jedan sudski spis, ne postoje dva spiska sa istom oznakom koja se sastoji od kombinacije od slova brojeva, npr. Pr 43725/08 (lupio sam napamet, ali otprilike tako izgleda) i oko se njega sve vrti.

Naše pravosuđe ja jako poznato po svojoj brzini, gdje procesi znaju trajati i po 10-20 godina, a kao što sam rekao sve je moguće da se događa (stranka umre(tužilac ili tuženi), a ako je npr. imovina u pitanju uvijek ima njegov zakonski nasljednik), stranka može promijeniti koliko god želi advokata ako smatra da mu prethodni nije dovoljno bio brz ili ništa nije poduzeo (mogu vam slobodno reči da advokati u stvarnosti namjerno odugovlače postupke i poduzimaju radnje koje su nepotrebne kako bi što više naplatili, ali to je tema za drugi post), može se promijeniti sudac (u slučaju smrti, porodiljskog,...),....

Npr. kad se zada kao query samo da se ispišu svi podaci koji su vezani uz spis pod tim i tim brojem, on će ispisati sve, apsolutno sve što je bilo vezano uz taj slučaj sva događanja i osobe,vrijeme i radnje koje su bile poduzete u postupku

Mozda je rano da se vec prave tabele i razgovara o kljucevima. Zasto ne opises proces koji baza mora da podrzi. Mozad isplivaju neke vasne stvari koje bi smanjile konfuziju? Na primer, ceo proces be se mogao opisati ovako:

1) Tuzitelj podnosi tuzbu sudu protiv nekog optuzenog. Tako pocinej sudski proces.
2) Sud sudskom procesu dodeljuje jednog sudiju, da zapocne proces i da ga vodi do daljnjega (dok sud ne promeni sudiju)
3) Tuzitelj i Optuzeni su dve stranke u procesu. Stranke na znaci dve osobe, i tuzitelj i tuzeni mogu biti grupe ljudi, u svakoj mogucoj kombinaciji (pojedinac tuzi pojednca, grupa tuzi pojedinca, pojedinac tuzi grupu, grupa tuzi grupu)
4) Svaka stranka u procesu moze imati jednog ili vise advokata, a ne mora ni jednog. to bi bio specijalan slucaj, fiktivni advokat, 'sam sebi advokat'.
5) Tokom procesa advokati se mogu dodavati strankama ili skidati sa slucaja.

Iz ovoga ja vidim veoma bazan entitet 'Sudski proces', koji ima svoj evidencioni broj, datum pocetka, i imace na kraju datum zavrsetka i nekakvo resenje.

U sudskom procesu ucestvuju stranke, u dve uloge. Ovo starsno ukazuje na odnos
"Sudski proces" : Stranke = 1 : vise to jest 1 : 2 (tacno dve starnke, tuitelj i tuzeni) Malo nize objasnicemo detalje.

Sudskom procesu se dodeljuju sudije. Ne znam da li moze biti vise od jednog sudije na procesu istovremeno, ili vise sudija radi u razlicitim nepreklapajucim vremenskim intervalima. Kako god, opet 1 proces ima vise sudija.

Svaka stranka u procesu (ima ih tacno dve, tuzeni i tuzitelj) je predstavljena jednom ili vise osoba ili pravnih lica. I svako lice koje cini stranku moze imati jednog ili vise ili nijednog advokata.

Eto ti gomila mogucih relacija.

Ako smem da primetim, formalno ovo lici na problem sportske lige. Utakmica odovara sudskom procesu. Tuzitelj i tuzeni odgovaraju domacem i gostujucem timu. Ako je stranka u stvari grupa pojedinaca, eto vam igraca u timovima. Ako je decija liga, za svakog igraca pratimo ko su mu roditelji/staraoci/predstavnici - neko ko u ime igraca donosi odluke. U ovom slucaju advokati odgovaraju roditeljima/staraocima. Sudije su sudije u oba slucaja. U raznim sportovima ima od jednog do N sudija, koji mogu imati razlicite uloge. Bas kao i u sudstvu. Ovo naravno ne znaci ni slucajno da treba uzeti model sportske lige i samo preimenovati tabele. Iz modela sportske lige treba pozajmiti, ako odgovara, neke lepe nacine za odrzavanje referencijalnog integriteta i to je sve.

Da li imati tabelu Osobe, pa osobe dodeljivati sudijama, advokatima, strankama? Cini se privlacno, da bismo ustedeli kod cuvanja adresa i generalija. Ali, ako ima vise adresa u pitanju, stvari se toliko komplikuju kasnije da je bolje imati adrese i genralije za advokate, isto to za stranke. Pa makar morali da sve to prepisemo ako neko iz kategorije Advokat postene Tuzeni. Mozda advokat pod jednom adresom radi kao advokat (adresa kancelarije), a pod drugom adresom kao tuzeni (kucna adresa). Moja preporuka, iz iskustva je da je ipak boje drzati odvojene skupove tabela, baska advokati, baska tuzeni, pa ko je neko na obadva mesta, neka bude na obadva mesta. to s ene desava toliko cesto da se ne bi moglo odrzavati. Ovo ej samo preporuka, neko drugi moze da ima drugacije iskustvo narano i drugaciji ukus.

:-)

Zidar, čak i pravnik se je sa tobom u potpunosti složio i rekao da si sve shvatio.

Imaš pravo jako je slično modelu sportske lige, probaću ga primjeniti na ovaj način. A isto tako vidim da je red da sjednem i sve zapišem. Samo ne znam na koji model od sportske lige mislis, koliko znam trojica kolega sa foruma su dala primjere, koji je najbolje primjeniti u ovom slučaju???

Želio sam poslati poslati i 3 slike primjera što sam nabrzinu napravio večeras prije nego što sam pročitao Zidarev post, ali vidim da to tako ne ide. Ujedno sam vas htio zamoliti da pogledate i reknete mi gdje sam pogriješio jer na greškama se uči. Ali sad sam primjetio da ne mogu slati nikakve slike ni atacmente. Budući iskreno da nisam pročitao pravila foruma pretpostavljam da moram doći do određenog broja poruka.

A ujedno je vijest da moram ubaciti i umiješača, napokon sam dobio pojašnjenje tko je on i kakva je njegova uloga. Mislio sam staviti attachment o umiješaću, ali ne mogu. Uglavnom on je isto tako uloga koja se mora pojaviti, ali isto kao i advokat nije obavezan. Kratko objašnjenje bi bilo:

UMJEŠAČ

Osoba A – TUŽITELJ
Osoba B – TUŽENI
Osoba C- UMJEŠAČ

Uzmimo primjer: prometna nezgoda

Osoba A = onaj koji je nastradao u prometnoj nezgodi
Osoba B = osiguravajuće društvo
Osoba C = onaj koji je skrivio prometnu nezgodu

Osoba A tužila je osobu B (osiguravajuće društvo) za isplatu svote od 5.000,00€ na ime štete nastale na njegovom automobilu, a iz razloga što ga je u zadnji kraj udarila osoba C svojim autom. Osoba C plaća premiju i osiguranik je osobe B.
Osoba B nije željela platiti zato što je svota bila previsoka, a i osoba C je bila pijana dok je vozila.
U parnici su, dakle stranke tužitelj- osoba A i tuženi osoba-B.
U slučaju da osoba A uspije u sporu, osoba B može novom tužbom (u novom sudskom postupku) tužiti osobu C da joj vrati sve novce koje je isplatila osobi A.
Zato u procesu koji vode osoba A i B, osoba B zove osobu C da uđe u parnicu kao UMJEŠAĆ, zajedno sa osobom B, jer i osobi C je u interesu da osoba A ne pobijedi u suđenju, kako ne bi osoba B mogla od nje potraživati isplatu onoga što je morala dati osobi A.

Ispričavam se, jer znam da nije tome ovdje mjesto, ali i ja sam puno toga novoga naučio od vas,pa nadam se i vi nešto od mene.

Hvala na komplimetnima. drago mi je da sam razumeo bar delimicno kako funkcionise sudstvo ;-)
Kako rekoh:
To bi bio i kraj moje umesanosti u problem. Kako rekose kolege ranije, amterija je veoma specificna, i pozeljno je poznavati i materiju i racunarskid eo na visokom nivou da bi se dobilo dobro resenje. Ja bar pola od toga ne posedujem pa bi smo se samo zapetljali nepotrebno i napravili vise stete nego koristi ako se upustimo u dlaju raspravu.

Srecan rad