Reviewing customer requirements

It is very important to note that this is not a book on software design or application architecture. Rather, our focus is on developing a useful set of classes that allow you to gain database access regardless of which Python framework you are using. In this section, we cover how to come up with a good database design based on customer requirements.

Introducing Sweets Complete Inc.

Sweets Complete Inc. is a fictitious company representing small enterprises that sell products online. They sell specialized confections, including cake, candy, and donuts, to an international clientele. People who use their website fall into one of four groups, each with different needs:

• Casual website visitors: This group consists of people who happened upon the site through word of mouth, search engines, and links from associated sites. They generally want to get information about the products on offer, and will hopefully be enticed to make a purchase and become a member.
• Members: Members are regular individual customers and partners who sell their products (for example, 7-Eleven). They do not need to be sold on the products. They mainly want to set up recurring purchases and check on the status of their orders.
• Administrative staff: Staff need to set up member accounts, manage the list of products, and generate sales reports for management.
• Management: Often, Sweets Complete employees who work in a managerial role do not need direct access to the data, relying instead upon reports issued by their staff; however, increasingly, managers want direct access and quick reports.

Sweets Complete will be our example company for this part of the book. Let's now dive into what we need to know to produce a solid database design.

What data comes out of the application?

As you review customer requirements, one of the first things you need to ascertain is what information is the application expected to produce? This is referred to as the output and can take many forms and encompass many different technologies. Some examples of the output include the following:

• Printed reports
• Charts and graphs
• A list of products on a web page
• Data produced in response to a representational state transfer (REST) request
• Output appearing on the screen of an app running on a smart device (for example, a tablet, or mobile phone)

The data required to satisfy these various forms of response will often be grouped in a certain logical manner, which will lead you to the database document structures definition. Different groups of users have different requirements for output:

What data goes into the application?

Continuing your review, the next piece of information you might consider is what information goes into the application. As with outputs, inputs to your application can take many forms, including the following:

• HTML forms
• Data obtained from external web services (for example, Google Maps)
• Streaming data (for example, the real-time location of warehouse workers)

It is useful to examine what form of input to expect from members of the different groups outlined in the previous section. Here is an example of what activities each group might perform to produce inputs:

Once you have determined the outputs (described in the previous subsection) that the application is expected to produce, you then have an idea of what data needs to go into the system. At first glance, it would seem logical to conclude that for every piece of output data, there needs to be a corresponding input source. For example, if one of the printed reports includes a list of product titles, somehow that information needs to be entered into the system.

In some cases, however, this theory does not hold true: your application might massage input data to produce the desired output. Not all inputs will appear directly as outputs and vice versa. For example, if the printed report is expected to produce a total for each customer purchase, this total does not need to be entered manually by an administrative assistant. Instead, the totals are calculated from the product price and quantity purchased, along with any other fees and taxes that might apply.

One simple technique is to visualize customer requirements, as illustrated in the following diagram:

Imagine placing all the inputs on the left and all the outputs on the right. The difference between the two is produced by the application software.

What needs to be stored?

So, at last, we arrive at the big question: what needs to be stored in our database? You might be tempted to go with the simple answer: everything. A lot depends on how many unique individual data items we deal with and how many of each can we expect. Your initial tendency might be to take the easy route and just store everything: storage is cheap, and a MongoDB installation can be scaled up easily through the process of sharding.

It is in your interest to economize, however, if for no other reason than to avoid having the database engine clogged up with massive amounts of unneeded data. Also, no matter how cheap it is, there will be only so many times management will grant your request for a purchase order to buy more storage! Furthermore, the less data your application needs to sort through, the more efficient it will be.

So, to answer the question, you should store any data items that cannot be generated from existing information. This means that the cost of a product and the quantity of items that are purchased needs to be stored. The extended price of a purchase does not need to be stored, however, as it can be easily generated from the quantity and price. Other items that need to be stored are identifying information, such as transaction numbers, purchase dates, and so forth.

A quick word on software design

Although we are not trying to teach you software design, it might be worth noting that Martin Fowler, a very influential thinker in the IT world, had this to say:

In this book, we will not go over software design patterns, but encourage you to have an awareness of these patterns. In an absolutely shameless plug, here are two good books on that subject from Packt Publishing:

• Architectural Patterns, by Pethuru Raj, Anupama Raman, and Harihara Subramanian
  (https://www.packtpub.com/application-development/architectural-patterns)
• Learning Python Design Patterns: Second Edition, by Chetan Giridhar
  (https://www.packtpub.com/application-development/learning-python-design-patterns-second-edition)

You could also, of course, read Martin Fowler's famous book, Patterns of Enterprise Application Architecture (https://martinfowler.com/books/eaa.html).