資料品質：驗證、整合與可追溯性

35 分鐘

Merge / Join 與資料關係

學習目標：使用 1:1、1:N、N:1 合併，辨識 many-to-many row explosion。

合併兩個表之前，最重要的問題不是「程式怎麼寫」，而是「這個 join 預期是什麼關係」。關係想錯了，程式一樣會跑，但結果的列數與意義會完全不對。

master = pd.read_csv("DS102_Company_Master.csv")

# site_id 本身會在不同公司間重複，必須搭配 company_id 才是唯一的據點
joined = site_long.merge(master, on="company_id", how="left", validate="m:1")
joined.shape[0] == site_long.shape[0]  # 1:N/N:1 的正確合併不應改變列數

• 合併前先問：這應該是 1:1、1:N 還是 N:1？
• 在程式碼中用 merge(..., validate="1:1" / "1:m" / "m:1") 讓 pandas 幫你檢查，關係不符會直接報錯
• 合併後一定要檢查列數，並和「合併前的預期列數」核對，不能只看有沒有報錯
• 看到列數比預期多很多，先懷疑 join 鍵是否唯一，而不是急著使用結果

重點: 合併資料前先確認關係，合併後一定要核對列數，不能只看程式有沒有報錯。

30 分鐘

Units、Definitions 與可比性

學習目標：只有在有明確換算規則時統一單位；辨識同名但不同定義的欄位。

兩份資料的欄位名稱相同，不代表它們可以直接合併或比較。單位不同（公噸 vs 公斤）與定義不同（含稅 vs 未稅營收）是兩種最常見、卻最容易被忽略的問題。

# 假設另一個來源用公斤記錄廢棄物量
waste_kg_source["waste_tonnes"] = waste_kg_source["waste_kg"] / 1000
waste_kg_source["original_unit"] = "kg"  # 保留原始單位，供日後追溯

• 合併不同來源前，先列出每個來源對同一個欄位的定義與單位
• 單位轉換只能用已經記錄下來、可查證的換算規則，不能憑感覺假設
• 保留原始單位或原始定義的欄位，方便日後追溯與核對
• 如果無法確認兩個來源的定義是否一致，寧可分開呈現，也不要強行合併

重點: 欄位名稱相同不代表可以直接合併；單位與定義都要先核對，才有可比性。

40 分鐘

Validation Rules 與 Data Contracts

學習目標：建立範圍、允許值、唯一性、參照完整性與 schema 驗證。

清理完的資料，如果沒有明確的驗證規則，很容易在下一次資料更新時悄悄壞掉。把預期規則寫成可執行的檢查，就是一份簡單的 data contract：資料如果不符合，應該被攔下來，而不是被默默接受。

checks = {
    "unique_company_year_key": clean["company_year_key"].is_unique,
    "employees_non_negative": bool((clean["employees"] >= 0).all()),
    "sector_allowed": master["sector"].isin(["Manufacturing", "Food & Beverage", "Retail", "Logistics"]).all(),
    "site_company_id_exists": site_long["company_id"].isin(master["company_id"]).all()
}
checks

• 每一條規則都先用已知有問題的練習資料測試過一次，確認它真的會回傳 False
• 規則的訊息要清楚說明哪一欄、哪個條件不符合，而不是只回傳 True / False
• 範圍檢查要同時考慮下限與上限，不要只檢查其中一邊
• 允許值清單要和資料字典上的分類保持一致，新增分類時要同步更新清單

重點: 把預期規則寫成可執行的檢查，資料不符合時就該被攔下來，而不是被默默接受。

30 分鐘

Data Dictionary、Lineage 與 Cleaning Log

學習目標：記錄欄位定義、來源、轉換、假設、未解問題與責任人。

Data dictionary 說明「每個欄位是什麼」；cleaning log 說明「實際上對資料做了什麼」。兩者一起使用，才能讓別人（或未來的自己）重現你的判斷，而不是只能相信最終的數字。

cleaning_log.append({
    "issue": "revenue_m_ntd stored as text with a thousands comma",
    "evidence": "column dtype was object before this step",
    "decision": "stripped commas and converted to float",
    "reason": "the underlying value is numeric; comma is formatting only",
    "residual_uncertainty": "assumes every comma is a thousands separator"
})

重點: Data dictionary 說明欄位是什麼；cleaning log 說明實際做了什麼；兩者一起，別人才能重現你的判斷。

45 分鐘

Independent Lab：建立可信的 Clean Dataset

學習目標：獨立完成 inspect、clean、reshape、integrate、validate、document 的完整流程，產出 clean dataset、驗證摘要與可稽核 cleaning report。

• 前往 DS 102 實作頁面
• 預覽下載練習資料（含刻意植入的品質問題）
• 下載 Independent Lab Starter Notebook
• 預覽下載資料字典（中文）
• 預覽下載資料字典（英文）

1. 1載入並檢查
   載入練習資料，檢查 shape、dtypes、缺失值與重複列。
2. 2清理並記錄
   處理每一個發現的問題，同時在 cleaning log 寫下 Issue、Evidence、Decision、Reason 與 Residual uncertainty。
3. 3建立候選鍵
   建立 company_year_key，確認清理後沒有重複。
4. 4寫驗證檢查
   至少寫三項驗證檢查：一項唯一性、一項範圍或允許值，以及至少一項你自己決定的檢查。
5. 5整理輸出
   產出清理後的資料、驗證摘要（validation summary）與完整的 cleaning log。
6. 6寫下限制
   寫一句這份清理後的資料仍然無法回答的問題。
7. 7AI 協助紀錄
   如果使用了 AI，寫下 AI 協助了什麼，以及你自己驗證了什麼。

• 一份可以從上到下重新執行的 Notebook
• 一份記錄至少四個處理決策的 cleaning log
• 至少三項驗證檢查與其結果
• 一份驗證摘要（列數、唯一性、缺失值數量等）
• 至少一項限制或未解問題
• AI 協助紀錄（若有使用）

• 確認 company_year_key 在清理後確實沒有重複
• 確認至少一項驗證規則曾經在故意製造的錯誤資料上失敗過
• 確認 cleaning log 中的每一筆決策都寫了 Reason，而不是只有 Decision

重點: 一份可信的 clean dataset，除了乾淨的數字，還要有能重現的清理過程與能失敗的驗證規則。