I see the GIS_Data as the master table. This is where ALL parcel ids live. Some are duplicate IDs, but the records are not duplicates. True, some more normalization could happen with this data, but we get the data from GIS systems from Counties here in Washington State and the data comes as is. It comes in as Excel spreadsheets and then we import it to the GIS_Data table. Because the way the County GIS systems calculate acreage and other things I don’t really understand, we get these records with duplicate parcel IDs. Deleting the records would cause an alarm with auditors.

All Parcel IDs from the Counties are all valid and we must use them to identify parcels. The application allows users to add attributes to parcel records based upon the parcel ID. Basically, the Field_Data table and several other tables hold these attributes that we enter into the application. When a user adds attributes to a record in the GIS_Data, the attributes are added to the Field_Data table and others tables.

It’s hard me to think the Field_Data table is the parent, when it really could have no records in it and when the GIS_Data table has all of the Parcel IDs.

Do I really need a foreign key? All is happening is when a user adds attributes to main record in GIS_DATA, a new record is added to Field_Data.

I don’t see a need for a strong link between these 2 tables.