A diffuse relationship is one of a group of similar relationships, which broadly apply to entities in a model. We can show them explicitly, but such an approach can become verbose and obscure the deeper content of a model. We coined the term “diffuse relationship” as we haven’t seen this phenomenon named by others.
Consider the following data warehouse model. The relationships to Source_System, Data_Warehouse_User, and Batch_Load_Run are diffuse relationships. Many of the tables have a source_system_key, created_by_key, updated_by_key, and batch_load_key. You can see the repetition, even in this small example.
The model is a proper model in that all relationships are defined. We can readily generate DDL code including foreign key constraints.
However there’s an aesthetic problem. The diffuse relationships cloud the underlying deeper meaning. Furthermore, if we consider the full warehouse with several hundred tables, we have severe clutter in the model. One purpose of a model is to generate DDL and the example model does that well. But another purpose is to foster deep understanding of a problem and communicate to others – the clutter of diffuse relationships undermines this latter purpose.
Here’s a restated model where we omit the diffuse relationships.
Clearly the simplified model is better at showing meaningful content. End users that are writing analytical queries would much prefer the simplified model to the verbose one.
If we want to have foreign key constraints, we have two choices.