Connect to and Transform Data

A regional sales team works offline on long-haul flights and queries a 40-million-row table on a corporate database that throttles ad-hoc analytical reads during business hours. The team needs fast filtering and aggregation in the workbook without hitting the source repeatedly. Which connection approach best fits these constraints?

• ACreate an extract so the data is stored locally for offline use and fast in-memory querying that avoids repeated load on the throttled source.check_circle Correct
• BKeep a live connection so every interaction reflects the current state of the corporate database in real time.
• CUse a live connection but lower the workbook's refresh frequency so the database receives fewer queries during business hours.
• DKeep a live connection and rely on the source database's own result cache to satisfy offline interactions.

Why A is correct: An extract snapshots the data into a local columnar store, which works offline and serves fast filtering and aggregation from memory without querying the throttled source each time.

Why B is wrong: A live connection sends a query to the source on every interaction, which fails the offline requirement and worsens the throttling problem the team is trying to avoid.

Why C is wrong: There is no per-interaction refresh frequency to lower on a live connection; each view interaction still issues a query, so this does not solve offline access or throttling.

Why D is wrong: A source-side cache cannot serve a disconnected client; with no network the live connection has nothing to query, so offline analysis is impossible.

An analyst replaces the data source for a finished dashboard with a new table whose columns are the same except that the field once named Customer ID is now named Client ID. After the replace, several worksheets and a calculated field show errors. What is the most likely cause?

• AReplace data source only works between two extracts, so swapping in a relational table breaks the dependent worksheets.
• BReplace data source matches fields by name, so the renamed identifier is no longer found and everything that referenced Customer ID breaks.check_circle Correct
• CReplace data source clears all calculated fields by design, so the analyst must always recreate them afterwards.
• DReplace data source matches fields by position rather than by name, so reordering the columns broke the references.

Why A is wrong: Replace data source works across connection types including relational tables, so the connection type is not what caused the errors here.

Why B is correct: Replace data source remaps by matching field names, so when Customer ID becomes Client ID the reference cannot resolve and every worksheet and calculation depending on it errors until the field is remapped.

Why C is wrong: Replace data source preserves calculated fields when their referenced fields still resolve; it does not wipe calculations by design, so this misstates the behaviour.

Why D is wrong: Replace data source matches fields by name, not column position, so a positional theory does not explain the breakage; the renamed field is the real issue.

A data source combines an Orders table and a Returns table. Many orders were never returned, and the analyst needs every order to appear in the analysis regardless of whether a matching return exists, without choosing an aggregation context up front or producing duplicated order rows. Which way of combining the two tables best fits this requirement?

• AAn inner join on the order identifier, so only matched rows survive
• BA union of the two tables stacked on the order identifier
• CA left join from Returns to Orders on the order identifier
• DA relationship between the tables on the order identifiercheck_circle Correct

Why A is wrong: An inner join keeps only orders that have a matching return, which discards the many unreturned orders the analyst explicitly needs to retain.

Why B is wrong: Union appends rows from similar tables rather than matching orders to returns by a key, so it would not associate a return with its order and is the wrong combining operation here.

Why C is wrong: A left join from Returns keeps all returns and drops unreturned orders, which is the opposite of keeping every order, and it also fixes the join context too early.

Why D is correct: A relationship keeps each table at its own level of detail, returns all orders by default because matching is deferred to the analysis, and avoids the premature aggregation and row duplication that fixed joins introduce.

An analyst connects to a sales workbook where the first eight rows hold a company logo, a report title, and blank spacers before the real column headers begin. The genuine table then sits below, but Tableau has read the title text as field names. Which feature should the analyst turn on to have Tableau detect the real header row and the underlying table automatically?

• AA pivot on the leading columns, which reshapes the title block into a single header row
• BA custom split, which separates the logo and title text from the data values
• CData Interpreter, which scans the sheet for the sub-table and promotes the correct row to field namescheck_circle Correct
• DA union with a cleaned copy of the sheet, which appends the corrected headers below

Why A is wrong: Pivot converts wide columns into rows of key-value pairs; it cannot recognise that the top eight rows are decoration rather than data, so it would not fix the misread headers.

Why B is wrong: Split divides the contents of one field into several based on a delimiter; it operates within columns and cannot strip out leading non-data rows or relocate the header row.

Why C is correct: Data Interpreter is designed to find a sub-table inside a messy spreadsheet, skip titles and blank spacers, and promote the genuine header row to field names, which is exactly the problem described.

Why D is wrong: Union stacks rows from similar tables on top of each other; appending another sheet would not remove the title block or fix which row Tableau treats as headers.

A data source imports a status column whose stored codes are 1, 2 and 3, representing Pending, Shipped and Delivered. The analyst wants the view, tooltips and legends to display the friendly labels without altering the underlying stored values or creating a new calculated field. Which Tableau feature meets this need?

• ARename the field so the column header reads Status instead of the imported name.
• BChange the default number format so the codes appear with descriptive prefixes.
• CConvert the field to a measure so Tableau can map the codes to text on an axis.
• DCreate an alias for each member so 1, 2 and 3 display as Pending, Shipped and Delivered.check_circle Correct

Why A is wrong: Renaming changes the field's caption, not the individual member values, so the codes 1, 2 and 3 would still show in the view.

Why B is wrong: Number formatting only adjusts how numeric values are styled, such as decimals or currency, and cannot substitute text labels for the codes.

Why C is wrong: Converting to a measure would aggregate the codes numerically and still display digits, so it does not produce the friendly text labels.

Why D is correct: Aliases relabel the displayed members of a dimension while leaving the stored values intact and without adding a calculated field, which is precisely the requirement.