Microsoft網狀架構倉儲中的維度模型化：維度數據表

適用於：✅ Microsoft Fabric 中的 SQL 分析端點和倉儲

本文提供在維度模型中設計 維度 數據表的指引和最佳做法。 它提供 Microsoft Fabric 中倉儲的實際指引，這是支援許多 T-SQL 功能的體驗，例如在數據表中建立及管理數據。 因此，您可以完全控制建立維度模型數據表，並使用數據載入它們。

在維度模型中，維度數據表描述與您商務和分析需求相關的實體。 大致上，維度數據表代表 您建立模型的專案 。 專案可以是產品、人員、地點或任何其他概念，包括日期和時間。 若要輕鬆地識別維度數據表，您通常會以 d_ 或 Dim_為其名稱加上前置詞。

維度數據表結構

若要描述維度數據表的結構，請考慮下列名為 d_Salesperson的銷售人員維度數據表範例。 此範例會套用良好的設計作法。 下列各節將說明每個數據行群組。

CREATE TABLE d_Salesperson
(
    --Surrogate key
    Salesperson_SK INT NOT NULL,
    
    --Natural key(s)
    EmployeeID VARCHAR(20) NOT NULL,
    
    --Dimension attributes
    FirstName VARCHAR(20) NOT NULL,
    <…>
    
    --Foreign key(s) to other dimensions
    SalesRegion_FK INT NOT NULL,
    <…>
    
    --Historical tracking attributes (SCD type 2)
    RecChangeDate_FK INT NOT NULL,
    RecValidFromKey INT NOT NULL,
    RecValidToKey INT NOT NULL,
    RecReason VARCHAR(15) NOT NULL,
    RecIsCurrent BIT NOT NULL,
    
    --Audit attributes
    AuditMissing BIT NOT NULL,
    AuditIsInferred BIT NOT NULL,
    AuditCreatedDate DATE NOT NULL,
    AuditCreatedBy VARCHAR(15) NOT NULL,
    AuditLastModifiedDate DATE NOT NULL,
    AuditLastModifiedBy VARCHAR(15) NOT NULL
);

Surrogate 金鑰

範例維度數據表具有 Surrogate 索引鍵，其名稱為 Salesperson_SK。 Surrogate 索引鍵是產生並儲存在維度數據表中的單一數據行唯一標識符。 這是 用來與維度模型中其他數據表相關的主鍵 數據行。

Surrogate 索引鍵會努力讓數據倉儲與源數據變更隔離。 它們也會提供許多其他優點，讓您能夠：

• 合併多個數據源（避免重複標識符衝突）。
• 將多數據行自然索引鍵合併成更有效率的單一數據行索引鍵。
• 使用緩時變維度 （SCD） 類型 2 追蹤維度歷程記錄。
• 限制儲存優化的事實數據表寬度（選取最小的可能整數數據類型）。

代理索引鍵數據行是建議的做法，即使自然索引鍵（如下所述）似乎是可接受的候選專案。 您也應該避免為索引鍵值提供意義（日期和時間維度索引鍵除外，如稍後所述）。

自然鍵

範例維度數據表也有名為的自然索引鍵EmployeeID。 自然金鑰是儲存在來源系統中的金鑰。 它允許將維度數據與其來源系統建立關聯，這通常是由擷取、載入和轉換 （ETL） 程式完成以載入維度數據表。 有時候自然索引鍵稱為 商務密鑰，其值對商務使用者可能有意義。

有時候維度沒有自然索引鍵。 這可能是日期 維度或查閱維度 的情況，或當您藉由正規化一般檔案來產生維度數據時。

維度屬性

範例維度數據表也有 維度屬性，例如數據 FirstName 行。 維度屬性會提供儲存在相關事實數據表中的數值數據內容。 它們通常是用於分析查詢中的文字數據行來篩選和分組（配量和骰子），但無法自行匯總。 某些維度數據表包含少數屬性，而其他數據表則包含許多屬性（支援維度模型的查詢需求所需數目）。

如果您打算建立 Direct Lake 語意模型，您應該包含篩選和分組為維度屬性所需的所有可能數據行。 這是因為 Direct Lake 語意模型不支援導出數據行。

外部索引鍵

範例維度數據表也有外 鍵，其名稱為 SalesRegion_FK。 其他維度數據表可以參考外鍵，而且其存在於維度數據表中是一個特殊案例。 它表示數據表與另一個維度數據表相關，這表示它可能會構成雪花維度的一部分，或它與外線維度相關。

網狀架構倉儲 支援外鍵條件約束 ，但無法強制執行它們。 因此，載入數據時，您的 ETL 程式必須測試相關資料表之間的完整性。

建立外鍵仍然是個好主意。 建立非強制外鍵的其中一個好理由是允許模型化工具，例如Power BI Desktop，在語意模型中自動偵測及建立數據表之間的關聯性。

歷程記錄追蹤屬性

範例維度數據表也有各種 歷程記錄追蹤屬性。 歷程記錄追蹤屬性是選擇性的，基於您需要追蹤來源系統中的特定變更。 它們允許儲存值來支持數據倉儲的主要角色，也就是要準確地描述過去。 具體來說，這些屬性會將歷程記錄內容儲存為 ETL 進程將新的或已變更的數據載入維度中。

如需詳細資訊，請參閱 本文稍後的管理歷程記錄變更 。

稽核屬性

範例維度數據表也有各種 稽核屬性。 稽核屬性是選擇性的，但建議使用。 它們可讓您追蹤維度記錄的建立或修改方式，而且可以包含 ETL 程式期間引發的診斷或疑難解答資訊。 例如，您會想要追蹤誰（或哪些程式）更新了數據列，以及何時更新。 稽核屬性也可以協助診斷具有挑戰性的問題，例如 ETL 進程意外停止時。 它們也可以將維度成員標示為錯誤或 推斷的成員。

維度數據表大小

通常，維度模型中最實用且多用途的維度是大型、寬維度。 在數據列（超過數百萬個）和維度屬性數目方面，它們很大（可能數百個）。 大小並不重要（雖然您應該針對最小可能的大小進行設計和優化）。 重要的是維度支持事實數據所需的篩選、分組和精確的歷史分析。

大型維度可能來自多個來源系統。 在此情況下，維度處理必須結合、合併、重複資料刪除，並標準化數據：和指派 Surrogate 索引鍵。

相較之下，有些維度很小。 它們可能代表只包含數筆記錄和屬性的查找表。 這些小型維度通常會在事實數據表中儲存與交易相關的類別值，而且它們會實作為具有代理索引鍵的維度，以與事實記錄相關。

維度設計概念

本節說明各種維度設計概念。

反正規化與正規化

維度數據表 應該反正規化的情況幾乎一律如此。 雖然 正規化 是用來描述以減少重複數據的方式儲存之數據的詞彙，但反正規化是用來定義預先計算備援數據所在的詞彙。 備援數據通常會因為階層的儲存而存在（稍後討論），這表示階層會扁平化。 例如，產品維度可以儲存子類別（及其相關屬性）和類別（及其相關屬性）。

因為維度通常很小（相較於事實數據表），因此儲存備援數據的成本幾乎總是超過改善的查詢效能和可用性。

雪花式維度

反正規化的一個例外是設計 雪花維度。 雪花維度已正規化，並將維度數據儲存在數個相關數據表中。

下圖描述由三個相關維度資料表組成的雪花維度： Product、 Subcategory和 Category。

請考慮在下列情況下實作雪花維度：

• 維度非常大，記憶體成本超過高查詢效能的需求。 （然而，定期重新評估這仍然是案件。
• 您需要索引鍵，才能將維度與較高粒紋的事實產生關聯。 例如，銷售事實數據表會將數據列儲存在產品層級，但銷售目標事實數據表會將數據列儲存在子類別層級。
• 您必須 追蹤較高層級數據粒度的歷程記錄變更 。

階層

通常，維度數據行會產生階層。 階層可讓您在不同的摘要層級探索數據。 例如，矩陣視覺效果的初始檢視可能會顯示年度銷售額，而報表取用者可以選擇 向下 切入以顯示每季和每月銷售額。

有三種方式可將階層儲存在維度中。 您可以使用：

• 來自單一反正規化維度的數據行。
• 雪花維度，其中包含多個相關數據表。
• 維度中的父子式（自我參考）關聯性。

階層可以平衡或不平衡。 也請務必瞭解某些階層不完全。

平衡階層

平衡階層 是最常見的階層類型。 平衡階層的層級數目相同。 平衡階層的常見範例是日期維度中的行事歷階層，其中包含年份、季、月和日期的層級。

下圖描述銷售區域的平衡階層。 它包含兩個層級，也就是銷售區域群組和銷售區域。

平衡階層的層級是根據單一、反正規化維度的數據行，或來自形成雪花維度的數據表。 根據單一反正規化維度，表示較高層級的數據行會包含備援數據。

對於平衡階層，事實一律與階層的單一層級相關，通常是最低層級。 如此一來，就可以將事實匯總到階層的最高層級。 事實可以與任何層級有關，由事實數據表的粒紋決定。 例如，銷售事實數據表可能會儲存在日期層級，而銷售目標事實數據表可能會儲存在季度層級。

不平衡階層

不平衡階層是較不常見的階層類型。 不平衡的階層具有以父子式關聯性為基礎的層級。 因此，不平衡階層中的層級數目取決於維度數據列，而不是特定的維度數據表數據行。

不平衡階層的常見範例是員工階層，其中員工維度中的每個數據列都與相同數據表中的報表管理員數據列相關。 在此情況下，任何員工都可以是具有報告員工的經理。 當然，階層的某些分支會比其他分支擁有更多層級。

下圖描述不平衡的階層。 其中包含四個層級，而階層中的每個成員都是銷售人員。 請注意，銷售人員在階層中有不同數目的上階，根據他們回報的人員。

不平衡階層的其他常見範例包括材料帳單、公司擁有權模型和總帳。

對於不平衡階層，事實一律與維度粒紋有關。 例如，銷售事實與具有不同報表結構的不同銷售人員有關。 維度數據表會有 Surrogate 索引鍵（名為 Salesperson_SK）和 ReportsTo_Salesperson_FK 外鍵數據行，其會參考主鍵數據行。 沒有任何人管理的每個銷售人員不一定位於階層中任何分支的最低層級。 當他們不在最低層級時，銷售人員可能會銷售產品，並報告銷售人員也會銷售產品。 因此，事實數據的匯總必須考慮個別銷售人員及其所有子系。

查詢父子式階層可能會很複雜且緩慢，尤其是針對大型維度。 雖然來源系統可能會將關聯性儲存為父子系，但建議您 將階層自然化 。 在此實例中，自然化方法可將階層層級轉換成數據行，並將其儲存在維度中。

不完全的階層

有時候階層是不 完全的 ，因為階層中成員的父代存在於階層中，而不是緊接在階層上方。 在這些情況下，遺漏的層級值會重複父代的值。

請考慮平衡地理位置階層的範例。 當國家/地區沒有州或省時，就會有不完全的階層。 例如，紐西蘭既沒有州也沒有省。 因此，當您插入紐西蘭數據列時，也應該將國家/地區值儲存在數據行中 StateProvince 。

下圖描述地理區域的不完全階層。

管理歷程記錄變更

必要時，可以藉由實 作緩時變維度 來管理歷程記錄變更（SCD）。 SCD 會維護歷程記錄內容，因為新數據或已變更的數據會載入其中。

以下是最常見的 SCD 類型。

• 類型 1： 覆寫現有的維度成員。
• 類型 2： 插入新的以時間為基礎的 版本 維度成員。
• 類型 3： 使用屬性追蹤有限的歷程記錄。

維度可以同時支援 SCD 類型 1 和 SCD 類型 2 變更。

SCD 類型 3 通常不會使用，部分原因是語意模型中難以使用。 請仔細考慮 SCD 類型 2 方法是否更適合。

SCD 類型 1

SCD 類型 1 變更會覆寫現有的維度數據列，因為不需要追蹤變更。 這個 SCD 類型也可以用來更正錯誤。 這是常見的 SCD 類型，它應該用於大多數變更的屬性，例如客戶名稱、電子郵件位址和其他屬性。

下圖描述銷售人員維度成員的前後狀態，其電話號碼已變更。

此 SCD 類型不會保留歷史檢視方塊，因為現有的數據列已更新。 這表示 SCD 類型 1 變更可能會導致不同的較高層級匯總。 例如，如果銷售人員指派給不同的銷售區域，SCD 類型 1 變更會覆寫維度數據列。 銷售人員對區域的歷程記錄銷售結果匯總會產生不同的結果，因為它現在會使用新的目前銷售區域。 就好像該銷售人員一律指派給新的銷售區域一樣。

SCD 類型 2

SCD 類型 2 變更會導致新的數據列代表維度成員的時間型版本。 一律會有目前的版本數據列，它會反映來源系統中維度成員的狀態。 維度數據表中的歷程追蹤屬性 會儲存允許識別目前版本（目前旗標為 TRUE）及其有效性時間週期的值。 需要 Surrogate 金鑰，因為儲存多個版本時會有重複的自然索引鍵。

這是常見的 SCD 類型，但應該保留給必須保留歷史檢視方塊的屬性。

例如，如果銷售人員指派給不同的銷售區域，SCD 類型 2 變更會涉及更新作業和插入作業。

1. 更新作業會覆寫目前的版本，以設定歷程記錄追蹤屬性。 具體來說，結束有效性資料行會設定為 ETL 處理日期（或來源系統中的適當時間戳），而目前的旗標會設定為 FALSE。
2. 插入作業會新增新的目前版本，並將 start validity 資料行設定為 end validity 資料行值（用來更新舊版），並將目前的旗標設定為 TRUE。

請務必瞭解相關事實數據表的數據粒度不在銷售人員層級，而是 銷售人員版本 層級。 其歷史銷售結果匯總至區域會產生正確的結果，但將會有兩個（或更多）銷售人員成員版本進行分析。

下圖描述銷售人員維度成員的前後狀態，其中其銷售區域已變更。 由於組織想要依指派的區域來分析銷售人員的工作，因此會觸發SCD類型 2 變更。

請考慮下列 SCD 類型 2 歷程記錄追蹤屬性。

CREATE TABLE d_Salesperson
(
    <…>

    --Historical tracking attributes (SCD type 2)
    RecChangeDate_FK INT NOT NULL,
    RecValidFromKey INT NOT NULL,
    RecValidToKey INT NOT NULL,
    RecReason VARCHAR(15) NOT NULL,
    RecIsCurrent BIT NOT NULL,

    <…>
);

以下是歷史追蹤屬性的目的。

• 數據 RecChangeDate_FK 行會儲存變更生效的日期。 它可讓您在變更發生時進行查詢。
• 和 RecValidToKey 數據RecValidFromKey行會儲存資料列有效有效日期。 請考慮儲存在日期維度RecValidFromKey中找到的最早日期，以代表初始版本，並儲存01/01/9999RecValidToKey目前版本的 。
• 數據 RecReason 行是選擇性的。 它允許記錄插入版本的原因。 它可以編碼哪些屬性已變更，或者可能是來源系統指出特定商務原因的程序代碼。
• 數據 RecIsCurrent 行可讓您只擷取目前的版本。 當 ETL 進程在載入事實數據表時查閱維度索引鍵時，就會使用它。

SCD 類型 3

SCD 類型 3 變更會追蹤具有屬性的有限歷程記錄。 當需要記錄最後一個變更或一些最新的變更時，此方法可能會很有用。

此 SCD 類型會 保留有限的 歷程記錄檢視方塊。 只有在應該儲存初始和目前值時，它可能會很有用。 在此實例中，不需要過渡性變更。

例如，如果銷售人員指派給不同的銷售區域，SCD 類型 3 變更會覆寫維度數據列。 特別儲存前一個銷售區域的數據行會設定為先前的銷售區域，而新的銷售區域會設定為目前的銷售區域。

下圖描述銷售人員維度成員的前後狀態，其中其銷售區域已變更。 因為組織想要判斷任何先前的銷售區域指派，所以會觸發SCD類型 3 變更。

特殊維度成員

您可以將資料列插入代表遺漏、未知、N/A 或錯誤狀態的維度中。 例如，您可以使用下列 Surrogate 索引鍵值。

索引鍵值	用途
0	遺漏 （來源系統中無法使用）
-1	未知（事實資料表載入期間的查閱失敗）
-2	N/A （不適用）
-3	錯誤

行事曆和時間

事實數據表幾乎不會例外地儲存特定時間點的量值。 若要支援依日期（以及可能的時間）進行分析，必須有行事曆（日期和時間）維度。

來源系統通常會有行事歷維度數據，因此必須在數據倉儲中產生。 一般而言，它會產生一次，如果是行事歷維度，則會視需要擴充未來日期。

日期維度

日期（或行事曆）維度是用於分析的最常見維度。 它會為每個日期儲存一個數據列，並支援依特定日期期間篩選或分組的常見需求，例如年、季或月。

日期維度的自然索引鍵應該使用 日期 數據類型。 Surrogate 索引鍵應該使用 YYYYMMDD format 和 int 數據類型來儲存日期。 當 Surrogate 索引鍵值具有意義且人類可讀取時，這個公認的做法應該是唯一的例外狀況（與時間維度一起）。 YYYYMMDD儲存為 int 數據類型不僅有效且以數值方式排序，而且符合明確的國際標準組織 （ISO） 8601 日期格式。

以下是要包含在日期維度中的一些常見屬性。

• Year、 、 Quarter、 MonthDay
• QuarterNumberInYear， MonthNumberInYear – 可能需要排序文字標籤。
• FiscalYear， FiscalQuarter – 某些公司會計排程會從年中開始，讓日曆年度的開始/結束和會計年度不同。
• FiscalQuarterNumberInYear， FiscalMonthNumberInYear – 可能需要排序文字標籤。
• WeekOfYear – 有多種方式可標記年度周，包括具有 52 或 53 周的 ISO 標準。
• IsHoliday， HolidayText – 如果您的組織在多個地理位置運作，您應該維護多個假日清單集，讓每個地理位置觀察為個別維度，或在日期維度的多個屬性中自然化。 HolidayText新增屬性有助於識別報告假日。
• IsWeekday - 同樣地，在某些地理位置，標準工作周不是星期一到星期五。 例如，工作周是許多中東地區的星期日到星期四，而其他地區則採用為期四天或六天的工作日。
• LastDayOfMonth
• RelativeYearOffset、 RelativeQuarterOffset、 RelativeMonthOffset– RelativeDayOffset 可能需要支援相對日期篩選（例如上月）。 目前期間使用零的位移（0）：先前的期間會儲存 -1、 -2、 -3...;未來期間儲存位移 1， 2， 3...

如同任何維度，重要的是它包含支援已知篩選、群組和階層需求的屬性。 也可能有屬性會將標籤的翻譯儲存為其他語言。

當維度用來與較高粒紋事實相關時，事實數據表可以使用日期週期的第一個日期。 例如，儲存每季銷售人員目標的銷售目標數據表，會將季的第一個日期儲存在日期維度中。 替代方法是在日期數據表中建立索引鍵數據行。 例如，四分之一密鑰可以使用格式和 smallint 資料類型來儲存四分之一金鑰YYYYQ。

維度應該填入所有事實數據表所使用的已知日期範圍。 它也應該包含數據倉儲儲存目標、預算或預測相關事實的未來日期。 如同其他維度，您可能會包含代表遺漏、未知、N/A 或錯誤情況的數據列。

一般而言，在明年年初，ETL 程式應該將日期維度數據列延伸至未來特定年份。 當維度包含相對位移屬性時，必須每天執行 ETL 程式，才能根據目前日期（今天）更新位移屬性值。

時間維度

有時候，事實需要儲存在某個時間點（如一天中的時間）。 在此情況下，請建立時間（或時鐘）維度。 它可以有分鐘 （24 x 60 = 1,440 個數據列） 或甚至秒 （24 x 60 x 60 = 86,400 個數據列）。 其他可能的穀物包括半小時或小時。

時間維度的自然索引鍵應該使用 時間 數據類型。 Surrogate 索引鍵可以使用適當的格式，並儲存具有意義且可讀取人類的值，例如，使用 HHMM 或 HHMMSS 格式。

以下是要包含在時間維度中的一些常見屬性。

• Hour、 、 HalfHour、 QuarterHourMinute
• 時段標籤（上午、下午、晚上、晚上）
• 工作班次名稱
• 尖峰或離峰旗標

符合維度

某些維度可能 符合維度。 符合的維度與許多事實數據表相關，因此它們是由維度模型中的多個星號共用。 它們提供一致性，並可協助您減少進行中的開發和維護。

例如，事實數據表通常會儲存至少一個日期維度索引鍵（因為活動幾乎一律依日期和時間記錄）。 因此，日期維度是一般符合規範的維度。 因此，您應該確定您的日期維度包含與分析所有事實數據表相關的屬性。

下圖顯示 Sales 事實數據表和 Inventory 事實數據表。 每個事實數據表都與符合維度的 Date 維度和 Product 維度相關。

另一個範例是，您的員工和使用者可能是同一組人員。 在此情況下，合併每個實體的屬性來產生一個符合規範的維度可能很合理。

角色扮演維度

在事實數據表中多次參考維度時，即稱為 角色扮演維度。

例如，當銷售事實數據表有訂單日期、出貨日期和交貨日期維度索引鍵時，日期維度會以三種方式關聯。 每個方式都代表不同的 角色，但只有一個實體日期維度。

下圖描述 Flight 事實數據表。 維度 Airport 是角色扮演維度，因為它與事實數據表相關兩次，做為 Departure Airport 維度和 Arrival Airport 維度。

雜項維度

當有許多獨立維度時，垃圾維度很有用，特別是當它們組成一些屬性時，以及當這些屬性具有低基數時（很少有值）。 垃圾維度的目標是將許多小型維度合併成單一維度。 此設計方法可以減少維度數目，並減少事實數據表索引鍵的數目，因而減少事實數據表記憶體大小。 它們也有助於減少 [數據] 窗格 雜亂，因為它們向用戶呈現較少的數據表。

垃圾維度數據表通常會儲存所有維度屬性值的笛卡兒乘積，並具有 Surrogate 索引鍵屬性。

良好的候選專案包括旗標和指標、訂單狀態和客戶人口統計狀態（性別、年齡群組等）。

下圖描述名為 Sales Status 的垃圾維度，其結合了訂單狀態值和傳遞狀態值。

變質維度

當維度與相關事實相同時，可能會發生變質維度。 變質維度的常見範例是與銷售事實數據表相關的銷售訂單編號維度。 發票編號通常是事實數據表中的單一非階層屬性。 因此，不建議複製此數據來建立個別維度數據表，這是可接受的做法。

下圖描述根據 Sales Order 銷售事實數據表中數據行而變質維度的維度 SalesOrderNumber 。 這個維度會實作為擷取相異銷售訂單號碼值的檢視。

從 Power BI 語意模型化的觀點來看，您可以使用 Power Query，將變質維度建立為個別數據表。 如此一來，語意模型就符合用來篩選或群組的欄位來源為維度數據表的最佳做法，而用來摘要事實的欄位則來自事實數據表。

Outrigger 維度

當維度數據表與其他維度數據表相關時，稱為 「外線維度」。 外線維度可協助符合和重複使用維度模型中的定義。

例如，您可以建立地理維度來儲存每個郵遞區編碼的地理位置。 然後，客戶維度 和 銷售人員維度可以參考該維度，這會儲存 geography 維度的 Surrogate 索引鍵。 如此一來，客戶和銷售人員就可以使用一致的地理位置進行分析。

下圖描述 Geography 維度是一個外線維度。 它與事實數據表不直接 Sales 相關。 相反地，它透過維度和Salesperson維度間接Customer相關。

請考慮當其他維度數據表屬性儲存日期時，日期維度可以當做外線維度使用。 例如，客戶維度中的出生日期可以使用日期維度數據表的 Surrogate 索引鍵來儲存。

多重值維度

當維度屬性必須儲存多個值時，您必須設計 多重值維度。 您可以藉由建立 網橋數據表 來實作多重值維度（有時稱為 聯結數據表）。 網橋數據表會儲存實體之間的多對多關聯性。

例如，假設有銷售人員維度，而且每個銷售人員都會指派給一或多個銷售區域。 在此情況下，建立銷售區域維度是合理的。 該維度只會儲存每個銷售區域一次。 稱為網橋數據表的個別數據表會針對每個銷售人員與銷售區域關聯性儲存一個數據列。 實際上，從銷售人員維度到網橋數據表有一對多關聯性，另一個從銷售區域維度到網橋數據表的一對多關聯性。 從邏輯上講，銷售人員與銷售區域之間有多對多關聯性。

在下圖中 Account ，維度數據表與 Transaction 事實數據表相關。 因為客戶可以有多個帳戶，而且帳戶可以有多個客戶， Customer 因此維度數據表是透過 Customer Account 網橋數據表相關的。

相關內容

在本系列中的下一篇文章中，瞭解事實數據表的指引和設計最佳做法。