"Linked" has different meanings to different folks. Since you mentioned it in the context of "split databases" I will try to give it a go in that context. I'll toss in a couple of different images. Mix my metaphors. Maybe one of them will click for you.
Inside Access (and most other databases that handle arbitrary or variable-sized records containing text), a table is REALLY just a list of pointers to locate and otherwise describe the individual records. When you step through any recordset, be it table- or query-based, all you are doing is following a list of pointers in some order defined by the original table layout or the query that provides that recordset. So as a first-level image, it is OK to say that an Access MDB file is just a container of many lists of records (and list of other things as well - list of forms, list of reports, etc.)
Normally for Access, the pointer to each record points to a spot inside the same Access MDB file as the MDB file that defines the application. I.e the primary MDB file. The Front End file. Whatever you call it.
The record starts at that spot within the file indicated by the record pointer. (It is sometimes called a file-relative address or a file record address on non-Microsoft file systems. For instance, in some H/P OpenVMS databases, this is the Record's File Address or RFA. The first address in the file is RFA 0. If the file is 2000000 bytes long, the last RFA is 1999999. Got the idea?) OK, enough about record pointers for a moment.
Having linked tables merely means you can reference the same exact kind of list of record pointers, but it is one that resides in a different MDB file than the one holding your primary application. So in other words, it is just a matter where you find the record pointer list.
Like the real-estate person says, "Location, location, location." In this case, to find a record, your application needs to know:
1. The location of the database so you can find...
2. The location of the record pointer list (table) so you can find...
3. The location of each record (as defined by the pointers in the list.)
See? Location, location, location! Having a linked table just lets you select a different source for the #1 location above. Once you are inside the file, all the other principles are EXACTLY IDENTICALLY THE SAME as a non-linked table. Folks try to make too much of this sometimes. The key is to realize that the pointers in each record are STILL pointers relative to the file in which they were found.
When you link to an external table, you need to know TWO things - the location of the database and the location of the table within that database. When you use an internal table, you need to know TWO things - the location of the database (which happens to match where your application is found) and the location of the table within that database. Gee, kinda similar, aren't they...?
Linked, cross-formatted tables (e.g. treating an Excel worksheet as a table) really do the same thing, except that Office has some code modules that provide you with an Excel "driver" to figure out and translate the differences in record-list formats between Excel and Access. One Excel ROW = one Access record. Otherwise, Excel and Access both work with lists.
BTW, this is a side-effect of Microsoft's Component Object Model. By forcing everything to be "collections" (LISTS... hint hint), it means that all MS programs have at least a chance to understand each other... sometimes.
That is why you need the ODBC or other translation module when dealing with a foreign (non-MS) data source. It is this "driver" (or if you prefer, interface routine, usually in a .DLL file) that allows you to do operations to non-MS databases. The "driver" does the translation of datasource pointers in the other DB to something Access can use.
Depending on the complexity of the "driver" and how much time it took to develop it, that is also why the vendor charges you an arm and a leg for the code - or requires that you put up your firstborn daughter as a deposit.
Simple enough?
