LITMIR.BIZ

       Class interfaces provide a reliable way for software to be developed and used by different programmers. Each interface has a name. By convention, interfaces’ names start with a capital I with the subsequent letter also capitalized. For example, ITable, IClass, and ITableCapabilities are the three interfaces added by the Table class that is part of ArcGIS. Most interfaces build on others. The parental relationship would be expressed as child : parent, as in “IObjectClass : IClass,” which means that the IObjectClass interface offers additional functions for the IClass interface.

       Object classes communicate with each other through messages conveyed between interfaces. You also communicate with an object class by sending, through an interface, arguments containing input data and work assignments to the class. The interface returns a result after the class’s software—called variously by the names of methods, behaviors, procedures, or operations—does its thing. ArcObjects programming involves the use of class interfaces. You cannot actually change the class itself because it is not possible to see inside the class due to encapsulation. As a result, ArcObjects documentation discusses only the interfaces and how to use them.

       All the software you need to manage a geodatabase is not contained in one object or feature class but in dozens of ArcObjects classes that work together to provide the performance you need in a GIS platform. Drawing-layer symbology, attribute domains, relationships, and rules are also contained in separate ArcObjects classes and are just as much a part of the geodatabase as the object classes and feature classes you create. Data models do not generally include all the things you can specify for a geodatabase in ArcGIS. They are normally restricted to tables, feature classes, relationship classes, and domain classes. Things like how a feature class is displayed as a map layer are usually omitted.

       To use any of the data models shown in this book, all you need to do is add fields to a class. No programming is required. You also do not need to know about or have experience with ArcObjects. In fact, this is the only place in this book where interfaces are discussed. The intent is to make you aware that a lot of things are going on when you use a geodatabase and to help you understand what you might see in ArcGIS documentation.

       Unless you plan to do some ArcObjects computer programming, all you need to know to design a geodatabase is that you will define object and feature classes using a class template supplied by ArcGIS and add attributes, define 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.³

       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.

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