Laserfiche WebLink
To help maintain consistency with the State's Hydrobase design and to make migration to the design <br />easier, the consultant was asked to include all the State's data found in the original dBase files directly <br />associated with the data included in the CRDSS database. <br />As the Year 2 project proceeded, a memorandum was written (to Ross Bethel and Will Burt from Doug <br />Greer and Larry Brazil, March 29, 1996) describing differences in the designs at the entity level for both <br />Hydrobase and the CRDSS database. The design used in the Phase 2b project is essentially the design <br />delivered to the State at the end of Phase 2a with minor changes. <br />The data types listed in Table 1 below were loaded into the database. The schedule of the data <br />population for all the database tasks was driven by the need to keep the water resources planning model <br />task and consumptive use task on schedule as much as possible. The first data populated from the State's <br />dBase files was the structures information to support the population of the diversion records and water <br />rights. As construction and population of the Phase 2 database continued, a number of data issues were <br />encountered that delayed the database tasks. Those are discussed later. <br />The primary database activities in Phase 2 involved completing the database design, populating the <br />database, and constructing database displays. Only minor data collection was done. New data included <br />some reservoir end of month contents records as specified by the water resources planning group and the <br />snow course records. The rest of the new data in the historical database came from the State in machine- <br />readable form. The State was responsible for a quality assurance task, and the consultant assumed that <br />the State's data were correct as received. However, the consultant did perform quality assurance checks <br />during the loading process. If any data issues were discovered, these issues were returned to the State for <br />resolution. <br />The database was populated according to the procedures outlined in Section 2.2.3 of the CRDSS <br />Developers? Manual. The procedures briefly consist of receiving the dBase files that have been checked <br />by the State. The consultant then parses the data in these files to the correct format to prepare them for <br />loading into the database. The data are then loaded into a temporary database table prior to being loaded <br />into the database to make sure that the data meet the constraints of the database and to allow <br />manipulation through use of the database system utility programs. Only once the data are checked and <br />accounted for are they loaded into the permanent tables. <br />A number of quality assurance checks are performed before any data becomes part of the CRDSS <br />database. These checks are as follows: <br />? <br />As related tables are populated, the integrity of the relationships among tables is checked. It is <br />important to ensure that the data are associated with correct values used as keys in related tables. <br /> <br />? <br />Tables with fields used as keys are checked for null and duplicate records so that searches and sorts <br />done on these fields will yield efficient and unambiguous results. <br /> <br />? <br />The results of table loading are checked for errors and for records that did not load so problems can <br />be resolved. <br /> <br />? <br />Once the data are loaded into the final tables, the data are spot-checked against the original source of <br />the data to ensure that the values are correct and are associated with the correct identifiers. Note that <br />one objective of the database population activities is to make sure that the data are traceable to the <br />original source. <br />2 <br />a320/taskmems/ 2-05-01.doc 01/03/97 <br />