Database Design Document

Database Design Document 1. Introduction Instructions: 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. Overview Instructions: 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. 3. Assumptions/Constraints/Risks 3.1 Assumptions Instructions: 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. 3.2 Constraints Instructions: Describe any limitations or constraints that have a significant impact on the database design for the system. 3.3 Risks Instructions: Describe any risks associated with the database design and proposed mitigation strategies. 4. Design Decisions Instructions: 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. 4.1 Key Factors Influencing Design Instructions: 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. 4.2 Functional Design Decisions Instructions: 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. 4.3 Database Management System Decisions Instructions: 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. 4.4 Security and Privacy Design Decisions Instructions: 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. 4.5 Performance and Maintenance Design Decisions Instructions: 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 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. 5. Detailed Database Design Instructions: 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. 5.1 Data Software Objects and Resultant Data Structures Instructions: 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. 5.2 Database Management System Files Instructions: 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. 6. Database Administration and Monitoring Instructions: Within the following sub-sections, describe the requirements and strategies to maintain the database operationally considering the following:       6.1 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. Roles and Responsibilities Instructions: 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. 6.2 System Information Instructions: 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. 6.2.1 Database Management System Configuration Instructions: 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. 6.2.2 Database Support Software Instructions: 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. 6.2.3 Security and Privacy Instructions: 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 subschemas that will support security and privacy requirements. 6.3 Performance Monitoring and Database Efficiency Instructions: Provide appropriate detailed subparagraphs that relate to the section named 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. 6.3.1 Operational Implications Instructions: 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. 6.3.2 Data Transfer Requirements Instructions: 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. 6.3.3 Data Formats Instructions: 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. 6.4 Backup and Recovery Instructions: 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. Appendix A: Suggested Appendices 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. Appendix B: Record of Changes Instructions: Provide information on how the development and distribution of the Database Design Document Template will be controlled and tracked. Use the table below to provide the version number, the date of the version, the author/owner of the version, and a brief description of the reason for creating the revised version. Table 1 - Record of Changes Version Number Date Author/Owner Description of Change Appendix C: Acronyms Instructions: Provide a list of acronyms and associated literal translations used within the document. List the acronyms in alphabetical order using a tabular format as depicted below. Table 2 - Acronyms Acronym Literal Translation Appendix D: Glossary Instructions: Provide clear and concise definitions for terms used in this document that may be unfamiliar to readers of the document. Terms are to be listed in alphabetical order. Table 3 - Glossary Term Acronym Definition Appendix E: Referenced Documents Instructions: Summarize the relationship of this document to other relevant documents. Provide identifying information for all documents used to arrive at and/or referenced within this document (e.g., related and/or companion documents, prerequisite documents, relevant technical documentation, etc.). Table 4 - Referenced Documents Document Name Document Location and/or URL Issuance Date Appendix F: Approvals The undersigned acknowledge that they have reviewed the Database Design Document and agree with the information presented within this document. Changes to this Database Design Document will be coordinated with, and approved by, the undersigned, or their designated representatives. Instructions: List the individuals whose signatures are desired. Examples of such individuals are Business Owner, Project Manager (if identified), and any appropriate stakeholders. Add additional lines for signature as necessary. Table 5 - Approvals Document Approved By Date Approved Name: , - Date Name: , - Date Name: , - Date Name: , - Date Appendix G: Notes to the Author/Template Instructions This document is a template for creating a Database Design Document Template for a given investment or project. The final document should be delivered in an electronically searchable format. The Database Design Document Template should stand on its own with all elements explained and acronyms spelled out for reader/reviewers, including reviewers outside CMS who may not be familiar with CMS projects and investments. This template includes instructions, boilerplate text, and fields. The developer should note that:    Each section provides instructions or describes the intent, assumptions, and context for content included in that section. Instructional text appears in blue italicized font throughout this template. Instructional text in each section should be replaced with information specific to the particular investment. Some text and tables 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. Table captions and descriptions are to be placed left-aligned, above the table. 2. Modify any boilerplate text, as appropriate, to your specific investment. 3. Do not delete any headings. If the heading is not applicable to the investment, type “Not Applicable” under the heading. 4. All documents must be compliant with Section 508 requirements. 5. Figure captions and descriptions are to be placed left-aligned, below the figure. All figures must have an associated tag providing appropriate alternative text for Section 508 compliance. 6. Delete this “Notes to the Author / Template Instructions” page and all instructions to the author before finalizing the initial draft of the document. Appendix H: XLC Template Revision History The following table records information regarding changes made to the XLC template over time. This table is for use by the XLC Steering Committee only. To provide information about the controlling and tracking of this artifact, please refer to the Record of Changes section of this document. Table 6 - XLC Template Revision History Version Number Date Author/Owner Description of Change 1.0 05/15/2011 Celia Shaunessy, CMS/OIS/DITG Baseline document 2.0 08/06/2014 Celia Shaunessy, CMS/OIS/DITG Changes made per CR 14-012 2.1 02/02/2015 Surya Potu, CMS/OEI/DPPIG Updated CMS logo 3.0 10/13/2015 CMS Updated template style sheet for Section 508 compliance Added Acronym column to Table 3 Glossary Reformatted Table 5 - Approvals in Appendix F: Approvals for Section 508 compliance Appendix I: Additional Appendices Instructions: Utilize additional appendices to facilitate ease of use and maintenance of the document.