rules, establish domains, and create relationships. You need not be concerned with how ArcGIS internally handles these parts of the geodatabase. However, because of the encapsulation of software and data within the geodatabase object-relational structure, you can only exchange data by sending the entire geodatabase to another user. You cannot just select one feature class and copy it. The behavior of that class depends on the contents of several other classes. A feature or object class functions only within the context of the geodatabase.
Just as software contained in an object class may be known by many names, attributes are also called by many names: columns, properties, and fields. There are more names for each discrete “thing” contained in a class: object, member, instance, row, and record. In general, ESRI restricts the use of object class to mean a type of table that stores nonspatial objects. This definition does not mean that the thing the object represents is nonspatial. A dam on a navigable waterway is certainly a spatial entity. If you choose to include it in a geodatabase using an object class, you are only making the decision that this particular abstract representation does not include geometry.
In ArcGIS, an object that includes a shape attribute (geometry) is called a feature; i.e., it is a geometry object. In practical terms, a feature class adds the additional software and data structures needed to store and retrieve geometry to the software supplied by the object class. More specifically, a feature class is a table with a geometry column stored as binary long object (BLOB) pages in a relational database. A feature class contains geometric elements (simple features) or network elements (topological features) in a coverage, shapefile, or geodatabase structure. ArcGIS displays it to you as a table with a SHAPE column, but there is a lot more going on behind the scene.3
Relationships in object-relational databases
Our earlier discussion of relational databases introduced association relationships. Object-relational data models will explicitly display their multiplicity. Frequently encountered examples include “0..1” to mean zero or one may exist; “1” or no notation to show that one must exist (a default value); “*” to mean more than one must exist; “0..*” to represent zero, one, or more instances may exist; and “1..*” to mean at least one must exist, although more may be included. Association is represented in our models as a medium-width gray line and may carry role names.
The next most common and important relationship in an object-relational database is inheritance, which is a parent-child relationship. Inheritance is shown in a data model using a thin solid-black line with a generalization arrow pointing to the parent class. (You can think of the arrow as pointing in the direction to look for additional attributes.) The end symbol is called generalization because it shows the parent class to be a more general form of the child class, or, conversely, the child class is a specialization of the parent.
In addition to showing a parental relationship, inheritance simplifies logical data models by allowing you to omit repeating the parent class’s attributes in the child class. In our data models, the child class will include only attributes that have been redefined or added to the parent’s. Parent classes are often called stereotypes. Many stereotypes are abstract, which means that their purpose is solely to serve as a class template; objects of an abstract stereotype class cannot be created. An abstract class’s name will be shown in italics. A class that can produce objects conforming to the class specification is said to be instantiable.
The other primary relationships you will see in data models are dependency, composition, and aggregation. A dependency relationship, also called navigability, shows which classes depend on other classes for their existence. Another way to define this relationship is to say that one class instantiates the other, meaning a function of one class creates objects of the other class. Dependency is shown using a dashed black line with an arrow pointing to the dependent class. None of the data models presented in this book will include dependency relationships, although they do frequently appear in ArcGIS documentation of the geodatabase and you may need them in your own data models.
Figure 2.8 Relationship types Data models at all levels of abstraction include relationships. This minitutorial explains the five primary types that you see in ArcGIS: association, type inheritance, instantiation, aggregation, and composition. All relationships are illustrated using a line and endpoint symbols.
Composition and aggregation are similar to each other with one important difference. A composition relationship is created when one class is composed of one or more instances of other classes. For example, a building may be seen as being composed of at least three walls, one floor, and one roof. Remove the building and its components cease to exist, at least as far as the database is concerned. Thus, a composition relationship tells you that when the sum of the parts is deleted from the database, you will also need to delete the objects of which it is composed. A thin black line with a solid-black diamond at the end adjacent to the composite class represents this kind of relationship.
Aggregation is not so particular. An aggregation relationship specifies that a class is a collection of other classes. For example, a baseball team may be a collection of players. If you express this relationship through aggregation, then you are saying the players will continue to exist in the database even when they do not belong to a team. If you instead use composition, then the players must be deleted from the database when the team is dissolved. Aggregation symbology is similar to that for composition, except that the diamond is outlined in black and white filled.
The data-modeling process
You need a good data model to produce a good geodatabase design. Developing a geodatabase design is a six-step process that follows the flow of the agile methods discussed in chapter 1:
Step 1—Define user requirements. First, you need to know the purpose of the data, the application requirements to be supported. Many users attempt to develop a complete set of requirements as the first step, but that cannot be done. Even for a small project, the agile method instead encourages you to create a good first effort that has the primary objective of identifying the major components. For an enterprise geodatabase that will support a wide variety of existing and yet-to-be-created applications, seeking a complete set of requirements as the first step is an impossible goal. No, your task here is to identify the general requirements.
Step 2—Develop conceptual data model. Once you have specified the general requirements for the final product, you will need to identify the basic elements of a geodatabase that meets the requirements. Such elements consist of entities and their relationships. An entity may eventually be reflected in a class, but at this point in the process, you cannot establish a one-to-one equivalency between entities and classes.
Step 3—Develop a logical data model. Once the general structure of the database—the skeleton—is established, the next step is to add some meat to the bones by specifying attributes for the geodatabase. Entities may change at this point, as attributes are assigned and new relationships discovered. The logical model is independent of the planned implementation platform.
Step 4—Develop a physical data model. Here is where entities become classes and the implementation platform makes a difference. Your RDBMS, network structure, and organizational behaviors will influence the way you translate the logical design into a physical implementation. The added benefits of the geodatabase and ArcGIS will become apparent at this stage. The
