Database Design Document Template
Database Design Document Template
Database Design Document Template
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 paragraphs styles.
Revision History
Date
Version
Description
Author
ii
<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...............................................................................................2
1.5.3. Data Owners...............................................................................................3
2.
System Overview.................................................................................3
2.1. System Information............................................................................................3
2.1.1. Database Management System Configuration.......................................3
2.1.2. Database Software Utilities.......................................................................4
2.1.3. Support Software.......................................................................................4
2.1.4. Security.......................................................................................................4
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.................................................................................................5
3.
4.
5.
Database Interfaces...........................................................................12
5.1. Database Interfaces.........................................................................................12
5.2. Operational Implications.................................................................................12
5.2.1. Data Transfer Requirements...................................................................12
5.2.2. Data Formats............................................................................................13
5.3. Interface [Name]...............................................................................................13
5.4. Dependencies...................................................................................................13
6.
Reporting............................................................................................13
6.1. Reporting Requirements.................................................................................13
6.2. Design issues...................................................................................................13
7.
Data Access.......................................................................................14
7.1. Role Definitions................................................................................................14
7.2. Users.................................................................................................................14
7.3. Table Access Patterns.....................................................................................14
8.
Implementation Considerations.......................................................15
8.1. Large Objects...................................................................................................15
8.2. Queues..............................................................................................................15
8.3. Partitioning.......................................................................................................15
9.
Non-Functional Design.....................................................................15
9.1.
9.2.
9.3.
9.4.
9.5.
Security Design................................................................................................15
Availability........................................................................................................15
Scalability..........................................................................................................16
Performance.....................................................................................................16
Error Processing..............................................................................................16
iv
<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 non-functional usage of the tables, and
performance considerations and requirements.
1.1. 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.
System Overview
Details
Project Sponsor
System name
System type
Operational status
<Month> <Year>
System Overview
Details
Special conditions
Acronym / Abbreviation
Meaning
POC
Point of Contact
RDBS
SA
System Administrator
DBA
Database Administrator
Role
Name
Telephone
[Role]
[Name]
[Email]
[123-345-456]
[Role]
[Name]
[Email]
[123-345-456]
[Role]
[Name]
[Email]
[123-345-456]
1.5.1.
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
Telephone
[Role]
[Name]
[Email]
[123-345-456]
[Role]
[Name]
[Email]
[123-345-456]
[Role]
[Name]
[Email]
[123-345-456]
1.5.2.
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.
Database Design Document
Template Version 1.1 (remove prior to publication)
<Month> <Year>
Organization
POC Name
Telephone
[Installation]
[Name]
[Email]
[123-345-456]
[Development]
[Name]
[Email]
[123-345-456]
[Security]
[Name]
[Email]
[123-345-456]
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
1.5.3.
Data Owners
Identify points of contact for those who own or are responsible for data quality, currency, accuracy, etc.
Type of Data
POC Name
Telephone
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.
<Month> <Year>
2.1.1.
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
2.1.2.
Identify any utility software that will be used to support the use or maintenance of the database.
Vendor
Product
Version
Comments
2.1.3.
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
2.1.4.
Security
Discuss any integrity and access controls that apply to database components such as schema, subschema, partitions or physical files, records or tables, sets or relations, and data elements.
<Month> <Year>
2.2. Architecture
2.2.1.
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.
2.2.2.
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.
2.2.3.
Interfaces
Identify interfaces to external systems. Interfaces are described in more detail in the following chapters.
2.2.4.
Data Stores
Identify and describe all data stores including databases, file systems and media data stores.
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.
Type of flexibility to be built into the database for adapting to changing requirements.
<Month> <Year>
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.
3.1. 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
#2
#3
Table 9: Assumptions
3.2. Issues
At this point, any outstanding issues should have been converted into design statements or into
assumptions as listed above.
3.3. 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
<Month> <Year>
Role
Name
Responsibility
Identify role
Email address
Identify role
Email address
Identify role
Email address
Guideline
Style
Table names
Field/Column
names
Example: Name Foreign key fields the same name as the primary key to
which they refer
Element
Element Name
Meaning
db_name
Database Name
db_path
Database Path
<Month> <Year>
Element
Element Name
Meaning
db_location
Database Location
System ID
Model
Version #
System Code
This Database
4.6.1.
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
Database Design Document
Template Version 1.1 (remove prior to publication)
<Month> <Year>
Script
Description
analz.sql
code.sql
comnt.sql
create.sql
dropname_d.sql
drop.sql
idx.sql
main.sql
populate.sql
4.6.2.
Physical Design
4.6.3.
Physical Structure
Provide a diagram illustrating the physical structure (i.e. partitions, files, indexes, pointers) and the
logical components of the database.
<Month> <Year>
4.9.1.
Mapping rules
4.9.2.
Identify entities and attributes that are not implemented as tables and columns.
Entity/Attribute
Description
4.9.3.
Non-trivial Mapping
List all tables that are not derived from an entity in a one-to-one fashion.
Table/Column
Mapped from
Purpose
4.9.4.
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
4.9.5.
Key Mappings
Identify the tables that have primary keys created from sequences:
Database Design Document
Template Version 1.1 (remove prior to publication)
10
<Month> <Year>
Table
Sequence
4.9.6.
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
4.10. Denormalisation
Where appropriate, describe how redundancy is added to the design to improve performance or support
specific functionality.
Denormalized Table/Column
Denormalized Table/Column
Source table or
entity
11
<Month> <Year>
Object
Description
Issues
Business Rule
Implemented
Identify business
rule
Implemented by using .
Identify business
rule
Implemented by using .
Identify business
rule
Implemented by using .
4.15. Storage
Provide sizing formulas for determining the storage required to support the database. Estimate the
internal and peripheral storage requirements.
4.16. Recovery
Describe how data, schemas and support files will be recreated or recovered in the event of a system
disaster.
5. Database Interfaces
5.1. Database Interfaces
Describe interfaces with other applications including those of other operational capabilities.
12
<Month> <Year>
5.2.1.
Describe data transfer requirements including content, format, sequence, and conversion issues.
5.2.2.
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.
Details
Purpose
Characteristics
Interface Architecture
Security
5.4. Dependencies
List any dependencies for the [Application] schema, for example, foreign keys across schemas.
Table
6. Reporting
6.1. Reporting Requirements
Describe any reporting requirements.
13
<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.
Role-name
Purpose
7.2. Users
Identify users that will be recognized by the database, including estimates of user volumetrics.
User name
Purpose
Function
Peak Frequency
Tables Used
Table
Type
14
<Month> <Year>
8. Implementation Considerations
8.1. Large Objects
Describe how large objects will be stored, for example, objects with a maximum size of 50MB will be
stored as BLOBS.
8.2. 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
Dependen
cy
Tracking
Auto
Commit
8.3. 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
Comments
9. Non-Functional Design
Describe the non-functional design elements for the database.
15
<Month> <Year>
9.2. Availability
Describe the database design subsystem/component availability and resilience requirements.
9.3. Scalability
Describe how the database design supports scalability requirements.
9.4. Performance
Describe how the database has been designed for performance.
9.7. Archiving
Describe the archiving policy to be used.
16
<Month> <Year>
Version
Description
Author
July 2009
1.0
OED Process
Management Service
September
2009
1.1
OED Process
Management Service
17
<Month> <Year>