No, there is no typo, in order to avoid the 'alligators in the pond', I layered the views. This keeps me from hitting the too many joins wall. Care must be used though to limit the view fields to only those that are updateable. In most cases only one or two tables are being updated at a time, so as well as the 'normal' fields, you need to include the foriegn key fields from the updateable parent tables. The child data needs not be updated within the view. In the example, I started with pers_rank, which includes the text value for rank, and the rank_key field from pers, as updateable. Thus, even several layers higher up, a person can be promoted from private to coropral simply by updateing the field rank_key(via a lsit box populated with select rank_key, rank_name from rank).
It's an ugly work around, but to paraphrase a line from a book, 'while 3rd normal form is great from the DBA/dat efficency point of view, there are NO tools available to easily implement it at the interface level'
For more complex systems, it is probably better to use a more complex RDBMS. Sadly, we now only use VFP for quick, down and dirty single user apps, and do the rest of our db work in Oracle, which can have views as complex as needed, or even better, work with cursor objects that can handle complex update logic.