半導体工場のMESにおいて、データベース(DB)は最も重要かつ複雑な部分です。
実際の商用MESでは数千〜数万のテーブルが存在しますが、その「核(Core)」となる主要な5つのテーブルと、その関係性(ER(Entity Relationship)図の構造)に絞って解説します。
これを理解すれば、MESがどうやってデータを保持しているかの全体像が見えます。
1. MESデータベースの「核」となる5つのテーブル
MESのデータは大きく分けて
「マスタデータ(定義)」と
「トランザクションデータ(実態・履歴)」の2種類があります。
A. マスタデータ(工場のルールブック)
① 装置テーブル (M_EQUIPMENT)
役割: 工場にある全ての装置のリスト。
主なカラム:
EQ_ID(PK): 装置ID (例: ETCH-01)EQ_TYPE: 装置の種類 (例: DryEtcher)STATE: 現在の状態 (IDLE, RUN, DOWN) ← リアルタイムで更新されるLOCATION: 設置場所
② プロセスフロー定義 (M_PROCESS_FLOW & M_STEP)
役割: 「どの順序で、何をするか」という手順書。通常はヘッダ(フロー全体)と明細(ステップ)に分かれます。
主なカラム (Stepテーブル):
FLOW_ID(PK): フローIDSTEP_SEQ(PK): 順番 (10, 20, 30…)STEP_NAME: 工程名 (例: Gate_Etch)RECIPE_ID: 使用するレシピ名TARGET_EQ_TYPE: どの種類の装置を使うか (リンク用)
B. トランザクションデータ(今の状態と過去の記録)
③ ロット情報 (T_LOT / WIP)
役割: 「今」工場にあるウェーハ(ロット)の状態。最も頻繁に更新(UPDATE)されるテーブルです。
主なカラム:
LOT_ID(PK): ロット番号CURRENT_FLOW_ID: 従っているフロー (FK)CURRENT_STEP_SEQ: 今どこにいるか (FK)STATUS: 状態 (WAITING, PROCESSING, HOLD)QTY: 枚数 (25枚など)
④ 処理履歴 / トランザクションログ (H_TXN_HISTORY)
役割: 「いつ、誰が、何をしたか」の全記録。絶対にUPDATEされず、INSERT(追記)のみ行われます。ここがビッグデータになります。
主なカラム:
TXN_ID(PK): 一意の履歴IDTIMESTAMP: 日時LOT_ID: 対象ロットACTION: 操作内容 (TrackIn, TrackOut, Move)EQ_ID: 使用した装置USER_ID: 操作者
2. ER図(Entity Relationship)の概念イメージ
これらのテーブルがどう繋がっているか、関係性を整理します。
LOT (多) ⇔ (1) PROCESS FLOW
1つのロットは、必ず1つのフロー定義に従います。「次どこへ行くか」はフロー定義を参照します。
LOT (多) ⇔ (1) EQUIPMENT
加工中(PROCESSING)の瞬間、1つのロットは特定の1台の装置に紐付きます。
HISTORY (多) ⇔ (1) LOT
1つのロットは、数百〜数千行の履歴データを持ちます。
3. 設計上の「半導体ならでは」の難所
一般的なWebアプリのDB設計とは異なる、MES特有の難しいポイントがあります。
① 「履歴」のデータ量が異常に多い
問題: 365日24時間、秒単位で数千のロットが動くため、
H_TXN_HISTORYテーブルはすぐに数億行を超え、検索が遅くなります。解決策: パーティショニング (Partitioning) を使います。「2024年1月分」「2月分」というように物理的にテーブルを分割し、古いデータは安いストレージ(アーカイブ)へ逃します。
② マスタデータの「バージョン管理」
問題: レシピやフローは頻繁に改善されます。「今日の朝10時まではVer.1で、10時以降はVer.2で流したい」という要求があります。
解決策: 単に上書き更新するのではなく、
VERSION_NOとACTIVE_FLAGを持ち、「現在有効なバージョンはどれか」を厳密に管理する設計が必要です。
③ 階層構造 (Hierarchy)
工場 > エリア (Bay) > 装置群 (Group) > 装置 (Equipment) > チャンバー (Chamber)
装置といっても、「4つの部屋(チャンバー)を持つ装置」の場合、MESは「チャンバーAは故障中だが、チャンバーBは使える」といったレベルまで管理する必要があります。ここの正規化設計が腕の見せ所です。
まとめ
MESのデータベースは、「現在の状態 (WIP)」を高速に処理しつつ、「過去の膨大な履歴 (History)」を確実に積み上げるという、相反する要件を満たすように設計されています。
このDB設計の基礎がしっかりしていないと、工場が大きくなった時に「画面が重くて開かない」「履歴検索に1時間かかる」といったシステム障害に直結します。













