Presented at the SaGES 2019 Conference, Nicholls State University, August, 2019. Re-thinking the Data Model: GIS as/is a Relational Database N.W.J. Hazelton and Yitong Wu Department of Geospatial Informatics, Troy University, Troy, AL, 36082. Email: [email protected] Abstract GIS application software matches spatial data very well with relational database technology for storing attribute data, even if a relational database is not used for storing the spatial components of the data. Early efforts to use a relational database as the foundational storage system for GIS ran into serious performance issues or used databases that were not fully relational (e.g., Empress for the System 9 GIS). More recent systems use extended relational databases as a storage system, in effect acting as a flat-file system of links to external files, but the spatial data component is handled by other software in a non-relational way. Yet the fundamental nature of GIS, whether raster or vector in nature, satisfies relational logic. GIS operations cannot proceed unless the GIS’s spatial data has been normalized to at least the Third Normal Form. Despite the many advances in making GIS object-oriented, both as they appear to the user and as they operate at a deeper level, whether a database is relational depends solely upon whether or not it can be conceived of by the user as being able to be represented solely using tables that contain straightforward atomic values (i.e., no pointers or similar addressing structures). As GIS commonly have their data perceived as maps and spatial/graphical representations, rather than purely as tables, the question for GIS comes down to whether the user can reasonably represent the underlying data, both spatial and attribute, as simple tables. Introduction The earliest developments in GIS were largely built using the grid-cell model. Here the attribute data was contained in separate files or separate structures within a single file, and most systems allowed a single value per grid cell. There were experiments with pixels that contained more than one attribute, termed ‘mixcels,’ but this was difficult to implement and was not continued. As grid-cell systems gained greater complexity, there was an effort to move attribute data into some kind of external file. In many cases, this was a simple table, stored in a text or binary format. Sometimes, the table was included in a database, and this was often in dBase III format, as this was popular as a PC-based database management system (DBMS) in the early years of widespread GIS adoption. The development of vector-based GIS, such as ESRI’s ARC/INFO, required a separation between the spatial data component and the attribute data component, and a relational database was a common means of storing the attribute data. The advantages of using an external database included being able to focus development on the means of storing and processing the spatial data, without having to worry about development of an attribute DBMS. INFO, the initial database used for ARC/INFO, was an early relational database. In the early days of ARC/INFO, the bulk of database research was focused on relational DBMS (Date, 1988, pp. 19-20). Despite the problems that became apparent in trying to place topologically-related spatial data into a relational database (e.g., van Roessel, 1986), relational DBMS became the attribute database of choice for GIS. The problems involved in placing topologically-related spatial data into a relational database are concerned with practicality, rather than what is possible. Traditionally, the ARC/INFO topological model for coverage was represented as a series of tables (relations), and while it was certainly possible to store spatial data that way (van Roessel (1986) suggested it as a means of data transfer), practical operation dictated other solutions. The primary problem arises when something as simple as a click to select a data item occurs. To determine which item has been clicked and bring up all the components required to display it involves a massive series of joins of the entire spatial database, and this recurs with almost every operation or query on the spatial data. As a consequence, ARC/INFO used a form of network database to store the spatial data, while the attribute data were stored in the INFO relational database. In later versions, and into ArcGIS, the spatial data is still moved to a network-type repository for analysis, despite being stored in a range of other data models, such as shapefiles. The spatial extensions to Oracle consist of links stored in relational tables to connect to external network-like data storage. The object-oriented data model can be adapted to the practical needs of spatial information processing and avoids the need to separate attribute and spatial data so sharply. However, discussion of object-oriented data models in any depth is beyond the scope of this paper. Figure 1 Classical Points–Lines–Polygons Tables giving a Relational Structure to Vector-Based Spatial Data. The Primary Key in each table is marked with an asterisk. Note that the Polygons table has a composite key. All of the attributes in the Lines table are foreign keys for the other tables. This arrangement of attributes and keys ensures both normalization and avoidance of complex functional dependencies. - 2 - Relational Database Definitions In his efforts to formalize the various definitions relating to relational databases, Date (1988) used somewhat different language to the earlier work of Codd (1970, 1974), to deal with some issues that had become apparent in database design since that time. There have been subsequent refinements, but we will retain Date’s definitions. Relational Database Date (1988, p. 320) defines a database system as relational “if and only if it supports at least the following: • Relational databases (i.e., databases that can be perceived by the users as tables, and nothing but tables); • At least the operations Select, Project, and (natural) Join, without requiring any predefinition of physical access paths to support those operations.” The named operations do not have to be supported explicitly, i.e., they may be invoked by other names and within larger functional processes. SQL is not required to be used as the operational and query language. There is no requirement that tables are indexed (although this is highly desirable for efficient operation), but it must be possible to query on any field, whether it is indexed or not. Within the spatial data component of GIS, the select operation (retrieving one or more tuples from a table) can be implemented in many ways, such as by running a formal SQL query or (more commonly) by clicking on a visible object. The project operation selects specific attributes (i.e., selects a column from a table), and in GIS that can be achieve by a query concerning all objects that have certain attributes (commonly by using the SQL SELECT statement in a query in a vector-based GIS, but also by threshold modeling in a grid-cell GIS). A join operation in GIS consist of a spatial overlay operation, and is achieved by a number of possible operations, depending upon the nature of the join required and the particular GIS in question. The user’s perception of tables means tables of data in their simplest form. The rows (tuples or records) are unordered, and the columns (fields) are likewise unordered. Each field contains single values (atomic, in that they cannot be divided into anything simpler). Each tuple has a unique identifier field or combination of fields, termed the primary key. Each tuple in any table is a relation that includes the various fields and can be modeled using the mathematics of relations. The fields in the relations are time-varying, in that values may be changed over time, i.e., the database does not have to be fixed in time but can be a dynamic entity. The relations are normalized to some degree (Date, 1988, p. 245). The question of the user perceiving the database as tables is important in GIS. A GIS user perceives the data in the GIS as predominantly graphical or spatial and consider it in terms of a map. But as has been argued elsewhere, such as by van Roessel (1986) through to Burrough et al., (2015), it is easily possible to consider GIS spatial data in the form of tables, whether a grid-cell or vector-based GIS is under discussion. An example of such a representation for vector-based GIS is shown in Figure 1. Of course, attribute data is readily perceived as tables. If the spatial component of a vector-based GIS is stored in a network database form, does this invalidate GIS being considered as a relational database? No, the critical issue is the user’s perception of the database as tables. This perception is at the conceptual level of the database architecture, not the internal or physical level. Many databases that are sold as RDBMS and can be operated as RDBMS at the conceptual level, are something quite different at the internal level. IBM’s DB2 can be considered as a RDBMS at the conceptual - 3 - level, which is as deep as most users need to go, but at the physical level it is primarily an inverted list type of database. So the relational definition is concerned purely with the conceptual level of the database architecture, and there is no need for a truly relational implementation at the internal or physical level. Keys Data is retrieved from a relational database by means of keys. There are a number of different types of keys that need to be considered, and they will be defined here.