The Hydrologic Database (HDB) is the foundation for the United States Bureau of Reclamation's (USBR) Database of Record. As conceptualized by the Database of Record defining document, the driving vision for the Hydrologic Database is:

• to consolidate data existing in various systems and personal spreadsheets.  
• to assure complete and consistent data collection and storage; documentation of data sources.  
• to provide historical information on other existing HDB data versions including information on when the data was either used or available for use.  
• as a means of quality control.
• to allow the user access, at any time interval, to the original source data for calculated or summarized data
• to provide for an automated generation of time-aggregated summary data.

Current Suite of HDB Applications developed by CADSWES utilizing the HDB Oracle database include:

• Derivation Application: The Derivation Application's purpose is to allow an automated derivation method (such as average or maximum value) to be applied to external sources of HDB data in order to derive the data for longer time intervals; including hour, day, month, year, and water year. Use of this application can assure that all of the data in the time series tables of HDB is kept up to date and internally consistent, resulting in an accurate data repository across all time intervals.
• Meta Data Application: This is an Oracle Forms application designed to make the viewing and maintenance of all HDB Meta Data more simple and efficient.
• Water Accounting: This application provides the HDB data structures necessary to accommodate data specific to Water Accounting and uses a Data Management Interface (DMI) to import data from a Water Accounting RiverWare model into HDB.
• Hydromet data loaders: Hydromet is a satellite and radio telemetry data collection system developed for and used by the USBR. There are two java based HDB data loader programs: one that reads data from the Hydromet dayfile and a second program that reads the Hydromet archive file; both programs process the respective data and place it into HDB. Additionally, a real time data loader program reads data sent to a specific server socket, bypassing the Hydromet dayfile and processes this data directly into HDB.

• Timeseries Data. Most of the information stored at the various HDB implementations consists of timeseries data describing the observed and forecasted behavior of a variety of water resources within the Bureau's domain of operations. Forecasted and observed data are kept in separate sets of relational tables.
  
• Physical Data. To maximize the efficiency of the relational model, HDB contains a large number of so-called "referential" tables. These tables serve to maintain relationships between certain entities in the database (reservoirs, users, models, HDB implementations) and their various attributes.
  
• Meta Data. Although the various implementations of HDB comprise independent, stand-alone versions, the organizational structure of the Bureau's operations requires that databases remain "in sync" with each other with respect to a number of different phenomena. For instance, the results of model runs conducted at one office may be needed for subsequent modeling at another office. As a consequence, certain sets of "meta" information (data about other data in the database) must be kept synchronized across the various HDB implementations.

• Structured and automated storage of operational and planning data.
• Automated report generation of standard operational reports.
• Initialization of models and storage of modeling results.
• Coordination of modeling between USBR Regional Offices.

An HDB Usage Scenario

Once a month, the Upper and Lower Colorado Regional Offices of the United States Bureau of Reclamation jointly produce a forecast of releases from the major Colorado River Reservoirs. This forecast is based on a monthly timestep RiverWare simulation model and comprises a 24-month look-ahead. The forecasting process described below is repeated monthly in order to incorporate changing flow conditions.

Since the Upper and Lower Colorado Basins are legally distinct entities, each is responsible for their own forecast. However, since the two forecasts strongly impact each other, the Upper and Lower Colorado Regional Offices cooperate closely in their join effort to product a combined 24-month Colorado River forecast.

The process starts with the Upper Colorado Regional Office HDB installation receiving a preliminary inflow forecast from the National Weather Service (NWS). This preliminary inflow forecast is recieved by the Upper Colorado RiverWare 24-month simulation model and used as new inflow data for the RiverWare monthly simulation run.

Once the Upper Colorado Regional Office completes the simulation run, the new RiverWare model data (forecast) is stored in the Upper Colorado HDB. This data is stored for Upper Colorado's own subsequent use as well as for retrieval by the Lower Colorado Regional Office as input for their forecast.

The Lower Colorado RiverWare 24-month forecast model then download the Upper Basin's forecasts, and updates their RiverWare model by running a simulation with the new data from the Upper Basin. The outcome, a new RiverWare 24-month model, is stored in Lower Colorado's Regional HDB.

Now with Lower Basin results at the Lower Colorado HDB, and Upper Basin results at Upper Colorado HDB, a complete forecast can be made available.

Upper Colorado retrieves Lower Colorado's results and runs the model one more time, using results from both Upper and Lower Colorado previous run. If all is well and no more changes are necessary, the run is stored by both Upper and Lower HDB offices as the official forecast.

The figure below illustrates the exchange of 24-month study information by means of an information space-time flow diagram. The grey bands running from left to right (in time) represent the Upper and Lower Colorado implementations of the HDB database (UCHDB and LCHDB) and the 24-modeling activities at those agencies (UC-24MS and LC-24MC). Note how information is retrieved from and stored in the various databases and how it flows between the databases and the modeling activities.

Of course, the above process can become more complex. If the preliminary NWS forecast data initiating this process differs from the final NWS forecast (e.g., weather conditions have suddenly changed), a new modeling round is necessary.