Tutorial on Database Schema - Slide 6 - Pay the Bill in Starbucks

Back   Next Slide

  1. Pay the Bill
    • Enter Starbucks
    • Order Coffee and Something to Eat
    • Finally Pay for it.
Customer places an Order

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