✏️
Alaska Region Interim Data Management User Guide
  • Alaska Region Interim Data Management User Guide
  • Background
    • Why Data Managment?
    • The Big Picture: Integrating Data Management with Project Management
    • Definition of Project and Product (aka Data Resources)
  • Four Fundamental Activities of Data Management
    • Establish Roles and Responsibilities
    • Quality Management
    • Security and Preservation
    • Documentation
  • Alaska Data Management 101
    • Workflow
    • File Organization and Best Practices
      • Best Practices in Naming Conventions
      • Best Practices for Version Control
      • Changelog Best Practices
    • Alaska Regional Data Repository
    • Data Management Policy
  • Plan
    • Why Data Planning?
    • Data Management Plan Templates
      • Data Standards in brief
    • Project & Data Management Integration
    • Considerations for Projects with External Partners
  • ACQUIRE
    • Common Data Types
      • Open Formats
      • Best Practices in Tabular Data
      • Best Practices in Databases
      • Best Practices in Geospatial Data
      • Best Practices with Collections of Similar Types of Data
      • Best Practices with Source Data
    • Quality Management Procedures
      • Incorporating Data Standards
      • Using Unique Identifiers
  • MAINTAIN
    • Update Metadata
  • Access & Share
    • Open Data Requirements
      • Obtaining a Digital Object Identifier (DOI)
      • Obtaining a URL
      • Sharing without a URL
  • Long-term Storage Options
    • Using the Regional Data Repository
    • Public Accessible Repositories
  • Records Schedule & Disposition
  • Data Management Actions Quick Guide
  • Glossary
Powered by GitBook
On this page

Was this helpful?

  1. ACQUIRE
  2. Common Data Types

Best Practices in Databases

PreviousBest Practices in Tabular DataNextBest Practices in Geospatial Data

Last updated 5 years ago

Was this helpful?

Databases are essentially a collection of tidy datasets with relationships between the tables specified. Generally, but not exclusively, databases in the Region are developed using MSAccess.

  • Variable names in each table should be described (i.e., a data dictionary is available for each table). When possible, the database should be documented within the database application (e.g. from within MS Access, add title and abstract to database properties and add description for all tables and fields)

  • Enforce constraints on variables to promote Quality Assurance (see section). For example, in a variable named “Gender,” inputs could be constrained to the values of “Female,” “Male,” and “Unknown;" in a variable named “Length_mm,” only integers between 10 and 1000 may be allowable values.

  • If possible, consider converting MSAccess databases to SQLite, an open format that will preserve the database functionality. Utilities are available to assist with this, but may require additional technical assistance. Contact your DST member if you are interested in this conversion.

  • If conversion is not possible, MSAccess tables and their data dictionaries should be exported to a preferred open format (e.g. Text or CSV) and the database structure (relationships diagram in MSAccess) should be saved to a preferred open format (e.g. JPEG or PNG) throughout the duration of the project and at the completion of the project. These files are stored in the same archive folder as the database.

Quality Management