Hi from my side, too. We had that discussion in my CDV2P Bootcamp today. "Adding new keys" is changing granularity. If it's due to schema evolution or absorbing new sources, different keys or different amounts of keys -> separate links. Sometimes, having the same link elements, there may be a reason, too, to separate: Different driving keys in different source tables with identical keys is also a reason to separate. I hope that helps and supplements @Marc Winkelmann 's statement.

If the hashing Algorithm is known, there is nearly no protection. Day of birth is about 100 (yrs) x 365 (days) values possible. Generating a 365k rows lookup table is a no-cost no-brainer. Same for city, zip code, social security number and more PII attributes. Or am I wrong with these assumptions?

I‘d take the red pill and start implementing DV in the underground.

@Lorenz Kindling Absolutely correct. Business Object not driven by source systems are possible and to store in a BV Hub.

@Tim Kirschke Yes, generate hashkeys, don‘t change the patterns. For writing queries (optionally automized) it shouldn‘t be a difference to query RV or BV.

In 1983, with my Commodore 64, I coded a sequential database (state of the art in this time, this environment), to manage my Minitrix model railway‘s (9mm rail gauge) parts. It was giving me an overview about money spent in different categories (tracks, engines and coaches, landscape, buildings, …) and inventory. Later dealing with csv file, read by Microsoft Word for Windows 3 to automize spare part & service efforts for reports & invoices (mid of 90th). Continuing my data journey at Oracle‘s starting 2000 …