What theoretical foundation have you found for "Repository pattern" database design? I'm guessing none. It's a layer of complexity resting on a bogus premise: that the "persistence layer" is something you need to be isolated from. From what I can tell, it plays to widespread programming ignorance of relational design principles, and panders to a presupposed centrality of the application's OO design. But it doesn't justify its existence on rational, let alone theoretical, grounds.
The One True Path to database design hasn't changed in 30 years: analyze the data. Find the keys and constraints and many-to-one relationships. Design your tables according to Boyce-Codd normal form. Use views and stored procedures to facilitate data access.
Unloved though it may be, a SQL DBMS provides a better isolation layer than anything the programmer can provide. It's true that as the database changes the SQL used to access it might have to change. But note that that's true regardless of whether or not there's a mediation layer. As long as the application uses views and stored procedures to access the DBMS, ordinary SQL engineering tools will indicate when changes to the underlying database invalidate those views and stored procedures.
Therein lies the challenge, of course. A mediation layer provides the illusion of isolation and the comfort to the programmer of writing code, which he knows how to do. Learning database design and SQL requires learning something new. Most people would rather die than think, and many succeed.
Someone on your team will doubtless object that writing SQL to support your 200 classes is a lot of work. No doubt. But at least it's useful work. If you design a database by mimicking your OO design, you will also do a lot of work, much of it useless, and defeat most of what the DBMS offers you.
For example, you contemplate reflecting Unit of Work in the database (as table or tables, I presume). Unit of work is a built-in service of the DBMS:
begin transaction ... update database ...
commit transaction. Nothing to model, other than the mapping of your classes to the database tables in SQL.
Your question was posted 4 years ago. I'm answering because it was "updated" in some way recently, indicating it's still of some interest to someone. I hope my answer encourages the reader to apply basic relational theory to the problem instead of adopting a pointless workaround.