Results 1 to 15 of 15

Thread: Er diagram!!!!

  1. #1
    Join Date
    Sep 2008
    Posts
    29

    Er diagram!!!!

    How can I Build an ER diagram for the following scenario:

    CSale is a trading company. Today, the company wishes to create a database to control the transaction between buyer, vendor and inventories. A vendor can supply one or more products to CSale Company. For each product, the company records the productID, name, quantity, and the vendor that supplied such product. A customer can place one or more orders, with each order for
    one or more products. Each order gives rise to one invoice, which can be paid by a number of methods, such as check, credit card, or cash. The name of the employee who initially processes the customer order is recorded.

    I know that I should have 4 tables ( CSale,vendor, buyer and inventories)
    Csale attributes are (productID,name,quantity, Vendor_name)
    as for the rest am kindda lost...help???

  2. #2
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    you do not need a table for the company itself, there would be only one row

    and maybe you need a table for customers?

    when is this assignment due?
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  3. #3
    Join Date
    Sep 2008
    Posts
    29
    Its due today actually ......
    I dont need a table for the company??...
    aren't the buyers are the same as customers?

  4. #4
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    Quote Originally Posted by Pearl_89 View Post
    I dont need a table for the company??...
    i don't think so


    Quote Originally Posted by Pearl_89 View Post
    aren't the buyers are the same as customers?
    probably
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  5. #5
    Join Date
    Sep 2008
    Posts
    29
    ok...any idea how it should look like?

  6. #6
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    Quote Originally Posted by Pearl_89 View Post
    ok...any idea how it should look like?
    boxes for the entities, lines joining the boxes for the relationships, and vwalah, an entity-relationship diagram!!

    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  7. #7
    Join Date
    Sep 2008
    Posts
    29
    um...ok...obviously that's how its suppose to look like....how else should it be??....I was asking about the DETAILED information's...but thanks anyway

  8. #8
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    you were asking me to do the assignment for you, and i'm not going to do that

    however, if you post your diagram, i'd be happy to look at it
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  9. #9
    Join Date
    Sep 2008
    Posts
    29
    I guess you miss understood me...I wasn't asking anyone to do it for me....I was only asking for help... I'm not sure if you read what I wrote correctly but i did write the word HELP at the end didn't I??....

    anyways thanks though....am not sure what I did was 100% right but am sure that its 100% my work

  10. #10
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    That's good... Even the "experts" can't be 100 percent certain they are correct (only fools can do that).

    Turning in your own work is incredibly important. At least in my opinion, schools don't stress integrity nearly enough. I work with a crew of IT consultants for a very large company, and there is zero tolerance for integrity issues... If we can't trust you with our children, you probably won't be here tomorrow.

    I'd recommend two things when you're looking for help here. First of all, show us what you've done... We see all too many students looking for someone to do their homework for them, so we've got a really jaded outlook and a pretty good sense for when we're being played. If you put forth what you've done so far we can see that you've put some work into the problem already, and more important than that we can see what misteaks (!!!) you've made and can help you understand points that aren't clear to you. The second thing is kind of obvious, but don't wait quite so long to ask for help. We don't live on DBForums, so you don't always get a quick (or even correct) response... Online communities take a while to work, so hitting them at the last moment is very risky.

    Anywho, welcome to DBForums!

    -PatP
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

  11. #11
    Join Date
    Sep 2008
    Posts
    29
    Thank you for the advice.....hopefully next time I wont forget to post what I did exactly...as for the asking help earlier I don't usually ask help online am still new to the idea...so once again thanks for the advice.


    Even though I have already submitted the assignment....I would still love to know what are my mistakes... this is what I came up with
    Attached Thumbnails Attached Thumbnails Untitled.png  

  12. #12
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    I won't be able to do much analysis for about ten hours or so, I'm working/travelling now.

    Without a copy of your assignment all I can do is offer a basic critique, I can't tell you whether or not you completed the assignment. It would help a bunch if you could include a URL, a scan, or at least a synopsis of the original assignment.

    -PatP
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

  13. #13
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    productID/Product_ID?
    Employee_ID/Emplyee_Name?
    Orde_ID/Order_ID?

    Some consistency in your naming convention would be good, and what's with the "_1" after each table?

    Plus, I detest splitting the product information into two tables...
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  14. #14
    Join Date
    Nov 2004
    Location
    on the wrong server
    Posts
    8,835
    buggers about naming conventions. I do not think he has met his requirements. His ERD looks like a Vebndor can only have 1 product and a buyer can only have 1 order.

    I would say you need a product table and that the order_id needs to come out of the Buyer table. It is already in CSALE which I believe is an "order".
    “If one brings so much courage to this world the world has to kill them or break them, so of course it kills them. The world breaks every one and afterward many are strong at the broken places. But those that will not break it kills. It kills the very good and the very gentle and the very brave impartially. If you are none of these you can be sure it will kill you too but there will be no special hurry.” Earnest Hemingway, A Farewell To Arms.

  15. #15
    Join Date
    May 2008
    Posts
    277
    Quote Originally Posted by Pearl_89 View Post
    I know that I should have 4 tables ( CSale,vendor, buyer and inventories)
    Actually, I'd say you'll have a lot more than that. Take a look at your own requirements:

    create a database to control the transaction between buyer, vendor and inventories. A vendor can supply one or more products to CSale Company. For each product, the company records the productID, name, quantity, and the vendor that supplied such product. A customer can place one or more orders, with each order for one or more products. Each order gives rise to one invoice, which can be paid by a number of methods, such as check, credit card, or cash. The name of the employee who initially processes the customer order is recorded.

    Everything in bold is a concept or entity you'll need to figure out what to do with. Not all of these will necessarily become a database table, but you'll have to consider each one.

    For instance: transaction and order seem to be two terms describing the same concept, so you can discard one. You mentioned inventory, but your only requirements are about managing products, so you may be able to discard this as well (or you're missing some requirements).

    After determining your entities, figure out the relationships between them. Don't forget that all relationships are two way. Consider vendors supply products. Given one vendor, how many products can it supply? Given one product, how many vendors can supply it? Or orders generate invoices. Given one order, how many invoices does it generate? Given one invoice, how many orders does it document? Many-to-many relationships will need an additional table to resolve them. One-to-one relationships can generally be combined into one table. And if you can't answer the question, you're missing a requirement.

    If you can get the hang of this process and apply it rigorously to your existing model, I think you may be surprised at the changes you come up with.

Posting Permissions

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