Tutorial on Database Schema - Slide 6 - Pay the Bill in Starbucks
Back Next Slide
- Pay the Bill
- Order Coffee and Something to Eat
Payments
Of course, we have to pay for what we have ordered before we get to consume it.
Fortunately, paying in Starbucks is quite straightforward.
In passing, let's note that the total price we have to pay is derived from the total cost of the individual items.
Customer Payment Methods
These will usually be Cash or Credit Card, and are shown in more detail in the next diagram.
Payments are simpler at Starbucks than Amazon.com, but our design is general and covers both.
Derived Data
The total price we have to pay is derived from the total cost of the individual items.
In a 'Normalised' Database Schema, we do not normally show derived fields, such as total figures.
This allows us to drill-down to the basic fundamental data.
We want to get to the point where we can't remove anything without losing meaning or value.
For this reason, I have shown the total price as a 'Derived' field, and called it 'der_order_price'.
One of the strengths of the Relational Database is that it strips away everything which is not fundamental.
Reference Data
Reference data is important, because it occurs in virtually every Database Schema in the real world.
Status
The status of an order in Starbucks usually changes so quickly that we don't need to keep track of it.
It is shown here to anticipate its use for Amazon.com, which is more complex, as we will see later.
The Status can be part of the Customer_Orders table, and take values from the 'Ref_Order_Status_Codes' table.
© DataBaseAnswers.org 2006