I really hope this is the ideal way to be creating this database.
Far from it. You should be developing a scope of work on paper after identifying what are the inputs and desired outputs for the processes involved and get agreement on that. If the employer knows what these are, great. If not, you use your db design knowledge to flush them out. These discussions should indicate to you what information (note I didn't say data) is required to support what's desired. Only then do you consider what tables and fields are required, what their data types should be and how to normalize the data as much as possible/practical. That you are altering tables in such a fashion leads me to think that neither you or the client understand where this should be going. I would not involve them in the design beyond a scenario where I might explain the benefits of one method over another if the choice added considerable design time.
Not until then would I create any tables and their relationships. Looking at the relationship diagram, I would test the design in my mind with scenarios based on the process that I had better understand by now. This would take the form of, if A happens then B but not C can I get D out of this? Can I get this, that and the other? Rather simplistic description, but hope you get the idea. You should also vet the relationships by checking them against any desired outputs such as, can I produce the reports they asked for? Only then would I dump in or create test data and build queries (not forms or reports) and attempt to assemble the data for the requirements that have been identified. If you cannot, there is something wrong with, or something missing from your table design. I would not create forms or reports until the queries were giving me what I need.
I have also created relationships on large sheets of paper when it seemed easier to erase connections or add/move fields around for large or complicated projects.
For table design, I found Excel useful for laying out table fields in rows and properties in columns, since there are so many property possibilities. It helps to coordinate a field data type and any limitations (length, allow Nulls, indexed, etc.) between the parent and any related tables.
Hope some of that helps.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.