The Zen approach to designing a business system

Part 3: Modeling—Use Cases/Business Scenarios

Here comes Julie again. She is trying to automate her entire Bakery Cakes-&-Kisses (which makes yummy cakes for weddings and special occasions). From age-old pen-and-paper methods, they are moving all their business processes to Zoho Creator, an online cloud business application maker. Join us on our journey with Julie as she marches ahead.

A bit of an introduction before we move on. (If you’d missed them, here are parts one and two.)

So Julie designed this system with long forms and a lot of data duplication. She realized it is soon becoming messy. So she sought the help of an expert business consultant Natasha to get things sorted out. Natasha helps Julie model her business system. In the previous post, we saw how Julie comes up with entities and relationships for her business system.

Now, that’s not complete. If you had followed it through and tried the same for your business, then using that approach, you would have by now identified most of the entities needed to model your system. But there are usually gaps left after this step is complete. We need to fill in those with the next step which is to identify and chart out the use cases for the system.


It is advisable to take the most general, common use case as the first one. Here it is the use case of customer ordering a cake. Let’s visualize this scenario for a moment.

The customer comes in. Looks at the various cake flavors, decorations and other options you have, compares the pricing and then decides on what to go ahead with. Then he places an order, and optionally makes a payment, and then leaves the shop. So several things (think ‘entities’) that emerge from what we have just said are listed below:

  1. Customer
  2. Cake
  3. Cake options
  4. Payment
  5. Staff

Let’s make what we call an entity-relationship diagram (also called, ER Diagram) from these. Without getting into too much technical stuff, and to keep it really simple, I will refrain from bringing in too much geeky stuff. Instead, we will draw a simple diagram which will show what are the different entities involved and how they are related to each other. First, let’s draw each entity separately, before we look into the relationships between them.

We already looked at this in detail in the previous blog post. The ‘Customer ID’ is a serial number generated automatically just to uniquely track each customer.

Also if you recollect, you will notice that we missed some entities (which we separated owing to their nature of being changeable or unchangeable). What are those missing entities?

  1. Customer Address Book
  2. Customer Performance Measures

Let’s add them now.

Again, note how we separated the changeable and unchangeable attributes into separate tables, though all of them relate to one single entity ‘customer’.

Let’s move on to the next one ‘Cake’. This is a little tricky because we need to first have some items on the menu before we can order them. So we need to first feed in our menu into the database. This means that we need to have details like the possible flavors of the cake, the list of decorations, and the toppings in the database even before any customer can actually place an order. So let’s first draw those entities.

As you can notice above, we don’t have an entity named ‘Cake’ as such. Instead, we have entities for flavors, decorations and toppings. This is because a cake is a dynamic combination of some of these, but doesn’t exist physically until it is created for a specific order. Hope this makes sense.

Let’s think of how a ‘Customer’ relates to a ‘Cake’. Of course, through an ‘Order’ i.e. when a Customer places an Order for a specific Cake. Now let’s design the entity ‘Order’.

Note how ‘Order’ has been separated from ‘Cake in Order’. This is because ‘Cake’ is actually a whole physical entity which is composed of parts like flavor, decorations, etc.

Did you see those single and double asterisk marks next to some of the entity details? Let me explain what they denote. Single asterisk is used to denote that the value is unique in that table. For example, ‘Order ID’ is unique in the ‘Order’ table/entity for every Order ; meaning no two Orders can have the same Order ID value. Now consider the double asterisk symbol. It also denotes a value which is in a table different from the one in which it is mentioned. For example, in the image above, ‘Customer ID’ has a double asterisk in the ‘List of Orders’ table/entity. What this means is that ‘Customer ID’ is a value referenced from another entity, in this case, the ‘Customer’ entity. I have used the terms ‘table’ and ‘entity’ interchangeably in this blog post intentionally. A table is an entity (like the entity ‘Order’). But an entity may not be a table (as is the case with the entity ‘Cake’ above).

Now that we have drawn some entities, let’s try to map the relationships between them. Here is a mapping of the relationships between the Customer-related entities.

And below is the mapping between the Cake related entities.

And now onto the Order entity and its related ones.

Now here’s a very interesting relationship. Can you guess why ‘Cakes in Orders’ is separated from ‘List of Orders’? One main reason is that one Order may have multiple cakes in it. So this is called a one-to-many relationship/mapping.

After mapping everything that we have right now, this is how it looks so far.

No, it is not over yet! But we can end this blog post here for the sake of brevity, and continue in the next one. But before we end this discussion, I would like to tickle your brain a bit. What is really disturbing and odd about the ‘List of Orders’ table you see below?

Keep thinking, and see you in the next post with the answer!

This is a guest post by Priya.Sri, a Zoho expert. Passionate about the ways in which software and automation help achieve in the real world, and in making businesses more productive, she publishes articles about best practices for businesses. She has been designing and implementing custom business workflows/apps for small and medium businesses for four years, and brings with her a rich experience of about 15 years in the software industry. For more information, contact