MapInfo 6.0 GIS software was used to display, manipulate and query the cadastral data. ...... surveying and mapping of land parcel boundaries in support of a country's land ... primary objective of cadastre is to meet the needs of various users by ... involves both the definition of structures for the storage of information and the ...
DEVELOPING A CADASTRAL INFORMATION SYSTEM WITH A SPATIOTEMPORAL MODELING APPROACH
A THESIS SUBMITTED TO THE GRADUATE SCHOOL OF NATURAL AND APPLIED SCIENCES OF THE MIDDLE EAST TECHNICAL UNIVERSITY
BY
SULTAN KOCAMAN
IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE IN THE DEPARTMENT OF GEODETIC AND GEOGRAPHIC INFORMATION TECHNOLOGIES
DECEMBER 2001
ABSTRACT
DEVELOPING A CADASTRAL INFORMATION SYSTEM WITH A SPATIOTEMPORAL MODELING APPROACH
Kocaman, Sultan MS., Department of Geodetic and Geographic Information Technologies Supervisor: Assist. Prof. Dr. Mustafa Turker
December 2001
The cadastre is a record of interest in land, encompassing both the nature and the extent of these interests. The basic spatial unit of cadastre is a land parcel, on which all land tenure and land use records are compiled. Cadastral works in Turkey are carried out on a parcelbased approach by focusing on land ownership rights for legal purposes. The cadastral data of Turkey form a large spatial dataset and require efficient data management tools. As a data management tool, a fruitful and effective database should be designed and developed for cadastral data. The database to be developed should be modeled using a spatial and temporal modeling technique due to its spatial and temporal data characteristics. In this thesis, the requirements of a cadastral database for Turkey was analyzed and a spatiotemporal database, which is believed to fulfill the requirements for spatial, temporal, and spatiotemporal queries performed on the cadastral data, was designed and developed. During the design process, the database design stages which are (i) requirements collection and analysis, (ii) conceptual design, (iii) logical design, (iv) physical design, and (v) database system implementation were applied. At requirements collection phase, existing cadastral maps and other cadastral and land registry documents were received from the Land Registry and Cadastre Offices of General Directorate of Land Registry and Cadastre (TKGM). In addition, interviews with technical and legal staff of TKGM were provided. At conceptual level, the STER model,
iii
which has been developed to model the spatiotemporal data, was used to model the cadastral data. At logical design phase, the modeling methods of the relational databases were applied to the conceptual schema. Oracle 8i Spatial was chosen as the Database Management System as it provides storing and management of spatial data in an object-relational structure. The database was implemented in a study area selected in Çayyolu Quarter of Çankaya District, Ankara. MapInfo 6.0 GIS software was used to display, manipulate and query the cadastral data.
Keywords: Cadastre, cadastral information system, spatial databases, spatiotemporal database modeling, GIS.
iv
ÖZ
KONUMSAL-ZAMANSAL VERİTABANI MODELLEME YAKLAŞIMI İLE BİR KADASTRO BİLGİ SİSTEMİ GELİŞTİRME
Kocaman, Sultan Yüksek Lisans, Jeodezi ve Coğrafi Bilgi Teknolojileri Anabilim Dalı Tez Yöneticisi: Yrd. Doç. Dr. Mustafa Türker Aralık 2001 Kadastro, toprakla ilgili bilgilerin doğasını ve uzantılarını da kapsayan kaydıdır. Toprakla ilgili hakların ve kullanım bilgilerinin üzerinde derlendiği parsel, kadastronun temel konumsal birimidir. Türkiye’deki kadastral çalışmalar da parsel tabanlı bir yaklaşımla, hukuki amaçlar için toprak mülkiyeti hakları ön plana alınarak gerçekleştirilmektedir. Türkiye’nin kadastral verileri büyük miktardaki konumsal verilerden oluşur ve etkili ve verimli veri yönetimi araçlarına ihtiyaç duyar. Bir veri yönetimi aracı olarak, kadastral veriler için verimli ve etkili bir veritabanı tasarlanmalı ve geliştirilmelidir. Geliştirilecek veritabanı, konumsal ve zamansal veri özelliklerinden dolayı, bir konumsal ve zamansal modelleme tekniği kullanılarak modellenmelidir. Bu tez çalışmasında, Türkiye için bir kadastral veritabanının ihtiyaçları analiz edilmiş ve kadastral veriye uygulanacak konumsal, zamansal, ve konumsal-zamansal sorgulamalara cevap verebilecek bir konumsal-zamansal veritabanı tasarlanmış ve geliştirilmiştir. Tasarlama sürecinde uygulanan veri tabanı tasarlama aşamaları şöyle sıralanabilir: (i) gereksinimlerin belirlenmesi ve analizi, (ii) kavramsal tasarım, (iii) mantıksal tasarım, (iv) fiziksel tasarım, ve (v) veritabanı sisteminin geliştirilmesi. Gereksinimlerin belirlenmesi aşamasında, Türkiye’de toprak haklarının belirlenmesi ve korunmasından sorunlu Tapu ve Kadastro Genel Müdürlüğü’ne (TKGM) v
bağlı Tapu Sicil ve Kadastro Müdürlüklerinden alınan kadastro haritaları, ve diğer tapu sicil ve kadastro dokümanları kullanılmıştır. Ayrıca, TKGM’nin teknik ve hukuki personeliyle de görüşmeler yapılmıştır. Kavramsal seviyede ise, konumsal-zamansal verileri modellemek için geliştirilmiş olan STER modeli, kadastral verileri modellemek için kullanılmıştır. Mantıksal tasarım aşamasında, kavramsal şemaya ilişkisel veritabanları modelleme yöntemleri uygulanmış ve konumsal verinin nesne-ilişkisel yapıda saklanması ve yönetilmesini sağlayan bir veritabanı yönetim sistemi (VTYS) olarak Oracle 8i Spatial seçilmiştir. Veritabanı Ankara’nın Çankaya İlçesi’ndeki Çayyolu Mahallesi’nde seçilen bir çalışma alanında uygulanmıştır. Kadastral verileri göstermek, değiştirmek, ve sorgulamak için bir Coğrafi Bilgi Sistemi (CBS yazılımı) olarak MapInfo 6.0 kullanılmıştır. Anahtar Kelimeler: Kadastro, kadastro bilgi sistemleri, konumsal veritabanları, konumsalzamansal veritabanı modelleme, CBS.
vi
To My Family
vii
ACKNOWLEDGEMENTS
I would like to thank to Assist. Prof. Dr. Mustafa Türker for his continuous support, insight, and guidance during my study, and his caring to my thesis writing process. I would also thank to Prof. Dr. Adnan Yazıcı for his suggestions and comments. He never abstained from giving his time to me. I would also thank to my manager Cevat Yaman, Sedat Bakıcı, and my colleagues from TKGM for their patience to my studying during the working hours, and to Deputy of General Director Nihat Şahin for his managerial supports. And thank to my friends Cüneyt, Ersin, and Yılmaz for their suggestions and assistance in technical subjects. S. Gökşin Seylam, the old headquarter of the Photogrametry and Geodesy Department, always motivated me and helped with his ideas about my research. Also, thanks to Birol, Mertkan, Mustafa Nevzat, Taner, Mahmut, Önder, Aynur, and Arda for their friendship and reassuring me while writing my thesis. I had to thank to my family for their continuous support for my education and in my life, and Serpil and Fatih for their tolerance to my untidiness at home.
viii
TABLE OF CONTENTS ABSTRACT .....................................................................................………....................
iii
ÖZ
v
..................................................................................…….......................................
DEDICATION ...............................................................……….....................................
vii
ACKNOWLEDGEMENTS ........................................................………........................
viii
TABLE OF CONTENTS ........................................................................……….............
ix
LIST OF TABLES ...........................................................................................………....
xiii
LIST OF FIGURES ...........................................................................................………...
xiv
CHAPTER 1. INTRODUCTION .....................................................................................………....
1
2. THE CADASTRE AND CADASTRAL DATA MANAGEMENT .........………..
9
2.1 Introduction ........................................................................................……….....
9
2.2 The Cadastre ........................................................................................………...
11
2.2.1 Cadastral Works in Turkey ......................................................………...
14
2.2.1.1 General Directorate of Land Registry and Cadastre ...........…..
14
2.2.1.2 Cadastral Data ............................................................………..
17
2.2.1.3 The Cadastre and Land Registration Processes ....……….........
18
2.3 Geographical Information Systems ..........................................………..............
20
2.3.1 Spatial Data Models .................................................................………..
20
2.3.2 Spatial Relationships ..............................................................………....
22
2.3.3 Spatial Databases ...................................................................……….....
22
2.3.4 Time in Databases ...................................................................………...
23
2.4 Information Systems Design ........................................................………........
23
3. THE REQUIREMENTS FOR A CADASTRAL DATABASE ............………......
26
ix
3.1 Introduction ......................................................................................………......
26
3.2 Main Objects of a Cadastral Database ..........................................……….........
27
3.2.1 Land Parcel ........................................................................……….........
27
3.2.2 Parcel Block .......................................................................………........
28
3.2.3 Country .................................................................................………......
29
3.2.4 Province ....................................................................………..................
29
3.2.5 District ..................................................................................………......
30
3.2.6 Quarter .......................................................................……….................
30
3.2.7 Village ................................................................................………........
31
3.2.8 Person ..................................................................……….......................
31
3.2.8.1 Real Person .........................................................……….............
32
3.2.8.2 Juridical Person ...........................................................………....
33
3.2.9 Buildings ............................................................................………........
34
3.2.10 Cadastral Map ...................................................................……….......
35
3.2.11 Ground Control Points .......................................................………......
38
3.2.11.1 Triangulation Points ...............................................……….......
39
3.2.11.2 Traverse Points ....................................................………..........
40
3.2.11.3 Levelling Points .....................................................………........
40
3.3 Other Land-related Data Linked to Cadastral Data .............................………...
41
3.4 The Relationships Between The Objects in a Cadastral Database ....………....
42
3.5 Basic Cadastral Queries ..................................................................………......
46
4. CONCEPTUAL MODELING OF CADASTRAL DATA .......................………..
48
4.1 Introduction ..................................................………..........................................
48
4.2 The STER Model ............................................……….....................................
50
4.2.1 The Entity-Relationship (ER) Model .............………............................
51
4.2.2 Spatiotemporal Constructs in STER ................………...........................
52
x
4.2.3 Entity Sets .......................................................……….............................
53
4.2.4 Attributes of Entity and Relationship Sets ...........……….......................
54
4.2.5 Relationship Sets ........................................................……….................
55
4.2.6 Adding Transaction Time to STER .......................………......................
58
4.3 Adding Enhanced-ER (EER) Model Constructs to STER ....……….................
58
4.4 A Conceptual Schema Design for Cadastral Data .....................…...……...........
60
5. LOGICAL DESIGN ...............................................................….....………............
64
5.1 Introduction ...........................................................................………..................
64
5.2 Choice of a Database Management System.......................……….....................
65
5.3 Mapping the Conceptual Schema to a Logical Schema ............………...........
65
5.4 The Relations and Functional Dependencies in the Cadastral Database ……..
67
5.5 Database Tables .......................................................…………............................
76
6. SYSTEM IMPLEMENTATION ..................................………..............................
78
6.1 Introduction .....................................................................………........................
78
6.2 The Systems .......................................................................………....................
78
6.2 The Implementation ...........................................................………....................
81
6.3.1 The Study Area ..............................................................………...............
81
6.3.2 Data ..............................................................................………................
81
6.3.2.1 Land Registry Data ............................................……….............
83
6.3.2.1.1 Anomalies in Land Registry Data ..............................
87
6.3.2.2 Cadastral Data ............................................………....................
87
6.3.2.2.1 Anomalies in Cadastral Data ......................................
89
6.3.3 Database Tables .........................................................................……......
90
6.3.4 Data Load Process ...................................................................………....
90
6.3.4.1 Fixing the Data Anomalies .........................................................
92
6.3.4.2 Populating the Database Tables..................................….............
95
6.3.5 Sample Queries ...................................................................………........
95
xi
7. CONCLUSIONS AND THE RECOMMENDATIONS ..........………..................
101
REFERENCES .............................................................................………......................
105
APPENDICES A. AN ABSTRACT SCHEMA DESIGN FOR CADASTRAL DATA USING THE STER MODEL .........................................................……………………..................... 109 B. A DETAILED SCHEMA DESIGN FOR CADASTRAL DATA USING THE ER MODEL .......................................................…………....................................... 113 C. THE RELATIONS AND FUNCTIONAL DEPENDENCIES IN THE CADASTRAL DATABASE ...................................................………………………................ 121 D. DATABASE TABLES ............................................………................................
145
E. THE LIST OF CREATED DATABASE TABLES .............................................
182
xii
LIST OF TABLES TABLES 5.1 The structure of PARCEL table .........................................………..…...............
76
5.2 The structure of PARCEL_GEO table ................................………..…..............
77
6.1 The file structure of Tapuakt table .........................................……….................
84
6.2 The file structure of Kisiakt table .......................................……….....................
85
6.3 The file structure of Ilisakt table ........................................……….....................
86
6.4 The file structure of Edinseb table .................................……….........................
86
6.5 The file structure of Mahalle table ....................................………......................
87
6.6 The file structure of Uyruk table .........................................………....................
87
6.7 The layer names, layer definitions, and some brief explanations about the cadastral data existing in the layers ..................................................…………………......
xiii
88
LIST OF FIGURES FIGURES 2.1 A portion of a cadastral map ...................................………..................................
12
2.2 Multipurpose cadastre components ................................………..........................
13
2.3 Land information systems ..........................................................………..............
13
2.4 Organisational structure for central units of TKGM in Ankara ......……….........
16
2.5 Organisational structures of the offices in the country ..................………...........
16
2.6 A classification of GIS analysis functions ..................................………..............
21
2.7 The macro life cycle of an information system ..............................………..........
24
2.8 The life cycle of database applications design ................................….…….........
24
3.1 (a) Four land parcels form a parcel block with the block identification number 13991. Each land parcel has a unique parcel identification number in the block. (b) The land parcels,1 and 2, have been combined and formed a new land parcel with the parcel identifier 1. ............................................……...........
28
3.2 Some portion of map index in Turkey’s map classification system ………........
36
4.1 Capturing existence time in (a) STER model and (b) ER model ........……….....
51
4.2 Representation of a spatial entity set in (a) STER model and (b) ER model ............ 51 4.3 Representation of a spatiotemporal entity set in (a) STER model and (b) ER model ..................................................................................................………………......
52
4.4 Representation of a temporal attribute in (a) STER model and (b) ER model .....
55
4.5 Representation of a spatial attribute in (a) STER model and (b) ER model ........
56
4.6 Representation of a spatiotemporal attribute in (a) STER model and (b) ER model ................................................................................................………………......... 4.7 The representation of a spatiotemporal relationship in (a) STER model and (b) ER
xiv
56
model .................................................................................……………................
57
4.8 Graphical representation of a specialization relationship in EER .....………........
59
4.9 A part of abstract conceptual schema of a cadastral database ........………...........
62
4.10 A part of detailed conceptual schema of a cadastral database ....………............
63
6.1 Components of the designed cadastral database ...................................................
82
6.2 The representation of cadastral maps in a part of the study area by using the MapInfo 6.0 GIS software ..........................................................………………….............
83
6.3 Spatial and non-spatial data load process into Oracle 8i Spatial ...........................
91
6.4 (a) The MapInfo display window including the parcel and parcel block maps of the study area. (b) The EasyLoader data load interface of the parcel and parcel block maps of the study area ......................................................................
93
6.5 The MapInfo display of land parcels owned by ‘Maliye Hazinesi’ (National Treasury) in Çayyolu ............................................................................................
96
6.6 The MapInfo display of the building and the building owners located in parcel block 15637 and parcel 2 Çayyolu ........................................................................
97
6.7 The query execution and the result of query 3 ......................................................
98
6.8 The list of the parcels owned by ‘Tuna Mühendislik’ company ...........................
98
6.9 The overlapping geometries of the parcel with parcel block number 13055 and parcel number 1 in Çayyolu in the last 15 years .................................................. 6.10 The land parcels located in parcel block 13064 recently ..................................
99 100
A.1 The abstract conceptual schema of a cadastral database prepared using the STER model ..................................................................................................................
109
B.1 The detailed conceptual schema of a cadastral database prepared using the ER model ...............................................................................................................................
xv
113
CHAPTER 1
INTRODUCTION
Land is the foundation of all forms of human activity: from it we obtain the food we eat, the shelter we need, the space to work, and the room to relax (Dale and McLaughlin, 1988). During his history, human being has given different meanings to his relation with land and arranged it in several forms: shelter, food resource, means of production, motherland... Also, he owned and managed it. The resources of the land are neither inexhaustible nor indestructible, as many men and countries have already found to their cost. Resources that had taken many million years to accumulate have been squandered or allowed to waste away in a few decades, and this squandering and wastage is likely to continue on an increasing scale wherever definite measures to stop it are not undertaken (Binns, 1953). Because the earth resources are limited and the land has got a certain economical importance, it should be carefully managed. Land management is defined as the process by which the resources of land are put to good effect. It covers all activities, concerned with the management of land as a resource such as farming, mineral extraction, property and estate management and the physical planning of towns and the countryside both from an environmental and from an economic perspective. Land-related information can be categorized as environmental information, infrastructure information, socio-economic information, and cadastral information. A satisfactory form of land management arrangement should contain land information management, resource management, and land administration arrangements over the country. Land administration is the processes of recording and disseminating information about the ownership, value and use of land. Land
1
administration is concerned with three commodities –the ownership, value and use of the land- within the overall context of land management. Land ownership, value and land use information required by land administration are gathered by cadastral surveys, which are the surveying and mapping of land parcel boundaries in support of a country’s land administration, conveyancing or land registration system. Different countries interpret the term cadastre in different ways. The common understanding is that a cadastre is a form of land information system. A land information system (LIS) gives support to land management by providing information about the land, the resources upon it and the improvements made to it. The International Federation of Surveyors (FIG) has defined an LIS as a tool for legal, administrative and economic decision making and aid for planning and development. The cadastre is a subset of LIS that has been defined as a record of interest in land, encompassing both the nature and the extent of these interests. An interest in land (or property right) may be narrowly construed as a legal right capable of ownership or more broadly interpreted to include any uniquely recognized relationship among people with regard to the acquisition and management of land (NRC, 1980). The basic spatial unit of cadastre is a land parcel, on which all land tenure and land use records are compiled. The primary objective of cadastre is to meet the needs of various users by providing information at parcel level. Parcel-based LIS, or cadastres, can be distinguished within the family of spatial information systems by at least two characteristics. A cadastre may encompass all or part of the information stored in any other LIS or Geographical Information System (GIS), but the main objective of the system is the provision of institutional data concerning land ownership, value, and use. Furthermore, in a parcel-based LIS the fundamental means of organizing data is the cadastral parcel or proprietary land unit. Information is therefore collected, stored, referenced, and retrieved primarily at the parcel level, although other referencing systems, such as co-ordinates, may be added to facilitate data manipulation and exchange (McLaughlin and Nichols, 1987). Data that may appear in a cadastre include:
geometric data (coordinates, maps),
property addresses,
land use,
2
real property information,
the nature and duration of the tenure,
details about the construction of buildings and apartments,
population,
land taxation values (CERCO, 1995).
Data in the cadastral system of country should be collected and organized considering the whole country. That necessity arises the data storage and management problem due to the large cadastral data sets. Data may be held in manual or computer compatible form. Enhancing a cadastral system by using computer systems has some benefits, such as forcing the data and operation standardization, speeding up the processes, decreasing the data storing cost, preventing unnecessary duplication, and facilitating the data access and analysis. Three broad categories of data must be managed within LIS. They are (1) alpha-numeric data, such as lists of land owners or site characteristics of properties; (2) graphical data on maps, photomaps, and aerial photographs; (3) numerical spatial data in either vector or raster form (Dale and McLaughlin,1988). That diversity of data brings the complexity in data management and requires to be managed by using an advanced database management system (DBMS). The databases are designed to manage large bodies of information. The management of data involves both the definition of structures for the storage of information and the provision of mechanisms for the manipulation of information. In addition, the database systems provide for the safety of the information stored, despite system crashes or attempts to unauthorized access (Silberschatz et al, 1997). A database may have special characteristics according to the structures of the data managed by, such as spatial databases which manages the geographical data. When the time constructs are considered in a spatial database, it is called spatiotemporal database. Database definition and modeling has an important role on database administration and optimizing data storage and processing. The complexity of spatial data structures and the advances in geographic data management together with a wide application of GIS have made spatial database modeling an interesting and challenging research area. In recent years, several models have been proposed that are based on either an entity-relationship (ER) approach or an object-oriented (OO) approach. MODUL-R (Bédard 1996, Caron 1993), GeO2 (David 1993) and GeoER (Hadzilacos and
3
Tryfona, 1997) models were developed based on an ER model. On the other hand, GeOm (Tryfona 1997), POLLEN (Gayte 1996) and CONGOO (Pantazis 1996) are the examples that used OO approaches in their conceptual modeling. As can be seen from the previous studies, a cadastral database should be modeled using a spatial and temporal modeling technique due to its spatial and temporal data characteristics. Basic cadastral queries require information about the changes on objects, their attributes, and the relationships between these objects. Thus, to store historical information on cadastral objects and the relationships between these objects is a considerable necessity. Most of the countries with a formal land information system in place have already computerised their systems, or are on the way to do so. Different countries in the world have different cadastral systems according to the objectives of the cadastre and the data contained in the system. That different approaches to the cadastral systems obstructs to define a worldwide unique computerised cadastral information system. There have been several studies for developing a cadastral information system for several countries. In KISVO Report (1988), a general-purpose cadastral information for developing countries was defined. Bacino (1999) introduced “The Montana Cadastral Project” that aims to create a statewide digital land ownership database. Y. Kim and S. Kim (1999) describe the present status of parcel-based land information system which also serves as a multipurpose cadastral system in Korea. Blanchard and Lovett (1994) outline one parcel management data model as an extension of a geographical information system. Qiao (1996) designed and developed a practical county/city cadastral information system which consists of three subsystems (town cadastral information system, village cadastral information system, land use information system) and its fundamental functions. Meijere et al (1998) explained a case study for maintenance of cadastral information systems from Argentina. Tuomaala and Uimonen (1998) introduced the new object-oriented cadastral information system (JAKO) of Finland. Cadastral works in Turkey started in 1925 and planned by the cadastre law. Land registry and cadastral works in Turkey are carried out by General Directorate of Land Registry and Cadastre (TKGM). Cadastral surveys are carried out by TKGM and land rights are guaranteed by the state. Since 1925 Turkey’s cadastral system has been formed by the state with a few legal and organizational modifications. Due to these modifications, there was a lack of standardization and consistency for geometric aspects of cadastral data (e.g. graphical maps without a coordinate system, coordinate system diversity between cadastral maps, etc.). Another reason for this problem is the development of new surveying systems by the
4
growing technology. Due to incapable surveying systems and lack of qualified personnel, old cadastral maps were produced with some technical problems, such as low accuracy, usage of various coordinate systems, etc. In addition, the maps were not updated unless the requests of the land parcel owners. Therefore, there are considerable update problems for the cadastral maps. However, they keep their validity according to the cadastral laws. In a number of cadastral offices, some of the cadastral maps are currently being converted into digital form through CAD software. But there is no digital data storage standard for cadastral data in Turkey. The problems regarding data (lack of data standardization and data quality, inconsistent data, problems in digital data storage and retrieval) and slowness in cadastral services forced to make a reform in Turkey’s cadastral system tending towards a computer-based cadastral information system. Several past studies focused on designing a cadastral system in Turkey. Yalın (1986) defined a multipurpose cadastral system and its automation in Turkey’s context. Erdi (1990) described a land information system and its fundamentals in Turkey’s context. These two studies focused only on an overall system design, a detailed spatial database design is not provided. Ercan (1997) studied the design and development of a cadastral information system for Turkey. However, this study was not in a spatiotemporal database modeling approach. The modernization and the automation of Turkey’s cadastral system started with HAKAR Project (Reform Project on Mapping and Cadastral Works) in 1986 by TKGM and TUBİTAK (Turkey Scientific and Technical Research Organization). However, it was stopped after the system analysis phase. In 1990, the first project for developing a Land Registry and Cadastre Information System was planned and taken part in the projects of State Planning Organization (DPT). No developments were achieved in this project either. Although some system automation works for land registration and cadastre offices have been carried out by TKGM. They are not in an information system approach. In 2000, a new project, TAKBIS (Land Registry and Cadastre Information System) was started by TKGM and the system analysis and the design phases were completed by October 2001. The main purpose of TAKBİS is to establish a countrywide cadastral information system using the database management and GIS software as well as additional application software required by various users working for TKGM or other organizations who need the cadastral data.
5
Since no database design study has been performed for cadastral data in Turkey and no cadastral information system implementation project has been completed yet, design of a comprehensive cadastral database was needed therefore. The objectives of this study are as follows:
to analyze the requirements of a cadastral database for Turkey,
to design and develop a spatiotemporal database to fulfill the requirements for spatial, temporal, and spatiotemporal queries for cadastral data,
to implement above mentioned cadastral database in a study area,
to provide data consistency between land registry and cadastral data,
to speed up the cadastral processes,
to support management of cadastre and mapping activities in Turkey,
to give a better service to people and institutions that require cadastral data, and
to enforce producing multipurpose-motivated cadastral data.
To achieve the study objectives, the characteristics of cadastral database was taken into consideration while designing the cadastral database. Because the cadastral data and the basic cadastral queries have certain spatial and temporal characteristics (e.g. querying the changes on the location and the shape of a land parcel, querying the ownership changes on a land parcel, etc.), a cadastral database was modeled using a spatiotemporal database modeling technique. There are some important phases for the database application systems design called micro life cycle of an information system, and these phases should be considered during a cadastral information system design. These steps can be ordered as; system definition, database design, software development, testing, system implementation, populating the database by loading the data or data conversion, processing and verifying the input data, testing of functionality, integration, performance, system, security, putting the system into operation, monitoring and maintenance. As a second step of database applications design, database design has some important phases. The phases of database design process are:
6
i.
Requirements Collection and Analysis: Identifying and analyzing the expectation of
users and intended uses. ii.
Conceptual Database Design: Examines the requirements from phase 1 and produces
a conceptual schema. iii.
Choice of a DBMS: This step is governed by a number of factors including software
acquisition cost, maintenance cost, hardware acquisition cost, database creation and conversion cost, personnel cost, training cost, and operating cost. iv.
Data Model Mapping (Logical Database Design): In this phase, the conceptual model
is mapped into the data model of the DBMS. This phase has two steps. In the first step, a system-independent mapping is applied and no specific and characteristics or special cases of the DBMS are considered. In the second step, schemas are mapped into a specific DBMS. The schemas from step 1 should be adjusted according to specific characteristics of the DBMS. v.
Physical Database Design: The process of choosing specific storage structures and
access paths for the database files to achieve good performance. vi.
Database System Implementation: After logical and physical designs are completed,
empty database files are created and the data can be loaded. In this thesis, a spatiotemporal database design for cadastral data was applied following above given database design phases. The system requirements were defined by using land laws in Turkey. The technical staff in Çankaya Cadastre office was communicated and the required documents and sample maps were supplied by Çankaya cadastre office. Additional information and documents were taken from the Photogrammetry and Geodesy Department of TKGM. After collecting the system requirements, a conceptual database design was applied using the Spatiotemporal Entity-Relationship (STER) Model in combination with the Enhanced Entity Relationship (EER) model. The proposed conceptual schema was mapped onto a logical data model in a relational design approach. Oracle 8i Spatial was chosen as database management
7
system (DBMS) software, which has spatial data handling capability. The physical design and database system implementation phases were treated together. The database tables defined in the logical schema were created in Oracle 8i Spatial. The cadastre and land registry data of Çayyolu Quarter in Çankaya District, Ankara was loaded into the created database tables. Since Oracle 8i does not have graphical edit and display tools for spatial data, MapInfo 6.0 GIS software was used to retrieve, display, manipulate, and analyze the cadastral data. This thesis is divided into seven chapters. In chapter 2, the general concepts of cadastre and cadastral works in Turkey are described. In addition, information regarding data management for spatial data is provided in this chapter. In chapter 3, system requirements analyses for the cadastral database are explained. In chapter 4, conceptual modeling of cadastral data given. In chapter 5, logical database design algorithms as applied the conceptual schema are presented. In chapter 6, the physical database design and the system implementation over a small study area are provided. Finally, in chapter 7, the results of the study and the recommendations are given.
8
CHAPTER 2
THE CADASTRE AND CADASTRAL DATA MANAGEMENT
In this chapter, the scope and definition of the cadastre are introduced and basic cadastral concepts are explained. The cadastre system of Turkey is presented with institutional and consisted data aspects. In addition, data management issues for spatial datasets are discussed. The cadastral data may be held in a spatial database that integrates a DBMS with a GIS. A cadastral database should be modeled using a spatiotemporal modeling approach. Basic concepts about spatial data models, spatial relationships, spatial databases, temporal databases, and GIS are introduced. The information systems lifecycle and the fundamentals of database design process, which is the main application of this thesis project, are explained.
2.1 Introduction
Land might be defined as any portion of the earth over which rights of ownership, stewardship, or use may be exercised (Barlowe, 1986). Because the earth resources are limited and land has got a certain economical importance, it should be carefully managed. A land management arrangement should contain land information management, resource management, and land administration arrangements. Land administration is concerned with managing the land tenure system. Land tenure may be defined as the rights, restraints, and responsibilities people have with respect to the land. Thus, land administration manages public, private, and state interests in land and the systems, such as land registration, land taxation, and land use planning related to land tenure (Nichols, 1994).
The information that is subject to the land administration is collected by cadastral surveys. A cadastre may be defined as a record of interests in land, encompassing both the nature and 9
extent of these interests (NRC, 1980). The principal function of cadastre is provision of data concerning such matters as land ownership, value, and use (Dale and McLaughlin, 1988). Also, every land administration system should include some form of land registration, that is a process for recording, and in some countries guaranteeing, information about the ownership of land (CERCO, 1995).
Land administration system in a country is affected by the country’s social and economical background. As the part of the land administration system, the cadastral system and the land registration system are interpreted thoroughly. Cadastral systems may be classified in three categories according to the information they contain or the primary purpose for which they have been developed: (i) the juridical cadastre, which serves as a legally recognized record of land tenure; (ii) the fiscal cadastre, which was developed primarily for property valuation; and (iii) the multipurpose cadastre, which encompasses both the fiscal and the juridical with addition of other parcel-related information. The changing needs in land management motivate the cadastral surveys towards a multipurpose cadastre approach, which serves to land ownership, land economics, planning, statistics, and management.
Cadastral system of Turkey can be classified as juridical cadastre with its fundamental objective which is the recording of the land tenure legally. Cadastral works are carried out by the General Directorate of Land Registry and Cadastre (TKGM) and the land tenure rights are guaranteed by the state. While the cadastral works are carried out by Cadastral Offices, the land registration works are carried out by Land Registry Offices.
The improvements in technology help the developments in cadastral systems with new surveying techniques such as Global Positioning System (GPS), digital photogrametric methods, etc., and with the advances in computer systems for spatial data management such as Geographical Information Systems (GISs), CAD/CAM systems, etc. As a subset of GIS, Land Information Systems (LIS) have been introduced as a useful tool for land-related information management. Cadastral information is an important part of LISs, and can be named as parcel-based land information system.
GIS has been a useful tool for storing, managing, analyzing and presenting the spatial data in a computerized environment since it was introduced to the market. GIS can be used in a large number of fields that use spatial data such as mapping, cartography, geography, etc.
10
Spatial database management systems are among the major components of a GIS. Spatial data models are therefore an important topic for GISs.
Several data models for modeling spatial data have been introduced. Two basic models which represent spatial data with their own modeling elements are vector and raster data models. Also, there are different approaches for spatial databases, like CAD/CAM design or geographical databases, which encode the spatial data for their own purposes (e.g., spaghetti model, topological model, etc.). Spatial relationships can be defined in topological models due to their complexity. Time is another important concept for spatial databases. When the time constructs are considered in a spatial database, it is called spatiotemporal database.
2.2 The Cadastre
The cadastre is an information system consisting of two parts: (i) a series of map or plans showing the size and location of all land parcels, and (ii) the text records that describe the attributes of the land. The basic spatial unit of cadastre is a land parcel on which land tenure and land use records are compiled (figure 2.1). The land and anything attached to the land that include buildings, apartments, and other constructions and natural objects, such as trees are named as property, or real estate.
A modern cadastre serves as multipurpose cadastre which can contain a variety of parcelrelated land information. The multipurpose cadastre is further conceptualized as a public operationally and administratively integrated land information system, which supports continuous, readily available, and comprehensive land-related information at parcel level. In such a system, information pertaining to land ownership, land economics, planning, statistics, and management may all be combined, either in one unified system or through a network of smaller systems linked together. The multipurpose cadastre may support:
Land transfer by holding the records relevant to land ownership;
Land taxation by records of details of owners, occupiers, properties, and values;
General land administration by providing land-related information in an integrated form, making possible both the complex forms of analysis and a broader understanding of land issues (Dale and McLaughlin, 1988).
11
a parcel block block identifier
parcel identifier
a land parcel
a building
Figure 2.1: A portion of a cadastral map.
The chief components of the multipurpose cadastre are a spatial reference framework, a base mapping programme on top which cadastral information can be overlain, and a series of files relating various types of information to each parcel (figure 2.2).
The multipurpose cadastre contains a set of data related to the parcel. Possible information types that can be collected for multipurpose cadastre are:
Land rights and restrictions
Land values and tax assessments
Rural and urban land use
Housing and buildings
Population and census data
Administration
Antiquities
Many other types of data can be linked to multipurpose cadastre by mapping overlay, or by reference coordinates. Some of these data are the topography, geological and geophysical
12
data, soils, vegetation, wildlife, hydrology, transportation, gas, electricity, telephones, emergency services, etc.
OTHER PARCEL-RELATED RECORDS ADMINISTRATIVE RECORDS
OTHER RECORDS
RESOURCE RECORDS
TENURE AND VALUE RECORDS
PARCEL ID OTHER IDENTIFIERS
OTHER OVERLAYS
CADASTRAL BOUNDARY OVERLAY
DATA-EXCHANGE CONVENTIONS BASE MAPS GEODETIC REFERENCE FRAMEWORK
Figure 2.2: Multipurpose cadastre components (Dale and McLaughlin, 1988)
The multipurpose cadastre is the closest to the universal concept of an LIS (Dale and McLaughlin, 1988). The operation of a LIS includes the acquisition and assembly of data; their processing, storage, and maintenance; and their retrieval, analysis, and dissemination (figure 2.3).
HUMAN RESOURCES
TECHNICAL RESOURCES ORGANIZING PROCEDURES
COLLECTION
STORAGE
RETRIEVAL
DISSEMINATION
LAND-RELATED INFORMATION
Figure 2.3: Land information systems (Dale and McLaughlin, 1988)
13
USE
The parcel-based land information system, or cadastre, is a subset of LIS. It consists of three basic components:
(i) the cadastral parcel as the basic unit for organizing the information in the system;
(ii) cadastral records(s) which may contain both textual and geographic information;
(iii) parcel identifiers or index codes (PIDs), that serve as the primary linkage mechanisms among the graphical and textual records and serve as the primary spatial reference for spatial information (McLaughlin and Nichols, 1987).
2.2.1 Cadastral Works in Turkey
The fundamental objective of cadastral works in Turkey is to record and arrange the ownership rights on the land parcels. Due to above objectives, the cadastral works in Turkey can be classified as “juridical cadastre”. The data that are gathered during cadastral surveys are the land tenure information, land parcels, geodetic control points, and other parcel-based data, such as buildings, annexes, etc. Cadastral works are carried out by the General Directorate of Land Registry and Cadastre (TKGM), and the ownership rights are guaranteed by the state.
2.2.1.1 General Directorate of Land Registry and Cadastre
General Directorate of Land Registry and Cadastre (TKGM) is responsible for the land registration and cadastre works. The main tasks of the TKGM are to make cadastral survey, to make all registration operations and contracts on land rights, to determine land tenure method, and to keep the cadastral data up to date in Turkey.
According to the Establishment Law of TKGM dated 1984, the tasks of TKGM can be listed as:
To make registrations according to contracts on land rights,
To make registrations of lands that are under the responsibility of National Treasury,
14
To enforce and control of modifications on registrations,
To preserve the registers and documents,
To determine the main principles for new land registrations,
To organize, make, and put into practise the cadastral works for country and also to
enforce and control the modifications on cadastre,
To make the renewal works of cadastral maps that are technically unusable,
To determine basic principles for producing geodetic network points, cadastral surveying
methods, aerial Photogrammetry and cartography for cadastral and topographic maps; and control and organize these duties,
To organize and improve land registration, cadastre and mapping services,
TKGM contains two main organizational units which are specialized with their works. The central units are located in Ankara where they have special administrative, inspection or technical works (figure 2.4). Land Registry and Cadastral Offices are constituted for carrying out the land registration and cadastral works in districts respectively. According to the deed density there is at least one land registry office in each district. On the other hand, there is only one cadastral office in each district. However, no cadastral office exists in small districts where a cadastral chiefship is constituted and administratively connected to the nearest Cadastral Office (figure 2.5).
Tasks of a few departments, which carry out considerable works for this study, illustrated in figure 2.4, are as follows: Land Rights Duties Department: Examines the legislative aspects of the land registration and cadastral operations. Science Duties Department: Examines cadastral renewal necessities. Also, it works as an archiving mechanism for all cadastral and topographic maps and their base documents produced by TKGM and for all maps produced by any other organization.
15
General Director
Deputy of General Director (3)
Personnel Department
Land Rights Duties Department
Science Duties Department
Education Department
Land Registration Department
Cadastre Department
Administrative and Financial Department
Archive of Land Registration Department
Geodesy and Photogrametry Department
Civilian Defense Specialization Revolving Fund Enterprise
Foreigner Duties Department
Inspection Committee Department Legal Adviser
Research, Planning and Coordination Department
Figure 2.4: Organizational structure for central units of TKGM in Ankara.
Regional Branch Offices (21)
Cadastral Offices (317)
Cadastral Chiefships (144)
Land Registration Offices (1001)
Figure 2.5: Organisational structure of the offices in the country. Cadastre Department: Plans and organizes cadastral surveys that are carried out by Cadastral Offices. Geodesy and Photogrammetry Department: Makes flight plans, takes aerial photographs, processes these photographs for cadastral and topographic mapping purposes, and reproduces these photographs and maps by cartographic reproduction methods. Another important task of this department is to establish a geodetic network, and to archive all the documents related to the network.
16
Research, Planning and Co-ordination Department: Follows innovations in technology particularly the advances in computer science and geomatics. New projects related to cadastral works are also proposed, developed, and implemented by this department.
2.2.1.2 Cadastral Data
All cadastral data are produced by TKGM. Only a few types of data auxiliary to cadastral surveys, such as accurate geodetic control points, 1:25000 scale maps, forest maps, etc., are obtained from other government organizations. Basic cadastral data types are as follows:
Geodetic reference framework: TKGM establishes a few types of geodetic control
points and forms the geodetic reference framework for cadastral surveys. While the 1st and 2nd degree triangulation points were constituted by General Command of Mapping, 3rd degree and complementary triangulation points were constituted by TKGM. The establishment of the triangulation points was carried out by Photogrammetry and Geodesy Department in TKGM. Other governmental organizations are competent to establish 3rd and complementary triangulation points for their mapping activities.
As part of base geodetic reference to cadastral surveys, traverse points are established in cadastral work areas at the beginning of cadastral surveys by field surveyors. Traverse points have less accuracy than the triangulation points, but they are located more densely, and in or next to the settlement areas which are subject to the cadastral surveys. Cadastral maps: They are produced by cadastral offices at the end of each cadastral surveying process. The standard topographic cadastral maps produced by the Photogrammetry and Geodesy Department are used as auxiliary maps during cadastral surveys. They can also be used as cadastral maps after the complementary works performed in the field. Land parcel boundaries on cadastral maps are legally recognized as ownership boundaries. Some other types of graphical data gathered during the cadastral surveys are:
- buildings, annexes, - hydrological units (e.g. rivers, lakes, springs, etc.), - transportation constructions (e.g. roads, railways, tracks, etc.), - mining structures (e.g. pits, etc.),
17
- energy structures (e.g. electric poles, transformers, etc.), - vegetation (e.g. forests, trees, etc.), - communication units (e.g. telephone poles, antennas, etc.), - cultural units (e.g. antiques, parks, etc.), - topographic units (e.g. elevation points, dry streams, hills, etc.) Land use information: Land use type for each land parcel is gathered during cadastral surveys. The determination of land use type of a land parcel is affected by the agricultural use type in rural areas (e.g. olive grove, pasture, etc.), or the constructions on the parcel (e.g. buildings, apartments, factories, etc.). The land use type of a parcel can be changed by the request of the land parcel owner(s). Land tenure records: The status of rights on land parcels, and the restrictions on these rights are gathered during the first cadastral survey. Land parcel boundaries, information about the owner(s), ownership information such as ownership rate, ownership transfer by inheritance, ownership date, etc., and restrictions on ownership rights such as mortgage, usage right of another parcel or person, property renting, etc., are some major information on land rights.
Owner’s and expertise people’s declaration and existing documents such as old title deeds, court’s sentences, etc., are used for determining the land rights. Also, disputes such as boundary disagreement between neighbouring parcels, ownership disagreement on a parcel between different people are determined and sent to the relevant court for final decision. After first cadastral survey, title deed books are written and transferred to the Land Registry Offices. Operations on land rights, such as property conveyancing, mortgage treatments, etc., are carried out by Land Registry Offices.
2.2.1.3 The Cadastre and Land Registration Processes
Cadastral works in Turkey are performed in two major phases. In the first phase, the cadastral offices carry out first cadastral survey in a city quarter or village, which has no land registration records earlier. Until the first cadastral survey finishes, all land-related laws are available for the land rights, but they are not registered by the state. By finishing the first cadastral survey, all land rights become clear and definite, except the land parcels which have conflicts. After finishing the first cadastral survey, as the second phase, the constituted
18
title deed books and base documents are transferred to the land registry office. The cadastral maps and the surveying documents are kept in the cadastral office. The modification operations on parcel boundaries and cadastral maps are carried out by cadastral offices. Manipulation operations on land rights, such as property conveyancing, etc., are carried out by land registry offices.
The cadastral surveys for quarters and villages are planned by TKGM and approved by the relevant ministry of TKGM. According to this plan, geodetic network points are established by the Photogrammetry and Geodesy Department and the related cadastral office. The cadastral surveys are then made by the field surveyors of the corresponding cadastral office. Land rights are also exposed by them with the help of elderly expertise people and the chief of the settlement area together with the old title deeds and other land tenure documents. Two main end products are obtained during the first phase of the cadastral work that are the cadastral maps and the title deed books.
In the second phase, the maintenance and update of cadastral data are provided by the Land Registry and Cadastre Offices. If the first cadastral survey has not been performed, no land registry and cadastre operation can be done by these offices. The works of the Land Registry Office and the Cadastre Office are synchronized. The modification operations are made by either the owner(s) request or a court’s decision.
The first cadastral survey of all the country has not been completed yet. By 1997, considering the total number of quarters in Turkey, 94.87 percent of cadastral survey was completed in urban areas. In addition, considering the total number of villages, 62 percent of cadastral survey was completed in rural areas. On the other hand, cadastral renewal works are needed in a number of cities, especially for those which had the first cadastral survey in 1950s. Time, personnel, and the money required for the first cadastral survey, cadastral renewal works, and the update operations are in huge amount. Completing the cadastral survey in a short period of time will prevent the country from an economical loss, such as the loss of land taxes, unregistered state lands, etc., and will help solve the legal problems such as land lawsuits. The use of the new technology in surveying methods and a better data management will speed up the cadastral work processes.
19
2.3 Geographical Information Systems
The history of using computers for mapping and spatial analysis shows that there have been parallel developments in automated data capture, data analysis, and presentation in several broadly related fields. These fields are cadastral and topographical mapping, thematic cartography, civil engineering, geography, mathematical studies of spatial variation, soil science, surveying and photogrametry, rural and urban planning, utility networks, and remote sensing (Burrough, 1985).
All these disciplines are attempting the same sort of operation- namely to develop a powerful set of tools for collection, storing, retrieving at will, transforming and displaying spatial data from the real world for a particular set of purposes. This set of tools constitutes a “Geographical Information System” (Burrough, 1985).
GIS is also a useful tool for integrated analysis of the spatial and non-spatial data. A classification of GIS analysis functions is given in figure 2.6. System design is important for GISs for efficient data storage, retrieval, and analysis. Data models and database modeling technologies should be studied well before a GIS design.
2.3.1 Spatial Data Models
Geographical data describe objects from real world in terms of (a) their position with respect to a known coordinate system, (b) their attributes that are unrelated to position, and (c) their spatial interrelations with each other (topological relations), which describe how they are linked together or how one can travel between them (Burrough, 1985).
There are two fundamental approaches to the representation of the spatial component of geographic information: the vector model and the raster model. In vector model, objects or conditions in the real world are represented by the points, lines and polygons that define their boundaries, much as if they were being drawn on a map. The position of each object is defined by its placement in a map space that is organized by a coordinate reference system. A number of systems have been devised to organize the storage of point, line, and polygon coordinate data. The early ones organize the vector data in spaghetti model, which encodes all geometric elements as a list of XY coordinate pairs. The latest systems use the topological model to represent geographic data. Topology is a mathematical model used to
20
define spatial relationships. More complex definitions of points, lines, and polygons can be used to capture internal structure of an entity; these definitions may be functional or descriptive.
1. MAINTENANCE AND ANALYSIS OF THE SPATIAL DATA
Format Transformations Geometric Transformations Transformations Between Map Projections Conflation Edge Matching Editing Of Graphic Elements Line Coordinate Thinning
2. MAINTENANCE AND ANALYSIS OF THE ATTRIBUTE DATA
Attribute Editing Functions Attribute Query Functions
3. INTEGRATED ANALYSIS OF SPATIAL AND ATTRIBUTE DATA
Retrieval/Classification Measurement
Retrieval Classification Measurement
Overlay Operations Neighborhood Operations Search
Connectivity Functions
4. OUTPUT FORMATTING
Map Annotation Text Labels Texture Patterns And Line Styles Graphic Symbols
Figure 2.6: A classification of GIS analysis functions (Aranoff, 1989).
21
Line-In-Polygon And Point-InPolygon Thiessen Polygons Interpolation Contour Generation Contiguity Measures Proximity Network Spread Seek Intervisibility Illumination Perspective View
In raster model, the space is regularly subdivided into cells (usually square in shape). The location of geographic objects or conditions is defined by the row and column position of the cells they occupy. The area that each cell represents defines the spatial resolution available (Aranoff, 1989). Two data models can be used for modeling raster data. In run-length encoding, adjacent cells along a row that have the same value are treated as a group termed a run (Aranoff, 1989). The quadtree data model provides a more compact raster representation by using a variable-sized grid cell. Instead of dividing an area into cells of one size, finer subdivisions are used in those areas with finer detail (Aranoff, 1989).
2.3.2 Spatial Relationships
Spatial relationships are determined in terms of the spatial extents of the objects being related. For example, river R “traverses” land parcel LP is a spatial relationship. The spatial relationships are subdivided into three subsets: topological (e.g., “inside”, “outside”), directional (e.g., “North of”, “North-East of”), and metric (e.g., “five km away from”) relationships (Tryfona and Jensen, 1998).
Spatial relationships are generally very numerous, may be complex, and are important. Only some of the spatial relationships are explicitly defined in the GIS, and the remainder is either calculated as needed or is not available (Aranoff, 1989).
2.3.3 Spatial Databases
A database is a collection of objects, which represent part of the real world. Each object belongs to an object class, which is characterized by a set of properties or attributes. Each attribute is associated with a domain, which is a set of values. A database is called spatial, temporal, or spatiotemporal if it manages spatial, temporal, or spatiotemporal concepts, respectively (Pfoser and Tryfona, 1998).
Spatial databases store information related to spatial locations, and provide support for efficient querying and indexing based on spatial locations. A spatial database would use special-purpose index structures, such as R-trees, k-d trees, quadtrees, R-trees, etc. Traditional index structures, such as hash indices and B-trees, are not suitable, since they only deal with one-dimensional data, whereas spatial data are typically of two or more dimensions (Silberschatz et al, 1997).
22
2.3.4 Time in Databases
Two general, orthogonal temporal aspects have widespread attention, namely valid time and transaction time. The valid time of a database fact is the time when the fact is true in the miniworld. Different time types may be used when modeling the valid-time aspect, e.g., single time instants, intervals, or sets of intervals (Gregersen and Jensen, 1999).
Orthogonal to valid time, transaction time of a database fact is the time when the fact is current in the database and may be retrieved. The transaction time has a duration: from insertion to (logical) deletion (Gregersen and Jensen, 1999).
Two basic models of time are used to record facts and information of a database: time points and time intervals. A time point t1 is considered as one chronon, while a time interval [tk,tm] with tk,tm time points and m'01-JAN-76' 97
Figure 6.7: The execution and the results of query 3.
Query 4: List the numbers of the parcels that were owned by ‘Tuna Mühendislik’ in the last 15 years in Çankaya district (figure 6.8). The SQL statement of the query is as follows:
SELECT jn.name||' '||p.pid||' '||j.startdate||' '||j.enddate||' '||j.rate1||' '||j.rate2 Tuna_Muhendislik_Tasinmazlari FROM jperson_name jn, jp_parcel_own j, parcel p WHERE jn.id=j.jperson_id AND j.parcel_obj_id=p.obj_id AND jn.name LIKE 'TUNA MÜHENDISLIK%' AND j.startdate>'01-JAN-86'
Figure 6.8: The list of the parcels owned by ‘Tuna Mühendislik’ company in the last 15 years.
98
Query 5: What changes have occured in the geometry of parcel 1 of block 13055 located in Çayyolu for the last 15 years? This query is of a spatiotemporal type. The query results are represented in figure 6.9. Each geometry was coloured and labelled separately according to their start date. The SQL statement of the query is as follows:
SELECT pg.obj_id, pg.geom_start FROM parcel p, parcel_geom pg WHERE pg.obj_id=(SELECT obj_id FROM parcel WHERE pid=’0601003a13055p1’) AND pg.geom_start>’01-JAN-86’
Figure 6.9: The changes in the geometry of parcel 1 in block 13055 located in Çayyolu for the last 15 years.
Query 6: Which parcel was added last to the parcel block 13064 in Çayyolu quarter? The result of the query is represented in figure 6.10. The SQL statements used for the query is as follows:
SELECT MAX(stdate), pid FROM parcel WHERE obj_id=(SELECT parcel_geom.obj_id FROM parcel_geom, pblock_geom WHERE pblock_geom.obj contains parcel_geom.obj AND pblock_geom.obj_id=(SELECT obj_id FROM pblock WHERE pblock_id=13064))
99
Figure 6.10: The land parcels located in parcel block 13064 recently.
100
CHAPTER 7
CONCLUSIONS and THE RECOMMENDATIONS
In this thesis, a spatiotemporal database design was studied for establishing a cadastral information system in Turkey. A system requirements analysis for a cadastral database was carried out in Turkey’s context. The basic cadastral queries showed that a cadastral database should store historical information on land parcels and related objects. A spatial and temporal database modeling approach is inevitable to design and implement a cadastral database. The database should store information on spatial and temporal object types and the relationships. In addition, temporal attributes of the objects and the relationships should be kept in the database. No spatial or spatiotemporal attribute type was defined during the system analysis phase. The integrated analysis of land registry and cadastral data, which were stored separately, is another important property required for a cadastral database. The major advantages of an integrated system approach are (i) to prevent the system from data inconsistency and update anomalies, (ii) to provide integrated analysis of land registry and cadastral data, and (iii) to speed up the cadastral processes.
Modern cadastres tend towards a Land Information System (LIS) approach. However, the cadastral system in Turkey is not in a LIS approach. In this study, the system requirements were analyzed in accordance to the data collected for the existing cadastral system. The restrictions on land rights, such as mortgage, usage rights, etc., were not considered during the system requirements analysis phase. The cadastral data should form a base for other applications, such as municipality works, engineering projects, etc. The proposed database design can provide a competent service for TKGM for spatial objects. However, the cadastral data requirements of other institutions, which produce maps, have not been considered during the design. For covering the requirements of other institutions and 101
applications, while analyzing the cadastral system, the requirements of a LIS should be considered. A LIS would also support the land management services in Turkey.
The selected conceptual model, Spatiotemporal Entity Relationship (STER) model, has met the requirements for a spatiotemporal conceptual model. It can be used for any spatiotemporal database design application. Learning and using the STER model does not require an intensive effort. It is orthogonal to Entity-Relationship (ER) model and can be added to or removed from the traditional ER model constructs when necessary. In short, the STER model is an easy-to-use conceptual model.
Adding Enhanced ER (EER) model constructs to the STER model has improved the expression power of the STER model. The resultant model met the requirements to represent the specialization relationships of the cadastral database at conceptual level. The EER model constructs have been added to STER model in an orthogonal way. They can be used when a specialization/generalization relationship is necessary to be represented in the database.
At logical design phase, Oracle 8i Spatial was chosen as spatial DBMS software due to its spatial data handling capability. The Oracle 8i Spatial was adequate for storing and managing the spatial data. It stores spatial data in both an object-relational or relational structure. But, it does not provide graphical data display and analysis tools. Additional application software are needed therefore for graphical display, interactive editing of graphic data and spatial analysis. To solve these deficiencies of Oracle 8i Spatial, MapInfo 6.0 was used in this study.
There were a few integration problems between Oracle 8i Spatial and MapInfo 6.0. While retrieving the graphical data from Oracle 8i database using MapInfo 6.0, the data were stored in MapInfo format. This problem causes duplication in storing the data. In addition, several spatial object types of MapInfo 6.0 were not defined in Oracle 8i Spatial, for example, ellipse objects, text objects, etc. This causes the loss of data. Another limitation occurred in using MapInfo 6.0 was that it allows only one nested query, which raises difficulties for invoking complex spatial and spatiotemporal queries. A single DBMS software having graphical data storage, display, editing, and analysis tools would be the best solution for a cadastral database.
102
Although the geometry of spatial objects were stored in an object-relational approach in Oracle 8i Spatial, the relational mapping algorithms were applied on schema. The geometry data were considered as atomic attributes and were excluded from first normal form. The transformation from conceptual schema into the logical schema was succeeded without any loss of information. The relations in the logical schema have formed the database tables. However, while tailoring the logical schema into Oracle 8i Spatial, the coordinate system and the symbol attributes of the relations could not be realized and lost therefore. By adding a few application programs, the loss of these attributes can be prevented.
At the system implementation phase, a study area in Çankaya District, Ankara was selected. The study area was adequate to represent the capabilities and the deficiencies of the designed database. Due to several problems with data, such as lack of data, data existing in hardcopy format, etc., not all the data required by the proposed design were able to be loaded into the database. To perform the test queries required in the system analysis phase, fictitious data were inserted into the database. Establishing cadastral information system or a LIS for the whole country, data collection, editing, and loading will seem to be a major problem. Tremendous amount of the time and labor will be spent for data collection and editing phase during the system development process.
A cadastral information system should be constituted and maintained by General Directorate of Land Registry and Cadastre (TKGM) due to its legal responsibilities on cadastral data. Besides, the data should be shared between those institutions that require cadastral data as base information for their applications. Municipalities, courts, and Ministry of Forest, can be listed among these institutions.
The followings are recommended for further studies on Cadastral Information System of Turkey:
The requirements of a LIS can be analyzed and a system can be developed. Such a
system should provide a better service for land management and meet the cadastral data requirements of other institutions that are interested in geographical data.
The proposed database schema in this study can be extended by adding the restrictions of
land rights. In addition, database security is very important for land registry and cadastral data due to their legal aspects. According to the internal organizational design, user profiles,
103
user’s data access rights and restrictions, and the database backup and recovery procedures should be defined. User interfaces are also needed to form. Special spatial data display and analysis tools should also be developed.
Due to the problems in cadastral data, such as the transformation between different
coordinate systems applied on cadastral maps, digitization errors of land parcel boundaries, etc., a fuzzy modeling approach can be included in the database design and development processes.
Because of the time limitation, the physical design level was not able to be focused on.
The organizational design and the hardware and network design were not able to be performed either. A real-life cadastral information system design must consider these issues. Therefore, a further study can focus on the internal and external organizational designs. An external organizational design should also include principles of the data sharing between several institutions.
104
REFERENCES
[1]
Antenucci, J.C. , Brown, K., Croswell, P.L., Kevany, M.J., Archer, H., Geographic Information Systems: A Guide to The Technology, New York, 1991.
[2]
Aronoff, S., Geographic Information Systems: A Management Perspective, WDL Publications, Ottawa, 1993.
[3]
Bacino, C. C., Automating the Parcel Mapping Process: The Montana Cadastral Project, Surveying and Land Information Systems, Vol. 59, No. 3, pp. 165-168, 1999.
[4]
Binns, Sir Bernard O., Cadastral Surveys and Records of Rights in Land, FAO Land Tenure Study, Rome, 1953.
[5]
Blais, J. A. R., Lecture Notes in Digital Mapping and Land Information, The University of Calgary, Department of Surveying Engineering, 1987.
[6]
Blanchard, B. M., Lovett, J. K., Parcel Management: A Cadastral Data Model, Proceedings, The Canadian Conference on GIS, Vol.1, Ottawa, 1994.
[7]
Burrough, P. A., Principles of Geographical Information Systems for Land Resources Assessment, Oxford Science Publications, Utrecht, 1985.
[8]
Burrough, P. A., McDonnell, R. A., Principles of Geographical Information Systems, Oxford University Press, New York, 1998.
[9]
Committee on Geodesy, Assembly of Mathematical and Physical Sciences, National Research Council, Panel on a Multipurpose Cadastre, Need For A Multipurpose
105
Cadastre, Panel on a Multipurpose Cadastre, National Academy Press, Washington D.C., 1980 [10]
Dale, P.F., McLaughlin, J., Land Information Management, Clarendon Press, Oxford, 1988.
[11]
Elmasri,
R.,
Navathe,
S.B.,
Fundamentals
of
Database
Systems,
The
Benjamin/Cummings Publishing Company, California, 1989. [12]
Ercan, O., Ülke Koşullarında Bir Kadastro Bilgi Sistemi Tasarımı ve Uygulaması, Ph.D. Thesis, Yıldız Teknik Üniversitesi, Jeodezi ve Fotogrametri Mühendisliği Bölümü, İstanbul, 1997.
[13]
Erdi, A., Türkiye Şartlarında Arazi Bilgi Sisteminin Temelleri, Ph.D. Thesis, Selçuk Üniversitesi, Jeodezi ve Fotogrametri Mühendisliği Bölümü, Konya, 1989.
[14]
Erkan, H., Kadastro Tekniği, TMMOB HKMO Yayınları, Ankara, 1995.
[15]
Gregersen, H., Jensen, C. S., Temporal Entity-Relationship Models-A Survey, IEEE Transactions on Knowledge and Data Engineering, Vol. 11, 1999.
[16]
Hadzilacos, T., Tryfona, N., An Extended Entity-Relationship Model for Geographic Applications, SIGMOD Record, Vol. 26, pp. 24-29, 1997.
[17]
Kim, Y., Kim, S., Establishment of a Parcel-based Land Information System in Korea, Surveying and Land Information Systems, Vol. 59, pp. 213-219, 1999.
[18]
KISVO, A Cadastral Information System for Developing Countries, Definition Study, KISVO Report No. 2, 1988.
[19]
Meijere, J., Lopez, M. A., Georgiadou, Y., Maintenance of Cadastral Information Systems:
A
Case
Study
from
the
Province
of
Chubut,
http://sunspot.sli.unimelb.edu.au/fig7/Brighton98/Comm7/Papers/TS26Meijere.html, 24.06.1998.
106
Argentina,
[20]
Mohamed, D. A. M., Tong, C. W., Seok, C. C. H., Cadastral Reforms in Malaysia, http://sunspot.sli.unimelb.edu.au/fig7/Brighton98/Comm7/Papers/TS3-Majid.htm, 24.06.1998.
[21]
Nichols, S., Managing Land Tenure Information For Sustainable Development, FIG XX. International Congress, Melbourne, 1994.
[22]
Oracle Spatial User’s Guide and Reference, 2000.
[23]
Oracle SQL/PLSQL, Oracle Corporation, U.S.A., 1994.
[24]
Parent, C., Spaccapietra, S., Zimanyi, E., Spatio-Temporal Conceptual Models: Data Structures+Space+Time, ACM GIS, 11/99, pp. 26-33, 1999.
[25]
Silberschatz, A., Korth, H.F., Sudarshan, S., Database System Concepts, McGrawHill, Singapore, 1997.
[26]
The UN ECE Initiative on Land Administration, Report to the CERCO Plenary Assembly, Budapest, 1995.
[27]
TKGM, Harita Kadastro Hizmetlerinde Yetmezlikler, Rapor, 1985.
[28]
TKGM, Kanunlar, Tüzükler, Yönetmelikler, Ankara, 1985.
[29]
TMMOB Harita ve Kadastro Mühendisleri Odası, Büyük Ölçekli Haritaların Yapım Yönetmeliği (Regulations for Large Scale Mapping Activities), Ankara, 1998.
[30]
Tryfona, N., Jensen, C. S., Conceptual Data Modelling for Spatiotemporal Applications, Technical Report, Chorochronos: TMR Research Network Project, www.dbnet.ece.ntua.gr/~choros, 1998.
[31]
Tryfona, N., Jensen, C. S., A Component-based Conceptual Model for Spatiotemporal Application Design, Technical Report, Chorochronos: TMR Research Network Project, www.dbnet.ece.ntua.gr/~choros, 1998.
107
[32]
TUBITAK, HAKAR Projesi, Proje Raporu, Ankara, 1986.
[33]
Qiao, Y., The Design and Development of a County/City Cadastral Information System, The Proceedings of Geoinformatics, pp. 343-347, Florida, 1996.
[34]
Yalın, D., Türkiye Koşullarında Çok Amaçlı Kadastro Sistemi ve Sistemin Otomasyonu, Ph.D. Thesis, İstanbul Teknik Üniversitesi, Jeodezi ve Fotogrametri Mühendisliği Bölümü, İstanbul, 1986.
108
APPENDIX A
AN ABSTRACT SCHEMA DESIGN FOR CADASTRAL DATA USING THE STER MODEL
et
tt
svt
stt
Parcel
M
is_located_at vt s
P_block M
et
tt
svt
stt
M is located at
is located at vt s
vt
vt
s
s
1
1 Cw_id
M is located at
1
vt
name
1
Village_id Quarter
et
tt
svt
stt
et
tt
svt
stt
Village vt
name M
1
M
belongs_to is located at
is located at
vt
vt
vt
s
s
s
1
M
1 et
tt
svt
stt
District name
et
tt
svt
stt
Villageward
District_id vt
M
vw_id
name
vt
is located at vt
Tr_code
s
1
is_part_of
Tr_code name
Province
name
et
tt
svt
stt
vt
M
s
country 1
s
Figure A.1: The abstract conceptual schema of a cadastral database prepared using STER model.
109
is_part_of et
Parcel
tt
svt
M
1
M
P_block s
stt
id
N
et
tt
svt
stt
vt
area
Oper_type vt
tt
Oper_no P_alteration type
proj
ellips
producer
prod_meth
Prod_map
Map_def
et
name cad_map
scale R
N
N is located at is located at vt
vt
s
s
M
parcel
M et
tt
svt
stt
et
tt
svt
stt
p_block
N vt
vt
s
s
is located at
vt s
is located at
M quarter
N
N
is located at
M
M
et
tt
svt
stt
village
Figure A.1: continuing…
110
et
tt
svt
stt
district
et
tt
svt
stt
et
tt
svt
stt
district
et
tt
svt
stt
quarter
1
et
tt
svt
stt
village
1
cad_map R
1
1
is located at vt
is located at
vt
s
is located at
s
M
is located at
vt
vt
s
M
s
M
et
GCP
P_no
M
producer
P
type
Prod_method
Construct
symbol
Sketch_no Route_no
d site
Posit_err
Route_fl
Route_fq
explanation
levelling
triangulation
Posit_err Elev_method
d
Tri_1-2-a3-3i
Tri_intensifying
site
Route_no
name
Route_fL
G_lat
Route_fQ
G_long
Figure A.1: continuing...
111
traversing
et
Prod_map
R
N is located in s
obj_id type name
M
definition symbol map_unit s
hydrology
mining o vegetation
energy
topography
communication
Figure A.1: continuing…
112
transportation
parks
culture
APPENDIX B
A DETAILED SCHEMA DESIGN FOR CADASTRAL DATA USING THE ER MODEL
M
P_alteration
parcel N
reason
M Oper_type
proc_no
Oper_no
Parcel_ownership start end
trans_time
rate valid_time
valid_time
Oper_date
Oper_date
Oper_time
Oper_time
N start
trans_time
person
end
d
time/id
id
start
exist time
end
trans time
start end
Jurid_person
Real_person
start end
name valid_time surname
Id
Tax no
name
Tax office name
fat name name
valid_time
start end
mot name province district Cw/village
jtype
birth place jtype
valid_time
start end
birth date sex
volume citizen page start end
Reg_info Family_order valid_time
Death date
Figure B.1: The detailed conceptual schema of a cadastral database prepared using ER model. 113
parcel
person reason rate start
N
1
Proc_no end valid_time
start end
is_located_at
Flat_ownership
start
trans_time
end
valid_time M
start end
start
id
end
exist_time
valid_time M
end
trans_time
time/id
start
start
trans_time
1
end
1
building
REGION is_located_at M
belongs_to
definition Flat_by_flat_build
story no
1
SPACE
flat no story id
block id
block id
address
flat id
usage start end
usage
value
value valid_time
start end
valid_time usage Usage
Figure B.1: continuing…
114
valid_time
start end
1
M
M
country
1
REGION
SPACE
is_located_at
belongs_to
1 Tr_code
name start valid_time
end
is_part_of M start
start
end
valid_time
end
POINT
REGION
trans_time
d
1
M
M
province
1
GEOMETRY
SPACE
belongs_to
is_located_at tr_code name time/id
1
id exist_time
start
trans_time
start
is_located_at
POINT
REGION
start valid_time
end
M
d 1
M
district
M
1 SPACE
GEOMETRY is_located_at
belongs_to
start name District_i
time/id
name
trans time
exist time
valid_time
start end
id
valid_time
trans_time
end start end
start
end
start
end
Figure B.1: continuing…
115
start
end
start
end
start
valid_time
name id
exist_time
trans_time
end POINT
start
valid_time
REGION
end Cw_id
time/id
name
start
trans_time
d
end 1
M
M
quarter
1
GEOMETRY is_located_at
SPACE
belongs_to
M is_located_at
1
1
valid_time
start
end
is_located_at
is_located_at
1
valid_time
district
valid_time M
start
M start
end
1 parcel
p_block
is_located_at POINT
valid_time
start
M
REGION
end
d 1
village
M
M GEOMETRY
is_located_at
1
valid_time name Village_id
time/id trans_time
start
end
start end
exist_time
start
start end
name valid_time
id
SPACE
belongs_to
trans_time
start end
end
Figure B.1: continuing…
116
end
start
end
start
end
id
exist_time
time/id
vw_id
end
start start
valid_time
trans_time
name
end
start
end valid_time
valid_time
name 1
1
village_ward
M
1
REGION is_located_at
SPACE
belongs_to
M start
end
valid_time belongs_to 1
village
1
1
is_located_at
is_located_at
valid_time
start
valid_time
start
end M
M
parcel
p_block
Figure B.1: continuing…
117
end
SPACE 1
belongs_to
type
M
proj
ellips
producer
prod_meth
REGION
start name
1
is_located_at
exist_time prod_map
time/id
id
1 cad_map
map_def start
is_located_at M
N
N
is_located_at
N
valid_time
start
end
is_located_at valid_time
end
district
N
is_located_at
valid_time
end
valid_time
N
start
end
scale
start M
is_located_at valid_time
end
start
end
M
M
quarter
village
M
parcel
P_block
Figure B.1: continuing…
118
time/id
producer
SPACE
id
start 1
exist time
Prod_method
end
belongs_to
symbol M
is_located_at
GCP
P_no
POINT 1
type
1
Construct Sketch_no
d Route_no site
Posit_err
Route_fl
Route_fq
explanation
Triangulation
levelling
traversing
Posit_err Elev_method
d
Tri_1-2-a3-3i
Tri_intensifying
site
Route_no
name
Route_fL
G_lat
Route_fQ
G_lon M M
is_located_at
start
is_located_at
is_located_at
valid_time
valid_time
start
end 1 district
M
M
valid_time
end
start 1
is_located_at valid_time
end
start
end
1
quarter
cad_map
Figure B.1: continuing…
119
village
1
SPACE 1 POINT
LINE
belongs_to
REGION
prod_map M
d
M
GEOMETRY 1
is_located_at is_located_in
obj_id 1
type
N
name definition symbol map_unit hydrology
mining o vegetation
energy
topography
communication
Figure B.1: continuing…
120
transportation
parks
culture
APPENDIX C
THE RELATIONS AND FUNCTIONAL DEPENDENCIES IN THE CADASTRAL DATABASE
P_ALTERATION old_obj_id
new_obj_id
oper_type valid_time process_no
fd1:
P_ALTERATION(old_obj_id, new_obj_id, date, time, process_no, oper_type) Candidate key: old_obj_id, new_obj_id, valid_time, process_no Primary key: (old_obj_id, new_obj_id, date, time, process_no)
COUNTRY tr_code
name
geo
fd1: fd2 fd3
COUNTRY(tr_code, name, geo) Candidate keys:
tr_code name geo
Primary key:
tr_code
PROVINCE obj_id
exist_time tr_code
name
fd1: fd2
121
geo (vt)
1NF R1(obj_id, exist_time(stdate, enddate), tr_code, name) Candidate key: obj_id
R2(obj_id, geo(geo, stdate, enddate)) Candidate key: obj_id, stdate
The application of 1NF was in the same way as it was in PARCEL relation explained earlier. The relations obtained after the 1NF operation obey the 2NF. However, R1 does not obey 3NF and BCNF rules because of fd2. Neither the tr_code nor name is a prime attribute or superkey. Therefore, the resultant relations that obey 1NF, 2NF, 3NF, and BCNF rules are as follows:
R1PROVINCE(obj_id, stdate, enddate, tr_code) Primary key: obj_id
R2PROVINCE_NAME(tr_code, name) Primary key: tr_code
R3PROVINCE_GEO(obj_id, geo, stdate, enddate) Primary key: obj_id, stdate
DISTRICT obj_id
exist_time name (vt)
District_id geo (vt)
fd1: fd2
1NF R1(obj_id, exist_time(stdate, enddate), district_id) Candidate key: obj_id
R2(obj_id, name(name, stdate, enddate)) Candidate key: obj_id, stdate
R3(obj_id, geo(geo, stdate, enddate)) Candidate key: obj_id, stdate
122
The application of 1NF was in the same way as it was in PARCEL relation explained earlier. The relations obtained after 1NF operation also obey 2NF, 3NF, and BCNF rules. Although the fd2 was lost after 1NF had been applied, it was accepted. The resultant relations that obey 1NF, 2NF, 3NF, and BCNF rules are as follows:
R1DISTRICT(obj_id, stdate, enddate, district_id) Primary key: obj_id
R2DISTRICT_NAME(obj_id, name, stdate, enddate) Primary key: obj_id, stdate
R3DISTRICT_GEO(obj_id, geo, stdate, enddate) Primary key: obj_id, stdate
PROVINCE_ISPARTOF_COUNTRY province.obj_id
country.tr_code valid_time
fd1:
PROVINCE_ISPARTOF_COUNTRY(province.obj_id, country.tr_code, valid_time(stdate)) Candidate key: province.obj_id, country.tr_code Primary key: province.obj_id, country.tr_code
QUARTER obj_id
exist_time Name (vt) cw_id
fd1: fd2
1NF R1(obj_id, exist_time(stdate, enddate), cw_id) Candidate key: obj_id
R2(obj_id, name(name, stdate, enddate)) Candidate key: obj_id, stdate
R3(obj_id, geo(geo, stdate, enddate))
123
geo (vt)
Candidate key: obj_id, stdate
These relations also obey 2NF, 3NF and BCNF rules, but fd2 was lost. Therefore, resultant relations that obey 1NF, 2NF, 3NF and BCNF rules were:
R1QUARTER(obj_id, stdate, enddate, cw_id) Primary key: obj_id
R2CW_NAME(obj_id, name, stdate, enddate) Primary key: obj_id, stdate
R3CW_GEO(obj_id, geo, stdate, enddate) Primary key: obj_id, stdate
QUARTER_ISLOCATEDAT_DISTRICT district.obj_id
Quarter.obj_id
valid_time
fd1:
QUARTER_ISLOCATEDAT_DISTRICT(quarter.obj_id, district.obj_id, valid_time(stdate, enddate)) Candidate key: quarter.obj_id, district.obj_id Primary key: quarter.obj_id, district.obj_id
VILLAGE
obj_id
exist_time name (vt)
village_id
geo (vt)
fd1: fd2
1NF R1(obj_id, exist_time(stdate, enddate), village_id) Candidate key: obj_id
R2(obj_id, name(name, stdate, enddate)) Candidate key: obj_id, stdate
124
R3(obj_id, geo(geo, stdate, enddate)) Candidate key: obj_id, stdate
These relations also obey 2NF, 3NF and BCNF rules, but fd2 was lost. Therefore, resultant relations that obey 1NF, 2NF, 3NF and BCNF were:
R1VILLAGE(obj_id, stdate, enddate, village_id) Primary key: obj_id
R2VILLAGE_NAME(obj_id, name, stdate, enddate) Primary key: obj_id, stdate
R3VILLAGE_GEO(obj_id, geo, stdate, enddate) Primary key: obj_id, stdate
VILLAGE_ISLOCATEDAT_DISTRICT
district.obj_id
village.obj_id
valid_time
fd1:
VILLAGE_ISLOCATEDAT_DISTRICT(district.obj_id, village.obj_id, valid_time(stdate, enddate)) Candidate key: village.obj_id, district.obj_id Primary key: village.obj_id, district.obj_id
PARCEL_ISLOCATEDAT_QUARTER Parcel.obj_id
quarter.obj_id
valid_time
fd1:
PARCEL_ISLOCATEDAT_QUARTER(parcel.obj_id, quarter.obj_id, valid_time(stdate, enddate)) Candidate key: parcel.obj_id, quarter.obj_id Primary key: parcel.obj_id, quarter.obj_id
125
PARCEL_ISLOCATEDAT_VILLAGE
Parcel.obj_id
village.obj_id
valid_time
fd1:
PARCEL_ISLOCATEDAT_VILLAGE(parcel.obj_id, village.obj_id, valid_time(stdate, enddate)) Candidate key: parcel.obj_id, village.obj_id Primary key: parcel.obj_id, village.obj_id
PBLOCK_ISLOCATEDAT_QUARTER
Pblock.obj_id
quarter.obj_id
Valid_time
fd1:
PBLOCK_ISLOCATEDAT_QUARTER(pblock.obj_id, quarter.obj_id, valid_time(stdate, enddate)) Candidate key: pblock.obj_id, quarter.obj_id Primary key: pblock.obj_id, quarter.obj_id
PBLOCK_ISLOCATEDAT_VILLAGE
Pblock.obj_id
village.obj_id
valid_time
fd1:
PBLOCK_ISLOCATEDAT_VILLAGE(pblock.obj_id, village.obj_id, valid_time(stdate, enddate)) Candidate key: pblock.obj_id, village.obj_id Primary key: pblock.obj_id, village.obj_id
VILLAGEWARD
obj_id
exist_time name(vt)
vw_id
fd1:
1NF R1(obj_id, exist_time(stdate, enddate), vw_id) 126
geo (vt)
Candidate key: obj_id
R2(obj_id, name(name, stdate, enddate)) Candidate key: obj_id, stdate
R3(obj_id, geo(geo, stdate, enddate)) Candidate key: obj_id, stdate
These relations also obey 2NF, 3NF and BCNF rules. Therefore, the resultant relations that obey 1NF, 2NF, 3NF and BCNF were:
R1VILLAGEWARD(obj_id, stdate, enddate, vw_id) Primary key: obj_id
R2VW_NAME(obj_id, name, stdate, enddate) Primary key: obj_id, stdate
R3VW_GEO(obj_id, geo, stdate, enddate) Primary key: obj_id, stdate
VILLAGEWARD_BELONGSTO_VILLAGE villageward.obj_id village.obj_id
valid_time
fd1:
VILLAGEWARD_BELONGSTO_VILLAGE(villageward.obj_id, village.obj_id, valid_time(stdate, enddate)) Candidate key: villageward.obj_id, village.obj_id Primary key: villageward.obj_id, village.obj_id
JURIDICAL_PERSON
id
exist_time
Tax_no (vt)
tax_office (vt)
fd1:
127
name (vt)
jtype (vt)
1NF R1(id, exist_time(stdate, enddate)) Candidate key: id
R2(id, tax_no(tax_no, stdate, enddate)) Candidate key: (id, stdate)
R3(id, tax_office(tax_office, stdate, enddate)) Candidate keys: (id, stdate)
R4(id, name(name, stdate, enddate)) Candidate keys: (id, stdate)
R5(id, jtype(jtype, stdate, enddate)) Candidate keys: (id, stdate)
These relations obey 1NF, 2NF, 3NF and BCNF rules. Therefore, the resultant relations are:
R1JPERSON(id, stdate, enddate) Primary key: id
R2JPERSON_TAX_NO(id, tax_no, stdate, enddate) Primary key: (id, stdate)
R3JPERSON_TAX_OFFICE(id, tax_office, stdate, enddate) Primary key: (id, stdate)
R4JPERSON_NAME(id, name, stdate, enddate) Primary key: (id, stdate)
R5JPERSON_TYPE(id, jtype, stdate, enddate) Primary key: (id, stdate)
128
BUILDING_ISLOCATEDAT_PARCEL parcel.obj_id
building.obj_id
valid_time
fd1:
BUILDING_ISLOCATEDAT_PARCEL(parcel.obj_id, building.obj_id, valid_time(stdate, enddate)) Candidate key: (parcel.obj_id, building.obj_id) Primary key: (parcel.obj_id, building.obj_id)
MAP_DEF
name
scale
geo
fd1: fd2:
MAP_DEF (name, scale, geo) Candidate keys:
name geo
Primary key:
name
PROD_MAP
obj_id exist_time name scale
geo
type pro ellips j
producer prod_method
fd1:
PROD_MAP(obj_id, stdate, enddate, name, scale, geo, type, proj, ellips, producer, prod_method) Candidate key: obj_id Primary key: obj_id
129
PARCEL_ISLOCATEDAT_MAP_DEF
parcel.obj_id
Map_def.name
valid_time
fd1:
PARCEL_ISLOCATEDAT_MAP_DEF(parcel.obj_id, map_def.name, valid_time(stdate, enddate)) Candidate key: (parcel.obj_id, map_def.name) Primary key: (parcel.obj_id, map_def.name)
PARCEL_ISLOCATEDAT_PROD_MAP
parcel.obj_id
Prod_map.obj_id
valid_time
fd1:
PARCEL_ISLOCATEDAT_PROD_MAP(parcel.obj_id, prod_map.obj_id, valid_time(stdate, enddate)) Candidate key: (parcel.obj_id, prod_map.obj_id) Primary key: (parcel.obj_id, prod_map.obj_id)
PBLOCK_ISLOCATEDAT_MAP_DEF
Pblock.obj_id map_def.name
valid_time
fd1:
PBLOCK_ISLOCATEDAT_MAP_DEF(pblock.obj_id, map_def.name, valid_time(stdate, enddate)) Candidate key: (pblock.obj_id, map_def.name) Primary key: (pblock.obj_id, map_def.name)
PBLOCK_ISLOCATEDAT_PROD_MAP
pblock.obj_id prod_map.obj_id valid_time fd1:
130
PBLOCK_ISLOCATEDAT_PROD_MAP(pblock.obj_id, prod_map.obj_id, valid_time (start, end)) Candidate key: (pblock.obj_id, prod_map.obj_id) Primary key: (pblock.obj_id, prod_map.obj_id)
QUARTER_ISLOCATEDAT_MAP_DEF
quarter.obj_id
map_def.name
valid_time
fd1:
QUARTER_ISLOCATEDAT_MAP_DEF(quarter.obj_id, map_def.name, valid_time(start, end)) Candidate key: (quarter.obj_id, map_def.name) Primary key: (quarter.obj_id, map_def.name)
QUARTER _ISLOCATEDAT_PROD_MAP
quarter.obj_id
rod_map.obj_id valid_time
fd1:
QUARTER_ISLOCATEDAT_PROD_MAP(quarter.obj_id, prod_map.obj_id, valid_time(start, end)) Candidate key: (quarter.obj_id, prod_map.obj_id) Primary key: (quarter.obj_id, prod_map.obj_id)
VILLAGE_ISLOCATEDAT_MAP_DEF
village.obj_id map_def.name
valid_time
fd1:
VILLAGE_ISLOCATEDAT_MAP_DEF(village.obj_id, map_def.name, valid_time(start, end)) Candidate key: (village.obj_id, map_def.name) Primary key: (village.obj_id, map_def.name)
131
VILLAGE_ISLOCATEDAT_PROD_MAP
village.obj_id prod_map.obj_id valid_time fd1:
VILLAGE_ISLOCATEDAT_PROD_MAP(village.obj_id, prod_map.obj_id, valid_time(start, end)) Candidate key: (village.obj_id, prod_map.obj_id) Primary key: (village.obj_id, prod_map.obj_id)
DISTRICT_ISLOCATEDAT_MAP_DEF
district.obj_id map_def.name
valid_time
fd1:
DISTRICT_ISLOCATEDAT_MAP_DEF(district.obj_id, map_def.name, valid_time(start, end)) Candidate key: (district.obj_id, map_def.name) Primary key: (district.obj_id, map_def.name)
DISTRICT_ISLOCATEDAT_PROD_MAP
district.obj_id Prod_map.obj_id valid_time fd1:
DISTRICT_ISLOCATEDAT_PROD_MAP(district.obj_id, prod_map.obj_id, valid_time(start, end)) Candidate key: (district.obj_id, prod_map.obj_id) Primary key: (district.obj_id, prod_map.obj_id)
GCP
obj_i exist_tim P_no type construc sketch_n symbol produce prod_metho geo d e t o r d fd1: fd2:
132
This relation obeys to 1NF and 2NF, but it does not obey 3NF due to fd2. Because neither ‘type’ nor ‘symbol’ attributes are candidate keys or prime attributes. Therefore, the relations that obey to 3NF are:
R1(obj_id, exist_time(start, end), p_no, type construct, sketch_no, producer, prod_method, geo) Candidate key:.obj_id
R2(type, symbol) Candidate keys:
type symbol
These relations obey 1NF, 2NF, 3NF and BCNF. Therefore, the resultant relations are:
R1GCP(obj_id, start, end, p_no, type construct, sketch_no, producer, prod_method, geo) Primary key:.obj_id
R2GCP_SYMBOL(type, symbol) Primary key: type
LEVELLING_POINTS
gcp.obj_id
site
posit_err
explanation
fd1:
LEVELLING(gcp.obj_id, site, posit_err, explanation) Candidate key: gcp.obj_id Primary key: gcp.obj_id
TRI_1-2-A3-3I_POINTS
gcp.obj_id
name
site
posit_err
fd1:
133
elev_method
G_lat
G_lon
TRI_1-2-A3-3I(gcp.obj_id, name, site, posit_err, elev_method, G_lat, G_lon) Candidate key: gcp.obj_id Primary key: gcp.obj_id
TRI_INTENSIFYING_POINTS
Gcp.obj_id
Posit_err
Elev_method route_no route_fL route_fQ
fd1:
TRI_INTENSFYING(gcp.obj_id, posit_err, elev_method, route_no, route_fL, route_fQ) Candidate key: gcp.obj_id Primary key: gcp.obj_id
TRAVERSE_POINTS
gcp.obj_id
route_no route_fl
route_fq
fd1:
TRAVERSE(gcp.obj_id, route_no, route_fl, route_fq) Candidate key: gcp.obj_id Primary key: gcp.obj_id
GCP_ISLOCATEDAT_DISTRICT
GCP.obj_id
district.obj_id
valid_time
fd1:
GCP_ISLOCATEDAT_DISTRICT(district.obj_id, gcp.obj_id, valid_time(start, end)) Candidate key: (district.obj_id, gcp.obj_id) Primary key: (district.obj_id, gcp.obj_id)
GCP_ISLOCATEDAT_QUARTER
GCP.obj_id
quarter.obj_id
valid_time
fd1:
134
GCP_ISLOCATEDAT_QUARTER(quarter.obj_id, gcp.obj_id, valid_time(start, end)) Candidate key: (quarter.obj_id, gcp.obj_id) Primary key: (quarter.obj_id, gcp.obj_id)
GCP_ISLOCATEDAT_MAP_DEF
GCP.obj_id
Map_def.name
valid_time
fd1:
GCP_ISLOCATEDAT_MAP_DEF(gcp.obj_id, map_def.name, valid_time(start, end)) Candidate key: (gcp.obj_id, map_def.name) Primary key: (gcp.obj_id, map_def.name)
GCP_ISLOCATEDAT_PROD_MAP
GCP.obj_id
Prod_map.obj_id valid_time
fd1:
GCP_ISLOCATEDAT_PROD_MAP(gcp.obj_id, prod_map.obj_id, valid_time(start, end)) Candidate key: (gcp.obj_id, prod_map.obj_id) Primary key: (gcp.obj_id, prod_map.obj_id)
GCP_ISLOCATEDAT_VILLAGE GCP.obj_id
village.obj_id
valid_time
fd1:
GCP_ISLOCATEDAT_VILLAGE(gcp.obj_id, village.obj_id, valid_time(start, end)) Candidate key: (gcp.obj_id, village.obj_id) Primary key: (gcp.obj_id, village.obj_id)
135
HYDROLOGY obj_id name
type
definition
symbol
geo
fd1: fd2:
This relation obeys to 1NF and 2NF rules, but it does not obey 3NF rules due to fd2. Because neither ‘type’ nor ‘symbol’ attributes are candidate keys or prime attributes. Therefore, the relations that obey to 3NF were:
R1(obj_id, name, type, definition, geo) Candidate key: obj_id
R2(type, symbol) Candidate keys:
type symbol
These relations obey 1NF, 2NF, 3NF and BCNF rules. Therefore, the resultant relations are:
R1HYDROLOGY(obj_id, name, type, definition, geo) Primary key: obj_id
R2HYDROLOGY_SYMBOL(type, symbol) Primary key: type
MINING
obj_id name
type
definition
symbol
geo
fd1: fd2:
This relation obeys to 1NF and 2NF rules, but it does not obey 3NF rules due to fd2. Because neither type nor symbol attributes are candidate keys or prime attributes. Therefore, the relations that obey to 3NF rules were:
136
R1(obj_id, name, type, definition, geo) Candidate key: obj_id
R2(type, symbol) Candidate keys:
type symbol
These relations obey 1NF, 2NF, 3NF and BCNF rules. Therefore, the resultant relations are:
R1MINING(obj_id, name, type, definition, geo) Primary key: obj_id
R2MINING_SYMBOL(type, symbol) Primary key: type
VEGETATION
obj_id name
type
Definition
symbol
geo
fd1: fd2:
This relation obeys to 1NF and 2NF rules, but it does not obey 3NF rules due to fd2. Because neither type nor symbol attributes are candidate keys or prime attributes. Therefore, the relations that obey to 3NF rules were:
R1(obj_id, name, type, definition, geo) Candidate key: obj_id
R2(type, symbol) Candidate keys:
type symbol
These relations obey 1NF, 2NF, 3NF and BCNF rules. Therefore, the resultant relations are:
R1VEGETATION(obj_id, name, type, definition, geo)
137
Primary key: obj_id
R2VEGETATION_SYMBOL(type, symbol) Primary key: type ENERGY
obj_id name
type
definition
symbol
geo
fd1: fd2:
This relation obeys to 1NF and 2NF rules, but it does not obey 3NF rules due to fd2. Because neither type nor symbol attributes are candidate keys or prime attributes. Therefore, the relations that obey to 3NF rules are:
R1(obj_id, name, type, definition, geo) Candidate key: obj_id
R2(type, symbol) Candidate keys:
type symbol
These relations obey 1NF, 2NF, 3NF and BCNF rules. Therefore, the resultant relations are:
R1ENERGY(obj_id, name, type, definition, geo) Primary key: obj_id
R2ENERGY_SYMBOL(type, symbol) Primary key: type
COMMUNICATION
obj_id name
type
definition
symbol
fd1: fd2:
138
geo
This relation obeys to 1NF and 2NF rules, but it does not obey 3NF rules due to fd2. Because neither type nor symbol attributes are candidate keys or prime attributes. Therefore, the relations that obey to 3NF were:
R1(obj_id, name, type, definition, geo) Candidate key: obj_id
R2(type, symbol) Candidate keys:
type symbol
These relations obey 1NF, 2NF, 3NF and BCNF rules. Therefore, the resultant relations are:
R1COMMUNICATION(obj_id, name, type, definition, geo) Primary key: obj_id
R2COMMUNICATION_SYMBOL(type, symbol) Primary key: type
TRANSPORTATION
obj_id name
Type
definition
symbol
geo
fd1: fd2:
This relation obeys to 1NF and 2NF rules, but it does not obey 3NF rules due to fd2. Because neither type nor symbol attributes are candidate keys or prime attributes. Therefore, the relations that obey to 3NF are:
R1(obj_id, name, type, definition, geo) Candidate key: obj_id
R2(type, symbol) Candidate keys:
type symbol
139
These relations obey 1NF, 2NF, 3NF and BCNF rules. Therefore, the resultant relations are:
R1TRANSPORTATION(obj_id, name, type, definition, geo) Primary key: obj_id
R2TRANSPORTATION_SYMBOL(type, symbol) Primary key: type
PARKS
obj_id name
type
definition
symbol
geo
fd1: fd2:
This relation obeys to 1NF and 2NF rules, but it does not obey 3NF rules due to fd2. Because neither ‘type’ nor ‘symbol’ attributes are candidate keys or prime attributes. Therefore, the relations that obey to 3NF rules were:
R1(obj_id, name, type, definition, geo) Candidate key: obj_id
R2(type, symbol) Candidate keys:
type symbol
These relations obey 1NF, 2NF, 3NF and BCNF rules. Therefore, the resultant relations are:
R1PARKS(obj_id, name, type, definition, geo) Primary key: obj_id
R2PARKS_SYMBOL(type, symbol) Primary key: type
140
CULTURE
obj_id name
type
definition
symbol
geo
fd1: fd2:
This relation obeys to 1NF and 2NF rules, but it does not obey 3NF rules due to fd2. Because neither type nor symbol attributes are candidate keys or prime attributes. Therefore, the relations that obey to 3NF rules are:
R1(obj_id, name, type, definition, geo) Candidate key: obj_id
R2(type, symbol) Candidate keys:
type symbol
These relations obey 1NF, 2NF, 3NF and BCNF rules. Therefore, the resultant relations are:
R1CULTURE(obj_id, name, type, definition, geo) Primary key: obj_id
R2CULTURE_SYMBOL(type, symbol) Primary key: type
TOPOGRAPHY
obj_id name
type
definition
symbol
geo
fd1: fd2:
This relation obeys to 1NF and 2NF rules, but it does not obey 3NF rules due to fd2. Because neither type nor symbol attributes are candidate keys or prime attributes. Therefore, the relations that obey to 3NF rules are:
R1(obj_id, name, type, definition, geo) 141
Candidate key: obj_id
R2(type, symbol) Candidate keys:
type symbol
These relations obey 1NF, 2NF, 3NF and BCNF rules. Therefore, the resultant relations are:
R1TOPOGRAPHY(obj_id, name, type, definition, geo) Primary key: obj_id
R2 TOPO_SYMBOL(type, symbol) Primary key: type
HYDROLOGY_ISLOCATEDIN_PROD_MAP
Prod_map.obj_id
Hydrology.obj_id
HYDROLOGY_ISLOCATEDIN_PROD_MAP(prod_map.obj_id, hydrology.obj_id) Primary key: (prod_map.obj_id, hydrology.obj_id)
MINING_ISLOCATEDIN_PROD_MAP
Prod_map.obj_id
mining.obj_id
MINING_ISLOCATEDIN_PROD_MAP(prod_map.obj_id, mining.obj_id) Primary key: (prod_map.obj_id, mining.obj_id)
VEGETATION_ISLOCATEDIN_PROD_MAP
Prod_map.obj_id
vegetation.obj_id
VEGETATION_ISLOCATEDIN_PROD_MAP(prod_map.obj_id, vegetation.obj_id) Primary key: (prod_map.obj_id, vegetation.obj_id)
142
ENERGY_ISLOCATEDIN_PROD_MAP
Prod_map.obj_id
energy.obj_id
ENERGY_ISLOCATEDIN_PROD_MAP(prod_map.obj_id, energy.obj_id) Primary key: (prod_map.obj_id, energy.obj_id)
COMMUNICATION_ISLOCATEDIN_PROD_MAP
Prod_map.obj_id
communication.obj_id
COMMUNICATION_ISLOCATEDIN_PROD_MAP(prod_map.obj_id, communication.obj_id) Primary key: (prod_map.obj_id, communication.obj_id)
TRANSPORTATION_ISLOCATEDIN_PROD_MAP
Prod_map.obj_id
transportation.obj_i d
TRANSPORTATION_ISLOCATEDIN_PROD_MAP(prod_map.obj_id, transportation.obj_id) Primary key: (prod_map.obj_id, transportation.obj_id)
PARKS_ISLOCATEDIN_PROD_MAP
Prod_map.obj_id
parks.obj_id
PARKS_ISLOCATEDIN_PROD_MAP(prod_map.obj_id, parks.obj_id) Primary key: (prod_map.obj_id, parks.obj_id)
CULTURE_ISLOCATEDIN_PROD_MAP
Prod_map.obj_id
culture.obj_id
CULTURE_ISLOCATEDIN_PROD_MAP(prod_map.obj_id, culture.obj_id) Primary key: (prod_map.obj_id, culture.obj_id)
143
TOPOGRAPHY_ISLOCATEDIN_PROD_MAP
Prod_map.obj_id
Topography.obj_id
TOPOGRAPHY_ISLOCATEDIN_PROD_MAP(prod_map.obj_id, topography.obj_id) Primary key: (prod_map.obj_id, topography.obj_id)
144
APPENDIX D
DATABASE TABLES
TABLE_NAME: PARCEL_USE COLUMN NAME obj_id stdate enddate land_use
DATA TYPE number date date char
SIZE 14
50
NULL CONSTRAINTS N primary key, foreign key N primary key Y N
DDL STATEMENT: CREATE TABLE parcel_use (obj_id NUMBER(14) NOT NULL, stdate DATE NOT NULL, enddate DATE, land_use VARCHAR2(50) NOT NULL, CONSTRAINT PRIMARY KEY(obj_id, stdate), CONSTRAINT FOREIGN KEY(obj_id) REFERENCES parcel(obj_id)) TABLE_NAME: PARCEL_VALUE COLUMN NAME obj_id stdate enddate value
DATA TYPE number date date number
SIZE 14
16
NULL CONSTRAINTS N primary key, foreign key N primary key Y N
DDL STATEMENT: CREATE TABLE parcel_value (obj_id NUMBER(14) NOT NULL, stdate DATE NOT NULL, enddate DATE, value NUMBER(16) NOT NULL, CONSTRAINT PRIMARY KEY(obj_id, stdate), CONSTRAINT FOREIGN KEY(obj_id) REFERENCES parcel(obj_id)) TABLE_NAME: PBLOCK COLUMN NAME obj_id Stdate Enddate
DATA TYPE number date date
SIZE 12
145
NULL N N Y
CONSTRAINTS primary key
block_id
number
6
N
DDL STATEMENT: CREATE TABLE pblock (obj_id NUMBER(12) NOT NULL, stdate DATE NOT NULL, enddate DATE, block_id NUMBER(6) NOT NULL, CONSTRAINT PRIMARY KEY(obj_id)) TABLE_NAME: PBLOCK_GEO COLUMN NAME obj_id area area_stdate area_enddate geo_stdate geo_enddate geo
DATA TYPE number number date date date date geometry
SIZE 12 13
NULL CONSTRAINTS N primary key, foreign key N N Y N primary key Y N
DDL STATEMENT: CREATE TABLE pblock_geo (obj_id NUMBER(12) NOT NULL, area NUMBER(13) NOT NULL, area_stdate DATE NOT NULL, area_enddate DATE, geo_stdate DATE NOT NULL, geo_enddate DATE, geoloc SDO_GEOMETRY NOT NULL, CONSTRAINT PRIMARY KEY(obj_id, geo_stdate), CONSTRAINT FOREIGN KEY(obj_id) REFERENCES pblock(obj_id)) TABLE_NAME: PARCEL_ISPARTOF_BLOCK COLUMN NAME p_obj_id pb_obj_id
DATA TYPE Number Number
SIZE 14 12
NULL N N
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE parcel_ispartof_block (p_obj_id NUMBER(14) NOT NULL, pb_obj_id NUMBER(12) NOT NULL, CONSTRAINT PRIMARY KEY(p_obj_id, pb_obj_id), CONSTRAINT FOREIGN KEY(pb_obj_id) REFERENCES PBLOCK(obj_id), CONSTRAINT FOREIGN KEY(p_obj_id) REFERENCES parcel(obj_id))
146
TABLE_NAME: P_ALTERATION COLUMN NAME old_obj_id new_obj_id date time process_no oper_type
DATA TYPE Number Number date number number char
SIZE 14 14 (2,2) 5 25
NULL N N N N N N
CONSTRAINTS primary key, foreign key primary key, foreign key primary key primary key primary key
DDL STATEMENT: CREATE TABLE p_alteration (old_obj_id NUMBER(14) NOT NULL, new_obj_id NUMBER(14) NOT NULL, date DATE NOT NULL, time NUMBER(2, 2) NOT NULL, process_no NUMBER(5) NOT NULL, oper_type VARCHAR2(25) NOT NULL, CONSTRAINT PRIMARY KEY(old_obj_id, new_obj_id, date, time, process_no) CONSTRAINT FOREIGN KEY(old_obj_iD) REFERENCES parcel(obj_id), CONSTRAINT FOREIGN KEY(new_obj_id) REFERENCES parcel(obj_id)) TABLE_NAME: COUNTRY COLUMN NAME tr_code name geo
DATA TYPE char char geometry
SIZE 3 30
NULL N N Y
CONSTRAINTS primary key unique
DDL STATEMENT: CREATE TABLE country (name VARCHAR2(30) NOT NULL, tr_code VARCHAR2(3) NOT NULL geoloc SDO_GEOMETRY, CONSTRAINT PRIMARY KEY(tr_code), CONSTRAINT UNIQUE(name)) TABLE_NAME: PROVINCE COLUMN NAME obj_id stdate enddate tr_code
DATA TYPE number date date number
SIZE 3
3
DDL STATEMENT: CREATE TABLE province (obj_id NUMBER(3) NOT NULL, stdate DATE NOT NULL, enddate DATE, tr_code NUMBER(3) NOT NULL, 147
NULL N N Y N
CONSTRAINTS primary key
CONSTRAINT PRIMARY KEY(obj_id)) TABLE_NAME: PROVINCE_NAME COLUMN NAME tr_code name
DATA TYPE number char
SIZE 3 15
NULL N N
CONSTRAINTS primary key, foreign key unique
NULL N N Y N
CONSTRAINTS primary key, foreign key primary key
DDL STATEMENT: CREATE TABLE province_name (tr_code NUMBER(3) NOT NULL, name VARCHAR2(15) NOT NULL, CONSTRAINT PRIMARY KEY(tr_code), CONSTRAINT FOREIGN KEY(tr_code) REFERENCES province(tr_code), CONSTRAINT UNIQUE(name)) TABLE_NAME: PROVINCE_GEO COLUMN NAME obj_id stdate enddate geo
DATA TYPE number date date geometry
SIZE 3
DDL STATEMENT: CREATE TABLE province_geo (obj_id NUMBER(3) NOT NULL, stdate DATE NOT NULL, enddate DATE, geoloc SDO_GEOMETRY NOT NULL, CONSTRAINT PRIMARY KEY(obj_id, stdate), CONSTRAINT FOREIGN KEY(obj_id) REFERENCES province(obj_id)) TABLE_NAME: PROVINCE_ISPARTOF_COUNTRY COLUMN NAME p_obj_id tr_code stdate
DATA TYPE number char date
SIZE 3 3
NULL N N N
DDL STATEMENT: CREATE TABLE province_ispartof_country (p_obj_id NUMBER(3) NOT NULL, tr_code VARCHAR2(3) NOT NULL, stdate DATE NOT NULL, CONSTRAINT PRIMARY KEY(p_obj_id, tr_code), CONSTRAINT FOREIGN KEY(p_obj_id) REFERENCES province(obj_id), CONSTRAINT FOREIGN KEY(tr_code) REFERENCES districtr(tr_code))
148
CONSTRAINTS primary key, foreign key primary key, foreign key
TABLE_NAME: DISTRICT COLUMN NAME obj_id stdate enddate district_id
DATA TYPE number date date number
SIZE 5
2
NULL N N Y N
CONSTRAINTS primary key
NULL N N N Y
CONSTRAINTS primary key, foreign key
DDL STATEMENT: CREATE TABLE district (obj_id NUMBER(5) NOT NULL, stdate DATE NOT NULL, enddate DATE, district_id NUMBER(2) NOT NULL, CONSTRAINT PRIMARY KEY(obj_id)) TABLE_NAME: DISTRICT_NAME COLUMN NAME obj_id name stdate enddate
DATA TYPE number char date date
SIZE 5 30
primary key
DDL STATEMENT: CREATE TABLE district_name (obj_id NUMBER(5) NOT NULL, name VARCHAR2(30) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(obj_id, stdate), CONSTRAINT FOREIGN KEY(obj_id) REFERENCES district(obj_id)) TABLE_NAME: DISTRICT_GEO COLUMN NAME obj_id stdate enddate geo
DATA TYPE number date date geometry
SIZE 5
NULL N N Y N
DDL STATEMENT: CREATE TABLE district_geo (obj_id NUMBER(5) NOT NULL, stdate DATE NOT NULL, enddate DATE, geoloc SDO_GEOMETRY NOT NULL, CONSTRAINT PRIMARY KEY(obj_id, stdate), CONSTRAINT FOREIGN KEY(obj_id) REFERENCES district(obj_id)) TABLE_NAME: DISTRICT_ISLOCATEDAT_PROVINCE 149
CONSTRAINTS primary key, foreign key primary key
COLUMN NAME p_obj_id c_obj_id stdate enddate
DATA TYPE number number date date
SIZE 3 5
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE district_islocatedat_province (p_obj_id NUMBER(3) NOT NULL, c_obj_id NUMBER(5) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(p_obj_id, c_obj_id), CONSTRAINT FOREIGN KEY(c_obj_id) REFERENCES district(obj_id), CONSTRAINT FOREIGN KEY(p_obj_id) REFERENCES province(obj_id)) TABLE_NAME: QUARTER COLUMN NAME obj_id stdate enddate cw_id
DATA TYPE number date date number
SIZE 7
3
NULL N N Y N
CONSTRAINTS primary key
NULL N N N Y
CONSTRAINTS primary key, foreign key
DDL STATEMENT: CREATE TABLE quarter (obj_id NUMBER(7) NOT NULL, stdate DATE NOT NULL, enddate DATE, cw_id NUMBER(3) NOT NULL, CONSTRAINT PRIMARY KEY(obj_id)) TABLE_NAME: CW_NAME COLUMN NAME obj_id name stdate enddate
DATA TYPE number char date date
SIZE 7 25
DDL STATEMENT: CREATE TABLE cw_name (obj_id NUMBER(7) NOT NULL, name VARCHAR2(25) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(obj_id, stdate), CONSTRAINT FOREIGN KEY(obj_id) REFERENCES quarter(obj_id)) 150
primary key
TABLE_NAME: CW_GEO COLUMN NAME obj_id stdate enddate geo
DATA TYPE number date date geometry
SIZE 7
NULL N N Y N
CONSTRAINTS primary key, foreign key primary key
DDL STATEMENT: CREATE TABLE district_geo (obj_id NUMBER(7) NOT NULL, stdate DATE NOT NULL, enddate DATE, geoloc SDO_GEOMETRY NOT NULL, CONSTRAINT PRIMARY KEY(obj_id, stdate), CONSTRAINT FOREIGN KEY(obj_id) REFERENCES quarter(obj_id)) TABLE_NAME: QUARTER_ISLOCATEDAT_DISTRICT COLUMN NAME cw_obj_id c_obj_id stdate enddate
DATA TYPE number number date date
SIZE 7 5
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE quarter_islocatedat_district (cw_obj_id NUMBER(7) NOT NULL, c_obj_id NUMBER(5) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(cw_obj_id, c_obj_id), CONSTRAINT FOREIGN KEY(cw_obj_id) REFERENCES quarter(obj_id), CONSTRAINT FOREIGN KEY(c_obj_id) REFERENCES district(obj_id)) TABLE_NAME: VILLAGE COLUMN NAME obj_id stdate enddate village_id
DATA TYPE number date date number
SIZE 7
3
DDL STATEMENT: CREATE TABLE village (obj_id NUMBER(7) NOT NULL, stdate DATE NOT NULL, enddate DATE, village_id NUMBER(3) NOT NULL, CONSTRAINT PRIMARY KEY(obj_id)) 151
NULL N N Y N
CONSTRAINTS primary key
TABLE_NAME: VILLAGE_NAME COLUMN NAME obj_id name stdate enddate
DATA TYPE number char date date
SIZE 7 25
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key
DDL STATEMENT: CREATE TABLE village_name (obj_id NUMBER(7) NOT NULL, name VARCHAR2(25) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(obj_id, stdate), CONSTRAINT FOREIGN KEY(obj_id) REFERENCES village(obj_id)) TABLE_NAME: VILLAGE_GEO COLUMN NAME obj_id stdate enddate geo
DATA TYPE number date date geometry
SIZE 7
NULL N N Y N
CONSTRAINTS primary key, foreign key primary key
DDL STATEMENT: CREATE TABLE village_geo (obj_id NUMBER(7) NOT NULL, stdate DATE NOT NULL, enddate DATE, geoloc SDO_GEOMETRY NOT NULL, CONSTRAINT PRIMARY KEY(obj_id, stdate), CONSTRAINT FOREIGN KEY(obj_id) REFERENCES village(obj_id)) TABLE_NAME: VILLAGE_ISLOCATEDAT_DISTRICT COLUMN NAME v_obj_id c_obj_id stdate enddate
DATA TYPE number number date date
SIZE 7 5
NULL N N N Y
DDL STATEMENT: CREATE TABLE village_islocatedat_district (v_obj_id NUMBER(7) NOT NULL, c_obj_id NUMBER(5) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(v_obj_id, c_obj_id), CONSTRAINT FOREIGN KEY(v_obj_id) 152
CONSTRAINTS primary key, foreign key primary key, foreign key
REFERENCES village(obj_id), CONSTRAINT FOREIGN KEY(c_obj_id) REFERENCES district(obj_id)) TABLE_NAME: PARCEL_ISLOCATEDAT_QUARTER COLUMN NAME p_obj_id cw_obj_id stdate enddate
DATA TYPE number number date date
SIZE 14 7
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE parcel_islocatedat_quarter (cw_obj_id NUMBER(7) NOT NULL, p_obj_id NUMBER(14) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(cw_obj_id, p_obj_id) CONSTRAINT FOREIGN KEY(cw_obj_id) REFERENCES quarter(obj_id), CONSTRAINT FOREIGN KEY(p_obj_id) REFERENCES parcel(obj_id)) TABLE_NAME: PARCEL_ISLOCATEDAT_VILLAGE COLUMN NAME p_obj_id v_obj_id stdate enddate
DATA TYPE number number date date
SIZE 14 7
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE parcel_islocatedat_village (v_obj_id NUMBER(7) NOT NULL, p_obj_id NUMBER(14) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(v_obj_id, p_obj_id) CONSTRAINT FOREIGN KEY(v_obj_id) REFERENCES village(obj_id), CONSTRAINT FOREIGN KEY(p_obj_id) REFERENCES parcel(obj_id)) TABLE_NAME: PBLOCK_ISLOCATEDAT_QUARTER COLUMN NAME pb_obj_id cw_obj_id stdate enddate
DATA TYPE number number date date
SIZE 12 7
DDL STATEMENT: 153
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
CREATE TABLE pblock_islocatedat_quarter (cw_obj_id NUMBER(7) NOT NULL, pb_obj_id NUMBER(12) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(cw_obj_id, pb_obj_id) CONSTRAINT FOREIGN KEY(cw_obj_id) REFERENCES quarter(obj_id), CONSTRAINT FOREIGN KEY(pb_obj_id) REFERENCES pblock(obj_id)) TABLE_NAME: PBLOCK_ISLOCATEDAT_VILLAGE COLUMN NAME pb_obj_id v_obj_id stdate enddate
DATA TYPE number number date date
SIZE 12 7
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE pblock_islocatedat_village (v_obj_id NUMBER(7) NOT NULL, pb_obj_id NUMBER(12) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(v_obj_id, pb_obj_id) CONSTRAINT FOREIGN KEY(v_obj_id) REFERENCES village(obj_id), CONSTRAINT FOREIGN KEY(pb_obj_id) REFERENCES pblock(obj_id)) TABLE_NAME: VILLAGEWARD COLUMN NAME obj_id stdate enddate vw_id
DATA TYPE number date date number
SIZE 9
2
NULL N N Y N
CONSTRAINTS primary key
NULL N N N
CONSTRAINTS primary key, foreign key
DDL STATEMENT: CREATE TABLE villageward (obj_id NUMBER(9) NOT NULL, stdate DATE NOT NULL, enddate DATE, vw_id NUMBER(2) NOT NULL, CONSTRAINT PRIMARY KEY(obj_id)) TABLE_NAME: VW_NAME COLUMN NAME obj_id name stdate
DATA TYPE number char date
SIZE 9 25
154
primary key
enddate
date
Y
DDL STATEMENT: CREATE TABLE vw_name (obj_id NUMBER(9) NOT NULL, name VARCHAR2(25) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(obj_id, stdate), CONSTRAINT FOREIGN KEY(obj_id) REFERENCES villageward(obj_id)) TABLE_NAME: VW_GEO COLUMN NAME obj_id stdate enddate geo
DATA TYPE number date date geometry
SIZE 9
NULL N N Y N
CONSTRAINTS primary key, foreign key primary key
DDL STATEMENT: CREATE TABLE vw_geo (obj_id NUMBER(9) NOT NULL, stdate DATE NOT NULL, enddate DATE, geoloc SDO_GEOMETRY NOT NULL, CONSTRAINT PRIMARY KEY(obj_id, stdate), CONSTRAINT FOREIGN KEY(obj_id) REFERENCES villageward(obj_id)) TABLE_NAME: VILLAGEWARD_BELONGSTO_VILLAGE COLUMN NAME v_obj_id vw_obj_id stdate enddate
DATA TYPE number number date date
SIZE 7 9
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE village_islocatedat_district (v_obj_id NUMBER(7) NOT NULL, vw_obj_id NUMBER(9) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(v_obj_id, vw_obj_id), CONSTRAINT FOREIGN KEY(v_obj_id) REFERENCES village(obj_id), CONSTRAINT FOREIGN KEY(vw_obj_id) REFERENCES villageward(obj_id))
155
TABLE_NAME: RPERSON COLUMN NAME id name surname name_start name_end fat_name mot_name birth_place birth_date death_date sex
DATA TYPE number char char date date char char char date date char
SIZE 11 25 25
25 25 30
1
NULL N N N N Y N Y Y N Y Y
CONSTRAINTS primary key
primary key
DDL STATEMENT: CREATE TABLE rperson (id NUMBER(11) NOT NULL, name VARCHAR2(25) NOT NULL, surname VARCHAR2(25) NOT NULL, name_start DATE NOT NULL, name_end DATE, fat_name VARCHAR2(25), mot_name VARCHAR2(25), birth_place VARCHAR2(30), birth_date DATE, death_date DATE, sex CHAR(1), CONSTRAINT PRIMARY KEY(id, name_start) CONSTRAINT UNIQUE(name, surname, fat_name, birth_date) TABLE_NAME: RPERSON_REGINFO COLUMN NAME id province district cw_village volume page family_order stdate enddate citizen
DATA TYPE number number char char char char char date date number
SIZE 11 3 30 25 5 5 5
3
DDL STATEMENT: CREATE TABLE rperson_reginfo (province NUMBER(3) NOT NULL, district VARCHAR2(30) NOT NULL, cw_village VARCHAR2(25) NOT NULL, volume VARCHAR2(5) NOT NULL, page VARCHAR2(5) NOT NULL, family_order VARCHAR2(5) NOT NULL, 156
NULL N N N N N N N N Y N
CONSTRAINTS primary key, foreign key
primary key
stdate DATE NOT NULL, enddate DATE, citizen NUMBER(3) NOT NULL, id NUMBER(11) NOT NULL, CONSTRAINT PRIMARY KEY(id, stdate), CONSTRAINT FOREIGN KEY(id) REFERENCES rperson(id)) TABLE_NAME: JPERSON COLUMN NAME id stdate Enddate
DATA TYPE number date date
SIZE 11
NULL N N Y
CONSTRAINTS primary key
NULL N N N Y
CONSTRAINTS primary key, foreign key
NULL N N N Y
CONSTRAINTS primary key, foreign key
DDL STATEMENT: CREATE TABLE jperson (id NUMBER(11) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(id)) TABLE_NAME: JPERSON_TAX_NO COLUMN NAME id tax_no stdate enddate
DATA TYPE number number date date
SIZE 11 20
primary key
DDL STATEMENT: CREATE TABLE jperson_tax_no (id NUMBER(11) NOT NULL, tax_no NUMBER(20) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(id, stdate), CONSTRAINT FOREIGN KEY(id) REFERENCES jperson(id)) TABLE_NAME: JPERSON_TAX_OFFICE COLUMN NAME id tax_office stdate enddate
DATA TYPE number char date date
SIZE 11 25
DDL STATEMENT: CREATE TABLE jperson_tax_office (id NUMBER(11) NOT NULL, tax_office VARCHAR2(25) NOT NULL, stdate DATE NOT NULL, 157
primary key
enddate DATE, CONSTRAINT PRIMARY KEY(id, stdate), CONSTRAINT FOREIGN KEY(id) REFERENCES jperson(id)) TABLE_NAME: JPERSON_NAME COLUMN NAME id name stdate enddate
DATA TYPE number char date date
SIZE 11 50
NULL N N N Y
CONSTRAINTS primary key, foreign key
NULL N N N Y
CONSTRAINTS primary key, foreign key
primary key
DDL STATEMENT: CREATE TABLE jperson_name (id NUMBER(11) NOT NULL, name VARCHAR2(50) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(id, stdate), CONSTRAINT FOREIGN KEY(id) REFERENCES jperson(id)) TABLE_NAME: JPERSON_TYPE COLUMN NAME id type stdate enddate
DATA TYPE number char date date
SIZE 11 25
primary key
DDL STATEMENT: CREATE TABLE jperson_type (id NUMBER(11) NOT NULL, type VARCHAR2(50) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(id, stdate), CONSTRAINT FOREIGN KEY(id) REFERENCES jperson(id)) TABLE_NAME: RPERSON_PARCEL_OWNERSHIP COLUMN NAME rperson_id parcel_obj_id stdate sttime reason process_no rate1 rate2 enddate
DATA TYPE number number date number char number number number date
SIZE 11 14 (2,2) 40 5 10 10 158
NULL N N N N N N Y Y Y
CONSTRAINTS primary key, foreign key primary key, foreign key primary key primary key primary key
endtime
number
(2,2)
Y
DDL STATEMENT: CREATE TABLE rperson_parcel_ownership (rperson_id NUMBER(11) NOT NULL, parcel_obj_id NUMBER(14) NOT NULL, stdate DATE NOT NULL, sttime NUMBER(2, 2) NOT NULL, reason VARCHAR2(40) NOT NULL, process_no NUMBER(5) NOT NULL, rate1 NUMBER(10) NOT NULL, rate2 NUMBER(10) NOT NULL, enddate DATE, endtime NUMBER(2, 2), CONSTRAINT PRIMARY KEY(rperson_id, parcel_obj_id, stdate, sttime, process_no), CONSTRAINT FOREIGN KEY(rperson_id) REFERENCES rperson(id), CONSTRAINT FOREIGN KEY(parcel_obj_id) REFERENCES parcel(obj_id)) TABLE_NAME: JPERSON_PARCEL_OWNERSHIP COLUMN NAME jperson_id parcel_obj_id stdate sttime reason process_no rate1 rate2 enddate endtime
DATA TYPE number number date number char number number number date number
SIZE 11 14 (2,2) 40 5 10 10 (2,2)
NULL N N N N N N Y Y Y Y
CONSTRAINTS primary key, foreign key primary key, foreign key primary key primary key primary key
DDL STATEMENT: CREATE TABLE jperson_parcel_ownership (jperson_id NUMBER(11) NOT NULL, parcel_obj_id NUMBER(14) NOT NULL, stdate DATE NOT NULL, sttime NUMBER(2, 2) NOT NULL, reason VARCHAR2(40) NOT NULL, process_no NUMBER(5) NOT NULL, rate1 NUMBER(10) NOT NULL, rate2 NUMBER(10) NOT NULL, enddate DATE, endtime NUMBER(2, 2), CONSTRAINT PRIMARY KEY(jperson_id, parcel_obj_id, stdate, sttime, process_no), CONSTRAINT FOREIGN KEY(jperson_id) REFERENCES jperson(id), CONSTRAINT FOREIGN KEY(parcel_obj_id) REFERENCES parcel(obj_id)) 159
TABLE_NAME: BUILDING COLUMN NAME obj_id stdate enddate definition flat_no story_no block_id address
DATA TYPE number date date char number number char char
SIZE 15
50 2 2 5 60
NULL N N Y Y Y Y Y Y
CONSTRAINTS primary key
NULL N N Y N
CONSTRAINTS primary key, foreign key primary key
DDL STATEMENT: CREATE TABLE building (obj_id NUMBER(15) NOT NULL, definition VARCHAR2(50), flat_no NUMBER(2), story_no NUMBER(2), block_id VARCHAR2(5), address VARCHAR2(60), stdate DATE, enddate DATE, CONSTRAINT PRIMARY KEY(obj_id)) TABLE_NAME: BUILDING_USAGE COLUMN NAME obj_id stdate enddate definition
DATA TYPE number date date char
SIZE 15
50
DDL STATEMENT: CREATE TABLE building_usage (obj_id NUMBER(15) NOT NULL, stdate DATE NOT NULL, enddate DATE, usage VARCHAR2(50) NOT NULL, CONSTRAINT PRIMARY KEY(obj_id, stdate), CONSTRAINT FOREIGN KEY(obj_id) REFERENCES building(obj_id)) TABLE_NAME: BUILDING_GEO COLUMN NAME DATA TYPE SIZE obj_id number 15 stdate date enddate date geo geometry DDL STATEMENT: CREATE TABLE building_usage (obj_id NUMBER(15) NOT NULL, 160
NULL N N Y N
CONSTRAINTS primary key, foreign key primary key
stdate DATE NOT NULL, enddate DATE, geoloc SDO_GEOMETRY NOT NULL, CONSTRAINT PRIMARY KEY(obj_id, stdate), CONSTRAINT FOREIGN KEY(obj_id) REFERENCES building(obj_id)) TABLE_NAME: BUILDING_ISLOCATEDAT_PARCEL COLUMN NAME p_obj_id b_obj_id stdate enddate
DATA TYPE number number date date
SIZE 14 15
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE building_islocatedat_parcel (p_obj_id NUMBER(14) NOT NULL, b_obj_id NUMBER(15) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(p_obj_id, b_obj_id), CONSTRAINT FOREIGN KEY(p_obj_id) REFERENCES parcel(obj_id), CONSTRAINT FOREIGN KEY(b_obj_id) REFERENCES building(obj_id)) TABLE_NAME: FLAT COLUMN NAME b_obj_id flat_id block_id story_id
DATA TYPE number number char number
SIZE 15 3 5 2
NULL N N Y Y
CONSTRAINTS primary key, foreign key primary key
DDL STATEMENT: CREATE TABLE flat (b_obj_id NUMBER(15) NOT NULL, flat_id NUMBER(3) NOT NULL, block_id VARCHAR2(5), story_id NUMBER(2), CONSTRAINT PRIMARY KEY(b_obj_id, flat_id), CONSTRAINT FOREIGN KEY(b_obj_id) REFERENCES building(obj_id)) TABLE_NAME: FLAT_USAGE COLUMN NAME b_obj_id flat_id stdate enddate usage
DATA TYPE number number date date char
SIZE 15 3
50 161
NULL N N N Y N
CONSTRAINTS primary key, foreign key primary key, foreign key primary key
DDL STATEMENT: CREATE TABLE flat_usage (b_obj_id NUMBER(15) NOT NULL, flat_id NUMBER(3) NOT NULL, stdate DATE NOT NULL, enddate DATE, usage VARCHAR2(50) NOT NULL, CONSTRAINT PRIMARY KEY(b_obj_id, flat_id, stdate), CONSTRAINT FOREIGN KEY(b_obj_id, flat_id) REFERENCES flat(b_obj_id, flat_id)) TABLE_NAME: FLAT_VALUE COLUMN NAME b_obj_id flat_id stdate enddate usage
DATA TYPE number number date date number
SIZE 15 3
16
NULL N N N Y N
CONSTRAINTS primary key, foreign key primary key, foreign key primary key
DDL STATEMENT: CREATE TABLE flat_value (b_obj_id NUMBER(15) NOT NULL, flat_id NUMBER(3) NOT NULL, stdate DATE NOT NULL, enddate DATE, value NUMBER(16) NOT NULL, CONSTRAINT PRIMARY KEY(b_obj_id, flat_id, stdate), CONSTRAINT FOREIGN KEY(b_obj_id, flat_id) REFERENCES flat(b_obj_id, flat_id)) TABLE_NAME: RPERSON_FLAT_OWNERSHIP COLUMN NAME rperson_id b_obj_id flat_id stdate sttime reason process_no rate1 rate2 enddate endtime
DATA TYPE number number number date number char number number number date number
SIZE 11 15 3 (2,2) 40 5 10 10 (2,2)
DDL STATEMENT: CREATE TABLE rperson_flat_ownership (rperson_id NUMBER(11) NOT NULL, b_obj_id NUMBER(15) NOT NULL, flat_id NUMBER(3) NOT NULL, 162
NULL N N N N N N N Y Y Y Y
CONSTRAINTS primary key, foreign key primary key, foreign key primary key primary key primary key primary key
stdate DATE NOT NULL, sttime NUMBER(2,2) NOT NULL, reason VARCHAR2(40) NOT NULL, process_no NUMBER(5) NOT NULL, rate1 NUMBER(10) NOT NULL, rate2 NUMBER(10) NOT NULL, enddate DATE, endtime NUMBER(2, 2), CONSTRAINT PRIMARY KEY(rperson_id, b_obj_id, flat_id, stdate, sttime, process_no), CONSTRAINT FOREIGN KEY(rperson_id) REFERENCES rperson(id), CONSTRAINT FOREIGN KEY(b_obj_id, flat_id) REFERENCES flat(b_obj_id, flat_id)) TABLE_NAME: JPERSON_FLAT_OWNERSHIP COLUMN NAME jperson_id b_obj_id flat_id stdate sttime reason process_no rate1 rate2 enddate endtime
DATA TYPE number number number date number char number number number date number
SIZE 11 15 3 (2,2) 40 5 10 10 (2,2)
NULL N N N N N N N Y Y Y Y
CONSTRAINTS primary key, foreign key primary key, foreign key primary key primary key primary key primary key
DDL STATEMENT: CREATE TABLE jperson_flat_ownership (jperson_id NUMBER(11) NOT NULL, b_obj_id NUMBER(15) NOT NULL, flat_id NUMBER(3) NOT NULL, stdate DATE NOT NULL, sttime NUMBER(2,2) NOT NULL, reason VARCHAR2(40) NOT NULL, process_no NUMBER(5) NOT NULL, rate1 NUMBER(10) NOT NULL, rate2 NUMBER(10) NOT NULL, enddate DATE, endtime NUMBER(2, 2), CONSTRAINT PRIMARY KEY(jperson_id, b_obj_id, flat_id, stdate, sttime, process_no), CONSTRAINT FOREIGN KEY(jperson_id) REFERENCES jperson(id), CONSTRAINT FOREIGN KEY(b_obj_id, flat_id) REFERENCES flat(b_obj_id, flat_id))
163
TABLE_NAME: MAP_DEF COLUMN NAME name scale geo
DATA TYPE char number geometry
SIZE 25 7
NULL N N N
CONSTRAINTS primary key
NULL N N Y N N Y Y Y Y Y N
CONSTRAINTS primary key
DDL STATEMENT: CREATE TABLE map_def (name CHAR(25) NOT NULL, scale NUMBER(7) NOT NULL, geoloc SDO_GEOMETRY NOT NULL, CONSTRAINT PRIMARY KEY(name)) TABLE_NAME: PROD_MAP COLUMN NAME obj_id stdate enddate name scale type proj ellips producer prod_method geo
DATA TYPE number date date char number char char char char char geometry
SIZE 15
25 7 15 15 15 40 20
DDL STATEMENT: CREATE TABLE prod_map (obj_id NUMBER(15) NOT NULL, stdate DATE NOT NULL, enddate DATE, name CHAR(25) NOT NULL, scale NUMBER(7) NOT NULL, type CHAR(15), PROJ CHAR(15), ellips CHAR(15), producer CHAR(40), prod_method CHAR(20), geoloc SDO_GEOMETRY NOT NULL, CONSTRAINT PRIMARY KEY(obj_id)) TABLE_NAME: PARCEL_ISLOCATEDAT_MAP_DEF COLUMN NAME p_obj_id map_name stdate enddate
DATA TYPE number char date date
SIZE 14 25
DDL STATEMENT: 164
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
CREATE TABLE parcel_islocatedat_map_def (p_obj_id NUMBER(14) NOT NULL, map_name CHAR(25) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(p_obj_id, map_name), CONSTRAINT FOREIGN KEY(p_obj_id) REFERENCES parcel(obj_id), CONSTRAINT FOREIGN KEY(map_name) REFERENCES map_def(name)) TABLE_NAME: PARCEL_ISLOCATEDAT_PROD_MAP COLUMN NAME p_obj_id map_obj_id stdate enddate
DATA TYPE number number date date
SIZE 14 15
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE parcel_islocatedat_prod_map (p_obj_id NUMBER(14) NOT NULL, map_obj_id NUMBER(15) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(p_obj_id, map_obj_id), CONSTRAINT FOREIGN KEY(p_obj_id) REFERENCES parcel(obj_id), CONSTRAINT FOREIGN KEY(map_obj_id) REFERENCES prod_map(obj_id)) TABLE_NAME: PBLOCK_ISLOCATEDAT_MAP_DEF COLUMN NAME pb_obj_id map_name stdate enddate
DATA TYPE number char date date
SIZE 12 25
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE pblock_islocatedat_map_def (pb_obj_id NUMBER(12) NOT NULL, map_name CHAR(25) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(pb_obj_id, map_name), CONSTRAINT FOREIGN KEY(pb_obj_id) REFERENCES pblock(obj_id), CONSTRAINT FOREIGN KEY(map_name) REFERENCES map_def(name))
165
TABLE_NAME: PBLOCK_ISLOCATEDAT_PROD_MAP COLUMN NAME pb_obj_id map_obj_id stdate enddate
DATA TYPE number number date date
SIZE 12 15
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE pblock_islocatedat_prod_map (pb_obj_id NUMBER(12) NOT NULL, map_obj_id NUMBER(15) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(pb_obj_id, map_obj_id), CONSTRAINT FOREIGN KEY(pb_obj_id) REFERENCES pblock(obj_id), CONSTRAINT FOREIGN KEY(map_obj_id) REFERENCES prod_map(obj_id)) TABLE_NAME: QUARTER_ISLOCATEDAT_MAP_DEF COLUMN NAME cw_obj_id map_name stdate enddate
DATA TYPE number char date date
SIZE 7 25
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE quarter_islocatedat_map_def (cw_obj_id NUMBER(7) NOT NULL, map_name CHAR(25) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(cw_obj_id, map_name), CONSTRAINT FOREIGN KEY(cw_obj_id) REFERENCES quarter(obj_id), CONSTRAINT FOREIGN KEY(map_name) REFERENCES map_def(name)) TABLE_NAME: QUARTER_ISLOCATEDAT_PROD_MAP COLUMN NAME cw_obj_id map_obj_id stdate enddate
DATA TYPE number number date date
SIZE 7 15
DDL STATEMENT: CREATE TABLE quarter_islocatedat_prod_map (cw_obj_id NUMBER(7) NOT NULL, map_obj_id NUMBER(15) NOT NULL, stdate DATE NOT NULL, 166
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
enddate DATE, CONSTRAINT PRIMARY KEY(cw_obj_id, map_obj_id), CONSTRAINT FOREIGN KEY(cw_obj_id) REFERENCES quarter(obj_id), CONSTRAINT FOREIGN KEY(map_obj_id) REFERENCES prod_map(obj_id)) TABLE_NAME: VILLAGE_ISLOCATEDAT_MAP_DEF COLUMN NAME v_obj_id map_name stdate enddate
DATA TYPE number char date date
SIZE 7 25
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE village_islocatedat_map_def (v_obj_id NUMBER(7) NOT NULL, map_name CHAR(25) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(v_obj_id, map_name), CONSTRAINT FOREIGN KEY(v_obj_id) REFERENCES village(obj_id), CONSTRAINT FOREIGN KEY(map_name) REFERENCES map_def(name)) TABLE_NAME: VILLAGE_ISLOCATEDAT_PROD_MAP COLUMN NAME v_obj_id map_obj_id stdate enddate
DATA TYPE number number date date
SIZE 7 15
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE village_islocatedat_prod_map (v_obj_id NUMBER(7) NOT NULL, map_obj_id NUMBER(15) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(v_obj_id, map_obj_id), CONSTRAINT FOREIGN KEY(v_obj_id) REFERENCES village(obj_id), CONSTRAINT FOREIGN KEY(map_obj_id) REFERENCES prod_map(obj_id)) TABLE_NAME: DISTRICT_ISLOCATEDAT_MAP_DEF COLUMN NAME c_obj_id map_name stdate enddate
DATA TYPE number char date date
SIZE 5 25
167
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE district_islocatedat_map_def (c_obj_id NUMBER(7) NOT NULL, map_name CHAR(25) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(c_obj_id, map_name), CONSTRAINT FOREIGN KEY(c_obj_id) REFERENCES district(obj_id), CONSTRAINT FOREIGN KEY(map_name) REFERENCES map_def(name)) TABLE_NAME: DISTRICT_ISLOCATEDAT_PROD_MAP COLUMN NAME v_obj_id map_obj_id stdate enddate
DATA TYPE number number date date
SIZE 7 15
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE district_islocatedat_prod_map (c_obj_id NUMBER(7) NOT NULL, map_obj_id NUMBER(15) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(c_obj_id, map_obj_id), CONSTRAINT FOREIGN KEY(c_obj_id) REFERENCES district(obj_id), CONSTRAINT FOREIGN KEY(map_obj_id) REFERENCES prod_map(obj_id)) TABLE_NAME: GCP COLUMN NAME obj_id p_no stdate enddate type construct sketch_no producer prod_method geo
DATA TYPE number char date date char char number char char geometry
SIZE 11 9
15 15 11 20 20
DDL STATEMENT: CREATE TABLE gcp (obj_id NUMBER(11) NOT NULL, p_no VARCHAR2(9), stdate DATE NOT NULL, enddate DATE, 168
NULL N Y N Y N Y N N N N
CONSTRAINTS primary key
type VARCHAR2(15) NOT NULL, construct VARCHAR2(15), sketch_no NUMBER(11) NOT NULL, producer VARCHAR2(20) NOT NULL, prod_method VARCHAR2(20) NOT NULL, geoloc SDO_GEOMETRY NOT NULL, CONSTRAINT PRIMARY KEY(obj_id)) TABLE_NAME: GCP_SYMBOL COLUMN NAME type symbol
DATA TYPE char char
SIZE 15 15
NULL N N
CONSTRAINTS primary key
NULL N N Y Y Y
CONSTRAINTS primary key, foreign key
NULL N Y Y Y Y Y Y
CONSTRAINTS primary key, foreign key
DDL STATEMENT: CREATE TABLE gcp_symbol (type VARCHAR2(15) NOT NULL, symbol CHAR(15) NOT NULL, CONSTRAINT PRIMARY KEY(type)) TABLE_NAME: LEVELLING COLUMN NAME obj_id elevation site posit_err explanation
DATA TYPE number number char number char
SIZE 11 11 25 6 50
DDL STATEMENT: CREATE TABLE levelling (obj_id NUMBER(11), elevation NUMBER(11), site VARCHAR2(25), posit_err NUMBER(6), explanation VARCHAR2(50), CONSTRAINT PRIMARY KEY(obj_id), CONSTRAINT FOREIGN KEY(obj_id), REFERENCES gcp(obj_id)) TABLE_NAME: TRI_1-2-A3-3I COLUMN NAME obj_id name site posit_err elev_method G_lat G_lon
DATA TYPE number char char number char number number
SIZE 11 40 25 6 20 (2,5) (2,5)
DDL STATEMENT: CREATE TABLE tri_1-2-A3-3I 169
(obj_id NUMBER(11) NOT NULL, name VARCHAR2(40), site VARCHAR2(25), posit_err NUMBER(6), elev_method VARCHAR2(20), G_lat NUMBER(2,5), G_lon NUMBER(2,5), CONSTRAINT PRIMARY KEY(obj_id), CONSTRAINT FOREIGN KEY(obj_id), REFERENCES gcp(obj_id)) TABLE_NAME: TRI_INTENSIFYING COLUMN NAME obj_id posit_err elev_method route_no route_fL route_fQ
DATA TYPE number number char number number number
SIZE 11 6 20 6 6 6
NULL N N Y N N N
CONSTRAINTS primary key, foreign key
NULL N N N N
CONSTRAINTS primary key, foreign key
DDL STATEMENT: CREATE TABLE tri_intensifying (obj_id NUMBER(11) NOT NULL, posit_err NUMBER(6) NOT NULL, elev_method VARCHAR2(20), route_no NUMBER(6) NOT NULL, route_fL NUMBER(6) NOT NULL, route_fQ NUMBER(6) NOT NULL, CONSTRAINT PRIMARY KEY(obj_id), CONSTRAINT FOREIGN KEY(obj_id), REFERENCES gcp(obj_id)) TABLE_NAME: TRAVERSE COLUMN NAME obj_id route_no route_fl route_fq
DATA TYPE number number number number
SIZE 11 6 6 6
DDL STATEMENT: CREATE TABLE traverse (obj_id NUMBER(11) NOT NULL, route_no NUMBER(6) NOT NULL, route_fl NUMBER(6) NOT NULL, route_fq NUMBER(6) NOT NULL, CONSTRAINT PRIMARY KEY(obj_id), CONSTRAINT FOREIGN KEY(obj_id), REFERENCES gcp(obj_id))
170
TABLE_NAME: GCP_ISLOCATEDAT_DISTRICT COLUMN NAME gcp_obj_id c_obj_id stdate enddate
DATA TYPE number number date date
SIZE 11 5
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE gcp_islocatedat_district (gcp_obj_id NUMBER(11) NOT NULL, c_obj_id NUMBER(5) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(gcp_obj_id, c_obj_id), CONSTRAINT FOREIGN KEY(gcp_obj_id) REFERENCES gcp(obj_id), CONSTRAINT FOREIGN KEY(c_obj_id) REFERENCES district(obj_id)) TABLE_NAME: GCP_ISLOCATEDAT_QUARTER COLUMN NAME gcp_obj_id cw_obj_id stdate enddate
DATA TYPE number number date date
SIZE 11 7
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE gcp_islocatedat_quarter (cw_obj_id NUMBER(7) NOT NULL, gcp_obj_id NUMBER(11) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(cw_obj_id, gcp_obj_id) CONSTRAINT FOREIGN KEY(cw_obj_id) REFERENCES quarter(obj_id), CONSTRAINT FOREIGN KEY(gcp_obj_id) REFERENCES gcp(obj_id)) TABLE_NAME: GCP_ISLOCATEDAT_VILLAGE COLUMN NAME gcp_obj_id v_obj_id stdate enddate
DATA TYPE number number date date
SIZE 11 7
DDL STATEMENT: CREATE TABLE gcp_islocatedat_village (v_obj_id NUMBER(7) NOT NULL, gcp_obj_id NUMBER(11) NOT NULL, stdate DATE NOT NULL, 171
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
enddate DATE, CONSTRAINT PRIMARY KEY(v_obj_id, gcp_obj_id) CONSTRAINT FOREIGN KEY(v_obj_id) REFERENCES village(obj_id), CONSTRAINT FOREIGN KEY(gcp_obj_id) REFERENCES gcp(obj_id)) TABLE_NAME: GCP_ISLOCATEDAT_MAP_DEF COLUMN NAME gcp_obj_id map_name stdate enddate
DATA TYPE number char date date
SIZE 11 25
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE gcp_islocatedat_map_def (gcp_obj_id NUMBER(11) NOT NULL, map_name CHAR(25) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(gcp_obj_id, map_name), CONSTRAINT FOREIGN KEY(gcp_obj_id) REFERENCES gcp(obj_id), CONSTRAINT FOREIGN KEY(map_name) REFERENCES map_def(name)) TABLE_NAME: GCP_ISLOCATEDAT_PROD_MAP COLUMN NAME gcp_obj_id map_obj_id stdate enddate
DATA TYPE number number date date
SIZE 11 15
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE gcp_islocatedat_prod_map (gcp_obj_id NUMBER(11) NOT NULL, map_obj_id NUMBER(15) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(gcp_obj_id, map_obj_id), CONSTRAINT FOREIGN KEY(gcp_obj_id) REFERENCES gcp(obj_id), CONSTRAINT FOREIGN KEY(map_obj_id) REFERENCES prod_map(obj_id)) TABLE_NAME: HYDROLOGY COLUMN NAME obj_id name type
DATA TYPE number char char
SIZE 6 25 15 172
NULL N Y Y
CONSTRAINTS primary key
definition geo
char geometry
40
Y N
DDL STATEMENT: CREATE TABLE hydrology (obj_id NUMBER(6) NOT NULL, name VARCHAR2(25), type VARCHAR2(15), definition VARCHAR2(40), geoloc SDO_GEOMETRY NOT NULL, CONSTRAINT PRIMARY KEY(obj_id)) TABLE_NAME: HYDROLOGY_SYMBOL COLUMN NAME type symbol
DATA TYPE char char
SIZE 15 15
NULL N N
CONSTRAINTS primary key
NULL N Y Y Y N
CONSTRAINTS primary key
NULL N N
CONSTRAINTS primary key
DDL STATEMENT: CREATE TABLE hydrology_symbol (type VARCHAR2(15) NOT NULL, symbol CHAR(15) NOT NULL, CONSTRAINT PRIMARY KEY(type)) TABLE_NAME: MINING COLUMN NAME obj_id name type definition geo
DATA TYPE number char char char geometry
SIZE 6 25 15 40
DDL STATEMENT: CREATE TABLE mining (obj_id NUMBER(6) NOT NULL, name VARCHAR2(25), type VARCHAR2(15), definition VARCHAR2(40), geoloc SDO_GEOMETRY NOT NULL, CONSTRAINT PRIMARY KEY(obj_id)) TABLE_NAME: MINING_SYMBOL COLUMN NAME type symbol
DATA TYPE char char
SIZE 15 15
DDL STATEMENT: CREATE TABLE mining_symbol (type VARCHAR2(15) NOT NULL, symbol CHAR(15) NOT NULL, CONSTRAINT PRIMARY KEY(type)) 173
TABLE_NAME: VEGETATION COLUMN NAME obj_id name type definition geo
DATA TYPE number char char char geometry
SIZE 6 25 15 40
NULL N Y Y Y N
CONSTRAINTS primary key
NULL N N
CONSTRAINTS primary key
NULL N Y Y Y N
CONSTRAINTS primary key
NULL N
CONSTRAINTS primary key
DDL STATEMENT: CREATE TABLE vegetation (obj_id NUMBER(6) NOT NULL, name VARCHAR2(25), type VARCHAR2(15), definition VARCHAR2(40), geoloc SDO_GEOMETRY NOT NULL, CONSTRAINT PRIMARY KEY(obj_id)) TABLE_NAME: VEGETATION_SYMBOL COLUMN NAME type symbol
DATA TYPE char char
SIZE 15 15
DDL STATEMENT: CREATE TABLE vegetation_symbol (type VARCHAR2(15) NOT NULL, symbol CHAR(15) NOT NULL, CONSTRAINT PRIMARY KEY(type)) TABLE_NAME: ENERGY COLUMN NAME obj_id name type definition geo
DATA TYPE number char char char geometry
SIZE 6 25 15 40
DDL STATEMENT: CREATE TABLE energy (obj_id NUMBER(6) NOT NULL, name VARCHAR2(25), type VARCHAR2(15), definition VARCHAR2(40), geoloc SDO_GEOMETRY NOT NULL, CONSTRAINT PRIMARY KEY(obj_id)) TABLE_NAME: ENERGY_SYMBOL COLUMN NAME type
DATA TYPE char
SIZE 15 174
symbol
char
15
N
DDL STATEMENT: CREATE TABLE energy_symbol (type VARCHAR2(15) NOT NULL, symbol CHAR(15) NOT NULL, CONSTRAINT PRIMARY KEY(type)) TABLE_NAME: COMMUNICATION COLUMN NAME obj_id name type definition geo
DATA TYPE number char char char geometry
SIZE 6 25 15 40
NULL N Y Y Y N
CONSTRAINTS primary key
NULL N N
CONSTRAINTS primary key
NULL N Y Y Y N
CONSTRAINTS primary key
DDL STATEMENT: CREATE TABLE communication (obj_id NUMBER(6) NOT NULL, name VARCHAR2(25), type VARCHAR2(15), definition VARCHAR2(40), geoloc SDO_GEOMETRY NOT NULL, CONSTRAINT PRIMARY KEY(obj_id)) TABLE_NAME: COMMUNICATION_SYMBOL COLUMN NAME type symbol
DATA TYPE char char
SIZE 15 15
DDL STATEMENT: CREATE TABLE communication_symbol (type VARCHAR2(15) NOT NULL, symbol CHAR(15) NOT NULL, CONSTRAINT PRIMARY KEY(type)) TABLE_NAME: TRANSPORTATION COLUMN NAME obj_id name type definition geo
DATA TYPE number char char char geometry
SIZE 6 25 15 40
DDL STATEMENT: CREATE TABLE transportation (obj_id NUMBER(6) NOT NULL, name VARCHAR2(25), type VARCHAR2(15), definition VARCHAR2(40), 175
geoloc SDO_GEOMETRY NOT NULL, CONSTRAINT PRIMARY KEY(obj_id)) TABLE_NAME: TRANSPORTATION_SYMBOL COLUMN NAME DATA TYPE SIZE type char 15 symbol char 15 DDL STATEMENT: CREATE TABLE transportation_symbol (type VARCHAR2(15) NOT NULL, symbol CHAR(15) NOT NULL, CONSTRAINT PRIMARY KEY(type))
NULL N N
CONSTRAINTS primary key
NULL N Y Y Y N
CONSTRAINTS primary key
NULL N N
CONSTRAINTS primary key
NULL N Y Y Y N
CONSTRAINTS primary key
TABLE_NAME: PARKS COLUMN NAME obj_id name type definition geo
DATA TYPE number char char char geometry
SIZE 6 25 15 40
DDL STATEMENT: CREATE TABLE parks (obj_id NUMBER(6) NOT NULL, name VARCHAR2(25), type VARCHAR2(15), definition VARCHAR2(40), geoloc SDO_GEOMETRY NOT NULL, CONSTRAINT PRIMARY KEY(obj_id)) TABLE_NAME: PARKS_SYMBOL COLUMN NAME type symbol
DATA TYPE char char
SIZE 15 15
DDL STATEMENT: CREATE TABLE parks_symbol (type VARCHAR2(15) NOT NULL, symbol CHAR(15) NOT NULL, CONSTRAINT PRIMARY KEY(type)) TABLE_NAME: CULTURE COLUMN NAME obj_id name type definition geo
DATA TYPE number char char char geometry
SIZE 6 25 15 40
176
DDL STATEMENT: CREATE TABLE culture (obj_id NUMBER(6) NOT NULL, name VARCHAR2(25), type VARCHAR2(15), definition VARCHAR2(40), geoloc SDO_GEOMETRY NOT NULL, CONSTRAINT PRIMARY KEY(obj_id)) TABLE_NAME: CULTURE_SYMBOL COLUMN NAME type symbol
DATA TYPE char char
SIZE 15 15
NULL N N
CONSTRAINTS primary key
NULL N Y Y Y N
CONSTRAINTS primary key
NULL N N
CONSTRAINTS primary key
DDL STATEMENT: CREATE TABLE culture_symbol (type VARCHAR2(15) NOT NULL, symbol CHAR(15) NOT NULL, CONSTRAINT PRIMARY KEY(type)) TABLE_NAME: TOPOGRAPHY COLUMN NAME obj_id name type definition geo
DATA TYPE number char char char geometry
SIZE 6 25 15 40
DDL STATEMENT: CREATE TABLE topography (obj_id NUMBER(6) NOT NULL, name VARCHAR2(25), type VARCHAR2(15), definition VARCHAR2(40), geoloc SDO_GEOMETRY NOT NULL, CONSTRAINT PRIMARY KEY(obj_id)) TABLE_NAME: TOPO_SYMBOL COLUMN NAME type symbol
DATA TYPE char char
SIZE 15 15
DDL STATEMENT: CREATE TABLE topo_symbol (type VARCHAR2(15) NOT NULL, symbol CHAR(15) NOT NULL, CONSTRAINT PRIMARY KEY(type))
177
TABLE_NAME: HYDROLOGY_ISLOCATEDAT_PROD_MAP COLUMN NAME hyd_obj_id map_obj_id stdate enddate
DATA TYPE Number Number date date
SIZE 6 15
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE hydrology_islocatedat_prod_map (hyd_obj_id NUMBER(6) NOT NULL, map_obj_id NUMBER(15) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(hyd_obj_id, map_obj_id), CONSTRAINT FOREIGN KEY(hyd_obj_id) REFERENCES hydrology(obj_id), CONSTRAINT FOREIGN KEY(map_obj_id) REFERENCES prod_map(obj_id)) TABLE_NAME: MINING_ISLOCATEDAT_PROD_MAP COLUMN NAME min_obj_id map_obj_id stdate enddate
DATA TYPE number number date date
SIZE 6 15
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE mining_islocatedat_prod_map (min_obj_id NUMBER(6) NOT NULL, map_obj_id NUMBER(15) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(min_obj_id, map_obj_id), CONSTRAINT FOREIGN KEY(min_obj_id) REFERENCES mining(obj_id), CONSTRAINT FOREIGN KEY(map_obj_id) REFERENCES prod_map(obj_id)) TABLE_NAME: VEGETATION_ISLOCATEDAT_PROD_MAP COLUMN NAME veg_obj_id map_obj_id stdate enddate
DATA TYPE number number date date
SIZE 6 15
DDL STATEMENT: CREATE TABLE vegetation_islocatedat_prod_map (veg_obj_id NUMBER(6) NOT NULL, map_obj_id NUMBER(15) NOT NULL, stdate DATE NOT NULL, 178
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
enddate DATE, CONSTRAINT PRIMARY KEY(veg_obj_id, map_obj_id), CONSTRAINT FOREIGN KEY(veg_obj_id) REFERENCES vegetation (obj_id), CONSTRAINT FOREIGN KEY(map_obj_id) REFERENCES prod_map(obj_id)) TABLE_NAME: ENERGY_ISLOCATEDAT_PROD_MAP COLUMN NAME en_obj_id map_obj_id stdate enddate
DATA TYPE number number date date
SIZE 6 15
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE energy_islocatedat_prod_map (en_obj_id NUMBER(6) NOT NULL, map_obj_id NUMBER(15) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(en_obj_id, map_obj_id), CONSTRAINT FOREIGN KEY(en_obj_id) REFERENCES energy(obj_id), CONSTRAINT FOREIGN KEY(map_obj_id) REFERENCES prod_map(obj_id)) TABLE_NAME: COMMUNICATION_ISLOCATEDAT_PROD_MAP COLUMN NAME com_obj_id map_obj_id stdate enddate
DATA TYPE number number date date
SIZE 6 15
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE communication_islocatedat_prod_map (com_obj_id NUMBER(6) NOT NULL, map_obj_id NUMBER(15) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(com_obj_id, map_obj_id), CONSTRAINT FOREIGN KEY(com_obj_id) REFERENCES communication(obj_id), CONSTRAINT FOREIGN KEY(map_obj_id) REFERENCES prod_map(obj_id)) TABLE_NAME: TRANSPORTATION_ISLOCATEDAT_PROD_MAP COLUMN NAME tr_obj_id map_obj_id stdate enddate
DATA TYPE number number date date
SIZE 6 15
179
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE transportation_islocatedat_prod_map (tr_obj_id NUMBER(6) NOT NULL, map_obj_id NUMBER(15) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(tr_obj_id, map_obj_id), CONSTRAINT FOREIGN KEY(tr_obj_id) REFERENCES transportation(obj_id), CONSTRAINT FOREIGN KEY(map_obj_id) REFERENCES prod_map(obj_id)) TABLE_NAME: PARKS_ISLOCATEDAT_PROD_MAP COLUMN NAME park_obj_id map_obj_id stdate enddate
DATA TYPE number number date date
SIZE 6 15
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE parks_islocatedat_prod_map (park_obj_id NUMBER(6) NOT NULL, map_obj_id NUMBER(15) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(park_obj_id, map_obj_id), CONSTRAINT FOREIGN KEY(park_obj_id) REFERENCES parks(obj_id), CONSTRAINT FOREIGN KEY(map_obj_id) REFERENCES prod_map(obj_id)) TABLE_NAME: CULTURE_ISLOCATEDAT_PROD_MAP COLUMN NAME cul_obj_id map_obj_id stdate enddate
DATA TYPE number number date date
SIZE 6 15
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE culture_islocatedat_prod_map (cul_obj_id NUMBER(6) NOT NULL, map_obj_id NUMBER(15) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(cul_obj_id, map_obj_id), CONSTRAINT FOREIGN KEY(cul_obj_id) REFERENCES culture(obj_id), CONSTRAINT FOREIGN KEY(map_obj_id) REFERENCES prod_map(obj_id))
180
TABLE_NAME: TOPO_ISLOCATEDAT_PROD_MAP COLUMN NAME topo_obj_id map_obj_id stdate enddate
DATA TYPE number number date date
SIZE 6 15
NULL N N N Y
CONSTRAINTS primary key, foreign key primary key, foreign key
DDL STATEMENT: CREATE TABLE topo_islocatedat_prod_map (topo_obj_id NUMBER(6) NOT NULL, map_obj_id NUMBER(15) NOT NULL, stdate DATE NOT NULL, enddate DATE, CONSTRAINT PRIMARY KEY(topo_obj_id, map_obj_id), CONSTRAINT FOREIGN KEY(topo_obj_id) REFERENCES topography(obj_id), CONSTRAINT FOREIGN KEY(map_obj_id) REFERENCES prod_map(obj_id))
181
APPENDIX E
THE LIST OF CREATED DATABASE TABLES
Table BUILDING BUILDING_GEOM BUILDING_GEOM_SX_FL6$ BUILDING_ISLOCATEDAT_PARCEL BUILDING_USAGE COMM_LOCAT_PROD_MAP COUNTRY COUNTRY_SX_FL6$ DISTRICT DISTRICT_GEOM DISTRICT_GEOM_SX_FL6$ DISTRICT_ISLOCATEDAT_PROVINCE DISTRICT_LOCAT_MAP_DEF DISTRICT_LOCAT_PROD_MAP DISTRICT_NAME QUARTER QUARTER_ISLOCATEDAT_DISTRICT CULTURE CULTURE_LOCAT_PROD_MAP CULTURE_SX_FL8$ CW_GEOM CW_GEOM_SX_FL6$ CW_LOCAT_MAP_DEF CW_LOCAT_PROD_MAP CW_NAME ENERGY ENERGY_LOCAT_PROD_MAP ENERGY_SX_FL6$ FLAT FLAT_VALUE FLAT_USAGE GCP
182
Data Loaded Y Y Y Y N Y Y Y Y N N Y Y Y Y N Y N N Y Y N Y Y Y Y
GCP_ISLOCAT_DISTRICT GCP_ISLOCAT_CW GCP_ISLOCAT_MAP_DEF GCP_ISLOCAT_PROD_MAP GCP_ISLOCAT_VILLAGE GCP_SX_FL6$ GCP_SYMBOL HYDRO_LOCAT_PROD_MAP HYDROLOGY JPERSON JPERSON_FLAT_OWNERSHIP JPERSON_NAME JPERSON_PARCEL_OWNERSHIP JPERSON_TAX_NO JPERSON_TAX_OFFICE JPERSON_TYPE MAP_DEF MAP_DEF_SX_FL6$ MINING MINING_LOCAT_PROD_MAP NIR_INTENSIFYING NIR_1-2-A3-3I NIVELMAN P_ALTERATION PARCEL PARCEL_GEOM PARCEL_GEOM_SX_FL6$ PARCEL_ISLOCATEDAT_QUARTER PARCEL_ISLOCATEDAT_VILLAGE PARCEL_ISPARTOF_BLOCK PARCEL_LOCAT_MAP_DEF PARCEL_LOCAT_PROD_MAP PARCEL_VALUE PARCEL_USE PARKS PARKS_LOCAT_PROD_MAP PARKS_SX_FL6$ PBLOCK PBLOCK_GEOM PBLOCK_GEOM_SX_FL6$ PBLOCK_ISLOCATEDAT_QUARTER PBLOCK_ISLOCATEDAT_VILLAGE
183
N Y N N N N N N Y Y Y Y N N N Y N N Y Y Y Y Y Y Y N Y N N Y Y Y N Y Y Y N
PBLOCK_LOCAT_MAP_DEF PBLOCK_LOCAT_PROD_MAP POLIGON PROD_MAP PROD_MAP_SX_FL6$ PROVINCE PROVINCE_ISPARTOF_COUNTRY PROVINCE_NAME PROVINCE_GEOM RPERSON RPERSON_FLAT_OWNERSHIP RPERSON_PARCEL_OWNERSHIP RPERSON_REGINFO TOPOGRAPHY TOPOGRAPHY_SX_FL6$ TRANS_LOCAT_PROD_MAP TRANSPORTATION TRANSPORTATION_SX_FL8$ VEGETATION VEGET_LOCAT_PROD_MAP VILLAGE VILLAGE_ISLOCATEDAT_DISTRICT VILLAGE_LOCAT_MAP_DEF VILLAGE_LOCAT_PROD_MAP VILLAGE_NAME VILLAGEWARD VILLAGEWARD_BELONGSTO_VILLAGE VW_NAME
184
N N Y Y Y Y Y N Y Y Y N Y N Y N N N N N N N N N N
