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

Višestruke relacije

[es] :: Baze podataka :: Višestruke relacije

Strane: 1 2

[ Pregleda: 5377 | Odgovora: 22 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

Fanta
Fanta Genije

Član broj: 119794
Poruke: 118
*.cmu.carnet.hr.



Profil

icon Višestruke relacije05.11.2006. u 18:40 - pre 212 meseci
Poštovanje svima!

Već neko vrijeme se bavim mysql i php-om i sve što sam do sada radio je bilo prilično jednostavno, ali sada sam naišao na problem, barem je meni, jer već tri tjedna razbijam glavu kako ga riješiti, crtam razne šeme tablica i relacija, ali nikako da nađem neko riješenje. Možda nekome bude i moj problem jako lagan pa ću mu biti stvarno zahvalan na pomoći, a ako postoji već slična tema gdje bih mogao naći riješenje ispričavam se, ali bih i dalje bih bio zahvalan na odgovoru ili ideji.

O čemu se radi? Dobio sam nedavno molbu da sastavim bazu za simulaciju za pravo koja bi trebala izgledati sljedeće.

TablicaPredmet(Id_BrojPremeta,DatumPodnošenjaTužbe,PredmetSpora)
TablicaStranka(Id_Stranke(JMBG),Ime,Prezime,Adresa,...)
TablicaOdvjetnik(Id_Odvjetnika(registracujska oznaka u advokatskoj komori),Ime,Prezime,Adresa,...)
TablicaSudac(Id_Sudac(registracijska oznaka suca),Ime,Prezime,Adresa,...)

Ovo je jednostavno naizgled, ali onda nastaju problemi mi među relacijama,a radi se o sljedećima:

Za stranku:
-jedna stranka može u predmetu imati dvostruku ulogu: 1. Tužilac, a 2. Tuženi(osoba koja se brani)
-može imati ulogu umiješaća u sporu,tj predmetu na bilo kojoj strani, bilo na strani tužioca,bilo na strani tuženoga, a čak i umiješać može,ali doduše veoma rijetko angažirati odvjetnika ili sam umješać može biti odvjetnik(ne znam da li da njih stavim u posebnu tablicu?)
-može imati više predmeta, tj suditi se u više sporova
-može više stranaka biti kao tužitelj ili kao tuženi (branjeni) u predmetu
-moguće ja da se više stranka nađe kao tužioc ili kao tuženi(više osoba se brani)
-moguće je da tužioc i tuženi imaju svako po jednog odvjetnika, ali ih isto tako mogu imati i više
-moguće je da tužioc ili tuženi promijene odvjetnika i to više puta (potrebno je znati s kojim datumom je poceo novi odvjetnik, a s kojim je stari završio)
-moguće je da se na strani tužitelja ili tuženoga promijeni strana, (npr. fizička osoba u sporu umre u postoji potraživanje prema njenoj imovini, pa se tuže dalje nasljednici) i potrebno je znati s kojim datumom je došlo do promijene, a stari podaci moraju ostati

Za odvjetnika:
-u nekom predmetu isti odvjetnik može biti na strani tužitelja, u nekom drugom predmetu može biti na strani tuženoga
-može imati više predmeta(sporova) na jednom sudu
-može zastupati jednu, ali i više osoba u predmetu

Za suca:
-jedan sudac može imati više sporova
-više sudaca može biti na jednom sporu

Ono oko čega se sve vrti je TablicaPredmet, tj. točnije Id_BrojPredmeta jer to sve može biti u jednom predmetu na sudu.

Ne znam ni sam kako da se postavim u ovome: prvo sam mislio da napravim zajednička polja kao što bi bila (id_BrojPredmeta,Tužilac,Tuženi(iz TabliceStranka),OdvjetnikTužioca,OdvjetnikTuženoga(iz tabliceOdvjetnik),Sudac), ali to bi bilo samo za jednu osobu u svakom slučaju, što kada je više njih?

Zatim sam pomislio da sve osobe stavim kao TablicuStranka, a napravim TablicuUloga (tužilac,tuženi,sudac,odvjetniktužitelja,odvjetniktuženoga,umiješać tužitelja, umiješać tuženoga) i povežem ih sve skupa 3 tablice (tablicaPredmet,tablicaStranka,tablicaUloga) tj. u jednu tablicu, TablicaPovezano (idBrojPredmeta,idStranke,idUloga). Međutim problem nastaje u tome što je bi svima oznaka indetiteta bila JMBG, ali isto tako sudac ili odvjetnik se može naći kao stranka u postupku, tj. kao tužilac ili tuženi. Problem je i u tome što se tiče prava sigurnosti jer stranke i odvjetnici imaju samo pravo gledati podatke, a sudac ima pravo da ih mijenja i unosi. Tako da sudac ne može otići u predmet drugog suca, gdje je tužen kao stranka i mijenjati podatke kako želi.

Od ova dva načina ovaj drugi mi se čini najispravniji ili možda postoji bolji?

Ako imte još kakva pitanja ili nejasnoća vezana uz moj problem samo pitajte.

Baza na kojoj radim je MySQL, tip tablica sam stavio innoDB, a alat u kojem radim je DBDesigner 4

 
Odgovor na temu

broker

Član broj: 2415
Poruke: 8514
212.62.59.*



+11 Profil

icon Re: Višestruke relacije06.11.2006. u 09:24 - pre 212 meseci
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.
 
Odgovor na temu

delalt

Član broj: 68360
Poruke: 198
*.teol.net.



Profil

icon Re: Višestruke relacije06.11.2006. u 11:01 - pre 212 meseci
Citat:
Fanta:... Možda nekome bude i moj problem jako lagan pa ću mu biti stvarno zahvalan na pomoći, a ako postoji već slična tema gdje bih mogao naći riješenje ispričavam se, ali bih i dalje bih bio zahvalan na odgovoru ili ideji.

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.
 
Odgovor na temu

Miloš Baić
Miloš Baić
ERP (Dynamics NAV) programer
Beograd

Član broj: 72468
Poruke: 1155
*.kalik.info.



Profil

icon Re: Višestruke relacije06.11.2006. u 11:19 - pre 212 meseci
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 ...
Someone's sitting in the shade today because someone planted a tree a long time ago.
 
Odgovor na temu

goranvuc
Goran Vucicevic
Novi Sad

Član broj: 4934
Poruke: 1846
*.dialup.neobee.net.



+41 Profil

icon Re: Višestruke relacije06.11.2006. u 11:25 - pre 212 meseci
Citat:
loshmiscg: 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 ;)
 
Odgovor na temu

Miloš Baić
Miloš Baić
ERP (Dynamics NAV) programer
Beograd

Član broj: 72468
Poruke: 1155
*.kalik.info.



Profil

icon Re: Višestruke relacije06.11.2006. u 11:56 - pre 212 meseci
Citat:
goranvuc:
Brzo napredujes ;)

Hvala, trudim se, a i fax mi pomaže.
Someone's sitting in the shade today because someone planted a tree a long time ago.
 
Odgovor na temu

Fanta
Fanta Genije

Član broj: 119794
Poruke: 118
193.24.251.*



Profil

icon Re: Višestruke relacije06.11.2006. u 12:17 - pre 212 meseci
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.
 
Odgovor na temu

Alter Ego
null
Pančevo

Član broj: 1880
Poruke: 453
*.vdial.verat.net.

Sajt: www.tridenet.com


Profil

icon Re: Višestruke relacije06.11.2006. u 14:31 - pre 212 meseci
Citat:
loshmiscg:
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.


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.
 
Odgovor na temu

Miloš Baić
Miloš Baić
ERP (Dynamics NAV) programer
Beograd

Član broj: 72468
Poruke: 1155
*.kalik.info.



Profil

icon Re: Višestruke relacije06.11.2006. u 15:27 - pre 212 meseci
Citat:
Alter Ego: 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.

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.
Someone's sitting in the shade today because someone planted a tree a long time ago.
 
Odgovor na temu

aleksandarpopov
IT consultant
Senta

Član broj: 57172
Poruke: 484
*.sksyu.net.

Sajt: www.linkedin.com/in/aleks..


Profil

icon Re: Višestruke relacije06.11.2006. u 15:54 - pre 212 meseci
@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
RTFM
 
Odgovor na temu

Miloš Baić
Miloš Baić
ERP (Dynamics NAV) programer
Beograd

Član broj: 72468
Poruke: 1155
*.kalik.info.



Profil

icon Re: Višestruke relacije06.11.2006. u 16:17 - pre 212 meseci
Citat:
aleksandarpopov: ...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.

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.
Someone's sitting in the shade today because someone planted a tree a long time ago.
 
Odgovor na temu

Alter Ego
null
Pančevo

Član broj: 1880
Poruke: 453
*.vdial.verat.net.

Sajt: www.tridenet.com


Profil

icon Re: Višestruke relacije06.11.2006. u 16:22 - pre 212 meseci
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.
 
Odgovor na temu

mkaras
Marko Karas
Beograd

Član broj: 66087
Poruke: 427



+19 Profil

icon Re: Višestruke relacije06.11.2006. u 16:53 - pre 212 meseci
Stranac može biti učesnik u sporu ali on nema JMBG.
 
Odgovor na temu

Miloš Baić
Miloš Baić
ERP (Dynamics NAV) programer
Beograd

Član broj: 72468
Poruke: 1155
*.kalik.info.



Profil

icon Re: Višestruke relacije06.11.2006. u 21:43 - pre 212 meseci
Citat:
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.
Someone's sitting in the shade today because someone planted a tree a long time ago.
 
Odgovor na temu

chachka
Srđan Mijatov
Programer
BUS Computers
Kikinda

Član broj: 53780
Poruke: 576
*.dialup.neobee.net.

Sajt: www.baze-podataka.net


+4 Profil

icon Re: Višestruke relacije06.11.2006. u 22:53 - pre 212 meseci
Citat:
loshmiscg: ID_Advokata, ID_Stranke bi se mogao postaviti i kao UNIQUE, jer ...

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 ... '




[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]
"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming."
- Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo
 
Odgovor na temu

Miloš Baić
Miloš Baić
ERP (Dynamics NAV) programer
Beograd

Član broj: 72468
Poruke: 1155
*.kalik.info.



Profil

icon Re: Višestruke relacije07.11.2006. u 10:58 - pre 212 meseci
@chachka
Hvala što si se ubacio sa svojim argumentima.
Citat:
: 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.

Da, ID_Advokata da bude UNIQUE NOT NULL.
Citat:
Tada po definiciji par atributa (ID_Advokata, ID_Stranke) ne moze biti kljuc!

U redu, prihvatam argument i slažem se s njim, prevideo sam, izvinjavam se na netačnosti.
Citat:
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.

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;
Citat:
Dakle: Advokat nije stranka!, pa nemamo ni relaciju (foreign key) izmedju tabela Advokati i Stranke sa tumacenjem '... JE ... '

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.
Someone's sitting in the shade today because someone planted a tree a long time ago.
 
Odgovor na temu

Fanta
Fanta Genije

Član broj: 119794
Poruke: 118
193.24.251.*



Profil

icon Re: Višestruke relacije07.11.2006. u 12:36 - pre 212 meseci
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?

 
Odgovor na temu

chachka
Srđan Mijatov
Programer
BUS Computers
Kikinda

Član broj: 53780
Poruke: 576
*.suonline.net.

Sajt: www.baze-podataka.net


+4 Profil

icon Re: Višestruke relacije07.11.2006. u 12:39 - pre 212 meseci
Citat:
loshmiscg: (id_BrojPredmeta,Tužilac,Tuženi,OdvjetnikTužioca,OdvjetnikTuženoga,Sudac)

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.



Citat:
loshmiscg: 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!?!

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


"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming."
- Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo
 
Odgovor na temu

Miloš Baić
Miloš Baić
ERP (Dynamics NAV) programer
Beograd

Član broj: 72468
Poruke: 1155
*.kalik.info.



Profil

icon Re: Višestruke relacije07.11.2006. u 13:13 - pre 212 meseci
Ovu listu atributa, (id_BrojPredmeta,Tužilac,Tuženi,OdvjetnikTužioca,OdvjetnikTuženoga,Sudac), sam preuzeo od Fante, nisam je sam kreirao.
Citat:
chachkaAko je kljuc kombinacija vise polja, onda gornji entitet nije ni u 2NF

(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 !?!

Citat:
broker:primer je ponajmanje dobar za ucenje

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


Someone's sitting in the shade today because someone planted a tree a long time ago.
 
Odgovor na temu

Fanta
Fanta Genije

Član broj: 119794
Poruke: 118
193.24.251.*



Profil

icon Re: Višestruke relacije07.11.2006. u 13:31 - pre 212 meseci
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
 
Odgovor na temu

[es] :: Baze podataka :: Višestruke relacije

Strane: 1 2

[ Pregleda: 5377 | Odgovora: 22 ] > FB > Twit

Postavi temu Odgovori

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