Lower Colorado Region Multi-Species Conservation Program Database Management System

1. Lower Colorado Region Multi-Species Conservation Program Database Management System

2. Database Management System’sMission Develop an accessible, multi-disciplinary, spatially referenced, relational database to consolidate, organize, document, store and distribute scientific information related to the Lower Colorado River Multi-Species Conservation Program (LCR MSCP), in a cost efficient, effective and transparent manner.

3. Data Management System • File system application architecture to store and retrieve archived deliverables based on keywords i.e. a repository for original electronic copies of data and report documents. • A RDBMS to consolidate and warehouse both tabular and spatial data in a central location accessible to all LCR MSCP staff with the proper permissions. • A spatial data engine (ArcSDE), for storage and manipulation of regional GIS data sets within the RDBMS.

4. Why Do This? To support scientific monitoring, research and recovery activities related to the LCR ecosystem. To facilitate the adaptive management of the LCR by establishing a foundation for a decision support system, based on scientific information about the ecosystem. To improve the level of quality assurance and provide strong incentives to standardize and coordinate data collection.

5. Scoping Meeting Scoping Meetings held December 2005. Met with members of the LCR MSCP Administration, LCR MSCP Steering Committee, and LCR MSCP scientific staff groups Reviewed databases Analyzed the data and reporting needs Provided recommendations for the development of an interdisciplinary Data Management System (DMS). Formulated options for DMS.

6. Database Management SystemRequirements Analysis Identify, catalogue, prioritize all possible data sets Create database and file data structure Evaluate and review existing data management system for model Develop and maintain physical and electronic data storage and retrieval Create distribution technologies for access by internal and external users Document database structure and maintenance. Develop a sound information base for decision making in the adaptive management process.

7. Functional Requirements • Data Set Consolidation and Sharing • Methodology Standardization • Analyzed for common entities and attributes • Data Set Accessibility • Web services to published to broad and diverse groups of users, each with their own specific data requirements and permissions. • Data Set Download Capability • Data Capture Applications • electronic data collection in the field • Data Maintenance / Data Administration Applications

8. Example of Web-Application Module and Database Module Architecture

9. Option 1 – Sole Solutions Integration Comprehensive, integrated, end-to-end database that provides a secure, reliable, and productive platform for making data more manageable. Relational database system that houses all data in one database, to include all scientific data, financial, meeting management, etc. Modeled after Southern Nevada Water Authority database system.

10. Option 1 Benefits All data would be stored in one large relational database, making it efficient to consolidate, retrieve, and analyze large data sets across disciplines over a 50-year period. Maximizes the availability of information/data to managers, Steering Committee, scientific staff, and general public at different security levels by providing web interface. Application programs would be created to allow the database to be searchable in multiple ways using user friendly query tools.

11. Option 2 - Selected Technical Modular Development System would be built on a module-by module basis, with development priorities based on need, functionality, and cost, with scientific data requirements receiving top priority. Pay-as-you-go approach to database development.

12. Option 2Benefits Modular approach allows for prioritization of need. Each separate module would be ready to use after development. Similar to Option 1, but analysis across disciplines would be limited until modules are on-line.

13. Option 3 - Basic Systems Utilization Utilization of current software and applications with no centralization of data into one database. Data would be housed on a shared drive. Data management would be controlled through a data manager and through the use of set standards and protocols for data input, storage, and retrieval.

14. Option 3 Benefits Lower costs and fewer FTE’s. Consolidation of data set in same or similar formats onto one shared drive, but maintain individual files. Users are already familiar with current software and systems.

15. Option 4 - Outsourced System Development Data management system would be completed by a large-scale contract with a consulting firm to fully develop the system and populate the database. Application design, development, coding implementation, and maintenance would all be contracted.

16. Option 4 Benefits Database system can be running within three years of contract award. Places the responsibility for successful project completion on an outside database development consulting firm. No additional FTE positions during development phase.

17. Southern Nevada Water Authority’s Data Structure Potentially, the SNWA database could be exported and used to generate an exact structural duplicate that would satisfy perhaps 50%-70% of the needs of LCR MSCP “out of the box”, without any modification. Individual LCR MSCP data sets would need to be imported into the structure, but this approach would essentially jump-start the system development process, providing LCR MSCP with a functional database and applications in the least amount of time.

18. Southern Nevada Water Authority’s Database system