RelationalDBDesign RelationalDBDesign



Database Design   «Prev  Next»
Lesson 11

Database Requirements Analysis Conclusion

This module discussed the key tasks performed during Requirements Analysis. You discovered that, although these tasks are presented in a linear format that begins by examining an organization's existing database(s), the tasks can be performed in almost any order; several tasks are in fact performed in conjunction with each another. Documentation, especially, is a process the pervades every phase of Requirements Analysis. You also learned that Requirements Analysis involves determining the overall informational needs of an organization--both its current, and to some extent, future needs.

Topics covered in this module:

Now that you have completed the lessons in this module, you will be able to:
  1. Explain the purpose of Requirements Analysis
  2. Identify business objects and describe their characteristics
  3. Explain the importance of business rules
  4. Explain the purpose for interviewing users of data
  5. Explain the purpose of the data flow diagram
  6. List reasons for creating user views
  7. Describe the documents produced during Requirements Analysis

Glossary terms

This module introduced you to the following terms:
  1. attribute: A characteristic of an entity; data that identifies or describes an entity. Usually represented as a column in a table, attributes store data values.
  2. base table: A table stored in a database.
  3. business objects: Items in a business environment that are related, and about which data need to be stored (e.g., customers, products, orders, etc.)
  4. Business rules: A set of rules or conditions describing the business polices that apply to the data stored on a company databases.
  5. constraints: Rules a database designer imposes upon certain elements in a database to preserve data integrity.
  6. data flow diagram: A diagram illustrating the flow of data in an organization, including data sources, data storage, and data transformation processes.
  7. Data integrity: A term used to describe the quality (in terms of accuracy, consistency, and validity) of data in a database, in the sense that values required to enforce data relationships actually exist. Problems with data integrity occur when a value in one table that’s supposed to relate to a value in another cannot because the second value either has been deleted or was never entered.
  8. entity: A single stand-alone unit or a business object about which data are stored in a database; usually synonymous with a database table.
  9. logical schema: The overall logical plan of a database; typically a completed ER diagram.
  10. legacy database: Any type of database that has been in use by an organization for several years.
  11. paper-based database: Typically a filing system where data is stored on a variety of paper forms.
  12. requirements analysis: The stage in the database design cycle when designers find out everything they can about the data the client needs to store in the database and the conditions under which that data needs to be accessed.
  13. SQL: SQL is an acronym for Structured Query Language. It provides a set of commands that can be used to add data to a database, retrieve that data, and update it. SQL, often pronounced sequel, is universally supported by relational database vendors.
  14. virtual table: A table stored in the computer’s memory. Virtual tables themselves are not stored in the database; rather, the definition of the view is stored and given a name. Users call up that name, and the view is created (from base tables) on the fly. When a user closes the view, it "disappears" from memory, only to be recreated the next time its name is invoked.
  15. Yourdon/DeMarco: A popular style of data-flow diagram. It includes symbols that illustrate who handles the data in a database, where the data moves, where the data are stored, and what is done to the data.
The next module discusses entities (business objects) and attributes (characteristics of business objects). Understanding business objects as entities with attributes moves the designer a step closer to creating an entity-relationship (ER) diagram.

Requirements Analysis - Quiz

Before moving on to the next module, click the Quiz link below to test your understanding of Requirements Analysis.
Requirements Analysis - Quiz