Thank you for your post.
There are a number of third-party FileMaker Pro books. You can perform web search using your favorite web search engine.
This forum is just over a year old, and there are other FileMaker forums. One that comes immediately to mind is FMForums.com, and that forum has some more advanced topics.
If you are having trouble with any concept, feel free to post a question here or any other forum, and someone should reply.
A few observations that may help you with that initial learning curve:
Filemaker "grew" out of a flat file "anyone can use it" DB into an RDMS system of one table per file and from there grew into the multi-table per file system they sell today. Sometimes that past legacy shows in how Filemaker does things.
Filemaker was not originally designed so that users/developers could use SQL expressions to query the database as the standard day in day out process for generating record sets of data to manipulate. (Filemaker has been upgraded so that SQL queries can be performed on DBs using ODBC, but that's not the typical, "just working with Filemaker" approach.) Instead, Filemaker uses a layout dependent approach where example criteria (with logical operators and wild cards) are entered in specific fields while the layout is in a special "Find" mode. This makes simple queries simple, but can make designing complex queries a bit more challenging than simply constructing an SQL statement.
Filemaker tries to remain accessible to neophyte users with limited knowledge/education about relational database design and/or computer programming. This results in a modular, point and click interface for a lot of design functions such as creating a layout or designing a script. This can make it easy to get started, but in some cases it can be limiting in ways that systems with full up text based script editors are not.
I've described this key difference to others with the following analogy:
If Filemaker were a system for creating buildings, FMP is a system where you select various building modules and assemble them to create a finished building. As long as you have a module for every requirement, your building goes up rapidly and you have a happy customer.
Most other DB systems are more a "build it starting with boards and bricks" approach. This approach usually takes more hours of development and can result in sharply higher development costs. It also is more likely to require experts to create even simple "buildings". On the other hand, in cases where "there's no module for that" in the filemaker system, the "brick and board" systems have a good chance of being able to produce what Filemaker cannot.
Having a similar background to yourself I can see where you are coming from and finding FMP confusing.
In short you can take this approach with FMP, however you will of course not have SQL access. In place of SQL you would use Table Occurrences (on the relationship graph) and summary fields. You would access the summary field data through a 1-many relationship from the 1 side, there by allowing you to update a field in the 1-side, or in another table. You would also use Find mode or even global fields as the foreign key in the details table to identify the records to be updated by batch, ie for a specific month, quarter, year, etc.