Task 2.1: Design and implement a data model

• AAdd a second relationship from the Date table to Sales[ShipDate] and make both relationships active

  Incorrect

  Only one active filter path can exist between two tables, so the second relationship can't be active.

• BSet the OrderDate relationship to filter in both directions so ship dates follow

  Incorrect

  The filter direction doesn't create a ship date role; filters still use OrderDate only.

• CRelate the Date table to Sales[ShipDate] with a many-to-many relationship

  Incorrect

  A table pair can still have only one active path, and Date is the one side of this relationship anyway.

• DAdd a Ship Date calculated table copied from Date, with an active relationship to ShipDate

  Correct

  Each role gets its own table and active relationship, so both slicers filter Sales at once and RLS filters propagate.

A role-playing dimension relates to a fact table more than once, but only one relationship between two tables can be active. Guidance recommends active relationships wherever possible, especially when RLS roles exist, which means duplicating the role-playing table, one per role. For an import table, create the copy as a calculated table.

• ASet the Product to Sales relationship to filter in both directions

  Incorrect

  This gives the behavior but adds the bi-directional relationship you want to avoid.

• BTurn on Show items with no data for the Product slicer

  Incorrect

  This shows products that have no data, the opposite of what's needed.

• CAdd a visual-level filter to the Product slicer: Total Quantity is not blank

  Correct

  The slicer then lists only products with sales in the current filter context, with no change to relationships.

• DSync the Product slicer with the Country slicer

  Incorrect

  Syncing doesn't limit one slicer's items by another slicer's selection.

Bi-directional relationships can make slicers show only options "with data", but they require more processing and can hurt query performance. Guidance recommends instead filtering the slicer itself with a visual-level filter, using a measure such as Total Quantity with the is not blank condition.

• AHide Unit Price and create Average, Min and Max measures over it

  Correct

  Authors then use the explicit measures, and the hidden column isn't available to be summed.

• BCreate a calculated column that stores the average unit price on each row

  Incorrect

  The new column is just as easy to sum in a visual, so the problem remains.

• CChange the Unit Price data type to Text so it can't be summed

  Incorrect

  Text can't be averaged either, so authors lose the aggregations they need.

• DMove Unit Price from Sales into the Product table

  Incorrect

  The column can still be summed in a visual from the Product table.

Columns that can be summarized by a visual act as implicit measures. To control how a column is summarized, for example a rate that should never be summed, guidance suggests hiding the column and creating explicit measures for the appropriate aggregations. Report authors using live connections in Power BI Desktop can still show hidden fields.

• AIts relationship to the fact table filters in both directions

  Incorrect

  Date tables filter fact tables through ordinary one-to-many, single-direction relationships.

• BIts date column holds unique, contiguous dates with no blanks, spanning full years

  Correct

  These are the requirements for the date column of a date table.

• CIts date column uses the Text type in yyyy-mm-dd format

  Incorrect

  The date column must be of the Date or Date/Time data type.

• DAuto date/time stays turned on for the file

  Incorrect

  Auto date/time creates hidden tables of its own; it isn't a requirement for your date table.

• EIt's marked as a date table, with its date column selected

  Correct

  Classic time intelligence requires the date table to be marked as a date table.

A date table needs a date column of the Date (or Date/Time) type with unique values, no blanks and no missing dates, spanning full years. When you use the classic time intelligence functions, the table must also be marked as a date table. Auto date/time is a separate convenience feature.

• AChange the Country column's data type to Text

  Incorrect

  The column is already text; the type doesn't tell a map what kind of location it holds.

• BSort the Country column by a CountryCode column in the same table

  Incorrect

  Sort order affects how values are listed, not how they're geocoded.

• CSet the Country column's data category to Country/Region

  Correct

  The data category tells map visuals what kind of place the values are.

• DMark the Customer table as a date table

  Incorrect

  Marking a date table applies to date columns, not geography.

Data categories describe what a column contains, such as Address, City or Country/Region. Map visuals use the data category to geocode values, so ambiguous names such as Georgia are placed correctly when the column is categorized as Country/Region.

• ASet the relationship's cross-filter direction to Both

  Incorrect

  The direction doesn't make 00123 equal 123.

• BChange the relationship's cardinality to many-to-many

  Incorrect

  Cardinality doesn't change how values are compared.

• CMark Product.ProductKey as hidden and keep Sales.ProductKey as Whole Number

  Incorrect

  Hiding the column changes the field list, not the matching.

• DConvert Product.ProductKey to Whole Number in Power Query

  Correct

  With the same type and values on both sides, every sales row finds its product.

A relationship propagates filters by matching values between the two columns, so the columns should have the same data type and the same representation of each key. Text keys with leading zeros don't match numbers; convert one side in Power Query, as long as every key is numeric, so the values line up.

• AIt filters in both directions

  Incorrect

  Filter direction is shown by arrowheads on the line; a double arrowhead means both directions.

• BIt's a many-to-many relationship

  Incorrect

  Cardinality is shown by the 1 and * indicators at the ends of the line.

• CIt's an inactive relationship

  Correct

  A solid line represents an active relationship and a dashed line an inactive one.

• DIt's a limited relationship

  Incorrect

  A limited relationship shows parenthesis-like marks after the cardinality indicators.

Model view shows a relationship's properties on its line: the 1 and * indicators show the cardinality, arrowheads show the cross filter direction (a double arrowhead for both directions), a solid line is an active relationship and a dashed line an inactive one, and parenthesis-like marks after the indicators show a limited relationship.

• AData category: Image URL

  Correct

  With this category, table and matrix visuals display the image the link points to.

• BData category: Web URL

  Incorrect

  Web URL shows clickable links, not images.

• CData type: Binary

  Incorrect

  The column holds links, which are text, not image data.

• DSort by column: ProductID

  Incorrect

  Sorting doesn't change how values are displayed.

Setting a column's data category to Image URL makes visuals such as tables, matrices and slicers show the image at that address. Web URL turns values into clickable links.

• AMany-to-many

  Incorrect

  ProductID is unique in Product, so Product can be the one side.

• BOne-to-many, from Product to Sales

  Correct

  Product is the one side with unique values, and Sales is the many side.

• COne-to-one

  Incorrect

  Sales has repeated ProductID values, so one-to-one doesn't fit.

• DMany-to-one, from Product to Sales

  Incorrect

  This would make Product the many side, which it isn't.

Relationship cardinality describes how values on each side relate. When the column is unique on one side and repeats on the other, the relationship is one-to-many (or many-to-one, depending on which table you start from), with the unique side as the one side.

• AFrom Sales to Product

  Incorrect

  That's the reverse direction, which single filtering doesn't apply.

• BFrom Product to Sales

  Correct

  With single direction, the one side filters the many side.

• CBoth ways, but only for measures

  Incorrect

  That describes filtering in both directions, not single.

• DNeither way until the relationship is activated

  Incorrect

  Activation concerns inactive relationships, not filter direction.

Cross-filter direction controls how filters propagate along a relationship. With Single, filters flow from the one side to the many side; with Both, they flow in both directions. Bi-directional relationships should be used sparingly.