The problem with RI is that it requires extra work by Access (and extra design work by you) to maintain it properly. You are quite right that adding more tables with RI-class constraints on them will slow down performance. It is a cost of doing business on ANY database, I'm afraid, but there are ways to mitigate the problem.
Tricks that folks can play to reduce the amount of work include such things as always using the shortest keys possible. Use prime keys based on autonumber fields only for tables with potentially unlimited range, but perhaps you can use keys of only one or two bytes for lookup tables with a known, more limited data range.
Normalization is always desirable and without it, RI becomes problematic. But RI is not always desirable. Only you know what is in your tables, and this next is not intended as a criticism, just a suggestion. Consider whether each of those seven tables really requires RI or whether you might wish to relax that requirement for some of the tables. I also wonder if you have too many separated tables if all of them include RI to the same main table. Of course, if each table further joins to different tables besides that main table, then you should, indeed, separate them. But I wonder about possible proliferation of tables where consolidation might be preferable. Reducing the number of tables reduces the work done for RI checking. Just a suggestion for your consideration, not finger-pointing!
Another important issue is indexes. (Indices?) Since you could not even set up RI without a primary key on the main table, I know you MUST have that, and I know it has to be properly and uniquely indexed. But do you have similar non-unique indexes on the child tables in order to provide faster access to the field that is the foreign key in the child corresponding to the prime key in the parent? Indexes on such fields can help because they provide a faster data source for RI checking. (Has to do with how much data you can fit in a single Access block-buffer. Smaller index = more data in a single block input = faster scan for records affected by RI.)
If you don't already have such an index on the child tables, I would add an index to each table and make it hold ONLY the FK corresponding to the main table's PK. Even if no other program action requires use of such an index. Which I doubt anyway since you probably have JOIN queries linking the main table and your child tables, so such indexes would be useful there, too.
Supplement: On re-reading the problem, I see it is possible that the table with these relationships might be a child of seven different tables rather than a parent of seven tables. The suggestions of reducing key size and putting an index on the table in question is STILL a good idea even if the other idea (consolidation of multiple tables) might not work.
