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???

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?

Its due today actually ......
I dont need a table for the company??...
aren't the buyers are the same as customers?

i don't think so


probably

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!!

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

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

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

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

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

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

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...

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".

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.