物理データモデリング

では、物理モデルの作業に取り掛かりましょう。まず、テーブルを格納するためのキースペースが必要です。設計を比較的単純にするために、ホテルと可用性データのテーブルを格納する `hotel` キースペースと、予約とゲストデータのテーブルを格納する `reservation` キースペースを作成します。実際のシステムでは、懸念事項を分離するために、テーブルをさらに多くのキースペースに分割する場合があります。

`hotels` テーブルの場合、Cassandra の `text` 型を使用して、ホテルの `id` を表します。住所の場合は、`address` ユーザー定義型を作成します。国によって番号の形式にかなりのばらつきがあるため、電話番号を表すには `text` 型を使用します。

`hotel_id` などの属性には `uuid` 型を使用するのが理にかなっていますが、このドキュメントではサンプルをシンプルで読みやすくするために、識別子として主に `text` 属性を使用しています。たとえば、ホテル業界の一般的な慣例では、「AZ123」や「NY229」のような短いコードでプロパティを参照することです。この例では、これらが必ずしもグローバルに一意ではないことを認識しながら、これらの値を `hotel_ids` に使用します。

要素を一意に参照するために一意の ID を使用し、他のエンティティを表すテーブルでこれらの `uuids` を参照として使用すると便利なことがよくあります。これにより、異なるエンティティタイプ間の結合を最小限に抑えることができます。これは、アプリケーションにマイクロサービスアーキテクチャスタイルを使用している場合に特に効果的であることが証明される可能性があります。このスタイルでは、各エンティティタイプを担当する個別のサービスが存在します。

論理ホテルデータモデルのさまざまなテーブルの物理表現を作成するために作業するときは、同じアプローチを使用します。結果として得られる設計を次の図に示します

`address` 型も設計に含まれていることに注意してください。これはユーザー定義型であることを示すためにアスタリスクで指定されており、主キー列は識別されていません。この型は、`hotels` および `hotels_by_poi` テーブルで使用されます。

ユーザー定義型は、`address` ユーザー定義型で行われたように、非プライマリキー列の重複を減らすのに役立つことがよくあります。これにより、設計の複雑さを軽減できます。

UDT のスコープは、それが定義されているキースペースであることに注意してください。以下の設計で定義されている `reservation` キースペースで `address` を使用するには、再度宣言する必要があります。これは、データモデル設計で考慮する必要のある多くのトレードオフの1つにすぎません。

次に、設計の予約テーブルを見てみましょう。論理モデルには、確認番号、ゲスト、ホテルと日付による予約のクエリをサポートするために、3つの非正規化テーブルが含まれていたことを思い出してください。物理データモデル設計の最初の反復では、この非正規化を手動で管理することを前提としています。この設計は、Cassandra の (実験的な) マテリアライズドビュー機能を使用するように修正できることに注意してください。

`address` 型がこのキースペースで再現され、`guest_id` がすべてのテーブルで `uuid` 型としてモデル化されていることに注意してください。

Cassandra, The Definitive Guide から翻案された資料。 O’Reilly Media, Inc. 発行。Copyright © 2020 Jeff Carpenter, Eben Hewitt. 無断複写・転載を禁じます。許可を得て使用。