{'fraction_non_alphanumeric': 0.018528610354223433, 'fraction_numerical': 0.0, 'mean_word_length': 5.0394736842105265, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Handling Spatial Objects in a GIS Database-Relational v Object Oriented Approaches

One of the foundations of spatial analysis is the object. Objects can be many things varying from an actual feature which can be extracted from a scene to more abstract entities which are associated with those features. There are a variety of database structures which can be used to store data about spatial features. These include RDBMS (Relational Database Management Systems) OODBMS (Object Oriented Database Management Systems) and ORDBMS (Object Relational Database Management Systems). All of these have retrieval systems based on SQL (Structured Query Language). RDBMS systems store data in tables linked by foreign keys, data fields which two or more tables have in common. These form the basis of the majority of database systems in use and include products such as Oracle and Microsoft Access. They can be used with GIS via ODBC (Open DataBase Connectivity) and handle spatial objects by extending the data types available. OODBMS and ORDBMS such as PostgreSQL also store data in tables, but each of the tables represents an object (or object class) which spatial users are more comfortable with. The tables are arranged in a hierarchy with objects lower in the hierarchy inheriting attributes from those at higher levels. It is also possible to have objects which are composed of other objects. The dominant development methodology for object oriented applications is based on UML (Unified Modelling Language). The aim of this paper is to compare the implementation of a GIS (Geographic Information System) database using RDBMS and OODBMS developed by normalisation and UML methodologies. To this end database schema of both types will be presented. These have been developed for an agricultural domain involving crop and field monitoring.