Database Design Document (DBDD)
- Database Design Document (DBDD)
- the design work product that officially documents the
design of the
databases that will be part of an
application
The typical objectives of a database design document are
to:
- Formally document the logical and physical design of all
application databases.
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.
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
The typical stakeholders of a database design document
are:
- Producer:
- Evaluators:
- Approvers:
- Maintainers:
- 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.
A database design document is typically developed during the
following phases:
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.
The typical inputs to a database design document
include:
- Work Products:
- Stakeholders:
- Database tool vendors
- Database experts
- 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.
A database design document is typically constrained by the
following conventions:
-
Work Flow
-
Content and Format Standard
-
MS Word Template
-
XML Template
-
Inspection Checklist
-
Example Database Design
Document