Inventory Management DB Design
There are some things you want to think about based on the nature of your items and how you store and track them.

Are your items discrete or are they a commodity?  The way you would track television sets, each of which has its own distinct serial number is different from how you might track boxes of nails.  If your SKUs are discrete you don't have a "quantity" field, instead you track individual items with an intersection table (as suggested by Joe).  Otherwise whether you need an intersection table depends on how many different SKUs can be on a shelf (see below).

Is it important to track inventory movements?  Do you need to see stock deliveries and shipments?  If so you might want to take a kind of double entry accounting approach, treating shelves like GL numbers.  If not, a simpler quantity per shelf may be sufficient.

Can multiple SKUs share a shelf?  If so, you need an intersection table.  If not, you can get by with a foreign key from Shelf to Item.

Does every bin have at least one shelf?  Your application (queries) will be much simpler if every bin has at least one shelf, such that you don't need to track inventory which is in a bin but has no applicable shelf information.



EDIT:

It's important to get the terminology clear. When you say "bin" you mean a box without a lid that sits on a shelf. In a lot of inventory situations, a "bin" is a space on a rack where you could put a skid or one or more shelves. 

As long as we're clear, you want a hierarchy of SHELVES each of which has many BINS each of which can have many BIN_CONTENTS each of which is an intersection between BIN and ITEM and which has a quantity. Don't store quantity on your ITEM table, store it on the intersection table, that way you can have multiple bins of the same item, or even many different kinds of items, each in their own distinct bins or even multiple different items mixed within a bin, all on the same shelf.

Consider the following ERD: