Data Dictionary

Definition

Data Dictionary

the design work product that officially documents the data of an application, database, or enterprise

Objectives

The typical objectives of a data dictionary are to:

• Formally specify all data.

Benefits

The typical benefits of a data dictionary are to:

• TBD

Contents

The typical contents of a data dictionary are:

• For each datatype:
  • Name
  • Description
  • Keywords
  • Format
  • Source
• Appendices:
  • Major Issues
  • TBDs
  • Assumptions

Stakeholders

The typical stakeholders of a data dictionary are:

• Producer:
  • Database Team
• Evaluators:
  • Database Inspection Team
• Approvers:
  • Technical Leader
  • Project Manager
  • Customer Representative
• Maintainers:
  • Database Team
• Users:
  • The Project Management Team uses the DBDD to manage project scope and estimate project costs.
  • The Environments Team uses the DBDD to what databases to acquire and to include in the project environments.
  • The Software Development Team uses the DBDD to drive the design of the software involving persistent data.
  • The Integration Team uses the DBDD to help integrate the builds involving persistent data and to generate integration test cases.
  • The Security Team uses the DBDD to determine the security implications of the persistent data (e.g., access control, data integrity).
  • The Customer Organization uses the DBDD to understand the scope and structure of the database they will use and maintain.

Phases

A data dictionary is typically developed during the following phases:

• Business Strategy: Not Applicable
• Business Optimization: Not Applicable
• Initiation: Not Applicable
• Construction: Completed
• Delivery: Maintained
• Usage: Maintained
• Retirement: Archived

Preconditions

A data dictionary can typically be started if the following preconditions hold:

• The Inception Phase is started.
• The database team is staffed.
• Requirements regarding persistent data are documented in the system requirements specification.
• Relevant sections of the architecture documents are started.
• The associated conventions (e.g., content and format standard, template) are ready.

Inputs

The typical inputs to a data dictionary include:

• Work Products:
  • System Requirments Specification
  • Domain Model Document
  • Glossary
  • System Architecture Document
  • Software Architecture Document
• Stakeholders:
  • TBD

Guidelines

• This is a living document that is developed incrementally and iteratively in parallel with other work products.
• Different parts of this document are due at different times (i.e., during different phases).
• Some parts of this document are mandatory and some parts are optional.
• Anything that holds data used for or within the application that needs to be persisted should be documented including flat files, registry entries, and others.
• During the Construction Phase, this document will typically require iteration as new information and/or software and hardware changes occur.
• The data dictionary and the architecture documents will typically be iterated in parallel because database requirements affect the architecture and the architecture impacts operational and quality capabilities of the database.
• The data dictionary should reference the relevant documentation of any COTS database or package including a database for the detailed documentation on the installed DB structures. Furthermore, the data dictionary should document, in a detailed manner, any changes made to those structures to support the operational or quality requirements of the application.
• Where changes are made to data structures of a COTS database, it is mandatory that these changes be documented in the data dictionary.
• The maintenance, backup, and disaster recovery sections of the data dictionary are not completely necessary in IT environments where the client has a formal database management competency and will take on full responsibility for the management of the database using management tools already in place. In such a case, it should be generally documented that the client has these tools already in their environment and will utilize them in the operational management of the database according to their own guidelines.
• A separate data dictionary is not required for each persistent data store. However, DDDs may be desirable in some very large implementations where the ongoing maintenance of the database will be handled by more than one functional IT group.

Conventions

A data dictionary is typically constrained by the following conventions:

• Work Flow
• Content and Format Standard
• MS Word Template
• XML Template
• Inspection Checklist

Examples

• Example Data Dictionary