hi, and welcome to the forum
depending on the degree you feel you are out of your depth this may help with providing some ideas on what you are being asked to do.
one of the fundametnal principles of relationl design is to eliminate duplication of data. I've always found it easier to think of it in terms of what information can be logically grouped together without uneccesary duplication or repitition. Think of a table (or datastore) as a bucket which associated bits of data are grouped together. if there is a piece of data that doesn't belong int he bucket, then you proabbly need another bucket
on first glance you might want to store the model of skateboard alongside a customer - fine, unitll they customer comes back and buys another board, or more components. so what the customer details 'bucket' probably contians anything which is unique and identifiable to the customer (ie that customer will only ever have one of. so its going to include things like their name, address, cellphone, homephone & email) it wont contain detaiuls of what the cusotmer has bought because you would then be dupolicating the name, address etc.... some business applciaitons may require the address to be a separate bucket, as someone may have more than one address (eg home, school, vacation, work etc....), they may have more than one phone - but lets avoid such complication for this
so the next question is whewre do I store details of what the customer buys
well you need soemthing that identifies who the customer is (as names can be duplicated you need a simple reference to the custoemr, that uniquely identifies that custoemr, so we need to add a customer ID to our customer bucket, and copy that piece of information in the customers purchases
we need to know what they bought (item and quantity), possibly when they bought it, and possibly how much they paid.
so if we think in terms of a purchase, a customer can make several purchases at the same time
so we need a table that stores sales transactions that identiifies that uniquely identifies a specific sale (so we are probably gouing to store the date & time the sale toook place, the customer, the invoice number) etc....
we then need a sub table which stores the deatls that comprise that sale (eg the product, the quantity bought, the sales value)
so have a good read of Rudy's (R937) site and try to analyse which buckets you need to store sepcific pieces of infromation. start out with a pencil and paper, don't worry if you make any/many mistakes after all its the first data model you are doing and you are bound to go down some blind alleys.
I'd rather be riding on the Tiger 800 or the Norton