資料架構與數位基礎設施
題面來自台大官方試卷；解析與逐項自評標準（rubric）為本站依已複查來源整理的非官方內容，策略申論容許有條件且有證據的替代論點。
考古題證據邊界： 考古題只證明此範圍曾出現；題面均為申論或開放題，答案非官方，課程練習採 rubric self-review，絕不進自動計分或完整模擬考。
第一次接觸也沒關係
這堂先懂這些詞
先記住白話意思，不必急著背英文。看到正文時，再把正式名稱接回來。
關聯式資料庫綱要
也會看到：relational schema用資料表、欄位、關係與規則定義資料如何組織。
- 生活例子：
- 圖書、讀者、借閱各是一張表，靠編號連接。
- 別搞混：
- schema 是結構規則，不是資料內容本身。
SQL 資料表連接
也會看到：SQL JOIN、JOIN依共同欄位把不同資料表中相關的資料組合起來查詢。
- 生活例子：
- 用訂單的顧客編號找出顧客姓名。
- 別搞混：
- 漏掉連接條件會把每列任意配對，產生笛卡兒積。
NoSQL 與 ACID
也會看到：NoSQL、ACIDNoSQL 是不只使用關聯表的一類資料庫；ACID 是讓一組資料操作維持可靠的交易特性。
- 生活例子：
- 商品規格可用文件保存，但付款扣庫存仍可能需要全做或全不做。
- 別搞混：
- NoSQL 不是沒有結構，也不是一律不支援 ACID。
水平／垂直擴展
也會看到：horizontal scaling、vertical scaling、horizontal scale、vertical scale水平是增加更多機器分工；垂直是把單台機器升級得更強。
- 生活例子：
- 多開收銀櫃台，或換一位速度更快的收銀員。
- 別搞混：
- 水平擴展不會自動變簡單，會增加分割與協調成本。
逐項自評標準
也會看到：rubric、評分規準把好答案拆成一條條可以自行確認的要點，幫你檢查論證是否完整。
- 生活例子：
- 像交報告前用清單確認有定義、理由、例子和限制。
- 別搞混：
- 它不是官方標準答案，也不代表勾選後就取得正式分數。
以 3 題已核對題面為範圍證據，建立「定義→機制→條件與權衡→案例」的申論骨架。所有答案與 rubric 均為非官方自評材料，不提供單一標準論點或自動計分。
先抓住這幾件事
- 比較關聯式與 NoSQL 的取捨
- 撰寫可驗證的 SQL 查詢
- 分析開源授權與技術 sourcing
先想像這個場景
圖書館的目錄、書架與借閱規則
固定欄位便於一致查詢，彈性收藏便於擴充，但仍需說清一致性與授權義務。
先別急著背名詞，花十秒想一想：
如果兩個組織買了同一套技術，結果會必然相同嗎？先列出至少兩個會改變結果的條件，再往下對照。
把故事換成管理語言
| 生活中的角色 | 對應到 | MIS 概念 |
|---|---|---|
| 借閱資料使用固定欄位與關聯規則 | Relational schema、keys 與 integrity constraints | |
| 用目錄連接書籍、館藏與分館 | SQL JOIN 沿 foreign-key relationships 組合資料 | |
| 先分館統計再篩選至少兩冊 | GROUP BY、aggregate 與 HAVING | |
| 採用共享工具前先讀散布與修改條款 | OSS license obligations 與 sourcing governance |
題目出現這些字，先想到
- 先界定題目名詞與分析單位。
- 再寫出因果機制，不只列工具名稱。
- 補上適用條件、風險與替代方案。
- 最後用題目案例驗證，並指出比喻或主張的限制。
1.關聯式與 NoSQL 不是一致性有無的二分法
關聯式資料庫（Relational Database, RDBMS）把資料組織成表格（table），每張表有固定的欄位（schema），表與表之間用 foreign key 連結。它的核心強項是 ACID 交易保證（Atomicity、Consistency、Isolation、Durability）和結構化查詢語言 SQL。適合的場景：資料結構穩定、需要嚴格一致性、查詢模式以 JOIN 為主（例如銀行帳務、ERP 系統）。 NoSQL 是一類非關聯式資料庫的統稱，包括四種主要模型：Document（如 MongoDB，存 JSON-like 文件，適合彈性 schema）、Key-value（如 Redis，簡單快速的鍵值查找）、Column-family（如 Cassandra，適合大規模寫入和時間序列）、Graph（如 Neo4j，適合關係密集的資料如社群網路）。NoSQL 的核心強項是 horizontal scalability（水平擴展）和 schema flexibility（彈性 schema）。 一個常見的考試迷思是「NoSQL 不支援 ACID」。事實是：(1) 很多 NoSQL 系統在 single-document 層級支援 ACID（如 MongoDB 4.0+ 支援 multi-document transactions）；(2) CAP 定理（一致性、可用性、分區容忍性三取二）描述的是分散式系統在網路分區時的行為，不是「NoSQL 不能做一致性」；(3) 選擇 RDBMS vs NoSQL 不是「一致性有無」的二分法，而是「在特定 workload 下，哪種 trade-off 更合適」的決策。 答題框架：先描述 workload 特性（讀寫比例、資料模型複雜度、consistency 需求、scale 需求、query pattern），再依此推導適合的資料庫類型，最後說明 trade-off。
- RDBMS 強在 ACID 和 SQL JOIN，適合結構穩定、一致性要求嚴格的場景
- NoSQL 四種模型各有適用場景：document、key-value、column-family、graph
- 「NoSQL 不支援 ACID」是迷思——很多 NoSQL 在 single-document 支援 ACID
- CAP 定理描述分散式系統在網路分區時的 trade-off，不是「RDBMS 好 NoSQL 差」
- 選擇的判斷依據是 workload 特性，不是技術偏好
2.SQL 從關係與粒度開始
SQL（Structured Query Language）是 MIS 考試中少數需要實際「寫程式碼」的技能。台大 MIS 考題常出一個情境表格，要你寫 SQL 查詢或解讀查詢結果。掌握 SQL 的關鍵不在語法（那些可以查手冊），而在於思考邏輯。 寫 SQL 的正確思考順序：(1) 先決定輸出——每一列（row）代表什麼？例如「每個部門的平均薪資」代表每列是一個部門。(2) 確認需要的表——資料分散在哪些表？用什麼 key 連接？(3) JOIN——沿著 PK/FK（primary key / foreign key）連接表。注意 INNER JOIN（只保留兩邊都有的）、LEFT JOIN（保留左表全部，右表沒有的填 NULL）的差別。(4) WHERE——在 grouping 之前篩選個別記錄（row-level filter）。(5) GROUP BY——依分組欄位聚合（aggregate），常搭配 COUNT、SUM、AVG、MAX、MIN。非 aggregate 欄位必須出現在 GROUP BY 中。(6) HAVING——在 grouping 之後篩選群組（group-level filter）。(7) ORDER BY——排序，預設 ASC，用 DESC 反向。 最常出錯的地方：(1) JOIN 條件漏寫導致 Cartesian product（笛卡兒積），結果集爆炸。(2) WHERE 和 HAVING 混淆——WHERE 篩選 row，HAVING 篩選 group。(3) GROUP BY 漏列非 aggregate 欄位——在 strict mode 下會報錯。(4) NULL 的行為不直覺——NULL ≠ 0，NULL ≠ ''，NULL 參與比較的結果是 UNKNOWN，不是 TRUE 或 FALSE。 考試提醒：先在紙上畫出表的 ER 圖和想要的結果格式，再寫 SQL。邊想邊寫很容易漏 JOIN 或 GROUP BY。
- 寫 SQL 的思考順序：決定輸出粒度 → 找表和 JOIN → WHERE 篩選 → GROUP BY 聚合 → HAVING 篩選 → ORDER BY
- JOIN 條件漏寫會產生 Cartesian product（N×M 筆結果），是最常見的錯誤
- WHERE 篩選個別記錄（row-level），HAVING 篩選群組（group-level），不要混用
- 非 aggregate 欄位必須在 GROUP BY 中列出，否則結果不確定
- NULL 行為不直覺：NULL ≠ 0、NULL 參與比較的結果是 UNKNOWN
3.可擴展性同時有技術與治理成本
可擴展性（scalability）是指系統處理增長的負載（使用者數、資料量、交易量）的能力。有兩種基本策略：Vertical scaling（scale up，加強單一機器的 CPU、記憶體、儲存）簡單直接但有物理上限和單點故障風險。Horizontal scaling（scale out，增加更多機器組成叢集）理論上無上限，但引入了分散式系統的複雜度。 水平擴展需要解決的核心問題：(1) Partitioning（分片）——資料如何切分到不同節點？依 key range（範圍分片）還是 hash（雜湊分片）？分片策略影響查詢效率和 hotspot 風險。(2) Replication（複本）——資料複製到多個節點，提高可用性和讀取吞吐量。但寫入時需要決定 consistency model：strong consistency（所有節點同時更新，延遲高）vs eventual consistency（先回應再逐步同步，延遲低但短暫不一致）。(3) Coordination——分散式交易（distributed transaction）、consensus protocol（如 Raft、Paxos）增加延遲和複雜度。 治理面向同樣重要：(1) 運維能力——分散式系統的 debug、監控和故障排除遠比單機複雜，團隊是否有能力？(2) 備份與恢復——分散式系統的 backup/restore 需要考慮一致性快照。(3) 成本——水平擴展的硬體便宜但運維人力成本高。(4) 供應商依賴——cloud-native 的擴展方案（如 AWS DynamoDB auto-scaling）方便但 lock-in 風險高。 考試常見：分析某系統的擴展策略、比較 vertical 和 horizontal 的優缺點、解釋 CAP 定理在實際案例中的應用。
- Vertical scaling 簡單但有上限和單點故障；Horizontal scaling 理論無上限但複雜度高
- 水平擴展的核心問題：partitioning（資料切分）、replication（複本同步）、coordination（一致性協議）
- Strong consistency vs eventual consistency 的選擇取決於業務對不一致的容忍度
- 分散式系統的運維成本（debug、監控、故障排除）遠高於單機
- 評估擴展方案時同時考慮技術可行性和團隊操作能力
4.開源不等於沒有義務
開源軟體（Open Source Software, OSS）是指原始碼公開、允許使用者自由使用、修改和散布的軟體。但「開源」不等於「沒有規則」——不同的開源授權（license）有非常不同的義務和限制。MIS 考試常考的是理解授權條款對企業決策的影響。 主要的授權類型：(1) Permissive license（寬鬆型，如 MIT、Apache-2.0、BSD）——允許自由使用、修改和散布，包括放入商業產品中，只需保留版權聲明和免責條款。Apache-2.0 還額外提供 patent grant（專利授權），降低專利訴訟風險。(2) Copyleft license（傳遞型，如 GPL-2.0、GPL-3.0）——如果你修改了 GPL 軟體並散布，你必須以同樣的 GPL 授權公開你的修改版原始碼。這就是所謂的「傳染性」——但注意：只有在「散布」（distribution）時才觸發義務。如果只在內部使用或提供 SaaS 服務（不散布程式碼），傳統 GPL 不要求公開原始碼（但 AGPL 會）。(3) AGPL（Affero GPL）——擴展了 GPL，把「透過網路提供服務」也視為一種散布，要求公開原始碼。這對 SaaS 提供者影響最大。 企業 OSS 治理的實務考量：(1) License compliance——專案中用了哪些 OSS？各有什麼授權？有沒有衝突（例如 GPL 和 proprietary 混用）？需要用 SCA（Software Composition Analysis）工具掃描。(2) Security——OSS 的安全漏洞需要持續追蹤（如 CVE 資料庫），因為沒有供應商幫你修補。(3) Sustainability——依賴的 OSS 專案是否活躍維護？單一維護者的專案有 bus factor 風險。(4) 法律風險——授權違規可能導致訴訟或被迫公開原始碼。 考試提醒：不要用「傳染性」一詞簡化 GPL——要說清楚觸發條件（散布）和不觸發的情境（內部使用、SaaS 在傳統 GPL 下）。法律判斷需要由專業律師確認，考試答案只能基於公開的授權條款進行分析。
- Permissive（MIT、Apache）允許商業使用只需保留聲明；Copyleft（GPL）散布時須以同授權公開原始碼
- GPL 的義務只在「散布」時觸發——內部使用和傳統 SaaS 不需公開原始碼，但 AGPL 例外
- Apache-2.0 的 patent grant 降低專利訴訟風險，是企業偏好的寬鬆授權
- 企業 OSS 治理需要 SCA 工具掃描授權合規、CVE 追蹤安全漏洞、評估專案活躍度
- 不要用「傳染性」簡化 GPL——精確說明觸發條件和不觸發情境
一起搭作答骨架
範例 1：如何回答「資料架構與數位基礎設施」的比較題？
- 定義比較軸與分析單位。
- 各寫一條作用機制。
- 加入至少兩項條件或風險。
- 用案例與指標驗證。
所以作答主軸是：可接受的答案不只一種；關鍵是條件透明、概念正確、推論可追蹤，並能說明限制。
範例 2：題目要求提出建議時，如何避免只列 buzzwords？
- 先指出要改善的問題。
- 說明建議如何改變流程、資訊或激勵。
- 指定責任人與衡量方式。
- 補上失敗訊號與替代方案。
所以作答主軸是：建議應包含 action、mechanism、metric 與 risk，而不是只寫「導入 AI／雲端／平台」。
這裡最容易寫偏
- 把工具名稱當成因果解釋
- 沒有說明分析層級與前提
- 只寫單一立場，不處理權衡
- 把非官方參考解析當唯一標準答案
- 引用時事卻沒有日期與來源邊界
換你快速判斷
先用自己的話說出定義、機制、條件與取捨，再展開答案。
1關聯式資料庫與 NoSQL：答題時先定義什麼？
先界定 關聯式資料庫與 NoSQL 的分析單位、核心機制與適用條件。
MIS 概念不能只背名詞；定義後必須說明它如何改變資訊、協調、成本、能力或風險。
2關聯式資料庫與 NoSQL：完整申論至少要補哪三類內容？
機制、條件／權衡、可觀察指標與限制。
以「主張→因果機制→成立條件→案例／指標→限制」自我檢查，合理替代論點亦可接受。
3SQL、schema 與查詢：答題時先定義什麼？
先界定 SQL、schema 與查詢 的分析單位、核心機制與適用條件。
MIS 概念不能只背名詞；定義後必須說明它如何改變資訊、協調、成本、能力或風險。
4SQL、schema 與查詢：完整申論至少要補哪三類內容？
機制、條件／權衡、可觀察指標與限制。
以「主張→因果機制→成立條件→案例／指標→限制」自我檢查，合理替代論點亦可接受。
5開源軟體、授權與 sourcing：答題時先定義什麼？
先界定 開源軟體、授權與 sourcing 的分析單位、核心機制與適用條件。
MIS 概念不能只背名詞；定義後必須說明它如何改變資訊、協調、成本、能力或風險。
6開源軟體、授權與 sourcing：完整申論至少要補哪三類內容？
機制、條件／權衡、可觀察指標與限制。
以「主張→因果機制→成立條件→案例／指標→限制」自我檢查，合理替代論點亦可接受。
最後用考古題自評
請先完成自己的申論，再依非官方解析和逐項自評標準檢查；不使用 A–E 假選項或虛假分數。
開始本課申論自評參考來源
- Management Information Systems: Managing the Digital Firm, 17th Edition — Kenneth C. Laudon; Jane P. Laudon
- Apache License, Version 2.0 — Apache Software Foundation
- GNU General Public License, version 3 — Free Software Foundation
- PostgreSQL Documentation: The SQL Language — PostgreSQL Global Development Group