First, why is your fact table carrying option FK to the time dimension? If the fact has fact attributes about a business transaction, that fact must have occured and must have a time-stamp associated with it. I would focus on fixing the design that is loading the facts.
Second, if addressing the fact is not palatable, consider implementing an architecture-wide standard that distinquishes the difference between zero, not applicable and unknown. For example: if the time is unknown, point the fact to the "unkn" time dimension entry, pick a value for the unkn fk (say -1). If the time is not applicable, point the fact to the "n/a" time dimension entry, pick a value for "n/a" fk (say 0). This way you can set up standard filters that include and/or exclude "unkn" and "n/a" entries across your analysis dimensions.
For More Information
- Dozens more answers to tough data warehousing questions from Mike Lampa are available here.
- The Best Data Warehousing and Business Intelligence Web Links: tips, tutorials, scripts, and more.
- Have an DW tip to offer your fellow administrators and developers? The best tips submitted will receive a cool prize. Submit your tip today!
- Ask your technical data warehousing questions -- or help out your peers by answering them -- in our live discussion forums.
- Ask the Experts yourself: Our SQL, database design, SQL Server, DB2, object-oriented and data warehousing gurus are waiting to answer your toughest questions.
Dig Deeper on Oracle database design and architecture
Related Q&A from Mike Lampa
When trying to design a data warehouse, we often try to model the database on the operational data model. Are there any guidelines in trying to ... Continue Reading
What is a surrogate key in a table? Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.