資料知識地圖 · 2. 資料來源
DB / API
資料庫與 API 串接
觀念教學
取得資料的兩條主幹道:一條往內,從自家資料庫撈;一條往外,透過 API 跟別人的系統要。
核心觀念
關聯式資料庫(Relational Database)如 MySQL、PostgreSQL:資料表加 SQL 查詢,擅長結構化資料與交易處理。NoSQL 如 MongoDB:文件、鍵值等彈性結構,擅長半結構化資料與高速寫入。外部資料靠 REST API 或 GraphQL:REST 一個端點對一種資源;GraphQL 讓用戶端指定「只回傳這幾個欄位」,減少來回傳輸。
白話理解
零售公司做銷售分析:訂單放 PostgreSQL(交易要安全)、商品評論放 MongoDB(格式彈性)、天氣資料跟氣象開放 API 要。分析的第一步不是建模,是把三路資料撈出來、串起來。
選用重點
- 結構固定、需要交易一致性 → 關聯式資料庫
- 欄位多變、寫入量大 → NoSQL
- 外部串接注意 API 回應時間、呼叫次數上限(Rate Limit)與版本異動
- 內部撈數顧查詢效能:善用索引、避免全表掃描,別把正式交易庫查掛
- 大量分析請走倉儲或唯讀副本,分析與交易分流
🎯 口訣:內部找 DB、外部靠 API;結構穩用 SQL、彈性快用 NoSQL。
iPAS 考點
分類題:MongoDB 屬 NoSQL 文件型資料庫;訂單交易系統選關聯式。差異題:GraphQL 與 REST 的差別在用戶端可指定回傳欄位。判斷關鍵字:「彈性 Schema、水平擴充」選 NoSQL;「交易、關聯查詢、一致性」選關聯式,兩組別搞反。
應用場景
評估指標
iPAS 歷屆考題詳解(4 題)
先自行作答,再展開詳解。題目出處均為 iPAS AI 應用規劃師正式考題,著作權屬原主辦單位。
在圖形資料庫(Graph Database)中建模社群平台資料時,若每筆「按讚」行為都包含時間戳記(Timestamp)與裝置類型(Device Type)等資訊。若希望同時保留使用者與貼文之間的互動關係,並能有效查詢「按讚」的行為屬性,下列哪一種設計方式最為合適?
- A將「按讚」視為節點（Node），與使用者建立邊（Edge）
- B將「按讚」資訊作為邊的屬性（Property）儲存，連結使用者與被按讚的貼文節點
- C把「按讚」資訊直接寫入使用者節點中作為屬性
- D建立「按讚紀錄表」並將資料存入關聯式資料庫
看正解與逐選項詳解
正解:B
某企業欲建構知識圖譜（Knowledge Graph），以整合內部的研究報告、專利資料與專家知識，並支援語意查詢與關聯推理。若希望模型能具備良好的語意擴展性與高效推理能力，下列哪一種圖模型設計最為合適？
- A僅以節點（Node）與邊（Edge）表示，所有資訊存放於節點屬性中
- B將資料結構建為 RDF（Resource Description Framework）三元組（Subject–Predicate–Object）
- C使用文件型資料庫儲存內容，並以標籤（Tag）連接節點
- D採用關聯式資料庫儲存對應關係，並搭配預建索引加速查詢
看正解與逐選項詳解
正解:B
某電商平台正在重構商品資料架構，需同時支援三個系統：商品管理後台需處理結構化與半結構化資料（如巢狀庫存與不同類別商品欄位差異），並支援複雜條件查詢；AI推薦系統需儲存高維向量（1,536 維）並進行高效相似度搜尋（高 QPS）；即時庫存服務則要求ACID且延遲低於 10ms，以避免超賣。在此情境下，哪種資料庫架構最適合？
- A全部使用關聯式資料庫，透過 JSON 欄位儲存巢狀資料，並以延伸套件支援向量搜尋，同時以資料列鎖（Row-level Lock）處理庫存扣減
- B商品資料使用文件型資料庫，向量搜尋使用專用向量資料庫，庫存服務使用關聯式資料庫，各系統依需求選擇最適合的資料庫
- C全部使用文件型資料庫，同時處理商品資料、向量搜尋與庫存服務，以統一技術棧降低維運複雜度
- D商品與向量資料使用搜尋引擎型資料庫，並以文件更新機制處理庫存扣減
看正解與逐選項詳解
正解:B
某AI平台的資料量已達 PB 級，單一資料庫節點已無法負荷，決定採用分片（Sharding）策略。下列何者為 Sharding設計的主要目的？
- A增加資料備份數量以提升安全性
- B將查詢結果預先計算以降低延遲
- C將資料水平分割以提升擴展性與負載均衡
- D將資料壓縮以減少儲存成本
看正解與逐選項詳解
正解:C