An analyst who prefers a no-code experience opens the "Visual Query Editor" on a "SQL analytics endpoint" to build a summary that counts orders per status. They drag the orders table onto the canvas and now need to produce one row per status with a row count. Which step in the Visual Query Editor produces this aggregation, and what does the editor generate underneath?
- AApply the Filter rows transformation on status, which collapses duplicate status values into one row each and emits a SELECT DISTINCT statement under the canvas.
- BApply the Group by transformation, choosing status as the grouping column and a count aggregation, and the editor generates the equivalent T-SQL with a GROUP BY clause. Correct
- CApply the Sort transformation on status so identical values sit together, and the editor emits an ORDER BY statement that the report then counts visually per block.
- DSwitch to the Merge queries transformation to join the table to itself on status, and the editor emits a self-join that totals the matching rows per status.
Why A is wrong: Filtering rows removes records that fail a condition rather than aggregating, so it neither produces per-status counts nor generates the grouping logic the task needs.
Why B is correct: The Group by step is the visual equivalent of GROUP BY, and the editor renders the diagram as T-SQL behind the canvas, so it both aggregates correctly and produces reviewable SQL.
Why C is wrong: Sorting only orders rows and produces ORDER BY, which does not compute counts per status, so the aggregation still has to be done somewhere else.
Why D is wrong: Merge queries performs a join between tables rather than an aggregation, so a self-join overcomplicates the task and does not cleanly yield one counted row per status.