In Kimball's 3rd edition book he recommends using views for the fact and dimension tables. I had done this in a couple of instances. As an example, all the inspectors for one cube were also technicians, but most technicians were not inspectors. So I created a dimInspector view using the dimTechnican table as a base. But the surrogate key for the view was from the table (and therefore not sequential, but that isn't important). I did not try to create a new surrogate key on the fly. In my most recent design I use views for all the fact and dimension tables. But in each case the underlying surrogate key already exists. I don't, and wouldn't, try to create them on the fly. I'm not normally a fan of views in an OLTP environment. There are only a few good use cases for them and they seem to me too often used when a stored procedure would have been better. But I've become a big fan of views in an OLAP environment. Just not in the way that I think you're suggesting.