實體資料建模
定義邏輯資料模型後，建立實體模型是一個相對簡單的程序。
您會逐一檢視每個邏輯模型表格，並將類型指定給每個項目。您可以使用任何有效的 CQL 資料類型 <資料類型>，包括基本類型、集合和使用者定義的類型。您可以識別可以建立的其他使用者定義的類型，以簡化您的設計。
指定資料類型後，您可以透過執行大小計算和測試模型運作方式來分析模型。您可能會根據您的發現進行一些調整。讓我們再次透過一個範例更詳細地說明資料建模程序。
在開始之前，讓我們先來看看 Chebotko 物理資料模型的幾個新增功能。若要繪製物理模型，您需要能夠為每一個欄位新增型別資訊。此圖顯示範例表格中每一個欄位的型別新增。
此圖包含每個表格所含鍵空間的標示，以及使用集合和使用者定義型別表示的欄位的視覺提示。請注意靜態欄位和次要索引欄位的標示。將這些內容指定為邏輯模型的一部分並沒有限制，但通常更偏重於物理資料建模考量。
飯店物理資料模型
現在讓我們開始建立物理模型。首先，您需要鍵空間來包含表格。為了讓設計保持相對簡單，請建立一個 hotel 鍵空間來包含飯店和可用性資料的表格，以及一個 reservation 鍵空間來包含預訂和房客資料的表格。在實際系統中，您可能會將表格分佈在更多鍵空間中，以區分不同的考量。
對於 hotels 表格，請使用 Cassandra 的 text 型別來表示飯店的 id。對於地址，請建立一個 address 使用者定義型別。請使用 text 型別來表示電話號碼，因為不同國家/地區的數字格式有很大的差異。
雖然對於 hotel_id 等屬性使用 uuid 型別是有道理的，但本文檔主要使用 text 屬性作為識別碼，以保持範例的簡潔性和可讀性。例如，飯店業界的常見慣例是使用「AZ123」或「NY229」等簡碼來參照屬性。此範例對 hotel_id 使用這些值，同時承認它們不一定在全球範圍內都是唯一的。
您會發現，使用唯一 ID 來唯一參照元素，並在表示其他實體的表格中使用這些 uuid 作為參照，通常是有幫助的。這有助於最小化不同實體型別之間的關聯。如果您為應用程式使用微服務架構樣式，其中有不同的服務負責每一個實體型別，這可能會特別有效。
當您努力為邏輯飯店資料模型中的各種表格建立物理表示時，請使用相同的方法。結果設計顯示在此圖中
請注意，設計中也包含 address 型別。它以星號標示，表示它是一個使用者定義型別，並且沒有識別的主要金鑰欄位。此型別用於 hotels 和 hotels_by_poi 表格中。
使用者定義型別經常被用來協助減少非主要金鑰欄位的重複，就像 address 使用者定義型別所做的那樣。這可以降低設計的複雜性。
請記住，UDT 的範圍是定義它的鍵空間。若要使用在下方設計中定義的 reservation 鍵空間中的 address，您必須再次宣告它。這只是資料模型設計中必須做出的許多權衡之一。
預訂實體資料模型
現在，讓我們檢查設計中的預訂表格。請記住，邏輯模型包含三個非正規化表格，以支援依確認編號、旅客、旅館和日期查詢預訂。對於您的實體資料模型設計的第一個反覆運算，假設您將手動管理此非正規化。請注意，此設計可以修改為使用 Cassandra（實驗性）的實體化檢視功能。
請注意，address 類型會在此鍵空間中複製，而 guest_id 會在所有表格中建模為 uuid 類型。
改編自 Cassandra, The Definitive Guide 的素材。由 O’Reilly Media, Inc. 發行。版權所有 © 2020 Jeff Carpenter、Eben Hewitt。保留所有權利。經許可使用。
