A data warehouse exists to provide the business with usable data. A NULL value does not tell your users anything; you can do better. Also, a NULL value will drop out when joining your fact table to a dimension table, causing undercount.
In your dimension table, include a record for each scenario where a transactional database might store a NULL. All of my dimension tables have at least two, for "Not applicable" and "Unknown", but those are only fallback options for when you can't give a better answer.
For an example, consider
Salesperson. If a sale has NULL in this field in the transactional database it could be because...
- the order was just placed and the salesperson hasn't been entered yet
- the sale came directly through the corporate web site; there won't be a salesperson
- multiple salespeople were involved and no single person should get credit
- it's not a normal sale, but a accounting correction
- the salesperson wasn't recorded on the invoice
- salesperson's name was illegible on the invoice
- the salesperson is known, but hasn't been loaded into your
Salespeople dimension yet
Each scenario (that's plausible for your business) should get a value in your
Salespeople dimension, and every record in your
Sales fact table should point to one of these. If necessary, fall back on something generic like "No salesperson available," but only if there's no information with which to do better.
About the only place I use NULL values in a data warehouse is where a metric is missing or inapplicable. Your
SalesPrice fields are probably of
DECIMAL types, so you obviously can't store a text value; you could use codes like "-1 = not entered, -2 = pending, -3 = illegible" but then you'd have to diligently avoid these when performing aggregates.