<Enter Project Name Here>

Database Design Document

Department of Veterans Affairs

<Month><Year>

Version <#.#>

This template contains a paragraph style called Instructional Text. Text using this paragraph style is
designed to assist the reader in completing the document. Text in paragraphs added after this help text is
automatically set to the appropriate body text level. For best results and to maintain formatting
consistency, use the provided paragraph styles. Delete all instructional text before publishing or
distributing the document Revision History

Revision History
Date

Version

Description

Author

Place latest revisions at top of table.

The Revision History pertains only to changes in the content of the document or any updates
made after distribution. It does not apply to the formatting of the template.
Remove blank rows.

Database Design Document

<Month> <Year>

Table of Contents
1.

Introduction..........................................................................................1
1.1. Purpose...............................................................................................................1
1.2. Scope, Approach and Methods........................................................................1
1.3. System Overview...............................................................................................1
1.4. Acronyms and Abbreviations...........................................................................2
1.5. Points of Contact...............................................................................................2
1.5.1. Information.................................................................................................2
1.5.2. Coordination...............................................................................................3
1.5.3. Data Owners...............................................................................................3

2.

System Overview.................................................................................4
2.1. System Information............................................................................................4
2.1.1. Database Management System Configuration.......................................4
2.1.2. Database Software Utilities.......................................................................4
2.1.3. Support Software.......................................................................................4
2.1.4. Security.......................................................................................................5
2.2. Architecture........................................................................................................5
2.2.1. Hardware Architecture..............................................................................5
2.2.2. Software Architecture................................................................................5
2.2.3. Interfaces....................................................................................................5
2.2.4. Data Stores.................................................................................................6

3.

Database Design Decisions................................................................7

3.1. Assumptions......................................................................................................7
3.2. Issues..................................................................................................................8
3.3. Constraints.........................................................................................................8

4.

Database Administrative Functions...................................................9

4.1. Responsibility.....................................................................................................9
4.2. Naming Conventions.........................................................................................9
4.3. Database Identification......................................................................................9
4.4. Systems Using the Database..........................................................................10
4.5. Relationship to Other Databases...................................................................10
4.6. Schema Information.........................................................................................10
4.6.1. Description...............................................................................................11
4.6.2. Physical Design........................................................................................11
4.6.3. Physical Structure....................................................................................11
4.7. Special Instructions.........................................................................................11
4.8. Standards Deviations......................................................................................12

Database Design Document

<Month> <Year>

4.9. Entity Mapping.................................................................................................12

4.9.1. Mapping rules...........................................................................................12
4.9.2. Entities and Attributes Not Implemented..............................................12
4.9.3. Non-trivial Mapping.................................................................................12
4.9.4. Additional Objects...................................................................................12
4.9.5. Key Mappings...........................................................................................13
4.9.6. Other Deviations......................................................................................13
4.10.Denormalisation...............................................................................................13
4.11.Performance Improvement.............................................................................13
4.12.Functional Support..........................................................................................13
4.13.Historical Data..................................................................................................14
4.14.Business Rules................................................................................................14
4.15.Storage..............................................................................................................14
4.16.Recovery...........................................................................................................14

5.

Database Interfaces...........................................................................15
5.1. Database Interfaces.........................................................................................15
5.2. Operational Implications.................................................................................15
5.2.1. Data Transfer Requirements...................................................................15
5.2.2. Data Formats............................................................................................15
5.3. Interface <Name>..............................................................................................15
5.4. Dependencies...................................................................................................15

6.

Reporting............................................................................................16
6.1. Reporting Requirements.................................................................................16
6.2. Design issues...................................................................................................16

7.

Data Access.......................................................................................17
7.1. Role Definitions................................................................................................17
7.2. Users.................................................................................................................17
7.3. Table Access Patterns.....................................................................................17

8.

Implementation Considerations.......................................................18
8.1. Large Objects...................................................................................................18
8.2. Queues..............................................................................................................18
8.3. Partitioning.......................................................................................................18

9.

Non-Functional Design.....................................................................19
9.1.
9.2.
9.3.
9.4.
9.5.

Security Design................................................................................................19
. Availability.......................................................................................................19
Scalability..........................................................................................................19
Performance.....................................................................................................19
Error Processing..............................................................................................19

Database Design Document

<Month> <Year>

9.6. Backups and Recovery...................................................................................19

9.7. Archiving...........................................................................................................19

Database Design Document

<Month> <Year>

1. Introduction
The Database Design maps the logical data model to the target database management system
with consideration to the systems performance requirements. The Database Design converts
logical or conceptual data constructs to physical storage constructs (e.g., tables, files) of the
target DBMS.
Use this Database Design Template to define the basis for the [Application] database design.
Describe how the database that will support the [Application] Data Model, supported with
details of the logical and physical definitions, non-functional issues, database interfaces, and
storage requirements. Where possible, provide expected data volumes, functional and nonfunctional usage of the tables, and performance considerations and requirements.

Database Design Document

<Month> <Year>

Purpose

The purpose of the Database Design is to ensure that every database transaction meets or exceeds
its performance requirements. This document takes into account data and transaction volume to
produce a schema and environment that will meet necessary performance.
Describe the purpose of the Database Design document.

Database Design Document

<Month> <Year>

Scope, Approach and Methods

Describe the scope of this document as it relates to the project. For example:
The Database Design for the [Application] is composed of definitions for database objects
derived by mapping entities to tables, attributes to columns, unique identifiers to unique keys
and relationships to foreign keys. During design, these definitions may be enhanced to support
the functionality described in the functional specifications and defined in the primary and
supporting modules of the applications High-Level Design.

Database Design Document

<Month> <Year>

System Overview

Briefly describe the system for which this database will be designed. This serves as a point of
reference for the system designers and others involved in decision-making roles.

System Overview

Details

Project Sponsor
System name
System type

Major application, support system, back office

etc.

Operational status

Operational / In development / Under

modification

Special conditions
Table 1: System Overview

Database Design Document

<Month> <Year>

Acronyms and Abbreviations

Provide a list of the acronyms and abbreviations used in this document and the meaning of each.

Acronym / Abbreviation

Meaning

POC

Point of Contact

RDBS

Relational Database System

SA

System Administrator

DBA

Database Administrator

Table 2: Acronyms and Abbreviations

Database Design Document

<Month> <Year>

Points of Contact

Identify the points of contact that may be needed for informational purposes.

Role

Name

Email

Telephone

[Role]

[Name]

[Email]

[123-345-456]

[Role]

[Name]

[Email]

[123-345-456]

[Role]

[Name]

[Email]

[123-345-456]

Table 3: POC Contact Information

Database Design Document

<Month> <Year>

Information

Provide a list of the points of organizational contact (POCs) that may be needed by the
document user for informational and troubleshooting purposes. Include type of contact, contact
name, department, telephone number, and e-mail address (if applicable). Points of contact may
include, but are not limited to, helpdesk POC, development/maintenance POC, and operations
POC.

Role

Name

Email

Telephone

[Role]

[Name]

[Email]

[123-345-456]

[Role]

[Name]

[Email]

[123-345-456]

[Role]

[Name]

[Email]

[123-345-456]

Table 4: Organizational POC Contact Information

Database Design Document

<Month> <Year>

Coordination

Provide a list of organizations that require coordination between the project and its specific
support function (e.g., installation coordination, security, etc.). Include a schedule for
coordination activities.

Organization

POC Name

Email

Telephone

[Installation]

[Name]

[Email]

[123-345-456]

[Development]

[Name]

[Email]

[123-345-456]

[Security]

[Name]

[Email]

[123-345-456]

Table 5: Coordination POC Contact Information

Phase

Activity

POC

Start Date

Design

Sign-off document

[Name]

DD/MM/YYYY

Development

Develop Database

[Name]

DD/MM/YYYY

Testing

Test cycle

[Name]

DD/MM/YYYY

Table 6: Activity Start Information

Database Design Document

<Month> <Year>

Data Owners

Identify points of contact for those who own or are responsible for data quality, currency,
accuracy, etc.

Type of Data

POC Name

Email

Telephone

Table 7: Data Owner POC Information

Database Design Document

<Month> <Year>

2. System Overview
Provide a brief overview of the system. Ensure that this section is consistent with the high-level
design (if it exists).

NOTE:

Highlight errors in the High-Level Design document to the Database Designer.

Label each component, so that they may reference consistently across technical documents,
diagrams, and spreadsheets when referencing subsystems and components.

Database Design Document

<Month> <Year>

System Information

Specify the Database Management System configuration, hardware configuration, database

software utilities, and any support software used.

Database Design Document

<Month> <Year>

Database Management System Configuration

Identify the vendor, version and targeted hardware for the database management system.
Highlight any restrictions on the initialization and use of the DBMS.

Vendor

Hardware

Version

Comments

Table 8: Database Management System Configuration

Database Design Document

<Month> <Year>

Database Software Utilities

Identify any utility software that will be used to support the use or maintenance of the database.

Vendor

Product

Version

Comments

Table 9: Database Software Utilities

Database Design Document

<Month> <Year>

Support Software

Identify the support software directly related to the database, including name, version, function,
and major operating characteristics.
Examples include software for query language, report writers, storage, database loading, file
processing, and data cleansing.

Product

Version

Purpose

Table 10: Support Software

Database Design Document

<Month> <Year>

Security

Discuss any integrity and access controls that apply to database components such as schema,
sub-schema, partitions or physical files, records or tables, sets or relations, and data elements.

Database Design Document

<Month> <Year>

Architecture

Database Design Document

<Month> <Year>

Hardware Architecture

Provide a brief an overview of the hardware architecture with supporting [flowchart / state /
sequence etc.] diagrams to illustrate how components are connected. Identify the hardware
configurations on which the database will reside.

Database Design Document

<Month> <Year>

Software Architecture

List the components within the subsystem/application. Provide component diagrams to illustrate
connections within the application and external systems. Include components, datastores and
interfaces within the application as well as interfaces between internal components and external
systems.

Label internal interfaces for reference. Label external interfaces consistently with those
used in the high-level design document.
Indication direction on an interface, i.e. the direction of initiation or the main direction
of dataflow.

Database Design Document

<Month> <Year>

Interfaces

Identify interfaces to external systems. Interfaces are described in more detail in the following
chapters.

Database Design Document

<Month> <Year>

Data Stores

Identify and describe all data stores including databases, file systems and media data stores.

Database Design Document

<Month> <Year>

3. Database Design Decisions

Discuss the decisions that were made when designing the database for [Application], including
problems, alternative solutions, and design assumptions that had to be made. Ensure the analyst
team verifies any assumptions made as a result from ambiguities or lack of details.
Divide this section into paragraphs as needed to present database-wide design decisions.
Discuss how it will behave, from a user's point of view, in meeting its requirements and other
decisions affecting further design of the database.
Examples of design decisions may include:

Queries or other inputs the database will accept and outputs (displays, reports,
messages, responses, etc.) it will produce.
Database behavior in response to each input or query, including actions, response times
and other performance characteristics.
How databases / data files will appear to the user.

Type of flexibility to be built into the database for adapting to changing requirements.

Levels and types of availability, security, privacy, and continuity of operations.

Database distribution (such as client / server), master database file updates and
maintenance, including maintaining consistency, synchronization, enforcing integrity and
business rules
Backup and restoration including distribution strategies, permissible actions, and special
considerations for non-standard technologies.
Decisions on sorting, indexing, synchronization, and consistency including automated
disk management, optimizing strategies, storage and size considerations, and population
of the database and capture of legacy data

Database Design Document

<Month> <Year>

Assumptions

List any assumptions made due to lack of information, e.g. ambiguous sections in the functional
specifications, or made during design, e.g. assumed constraints, assumptions about other
systems or where requirements analysis was unclear.

Ref #

Assumption

Impact

#1

Describe the assumption

Discuss its effect on the database

design

#2

Describe the assumption

Discuss its effect on the database

design

#3

State none if appropriate

Table 11: Assumptions

Database Design Document

<Month> <Year>

Issues

At this point, any outstanding issues should have been converted into design statements or into
assumptions as listed above.

Database Design Document

<Month> <Year>

10

Constraints

Identify any known constraints on the database design. Constraints are factors that may restrict
the design/project by scope, resource, platform, language, schedule etc.

Ref #

Constraint

Impact

Table 12: Constraints

Database Design Document

<Month> <Year>

4. Database Administrative Functions

Database Design Document

<Month> <Year>

11

Responsibility

Identify the organizations and personnel responsible for the following database administrative
functions: database administrator, system administrator, and security administrator. Describe
specific administration skill requirements.

Role

Name

Responsibility

Email

Identify role

Identify the person

responsible

Identify area of responsibility

Email address

Identify role

Identify the person

responsible

Identify area of responsibility

Email address

Identify role

Identify the person

responsible

Identify area of responsibility

Email address

Table 13: Database Responsibilities

Database Design Document

<Month> <Year>

12

Naming Conventions

Identify logical and physical naming standards and conventions.

Type

Guideline

Style

Example: Use lowercase characters

Table names

Use singular names. Never plural

Field/Column
names

Example: Name Foreign key fields the same name as the primary key
to which they refer

Table 14: Database Naming Conventions

Database Design Document

<Month> <Year>

13

Database Identification

Identify the names or labels by which the database will identified. Specify the code name, tag, or
label by which each database table or file will be identified.
For example, the following elements provide identification and status information about the
database.

Element

Element Name

Meaning

db_name

Database Name

The name the database was given when created.

The real name of the database for which
information is collected or to which the
application is connected.

db_path

Database Path

The full path to the location where the database

is stored on the system.

db_location

Database Location

The location of the database in relation to the

application.

db_storage_pat
h

Storage path

Full path of a location that is used by the

database for placing automatic storage table
spaces

Table 15: Database Identification

Database Design Document

<Month> <Year>

14

Systems Using the Database

Identify the systems that will use the database. Include the full system identification and model,
modification, version number, and system code.

System ID

Model

Version #

System Code

Table 16: Systems Using the Database

Database Design Document

<Month> <Year>

15

Relationship to Other Databases

Indicate whether the database will supersede or interface with other databases, and specify
which one(s).

This Database

Supersedes this Database

Interfaces with the

Database

Table 17: Relationship to Other Databases

Database Design Document

<Month> <Year>

16

Schema Information

Describe the overall structure in the schema or other global definition of the database.

Database Design Document

<Month> <Year>

Description

Describe the schema and each sub-schema of the system including name, file type and name,
data description language, access control keys, concurrence locking, data name mapping,
overall partition/file limitations and controls, redefinition and access path restrictions and any
other limitations or restrictions.
Sample Schema

Script

Description

analz.sql

Collects statistics on the tables in the schema

code.sql

Creates procedural objects in the schema

comnt.sql

Creates comments for each object in the schema

create.sql

Creates the objects

dropname_d.sql

Drops the name column

drop.sql

Drops the schema and all its objects

idx.sql

Creates indexes on the tables

main.sql

Main script for the schema; calls other scripts

populate.sql

Populates the objects

Table 18: Schema Description

< Insert generated DDL from DBMS tool >

Database Design Document

<Month> <Year>

Physical Design

Provide a diagram illustrating the physical design of the database.

Database Design Document

<Month> <Year>

Physical Structure

Provide a diagram illustrating the physical structure (i.e. partitions, files, indexes, pointers) and
the logical components of the database.

Database Design Document

<Month> <Year>

17

Special Instructions

Provide instructions for DBAs, operators and testers who my use the database for testing and
operational purposes. For example:

Specialized criteria for entering data into the database.

Procedures for submitting data for entry into the database.

Instructions for generating, modifying, updating, or otherwise using the database.

Database Design Document

<Month> <Year>

18

Standards Deviations

List any known deviations from corporate standards and recommended guidelines.

Database Design Document

<Month> <Year>

19

Entity Mapping

Identify the mapping rules and lists tables and columns that either:

Do not originate from a single entity

Are not implemented

Database Design Document

<Month> <Year>

Mapping rules

Identify rules for mapping entities to tables, for example:

Entities are mapped onto tables in a one to one manner

Attributes are mapped to columns in a one to one manner

One-to-many relationships are mapped to foreign keys

Many-to-many relationships are implemented using a keys-only table

Database Design Document

<Month> <Year>

Entities and Attributes Not Implemented

Identify entities and attributes that are not implemented as tables and columns.

Entity/Attribute

Description

Reason for not

implementing

Table 19: Entities and Attributes Not Implemented

Database Design Document

<Month> <Year>

Non-trivial Mapping

List all tables that are not derived from an entity in a one-to-one fashion.

Table/Column

Mapped from

Purpose

Reason for
deviation

Table 20: Non-trivial Mapping

Database Design Document

<Month> <Year>

Additional Objects

Lists database objects (tables or columns) that were not derived from an entity but added to the
database design for the purpose listed below.

Table/column

Description

Purpose

Table 21: Additional Objects

Database Design Document

<Month> <Year>

Key Mappings

Identify the tables that have primary keys created from sequences:

Table

Primary key column

Sequence

Table 22: Key Mappings

Database Design Document

<Month> <Year>

Other Deviations

Identify deviations from a one-to-one mapping of entity and attribute names to table and column
names and any foreign key naming deviations.

Entity/Attribute/Relation

Table/Column/Foreign Key
Column

Reason for deviating

Table 23: Other Deviations

Database Design Document

<Month> <Year>

20

Denormalisation

Where appropriate, describe how redundancy is added to the design to improve performance or
support specific functionality.

Database Design Document

<Month> <Year>

21

Performance Improvement

Identify objects that were modified in order to improve performance:

Denormalized
Table/Column

Source table or entity

Rules and methods for

maintaining integrity

Table 24: Denormalization-related Performance Improvements

Database Design Document

<Month> <Year>

22

Functional Support

Identify objects that were modified in order to support the proposed functionality of
[Application]:

Denormalized Table/Column

Source table or
entity

Rules and methods for

maintaining integrity

Table 25: Denormalization-related Function Support

Database Design Document

<Month> <Year>

23

Historical Data

Identify additions made to accommodate data manipulation and to keep/archive/delete historic

data.

Object

Description

Issues

Table 26: Historical Data

Database Design Document

<Month> <Year>

24

Business Rules

Describe business rules modeled in the data model, specified for entities in the data model or in
the functional specification that have NOT been implemented as table/column
constraints/column-defaults.

Business Rule

Implemented

Identify business
rule

Implemented by using .

Identify business
rule

Implemented by using .

Identify business
rule

Implemented by using .

Table 27: Business Rules

Database Design Document

<Month> <Year>

25

Storage

Provide sizing formulas for determining the storage required to support the database. Estimate
the internal and peripheral storage requirements.

Database Design Document

<Month> <Year>

26

Recovery

Describe how data, schemas and support files will be recreated or recovered in the event of a
system disaster.

Database Design Document

<Month> <Year>

5. Database Interfaces

Database Design Document

<Month> <Year>

27

Database Interfaces

Describe interfaces with other applications including those of other operational capabilities.

Database Design Document

<Month> <Year>

28

Operational Implications

Describe operational implications of data transfer, including security considerations.

Database Design Document

<Month> <Year>

Data Transfer Requirements

Describe data transfer requirements including content, format, sequence, and conversion issues.

Database Design Document

<Month> <Year>

Data Formats

Describe data formats for the sending and receiving systems, including the data item names,
codes, abbreviations, as well as any units of measure/conversion issues.

Database Design Document

<Month> <Year>

29

Interface <Name>

Interface

Details

Purpose

Describe the purpose of the interface

Characteristics

Summarize the interface characteristics

Interface Architecture

Describe the interface architecture.

API and Error

Conditions

Describe the API and error conditions. Reference separate module

interface specifications for more detailed information.

Security

Describe protocols, user authentication, encryption, access control

(at the interface entry point).

Table 28: Interface Details

Database Design Document

<Month> <Year>

30

Dependencies

List any dependencies for the [Application] schema, for example, foreign keys across schemas.

Table and column in [application]

schema

Schema the table/ column

refers to

Table

Table 29: Dependencies

Database Design Document

<Month> <Year>

6. Reporting

Database Design Document

<Month> <Year>

31

Reporting Requirements

Describe any reporting requirements.

Database Design Document

<Month> <Year>

32

Design issues

Describe the design to support reporting and other information requirements.

Database Design Document

<Month> <Year>

7. Data Access
Discuss which roles are needed to use the database and highlight any significant information
related to the physical database implementation, for example, tables subject to high insert or
delete activity or with specific archiving rules.

Database Design Document

<Month> <Year>

33

Role Definitions

Identify the roles defined in the database.

Role-name

Purpose

Table 30: Database Role Definitions

Database Design Document

<Month> <Year>

34

Users

Identify users that will be recognized by the database, including estimates of user volumetrics.

User name

Purpose

Table 31: Database Users

Database Design Document

<Month> <Year>

35

Table Access Patterns

Identify performance-critical functions and their table usage. Where possible, provide
volumetric information needed for the physical database design.

Function

Peak Frequency

Tables Used

Table 32: Table Access Patterns

Identify tables that will be classified as one of the following:

Table

Type

High-volume read only

High-volume insert
High-volume updates
Table 33: Table Types

Database Design Document

<Month> <Year>

8. Implementation Considerations

Database Design Document

<Month> <Year>

36

Large Objects

Describe how large objects will be stored, for example, objects with a maximum size of 50MB
will be stored as BLOBS.

Database Design Document

<Month> <Year>

37

Queues

Describe how queues (i.e. asynchronous messaging techniques) will be used. Specify which
functionality the queue implements and the implementing queuing technology (e.g. JMS).
Queue
Name

Table
Name

Queue
Type

Max
Retries

Retry
Delay

Retentio
n
Time

Dependenc
y Tracking

Auto
Commit

Table 34: Queues Descriptions

Database Design Document

<Month> <Year>

38

Partitioning

Describe the design and format of each partition/file, including name, type, code, mapping,
limitations and controls, access procedures, and mechanisms. Identify the interdependencies of
each partition/file in the database.

Partition
Table

Index (Y/N)

Partitio
n
column

Partition
value

Partition
Name

Partition
size

Comment
s

Table 35: Partition Descriptions

Database Design Document

<Month> <Year>

9. Non-Functional Design
Describe the non-functional design elements for the database.

Database Design Document

<Month> <Year>

39

Security Design

Describe authentication, integrity, and confidentiality requirements that will be supported within
the database.

Database Design Document

<Month> <Year>

40

Availability

Describe the database design subsystem/component availability and resilience requirements.

Database Design Document

<Month> <Year>

41

Scalability

Describe how the database design supports scalability requirements.

Database Design Document

<Month> <Year>

42

Performance

Describe how the database has been designed for performance.

Database Design Document

<Month> <Year>

43

Error Processing

Describe the error processing strategy adopted and how it is supported within the database
design.

Database Design Document

<Month> <Year>

44

Backups and Recovery

Describe the backup and recovery policy to be used.

Database Design Document

<Month> <Year>

45

Archiving

Describe the archiving policy to be used.

Database Design Document

<Month> <Year>

Template Revision History

Date

Versio
n

Description

Author

October 2014

1.2

Upgrade to MS Office 2007-2010 format

and edit for conformance to current
Section 508 Guidelines

Process
Management

September
2009

1.1

Removed This Page Intentionally Left

Blank pages.

OED Process
Management Service

July 2009

1.0

Initial OED ProPath release

OED Process
Management Service

Database Design Document

<Month> <Year>