Entity Relationship Diagram (E-R Diagram)

[snoofer]

I am very, very new to Access and d-base systems (you will see why) so please bear with me. I am trying to design an inventory d-base for a mobile food catering service (Roach Coach), but I am having prob's with the E-R Diag. So far I've created a list for future tables such as:

Inventory: hamburger buns, lettuce, plates - - -

Vendor: Sam's Club, Pepsi, Franks Bakery - - -

Misc: qty., unit price, expiration date - - -


- - - and so on.

My ER diag:

Caterer's Name

Menu

Ingriedients

Vendors

I know this cannot be the ERD alone, Do I need to include all the Inventory, Vendor, and Misc items in my Diagram, or what am I doing/not doing wrong?
I really need help (in more ways than one)!
Thanks.

 

[Cosmos75]

Do you get all you inventory items from seperate vendors? I.e., is it possible for you to one day buy hamburger buns from one vender and then another the next time?

You could create a table for items that you buy (Buns, Hot Dogs, Plates...)

Another table for vendors (i.e. people you buy from).

Then have a junction table that store the key from both the above mentioned tables to store quantity, price, date purchased, expiration date.

So, we have

1) Many-to-One from Items to Junction
2) Many-to-One from vVendors to Junction
Thus, creating a psuedo many-to-many from Items and Vendor (to handle the fact that you could possible buy lettuce from more than one vendor)

Are you just tracking items bought or also who the catering company is catering for? I don't inderstand what the field menu is for? Try to create a list of all the fields you want in your database and what you want to track with you database, what information you want to be able to extract from you database (e.g. How much lettuce did we purchance between 01/01/2002 and 06/30/2002? What's the highest price we've paid for plates?)

Post back with more info and I'll try to help some more!

 

[Adrianna]

Hmm...I think that you might be going about all of this in the wrong frame of mind. I'm assuming that you have a good idea of the user requirements?

You can either start from what the user wants the end product(s) to look like, or start from the elements that they want to track.

So..determine your starting point. You seem like you have many of the elements. Now figure out how they relate so that you can determine how to group data into tables, how the tables related, and determine what unique identifier you will be using. Remember that if you're not tracking data in a able...and only want a list....you have the option to use listboxes and comboboxes using list values! This will prevent you from getting frustrated with additional tables and links that are not really needed.

If you work something up and want to send it to me for comment, I will be more then happy to look over it for you...make some changes and suggestion.

Good Luck!

 

[Cosmos75]

I concur with Adrianna (or was Adrianna refeing to me?), I am still not all that sure as to what you are trying to track. If you could

1) tell us what you what to do
2) what fields (data) you want to store and keep track of in the database
3) what do you want to do with the data? What reports do you want to generate (what information do you want to be able to extract from you database)?