||Well, we (City of Boise) have sort of a similar situation where some of our spatial layers have attributes that need to be edited frequently and by a variety of people. In some cases, the full set of attributes are not managed by GIS at all, but instead by other work groups.
What we've done, in these cases, is to create non-ArcSDE, purely relational databases, or tables in relational databases, for the attributes. The primary key is managed by the RDBMS (in our case SQL Server) and GIS carries that key in the featureclasses as a foreign key to the attributes. That way 1) attribute editors DO NOT need a connection into ArcSDE and 2) we can capitalize on all the strengths of a traditional relational database for a good chunk of our data. We are doing VB .NET GUIs/applications for those attrribute editors. They never get into GIS at all during editing.
We create spatial views, in ArcSDE, to join the attributes with the features. So far it works great. There are a couple of options for managing the foreign key inserts into the business table in ArcSDE - triggers on the relational database or via the .NET application (using code).
I would imagine that you could use an Access front-end to manage the edits to the relational tables, but doing it via a true development language is more robust and offers better security.
A couple of the things I especially like about this method of managing attributes are:
1) changing the schema is relatively easy compared to schema changes in ArcSDE; 2) we keep the connections to ArcSDE limited to those folks who actually need to do GIS operations; 3) GIS staff is not responsible for managing data that is more appropriately managed by others; and 4) traditional relational databases have great security models and very solid data integrity features - pardon my skepticism, but I'm still waiting for the way that ESRI has implemented data integrity to prove itself.