Database Design Document
Table of Contents
1. Introduction 1 2. Overview 2 3. Literature Review 3 4. Assumptions/Constraints/Risks 4 4.1 Assumptions 4 4.2 Constraints 4 4.3 Risks 4 5. Design Decisions 5 5.1 Key Factors Influencing Design 5 5.2 Functional Design Decisions 5 5.3 Database Management System Decisions 5 5.4 Security and Privacy Design Decisions 6 5.5 Performance and Maintenance Design Decisions 6 6. Detailed Database Design 7 6.1 Data Software Objects and Resultant Data Structures 7 6.2 Database Management System Files 7 7. Database Administration and Monitoring 9 7.1 Roles and Responsibilities 9 7.2 System Information 9 7.2.1 Database Management System Configuration 9 7.2.2 Database Support Software 9 7.2.3 Security and Privacy 10 7.3 Performance Monitoring and Database Efficiency 10 7.3.1 Operational Implications 10 7.3.2 Data Transfer Requirements 10 7.3.3 Data Formats 10 7.4 Backup and Recovery 10 Appendix A: Suggested Appendices 11 Appendix B: Acronyms 12 Appendix C: Glossary 13 Appendix D: Additional Appendices 14
No table of figures entries found.
Table 2 – Acronyms 12 Table 3 – Glossary 13
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.
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.
Instructions: Provide summary of related work similar to the project. Your related work summary should capture the purpose for the project and the outcome/recommendations.
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.
Instructions: Describe any risks associated with the database design and proposed mitigation strategies.
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.
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.
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.
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.
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.
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.
6. Statement of Work
Instructions: The statement of work should specify the mission/goal and objectives for the design. Include the SOW from part 1 of your project here.
7. Requirements Analysis
Instructions: The requirements analysis should identify the system and user requirements for the system design. Include part 2 of your project here.
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 Entity Relationship Diagram (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.
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.
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.
Instructions: 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.
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.
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.
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.
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.
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 sub-schemas that will support security and privacy requirements.
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.
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.
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.
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.
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.
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.
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.
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.
Instructions: Utilize additional appendices to facilitate ease of use and maintenance of the document.