The goal of good database design should be to provide a solution to real world problem. In order to create a solution though, you first need to to understand the problem at a granular level.

One approach that I like to take:

• Break down tasks users perform
• Ensure you have the data needed for those tasks

Keep in mind:

•Understanding a problem involves looking at both the input and output tasks

•The data model goes hand in hand with the use cases

•Continue to re-evaluate whether the data model can handle the input and output use cases

•Most of the time, users won’t have this readily available and it needs to come through discussion

•Users can be very narrowly focused, it’s your job as the designer not to be

Let’s imagine an example of a meal delivery service where people call in to a receptionist who takes the order and dispatches drivers to delivery the meals

We need to figure out:

1.Who are the users?

2.What tasks do they do?

3.What data is needed?

---

First make sure you understand the process:

Users and Tasks:

•Visitor calls the company

•Receptionist takes the order

•Receptionist selects/assigns a driver

•Receptionist gives order to the driver

•Driver picks up meals

•Driver delivers meals

•Visitor pays the driver

•Driver informs the company

•Receptionist records the completed order

•Driver maintains timesheet

---

Then decide what tasks our system will be involved with?

Users and Tasks:

•Visitor calls the company (probably not)

•Receptionist takes the order (yes – need to record some details)

•Receptionist selects/assigns a driver (yes – need to see who is available)

•Receptionist gives order to the driver (yes – need to be able to see the order details)

•Driver picks up meals (maybe – do we need to keep track of time of pickup?)

•Driver delivers meals (maybe – do we need to keep track of delivery time?)

•Visitor pays the driver (probably not)

•Driver informs the company (maybe – is the driver entering details himself or calling?)

•Receptionist records the completed order (yes)

•Driver maintains timesheet (yes)

---

Then we can create some basic tables and relationships based on this imformation above

The Driver and Order interact as the driver needs to get an order to deliver, and the driver and timesheet interact as the driver needs to fill in the time sheet, but the Timesheet and Order do not interact though, so there is no relationship there.

Next, we can fill in some attributes

This basic model above should meet the needs of the use case described

Sample of steps to take when working through the analysis phase:

•What does the user do?

•What data is involved in the user’s jobs?

•What is the main objective of the system?

•What data is needed to satisfy the main objective?

•What are the input use cases?

•What is the data model? 

•Can it handle everything so far?

•What are the output use cases?

•Can the data model provide everything so far?

Back to Main Course Page: Course