most common cardinality is one to many. In this case, one row in the origin table points to many rows in the destination table. The foreign key goes in the destination table and points to the origin table. For example, if you use coded values in your geodatabase, you will often provide a domain class that lists the range of valid values and ties each value to its meaning. The table with value meanings is the origin and the table where those values are used is the destination. Many rows in the destination table can have the same value, all of which point to one row in the domain (origin) class.
Figure 2.4 The foreign key can go in either or both tables in a one-to-one relationship. Association is a connection that shows which tables participate in the relationship. Multiplicity expresses the cardinality of the relationship; i.e., the number of rows in each table that may participate in the relationship. The foreign key goes in the “many” end of a one-to-many relationship because that is the end with a single possible value. The foreign key in the destination table stores the primary key of the origin table.
The toughest cardinality to address in database design is many to many. This is because you cannot accommodate such an m:n cardinality by simply using a foreign key. A given row in either related table may need to point to an unknown number of rows in the other table, and a column in a relational database can only have one value.
Figure 2.5 Use an associative table to store the many possible relationships and give each one-to-many relationship its own foreign key. In a geodatabase, an associative table is called an attributed relationship class and can include user-defined columns.
To accommodate a many-to-many association, you have to turn the relationship into a table. Such an associative table will contain the primary keys of both related tables. The result is that each end of a many-to-many relationship can be listed in any number of rows in the associative table, thereby resolving the many-to-many relationship as a pair of one-to-many relationships. You can also store other information about the relationship.
Transportation databases are full of many-to-many relationships. For example, a work program project may affect several roads, and a given road may be affected by several projects over several years. Thus, the relationship between roads and projects is many-to-many. You will need a Road-Project table to store the relationship as a set of one-to-many relationships tying each project to one of the facilities it affected. Each row would have one road identifier and one project identifier. A given road or project identifier may occur in the associative table many times, but never more than once in the same combination.
Figure 2.6 Relationships can be given names that express their role. This example shows a one-to-many relationship, where each row in table 1 relates to a collection of rows in table 2. The caret points in the applicable direction along the association. For example, objects in table 2 are part of objects in table 1.
Association relationships are usually obvious in their meaning, but naming relationships can help eliminate ambiguity. For example, you could say that an address includes a street name and that a street name is part of an address, or that an engine is part of a vehicle that may include many other components. We place relationship names next to the association connector and symbolize them with a caret that indicates the direction for which it applies.
Object-relational databases
The ArcGIS geodatabase is an object-relational design. Object-oriented software encapsulates data and the software that uses the data into an object class. The geodatabase consists of object classes that use a relational database approach to storing data. The kinds of object classes we will discuss are ArcObjects classes, which are the components of ArcGIS.
A class describes a set of data along with the functions that operate on that data. Class encapsulation is absolute. You cannot see inside the object class to view its data structure. You can only communicate with the object through the interfaces it supplies. An interface is a contract between the class and the outside world. Once an interface is declared for a class, it must always be supplied in every subsequent generation of that class and any classes that are based on that class.
Figure 2.7 Object relational The ArcGIS geodatabase is object relational, which allows ArcGIS to evolve its internal class workings without affecting how you view the data. By convention, we treat geodatabase object classes as if they were composed of a single relational table, but they are much more. Appearance versus reality With a geodatabase, ArcGIS only gives you the appearance of a relational database through its class interfaces and wizards. You are not actually seeing the internal data structure. A fundamental principle of object-oriented programming, called “encapsulation,” means that you can never see the internal structure.
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
