Lesson 1

Earlier in this course, we took a brief look at the stages of the database lifecycle (DBLC). This module examines the critically important first stage in the database lifecycle which is Requirements Analysis.

• Requirements Analysis.
  Requirements Analysis is the stage in the design cycle when you find out everything you can about the data the client needs to store in the database and the conditions under which that data needs to be accessed. Keep in mind, too, that a single pass through this stage rarely yields all the information the database designer needs. Be prepared to return to the tasks associated with Requirements Analysis several times during the course of designing a database.
• Learning Objectives for Module 4
  After completing 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 of 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
  
  A DBMS is viewed not so much as a good thing in its own right, but more as a means of overcoming the problems of shared data. A data model can be designed in a "bottom-up" direction by applying normalisation techniques to the data items (attributes).

1. What are your impressions of the case study?
   • The case study paints a picture of a small, family-owned business that’s hit a classic growth snag.
   • Bob and Jane Martin started with a simple vision, which is selling children’s audio CDs and it has clearly taken off, with a mix of in-store and mail-order sales peaking during predictable busy seasons.
   • Ted’s original database was a decent first stab for a fledgling operation, but it’s buckling under the weight of expansion.
   • Duplicate data and messy deletions scream “normalization issues”, which is a common headache when a flat-file system outlives its usefulness.
   • The Martins are smart to bring in a pro to build a relational database—they’ve got a solid foundation but need a scalable solution to match their ambition.
2. Do the requirements of Stories on CD, Inc. seem complicated?
   • Not really—on the surface, their needs are pretty straightforward for a retail business.
   • They’re tracking customers, orders, products (CDs), and distributors, with some basic sales incentives and marketing thrown in.
   • The complexity creeps in with the quirks: storing potential customers who haven’t bought anything, managing distributor info that’s currently stuck on Rolodex cards, and handling brochure content like CD descriptions.
   • It’s not rocket science, but it’s enough to trip up a simple system if not structured right.
   • Multiple passes through requirements analysis, as you mentioned earlier, will be key to nailing down the details—like how they define “potential” customers or what distributor data really matters.
3. Do you have any initial ideas regarding what kinds of data they are likely to want to store and retrieve?
   • Customers: They will need a table for customer details, customer number, first/last name, address (street, city, state, zip), phone, and maybe a flag for “potential” vs. “actual” customers since they track both. They might also want order history tied to each customer.
   • Orders: An orders table seems obvious, order number, customer number (linked to the customer table), order date, CD number, price (with that 40% discount applied), and shipping status. Mail-order vs. in-store could be a field too, given the 70/30 split.
   • Products (CDs): A table for CDs: CD number, title, age group (4–6, 7–10, 11–14), retail price, discounted price, and maybe a short description for those brochures. Stock levels could be useful too, especially with seasonal spikes.
   • Distributors: Since they’re moving from Rolodex to digital, a distributors table: name, contact info (phone, address), and maybe a unique ID. They only use U.S. distributors, so no need for international fields.
   • Brochures/Marketing: They might want a table for brochure campaigns: date sent, CDs featured, and descriptions—to track what’s promoted when.
   • They’ll likely want to retrieve stuff like: sales by season, top CDs per age group, customer order trends, or which potential customers to target next. A relational setup with proper keys (e.g., customer number, CD number) will make those queries smooth.
4. Do you have any experience with businesses of this kind, either as owner/operator, employee, or database-design consultant?
   • I’ve analyzed countless scenarios where small businesses outgrow their starter systems, and I can draw on patterns from those.
   • Think of me as a consultant who’s seen it all through data and case studies.
   • I wouldapproach this like I would any retail client: listen hard, map the data flows, and build something that grows with them.

Collecting data is relatively easy, but turning raw information into something useful requires that you know how to extract precisely what you need. In this module, intermediate to experienced programmers interested in data analysis will learn techniques for working with data in a business environment. You will learn how to look at data to discover what it contains, how to capture those ideas in conceptual models, and then feed your understanding back into the organization through business plans, metrics dashboards, and other applications. Along the way, you will experiment with concepts through hands-on exercises at various points in the moule.

1. Use graphics to describe data with one, two, or dozens of variables
2. Develop conceptual models using back-of-the-envelope calculations, as well as scaling and probability arguments
3. Mine data with computationally intensive methods such as simulation and clustering
4. Make your conclusions understandable through reports, dashboards, and other metrics programs
5. Understand financial calculations, including the time value of money
6. Use dimensionality reduction techniques or predictive analytics to conquer challenging data analysis situations
7. Become familiar with different open source programming environments for data analysis

The next lesson explains the overall purpose of Requirements Analysis.