Laserfiche WebLink
subsequent verification procedures will employ the query and analysis power of the database <br />engine. <br />-Each data record in the incoming data sets will be analyzed and verified before being applied to <br />the production database. Examples of the verification process follow: <br />Each incoming diversion record: <br />Must contain a valid set of key values (struct_num, geoloc_num, div, wd, id) that <br />? <br />associate with an existing structure <br /> <br />Must contain valid values for year and month such that <br />? <br />-the row matches an existing row in the database (a ?change? row) <br /> <br />-the row is for the expected update year only (a ?new? row) <br />-the row fills a gap in the historical range of values (a ?new? row) <br />-The deletion of existing production data should be approached with caution. While simple in <br />concept, removing data from the production database can have far-reaching, and possibly <br />catastrophic, implications on the remaining data in the database. It is suggested that if the need <br />arises, rows be deleted logically using status codes and timestamps versus physically removing <br />the rows from the database. A logical delete establishes an audit trail of past data <br />configurations. A physical delete removes any trace of data that are not currently present in the <br />database. If necessary, new columns should be added to the targeted tables to track any agreed <br />upon deletion criteria (e.g., timestamps for date added, last modified, deleted). <br />Rows in other tables in the database that have relational dependencies upon a row to be deleted <br />should be analyzed before the delete is carried out. If a physical delete occurs, foreign keys <br />will point to non-existent instances of the dependent-upon entity, which can corrupt the <br />database and damage applications that depend on intact data relationships. The CRDSS ERD <br />will help identify the dependent relationships within the database. <br />Any rows of a particular table that are eligible for deletion could be isolated in a separate <br />?delete? data set that would accompany the ?refresh? data set, and optionally, the ?verify? data <br />set (for changes). <br />These data sets would get loaded into temporary database tables and would match existing rows <br />in the corresponding production table. <br />-If data issues arise, the record(s) in question will be unloaded from the temporary database table <br />in question to a separate data file for review by the State?s management team prior to inclusion <br />in the production database. <br />-The record count of each incoming data set will be checked against the sum of records in each <br />of the partitioned output subsets. Input count must match output count. <br />There are five general categories of CRDSS data that are eligible to be refreshed: <br />Water rights (recommended refresh every 2 years) <br />? <br /> <br />4 <br />a320/taskmems/ 2-13-01.doc 01/03/97 <br />