critical concerns for maintaining large datasets is assuring that only good data is put in. The geodatabase provides mechanisms to control what is entered into the dataset.
• Users work with more intuitive data objects. A properly designed geodatabase presents the user with multifaceted objects that combine spatial and nonspatial data into a single composite. Spatial features are no longer “dumb” points and lines but become roads, train stations, and bus stops. Nor is each type of object isolated from the others. By using an integrated geodatabase, you can maintain the relationships between objects. You can even use them during editing to specify what happens to other features when you move or modify a different feature.
Designing a geodatabase is a process of deciding which capabilities to use. You are not starting from a blank sheet of paper. The basic framework for an efficient enterprise design is already in place inside the geodatabase.
The geodatabase
The geodatabase is a collection of ArcObjects, but that simple definition does not really tell you what it does. ArcObjects interact with each other. If you establish a topological relationship between two lines, a change in one line can produce changes in the other line. Or you could create a connectivity rule that says a surface street may not connect directly to a limited-access highway, only to an exit ramp. You can control the direction of one-way streets or ensure that water always flows downhill. You can specify a particular map appearance for a given situation, such as label placement that does not overlap another feature. You can click on a feature and have a form appear. All of these functions are possible because the components of a geodatabase interact with each other and the user.
Figure 3.1 ArcGIS geodatabase feature dataset An ArcGIS geodatabase feature dataset can contain different class types. The more common types are discussed here.
A geodatabase consists of feature datasets, domains, validation rules, raster datasets, TIN datasets, survey datasets, metadata documents, and locators. A feature dataset can have a spatial reference that is shared by all the feature classes in the dataset. Transportation networks, geometric networks, and planar topology rules can be in a feature dataset.
Transportation data users are most concerned with four geodatabase class types: tables, features, relationships, and transport networks. ArcGIS supplies a uniform appearance for all these class types regardless of the database management system environment you implement.
A table is a class for which you can specify attributes and behaviors to represent an entity in the real world. It looks just like a relational table. ArcGIS even creates a primary key field, called OBJECTID, for you. Of course, you can create another field that can also uniquely identify each row in the table in order to support association relationships.
Although the OBJECTID field supplied by ArcGIS for all tables and feature classes is the primary key used by the software, it is not really a good foreign key for you to rely upon. The problem with OBJECTID is that it has values that can change as a result of certain database operations. For example, if you merge members of two tables into one, the OBJECTID values can change. Any foreign key relationships that you had constructed using OBJECTID no longer would work because those OBJECTID values are now gone or (worse) apply to other rows.
You create a candidate primary key in each of the classes that you will want to link to another class through a foreign key, whether it is implicit or instantiated in a relationship class. Some ways to do that are presented later.
Most ArcGIS documentation describes a feature class as a table class with a shape column. But a feature class also has all the added software required to work with geometry.
A transportation network uses feature classes as the source for information to construct a logical topology of the system and its behaviors. For example, you can define sign features to guide users who perform pathfinding analyses, or turn tables to express the temporal restrictions of movement by particular vehicle types at junctions.
Relationship classes manage associations between classes, although you can also rely upon on-the-fly relates and joins to tie classes together using foreign keys. Relationship classes are an important part of many best practices for transportation database design.
The geodatabase framework
The balance of this chapter is one big rocket science sidebar that will take you “under the hood” to present the internal structure of the ArcGIS geodatabase. If you don’t want to get your hands dirty, you can skip to the next chapter. However, if your job is to guide the data modeling process, create or implement the physical data model, or manage the geodatabase once it is created, then you are the mechanic others will rely upon and you will benefit from knowing how the geodatabase works. Of course, transportation types tend to like to take things apart to see how they work, so feel free to read this chapter for sheer pleasure, regardless of your role in a database development project.
Figure 3.2 The geodatabase This conceptual data model shows the core components of the geodatabase support structure. The included relationships suggest the sequence of events that produce the cascading instantiation of the classes shown here. For example, a WorkspaceFactory class creates a Workspace class into which a Name class can instantiate a Dataset subclass. The figure also shows that the Table class is the mother of ObjectClass and grandmother of FeatureClass—the two primary components with which you will interact. Through this series of inheritance relationships, FeatureClass has all the interfaces of Dataset, Table, and ObjectClass.
This conceptual model (figure 3.2) shows the primary classes that comprise the geodatabase. Exploring this diagram will help you understand both how the geodatabase works and the model symbology we use.
Starting at the top, you can see that a WorkspaceFactory instantiates a Workspace. You invoke a workspace factory when you tell ArcGIS the directory, file name, and connection properties for the data you plan to store and use. There are many types of workspace factories, each intended to create a particular type of workspace, as determined by the database management system that applies. For example, there are workspace factories for shapefiles, personal geodatabases, enterprise geodatabases, and CAD (computer-aided design) file structures. A workspace is a geodatabase, a coverage workspace, or an operating system folder containing shapefiles.
The workspace factory creates the kind of workspace you need to manage data. There are three basic kinds of workspace: file systems (shapefiles and coverages); local databases (personal geodatabase); and remote databases (SQL Server and other RDBMS products). Each database management environment requires its own methods of communication and data operators. You use workspaces to create every other kind of class. For example, the CreateTable function of the IFeatureWorkspace interface creates a new table class when you supply the name of the table.
Domain classes are created at the workspace level and can be applied to user-supplied attribute values in any dataset that exists
