Records individual business events at the most atomic grain. One row per transaction (sale, order, click). Captures the 'who, what, when, where, how much' of each event. Most common fact table type. Supports detailed drill-down analysis. Can grow very large but provides maximum flexibility for analysis.

Captures state at regular intervals (daily, weekly, monthly). One row per period per entity being measured. Shows cumulative or point-in-time metrics. Ideal for inventory, account balances, pipeline status. Predictable row count based on periods and entities. Complements transaction facts for trend analysis.

Tracks lifecycle of a process with defined milestones. Single row updated as entity progresses through stages. Multiple date foreign keys for each milestone. Lag calculations between milestones. Row is updated (not inserted) as process advances. Best for processes with clear start/end and measurable stages.

Records events or relationships without numeric measures. Captures occurrences or coverage. Two types: event tracking (student attendance) and coverage (product promotions). Foreign keys only, no measures. COUNT(*) is the implicit measure. Essential for tracking what didn't happen or eligibility.

Dimension shared across multiple fact tables and subject areas. Single definition of business entity (customer, product, date). Enables cross-process analysis and enterprise reporting. Bus architecture foundation. Same keys, attributes, and hierarchies everywhere. Master data management integration.

Same physical dimension used multiple times in one fact with different meanings. Common for date dimension (order date, ship date, due date). Implemented as views or aliases. Each role has different foreign key in fact. Avoids dimension duplication while supporting multiple perspectives.

Combines low-cardinality flags and indicators into single dimension. Avoids cluttering fact table with multiple flag columns. Cartesian product of all flag combinations. Typically small (dozens to hundreds of rows). Improves fact table compression. Named 'junk' but actually good design.

Dimension key stored in fact table with no corresponding dimension table. Typically transaction identifiers (order number, invoice number). No attributes to store in dimension. Provides drill-through to source. Occupies dimension position but has no join. Common in transaction fact tables.

Secondary dimension joined to primary dimension (not fact). Normalizes dimension hierarchy. Snowflake extension of star schema. Used when dimension attribute has its own attributes. Date dimension as outrigger to other dimensions. Trade-off: normalization vs query complexity.

Resolves many-to-many relationships between fact and dimension. Sits between fact and multi-valued dimension. Contains weighting factors for allocation. Examples: multiple diagnoses per patient, multiple categories per product. Enables M:M without violating star schema.

Can be summed across all dimensions. Most common and useful measure type. Examples: sales amount, quantity, cost. Freely aggregated by any dimension. Foundation of most business metrics. Sum, count operations always valid.

Can be summed across some dimensions but not all (typically not time). Balance and inventory measures. Snapshot values that shouldn't be summed over time. Use AVG, MIN, MAX, or LAST for time dimension. Common in periodic snapshot facts.

Cannot be summed across any dimension. Ratios, percentages, unit prices. Must be calculated from additive components. Store components, calculate ratio in reporting. Examples: profit margin, conversion rate, average price.

Computed from other measures at query time. Not stored in fact table. Business logic in BI tool or view. Examples: profit (revenue - cost), margin (profit/revenue). Keeps fact table clean. Trade-off between storage and compute.