How To Spatially Enable Business Information Systems
Step 1:  Survey the existing database structures and determine if entities contain geographic elements such as address, city, state, zip, county or region.  Tables with attributes such as these are often the starting points to building a spatial data repository from an existing database. 

Step 2:  Determine if the role of the existing database will interfere with the GIS and vice a versa. Most GIS are used for reporting and analytical purposes and must achieve high performance data retrieval speeds to be effective.  In that regard, spatially enabling a volitile, busy online transaction processing database can be a big mistake.  Rather, a good geodatabase will likely be a data warehouse isolated from other databases on separate hardware dedicated to GIS.   Also, even if the data creation and maintenance activities originate in a geodatabase, those activities should be performed in an online transaction processing geodatabase separate from the data warehouse geodatabase. 

Step 3:  Determine the data update requirements.  Does the spatial data get updated on intervals such as nightly and weekly (like most data warehouses) or is the data updated continuously in real time (like a tracking system or online trasaction processing system)?  These types of geodatbases must be laid out much differently from one another.  For example, data warehouse GIS systems usually require performing a high volume of data processing as data updates are loaded in batches.  These operations are best done by scheduled jobs that execute after the data replication jobs that load the data warehouse are completed.  On the other hand, geodatbases which manage real-time systems for emergency responses and other tracking systems must update the spatial data quickly as the events occur. Factors such as these influence the geodatabase design dramatically and must be considered before the geodatabse design phase begins.

Step 4:  Design the geododatabase to ensure geographic data entities (commonly reffered to as feature classes) are created in a normalized manner.  By normalized manner we mean primarily to prevent redundant spatial data.  Occasionaly this may require modification to existing data structures.  For example, addresses should be consolidated to a single table and made unique within that table.  When many tables within a database are attributed with address fields, the same addresses can then occur in multiple tables.  In a geodatabase un-normalized data such as this can force geocoding operations to be peformed multiple times on the same address which makes the system in-efficient.  Also, in any database redundant data should be eliminated to prevent values in tables from contradicting one another. 

Step 5:  Create the new geodatabase.  When creating a new geodatabase it may be created from scratch in an brand new empty database or an existing database may be spatially enabled, thus tranforming it into a geodatabase. 

If the geodatabase is to be developed from an existing database which contains tables and data, ArcSDE provides command line tools such as "sdelayer"  to spatially enable existing tables.  First the database itself must be spatially enabled by running the ArcSDE post intallation over the database instance.  Once ArcSDE has been installed into the database instance sdelayer and other ArcSDE command line commands may be used upon tables within the database to add spatial attributes.  When an existing table is spatially enabled, ArcSDE simply places two additional columns on the table.  The first column is named "shape" and the second is named "objectid".  At this point the shape column is empty and the objectid column is simply filled with unique sequential numeric values. 

If the geodatabase is to be created from scratch, the ArcSDE post installation program must first be run upon the new empty database instance to install the ArcSDE tables, packages and procedures.  From that point, the database still retains all the functionality of a non-spatial database and can be used in every way it could before it was enabled.  There are a number of ways to establish spatial tables within the database using ESRI toolsets.   Nothing is required outside of ArcSDE to accomplish geodatabase creation if you like developing DDL like scripts with ArcSDE command line commands like sdelayer.  However, ESRI ArcGIS Desktop includes ArcCatalog which is much like the "Enterprise Manager" of ESRI.  WIth ArcCatalog you may create tables and feature classes in a user friendly GUI environment without command line scripts invovled.  In addition, ESRI ArcGIS Desktop provides a case tool which translates Visio UML diagrams into geodatabase tables if you prefer to use that route.

Step 6:  Perform Initial Spatial Enablement to batch build geometry in the geodatabase tables.  We shall focus on vector data and exclude raster (imagery) for the time being.  When a spatial table (feature class) is created in a geodatabase, it is a completely normal database table except for the objectid and shape columns that ArcSE adds to it.  When these columns are added to existing database tables ESRI software recognizes the tables as spatial tables.  However, the spatial tables will not render on maps at this point since the shape column contains no geometery for the GIS to render.  This is where initial spatial enablement comes in.  Initial spatial enablement usually involves running processes which read rows of data in tables and uses parts of that data to create some type of geometry.  Once the geometry is made from the data in rows, it is then stored back into the shape column of the spatial table.  For rows with address, city, state, zip or county this process usually involves geocoding points.  Geocoding addresses is a big topic and is best left for another white paper.  In other cases, rows may contain a "from-address" and a "to-address", thus forming a route line.  Other tables may have rows that must be poplulated with polygon shapes derived from things such as county, state or other areas.   The numbers of ways to derive and create spatial data are too many to describe, but the basic business spatial entities are often created from methods similar to ones described above.  Initial spatial enablement can be pretty involved especially if there is special logic required (often refered to as geoprocessing) to derive the geometry.  Geoprocessing can involve development of custom software applications, scripts or models.  Once these applications, scripts or models are developed the intitial spatial enablement is kicked off.  Depending on the size of the spatial table, initial spatial enablement can take seconds or it can take days or weeks. 

Step 7:  Perform Continuous Spatial Enablement to maintain the geometry within the geodatabase tables.  Continuous spatial enablement is performed to replace geometry in shape columns when data values from which the geometry is derived changes.  For example, a spatial table which contains point shapes derived from geocoded postal addresses must be re-geocoded when the data values of the postal addresses change.  Also, if new postal addresses are added to the table the geocoding operation must be performed to create the point geometry for the new data.  Consequently, continuous spatial enablement is best when performed only on rows of data that have changed or were added.  Often to accomplish continuous spatial enablement, scheduled data processing jobs are used.  These jobs can be created from the geoprocessing logic developed for the initial spatial enablement step above, but made more intelligent as to not re-process all of the data needlessly.  Another and usually better way to accomplish this is by "on-update" and "on-insert" database triggers.  Triggered continuous enablement is better because it is good for both batch and real-time updates, but be wary since triggers can also lead to problems that may interfere with other operations that occur in the database not related to GIS.  Geodatabases in DB2 (Spatial Extender) and Informix (Data Blade) must employ database spatial extensions, but spatial extensions (Oracle Spatial) are optional for Oracle and not available with SQL Server, yet. Ultimately, spatial extensions are a standard that extend SQL itself and are what enables spatial data creation logic to be performed by the database with stored procedures, triggers and the like.  As an alternative to spatial extensions, geometry creation logic can be written with the ESRI ArcObjects code libraries called by Microsoft .NET, Visual Basic 6.0, C++ or Java programs.  ArcObjects offers many functions beyond those in the spatial extensions, and has the advantage of portability enabling it to be used upon any of the ArcSDE supported RDBMS.  Still, another method of geometry creation logic is done with the ESRI ArcGIS Desckop Geoprocessing Toolbox, Models and Scripts.  Search for "geoprocessing" at the ESRI Devleoper Network website to get started that way.