物理数据建模
定义逻辑数据模型后，创建物理模型是一个相对简单的过程。
您遍历每个逻辑模型表，为每个项目分配类型。您可以使用任何有效的 CQL 数据类型 <data-types>，包括基本类型、集合和用户定义类型。您可以识别可以创建的附加用户定义类型，以简化您的设计。
分配数据类型后，您可以通过执行大小计算和测试模型的工作方式来分析模型。您可以根据您的发现进行一些调整。让我们再次通过一个示例更详细地介绍数据建模过程。
在开始之前，让我们看一下 Chebotko 符号在物理数据模型中的几个补充。要绘制物理模型，您需要能够为每个列添加类型信息。此图显示了在示例表中为每个列添加类型的示例。
该图包括包含每个表的键空间的指定，以及使用集合和用户定义类型表示的列的视觉提示。请注意静态列和二级索引列的指定。在逻辑模型中没有限制将这些列分配为一部分，但它们通常更多地是物理数据建模的关注点。
酒店物理数据模型
现在让我们开始创建物理模型。首先，您需要键空间来包含表。为了使设计相对简单，创建一个 hotel 键空间来包含酒店和可用性数据的表，以及一个 reservation 键空间来包含预订和客户数据的表。在实际系统中，您可能将表划分为更多键空间，以分离关注点。
对于 hotels 表，使用 Cassandra 的 text 类型来表示酒店的 id。对于地址，创建一个 address 用户定义类型。使用 text 类型来表示电话号码，因为不同国家/地区的号码格式存在很大差异。
虽然使用 uuid 类型来表示 hotel_id 等属性是有意义的，但本文档主要使用 text 属性作为标识符，以保持示例的简单性和可读性。例如，酒店行业中的一种常见约定是使用简短代码（如“AZ123”或“NY229”）来引用酒店。此示例使用这些值作为 hotel_ids，同时承认它们不一定是全局唯一的。
您会发现，使用唯一 ID 来唯一引用元素并使用这些 uuids 作为其他实体表示的表的引用通常很有帮助。这有助于最大程度地减少不同实体类型之间的耦合。如果您对应用程序使用微服务架构风格，其中有单独的服务负责每个实体类型，这可能特别有效。
在创建逻辑酒店数据模型中各种表的物理表示时，您使用相同的方法。生成的图表显示在此图中
请注意，address 类型也包含在设计中。它用星号标记，表示它是一个用户定义类型，并且没有标识任何主键列。此类型用于 hotels 和 hotels_by_poi 表中。
用户定义类型经常用于帮助减少非主键列的重复，就像使用 address 用户定义类型一样。这可以降低设计的复杂性。
请记住，UDT 的范围是定义它的键空间。要在下面设计的 reservation 键空间中使用 address，您必须再次声明它。这只是您在数据模型设计中必须做出的许多权衡之一。
