In the abstract, there is no substitute for identifying the function of each existing element and "peeling the onion" one layer at a time.
However, check for the chance that someone left around documentation. (Yeah, I know that's a forlorn hope...)
What you have is NOT a trivial problem. Understanding data flow means (among other things) that you had better know a LOT about the problem attacked by the database. If you are a novice to the problem being solved, you have a long road ahead of you.
My advice is a big pack of sticky notes and a big dry-erase board. Then for each entity in the DB, make a note on a sticky sheet. As you identify each item, you will see that (for example) a query depends on one or more tables. Draw lines linking tables to the query. You will see that a form uses some query as its dataset. Draw more linking lines. You MIGHT find a switchboard form (not bound to a table) that activates one or more forms, reports, or code sequences. Draw more linking lines.
Eventually you would see the relationships among the major components. But I do not envy you the task of deconvoluting a broken database. I did that once. Took me literally three months to finish deconvoluting it to the point where I felt confident enough to fix anything. Good luck!