DEA / ドメイン2 データストア管理
データモデリング (Redshift・DynamoDB・Lake Formation)
データモデリングは、データをどんなテーブルと列に分け、どうつなぐかを決める設計です。同じ「注文」のデータでも、 の分析用、 のアプリ用、の共有用で、最適な形はまったく違います。DEA-C01 では、Redshift・DynamoDB・ (データレイク) のスキーマ設計 (スキル 2.4.1) として、、正規化と非正規化、 (SCD)、アクセスパターンからの設計が問われます。
Point
- ファクト (fact): 売上金額や数量など、集計の対象になる出来事の記録です。
- ディメンション (dimension): 顧客、商品、日付、店舗など、ファクトを切り分ける観点です。
- SCD = Slowly Changing Dimension (緩やかに変化するディメンション) です。顧客の住所のように、ときどき変わる属性の履歴の扱い方です。
- 和訳
- Dimension: 次元、観点
- Weblio英和辞書「dimension」
概要
| 保管先 | 設計の出発点 | 典型の形 |
|---|---|---|
| (DWH) | 分析で使う問い (どの観点で何を集計するか) | (ファクト + ディメンション) |
| (アプリ) | アプリのアクセスパターン (どのキーで何を取るか) | 非正規化した1つまたは少数のテーブル |
| / (業務) | データの整合性と更新のしやすさ | 正規化したテーブル |
| ( Data Catalog + ) | 共有する利用者と権限、読み方 | ゾーン・領域ごとのデータベース、パーティションを切ったテーブル |
試験では、「分析向けか、アプリ向けか」「更新が多いか、読み取りが多いか」から、正規化の度合いとテーブルの形を選びます。
主要技術
①スタースキーマとスノーフレークスキーマ ⚠️ 頻出
| 形 | 内容 | 長所 | 短所 |
|---|---|---|---|
| ファクトの周りに、非正規化したディメンションを1段だけ置く | 結合が少なく、クエリが単純で速い。 ツールと相性がよい | ディメンションに同じ値が重複する | |
| スノーフレークスキーマ | ディメンションをさらに正規化して分ける (商品 → カテゴリ → 部門) | 重複が少なく、更新しやすい | 結合が増えて遅く、クエリが複雑 |
列指向で圧縮の効く では、ディメンションの重複による容量の増加は小さいため、スタースキーマが基本です。
②正規化と非正規化
| 方式 | 内容 | 向く保管先 |
|---|---|---|
| 正規化 | 同じ情報を1か所にだけ持ち、テーブルを分ける。更新の矛盾が起きない | / () |
| 非正規化 | 読み取りに必要な情報をあらかじめまとめて持つ。結合が減る | ()、、の curated ゾーン |
業務 DB の正規化されたテーブルを、そのまま Redshift やデータレイクに写すと、分析のたびに多くの結合が必要になります。取り込み後の変換で、分析しやすい非正規化した形に直します。
③緩やかに変化するディメンション (SCD) ⚠️ 頻出
顧客の住所や担当営業のように、ディメンションの属性はときどき変わります。過去の売上を「当時の住所」で集計したいか、「今の住所」で集計したいかで、扱いを決めます。
| 型 | 変わったときの扱い | 履歴 | 向くケース |
|---|---|---|---|
| タイプ1 | 上書きする | 残らない | 誤記の訂正、履歴が不要な属性 |
| タイプ2 | 新しい行を追加し、有効開始日・終了日・現行フラグで区別する | すべて残る | 当時の値で集計したい (監査、地域別の売上の推移) |
| タイプ3 | 「前の値」の列を追加する | 直前の1回分だけ | 直前との比較だけでよい |
タイプ2では、業務上の顧客 ID とは別に、行ごとに一意のサロゲートキー (代理キー) を付け、ファクトはサロゲートキーで結合します。 では、ステージングテーブルと で、変わった行の終了日を更新し新しい行を挿入します (「Redshift へのロードとアンロード」の章)。
④Redshift のスキーマ設計
| 観点 | 設計の要点 |
|---|---|
| ファクトテーブル | 大きい。よく結合するディメンションのキーを (KEY) に、日付をの先頭にする |
| 小さなディメンション | 分散スタイル ALL で全ノードに置き、結合時の再分散をなくす |
| 大きなディメンション | ファクトと同じ結合キーで KEY 分散にする |
| 半 | SUPER 型の列に入れ、PartiQL で取り出す。よく使う属性は通常の列に出す |
| 制約 | 主キー・外部キー・一意制約は宣言できるが強制されない。オプティマイザーの判断材料になるため、正しい場合だけ宣言する |
| 列の型 | 必要な長さの VARCHAR にする (大きすぎる長さはメモリを浪費する)、日付は DATE / TIMESTAMP |
分散スタイル・ソートキーの詳細は「」の章で扱います。
⑤DynamoDB のスキーマ設計
では、アクセスパターンを先に列挙し、それぞれを1回の GetItem か Query で満たせるようにキーを設計します (「Amazon DynamoDB」の章)。
| パターン | 設計の例 |
|---|---|
| 顧客と、その注文一覧を一度に取る | = CUSTOMER#123、 = PROFILE と ORDER#2026-10-17#987 (シングルテーブル設計) |
| 注文 ID だけで1件取る | のパーティションキー = 注文 ID |
| 多対多 (学生と講座) | 隣接リスト: 同じテーブルに両方向の項目を持ち、GSI で逆向きに引く |
| 最新の状態だけ頻繁に読む | 最新の状態の項目と、履歴の項目を分ける |
| リレーショナルとの違い | DynamoDB での考え方 |
|---|---|
| 結合で関連データを集める | 関連データを同じパーティションキーにまとめ、1回の Query で取る |
| 正規化して重複を避ける | 読み取りのために非正規化し、重複を受け入れる |
| 後から任意のクエリを書く | 新しいアクセスパターンには GSI を追加する。任意の集計は へエクスポートして分析する |
⑥データレイクのテーブル設計 (Glue Data Catalog と Lake Formation)
では、テーブルの形に加えて、誰に何を見せるかを設計に含めます。
| 観点 | 設計の要点 |
|---|---|
| データベースの分け方 | ゾーン (raw / cleansed / curated) や業務の領域 (販売、人事) ごとに分ける。権限を付ける単位になる |
| テーブルの形式 | などの列指向。更新・削除が必要なら (「と 」の章) |
| パーティション | よく絞り込む列 (日付、地域) で切る |
| 機密な列 | の列を別のテーブルに分ける、または の列レベルの権限やタグで隠す |
| タグ | 機密度や領域を としてデータベース・テーブル・列に付け、タグで権限を付ける |
Lake Formation の列・行・セルの権限と LF タグによるアクセス制御の詳細は「AWS Lake Formation」の章で扱います。設計の段階で「権限を分けたい列を、タグや別テーブルで分けられる形にしておく」ことが、データモデリングの側の役割です。
試験対策
①判断マトリクス
| 問題文のキーワード | 選ぶもの |
|---|---|
| で多くの観点から集計、クエリを単純に速く | |
| ディメンションの重複を減らし更新しやすく (結合は増えてよい) | スノーフレークスキーマ |
| 過去の売上を当時の住所で集計したい | タイプ2 (行を追加、有効期間) |
| 履歴は不要、最新の値だけでよい | SCD タイプ1 (上書き) |
| 直前の値との比較だけ | SCD タイプ3 (前の値の列) |
| 小さなディメンションとの結合で再分散が起きる | ALL |
| で顧客と注文を1回で取得 | 同じ + の接頭辞 (シングルテーブル設計) |
| DynamoDB で後から別の検索軸が必要 | を追加 |
| で機密な列だけ一部の人に隠す | 列の分離、 の列レベル権限・ |
| 業務 DB の正規化テーブルを分析しやすくしたい | 変換で非正規化してスタースキーマにする |
②よくある誤答
- に業務 DB と同じ正規化した形でテーブルを作ること。結合が増えて遅くなります。
- をリレーショナル DB のように正規化して、アプリ側で結合すること。
- タイプ1 で、当時の値での集計という要件を満たそうとすること。上書きで履歴が消えます。
- Redshift の主キー制約で重複が防げると考えること。強制されません。