between those same classes. Third, relationship classes established between members of a geometric network can produce unexpected results during editing because both the relationship class and the requirements of a geometric network are trying to control referential integrity.
Recursive relationships where members of a class have relationships with each other are not currently supported by ArcGIS. Neither are complex primary and foreign keys. You can only use one field to define a primary or foreign key for a relationship. Custom software can be written to use complex keys. Lastly, if you put a relationship class within a feature dataset, at least one member of the relationship must be in the feature dataset.
By the way, you can have more than one simple relationship between the same two classes. This technique can be used to enforce cardinalities that differ depending on the situation. For example, the multiplicity for a node to the various links it may terminate is one to many with a minimum value of 1, but the multiplicity of a link to its terminal nodes is always 2.
Origin and destination tables
We have used the terms origin and destination to refer to the two classes participating in a relationship. It is very important that you know which is which, because it is easy to get it backward. You could lose data as a result of an identification error.
Figure 3.14 Origin and destination tables It may seem logical to treat the more important class as the origin, but that is usually the wrong thing to do. In this example, we seek to establish a relationship between a street class and a street name class. We have separated the names from the streets because we have a mixed-jurisdiction database that has several duplicated street names—sometimes with overlapping address ranges. The Street table is a valid combination of street name, address range, and community name. The address range and community name are stored directly in the Street table, but the street names are in a separate table. We need to create a relationship class to manage the one-to-many relationship between the Street and StreetName tables. Here are two approaches, one wrong, the other right.
In a one-to-many relationship, you will normally want the origin to be at the “one” end of the relationship. The top part of figure 3.14 shows a StreetHasName relationship between a Street table and a StreetName table. While it is certainly true that a street has a street name, this relationship is backward. The result of deleting a row in the Street (origin) table will be that the value of StreetNameID is set to null in the StreetName (destination) table. Suddenly, all Street table rows that pointed to that row no longer have a legitimate foreign key and the name disappears from all the streets that used it.
The lower part of figure 3.14 shows the right way to characterize this relationship as StreetNameIsAssignedToStreet. Now, if you delete a row in the Street able, nothing at all happens in the StreetName table. Of course, if you delete a row in the StreetName table, all the rows in the Street table that pointed to that street name no longer have a legitimate foreign key, but that is what needs to happen.
Other geodatabase classes for transportation data models
There are other geodatabase classes with specialized applications that will be discussed in later chapters. These classes include:
• Junction feature classes and edge feature classes that form a geometric network
• Turn feature classes that allow you to modify the default behavior of a transportation network
Because an understanding of these classes is necessary to use them in a data model, they are omitted from this “sidebar” chapter. Geometric networks are discussed in chapter 5. Transportation networks supported by the ArcGIS Network Analyst extension are covered in chapter 13.
Normalization
The last topic in this chapter is perhaps the toughest of all. Geodatabases that support data maintenance benefit from normalization, which is the process of removing data redundancies and dependencies. A database with data redundancies and dependencies is denormalized. You have already seen examples of normalization, such as the conversion of a many-to-many relationship to a pair of one-to-many relationships. The use of foreign keys is also part of normalization. This section will describe the breadth of normalization and why it is important.
Each table included in a geodatabase has a primary key, OBJECTID, which is used to uniquely identify each row by unambiguously identifying each member of the class. You cannot rely on record numbers as with sequential flat files or the row numbers that appear in spreadsheets because there is no ordering of rows in a relational database. Typically, each new or modified row is added to the end of the table. No two rows can have the same primary key value. Primary keys can be simple (one field) or complex (multiple fields), but the result must always be unique; no other row can have the same value. You do not want to use a manually entered attribute as a primary key. People can make mistakes and enter the same primary key value twice. You will want to use the computer to create the values in your primary key through such RDBMS functions as integer counters and date/time functions.
In addition to a primary key, a relational table can include one or more foreign keys. A foreign key in one table points to a related record in another table. It does this by having the same values in both tables. Say, for example, that you have a roadway inventory that includes a functional classification column. Rather than store the full name for each functional class, you will likely store the two-digit coded value in the inventory table, and put the coded values and their meanings in a functional class domain. Functional class is a foreign key. There will be lots of road segments with any given functional class, but each segment record must contain only one. Therefore, this is a one-to-many relationship: one functional class to many roads.
By the way, a foreign key is always a candidate primary key. This means that you do not have to pick the real primary key to enforce the relationship, just a column that could serve as the primary key. (The primary key must be unique. You cannot take any chances there.) Using functional class as an example, the coded value assigned to each class is unique to each record, which makes it a candidate primary key. You could store either the actual primary key or the coded value in the roadway inventory table. You will usually choose to store the coded value, as it provides information to the knowledgeable user without having to go to the functional class domain to see what it means.
Most spatial databases are normalized to the extent that they store information about discrete features, such as a parcel, a house, or a lake. Transportation data modelers are not so lucky. Linear transportation facilities are not really discrete. Agencies impose various segmentation methods to make linear facilities discrete, but in the process create denormalized data structures, such as when a street is subdivided into block-length segments. Denormalized data structures are fine, almost required, for mapping, but they are very difficult to maintain if you are trying to store a lot of data. The problem is data redundancy and the resulting need to change the same piece of data in several places. If the entire street has an asphalt surface, then you will need to repeat that information for each segment.
Data dependencies and redundancies are inefficient, but data redundancies can be downright dangerous, as they
