Database Design Document (DBDD)

Definition

Database Design Document (DBDD)

the design work product that officially documents the design of the databases that will be part of an application

Objectives

The typical objectives of a database design document are to:

• Formally document the logical and physical design of all application databases.

Benefits

The typical benefits of a database design document are to:

• Ensure that persistent data is correctly and efficiently stored.
• Clearly identify the documents, objects, or data that are persistent.
• Make it easier to install, configure, and maintain the databases.
• Make it easier for developers to integrate their executable software with the databases.
• Provide a consistency check on the domain object model document.

Contents

The typical contents of a database design document are:

• Database Overview (number, purpose, and kinds of databases)
• For each individual database:
  • Name
  • Objectives in terms of contents and usage
  • Kind (e.g., XML, object, relational, network, hierarchical, or flat file)
  • Vendor (e.g., Oracle, DB2, Versant)
  • Deployment (e.g., database server)
  • Characteristics:
    • Legacy or newly developed
    • Internal or external to the system
    • Location (e.g., webserver for database software, disk or tape library for data)
    • Expected size and access rate
    • Data definition language (DDL, Java)
    • Data manipulation language (e.g., SQL, JDBC, OQL, Java)
    • Source of data (e.g., data entry, existing database, external data feed)
  • Logical Data Model (i.e., Logical Database Schema):
    • Relational Model (e.g., entity relationship attribute (ERA) diagrams, table definitions, stored procedures).
    • Object Model (e.g., class diagrams, class specifications).
  • Physical Data Model (i.e., Physical Database Schema):
    • Relational Model (e.g., entity relationship attribute (ERA) diagrams,table definitions, stored procedures).
    • Object Model (e.g., class diagrams, class specifications).
  • Approach to maintenance, backup, and disaster recovery
• Database Facade Design
• Appendices:
  • Major Issues
  • TBDs
  • Assumptions

Stakeholders

The typical stakeholders of a database design document 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 database design document 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 database design document 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 database design document include:

• Work Products:
  • System Requirments Specification
  • Domain Model Document
  • Glossary
  • System Architecture Document
  • Software Architecture Document
  • Any COTS package managing its own persistent data.
• Stakeholders:
  • Database tool vendors
  • Database experts

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 database design document 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 database design document 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 database design document 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 database design document.
• The maintenance, backup, and disaster recovery sections of the database design document 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 database design document 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 database design document is typically constrained by the following conventions:

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

Examples

• Example Database Design Document