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 geodatabase. From these design forms, you will be able to create the entire structure and begin using it for storing data. If you do not have a lot of experience editing geodatabases, you may want to jump ahead to tutorial 2-1 and see how this design will function, and then come back to this exercise. Otherwise, complete this exercise, which will continue to focus on the design phase.
Exercise 1-1
The tutorial showed how to diagram a geodatabase to include feature classes along with their associated tables, domains, and subtypes. The goal was to think through the design, adding data integrity and behavior guidelines to the database.
In this exercise, you will repeat the process for another dataset required by the city planner. This one will contain the zoning data for Oleander. The zoning code for a piece of property determines the type of development that is allowed on a parcel (even though the land use may be different). The zoning districts may incorporate several parcels and generally follow parcel boundaries, but they can split parcels, too.
The zoning districts will be represented by solid shaded polygons, so you will want to design a polygon feature class for districts. The edges of the polygons should be symbolized in one of two ways—either as a solid line representing a zoning boundary or a dashed line representing a change in allowable development density. Because of this scenario, you will want to design an additional linear feature class for symbology purposes. The codes necessary for the zoning information are as follows:
R-1Single Family Residential
R-1ASingle Family Attached
R-1LSingle Family Limited
R-2Duplex
R-3Triplex
R-4Quadruplex
R-5Multifamily
C-1Light Commercial
C-2Heavy Commercial
THTownhomes
LILimited Industrial
I-1Light Industrial
I-2Heavy Industrial
TX-121121 Development District
POSPublic Open Space
Analyze the descriptions of this data and determine what feature datasets and feature classes must be made, what fields they should contain, any domains that might need to be created (and possibly contingent domains), and any subtypes that might be beneficial.
•Print a set of the geodatabase design forms as necessary.
•Use the forms to create the logical model for feature classes for the zoning polygons and zoning boundaries.
•Investigate the use of domains and subtypes to build data integrity and behavior into your design.
WHAT TO TURN IN
If you are working in a classroom setting with an instructor, you may be required to submit the design forms you created in tutorial 1-1.
•The completed geodatabase worksheets for:
