Kreiranje baze podataka za katastar (zemljisna knjiga)

Ovo je problem koji vucem od samog pocetka rada u Access bazama.
Kako napraviti relacionu bazu koja ce moci da primi sve podatke o gradjevinskim objektima, katastarskim parcelama na kojima se grade, a kasnije nastavljaju svoj 'zivot' kao tacne adrese sa nazivom ulice, kucnim brojem, dodatkom kucnog broja (slovne i druge oznake u adresi) i naravno o 'deci' takvog gradj. objekta ( stanovi, lokali, zajednicki prostori itd.)
Na pr:
1.Gradjevinska parcela ( u nastavku GP) nastaje od NN broj katastarskih parcela ( u nastavku KP)
2.Jedna GP moze da obuhvati vise gradjevinskih objekata (u nastavku GO)
3.Jedan GO moze imati vise lamela, a moze biti i bez lamele!
4.Jedan GO mora imati makar jedan ulaz, a moze ih biti vise.
5.Ukoliko GO ima lamelu, jedna lamela mora imati makar jedan ulaz, a moze ih imati i vise.
Kada je GO sagradjen, definisan po lamelama (ako postoje) i ulazima, svaki ulaz dobija Resenje o kucnom broju, koje definise sledece:
Sifru ulice, Naziv ulice, Kucni broj, Dodatak kucnom broju, mesnu zajednicu, opstinu, grad.
Ovakva baza bi trebalo da 'primi' podatke kako o postojecim objektima (znaci one se tacnom adresom), tako i podatke o objektima u izgradnji. Objekti u izgradnji se oznacavaju projektnim oznakama.
Znaci, ako je objekat GP (na vrhu ove 'piramide') recimo grad Beograd, kako izvesti tranziciju jednog gradjevinskog objekta kroz bazu tako da dobijem nesto kao:
Makedonska 4a, stan 7.
Da napomenem da je vazno znati da se uglavnom velike GP skoro uvek rade fazno, pa tako se moze dogoditi da u prvoj fazi dobijemo dva, tri ili vise objekata sa tacnom adresom, a da su ostali objekti jos na nivou neke gradjevisnske oznake na navedenoj GP.
Ovo je klasican problem 'roditelj-dete', ali sa malim ali bitnim odstupanjima.
Jedan od pristupa je da u svakoj 'dete' tabeli, ponavljam sve kolone njenog 'roditelja', a zatim upisujem pripadajuce podatke, ali to onda nije relaciona baza gde pamtim samo kljuc tabele 'roditelj'.
Sem toga, poslednja tabela bi imala kolona koliko zbir svih kolona iz prethodnih tabela.
Ne znam da li se neko od vas bavio ovim problemom, a svaki predlog je vise nego dobrodosao.

U polje pretraga ukucaj reč hijerarhija i pročitaj tih nekoliko tema. Verujem da ćeš doći do rešenja.

Potpis

https://mzahorjanski.wixsite.com/mzahorjanski
https://www.fiverr.com/miroljubzahorja?up_rollout=true
https://www.youtube.com/@miroljubzahorjanski

Uhhhhhh...

Vas problem je najmanje problem "rada u Access bazama"...

Problem s kojim ste se uhvatili u kostac je vise problem realnog sistema u kojem zivimo. Zatim zadire u normativnu regulativu i to na vise nivoa nadleznosti. Ako to prevedemo na nas informaticki jezik, osnovu svih problema cini ne postojanje prostorne identifikacije. Eto pomenuli ste pojam "ADRESA". Ne postoji na nivou drzave Srbije jedinstveni adresni sitem. Nesto je Posta radila za svoje potrebe (PAK), ali oni su gledali da resavaju svoj problem, sto je normalno. Da ne bih duzio susretao sam se s vasim problemom na vise razlicitih projekata i iz tog razloga sam Vam ovo napisao. Cak sam sa kolegama s kojim sam radio na projektima, pokusao da definisem jedinstveni model recimo Objekata (Parcela, gradjevinski objekat, lamela, ulaz, stan...), kao i jedinstveni model adresnog sistema, ali kada se krene u realizaciju sve pada u vodu jer normativno nije regulisano ili je parcijalno regulisano.

Pod pretpostavkom da je realni sistem jasno eksplicitno normativno regulisan, tek tada se moze upustiti u modeliranje realcionog modela koji ste spomenuli.

Potpis

http://zoraneremija.wix.com/eremijacv

Hvala na ovako brzom odzivu!
Getsbi kaze 'hijerarhija'. Tacno. Ali hijerarhija znaci uvek ista pravila nad svim objektima koje stavljamo u odnos 'roditelj-dete'.
Ne mogu imati ista pravila ukoliko neki od objekata nedostaje. Naravno, mogu pokusati da kodom prevazidjem problem, ali to posle nekog vremena preraste u samo kodiranje. Jednostavno, pokidam sve relacije izmedju tabela i pisem milione SELECT CASE procedura.
Drugim recima, nek je Bog u pomoci nekom posle mene.
Nesto sto je u realnosti i na papiru sasvim logicno i jednostavno uraditi, postavlja se kao veliki problem u prevodjenju u elektronski oblik.
Za gradjevinske objekte koji su definisani Adresom, hijerarhija nije problem.
Problem nastaje kod jos nedefinisanih gradj. obj., sa mogucim podelama na vise gradj.obj. istog nivoa (dakle, u istoj tabeli su i 'roditelj' i 'dete' zapis, a rekurzivna funkcija prikazuje rezultate prema ID i PARENT_ID iz iste tabele). Sta se onda desava sa tabelama koje su zavisne? Kljuc za raspodelu zapisa iz zavisnih tabela prema gore navedenoj podeli ne mora biti isti ( i u vecini slucajeva i nije).
Evo prostog primera:
Deo ulice Đure Đakovića postaje VENIZELOSOVA.
Deo ulice Đure Đakovića postaje POENKAREOVA.
Deo ulice Đure Đakovića ostaje Đure Đakovića.
Pravila za raspodelu kucnih brojeva iz stare u novo nastale ulice ne moraju biti ista za sva tri slucaja.
Najgore je sto moze da se desi (a to se i desilo), da neka baza kojom se sluze bitne sluzbe u ovom gradu nije mogla da primi novo nastalu podelu, pa se dogodilo da vatrogasci upadaju u Đure Đakovića 19, stan 9, prepadnu jadne stanare govoreći da su u pozaru, da bi tek posle saznali da posle podele ulice postoje DVA broja 19 u ul Đure Đakovića, i da je požar 150m niže niz ulicu.

Problem je spcifičan i traži takvo rešenje.
Hijerarhijski modeli ne poštuju normalizaciju. Ovo što ću predložiti više liči na analitičku bazu podataka. Probaj to ovako da rešiš. Za sada zaboravi relacioni model. Ovo je kombinacija analitičkog modela baze podataka i hijerarhijske tabele.
Tebi treba jedna centralna tabela, koja koja je denormalizovana i koja će da odražava strukturom svojih polja, hijerarhiju realnog sistema. Recimo ovako:


Tabela evidencija objekata

Grad------Politička opština-----Mesna zajednica-----Katastarska opština ---- Katastarska parcela-----Građevinska parcela-----Građevinski objekat------AdrsaID-----Lamela-----Ulaz----- Stan

Ova tabela će imati samo jedan prost PK, recimo ZapisID. Ta tabela ne mora u svim svojim poljima da sadrži vrednosti. Odnosno, biće zapisa sa Null vrednostima u poljima pojedinih kolona za ono što u realnom sistemu nedostaje, ali će biti polja gde se ponavljaju vrednosti (redudantnost postoji), što je osnovni znak denormalizacije.

Tabla šifarnik ulica:

Sifra ulice, Naziv ulice, Kucni broj, Dodatak kucnom broju

Ovoj tabeli dodeli takođe prost PK, gore pomenuti AdresaIID. Poveži ih jedan (Tabla šifarnik ulica) prema više (Tabela evidencija objekata)


Takođe razmisli o dodavanju tabela tipa šifarnik za političke i katastarske opštine, kao i mesne zajednice. Slično ovoj mojoj tabeli šifarnik ulica. Na kraju će to ličiti na jednu centralnu tabelu činjenica sa dimenzionim tabelama oko nje.


Ovo oko delova ulica, nemoj da te brine. Sve je to stvar ažuriranja.

Potpis

https://mzahorjanski.wixsite.com/mzahorjanski
https://www.fiverr.com/miroljubzahorja?up_rollout=true
https://www.youtube.com/@miroljubzahorjanski

U prilogu mozete videti model Adresa i Objekat. Kada sam Vam spomenuo normativne stvari u modelu Adresa zutim su oznaceni entiteti koji su definisani od strane drzave i moraju se tako definisati, a ono sto je najvaznije za Vas problem je entitet Adresa (zelene boje) koji je nastao kao iskustvo u modeliranju RTV pretplate. Model Objekat je nastao za potrebe opstinskih uprava. Mozda Vam moze pomoci za pocetak. U prethodnom postu sam bio manje rezigniran a vise ljut na neorganizovanost drzave.



ps: Mesna zajednica je po svojim osobinama pravno lice.

Potpis

http://zoraneremija.wix.com/eremijacv

Mozda vam necu mnogo pomoci ali to nije posao za jednog coveka. I nisam siguran da je access baza dovoljna za to.

Cak i kad resite sve sto ste nabrojali kao problem preostaje vam jos veliki deo posla, a to je digitalizovanje postojecih karti ili u skromnijoj varijanti skeniranje. A i to treba azurirati. Za to postoje resenja samo neko treba da ih kupi i obuci vas. To nisu stvari za stap i kanap.

Nedavno sam pricao sa nekim iz ovdasnjem vodovoda i zale se na opstnski katastar, jednostavno receno neazurni su. Mnogo druge sluzbe su svoje podatke digitalizovale (i georeferencirale) i sada razmenjuju slojeve (struja, voda, kanalizacija...). Jednostavno receno nisu dobijali od katastra trazene podatke pa su se snasli i sad to ima dobrih i losih strana.

Potpis

Pomozite Micro$oftu u borbi protiv piraterije, poklonite prijatelju Linux

Da i ja malo uplasim coveka

Nije samo hijerarrhija problem (iako hijerarhija sama po sebi jeste veeliki problem). Ovde postoji problem pracenja promena stanja kako pojedinih entiteta (GP, objekat) tako i cele baze.

Objekat prolazi kroz nekoliko faza ('planiran','projektuje se','u izgradnji','gotov','dobio resenje o adresi', 'porusen') U odredjenim fazama objekat dobija neke atribute - tek tada dobijaju smisao. Faze su medjusiobno zavisne. ne moze objekat dobiti resenje om adresi, ukoliko je pre toga srusen. Zatim, objekat, lamela, ulaz, stan - svi mogu menjati namene, vlasnike i korisnike. Jedna od namena katastra je da se prati ko je i kada imao vlasnistvo ili pravo koriscenja nad nekom jedinicom prostora (GP, objekat, lamela). Namena jedinice prostora se moze promeniti u nekom trenutku. Parcela prelazi iz poljoprivredne u gradjevinsku, ili obrnuto (obrnuto nesto redje Zanimljiv pojam - jedinica prostora. Mozda moze da pomogne da se hijerarhija nekako razresi.

Ovakav poslovni problem ima neka ogranicenja koja su jako vazana a nazalost u ovom trenutku relacione (a i druge) baze ne pruzaju jednostavnu mogucnost za to. kako cete na nivou baze obezbediti da na primer
4.Jedan GO mora imati makar jedan ulaz, a moze ih biti vise.
5.Ukoliko GO ima lamelu, jedna lamela mora imati makar jedan ulaz, a moze ih imati i vise.

Normalizacija ne daje odgovor na poslednje pitanje, niti na pitanje o pracenju promena stanja entiteta. Ne pomaze ni cinjenica da se u projektovanju baza uglavnom zadovoljimo kad nekako dostignemo 3NF, jer u glavnom ni dotle ne stignemo. 3NF opisuje staticke odnose izmedju entiteta. A sve preko toga, moramo da se snalazimo kako znamo i umemo. Nazalost, u zivotu ima mnogo vise primera gde nam treba vise od 3NF.

Postoji jedna knjiga koja o tome pise i daje vam ideju kako uopste razmisljati o ovim stvarima: "Applied Mathematics for Database professionals", lex De Haan and Toon Koppelars, izdavac apress. Knjiga se moze naci besplatno na internetu, kao PDF, Google "Apress.Applied.Mathematics.for.Database.Professionals.Jun.2007.pdf" i nesto ce se vec pojaviti. Ako ne ide, mogu je poslati na privatnu postu, ima ok0 2.5 MB (2,471 KB).

Lex i Toon su dakle psotavili teorijske osnove. Prakticno je to ziveo Alex Kuznetsov, u knjizi "Defensiev Database Programming with SQL Server". Takodje se moze naci na internetu ako PDF. besplatna verzija je skracema za dva poglavlja koja msilim nemaju veze s nasim problemom, pa je dakle besplatna verzija potpuno OK.

Alexova knjiga moze se skinuti ovde http://www.simple-talk.com/boo...efensive-database-programming/

Obe knjige ovu problematiku pokrivaju tek pri kraju, ali je veoma uputno da se obe knjige procitaju od pocetka. Knjige nisu lake za citanje i razumevanje, ali sta je tu je. To su otprilike jedina knjige koje vam u ovom momentu mogu pomoci.

Za hijerarhije evo dobar sajt, nadam se da jos uvek radi: http://www.codeproject.com/KB/...se/Trees_in_SQL_databases.aspx

Probajte nesto malo, dok se ne stekne neko iskustvo, pa pomalo, u sitnim koracima napred.

Pozdrav svima i hvala na intezivnoj pomoci!!!
Svaka vasa poruka iako poneka "obeshrabrujuca", znaci da nisam bas potpuno izludeo i da problem nije u mom razmisljanju, vec je mnogo ekstenzivniji i okviru multidisciplinarnog.
Ocigledno je da se, u odnosu na problematiku, vrlo mali segment moze pokriti relacionom bazom.
Jos jednom veliko hvala, i molim Vas da mi verujete da svaku poruku citam sa posebnom paznjom iako ne odgovaram na svaku od njih, jer kada ne mogu da kazem nesto sto doprinosi resenju, onda slusam (bolje reci:citam) i ucim.

Ne bih bas olako dao ovakvu tvrdnju iako je problematika kojom se bavite dosta slozena.

U mom prvom post-u sam izneo da je veliki problem u haoticnim normativnim dokumentima i oni multipliciraju probleme.

Nisam imao srece da imam razumne sagovornike iz realnog sistema pa da ovakav projekat realizujem do kraja. Mislim da sam ga sagledao u potpunosti sa svim tezinama koje je @Zidar naveo i mislim da moze da se realizuje u relacionom modelu s time da se mora izaci iz okvira MS Access-a zbog njegovih ogranicenja i mora da se definisu neka nova pravila koja ce olaksati realizaciju. Kolega @Zidar je pomenuo da "Objekat prolazi kroz nekoliko faza" i u tome je kompleksnost.

U mom prethodnom postu sam izdvojio samo dva dominantna objekta koji su kljucni, a postoji vise njih koji ucestvuju. Recimo da bi se pratilo stanje sistema ili bolje receno zivotni ciklus jednog objekta koji menja svoje osobine kao "Transformers :-)" mora se uvesti dominantan objekat Dokument koji bi imao vise vrsta u zavisnosti od tipa promene stanja objekta. Takodje bi se zbog istorije promena morala izvrsiti denormalizacija pojedinih objekata kojom bi se obezbedila informacija o prethodnom stanju.

Potpis

http://zoraneremija.wix.com/eremijacv

Zoran je u pravu. Nije da ne moze da se izvede u relacionoj bazi, moze, ali nema gotovog recepta. Za knjigovodstvo i trgovinu postoje gotovi recepti. Za kataster nema recepata. Zato sam preporucio da se podje u malim koracima. Ako se negde i napravi krupnija greska, moze se uvek ici nazad, nece biti preskupo.

Ne treba ocekivati da ce sad neki tim strucnjaka da sedne, proanalizira situaciju i izadje sa shemom baze i planom aplikacija koji ce da rese problem. To nazalost nije moguce, ma kako se trudili.

Jos jedna napomena. Zoran je lepo upozorio da ce "morati da se negde nesto denormalizuje". Ovo niposto ne treba shvatiti kao "ne treba ni da se normalizuje, posto ce se ionako denormalizovati". Jedna staticna shema mora da se napravi, saglasno zakonima i propisima na podrucju na kojem radis. Shema bi mogla da izgleda onako kako je Zoran dao, ili nesto slicno. Onda treba videti na toj shemi za koje entitete treba pratiti istoriju, promenu stanja i gde nam treba mozda dinamicka hijerarhija.

Pracenje transformacija, promena stanja ('state transitions') je teska za implementaciju, ali nije nemoguce. I to ne odstupa mnogo od 3NF. Sistem mora da se dovede na 3NF, pa se onda naoko odstupi od 3NF da bi se dodatna ogranicenja mogla osigurati. Postoje autori koji pokusavaju da dokazu da je to u stvari nadgrdnja 3NF, a ne denormalizacija. Znaci, sve ogranicenja koja uspostavimo sa 3NF i dalje vaze i moraju da vaze. Prividna denormalizacija se desava kada neke podatke moramo da cuvamo na nekoliko mesta da bi ispostvali dodatna pravila.

Hijerarhija ne odstupa puno od pravila normalizacije, malo je lakse nego promena stanja, ali su kveriji teski za pisanje. Ne znam kako bi zigledala kombinacija hijerarhije i promene stanja, to jos nisam ni probao ni imao prilike da vidim, ali ne be me zacudilo da zatreba za ovakav jedan zadatak. Vojnik ili oficir ima svoju poziciju u nekoj hijerrehiji, on je naka tacka negde na grafu koji predstavlaj hijerarhiju. To vazi dok ne dobije prekomandu ili unapredjenje. Stanje pre i posle promene se lako vidi u hiejrarhiji. Ali kako videti oba stanja, sa vremenom vazenja, Od-Do?

Dakle, recenica "Takodje bi se zbog istorije promena morala izvrsiti denormalizacija pojedinih objekata kojom bi se obezbedila informacija o prethodnom stanju. " niposto ne znaci "nema potrebe neormalizovati".


Alko hocete, mozemo posle Nove godine da otvorimo temu o hijerarhijama i jednu o tranziciji stanja pa da malo vidimo ima li tu nesto korisno za nas.

Ja sam za. I ova diskusija mi je interesantna.

Pozdrav.

Potpis

http://biske.rs