Access 2003 db design help

[crater]

I have been trying to create a DB that will hold info on the windows the we have to offer in our bussiness and then incorperate it with a VB form but i AM Having a **** of a time trying to figure out the design of the DB. So far I have a cluttered mess witch I think could be staightened out with using fewer tabels? the relationship thing has blew my mind.

What I think it should look like:
I need a table named MODELS with field named ModelID , Model Name
a table named GLASS OPTIONS with fields named GlassID , Glass Option
a table named UNITED INCHES with fields named UiID , United Inches
a table named LIST with fields named ListID , List

What I'm haveing trouble comperhending is: Do I really need a table for each record in the model table with the model name,United Inches and List as fields
I know that it should be able to be done using lookup cells(IE: the lookup would point to the other tables) however I don't see how it would work with the VB app.
The Model table would contain 3 records-->Allure,Contour,Enhancement
Glass Option table 3 records-->ProPlus,SolarPro,SeasonPro
United Inches table 4 records-->0-83,84-93,94-101,over 101 add
and List table --->$100,$200,$300
The List price should change according to the record choosenin the tables Model,Model type(ie: single hung,double hung ect.)Glass option, and United Inches
I know the Select statement will retrieve the info I need however I need a good place to start first(good design) witch I haven't been able to come up with so far on my own.
ANY help would be soooo appreciated
Thanks
Crater

[jp140768]

I don't know anything about Windows - well your Windows, but I would generally start off at the highest level eg the completed product, and then break it down into its common components, eg in your case what type of glazing.

So I would have a table, that gives me information about the window, and sub tables which give me a description of the common attributes.

The common attribute tables have a primary key, which I normally make an auto number or Identity type field. The main table then sets up a foreign key to these sub tables.

What you are trying to avoid is having to key the same information multiple times.

Eg your VB application, when asking you to enter your window specs, may have combo boxes set up with the results from the sub tables, and you click on an entry, the item data property of this box (the primary key), is then written to your main table. It saves you have to type double glazing multiple times.

I hope this is of some use to you.

[Hack]

I think that starting off with a Models table is a good start.

Now, the next question is how many of your other tables need to relate to that Models table? For those that do, ensure there is a ModelsId field in them which you can use to relate back to the Models table.

What other type of requirements do you have?

[crater]

well I think that all the tabels would be related to the model
IE: List = model+modeltype+glasspack+unitedinches

I have a screenshot of my tabels and the relationship(????) as they exist now, as you can see I think there should be a better way of storeing this info (as in subdatasheets)

I really have no idea about the relationships or if there correct?