workspace. There are several domain types, each with its own creatable class. For now, we only show the abstract superclass to illustrate the central point of domains being tied to the workspace, not a particular dataset. The one-to-many cardinality for the association relationship between Workspace and Domain shows that no domain class is required.
A dataset is any kind of data container, and the Dataset class is the grand ancestor of all other data classes. Dataset is an abstract class that represents a named collection of data in a workspace. It provides such functions as copy, delete, and rename, and controls access to data classes based on user privileges, which is common to all data class types. When you initiate editing in a geodatabase, one thing that happens behind the scenes is that the IDatasetEdit interface of the Dataset class sets the IsBeingEdited property to True for each dataset that can participate in the editing session. The cardinality of the Workspace-Dataset relationship shows that a workspace must include at least one dataset.
PropertySet is exactly what it sounds like: a set of properties defined for each dataset. For example, it can contain the connection instructions for linking to a remote database where the dataset is stored. If you could look inside this class, you would see a list of two columns, with property names in one column and the values of those properties in the other column.
The sequence of classes on the right side of the figure—Table, ObjectClass, and FeatureClass—form the core used in geodatabase data models. The Table class provides the basic data storage mechanism of a relational table consisting of columns, referred to as fields, and an unordered collection of rows containing table members. You connect a relational table to the geodatabase through registration methods of the Table class. Since it is a child of Dataset, it inherits all the properties and methods of the parent class, such as knowing the name to be displayed in ArcGIS, the actual table name used in the RDBMS, and the location of the relational table in the database. The Table class uses the ITable interface to provide the methods required to read and write rows in the relational table.
ObjectClass adds the necessary properties and methods to turn a relational table into an entity in your geodatabase. For example, it knows about relationships in which the table may participate, and the domains, rules, and default values that apply to various fields. ObjectClass adds the OBJECTID primary key field to the relational table it represents. When you create a table in ArcGIS, you are customizing a copy of the ObjectClass.
You do the same thing to create a feature class, except you are working with a copy of the FeatureClass class. As you already know, a feature class is just like an object class except that its members include a geometry property and the class has methods to work with that geometry. FeatureClass contains everything that any kind of geometry will need, but ArcGIS is clever enough to show you only the parts that apply to the type of geometry you are actually using for that class. For example, the IFeatureClass interface includes properties for shape length and shape area, but ArcGIS will only show you those properties when they are appropriate for the geometry of that class. You will not, for instance, see the Shape_Length field for a class with point geometry in the data dictionary view of a physical geodatabase model.
Figure 3.2 also shows three kinds of geometry datasets in the lower-left quadrant. There are more kinds of such datasets than we include. The one we want to emphasize here is the feature dataset, which consists of a set of one or more feature classes and may include a geometric network. Notice the difference in these relationships. Deleting a feature dataset containing a geometric network also deletes the network, while the same action with a feature dataset composed of simple feature classes merely removes the grouping, not its members.
Figure 3.3 shows how the engine works. This is really hard-core stuff, so you can skip it if you are not interested. We offer this illustration to demonstrate that such simple things as a single relational table require a large number of ArcObjects classes to support the functionality offered by the geodatabase.
ArcGIS provides five classes that help the Table class keep up with the data it manages. A table consists of columns, called fields, and unordered rows of data. All of these things are not stuffed into the Table class but are spread out over supporting classes. A Fields class stores the total number of fields in the table. Each such field is described in a Field class member. The OBJECTID field is created by ArcGIS to provide a primary key. If a feature class uses the table, one of the fields will define a type of geometry. Users can specify that an index be created on other fields. An index is always created on OBJECTID. An Indexes class manages all the indexes that exist for a table.
Figure 3.3 Table classes In ArcGIS, a large collection of classes performs a variety of database management system functions. Classes to the left of Table store information about the format of class attributes added by the user and manages any related indexes. If a user-defined class includes geometry, the GeometryDef class stores information about the kind of geometry to expect. Classes to the right of Table allow data rows to be created and retrieved. In the geodatabase, a Table class is a way to manage a collection of Row classes. A Feature-Cursor additionally knows how to read and create rows containing a geometry attribute, but it is the Field “gene” it inherited from its Table grandmother that tells it about the geometry. We visualize and interact with object and feature classes as simple rows in a table but they are actually much more.
The Table class does not directly interact with the data container, whether it is a shapefile or an ArcSDE instance managing a relational database. The Table class works through cursors. A cursor is used to manipulate records in a file or relational table by undertaking such tasks as creating, retrieving, and deleting rows in the host database environment. The Table class instantiates the Cursor class to work with instances of the Row class. In the same way, the FeatureClass object works through a FeatureCursor class to access Feature instances. Both paths point to functions supplied by the Row class, which includes the interfaces needed to change, compare, and edit records in the data table, and to report errors. All rows in a table have the same fields. The Table class uses the Field classes to help it understand what is in each row.
The data dictionary view
ArcGIS provides the means to view a table or feature class using the physical data model perspective. This is called the data dictionary view because it displays the contents of each table or feature class. You can see the name for the class and its type in the header. If it is a feature class, you will also be able to see the type of geometry used and whether it contains measure (M) and elevation (Z) values.
Figure 3.4 Tables and feature classes A geodatabase is seen as a collection of tables and feature classes. These examples show the minimal attributes such classes will contain. You may add many other attributes to any of these classes, but you cannot delete the mandatory attributes.
Below the header is a listing of each field in the class’s table. The first field will always be OBJECTID. If it is a feature class, you will also see a Shape field and, depending on the type of feature, Shape_Length and Shape_Area fields. ArcGIS adds these fields and you cannot delete them or change their parameters.
When you create a field, you must specify a data type, whether null values are allowed, a default value that will be entered if the user makes no specific entry, the name of a domain to control data entries, the precision and scale of numeric fields, and the length of a string field. The user can modify field parameters that are not set to a
