本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
在 DynamoDB 中製作關聯式資料模型的第一步
注意
NoSQL 設計思維與 RDBMS 設計不同。針對 RDBMS，您可以建立標準化的資料模型，而不需考量存取模式。您可以在稍後有新問題與查詢要求時擴展此模型。相反地，在 Amazon DynamoDB 中，您不應開始設計結構描述，除非您知道其需要回答的問題。您絕對必須事先了解企業問題和應用程式使用案例。
若要開始設計能有效擴展的 DynamoDB 資料表，您必須先執行數個步驟，以識別操作所需的存取模式與其需要支援的企業支援系統 (OSS/BSS)：
針對新應用程式，檢視活動與目標相關的使用者案例。記錄您識別的各種使用案例，並分析案例需要的存取模式。
針對現有應用程式，分析查詢記錄以找出人員目前使用系統的方式與索引鍵存取模式為何。
完成此程序後，您將收到一個清單，其看起來可能與以下類似。
| 模式 # | 存取模式描述 |
|---|---|
| 1 | 按員工 ID 查詢員工詳細資訊 |
| 2 | 按員工姓名查詢員工詳細資訊 |
| 3 | 尋找員工的電話號碼 (s) |
| 4 | 尋找客戶的電話號碼 (s) |
| 5 | 在日期範圍內為客戶取得訂單 |
| 6 | 顯示日期範圍內的所有開啟的訂單 |
| 7 | 查看所有最近僱用的員工 |
| 8 | 尋找 Warehouse 中的所有員工 |
| 9 | 取得產品訂單上的所有項目 |
| 10 | 在所有倉儲取得產品的庫存 |
| 11 | 依帳戶代表取得客戶 |
| 12 | 依帳戶代表取得訂單 |
| 13 | 取得具有任務標題的員工 |
| 14 | 依產品和倉儲取得庫存 |
| 15 | 取得產品庫存總計 |
在實際應用中，您的清單可能會更長。但此集合代表您可能會在生產環境中找到的查詢模式複雜度範圍。
DynamoDB 結構描述設計的現代方法使用彙總導向原則，根據存取模式而非剛性實體邊界來分組資料。此方法考慮多種設計模式：
單一資料表設計 - 使用複合排序索引鍵、超載的全域次要索引和相鄰清單模式，在一個資料表中存放多個實體類型
多資料表設計 - 針對具有獨立操作特性和低存取相關性的實體使用單獨的資料表，以及跨實體查詢的策略 GSIs
彙總設計 - 一律同時存取時嵌入相關資料 （訂單 + OrderItems) 或使用項目集合來識別關係 （產品 + 庫存）
這些方法的選擇取決於您的特定存取模式、資料特性和操作需求。您可以使用這些元素來建構資料，如此應用程式就可以使用對資料表或索引的單一查詢來擷取特定存取模式所需的項目。
注意
單一資料表和多資料表設計之間的選擇取決於您的特定需求。當實體具有高存取相互關聯性和類似的操作特性時，單一資料表設計可正常運作。當實體有獨立的操作需求、不同的存取模式，或是您需要明確的操作界限時，最好採用多資料表設計。本指南中的範例示範了具有策略彙總和非標準化的多資料表方法。
若要使用適用於 DynamoDB 的 NoSQL Workbench 來協助視覺化您的分割區索引鍵設計，請參閱 使用 NoSQL Workbench 建立資料模型。
