When defining a database, you must identify what you are tracking. Normally, when I say that, folks look at me askance. Except that you won't, because Geroge pointed out the bit about multiple batches per sales order. You already understand that you had failed to completely identify something that was being tracked.
Here is the way I do this: Before I write a line of code or design one field of the database, I take a design or requirements document to the nearest large white-board. Along with a case of sticky-note pads. For each requirement, I look at what will be needed to meet that goal. Where I decide a table is needed, I note the table on the board and populate it with a couple of example records via sticky notes.
When I have completely stepped through each requirement and made good notes, I have the beginnings of the design.
Here's an example:
I note that I will have sales orders. In order to track a sales order, I need a sales order number (and a place to store it), a customer to whom the sale was made (and a place to store customer data), and the details of the order such as a line-item table (and a place to store line-item data). The sales order and line-item are different but related, so I look for parent/child relationships. (Which in that case, I would find.) The details relate to a product or service I sell so I'll need a Sellables table to store that information. Sellables somehow relate to costs, but I need to know the problem intimately to tie that all together. For instance, do costs come strictly from components? There's a table for you. Do costs come strictly from labor? Different table. Do both time and materials contribute? That's TWO tables implied from the simple statement of having sales.
Now, if you take specific requirements into account to reflect your business rules, you find more things you need to either store or link together. Draw lines from your tables to show how they relate (which of course leads to action on the relationships window.)
This is the phase to be methodical. If you ain't methodical here, you are sunk. Not that there is ever a time to get really sloppy, but sometimes things get more sensitive than other times. Up front is the most critical because an error up front cascades its effect to the tail end of the process. Retrofitting an early mistake always costs more the longer you wait to fix it.