So in relational-database terms, we added a table to represent venues, each keyed to an affiliate; and a table to represent seminar event dates, each event keyed to a venue (and thereby implicitly to an affiliate). Now for each affiliate we can bust out a list of upcoming seminars, or with a little flagging, perhaps run off a "follow-up" minder for each affiliate's account manager to call and ask how their seminar went the next business day.
In app UI terms, I added a button on the affiliate-record-editor to pop-up a venue editor UI, which lists all the venues associated with the given affiliate, nicely sorted by useful criteria. When you click a venue name in the list, it loads detail data for that venue, including a list of seminar dates associated with that venue. The "click the list to load associated data" trick was a new one for me.
I went with the one-to-many relational structure; it's conceivable that multiple affiliates might run seminars at the same venue in a dense market, but in practice I think this almost never happens. Even when it does, there are advantages (both app-design-wise and logistic) to letting each venue record represent, not the physical venue location, but rather an affiliate-venue relationship.
The promise of MS Access lies in its stress on "Rapid Application Development". And say what you want about Microsoft, I don't know what issues there may be with any post-2K version of Access but they got ACC2K mostly right. It does enable RAD with magnitudes less training required than any other full-fledged application platform I've ever dealt with. My one complaint is that ultimately, the "bound form" concept doesn't free the diligent programmer from the chores of abstracting data-handling in any but the most naive applications.