You never want to use fields that contain meaningful data as key fields: i.e., do not use names to link the tables. Instead use ID fields that are not accessible to users.
Are you sure that it's even necessary to use 20 "sub" tables? Duplication of data is also generally best to avoid as much as possible.
Thank you for your post.
"Fitch" hit the nail on the head. That is, is it necessary to have 20 sub-databases? You may want to create some scripts or access privileges that limit the records that can be viewed. This would allow everyone to look at one database file, but have 20 different views into the file. That way, if a record is removed, you don't have to worry about deleting it from a separate database.
If it is necessary to have 20 sub-databases, how about creating a button that marks a record for deletion (by putting a value into a field). Then, when you close the file, it would find all records in the sub-databases and remove them, before deleting the "marked" record. Does that make sense?