0% found this document useful (0 votes)
30 views15 pages

DatabaseDesignDocumentV1 1

This document provides a template for creating a Database Design Document (DDD) for a given project. It includes sections for an introduction, referenced documents, design decisions, detailed database design, database administration and monitoring, glossary, acronyms, and appendices. The template guides the author to replace angle bracket fields with project-specific information, modify boilerplate text as needed, and delete instructions to the author. It also provides examples of how to format approvals, revision history, tables of contents, figures and tables.

Uploaded by

traspac9.traspac
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
30 views15 pages

DatabaseDesignDocumentV1 1

This document provides a template for creating a Database Design Document (DDD) for a given project. It includes sections for an introduction, referenced documents, design decisions, detailed database design, database administration and monitoring, glossary, acronyms, and appendices. The template guides the author to replace angle bracket fields with project-specific information, modify boilerplate text as needed, and delete instructions to the author. It also provides examples of how to format approvals, revision history, tables of contents, figures and tables.

Uploaded by

traspac9.traspac
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 15

Centers for Medicare & Medicaid Services

<Business Owner’s Office/Center>


<Business Owner’s Group>
7500 Security Blvd
Baltimore, MD 21244-1850

Database Design Document Template


Database Design Document (DDD)

Version: <1.0>
Last Modified: <Month Day, Year>

[DDD Template Version 1.1 – August 6, 2008


Approved for use by the ESD Deliverables Workgroup]
Document Number: <document’s configuration item control number>
Contract Number: <current contract number of company maintaining document>
<System Name and/or Acronym>

Notes to the Author

[This document is a template for creating a Database Design Document (DDD) for a given
project. The template includes instructions to the author, boilerplate text, and fields that should
be replaced with the values specific to the particular project.

 Blue italicized text enclosed in square brackets (i.e., [text]) provides instructions to the
document author, or describes the intent, assumptions and context for content included in
this document.
 Blue italicized text enclosed in angle brackets (i.e., <text>) indicates a field that should
be replaced with information specific to the particular project.
 Text and tables in black are provided as boilerplate examples of wording and formats
that may be used or modified as appropriate.

When using this template, follow these steps:

1.) Replace all text enclosed in angle brackets (e.g., <System Name (Acronym)>) with the
appropriate information for the specific project. These angle brackets appear in both the
body of the document and in headers and footers.
2.) Modify any boilerplate text as appropriate to the specific project.
3.) To add any new sections to the document, ensure that the appropriate header and body
text styles are maintained. Styles used for the section headings are Heading 1 (Times
New Roman 16 pt) and section sub-headings are Heading 2 (Times New Roman 14 pt).
The style used for boilerplate and body text is Body Text (Times New Roman 12 pt).
4.) To update the Table of Contents, right-click and select “Update field” and choose the
option “Update entire table”. Ensure that sub-headings at each level in the Table of
Contents are appropriately indented for improved readability.
5.) Delete this “Notes to the Author” page and all instructions to the author (i.e., all blue
italicized text enclosed in square brackets) before finalizing the initial draft of the DDD.]

_____________________________________________________________________________________________
Database Design Document <Version # / Date> i
<System Name and/or Acronym>

APPROVALS

[Obtain signature approval of the final document from the delivering organization’s Project
Manager and the primary CMS recipient (i.e., generally the Government Task Leader (GTL)).
Additional signature lines may be added as needed (e.g., CMS Business Owner).]

Submitting Organization’s Approving Authority:

Signature Printed Name Date Phone Number

<Position Title> [e.g., <System Name and/or Acronym> Project Manager]

CMS’ Approving Authority:

Signature Printed Name Date Phone Number

<Position Title> [e.g., <Contract or System Name> Government Task Leader]

_____________________________________________________________________________________________
Database Design Document <Version # / Date> ii
<System Name and/or Acronym>

REVISION HISTORY

[Use the table below to record information regarding changes made to the document over time.]
Versio Date Organization/Point of Contact Description of Changes
n
1.0 <mm/dd/yy> <Organization Identifier / Point-of- Baseline Version
Contact Name>

_____________________________________________________________________________________________
Database Design Document <Version # / Date> iii
<System Name and/or Acronym>

TABLE OF CONTENTS

1. INTRODUCTION..................................................................................................................1
2. REFERENCED DOCUMENTS............................................................................................1
3. OVERVIEW............................................................................................................................1
4. ASSUMPTIONS/CONSTRAINTS/RISKS..........................................................................2
4.1. Assumptions....................................................................................................................................2
4.2. Constraints.......................................................................................................................................2
4.3. Risks................................................................................................................................................2
5. DESIGN DECISIONS............................................................................................................2
5.1. Key Factors Influencing Design......................................................................................................2
5.2. Functional Design Decisions...........................................................................................................3
5.3. Database Management System Decisions.......................................................................................3
5.4. Security and Privacy Design Decisions..........................................................................................3
5.5. Performance and Maintenance Design Decisions...........................................................................3
6. DETAILED DATABASE DESIGN......................................................................................4
6.1. Data Software Objects and Resultant Data Structures....................................................................4
6.2. Database Management System Files...............................................................................................5
7. DATABASE ADMINISTRATION AND MONITORING.................................................5
7.1. Roles and Responsibilities..............................................................................................................5
7.2. System Information.........................................................................................................................6
7.2.1. Database Management System Configuration........................................................................6
7.2.2. Database Support Software.....................................................................................................6
7.2.3. Security and Privacy...............................................................................................................6
7.3. Performance Monitoring and Database Efficiency.........................................................................6
7.3.1. Operational Implications.........................................................................................................7
7.3.2. Data Transfer Requirements...................................................................................................7
7.3.3. Data Formats...........................................................................................................................7
7.4. Backup and Recovery......................................................................................................................7
8. GLOSSARY............................................................................................................................7
9. ACRONYMS...........................................................................................................................7
10. APPENDICES..........................................................................................................................8

_____________________________________________________________________________________________
Database Design Document <Version # / Date> iv
<System Name and/or Acronym>

LIST OF FIGURES

[Insert a List of Figures appearing within the DDD along with a page reference for each
identified figure as appropriate. Labels of Figure titles and descriptions are to be placed
centered, above the figure within the main body of the document. All figures must have an
associated tag providing appropriate alternative text for Section 508 compliance.]

<Figure #: Figure Title or Description……………………………………………Page Number>

LIST OF TABLES

[Insert a List of Tables appearing within the DDD along with a page reference for each
identified table as appropriate. Labels of Table titles and descriptions are to be placed centered,
above the table within the main body of the document.]

<Table #: Table Title or Description………………………..……………………Page Number>

Table 1: Referenced Documents.....................................................................................................1

_____________________________________________________________________________________________
Database Design Document <Version # / Date> v
<System Name and/or Acronym>

1. INTRODUCTION
[Provide identifying information for the existing and/or proposed automated system or situation
for which the DDD applies (e.g., the full names and acronyms for the development project, the
existing system or situation, and the proposed system or situation, as applicable). Summarize
the purpose of the document, the scope of activities that resulted in its development, the intended
audience for the document, and expected evolution of the document. Also describe any security
or privacy considerations associated with use of the DDD.]

2. REFERENCED DOCUMENTS
[Summarize the relationship of this document to other relevant documents (e.g., the
Requirements Document, High-Level Technical Design Concept/Alternatives, Logical Data
Model, System Design Document (SDD), Interface Control Document (ICD), Data Conversion
Plan, and Release Plan, if they exist).

Provide identifying information for all documents used to arrive at and/or referenced within the
DDD (e.g., Logical Data Model, Data Dictionary provided as an appendix to the SDD, related
and/or companion documents, prerequisite documents, relevant technical documentation, etc.).

Table 1: Referenced Documents

Document Name Document Number Issuance Date


<document name> <document’s configuration item <Month Day, Year>
control number>

3. OVERVIEW
[Briefly introduce the system context and the basic design approach or organization, including
dependencies on other systems. Identify if the database will supersede or interface with other
databases, and specifically identify them if applicable. Also identify interfaces with other
systems to the extent that they significantly impact the database design. Discuss the background
to the project, if this will help understand the functionality supported by the database design
contained in this document.]

_____________________________________________________________________________________________
Database Design Document <Version # / Date> 1 of <max pages>
<System Name and/or Acronym>

4. ASSUMPTIONS/CONSTRAINTS/RISKS
4.1. Assumptions
[Describe any assumptions or dependencies regarding the database design for the system. These
may concern such issues as: related software or hardware, operating systems, or end-user
characteristics.]

4.2. Constraints
[Describe any limitations or constraints that have a significant impact on the database design
for the system.]

4.3. Risks
[Describe any risks associated with the database design and proposed mitigation strategies.]

5. DESIGN DECISIONS
[Utilizing the following subsections, describe decisions made that impact the proposed database
design. This should include the platform and database management system (DBMS) chosen for
the project. Include any other information relevant to the database design decisions (e.g., Data
Conversion Plan, Service Level Agreements (SLAs)). The Design Decisions section is written at
a higher level than the subsequent Detailed Database Design section, and provides an
understanding and rationale for the content in the Detailed Database Design section. If any of
the information in this section is provided in the SDD, ICD(s), or other documents (e.g., Data
Conversion Plan), they may be referenced within this section as appropriate.]

5.1. Key Factors Influencing Design


[Describe key functional or non-functional requirements that influenced the design. If all such
decisions are explicit in the requirements, this section shall so state. Design decisions that
respond to requirements designated as critical (e.g., those for performance, availability,
security, or privacy) shall be placed in separate subparagraphs. If a design decision depends
upon system states or modes, this dependency shall be indicated. If some or all of the design
decisions are described in the documentation of a custom or commercial DBMS, or in the SDD,
they may be referenced in this section. Design conventions needed to understand the design
shall also be presented or referenced.]

_____________________________________________________________________________________________
Database Design Document <Version # / Date> 2 of <max pages>
<System Name and/or Acronym>
5.2. Functional Design Decisions
[Describe decisions about how the database will behave in meeting its requirements from a
user's point of view (i.e., functionality of the database from an application perspective), ignoring
internal implementation, and any other decisions affecting further design of the database.
Include decisions regarding inputs the database will accept and outputs (displays, reports,
messages, responses, etc.) it will need to support, including interfaces with other systems.
Describe the general types of processing (sequential versus random for inserts, updates, deletes
and queries) required both for data entering the database, and data most frequently accessed. If
any of this information is provided in ICD(s) or other documents, they may be referenced.
Describe selected equations/algorithms/rules, disposition, and handling of un-allowed inputs.
Also include decisions on how databases/data files will appear to the user.]

5.3. Database Management System Decisions


[Describe design decisions regarding the DBMS intended for the initial implementation.
Provide the name and version/release of the DBMS, the reason for selection, and the type of
flexibility built into the database for adapting to changing requirements.]

5.4. Security and Privacy Design Decisions


[Describe design decisions on the levels and types of security and privacy to be offered by the
database. General descriptions of classifications of users and their general access rights should
be included.]

5.5. Performance and Maintenance Design Decisions


[Describe how performance and availability requirements will be met. Examples include:
 Describe design decisions on database distribution (such as client/server), master
database file updates and maintenance, including maintaining consistency, establishing/
reestablishing and maintaining synchronization, enforcing integrity and business rules.
 Describe design decisions to address concurrence issues (e.g., how the data are
partitioned or distributed to support multiple applications or competing update functions,
if applicable).
 Describe design decisions to support Service Level Agreements (SLAs) for key functions
supported by the database.
 Describe design decisions on backup and restoration including data and process
distribution strategies, permissible actions during backup and restoration, and special
considerations for new or non-standard technologies such as video and sound. Describe
the impact this maintenance will have on availability.
 Describe design decisions on data reorganization (i.e., repacking, sorting, table and
index maintenance), synchronization, and consistency, including automated disk
management and space reclamation considerations, optimizing strategies and
_____________________________________________________________________________________________
Database Design Document <Version # / Date> 3 of <max pages>
<System Name and/or Acronym>
considerations, storage and size considerations (e.g., future expansion), and population
of the database and capture of legacy data. Describe the impact this maintenance will
have on availability.
 Describe design decisions to support purging and/or archiving of data to ensure
performance and storage objectives are met. Describe the impact this maintenance will
have on availability. Describe any needs to recall archived data back into the database.]

6. DETAILED DATABASE DESIGN


[Describe the design of all DBMS files associated with the system, and any non-DBMS files
pertinent to the database design. The headings and sub-headings in this section should be
structured according to the information to be presented, and may include discussions about or
references to the following:
 Logical Data Model (LDM) and LDM Entity Relationship Diagram (ERD).
 Physical Data Model (PDM) and PDM ERD.
 A comprehensive Data Dictionary showing data stores, data element name, type, length,
source, constraints, validation rules, maintenance (create, read, update, delete (CRUD)
capability), audit and data masking requirements, expected data volumes, life expectancy
of the data, information life-cycle management strategy or at least an archiving strategy,
outputs, aliases, and description.
 Indexes that will be required for the data objects.
 Planned implementation factors (e.g., distribution and synchronization) that impact the
design.

The detailed database design information can be included as an appendix, which would be
referenced here. If any of the information in this section is provided in the SDD, ICD(s), or
other documents, they may be referenced.]

6.1. Data Software Objects and Resultant Data Structures


[For each functional data object, specify the data structure(s) which will be used to store and
process the data. Describe any data structures that are a major part of the system, including
major data structures that are passed between components. List all database objects including
stored procedures, functions and function parameters. For functions, give function input and
output names in the description. Refer as appropriate to the decomposition diagrams. Provide
the detailed description of any non-DBMS files (e.g., property files) that are required for DBMS
functioning or maintenance and are not already addressed in the SDD. Include a narrative
description of the usage of each file that identifies if the file is used for input, output, or both, and
if the file is a temporary file. Also provide an indication of which modules read and write the file
(refer to the Data Dictionary). As appropriate, include file structure information.]

_____________________________________________________________________________________________
Database Design Document <Version # / Date> 4 of <max pages>
<System Name and/or Acronym>
6.2. Database Management System Files
[Provide an appropriate level of detailed design of the DBMS files, based on the DBMS chosen.
Describe file structures and their locations. Explain how data may be structured in the selected
DBMS, if applicable. For networks, detail the specific distribution of data. Note any changes to
the LDM, which occur because of software or hardware requirements or to support performance
objectives. Include the following information, as appropriate (refer to the Data Dictionary):
 Physical description of the DBMS schemas, sub-schemas, records, sets, tables, storage
page sizes, etc. A PDM ERD should be included in an appendix.
 Objects created to support access methods (e.g., indexed, via set, sequential, random
access, sorted pointer array, etc.)
 Distribution, partitioning, or other compartmentalization of the data to support design.
 Estimate of the DBMS file size or volume of data within the file, and data pages,
including overhead resulting from access methods and free space.
 Definition of the update frequency of the database tables, views, files, areas, records,
sets, and data pages. Also provide an estimate of the number of transactions, if the
database is an online transaction-based system.]

7. DATABASE ADMINISTRATION AND MONITORING


[Within the following sub-sections, describe the requirements and strategies to maintain the
database operationally considering the following:
 Required availability and requirements for standby sites of the data stores, both DBMS
and non-DBMS to satisfy continuity of operations and meet required Service Level
Agreements (SLAs).
 Any database specific application and user support scenarios that are not documented in
the SDD.
 Any monitoring and performance goals/requirements, and how the DDD supports them.
 Required maintenance of the data stores to maintain acceptable performance.
 Backup and recovery strategies needed to implement the DDD.
 Any security and/or privacy considerations.]

7.1. Roles and Responsibilities


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

_____________________________________________________________________________________________
Database Design Document <Version # / Date> 5 of <max pages>
<System Name and/or Acronym>
7.2. System Information
[Document the DBMS configuration, hardware configuration, database software utilities, and
any support software used. If any of these software elements or hardware configurations are not
CMS-standard architecture, indicate the date these items were approved or a waiver was
granted.]

7.2.1. Database Management System Configuration


[Identify the vendor, version or release date and targeted hardware for the DBMS chosen for the
initial implementation of the database. Describe any restrictions on the initialization and use of
the DBMS to support any intended distributed processing. Identify the minimum hardware
configurations for the environment on which the database will reside. Describe the storage
device and storage requirements. Provide sizing formulas for determining the storage required
to support the database content and associated software. Estimate the internal and peripheral
storage requirements. Identify multiple storage requirements for distributed processing.]

7.2.2. Database Support Software


[List and reference the documentation of any DBMS utility software available to support the use
or maintenance of the database. Describe all support software, including the operating system,
directly related to the database, including name, version, function, and major operating
characteristics. Cite documentation by title, number, and appropriate sections. Examples of
such software include database management systems, query languages, report writers, storage
allocation software, database-loading software programs, file processing programs, and data
cleaning software.]

7.2.3. Security and Privacy


[Describe the use and management of integrity and access controls that apply to all database
components such as schema, sub-schema, partitions or physical files, records or tables, sets or
relations, and data elements. Describe any tools or sub-schemas that will support security and
privacy requirements].

7.3. Performance Monitoring and Database Efficiency


[Provide appropriate detailed subparagraphs that relate to section 5.5 (Performance and
Maintenance Design Decisions). Describe what parties will be responsible for monitoring
performance (to include space utilization, system resource consumption, and query performance
metrics), along with tools that will help provide this monitoring. If interfaces with other systems
impact maintenance, provide a description of those interfaces with other application software
including those of other operational capabilities and from other organizations. For each
interface, specify the information described in the following sub-sections.]

_____________________________________________________________________________________________
Database Design Document <Version # / Date> 6 of <max pages>
<System Name and/or Acronym>
7.3.1. Operational Implications
[Describe operational implications of data transfer, refresh and update scenarios and expected
windows, including security considerations. If any of these are documented in the SDD or the
ICD, they can be referenced here.]

7.3.2. Data Transfer Requirements


[Describe data transfer requirements to and from the software, including data content, format,
sequence, volume/frequency and any conversion issues. If any of these are documented in the
SDD or the ICD, they can be referenced here.]

7.3.3. Data Formats


[Describe formats of data for both the sending and receiving systems, including the data item
names, codes, or abbreviations that are to be interchanged, as well as any units of
measure/conversion issues. If any of these are documented in the SDD or the ICD, they can be
referenced here.]

7.4. Backup and Recovery


[Describe required strategies and scheduling for periodic backups of the data. If certain objects
have differing requirements, provide a breakdown by object. Describe the methodology for
reestablishment or recreation of the necessary data schema and system support files.]

8. GLOSSARY
[Provide clear and concise definitions for terms used in the DDD that may be unfamiliar to
readers of the document. Terms are to be listed in alphabetical order.]

<Term Name>

<Term definition>

<Term Name>

<Term definition>

9. ACRONYMS
[Provide a list of acronyms and associated literal translations used within the document. List the
acronyms in alphabetical order utilizing a tabular format as depicted below.]

_____________________________________________________________________________________________
Database Design Document <Version # / Date> 7 of <max pages>
<System Name and/or Acronym>

<ACRONYM> <Literal Translation>


CRUD Create, Read, Update, Delete
DBMS Database Management System
DDD Database Design Document
ERD Entity Relationship Diagram
ICD Interface Control Document
LDM Logical Data Model
PDM Physical Data Model
SLA Service Level Agreement
SDD System Design Document

10. APPENDICES
[Utilize appendices to facilitate ease of use and maintenance of the DDD document. Each
appendix should be referenced in the main body of the document where that information would
normally have been provided. Suggested appendices include, but are not limited to the
following:
 PDM – provide the Physical Data Model prepared to support the project.
 PDM ERD – provide the Entity Relationship Diagram for the PDM.
 CRUD Matrix – provide CRUD Matrix (Create, Read, Update, Delete) indicating how the
data will be maintained and accessed.
 Database Request (DR) Forms – If required, provide CMS-approved documents or forms to
initiate, track, monitor, and implement changes to be made by the central DBAs to CMS
enterprise databases.]

_____________________________________________________________________________________________
Database Design Document <Version # / Date> 8 of <max pages>

You might also like