Geodatabase

A geodatabase is a database designed to store, query, and manipulate geographic information and spatial data. It is also known as a spatial database.

Within a spatial database, spatial data is treated as any other data type. Vector data can be stored as point, line or polygon data types, and may have an associated spatial reference system. A geodatabase record can use a geometry data type to represent the location of an object in the physical world and other standard database data types to store the object's associated attributes. Some geodatabases, such as those used by Esri in their ArcGIS software, also include support for storing raster data.

Many geodatabases have custom functions that allow the spatial data to be manipulated and queried using SQL, for example to find all the residents of an area within an exposure zone for a potential environmental hazard. However the spatial data in some geodatabases can only be accessed by using specialized client software.

Within a geographic information system (GIS) a spatial database is one component that can be used to store and manipulate data. Typically a complete system will also include client software to view and edit the data stored within the database. Like other spatial data formats geodatabases can also be used to serve data directly to web map server software, such as Esri's ArcGIS Server, MapServer and Google's mapping API.

The primary advantage of spatial databases, over file-based data storage, is that they let a GIS build on the existing capabilities of relational database management systems (RDBMS). This includes support for SQL and the ability to generate complex geospatial queries. Also, a database's client/server architecture supports multiple users simultaneously and lets them view, edit, and query the database without conflict.

History
Early GISs separated spatial data from attribute data and linked related records through a common identifier. Using specialized file structures (such as node/chain) for handling spatial data was necessary for efficient storage and processing. Attribute data was commonly in a file or RDBMS. Examples of this architecture are the Arc/Info coverage and Shapefile.

The early implementations to store both spatial and attribute data in a database used middleware to store spatial data using a traditional datatype such as BLOB, implement spatial indexing and provide a spatial query interface to applications. The IBM Geographic Database System (GDBS) in the mid-1980s used the IBM IMS hierarchical database and the IBM GeoManager in 1990 used the IBM DB2 relational database management system.

An early development in storing spatial data in a modified relational database management system resulted in a modified Oracle v.4 during the late 1980s and early 1990s; this eventually led to the creation of Oracle Spatial.

In the late 1990s Object-relational databases (ORDBMS) allowed geometry types to be added to additional databases. Some ORDBMSs were also extended with custom functions for the processing of spatial data using SQL. R-tree indexes allow efficient querying of the spatial data.

Implementations
By the mid-2000s, a variety of commercial and open source database management systems had the ability to store geospatial data, including IBM DB2, Microsoft Access, PostgreSQL, Microsoft SQL Server, MySQL and Oracle. It can be manipulated using extensions such as IBM DB2 Spatial Extender, Oracle Spatial, PostGIS, Intergraph's GeoMedia, ESRI's ArcGIS or ArcSDE and Informix Spatial DataBlade.

Geodatabase Design Steps
Design starts with thematic layers. Firstly, thematic layers should be identified for particular applications and information requirements. Then each thematic layer in more detail should be defined. The characterization of each thematic layer will result in a specification of standard geodatabase data elements such as feature classes, tables, relationship classes, raster datasets, subtypes, topologies, domains, and so on.

While identifying thematic layers in design, each theme has to be characterized in terms of its visual representations, its expected uses in the GIS, its likely data sources, and its levels of resolution.

Once you have identified the key thematic layers in your design, the next step is to develop specifications for representing the contents of each thematic layer in the physical database.