One Filemaker File can hold the equivalent of many files inside the one database - when they are contained in one database they are called tables. They operate just like having separate, but linkable, files. That is the way to go for you - have one file 'My Big Database' and have tables inside it, 'Personnel, 'Invoicing', etc.
You can have them as separate files and link them as well, but there are some significatnt advantages to using the multi-table feature.
You can have buttons or menu options on each screen to take the user to any other table.
If you have FM11 you can create custom menus, or you can create your own pop-up lists of values and use those as 'menu' options to drive scripts.
Historically, FileMaker 6 and older systems could only have one table in each file, so multiple, one table to a file systems were the only way you could set up a relational database with FileMaker. FileMaker has retained the capabilities for such an approach, but has added the ability to keep all the tables in a single file.
Open File, is the script step or button action you can use to open a different specified File if you want to set up buttons or scripts to open other files. You can also use Perform Script to perform a script in another Filemaker file and this script can both bring that file's window to the front, select a specified window, find data, etc to present the user with data in a specific layout in the other file. Like any other Perform Script step, you can base data to that script in as a script parameter should you need to do so.
Developers argue a lot over whether to design a FileMaker database with a separate file for each table, all in one file, or with a Data Separation approach that puts the data tables in one file and the layouts, scripts and other inteface elements in a second file.
With separate files for each table, it's easier to manage any future updates as you can just replace the one file being updated and only need to import data from that one file's table instead of from every table in your system. On the other hand, managing security accounts is more complex as you need identical account names and passwords set up in each file or your user will be asked to enter an account name and password every time the system opens another file. Imagine what it takes to change a user's password in a system of 50 different files... Also, moving data around and controlling what layout is next presented to the user gets more complex as global variables defined in one file cannot be accessed directly from another, you'd use fields with global storage or script parameters to pass such data from file to file instead.
The Convert to Seperation Model is a compromise between these two approaches. Since most updates are more likely to modify the user interface instead of the data, any changes to the interface file are simple as you just need to swap out the old copy for the new and no data imports are needed. And managing passwords for two files instead of one isn't too terribly difficult--a few simple scripts and perhaps a global field or two can be used to manate account/password changes while making matching changes in the same account of the other file.