[es] - Remontovanje železničkih vagona

Zidar
Canada

Moderator
Član broj: 15387
Poruke: 3085
*.dsl.bell.ca.

+79 Profil

^{02.08.2014. u 06:06 - pre 118 meseci}

Ponudjeni modeli su OK, dopunio si osnovni model dodatnim tabelama za cuvanje dodatnih podataka, jako lepa ideja, bravo.

Ima samo jedan previd. Modeli su u stvari isti, iako su zamisljeni kao razliciti. Jedan kao predstavlja specijalizaciju (broj 2), a drugi generalizaciju (broj 1), a u stvari su oba specijalizacija. (Hm, ovo je kao Petar petru Plete petlju...)

Oba modela omogucuju da se za svako novo stanje unesu dodatni podaci u odgovarajuce dodatne tabele (deca tabele PracenjePromenaStanja). Recimo, za stanje 'Vagon' lepo je znati i koji vagon, u kojoj kompoziciji, na kojoj poziciji. Slicno za remont, koji majstor je uradio remont, broj radnog naloga i slicno.

Kad je speciajalizacija u pitanju, dodatni podatak se moze poslati bilo koju tabelu. Kod generalizacije, podatak se mora poslati u tacno odredjenu tabelu. Oba modela dozvoljavaju da se dodatni podatak unese u bilo koju dodatnu tabelu. Kako? Pa nista nas ne sprecava da kas stanje predje u 'Vagon' mi unesemo podatak u 'Remont'. Ili u bilo koju drugu dodatnu tabelu. U stvari, mozemo uneti isti podatak u sve dodatne tabele odjednom. Oba modela to dozvoljavaju, prema tome isti su, bez obzira na razlicite simbole na cvoru odakle se granaju childeren tabele. Probaj pa ces se uveriti i sam.

Sta treba da uradimo da bismo garantovali da se dodatni podaci o svakom novom stanju upisu u tacnu tabelu? Evo sta:
Umesto da iz roditelj tabele PracenjePromenaStanja u 'children' tabele prenesemo PK ( SerijskiBrojOsovine, Godina, TrenutakPrelaza ), prenesimo Super Key (SerijskiBrojOsovine, Godina, TrenutakPrelaza, NovoStanje ). Ovo naravno zahteva da se u children tabelama doda kolona 'NovoStanje', kao i dfa se u roditelj tabli definise Super key. Onda se zada da u svakoj child tabeli kolona Novo Stanje mora imati konstantnu vrednost - koja odgovara onom stanju za koga skupljamo dodatne podatke. Na primer:

Code:
-- Primer: struktura nekih tabela i ogranicenja:

tabela Zaliha: {SerijskiBrojOsovine, Godina, TrenutakPrelaza, NovoStanje, Napomena},
PK = (SerijskiBrojOsovine, Godina, TrenutakPrelaza),
FK = (SerijskiBrojOsovine, Godina, TrenutakPrelaza, NovoStanje)
REF PracenejPromeneStanja (SerijskiBrojOsovine, Godina, TrenutakPrelaza, NovoStanje),
CHECK NovoStanje = 'Zaliha' -- znacenje: u svakom redu NovoStanje = 'Zaliha'

tabela Vagon: {SerijskiBrojOsovine, Godina, TrenutakPrelaza, NovoStanje, Pozicija, Majstor}
PK = (SerijskiBrojOsovine, Godina, TrenutakPrelaza),
FK = (SerijskiBrojOsovine, Godina, TrenutakPrelaza, NovoStanje)
REF PracenejPromeneStanja (SerijskiBrojOsovine, Godina, TrenutakPrelaza, NovoStanje),
CHECK NovoStanje = 'Vagon' -- znacenje: u svakom redu NovoStanje = 'Vagon'

Izgleda neobicno, ali u sustini nema nicega sto je zabranjeno u teoriji. PK ima u child tabelama manje kolona od FK - nigde ne pise da ne sme tako. Koristimo Super Key tebele roditelj umesto PK, da bi napravili vezu sa children tabelama. Takodje nije zabranjeno... Glavni stos je uvodjenej CHECK ogranicenja (Validation Rule za kolonu u Accessu). CHECK zahteva da kolona NovoSTanje bude konstantna i da se samo takve (NovoStanje = const = 'Zaliha' na primer) promene stanja mogu uneti u child tabele. E, kad dodamo extra kolonu u child tabelu, i vezemo je za Super kljuc u roditelj tabeli, onda imamo genralizaciju. Jeste, children tabele su denormalizovane, imaju redundatan podatak, NovoStanje, pa jos konstantna vrednost. Jeste, ali bez toga ne bismo mogli da garantujemo vazno ogranicenje. A kako onda svi kazu 'treba normalizovati do Byce-Codd Normalne Forme (BCNF)'? To vazi za staticke podatke. Ako se prate promene bilo cega, onda nije moguce dostici BCNF a da se ne zanemare vazna ogranicenja.

Medjutim, mislim da je ovo prekomplikovano za postavljaca pitanja. Poceli smo od toga kako se puni i prazni nevezana forma, a dodjosmo do modela baze.

Ko hoce da se bavi naprednim naucnim radom, evo zanimacije:
Kako na primer garantovati da u istoj kompoziciji, u istom danu, na vagonu 7 ne budu dve razlicite osovine na prednjem kraju? Ili da se ogranici da kompozicija ne moze imati vise od N vagona u datom mementu. Ja ne znam tacno kako bi se to izvelo, ali vredi eksperimentisati, ako neko ima vremena.

P.S. nece me biti do sledece srede na forumu.