Temporal data in separate tables

In many cases, temporal data is stored in different tables for better data management and to avoid data redundancy. This is particularly useful for data that doesn't change geographically over time. For instance, the stream flow data collected over time can be stored in different tables, one containing the geographic location of the stream gauges and the other containing the discharge values for the gauges over time.

To visualize such data, you can create a one-to-one, many-to-one, or one-to-many join using the Add Join geoprocessing tool.

One-to-many table relationships

When storing temporal data for features that do not change geographically over time, such as static sensors collecting data over time, it is recommended that you store the data in two separate tables. In such cases, you can store the geographic location of the features in one table and the data associated with each feature in the other table. In the example below, the geographic locations of the gauging stations are stored in one table and the corresponding temperature values collected at different times for the gauging stations have been stored in another table. Both tables, however, have the StationID field that can be used to create a one-to-many join between the Stations feature class table and the Temperature table. Time can then be enabled on the layer using the newly joined time field. In this example, you would choose the Temperature.Date1 field.

One-to-many table relationship
Stations feature class
One-to-many table relationship
Temperature table

Related topics