型付き辺: 出 3 / 入 0
ADR-0047: スタースキーマ型データモデルを採用する
- Status: Accepted
- Mode: Standard
- Kruchten Type: Property
- Scope: product
- Implementation Status: Done (既存実装が暗黙的に準拠済み)
- 起案者: [email protected]
- 起案日時 (JST): 2026-05-16 (旧 arch_data_model.md 付録「ADR-0008」を独立 ADR として再採番)
- 承認日時 (JST): 2026-05-16
- Deciders: [email protected]
本 ADR は元々
docs/architecture/arch_data_model.md付録に「ADR-0008」として埋め込まれていたが、正規 ADR-0008 (Vertex AI 集約) と番号衝突していたため、ADR-0047 として独立採番・切り出した。決定内容そのものに変更はない (誤字修正範疇の再採番)。
1. コンテキスト
1.1 背景 (Background)
BizLP GAS Accounting は Google Spreadsheet 上に構築された管理会計システムで、データ量とディメンション軸の増加に伴いデータモデルの設計指針が必要になった。当初 arch_data_model.md 付録に「ADR-0008」として記録していたが、正規 ADR-0008 (Vertex AI 集約) との番号衝突を解消するため独立採番する。
1.2 現状 (Current State / As-Is)
32_wrk_invoice / 33_wrk_bank をトランザクションテーブル、11〜15 番台のマスタをディメンション参照元とする構造が既に実装上は成立しているが、明文化された設計原則が ADR レジストリ上には存在せず、arch_data_model.md 付録の「ADR-0008」のみが唯一の根拠だった。
1.3 課題 (Problem)
- ファクトテーブル (32_wrk_invoice) とマスタデータの関係が暗黙的で、新規開発者がデータモデルを理解するまでに時間がかかる
- 集計処理 (
600_report/6*_datamart_*.js) がどのマスタを参照しているかがコードを読まないと分からない - 新しい分析軸 (ディメンション) を追加する際の設計指針がない
- arch_data_model.md 付録の「ADR-0008」が正規 ADR-0008 (Vertex AI 集約) と番号衝突しており、参照時に混乱を招く
1.4 制約・要件 (Constraints & Requirements)
- Google Spreadsheet は SQL JOIN をサポートしない (ルックアップは VLOOKUP /
indexOfベース) - GAS 1 関数の実行時間は 6 分以内 (集計時のマスタ参照回数を抑える必要)
- 既存実装 (
32_wrk_invoice/33_wrk_bank/ 11〜15 番台マスタ) を破壊変更しない範囲で明文化する
1.5 目標 (Goals / To-Be)
ファクト中心 + 非正規化ディメンションのスタースキーマを正規 ADR として明文化し、データモデル変更時の判断基準・新規ディメンション追加時の設計指針を提供する。
2. 判断基準 (Decision Drivers)
- GAS 6 分制限内で集計が完了すること (マスタ参照回数の最小化)
- 既存実装との整合性 (破壊変更なしで明文化できること)
- 新規開発者のオンボーディング容易性 (ファクト⇔ディメンションの関係が一目で分かる)
- 監査対応 (どのトランザクションがどのマスタ値を参照したかが追跡可能)
3. 検討した代替案 (Considered Options)
- 案 A: スタースキーマ (ファクト中心 + 非正規化ディメンション) を明文化
- Good, because Spreadsheet 環境では JOIN 不可なので非正規化が現実解。集計時のマスタ参照を最小化でき GAS 6 分制限と整合する
- Good, because 既存実装が既に暗黙的に採用しており、明文化コストが低い
- Bad, because マスタ側の名称変更時にファクトテーブルの既存行が不整合になりうる (整合性チェックで検出する運用が必要)
- 案 B: スノーフレークスキーマ (ディメンションの正規化)
- Good, because データ冗長性が減りマスタ更新時の整合性が保ちやすい
- Bad, because 多段ルックアップが GAS 6 分制限を圧迫する。Spreadsheet 環境では現実的でない
- 案 C: ドキュメントベース (テーブル間の関係を定義せず、処理単位で記述)
- Good, because 個別処理の文脈に閉じて記述できるため学習コストが局所最適化される
- Bad, because 全体のデータモデル像が永遠に明文化されず、新規ディメンション追加時の指針が立たない
4. 決定 (Decision Outcome)
採用: 案 A (スタースキーマ)。32_wrk_invoice と 33_wrk_bank をファクトテーブル、11〜15 番台のマスタをディメンションテーブルとするスタースキーマ型データモデルを正規 ADR として明文化する。理由: Spreadsheet 環境では JOIN 不可・GAS 6 分制限ありという 2 制約下で、マスタ参照を最小化できる非正規化が必須であり、既存実装も既にこの構造に従っているため。
5. 影響 (Consequences)
5.1 正の影響 (Good)
- Good, because データモデルの設計意図が明確になり、新規開発者のオンボーディングが容易になる
- Good, because 新しいディメンション (分析軸) 追加時の設計指針が確立される
- Good, because マスタ参照パターン (名称ベース結合) のルールが統一される
- Good, because ADR-0008 (Vertex AI) との番号衝突が解消され、参照の混乱がなくなる
5.2 負の影響 (Bad)
- Bad, because マスタ側の名称変更時に、ファクトテーブルの既存行が不整合になるリスクがある (データ整合性チェックで検出する運用負荷が発生)
- Bad, because 非正規化によりデータ冗長性が増加する (Spreadsheet ではストレージコスト無視可能だが、Cloud SQL 等への移行時はスキーマ再設計が必要)
5.3 中立 / トレードオフ (Neutral / Trade-offs)
- Neutral, because データ量が Spreadsheet の限界 (500 万セル) に近づいた場合、Cloud SQL 等への移行時にスキーマの再設計が必要になりうる (将来課題として認識)
- Neutral, because 既存実装がすでに暗黙的に従っているため、新規実装コストは発生しない (明文化のみ)
Status / Mode / Scope は 2026-06-11 に遡及追加 (ADR-0031 corrigendum パターン)。出典: Status = 旧形式「## ステータス」節の機械転記 / Mode = 旧 README §既存 ADR 一覧の推定値 (git 履歴) / Scope = ADR-0049 4 層分類の遡及付与 (PR レビューで確定)。
6. 撤退条件 / 再評価トリガー (Rollback Plan / More Information)
- 再評価トリガー:
- データ量が Spreadsheet の限界 (500 万セル) の 70% に到達した場合
- Cloud SQL / BigQuery 等の外部 DB への移行を本格検討する判断が出た場合
- ディメンション数が 20 を超え、スタースキーマでの可読性が損なわれた場合
- 判定タイミング: 半年に 1 回、データ量モニタリング時
- 判定主体: [email protected]
Confirmation (準拠確認 / Fitness Function)
- 検証手段: 新規ディメンション・ファクトテーブル追加時のレビューチェックリスト (
docs/architecture/arch_data_model.mdのデータモデル節への追記必須・ファクト⇔ディメンションの関係図への反映必須) - 実行頻度: PR ごと (データ定義変更を含む PR で人手レビュー)
- 違反時の対応: PR レビューで指摘・arch_data_model.md への追記を required change として返却
7. 参照 (References)
- 関連 ADR:
- 関連ドキュメント: docs/architecture/arch_data_model.md (本 ADR の決定が反映されたデータモデル全体像)
- 旧記録: 本 ADR は元々 arch_data_model.md 付録に「ADR-0008」として埋め込まれていたが、正規 ADR-0008 (Vertex AI 集約) との番号衝突解消のため ADR-0047 として再採番した