NoSQL Workbench のサンプルデータモデル

モデラーとビジュアライザーのホームページには、NoSQL Workbench に付属のサンプルモデルが多数表示されます。このセクションでは、これらのモデルとその可能性のある用途について説明します。

従業員データモデル

このデータモデルは、入門モデルです。これは、一意のエイリアス、名、姓、職名、マネージャー、およびスキルなどの従業員の基本的な詳細を表します。

このデータモデルは、複数のスキルを持つなどの複雑な属性を扱うなど、いくつかの技術を示しています。このモデルは、セカンダリインデックス DirectReports によって達成されたマネージャーとその部下の従業員による 1 対多リレーションシップの例でもあります。

このデータモデルによって容易になるアクセスパターンは次のとおりです。

• Employee というテーブルによって容易になる、従業員のログインエイリアスを使用した従業員レコードの取得。

• Name という Employee テーブルのグローバルセカンダリインデックスによって容易になる、名前による従業員の検索。

• DirectReports という従業員のテーブルのグローバルセカンダリインデックスによって容易になる、マネージャーのログインエイリアスを使用したマネージャーの直接レポートの取得。

ディスカッションフォーラムデータモデル

このデータモデルは、ディスカッションフォーラムを表します。このモデルを使用すると、お客様は開発者コミュニティとやり取りし、質問をしたり、他のお客さま顧客の投稿に応答することができます。各 AWS サービスには専用フォーラムがあります。フォーラムにメッセージを投稿することで、誰でも新しいディスカッションスレッドを開始できます。各スレッドは任意の数の返信を受け取ります。

このデータモデルによって容易になるアクセスパターンは次のとおりです。

• Forum というテーブルによって容易になる、フォーラムの名前を使用したフォーラムのレコードの取得。

• Thread というテーブルによって容易になる、フォーラムの特定のスレッドまたはすべてのスレッドの取得。

• PostedBy-Message-Index という Reply テーブルのグローバルセカンダリインデックスによって容易になる、投稿ユーザーの E メールアドレスを使用した返信の検索。

ミュージックライブラリデータモデル

このデータモデルは、大量の楽曲コレクションを持ち、ダウンロード数の多い楽曲をほぼリアルタイムで紹介するミュージックライブラリです。

このデータモデルによって容易になるアクセスパターンは次のとおりです。

• Songs というテーブルによって容易になる曲レコードの取得。

• Songs というテーブルによって容易になる、曲の特定のダウンロードレコードまたはすべてのダウンロードレコードの取得。

• Song というテーブルによって容易になる、曲の特定の月別ダウンロード数レコードまたはすべての月のダウンロード数レコードの取得

• Songs というテーブルによって容易になる曲のすべてのレコード (曲のレコード、ダウンロードレコード、月別ダウンロード数レコードを含む) の取得。

• DownloadsByMonth という Songs テーブルのグローバルセカンダリインデックスによって容易になる、ほとんどのダウンロード曲の検索。

スキーリゾートデータモデル

このデータモデルは、毎日収集される各スキーリフトについて大量のデータを収集するスキーリゾートを表します。

このデータモデルによって容易になるアクセスパターンは次のとおりです。

• SkiLifts というテーブルによって容易になる、指定されたスキーリフトやリゾート全体の動的および静的なすべてのデータの取得。

• SkiLifts というテーブルによって容易になる、特定の日付のスキーリフトまたはリゾート全体のすべての動的データ (一意のリフトライダー、積雪、雪崩の危険、リフト状況を含む) の取得。

• SkiLifts というテーブルによって容易になる、特定のスキーリフトのすべての静的データ (リフトが経験豊富なライダーのみを対象とする場合、リフトが上昇する垂直フィート、リフトのライディング時間を含む) の取得。

• SkiLiftsByRiders という SkiLifts テーブルのグローバルセカンダリインデックスによって容易になる、一意のライダーの総数によってソートされる特定のスキーリフトまたはリゾート全体について記録されたデータの日付の取得。

クレジットカードオファーデータモデル

このデータモデルは、クレジットカードオファーアプリケーションで使用されます。

クレジットカードプロバイダは、時間の経過とともにオファーを生成します。これらのオファーには、手数料なしの残高振替、与信限度額の増加、金利の低減、キャッシュバック、航空会社マイルが含まれます。お客様がこれらのオファーを承認または拒否すると、それに応じてそれぞれのオファーステータスが更新されます。

このデータモデルによって容易になるアクセスパターンは次のとおりです。

• メインテーブルによって容易になる、AccountId を使用した取引先レコードの取得。

• セカンダリインデックス AccountIndex によって容易になる、いくつかの予測項目を持つすべてのアカウントの取得。

• メインテーブルによって容易になる、AccountId を使用したアカウントおよびそれらのアカウントに関連付けられているすべてのオファーレコードの取得。

• メインテーブルによって容易になる、AccountId および OfferId を使用した取引先およびそれらの取引先に関連付けられた特定のオファーレコードの取得。

• セカンダリインデックス ACCEPTED/DECLINED によって容易になる、OfferType、AccountId、および OfferType を使用した取引先に関連付けられた特定の Status のすべての GSI1 オファーレコードの取得

• メインテーブルによって容易になる、OfferId を使用したオファーおよび関連するオファー項目レコードの取得。

ブックマークデータモデル

このデータモデルは、お客様のストアブックマークに使用されます。

お客様は多くのブックマークを持つことができ、ブックマークは多くのお客様に属することができます。このデータモデルは、多対多の関係を表します。

このデータモデルによって容易になるアクセスパターンは次のとおりです。

• customerId による単一のクエリで、ブックマークだけでなくお客様データも返せるようになりました。

• クエリ ByEmail インデックスは、E メールアドレスごとにお客様データを返します。ブックマークは、このインデックスによって取得されないことに注意してください。

• クエリ ByUrl インデックスは、URL ごとにブックマークデータを取得します。同じ URL を複数のお客様からブックマークすることができるため、インデックスのソートキーとして customerId があることに注意してください。

• クエリ ByCustomerFolder インデックスは、各お客様のフォルダごとにブックマークを取得します。