分析用のデータ基盤は、目的に応じていくつかの層を組み合わせて作ります。データレイクは構造化・半構造化・非構造化データを元の形式のまま大量に蓄積する場所で、読み出すときにスキーマを当てはめるスキーマオンリードが基本です。データウェアハウス（DWH）は、整備・統合したデータを分析しやすい形で保持する場所で、書き込む時点でスキーマを決めるスキーマオンライトです。データマートは特定の部門や用途向けにDWHから切り出したデータの集まりです。データレイクの柔軟さとDWHの管理性・性能を両立させる構成をレイクハウスといいます。

DWHでは、分析の対象となる数値（売上金額など）を持つファクトテーブルを中心に、分析の切り口（日付・店舗・商品など）を持つディメンションテーブルを周囲に配置するスタースキーマがよく使われます。ディメンションをさらに正規化して階層的に分けたものがスノーフレークスキーマです。データを取り込む処理には、抽出・変換してから格納するETLと、先に格納してから基盤内で変換するELTがあります。

そのほか、複数ノードで並列処理するMPP（大規模並列処理）、保存と計算の資源を独立して増減できるストレージとコンピュートの分離、データを物理的に移動せず複数のデータソースをまとめて問い合わせるデータ仮想化・フェデレーションクエリ、トランザクション処理と分析処理を1つの基盤で両立させるHTAPも重要な用語です。BIツールでは、集計の粒度を細かくするドリルダウン、粗くするドリルアップ、ある軸の値で切り出すスライス、複数軸で範囲を絞るダイスといった多次元分析（OLAP）の操作を使います。

データパイプラインはデータの収集・変換・格納を自動化する一連の処理です。一定期間分をまとめて処理するバッチ処理と、発生したデータを逐次処理するストリーム処理があり、ストリーム処理では一定時間ごとに区切って集計するウィンドウ処理を使います。元のデータベースの変更（追加・更新・削除）を検知して連携先へ反映するCDC（変更データキャプチャ）は、全件コピーより負荷が小さく鮮度の高い連携を実現します。

パイプラインの信頼性を高めるには、同じ処理を何度実行しても結果が変わらないべき等性を持たせることが重要です。べき等であれば、失敗時のリトライや、過去の期間のデータを後から再処理するバックフィルを安全に行えます。メッセージの配信保証には「最大1回（欠落の可能性）」「少なくとも1回（重複の可能性）」「正確に1回」の考え方があり、少なくとも1回の場合は受け側でべき等にして重複に備えます。ディメンションの属性変化の履歴を保持する手法は緩やかに変化するディメンション（SCD）と呼ばれ、ソース側の項目追加などに追従することをスキーマエボリューションといいます。

データ基盤はクラウド上に構築されることが多くなっています。クラウド事業者と利用者が責任範囲を分担する共有責任モデル、データセンター群であるアベイラビリティゾーン（AZ）を複数使うマルチAZ構成、地域単位で冗長化するマルチリージョン構成を押さえましょう。災害対策の指標として、どの時点のデータまで戻せればよいかを示すRPO（目標復旧時点）と、どれだけの時間で復旧させるかを示すRTO（目標復旧時間）があります。コスト面では、アクセス頻度に応じてホット／ウォーム／コールドに置き場所を変えるストレージ階層化や、実利用に合わせて資源量を見直すライトサイジング、FinOpsによるコストの可視化が有効です。

データベースは、外部スキーマ（利用者から見たビュー）・概念スキーマ（全体の論理構造）・内部スキーマ（物理的な格納構造）の3層スキーマアーキテクチャで整理され、これによりデータの独立性が保たれます。関係データベース以外にも、キーと値の組で高速に読み書きするキーバリュー型、JSONなどの文書単位で格納するドキュメント指向、列単位で格納し集計に強い列指向、ノードとエッジで関係をたどるグラフデータベースがあり、要件に応じて選択します（科目B 3-3）。

設計は概念設計（E-R図で実体と関連、カーディナリティ（1対多など）を表す）→論理設計（表・主キー・外部キー・制約を決める）→物理設計（索引、容量見積り、ファイル編成など性能面を決める）の順に進めます。業務上の意味を持たない連番などを主キーにしたものをサロゲートキーといいます。

正規化は、データの重複をなくして更新時の不整合（更新時異状）を防ぐための手順です。

分析用途や性能上の理由から、あえて表を結合済みの形で持つ非正規化を行うこともあります。その場合は更新時の整合性をどう保つかを併せて設計します。

SQLは役割により、表やビュー・索引を定義するDDL（CREATE、ALTER、DROP）、データを操作するDML（SELECT、INSERT、UPDATE、DELETE）、権限を管理するDCL（GRANT、REVOKE）に分かれます。DDLでは主キー制約・一意性制約・参照制約（外部キー）・検査制約（CHECK）を定義でき、参照先の削除に合わせて参照元も削除するCASCADEなどの動作も指定します。

集計の基本形は次のとおりです。WHEREは集約前の行を絞り込み、HAVINGはグループ化後の集計結果を絞り込みます。

SELECT 店舗コード, SUM(売上金額) AS 売上合計
  FROM 売上
 WHERE 売上日 >= '2026-04-01'
 GROUP BY 店舗コード
HAVING SUM(売上金額) > 1000000
 ORDER BY 売上合計 DESC

結合では、両方の表に一致する行だけを返す内部結合（INNER JOIN）と、左側の表の行をすべて残し、一致しない行の右側の列をNULLにする左外部結合（LEFT OUTER JOIN）の違いが重要です。科目Bのサンプル問題でも、SQLの結果行数を見積もる問題が出題されています。結合キーが1対多の場合、結果の行数は「多」側の件数に応じて増える点に注意しましょう。

副問合せのうち、外側の行ごとに内側の問合せが評価されるものを相関副問合せ（EXISTSでよく使う）といいます。行をまとめずに集計値や順位を各行に付けるウィンドウ関数も頻出です。

SELECT 店舗コード, 売上日, 売上金額,
       SUM(売上金額) OVER (PARTITION BY 店舗コード
                          ORDER BY 売上日) AS 累計売上,
       RANK() OVER (ORDER BY 売上金額 DESC) AS 順位
  FROM 売上

PARTITION BYでグループを分け、ORDER BYで並べた順に累計や順位を計算します。GROUP BYと違い、元の行数はそのまま残ります。

トランザクションはACID特性（原子性・一貫性・隔離性・耐久性）を満たす必要があります。複数のトランザクションを同時に実行すると、隔離性が弱い場合に次のような異常現象が起こります。ダーティリードは他のトランザクションの未コミットの更新を読んでしまうこと、ノンリピータブルリードは同じ行を2回読む間に他者に更新されて値が変わること、ファントムリードは同じ条件で2回検索する間に他者の追加・削除で行数が変わることです。SQLの隔離性水準と防げる現象の関係は次のとおりです。

同時実行制御には、読取り用の共有ロックと更新用の専有ロックを使うロック方式があります。ロックを獲得する段階と解放する段階を分ける2相ロッキングプロトコルに従えば直列化可能性が保証されます。互いに相手のロック解放を待ち合うデッドロックには、資源のロック順序を統一する、タイムスタンプを使うWait-Die方式（古いものは待ち、新しいものはアボート）やWound-Wait方式（古いものは新しいものをアボートさせ、新しいものは待つ）などで対処します。データの複数版を保持して読取りと書込みが互いを待たないようにするMVCC（多版同時実行制御）も広く使われますが、スナップショットを読む方式では、2つのトランザクションがそれぞれ制約を満たす前提で別の行を更新し、結果として制約が破れるライトスキューが起こり得ます。

障害回復では、トランザクション障害時に更新前ログを使って取り消すロールバック（バックワードリカバリ）と、媒体障害時にバックアップ（ダンプ）をリストアしてから更新後ログで再実行するロールフォワード（フォワードリカバリ）を使い分けます。チェックポイントはメモリ上の更新をディスクに書き出す時点で、回復時に処理すべきログの範囲を短くします。

分散データベースでは、複数ノードの更新をまとめて確定する2相コミットメント（準備フェーズ→確定フェーズ）が使われます。CAP定理は、ネットワーク分断が起きたとき一貫性（C）と可用性（A）を同時には完全に満たせないことを示し、可用性を優先して最終的に一致すればよいとする考え方がBASE特性・結果整合性です。データをキー範囲などで複数ノードに分けるシャーディングや、Apache Hadoop・Apache Sparkといった分散処理フレームワークも大規模データの基盤として押さえておきましょう。