A global field is used for all records in the file and no relationship is required nor needed. A global table does not use a pk, there is no reason to link because it is available in all layouts.
There are cases where it is useful to use a global field as a match field in a relationship. In those cases, you need to put the global field in a specific table. In all other cases, you can put the global field in any table in your file and it will still be accessible from any layout, script and calculation in that file due to the specified global storage.
I believe what he may have been referring to is the idea of using a table with a single record to store "Global" (not actual global) fields. We use this method in almost all of our systems to store configuration settings such as a container field to store the main logo displayed on reports in the system.
These fields cannot be made global because the systems are almost always stored on filemaker server and as you know any changes made to a global field will be on a per-session basis and revert upon re-opening the file. Thus we store this in a table that only ever has a single record.
The way we relate this table to all of the other tables is either using a cross join (aka cartesian or X join) or by defining a stored calculation field in every table called "constant" which always has the same value in every table which we can use to define an = relationship (e.g. Global::constant = Person::constant)
Another option is to create a global field in the Global table for every one of the normal fields, then create a script that will run on First Window Open that sets the global field value to the stored field value, so that it can be accessed from anywhere without a relationship