Tutorial on Database Schema - Slide 6 - Pay the Bill in Starbucks
Back Next Slide
- Pay the Bill
- Order Coffee and Something to Eat
- Finally Pay for it.
- 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.
- 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 is important, because it occurs in virtually every Database Schema in the real world.
- 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