Model the Data
Start with the shape
Most marks in this domain come from schema design. Fact tables hold foreign keys, numbers and the grain (one row per order line); dimension tables hold the descriptive attributes users filter and group by. Aim for a star: dimension filters fact, one-to-many, single direction. Snowflaking a dimension onto another dimension complicates DAX and is rarely the answer. Hide surrogate keys from Report view.
Dates and role-playing dimensions
Time intelligence needs a contiguous Date table, with no gaps, covering full years, holding a Date column of Date type, marked as a date table and related to the fact date. When several dates exist (order date, ship date), keep one active relationship and activate the others with USERELATIONSHIP inside CALCULATE.
Columns versus measures
A calculated column is computed row by row at refresh, stored and compressed: it grows the model and cannot react to a slicer. A measure is evaluated at query time in the current filter context. If a value must change when a user clicks a slicer, it is a measure. Prefer DIVIDE over the slash operator, and use variables to keep long measures readable.
Filter-context traps
CALCULATE replaces existing filters on the columns it modifies unless KEEPFILTERS is added. ALL and REMOVEFILTERS clear filters, which is how you build a percent-of-total denominator. Bidirectional relationships and many-to-many cardinality create ambiguous or duplicated results; prefer a bridge table with single-direction filters. Iterators such as SUMX evaluate row by row - use them only when the maths cannot be done on an existing column.
Worked example
YoY % = VAR Curr = [Total Sales] VAR Prev = CALCULATE([Total Sales], SAMEPERIODLASTYEAR(DimDate[Date])) RETURN DIVIDE(Curr - Prev, Prev). Rule of thumb: if it can be derived at query time from existing columns, it is a measure, not a column.