fix: correct WideWorldImporters Data Warehouse table creation scripts

[mchristopher]

Fix: WideWorldImportersDW fact tables fail to publish with Msg 35316 (columnstore not partition-aligned)

Summary

Publishing the WideWorldImportersDW SSDT project to a fresh database fails when creating the partitioned fact tables. This PR makes the five partitioned fact tables declare their partition scheme at the table level so their clustered columnstore indexes are partition-aligned with the base table.

Problem

Deploying the project (SSDT / SqlPackage publish, or building the DACPAC and deploying) fails on the first partitioned fact table with:

Msg 35316: The statement failed because a columnstore index must be partition-aligned
with the base table. Create the columnstore index using the same partition function and
same (or equivalent) partition scheme as the base table. If the base table is not
partitioned, create a nonpartitioned columnstore index.

CREATE CLUSTERED COLUMNSTORE INDEX [CCX_Fact_Transaction]
    ON [Fact].[Transaction]
    ON [PS_Date] ([Date Key]);

Root cause

Each partitioned fact table (Transaction, Movement, Sale, Order, Purchase) declares its PRIMARY KEY NONCLUSTERED and its nonclustered indexes ON [PS_Date] (...), but the CREATE TABLE itself has no table-level partition placement. With no clustered rowstore index, the table's rows are created in an unpartitioned heap on the default filegroup.

A partitioned clustered columnstore index requires the base table to already be partitioned on the same scheme — you cannot build a partitioned clustered columnstore index directly over an unpartitioned heap. So the final CREATE CLUSTERED COLUMNSTORE INDEX ... ON [PS_Date] (...) fails with Msg 35316.

Fix

Add a table-level ON [PS_Date] (<date key column>) to the CREATE TABLE of each partitioned fact table, using that table's existing partition column. The base table is then created as a partitioned heap, and the nonclustered PK/indexes and the clustered columnstore index are all partition-aligned to PS_Date.

Fact table	Partition column added
Fact.Transaction	[Date Key]
Fact.Movement	[Date Key]
Fact.Purchase	[Date Key]
Fact.Sale	[Invoice Date Key]
Fact.Order	[Order Date Key]

Fact.Stock Holding is intentionally not changed: it is not partitioned (no date column; its clustered columnstore index has no partition scheme), so it deploys correctly as-is.

Example (Fact/Tables/Transaction.sql):

...
    CONSTRAINT [FK_Fact_Transaction_Transaction_Type_Key_Dimension_Transaction Type] FOREIGN KEY (...) REFERENCES (...)
-);
+)
+ON [PS_Date] ([Date Key]);

Files changed

• samples/databases/wide-world-importers/wwi-dw-ssdt/wwi-dw-ssdt/Fact/Tables/Transaction.sql
• samples/databases/wide-world-importers/wwi-dw-ssdt/wwi-dw-ssdt/Fact/Tables/Movement.sql
• samples/databases/wide-world-importers/wwi-dw-ssdt/wwi-dw-ssdt/Fact/Tables/Purchase.sql
• samples/databases/wide-world-importers/wwi-dw-ssdt/wwi-dw-ssdt/Fact/Tables/Sale.sql
• samples/databases/wide-world-importers/wwi-dw-ssdt/wwi-dw-ssdt/Fact/Tables/Order.sql

Compatibility / risk

• Table-level ON <partition_scheme>(<column>) is standard T-SQL and has been valid since table partitioning was introduced, so this does not raise the project's platform requirement.
• The partition column added to each table matches the column already used by that table's PK and clustered columnstore index, so the on-disk layout and partitioning semantics are unchanged from what the sample already intends.
• No schema/column/index changes other than the table-level partition placement.

How to verify

1. Build the WideWorldImportersDW SSDT project (resolves cleanly — no SQL71501 unresolved-column errors).

2. Publish to a fresh database; publish now completes without Msg 35316.

3. Confirm the fact tables are partitioned:

   SELECT t.name AS table_name, i.type_desc, ps.name AS partition_scheme,
          COUNT(DISTINCT p.partition_number) AS partitions
   FROM sys.tables t
   JOIN sys.indexes i ON i.object_id = t.object_id
   LEFT JOIN sys.partition_schemes ps ON ps.data_space_id = i.data_space_id
   JOIN sys.partitions p ON p.object_id = t.object_id AND p.index_id = i.index_id
   WHERE t.schema_id = SCHEMA_ID('Fact')
   GROUP BY t.name, i.type_desc, ps.name
   ORDER BY t.name, i.type_desc;
   

[mchristopher]

@microsoft-github-policy-service agree