Laserfiche WebLink
Refreshing the Database <br />To successfully refresh the database, the following conditions must be met: <br />-Each database table that is eligible to be refreshed must have certain properties defined in <br />advance of the refresh process: <br />Refresh frequency (every year, every 2 years, never, etc.) - State personnel will be <br />? <br />consulted to obtain the correct refresh values for DWR data. <br /> <br />Source of refresh data and the transport mechanism to make that data available (ftp, <br />? <br />tape, etc.). The source of each data type is available in the database and in the CRDSS <br />Users? Manual (database section). <br /> <br />Potential porting problems once the incoming data has been obtained from an external <br />? <br />source. <br /> <br />Additional costs involved in obtaining non-State information (USGS records). <br />? <br />-Each database table that is eligible for updating should be unloaded to a disk file prior to any <br />update process. For long-term storage, the unloaded disk file should then be stored on tape in a <br />compressed format. In the event that new data are used to update a production table and are <br />later found to be in error, the table can be restored to its pre-update status by using the data <br />stored on the tape. <br />-Each database table that is eligible to be refreshed may have two distinct input data sets <br />associated with it. The primary ?refresh? data set will contain all of the data that are to be <br />merged into the permanent production database. The secondary ?verify? data set will contain <br />the records that are to replace existing historical data currently present in the production <br />database. The presence of the ?verify? data set is probably applicable only for State supplied <br />data, since historical data from other sources will rarely change. However, it is recommended <br />that historical data from non-State sources be spot checked. Changes made to the refresh data <br />set will be documented in a report and supplied to the original data owner. <br />-Each data item in a given incoming data set must meet any and all data constraints defined for <br />the destination table. This requirement assures that the new data meets the same integrity <br />standards as the data currently in the database. Constraints defined in the database can be found <br />in the schema and in the data dictionary. Some examples of data constraints are given below: <br />In the cropchar table, the value for cropname must match a value from a list of 39 valid <br />? <br />crop names. <br /> <br />In the cu_indust table, the value for unit must be either ac/ft or ha/m. <br />? <br /> <br />In the daily_flow table, the value for each of the observation type fields (obs1...obs31) <br />? <br />must be either F (filled) or O (observed). <br />-Each incoming data set will be loaded into a temporary database table that mirrors or closely <br />resembles the destination table. Once the data is contained within the database, then all <br />3 <br />a320/taskmems/ 2-13-01.doc 01/03/97 <br />