Database constraints are an important mechanism to ensure foreign key relationships are valid. So users are permitted to delete a row as long as any other record refers to it. Otherwise you would get different results with and without a join, once the join condition filters out the row, in the other case there is no such join.
Obviously, the same applies for a Data Warehouse, with one major exception: No user is modifying data, the load process does. And here we can perform this much more efficient.
So as a summary, when loading data it should be ensured that no foreign key is violated. Further, database constraints should be created, but disabled.
And what should the load process do in case a foreign key is invalid?
Option 1: Do not load that row. But then this revenue is missing as well!
Option 2: Load it, but set the foreign key pointing to a "unknown" row, one row in the dimension table that has a primary key of e.g. "?", whose name is "unknown" etc. This has the major advantage the enduser is actually seeing issues with data quality and gets the motivation to correct it in the source system.
Option 3: Load it, and create a new row with that primary key value in the dimension table. In case we assume that the dimension table is just not as current as it should be, we could create such a row already and set it to default values, like name "unknown" and tomorrow, when the dimension table gets updated, the load will find that this customer has a new name now...
