A team preparing a dimensional model for inter-branch loan reporting has not yet decided what a single row in the loan fact table represents: some want one row per loan agreement, others want one row per day an object remains on loan. Which step should the team complete before building the fact table?
Select an answer to reveal the explanation.
Short Explanation
A fact table can't be two things at once, one row per loan and one row per day, without turning every total into a guessing game. Pin down the grain first, and every measure and join you add afterward stays honest.
Full Explanation
Defining the fact table's grain, the precise meaning of a single row, is a foundational step in dimensional modeling that must happen before measures or dimension keys are added, because every subsequent design decision depends on it. If the grain is one row per loan agreement, a count of rows answers how many loans occurred; if it's one row per day an object remains on loan, the same count answers something entirely different, how many loan-days accumulated. Mixing the two in one table without deciding produces inconsistent, silently wrong aggregates the moment someone sums a measure expecting one grain while the table actually holds the other. Skipping the decision and letting reports interpret the grain as needed guarantees inconsistency, since two report authors querying the same table with different assumptions will produce contradictory numbers that both look plausible. Building two undocumented fact tables at different grains might technically resolve the ambiguity, but omitting documentation of which table means what defeats the purpose and invites exactly the same confusion later. Letting each report author decide the grain independently is the same failure as skipping the decision, just deferred to query time instead of design time, and it scales badly as more reports get built. Before finalizing the grain, confirm every currently planned measure and dimension can be expressed cleanly at that grain, since discovering a mismatch after the fact table is populated is far more expensive to fix.