Физическое моделирование данных#

После создания логической модели данных процесс создания физической модели является относительно простым. Каждой таблице логической модели назначаются типы данных для каждого элемента. Можно использовать любой допустимый CQL-тип данных, включая базовые типы, коллекции и пользовательские типы данных. Дополнительно возможно определить новые пользовательские типы, упрощающие проектирование.

После присвоения типов данных проводится анализ модели: выполняются расчеты размеров и проверяется работоспособность модели. Возможно внесение корректировок на основе полученных результатов.

Рассмотрим процесс физического моделирования подробнее, разобрав конкретный пример. Рассмотрим некоторые дополнения к обозначениям Чеботко для физических моделей данных. Чтобы создавать физические модели, необходимо добавлять информацию о типах данных для каждого столбца.

На рисунке ниже показано добавление типа для каждого столбца в примере таблицы.

На рисунке отображены пространства ключей (keyspaces), содержащие таблицы, визуальные обозначения столбцов, представленных коллекциями и пользовательскими типами. Отмечены статические столбцы и столбцы вторичных индексов. Важно отметить, что назначение статических и индексируемых столбцов является частью процесса логического проектирования, однако чаще всего эти аспекты относятся именно к физическому уровню моделирования.

Создание физической модели отеля#

Перейдем непосредственно к созданию физической модели.

Для начала нужно создать пространства ключей (keyspaces), чтобы хранить таблицы. Для сохранения простоты дизайна, создадим два ключевых пространства:

• hotel: будет содержать таблицы с информацией о гостиницах и доступности номеров.

• reservation: будет содержать таблицы с информацией о бронированиях и гостях.

На практике система может потребовать разделения таблиц еще больше, чтобы лучше разделять обязанности между компонентами системы.

Для таблицы hotels используйте тип данных text для представления id отеля. Для адреса создайте пользовательский тип данных (user-defined type) address. Телефонный номер представьте также через тип данных text, так как форматы номеров сильно различаются между странами.

Хотя логично было бы использовать тип uuid для атрибутов вроде hotel_id, в данном документе в основном используются атрибуты типа text в качестве идентификаторов, чтобы сохранить примеры простыми и понятными. Например, распространенная конвенция в гостиничной индустрии — ссылаться на объекты недвижимости с помощью коротких кодов, таких как AZ123 или NY229. В этом примере такие значения используются для hotel_ids, при этом отмечается, что они не обязательно уникальны глобально.

Использование уникальных идентификаторов позволяет однозначно ссылаться на элементы и эффективно использовать UUID в таблицах, представляющих другие сущности. Это помогает уменьшить взаимозависимость различных типов сущностей. Особенно полезно это становится, когда используется архитектурный стиль микросервисов, где каждая сущность обслуживается отдельным сервисом.

При создании физического представления таблиц логической модели отеля применяется аналогичный подход.

Итоговый дизайн представлен на следующем рисунке.

Тип данных address также включен в дизайн. Он обозначен звездочкой (*), чтобы указать, что это пользовательский тип данных (UDT), и у него не определены столбцы с первичным ключом. Этот тип используется в таблицах hotels и hotels_by_poi.

Пользовательские типы данных (UDT) часто применяют для сокращения дублирования неключевых столбцов, как это сделано с UDT address. Это помогает упростить дизайн.

Важно помнить, что область видимости UDT ограничена пространством ключей, где он определен. Чтобы использовать address в пространстве ключей reservation, описанном в данном дизайне, необходимо повторно объявить этот тип. Это лишь один из множества компромиссов, с которыми приходится сталкиваться при проектировании модели данных.

Физическая модель бронирования#

Рассмотрим физическую реализацию таблиц бронирования в проекте.

Логический уровень содержит три денормализованные таблицы, предназначенные для поддержки запросов по номеру подтверждения брони, гостю, гостинице и дате. На первом этапе проектирования физической модели предполагается вручную реализовать данную денормализацию. Данная физическая модель может впоследствии быть пересмотрена и адаптирована для использования экспериментальной функции материализованных представлений (materialized views) в Distributed DB.

Тип данных address повторяется в рамках данного пространства ключей. Поле guest_id во всех таблицах представлено типом данных uuid.