If you have the option of a test environment, or can put in test data, it's easier to figure out what goes where by putting dummy data in the front end and looking to see where your dummy values end up in the database.
I usually start from an entity approach. For example, your customer. Once you figure out what your primary key for your entity is, you can start looking to see where that ID shows up in other tables to figure out what the relationships are.
Lookup values are always a fun one. We have one system that decided cities should be a lookup. It makes sense for the application because it has to store extended information about the city for what it does, but it threw me just a bit when the front end says the customer address is like 123 main street, Springfield MA, and the table data says 123 main street, 54 MA.
I regularly use a script that searches all fields in all tables in the database for specific text values. Sometimes that's the only way to track down some of these lookup values. Especially when you have the fun of a master lookup table. So that's TableID, LookupID, LookupValue.
A lot of it is just knowing how databases are supposed to be designed, and then hoping that the designer of the system followed normal design patterns.  Some of it is just luck as to how much hunting you're going to have to do.