Dennis,

It's good to question your structure, because that it the foundation for
everything else. But defining your structure well requires an understanding
of the real-world process that you want to database, and the mission(s) that
you want the database to accomplish. From your post, it looks like you have
put a lot of goo thought into that area. However, since you have not
informed us enough on real-world process that you want to database, and the
mission(s) that you want the database to accomplish, we can't really review
your structure for you.

So, if you want us to analyze it, you'll need to tell us the above. If you
prefer to analyze it yourself, you might start by making a list of the
prospective entities to database. You might start those of your listed
tables:


- Work Orders
- whatever entity that second table is
- Work Order Details
- Expense Reports
- Expense Report Details

And consider a few other possible entities:

Invoices
Customers
Employees


You'll have to decide whether or not invoices are an entity (which heavy
duty systems treat them as) or not (which is how all 100% of the Access
examples I've seen treat them)

Make sure all of the data in each table is of "one-to-one" type with it's
entity. If not, split it.

See if the entities in any two tables are in a pure one-to-one relationship
with each other. If so, combine them into one table.

Well, there a few thoughts. Good luck.