Results 1 to 4 of 4
  1. #1
    Join Date
    Mar 2012
    Posts
    2

    Database Design Help- Online Checkout

    For a database design course I had to come up with a database that I would design and then implement. I chose to do an online checkout.

    I already submitted my use cases to my professor and he thought they were good, but I'm not sure how I should start implementing them into a database.

    What table would you break this use case into? Would you make any changes to my current use cases?

    Use Cases

    Tables

    Thanks in advance!

  2. #2
    Join Date
    Feb 2012
    Posts
    76
    Don't start with tables. Start with the attributes/fields you need to support the use case - what do you need to about what? For example, contact info, billing info, shipping info are pretty vague. You could just store them as chunks of text, and I guess then you're done, but in actual use people usually want to query things by city or country or area, or produce lists of telephone numbers. Breaking the information up into pieces for which the possible values are clearly defined makes it much easier to work with later.

    When you know what you need to know, look at how the attributes are related. What depends on what? This will guide you in choosing which tables to build.

  3. #3
    Join Date
    Mar 2012
    Posts
    2
    Thanks for the reply. I sort of revised what I was doing after talking to my professor.

    New Tables

    The "shopping cart" table isn't done, but I'm not sure how I should do it and be able to show quanities. The only thing I can think of would be adding another table named "sku" with all the info. Is that alright or would you do it differently?

    Primary key is accountNumber for the "account" table, orderID for the "order table, not sure about the "shopping cart" table yet. Foreign key is "orderID".

  4. #4
    Join Date
    Feb 2012
    Posts
    76
    That looks better, though some normalization could be applied. An sku table could work for product information, but this one case where normalization isn't desired. Product description and pricing, though it has to come from somewhere like an sku table, should not be updated as the current list changes. Perhaps also add a field for the ordered quantity.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •