10.On the Tables worksheet, add a new field on the bottom named Plat_Status, make its field type SI (short integer), give it an alias of Plat Status, and don’t allow for null values. Because most new property being added to the dataset will be platted, record its default value as 1. Finally, write the name Plat_Subtype for the subtype name, with a notation of (S1).
11.Go to the Subtypes worksheet (page 5). Write the name of the subtype as Plat_Subtype, and add the three codes described previously:
1 = Platted Property
2 = Unplatted Property
3 = Plat Pending
Extend the data model
This work concludes the initial design phase of the Parcels feature class, but there’s another component to investigate. When these polygons are symbolized, they can each have a solid fill and a line style for their perimeter. When maps are made, however, the boundaries of the parcels must be symbolized differently. The edge of the parcel that fronts a street will be drawn with a thicker line; the edges representing property lines between properties will be a thinner line; if someone owns two adjacent pieces of property, the line between them should be dashed.
Consider creating a set of lines that will duplicate the boundaries of each parcel. Then these lines can be symbolized as described. The only field the feature class will need is a code describing which type of line to draw. This field would benefit from having a data integrity rule (a domain) with the three categories of lines described.
A behavior will need to be created between the polygons representing property and the lines representing their boundaries. If the shape of any polygon is modified, the lines will need to automatically adjust to coincide. This type of relationship is called topology and will be discussed in chapter 7. For ArcGIS to manage this topology, the feature classes must reside within the same feature dataset.
Feature datasets are another way to segregate data inside a geodatabase. If any behavior is to be built for a feature class, such as topologies, network databases, geometric networks, relationships, or terrains, the feature class must reside in a feature dataset. For this example, you will establish a feature dataset for your feature classes, so that the corresponding topology can be built.
1.On the Geodatabase worksheet (page 1), write the name of the feature dataset as PropertyData. Next, write the new feature class name LotBoundaries on a blank line. Give it a feature type of LINE and an alias of Lot Boundaries.
2.Next, go to the Tables worksheet, and write the name of the new table as LotBoundaries. Then write the single attribute of this table, Line_Code. Give it a field type of Text, add an alias of Line Code, and do not allow nulls. Add a notation that there is a domain for this field, and name it (D4) Parcel_Line_Codes.
3.Finish by filling in the information for the domain. On the Domains worksheet (page 3), add the name of the domain as Parcel_Line_Codes, a description of Line Codes for Parcels, and a field type of Text, and note the domain type as Coded Values. Then write the three domain values described previously:
•ROW = Edge of Right-of-way
•LOT = Lot Line
•SPLIT = Split Lot Line
Design a relationship class
The features you’ve dealt with in the design so far have been the points, lines, and polygons that will create the model of reality. Not all the data you will need for this model, however, is in the form of points, lines, and polygons. The design will also need to include tabular data that is provided by an outside agency. For each parcel, a county appraisal agency provides ownership and value information. This data would be valuable for analysis if it was associated with the parcel data. The nature of the table is that it is updated regularly from separate appraisal software, so it cannot be incorporated in the polygon feature class in the same way as regular data. By keeping it separate, it will facilitate the maintenance of both ArcGIS use of the data and the third-party software’s use of the data.
A relationship class has many of the benefits of a simple join in a project but also provides a mechanism for controlling edits in the related table. If the graphic features are altered in editing, rules in the relationship class can also alter the related table and maintain the relationship. For this example, the parcels have a match in the appraisal roll table. If a piece of property is removed because of replatting, the associated record in the appraisal table can be set to be deleted automatically.
The final consideration is the cardinality of the relationship. If each parcel has one and only one match in the appraisal table, and vice versa, the cardinality is said to be one to one (1:1). If one parcel can have several matches in the appraisal table, such as the case of a single parcel being owned by more than one person, the cardinality is said to be one to many (1:M). If the opposite relationship was also true—that is, an owner can also own several pieces of property—the relationship is said to be many to many (M:N).
Armed with this information, you can move to the worksheet on relationship classes and fill in the details.
1.Continuing in the same design spreadsheet, on the Relationships worksheet (page 6), write the origin table as Parcels and the destination table as TaxRecords_2019. Name the output relationship class Ownership.
The relationship class can be used to add or delete records, but because the related table will be managed by another source, the relationship type should not allow records to be deleted, making it a simple (peer-to-peer) relationship. Labels will be shown to describe the relationship between the tables. The description for moving from the parcels feature class to the appraisal table is “Parcel is owned by,” and from the appraisal table to the parcels feature class, it is “Owner has ownership of.” As the relationship is used in analysis, these labels will remind the user of the nature of the relationship. Normally, relationship classes are transparent to the user, but you can have your project controls display a message when the relationship is used. For this example, opt not to use them.
2.Circle Simple (peer to peer) as the relationship type, and write the labels Parcel is owned by for Forward Path Label and Owner has ownership of for Backward Path Label. Circle None for Message propagation.
Next, you’ll note the cardinality as many to many, since a parcel can be owned by several people, and one person may own several parcels. It may also be beneficial to store what percentage of ownership can be attributed to each owner. This notation will help when more than one person is recorded as the owner. You’ll write the name of the table as Ownership_Rel, and it will be added to the Tables worksheet later. Finally, you’ll select the fields that will be the basis for the relationship and give them a label describing their relationship to the related table (foreign key name).
3.On your Relationship worksheet, circle M-N for Cardinality, and circle Yes under Attributes. Set the origin table and destination table primary key fields as Georeference. Name the origin table foreign key Owner and the destination table foreign key Property.
This work completes the logical model for the