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, you can store the stream flow data collected over time 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.
When visualization is not required and where a one-to-many or many-to-many relationship exists, you should instead use a relate or relationship class to establish the relationship between the datasets using the Add Relate 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 are stored in another table. Both tables, however, have the StationID field that you can use to create a one-to-many join between the Stations feature class table and the Temperature table. You can then enable time on the layer using the newly joined time field. In this example, you would choose the Temperature.Date1 field.
The joined table essentially duplicates the station point rows to match with the many temperature observations into a single large table that can then be filtered by row using the time slider.