Mirrored databases

I was hoping for comments about a general design.

We have 2 lines of business. I have to keep the data for the 2 lines in separate databases. I realize this is dumb because data in 2 different databases can be made to look like it's in the same database and vice versa - but a contract is a contract.

The contract stipulates that Line of Business "A" cannot see LOB "B"'s data, but LOB "B" can see LOB "A"s data.

I want to keep the concept of the BUS architecture. My plan is to keep a single version of the smaller more generic dimension tables - date dimension, for example. But for the larger dimensions or dimensions that have a lot of information specific to the line of busiess, I was planning to keep 2 versions of them with the exact same design. The reason for this is that the elements in the larger dimension tables (customer) can never switch lines of business and some of the smaller dimensions, such as product, would need views to limit the product set (for example) to a particular LOB to be used with the query tool, otherwise I get products from one LOB mixed in with the products of the other LOB in pick lists.

I was planning on using negative numbers for the surrogate keys for the dimensions of one LOB and positive numbers for the other LOB, just in case I ever need to combine the data, such as in a report counting members or transactions for the entire company - information that would not violate the contract. I can create union views of the dimension tables from the 2 LOBs as well as Union views of the fact tables.

Comments?

There is no particular reason why there needs to be two databases. After all, you could include LOB/source ID as a part of the dimension natural keys to keep things separate. And given they do want to look at things in total, it is probably not a good approach. However, given this is a contract and the customer has dictated such an approach, and assuming they not willing to consider alternatives, I wouldn't attempt to do anything special. Just build two independent databases and don't worry about keys. Don't share anything.

If they want to consolidate things later, its another contract.