Best design for table layout

[tagteam]

I am moving my company from an Approach database to Access. Right now everything is basically in one table in the approach database. I am trying to decide how far to break down the data into separate tables.
I deal with railcars and each railcar has attributes, tests and repairs but also has to be assigned to a customer for a certain period of time.
I was thinkg of doing the following:
Railcar table - basic railcar info
Test table - all the possible tests
Repair table - all the repairs


assignement table - information about that lease period
customer table - basic customer information

One of my main concerns is that if I break the tables down too much it becomes too difficult to update things. For example railcars can have several different types of attributes. if i make an extra attributes table it will be more difficult to update or change the attributes by just clicking on a dropdown or something.

I am not really sure if I am getting my question explained properly. I suppose basically I am wondering how "Normalized" I should make the database and if I break it down to too many tables will it be difficult to do simple updates and queries?
Thanks for any help

[orange]

I don't think it's a separate decision to identify how many tables to make/design/build.
If you forget Access and Approach for a minute and look at this tutorial, I'm sure you'll
see what I'm talking about. You can't arbitrarily say -- I'm going to build a database with 4 tables.

Well, I guess you could say that, but look a the tutorial and see...

good luck

[tagteam]

Yes, you are correct. I have actually read that document and it was very helpful. I have several more tables but I did not want to bog down the thread with all of the details.
Basically I am looking for some advice from anyone who has built a database with a lot of tables (My current plan actually has closer to 15 table) and see if there is any downside to breaking down the relationships all the way.
For example it is difficult to create ad hoc reports when the tables are broken down so far because users dont understand how all the tables work together.
Thanks

[orange]

So give the users some canned reports.
Or give them a form(s) to select parameters to build the SQL behind the scenes and then a button to build the report based on the sql that was built behind the scenes.

see Martin green' site especially dynamic reports. His sql and vba tutorials are thorough.

The users should not have to be aware of how many tables are involved.