哪個是結構化數據的例子？
在資料處理中，下列何者屬於「結構化數據」的例子？
資料處理中，依格式不同可以分成「結構化數據」和其他類型。題目給出四個儲存方式不同的資料例子。
問你：下列哪一個例子屬於「結構化數據」？
一句話總結
MySQL 資料庫中的訂單記錄是結構化數據，因為它存在關聯式資料庫的表格裡，每一欄有明確定義、可直接用 SQL 查詢。JSON/XML 是半結構化，純文字對話是非結構化。
先感受問題：同樣是「訂單資料」，存的地方不同差很多
「快樂電商」的資料工程師蘇建宏要分析過去一年的訂單，找出哪些商品最賺錢。他手上有四份資料：
- 資料庫裡的訂單表（order_id、customer_id、amount、date 每欄都定義好了）
- 物流 API 回傳的 JSON 檔（有鍵值對，但格式不完全固定）
- 供應商寄來的 XML 產品目錄（有標籤結構，但巢狀複雜）
- 客服系統的對話紀錄 txt 檔（客服隨手記的文字，沒有格式）
哪份資料可以直接 SELECT * FROM orders WHERE date > '2024-01-01'？只有第一份，因為它住在關聯式資料庫裡，欄位清楚、格式固定、可以直接查。
這就是結構化數據的本質：住在資料庫表格裡，欄位有定義，可以直接查詢計算。
如果所有資料都是「非結構化」，分析師的日子
假設「快樂電商」在 MySQL 導入之前，所有訂單都是 Excel 或文字檔，蘇建宏要分析就會碰到：
- 欄位定義不統一：A 同事記「金額」，B 同事記「total」，同一件事不同名字，無法合併計算
- 格式不一致：日期有人寫「2024/01/15」，有人寫「15-Jan-2024」，合起來計算就出錯
- 無法快速查詢：一年三十萬筆訂單，只能用 Ctrl+F 搜尋，完全沒辦法跑統計
- 重複和缺漏沒有約束：同一張訂單被記兩次，或者必填欄位空著，資料庫無法阻止這種情況
- 多人協作出亂子：每個人都能任意修改格式，資料越來越亂
把資料放進有結構定義的關聯式資料庫，才能解決這些問題。
結構化數據是什麼、住在哪裡
「快樂電商」把訂單放進 MySQL 之後，有幾個關鍵特性：
明確的 Schema（綱要）。訂單表定義了七個欄位：order_id（整數）、customer_id（整數）、product_name（文字，最多 100 字元）、amount（小數）、status（文字）、created_at（日期時間）。每一筆資料都必須符合這個格式，不能亂填。
可以直接用 SQL 查詢和計算。蘇建宏輸入一行指令就能得到「2024 年第一季、金額超過 1000 元的訂單總數」。這是結構化數據的核心優勢。
資料完整性約束。資料庫能強制「order_id 不能重複」「amount 不能是負數」，保護資料品質。
反過來，JSON 和 XML 雖然有階層和鍵值對，但格式不固定（JSON 的鍵可以任意增減），屬於半結構化數據。純文字對話完全沒有格式定義，是非結構化數據。
這就是選項 A 的正確理由：MySQL 資料庫的訂單記錄存在關聯式資料庫裡，有明確的表格結構和欄位定義，是最典型的結構化數據。
技術版：結構化、半結構化、非結構化的分類地圖
AI 和資料工程領域把資料分三類，考試必考：
結構化數據（Structured Data）：存在關聯式資料庫（RDBMS）中，有固定的表格格式和 Schema，每筆資料都有明確欄位和型別。例子：MySQL、PostgreSQL、Oracle 資料庫裡的交易記錄、員工資料、庫存數量。可直接用 SQL 查詢。
半結構化數據（Semi-structured Data）：有自描述標記（標籤或鍵值對），但格式不完全固定，不能直接放進關聯式表格。例子：JSON、XML、YAML、CSV（有時算這類）、NoSQL 資料庫（MongoDB）。需要解析（parsing）才能使用。
非結構化數據（Unstructured Data）：沒有預定義格式，電腦無法直接「理解」其內容。例子：純文字文件、電子郵件內文、社群媒體貼文、圖片、影片、音訊。需要 NLP 或電腦視覺等 AI 技術才能提取資訊。
一個常考的混淆點：JSON 和 XML 有鍵值對和標籤，感覺很「結構化」，但它們是半結構化。因為 JSON 的鍵可以自由增刪、值的型別不固定，不像關聯式資料庫有嚴格的 Schema 約束。
為什麼出題者考這題：AI 專案的第一步是了解手上有什麼數據、數據的格式如何，決定用什麼工具處理。搞錯資料類型，在資料準備階段就會走錯路。
為什麼其他選項是錯的
B以 JSON 格式儲存的商品訂單資訊
用 {"order_id": 1, "product": "書包", "amount": 599} 這種鍵值對格式存的訂單。
JSON 是半結構化數據。雖然有鍵值對，但 JSON 的鍵名可以不固定、值可以是任意型別、可以無限巢狀，沒有嚴格的 Schema 定義。它不能直接放進關聯式表格，需要解析才能分析。
看到 JSON「有格式、有鍵值對」就以為是結構化的人。結構化的關鍵是「關聯式資料庫裡有 Schema 定義的表格」，不是「有格式就算」。
C用 XML 標注的產品目錄
用 <product><name>書包</name><price>599</price></product> 這種標籤格式記錄的產品資訊。
XML 跟 JSON 一樣是半結構化數據。有標籤、有階層結構，但標籤名稱可以自由定義、不同文件可以有不同結構，需要 XML 解析器才能讀取，不能直接 SQL 查詢。
以為 XML「很嚴格、有標籤規範」就等於結構化的人。XML 的嚴格性是在語法層面（標籤要閉合），不是在資料模型層面的結構化。
D儲存在純文字檔案中的客服對話紀錄
客服和顧客的對話文字，存成 .txt 檔，沒有任何格式標記。
純文字是最典型的非結構化數據。沒有欄位定義、沒有固定格式、電腦無法直接理解語意，需要 NLP 技術（如情感分析、主題分類）才能提取有用資訊。
幾乎不會有人選 D，但如果腦子一片空白就胡亂猜，這是最容易排除的選項。
同個考點下次怎麼變形
CSV 檔案算結構化還是半結構化？
CSV 有欄位、用逗號分隔，感覺很「結構化」？
通常被歸類為半結構化，因為 CSV 雖然有欄位，但沒有強制型別定義（任何值都能填進去）、沒有資料完整性約束、不支援複雜查詢。不過業界有時也把「有明確表頭的 CSV」算作結構化。考試若出現 CSV，通常是半結構化。
電子郵件算哪種數據類型？
電子郵件有寄件人、收件人、日期、主旨，感覺有些結構？
電子郵件是半結構化。郵件標頭（Header：From、To、Date、Subject）是結構化的，但郵件正文（Body）是自由格式文字，是非結構化的。整體來說是兩種的混合，業界通常歸為半結構化。
為什麼 AI 模型訓練大多需要處理非結構化數據？
資料庫那麼好用，為什麼 AI 要碰亂七八糟的非結構化資料？
因為世界上 80% 以上的資料是非結構化的（圖片、影片、文字、語音），而這些恰好是人類溝通和感知的主要形式。AI 要理解人類語言、看懂圖片，就必須處理非結構化數據。結構化數據容易分析但資訊量有限，非結構化數據才是 AI 能力邊界的主戰場。
MongoDB 儲存的資料屬於什麼類型？
MongoDB 也是「資料庫」，跟 MySQL 一樣是結構化嗎？
MongoDB 是 NoSQL 文件資料庫，儲存 JSON-like 文件（BSON 格式），屬於半結構化數據。不同文件可以有不同欄位，沒有固定 Schema。這跟 MySQL 這類關聯式資料庫（固定表格結構 = 結構化）是本質上的不同。
在 AI 資料準備階段，非結構化數據需要哪些額外處理步驟？
非結構化資料就是亂的，怎麼讓 AI 用？
文字需要分詞（Tokenization）、清洗、向量化（Embedding）才能讓模型理解；圖片需要標注（Annotation/Labeling）、尺寸統一、正規化；音訊需要轉成頻譜圖或文字轉錄。結構化數據通常只需 ETL 就能直接用，非結構化需要多得多的前置工作。
想再往下看，這 5 個
- 結構化數據（Structured Data）存在關聯式資料庫、有明確 Schema 和表格格式的數據，可用 SQL 直接查詢，是傳統商業分析的主力資料類型
- 半結構化數據（Semi-structured Data）有自描述標記但格式不完全固定的數據，如 JSON、XML，需要解析器才能讀取，廣泛用於 API 傳輸和 NoSQL 資料庫
- 非結構化數據（Unstructured Data）無預定義格式的數據，如文字、圖片、影片，佔全球資料量 80% 以上，是深度學習和 NLP 的主要處理對象
- 資料湖（Data Lake）集中儲存各種類型原始數據（結構化、半結構化、非結構化）的儲存系統，讓 AI 能從同一個地方取得多種格式的資料
- 向量資料庫（Vector Database）儲存非結構化數據轉換成向量嵌入（Embedding）後的特殊資料庫，讓 AI 能進行語意搜尋，是 RAG 系統的核心元件