資料集類型說明：參照資料與主資料

歐噴資料入口的部分資料集帶有「參照資料」或「主資料」標記。本文說明這兩種標記的意義，以及如何善用它們查詢與整合資料。

參照資料（Reference Data）

正式術語：Reference Data（又稱 Lookup Data、Code Table）

主角是代碼本身。參照資料是以代碼為主鍵的查找表，來自單一官方主管機關的標準代碼系統，讓其他資料集能對應查詢。

主要特點：

  • 來自單一官方機關，具有官方權威性
  • 資料量相對小（通常不超過數十萬筆）
  • 異動頻率低，代碼一旦確立通常長期穩定
  • 主鍵即代碼，具有明確唯一性

典型範例：

  • 縣市代碼（內政部）
  • 選舉種類代碼（中央選舉委員會）
  • 學校代碼（教育部）
  • 醫事機關代碼（衛生福利部）
  • 政府機關代碼（人事行政總處）

如何使用：

當你手上有一份資料，裡面只有代碼（如 65000）沒有名稱，就可以拿這份參照資料做 JOIN，把代碼「翻譯」成人類可讀的名稱（如「新北市」）。

你的資料                   + 縣市代碼參照資料     →  完整資料
{ county_id: "65000" }    _id: "65000"           { county_id: "65000",
                          _name: "新北市"           county_name: "新北市" }

主資料（Master Data）

正式術語：Master Data（主數據管理學科：Master Data Management，MDM）

主角是「實體」本身。當同一個現實世界的實體（如一個政府機關、一位政治人物）在多個官方來源中各有不同的代碼系統，就需要整合成統一資料集，這就是主資料。

主要特點：

  • 整合多個官方來源的代碼系統
  • 需要判斷「不同代碼其實是同一個實體」（這是最難的部分）
  • 可能需要歐噴自創統一主鍵，作為跨系統的橋接依據
  • 附加價值高，但工程量也最大

兩種常見情況：

情況 A — 多套代碼整合：有官方資料，但分散在不同系統，需要比對整合。

例如「公務機關主資料」：同一個機關，在人事總處、國發會 OID、主計總處各有不同的代碼，三套系統互有差異與缺漏，需要逐一對應。

情況 B — 根本沒有官方統一清單：歐噴需要自行成為主數據提供者。

例如「政治人物主資料」：選委會、立法院、各地議會的名單分散在不同資料集，沒有任何官方機關維護統一的政治人物清單，需要歐噴自行彙整。

典型範例：

  • 公務機關主資料（整合人事總處代碼 + 國發會 OID + 主計總處代碼）
  • 政治人物主資料（整合各屆選舉候選人、立委、議員名單）

比較表

參照資料 主資料 一般交易資料
英文術語 Reference Data Master Data Transactional Data
主角 代碼 實體 事件或統計數字
代碼來源 單一官方機關 多來源整合（可能自創） —
資料量 小（<10k 筆） 中 大
異動頻率 低 中 高
Portal 標記 參照資料 badge 主資料 badge 無特別標記

可以同時標記嗎？

可以。如果某份資料集本身是一套代碼系統（參照資料），同時也已完整到足以作為某類實體的統一主數據（主資料），可以同時標記兩者。

交易資料（Transactional Data）是什麼？

未標記參照資料或主資料的資料集，通常是交易資料，以「事件」或「統計數字」為主角。

常見子類型：

子類型 說明 典型範例
定期統計型 每個週期（年/月）產生一筆彙總數字 學校招生人數、醫院病床數、政府預算
事件申報型 每個事件產生一筆記錄 政治獻金申報、標案決標、公司設立登記

交易資料通常資料量較大，適合用條件篩選查詢（時間範圍、地區、類型等）。

代碼設計原則

歐噴自創的主鍵代碼（用於整合型或代碼型資料集）遵循以下原則：

確定性（Deterministic）：給定相同規則，任何人都能獨立生成相同代碼，不依賴資料庫自動分配。

可讀性（Human-readable）：代碼本身帶有語意，方便人工辨識與 debug。

穩定性（Stable）：代碼一旦分配應盡量不變。

可攜性（Portable）：代碼可被其他資料集引用，形成資料間的關聯。

📄 查看原始 Markdown