LITMIR.BIZ

Скачать книгу

rel="nofollow" href="#fb3_img_img_ab999629-4ef0-551b-b37c-4fceb193c908.png" alt="image"/>

      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 with the 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

Скачать книгу