A fact records a process, not necessarily a numeric measure

Attendance, a scheduled shift, a registration, or an item entering a campaign is a business occurrence without a monetary value.

The combination of dimension keys can be the complete fact, and row count becomes a measure.

Separate event facts from coverage facts

An event fact says a visit or registration happened. A coverage fact says a person, item, or location was eligible or expected.

Together they answer which expected events never occurred.

Grain and uniqueness control the count

One row per scan, person-day, or person-session produces different attendance metrics.

Declare the natural uniqueness constraint and duplicate policy; preserve a separate event stream when state transitions require audit.

Absence requires a complete denominator

Non-attendance or non-purchase cannot be inferred from events alone. It needs an eligible roster, target population, or campaign assortment.

The denominator needs effective dates and exclusions or the anti-join will label ineligible entities as missing.

Accept with positive and negative questions

Test event count, unique actors, duplicates, cancellation, expected-but-missing, and not-applicable cases against source samples.

BuildTable can be assessed for fact modeling; coverage generation, anti-join semantics, and incremental deduplication require project verification.

Declare a process grain even without measures

Attendance, assignment, eligibility, and campaign inclusion are countable processes. Write a grain sentence and uniqueness rule before designing keys.

An event identifier may remain a degenerate dimension. No numeric measure does not remove the need for deduplication and quality contracts.

Pair event facts with coverage facts

Events record what happened; coverage records what should or could happen. Expected-but-missing requires an anti-join from a complete coverage population.

Align grain before comparing. Multiple scans per person-day may need consolidation to the scheduled shift.

Govern the denominator before anti-joining

Eligibility needs generation batch, rule version, effective period, and exclusion reason. Otherwise an absent event cannot be interpreted reliably.

Avoid materializing every possible Cartesian combination. Generate valid planned coverage or expand rules at query time based on scale and frequency.

Preserve state changes and duplicate evidence

Cancellation, reversal, and late events should not be hidden by deletion. Keep source events or history and state whether the analytical fact represents occurrence or current validity.

A constant measure of one does not fix grain, and storing billions of zero rows is usually inferior to governed coverage plus anti-join.

Test both directions and verify scope

Validate event count, unique actors, coverage, expected missing, ineligible, cancelled, duplicate, and late cases. Reconcile the denominator to source rules and prevent join multiplication.

BuildTable may support fact design, while coverage generation, anti-join semantics, deduplication, and rule versioning require verification. A current master-data relationship may be simpler as a bridge or dimension attribute.

Does a fact table still make sense when there is no amount or quantity?