4. テーブルタイプとスキーマ設計
この章では、保存するデータの意味と変更・クエリ要件を、Machbase DBMS のテーブルと列へ具体化します。 稼働を確認したら、まず1行に何を保存するかを決めます。慣れたタイプを先に選んですべてのデータを 当てはめると、履歴、更新範囲、保持ポリシーの要件が衝突することがあります。
各タイプの役割を初めて学ぶ場合は、データモデルの概念を先に読んでください。 この章では概念を実際のスキーマと検証可能な設計に結び付けます。
設計の出発点
テーブル名より先に、1行の意味を文章で定義します。「1つのセンサーの1回の計測」、 「設備状態の変化イベント」、「1台の機器の現在の設置情報」は異なる単位です。 同じ設備のデータでも、保存上の役割は異なります。
次の問いに答えると、テーブルを選ぶ根拠が得られます。
| 設計上の問い | 決定事項 |
|---|---|
| 1行は何を表すか | 計測、イベント、現在状態、参照データのどれを保存するか |
| 対象をどう識別するか | タグ名、業務キー、重複収集の識別基準 |
| 時刻や軸は何を意味するか | 計測時刻、受信時刻、距離・位置 |
| 値をどう解釈するか | 単位、型の範囲、精度、NULL・欠測処理 |
| どの変更が必要か | 追記、過去値の補正、キー変更、削除範囲 |
| どのクエリが多いか | タグ・時間範囲、条件検索、キー検索、集計、結合 |
| どれだけ保持するか | 元データ・集計・参照履歴の期間と再起動後の復旧 |
| 失敗時に何を戻すか | テーブル・API 別のトランザクション範囲と再試行・再構築手順 |
データサイズや入力頻度だけでタイプを決めないでください。同じ行の値が同じ観測やイベントを表すことを 確認し、関連データは共通識別子で結合できるようにします。結合キーがあることと、DBMS がすべての 業務上の関係を自動的に強制することは別です。対応する制約をタイプ別に確認します。
この章の構成
| 順序 | 節 | 設計結果 |
|---|---|---|
| 4.1 | テーブルタイプの選択 | 変更・クエリ・永続性・Edition の要件に合うタイプ |
| 4.2 | スキーマオブジェクトの定義 | 列と型、識別子、デフォルト・制約、インデックス、VIEW |
| 4.3 | データ変更ポリシー | 許可する補正・削除と失敗処理の範囲 |
| 4.4 | アンチパターン | 要件に合わない選択を修正する根拠 |
| 4.5 | モデリングパターン | 履歴・状態・参照データを組み合わせる具体例 |
4.1でタイプを選び、4.2と4.3で構造と変更方針を定義します。4.4のアンチパターンを点検し、 4.5のパターンを実データに適用します。比較表は出発点です。実際の SQL と条件は、 リンクしたテーブル別の文書とリファレンスで確認します。
設備監視の例
温度、アラーム、機器情報、画面表示用の状態をすべて同じ方式で保存する必要はありません。
| データ | 1行の意味 | 検討する保存方法 |
|---|---|---|
| 温度履歴 | 1センサーが特定時刻に測定した値 | タグ・時間範囲クエリと集計用の TAG |
| アラーム履歴 | 特定時刻のアラームイベント | 追記型イベント用の LOG |
| 機器の参照データ | 機器の名前・場所・許容基準 | LOOKUP、または複数変更をトランザクションにまとめる場合の TRANSACTION |
| 画面用の現在状態 | 再計算できる最新状態 | 元データと再構築経路がある場合の VOLATILE |
この表は例であり、固定の正解ではありません。複数項目が1イベントに含まれる場合や、更新・保持要件が 異なる場合は、別の設計が適切なこともあります。TRANSACTION は Standard Edition の対応も確認します。
温度履歴に最新の機器情報を結合すると、結果は現在の名前や場所で解釈されます。計測時点の場所や 許容基準が必要なら、元データに保存するか参照データの変更履歴を設計します。現在状態キャッシュも 更新する場合、元データ入力とキャッシュ更新を1トランザクションと考えず、失敗後の再構築方法を用意します。
小さなデータで設計を検証
運用規模へ拡大する前に、代表データと頻出クエリで次を確認します。
- 正常値だけでなく NULL、欠測、境界値、重複・遅延データを入力します。
- 元データと集計のクエリが同じ時刻基準・単位・NULL 方針を使うか確認します。
- 補正・削除・再入力後の結果と、他の行や集計への影響を比較します。
- 再起動後も保持するデータと再生成する状態を分け、復旧順序を確認します。
- 入力量、クエリ範囲、同時実行数を増やし、スループット・遅延・保存領域を測定します。
入力エラー、旧スキーマを使うアプリケーション、再起動後の復旧も、通常経路と併せて設計します。 スキーマ変更前には既存データとビュー・ROLLUP・クライアントの依存関係を確認し、 必要なら新テーブルへ移行して検証後に切り替えます。
実装はテーブル別利用ガイドと開発とアプリケーション連携、 測定は性能チューニングに進みます。