The Different Styles of Database Architecture in Geographical Information Systems 
Introduction
According to Kenneth Dueker, a Geographical Information System (GIS) is “a special case of information systems where the database consists of observations on spatially distributed features, activities, or events, which are definable in space as points, lines, or areas. A GIS manipulates data about these points, lines, and areas to retrieve data for ad hoc queries and analyses (Dueker, 1979).” There have been many types of databases that have been created and constructed over the years. Databases have been used in countless types of applications and for many purposes. However, even though the construction of the database has become somewhat rudimentary for database administrators, up until fairly recently, databases have not yet been seen in any other form except data and information management. While this is a very common and useful form of a database, there are other aspects of this technology that had yet to be discovered. Out of the four main database models that have been developed (Network, Hierarchical, Relational, and Object Oriented), there are two key models that form the key components to the construction of a GIS database in that they use certain characteristics of those models to create the GIS database architecture (Ricker, 2006).
Database Background
In general, a database can be described as a set of files or records that have some sort of relation to one another. In the two earlier models mentioned above (Network and Hierarchical), there are issues of flexibility in terms of the management of the database. The Hierarchical database, very similar to Extensible Markup Language (XML), is not as flexible as a database should be because of the parent / child relationship. In a Hierarchical database, if a relationship needs to be changed, it might be difficult to change it once the tables have been created. Similarly, the Network database model has a owner / member relationship allowing multiple “parents” and “children” relationships. There are some cases where one of these two types of database models may be needed, however, the most popular database model today is called the relational database model which provides much more flexibility and capabilities to change with the growing environment (Brown, Aspinall, & Bennett, 2006).
The relational model, developed in 1969 by Edgar Codd, is based on a set of mathematical principles and theories that allows data and information to be stored in cross-referenced tables. This idea of cross-referencing allowed information to be displayed almost however the user requests it using ad hoc (custom designed) queries. In order to do this, Codd designed a system of relationships called keys that can be placed on any column(s) of a table and where any key can be referenced from any table. There are two types of keys in a relational database – primary and foreign. The primary key marks the unique identifier of a table and a foreign key represents the primary key of an external table. A query against a relational database
containing baseball information might be able to pull all the people with a batting average of .3 and above from two different leagues or teams (Burrough & McDonnell, 1998). The relational database model provides support for cascading updates, inserts, and deletes so that the each table does not have to be monitored individually. This revolutionary structure is the most popular database model today, being utilized by major companies such as Microsoft and Oracle (Burrough & McDonnell, 1998).
An object oriented database is based on the idea of object oriented programming. As many programmers and developers know, there is a huge difference between an object oriented language and a procedural language. A procedural language is a basic set of instructions that are completed in a procedural fashion whereas an object oriented language is a programming language that is based on objects and its properties or characteristics. The procedural approach is still used in object oriented programming, but the key to object oriented programming is the ability to create objects and manipulate them. In the case of databases, the object oriented database is able to present information in the form of objects instead of text and is designed to work with certain programming languages such as Java, C#, Visual Basic .NET, C++ and Smalltalk (Corbley, 2007).
The main difference between object oriented databases and relational databases are their capabilities of storage. Where a relational database has the capabilities of storing the word “door,” an object oriented database has the capabilities of storing the same word along with a picture, video, or sound clip of what the word means. As one can imagine, an object oriented database model is very important to a GIS because of its ability to store pictures, maps, and other “objects” that cannot be described completely in a text-only fashion. A GIS does not necessarily use an object oriented database structure, but uses some of its qualities and characteristics so that data can be manipulated around certain maps and graphs (Corbley, 2007).
GIS Database Architecture
Designing a GIS database involves converting the conceptual design to a physical design. The GIS software that will be used determines most of the physical database design. In a GIS, the structure and format of the data have already been determined by each of their respective vendors. If a vendor separates the conceptual component and its attributes from the corresponding spatial component and its geometric representation, it is common that the physical database design for the spatial component has been completely defined by the vendor and the GIS application designer need not do anything more for this part of the data. The attributes of the components may, however, be held in a relational database management system (DBMS) linked to the GIS (ArcGIS using Microsoft Access as a backend DBMS). If this is the case, the GIS analyst needs to design the relational tables for the attribute information (Miller & Mangold, 2006).
In designing the architecture for how a database will be built and developed, it is very important to recognize the difference between the abstract data structure (the set of elements or attributes to be stored), or logical design, versus the physical data structure (how it is actually implemented), or physical design (Star, Estes, & McGwire, 1997).
The abstract data structure can be defined, as stated above, by the set of elements or attributes to be stored, the operations to be performed on them, and, the possible errors that may
occur. Although this seems as though it is a structure to follow for most database and application development, there is much else that should be considered when developing a database for a GIS. In a GIS, the data structures are very different from a normal relational database, yet at the same time, they are very similar. GIS use some of the concepts of a relational database and apply them to objects such as a map or a graph, in fact, many GIS software applications may use a third party database management system as its back-end data management. The data structures for a GIS must represent a map or a planar graph instead of just storing data; a common GIS structure might include elements – polygons representing states or other regions (Geneletti, 2007). Accompanying the polygons are operations that need to be performed with them in order to make a map item and every operation is comprised of six steps. 1) Draw the polygon. 2) Verify the internal consistency of the map (this would be finding the coordinate system of the map and assuring that the newly drawn polygon is comprised of the same coordinate system or drawing the new polygon in a compatible coordinate system.). 3) Calculate all the properties of the new polygon (i.e. area, perimeter, coordinate points). 4) Find the adjacent polygons to the newly created polygon. 5) Scale the map or transform it to another coordinate system (if not already in the same coordinate system). In order for the polygon to be drawn correctly, all of these operations should be followed. Along with these operations, however, there are still other criteria that should be considered when designing a GIS database system: design criteria. The design criteria is comprised of a few different components: 1) amount of storage used (in physical units such as hard drive space or RAM). 2) likelihood of errors (it is a good idea to take errors into consideration early-on in development.). 3) ease of implementation (along with errors, this is a good idea for future planning). 4) efficiency of execution (Florance, 2006) (Downye, 2006).
The efficiency of execution of a GIS is critical because if the execution or implementation is not smooth and free of errors (or at least as little errors as possible), one might run the risk of the GIS being rejected by its users. How the GIS is implemented is contingent upon the physical realization of the data structure. There are two major choices when deciding on the data structure of the database: a polygon based structure or an edge based structure (Hwang, 2006).
In a polygon structure, the polygons are stored merely as a sequence of points where the type of polygon and number of points would determine the storage space required for each individual polygon. This means that if there are two polygons that are adjacent to one another, the system would need to store the coordinates of the adjacent points twice (once for each polygon) (Rozgus, 2006). This polygon structure makes it very easy to handle each polygon within the GIS, however, with this data structure, the amount of storage used is often sacrificed for the ease of polygon management. This is a structure that might work best if the GIS will be dealing with primarily smaller types of maps and data sets in general. The more polygons that are created within this type of GIS structure, the more memory will be used to store those polygons. Another item to consider when contemplating a polygon structure is that of data redundancy. If there are two polygons that are adjacent to one another, one must assure that the adjacent point for polygon 1 (one) is exactly equal to the matching point of polygon 2 (two). If this is not the case, there can be data inconsistencies and redundancies that will arise if the two versions of each point are not identical down to the last millimeter. A polygon structure is a decent structure to assume as long as all of its pros and cons are not overlooked and step 2 (two) of the data design criteria, as noted above, is followed (Florance, 2006).

The other type of data structure is the edge based structure. In this type of structure, the polygons are formed by edges or chains. The edges simply separate the polygons and the polygons exist only in a stored ID number. Each edge has stored in its respective table the ID numbers of the two polygons that it is separating. This type of structure is easier on the storage area aspect of the design criteria because it takes up less space, but it is more difficult to manipulate the different polygons because it requires finding all of the edges associated with them (Florance, 2006).
Within the edge based structure, there are two different choices that can be made. The choices are whether to store a complete chain of points, or to store each edge separately. If the developer should choose to store a complete chain of points instead of storing each edge separately, he should be aware that although it is more space effective, it stores variable length data elements that can be more complicated and difficult to work with (Florance, 2006).
Part of designing a good data structure is setting the access level for the user so that the user is not able to write directly to the tables or the database at all. A clean and well designed implementation of the map’s data structure would tend to not allow most, if not all, of the program direct access to the data and databases. Instead, the desired operations would be “preprogrammed” into very basic operations such as: returning the total number of polygons, returning the external name of the polygon that is internally i, returning the number of points in polygon x, or returning a certain point for a certain polygon. These queries would then be configured and personalized into ad hoc queries to pull exactly the data that the user requires (Knigge & Meghan, 2006).
Procedures for Building the GIS Database
When a vast majority of technology specialists think of designing a GIS database, it is not uncommon for many of them to believe that it is simply a matter of replicating a map on a computer. The truth of the matter is that building a GIS database involves far more than simply a digital copy of a map. It usually includes many other sources such as tabular files, digital data, and aerial photos. Moreover, designing the “map” portion of the database is only the “front-end” to the type of information that it is actually storing. It is very possible and probable for a GIS database to be holding references to other objects, names and places, derived views form the data, and scanned images (photos, drawings, blueprints). This is a lot of information to gather and it may be challenging to find, hence, the collection of data from diverse sources and its organization into a useful database requires development of procedures to cover many different activities. 1) Getting the data – this includes finding and gathering data from both internal and external sources and then evaluating the source’s data integrity to assure that those sources are valid and true. If there are any problems with the data source, then the next procedure would be to 2) fix any problems in the data source. Another term for this is known as “map scrubbing,” where a heavy focus is placed on only the map source documents. In this procedure, the GIS analyst is expected to take responsibility of converting the paper map to its digital form. In the process of converting maps, there may be certain standards that the map will have to meet. If so, the map will not be accepted until it is ready to be fully implemented in the project. After the map has been fully digitized, there must be a process in place to account for future changes in the map. This process might be known as “evergreening.” After all of these steps have been completed, the sponsoring company will usually provide raw data that needs to be associated with the newly digitized map. It is the responsibility of the GIS analyst company to assure that
all of the raw data gets converted to a database type structure so that the GIS is able to be fully functional and operational (Maggio, 2007).
After the maps have been gathered, digitized, and all of the raw data has been synchronized with their respective aerial photos, blueprints, and drawings, similar to any other information system, one must consider how the system will be maintained and kept up-to-date. Because the world is constantly changing and “updating,” it is crucial that GIS applications and data are kept current. Without the evergreening process, a GIS database created today has a very high possibility of being completely irrelevant and rendered useless tomorrow. The timeliness of a GIS dataset begins from the date it is delivered at the client’s door. From that point on, it is the responsibility of the client organization to maintain the data, and its currency (Pickles, 2006).
A Geographical Information System is a very sophisticated information system that is capable of managing both spatial and non-spatial data. It handles both internal and external information to form its maps and information structure. This paper has gone over the many different steps and procedures in order to create a well-designed GIS (Geneletti, 2007). There are five different components that make up the design criteria of a GIS. 1) Draw the polygon. 2) Verify the internal consistency of the map (this would be finding the coordinate system of the map and assuring that the newly drawn polygon is comprised of the same coordinate system or drawing the new polygon in a compatible coordinate system.). 3) Calculate all the properties of the new polygon (i.e. area, perimeter, coordinate points). 4) Find the adjacent polygons to the newly created polygon. 5) Scale the map or transform it to another coordinate system (if not already in the same coordinate system). After these design criteria have been met, the data structure must be determined by choosing either a polygon based structure or an edge based structure – keeping in mind that a polygon based structure consumes more resources but is easier to manage and that an edge based structure consumes less resources, but is more difficult to manage. After deciding on the initial database structure, development needs to take place. A big part of development is gathering and converting data into the desired proper structure of the GIS. The gathering of the raw data, maps, aerial photos, blueprints, and plans are essential to the GIS database construction process. After all of the maps and photographs has been gathered, they need to be converted to the correct coordinate system and also comply with the standards set by the sponsored (client) company. Once the conversion is completed, the GIS changes custody from the GIS analyst to the client company. It is then the client company’s responsibility to continue to maintain the system.
A GIS is used by many companies and organizations such as county programs, governments, and engineering firms. There are infinitely many uses for GIS applications ranging from park planning to nationwide railroad systems, streets, highways, and freeways. Incredibly complex as they are, they are designed to be easy to use and because of that, have gained major acceptance and popularity from many organizations worldwide (Nieto & Robidoux, 2007). The importance of GIS today has grown so large that planning something as simple as a children’s soccer park might be incredibly difficult without one. Not only does a GIS help engineers to see the best location for a park in terms of its mere ability to fit, but also takes into consideration what is below the ground such as water and electrical lines. Consider the dangers of developing a soccer park or deeply supported playground where the metal of the jungle gyms collide with an electrical line. As one can see, geographical information systems are very important to any society where city planning is taking place (Laurini & Thompson, 1992).

Works Cited
Brown, D. G., Aspinall, R., & Bennett, D. A. (2006). Landscape Models and Explanation in Landscape Ecology - A Space for Generative Landscape Science? The Professional Geographer , 369 - 382.
Burrough, P. A., & McDonnell, R. A. (1998). Principles of Geographical Information Systems. New York: Oxford University Press.
Corbley, K. (2007). Can You Dig It? Utilities Update Their Maps' Accuracy to Answer the Question With Certainty. American City & County , 32 - 35.
Downye, L. (2006). Using GIS to Reconceptualize Spatial Relationships and Ecological context. American Journal of Sociology , 567 - 612.
Dueker, K. J. (1979). Land Resource Information Systems: A Review of Fifteen Years Experience. GeoProcessing , pp. 105 - 128.
Florance, P. (2006). GIS Collection Development within an Academic Library. Library Trends , 222 - 235.
Geneletti, D. (2007). An Approach Based on Spatial Multicriteria Analysis to Map the Nature Conservation Value of Agricultural Land. Journal of Environmental Management , 228 - 235.
Hwang, L. (2006). Mapping it Out. American School & University , 34 - 36.
Knigge, L., & Meghan, C. (2006). Grounded visualization: integrating the anaylsis of qualitative and quantitative data through grounded theory and visualization. Environment and Planning , 2021 - 2037.
Laurini, R., & Thompson, D. (1992). Fundamentals of Spatial Information Systems. San Diego: Academic Press Limited.
Llobera, M. (2007). Reconstructing Visual Landscapes. World Archaeology , 51 - 69.
Maggio, R. C. (2007). The Digital Pipeline: From Dirt To Desktop. Pipeline & Gas Journal , 32, 34, 36, 38.
Miller, F., & Mangold, W. G. (2006). Integrating GIS Applications Into Business Courses Using Online Business Geographics Modules. Journal of Education for Business , 74 - 79.
Nieto, A., & Robidoux, J. (2007). Potential use of GIS/GPS TeleGeMonitoring to Identify Sources of Vehicle Vibration Injuries. Mining Engineering , 56 - 63.
Pavlovskaya, M. (2006). Theorizing with GIS: a tool for critical geographies? Environment and Planning , 2003 - 2020.
Pickles, J. (2006). Ground Truth: The Social Implications of Geographic Information Systems. New York:
The Guilford Press.
Ricker, K. M. (2006). GIS Mentoring. Library Trends , 349 - 360.

Rozgus, A. (2006). A bird's eye view. Public Works , 47 - 48, 50.
Star, J. L., Estes, J. E., & McGwire, K. C. (1997). Integration of Geographic Information Systems and Remote Sensing. New York: Cambridge Univeristy Press.