|
|
<!--
|
|
|
CO_OP_TRANSLATOR_METADATA:
|
|
|
{
|
|
|
"original_hash": "870a0086adbc313a8eea5489bdcb2522",
|
|
|
"translation_date": "2025-08-27T08:21:32+00:00",
|
|
|
"source_file": "2-Working-With-Data/05-relational-databases/README.md",
|
|
|
"language_code": "mo"
|
|
|
}
|
|
|
-->
|
|
|
# 使用資料：關聯式資料庫
|
|
|
|
|
|
| ](../../sketchnotes/05-RelationalData.png)|
|
|
|
|:---:|
|
|
|
| 使用資料：關聯式資料庫 - _Sketchnote by [@nitya](https://twitter.com/nitya)_ |
|
|
|
|
|
|
你可能曾經使用過電子表格來存儲資訊。電子表格由一組列和欄組成，其中列包含資訊（或資料），而欄描述這些資訊（有時稱為元資料）。關聯式資料庫基於這種表格的核心原則，允許你將資訊分散到多個表格中。這使得你可以處理更複雜的資料，避免重複，並在探索資料時擁有更大的靈活性。讓我們來探討關聯式資料庫的概念。
|
|
|
|
|
|
## [課前測驗](https://purple-hill-04aebfb03.1.azurestaticapps.net/quiz/8)
|
|
|
|
|
|
## 一切從表格開始
|
|
|
|
|
|
關聯式資料庫的核心是表格。就像電子表格一樣，表格是一組欄和列的集合。列包含我們希望處理的資料或資訊，例如城市名稱或降雨量。欄則描述它們存儲的資料。
|
|
|
|
|
|
讓我們開始探索，建立一個表格來存儲城市的資訊。我們可以從城市名稱和國家開始。你可以將這些資訊存儲在如下表格中：
|
|
|
|
|
|
| 城市 | 國家 |
|
|
|
| -------- | ------------- |
|
|
|
| 東京 | 日本 |
|
|
|
| 亞特蘭大 | 美國 |
|
|
|
| 奧克蘭 | 紐西蘭 |
|
|
|
|
|
|
注意，**城市**、**國家**和**人口**這些欄名描述了存儲的資料，而每一列包含一個城市的資訊。
|
|
|
|
|
|
## 單一表格方法的缺點
|
|
|
|
|
|
上述表格可能對你來說相當熟悉。現在讓我們開始向這個初步的資料庫添加一些額外的資料——年度降雨量（以毫米為單位）。我們將專注於2018年、2019年和2020年。如果我們為東京添加這些資料，可能會像這樣：
|
|
|
|
|
|
| 城市 | 國家 | 年份 | 降雨量 |
|
|
|
| ----- | ------- | ---- | ------ |
|
|
|
| 東京 | 日本 | 2020 | 1690 |
|
|
|
| 東京 | 日本 | 2019 | 1874 |
|
|
|
| 東京 | 日本 | 2018 | 1445 |
|
|
|
|
|
|
你注意到我們的表格有什麼問題嗎？你可能會注意到我們重複了城市名稱和國家多次。這可能會佔用相當多的存儲空間，而且多次複製是完全不必要的。畢竟，東京的名稱只有一個。
|
|
|
|
|
|
好吧，讓我們嘗試另一種方法。讓我們為每一年添加新的欄：
|
|
|
|
|
|
| 城市 | 國家 | 2018 | 2019 | 2020 |
|
|
|
| -------- | ------------- | ---- | ---- | ---- |
|
|
|
| 東京 | 日本 | 1445 | 1874 | 1690 |
|
|
|
| 亞特蘭大 | 美國 | 1779 | 1111 | 1683 |
|
|
|
| 奧克蘭 | 紐西蘭 | 1386 | 942 | 1176 |
|
|
|
|
|
|
雖然這避免了列的重複，但也帶來了其他挑戰。我們需要在每次有新年份時修改表格的結構。此外，隨著資料的增長，將年份作為欄會使檢索和計算值變得更加困難。
|
|
|
|
|
|
這就是為什麼我們需要多個表格和關係。通過拆分資料，我們可以避免重複，並在處理資料時擁有更大的靈活性。
|
|
|
|
|
|
## 關係的概念
|
|
|
|
|
|
讓我們回到資料，並決定如何拆分它們。我們知道我們希望存儲城市的名稱和國家，因此這可能最適合存儲在一個表格中。
|
|
|
|
|
|
| 城市 | 國家 |
|
|
|
| -------- | ------------- |
|
|
|
| 東京 | 日本 |
|
|
|
| 亞特蘭大 | 美國 |
|
|
|
| 奧克蘭 | 紐西蘭 |
|
|
|
|
|
|
但在建立下一個表格之前，我們需要弄清楚如何引用每個城市。我們需要某種形式的識別碼、ID或（在技術資料庫術語中）主鍵。主鍵是一個用於識別表格中特定列的值。雖然這可以基於某個值本身（例如，我們可以使用城市名稱），但它幾乎應該始終是一個數字或其他識別碼。我們不希望ID發生變化，因為這會破壞關係。在大多數情況下，主鍵或ID通常是一個自動生成的數字。
|
|
|
|
|
|
> ✅ 主鍵通常縮寫為PK
|
|
|
|
|
|
### 城市表
|
|
|
|
|
|
| city_id | 城市 | 國家 |
|
|
|
| ------- | -------- | ------------- |
|
|
|
| 1 | 東京 | 日本 |
|
|
|
| 2 | 亞特蘭大 | 美國 |
|
|
|
| 3 | 奧克蘭 | 紐西蘭 |
|
|
|
|
|
|
> ✅ 在本課程中，你會注意到我們交替使用“id”和“主鍵”這些術語。這些概念也適用於DataFrames，你稍後會探索。DataFrames不使用“主鍵”這一術語，但你會注意到它們的行為非常相似。
|
|
|
|
|
|
建立城市表後，讓我們存儲降雨量。與其重複城市的完整資訊，我們可以使用ID。我們還應確保新建立的表格有一個*id*欄，因為所有表格都應有一個ID或主鍵。
|
|
|
|
|
|
### 降雨量表
|
|
|
|
|
|
| rainfall_id | city_id | 年份 | 降雨量 |
|
|
|
| ----------- | ------- | ---- | ------ |
|
|
|
| 1 | 1 | 2018 | 1445 |
|
|
|
| 2 | 1 | 2019 | 1874 |
|
|
|
| 3 | 1 | 2020 | 1690 |
|
|
|
| 4 | 2 | 2018 | 1779 |
|
|
|
| 5 | 2 | 2019 | 1111 |
|
|
|
| 6 | 2 | 2020 | 1683 |
|
|
|
| 7 | 3 | 2018 | 1386 |
|
|
|
| 8 | 3 | 2019 | 942 |
|
|
|
| 9 | 3 | 2020 | 1176 |
|
|
|
|
|
|
注意新建立的**降雨量表**中的**city_id**欄。這個欄包含的值引用了**城市表**中的ID。在技術關聯資料術語中，這被稱為**外鍵**；它是另一個表格中的主鍵。你可以簡單地將其視為一個引用或指針。**city_id** 1引用了東京。
|
|
|
|
|
|
> [!NOTE] 外鍵通常縮寫為FK
|
|
|
|
|
|
## 資料檢索
|
|
|
|
|
|
將資料分成兩個表格後，你可能會想知道如何檢索它們。如果我們使用像MySQL、SQL Server或Oracle這樣的關聯式資料庫，我們可以使用一種名為結構化查詢語言（SQL）的語言。SQL（有時讀作sequel）是一種標準語言，用於在關聯式資料庫中檢索和修改資料。
|
|
|
|
|
|
要檢索資料，你可以使用指令`SELECT`。其核心是，你**選擇**想要查看的欄，**從**它們所在的表格中檢索。如果你只想顯示城市的名稱，可以使用以下指令：
|
|
|
|
|
|
```sql
|
|
|
SELECT city
|
|
|
FROM cities;
|
|
|
|
|
|
-- Output:
|
|
|
-- Tokyo
|
|
|
-- Atlanta
|
|
|
-- Auckland
|
|
|
```
|
|
|
|
|
|
`SELECT`是列出欄的地方，`FROM`是列出表格的地方。
|
|
|
|
|
|
> [NOTE] SQL語法不區分大小寫，這意味著`select`和`SELECT`是相同的。然而，根據你使用的資料庫類型，欄和表格可能區分大小寫。因此，最佳做法是始終將程式設計中的所有內容視為區分大小寫。在撰寫SQL查詢時，常見的慣例是將關鍵字全部用大寫字母表示。
|
|
|
|
|
|
上述查詢將顯示所有城市。假設我們只想顯示紐西蘭的城市。我們需要某種形式的篩選器。SQL的關鍵字是`WHERE`，即“某些條件為真”。
|
|
|
|
|
|
```sql
|
|
|
SELECT city
|
|
|
FROM cities
|
|
|
WHERE country = 'New Zealand';
|
|
|
|
|
|
-- Output:
|
|
|
-- Auckland
|
|
|
```
|
|
|
|
|
|
## 資料連結
|
|
|
|
|
|
到目前為止，我們只從單一表格中檢索資料。現在我們希望將**城市表**和**降雨量表**中的資料結合起來。這可以通過*連結*它們來完成。你將有效地在兩個表格之間建立一個接合點，並匹配每個表格中的欄值。
|
|
|
|
|
|
在我們的例子中，我們將匹配**降雨量表**中的**city_id**欄與**城市表**中的**city_id**欄。這將把降雨量值與其相應的城市匹配起來。我們將執行一種稱為*內部連結*的操作，這意味著如果某些列未與另一個表格中的任何內容匹配，它們將不會顯示。在我們的例子中，每個城市都有降雨量，因此所有資料都會顯示。
|
|
|
|
|
|
讓我們檢索2019年的所有城市降雨量。
|
|
|
|
|
|
我們將分步進行。第一步是通過指明接合點的欄——如前所述的**city_id**——來連結資料。
|
|
|
|
|
|
```sql
|
|
|
SELECT cities.city
|
|
|
rainfall.amount
|
|
|
FROM cities
|
|
|
INNER JOIN rainfall ON cities.city_id = rainfall.city_id
|
|
|
```
|
|
|
|
|
|
我們已經指明了我們想要的兩個欄，以及我們希望通過**city_id**連結表格的事實。現在我們可以添加`WHERE`語句來篩選出僅2019年的資料。
|
|
|
|
|
|
```sql
|
|
|
SELECT cities.city
|
|
|
rainfall.amount
|
|
|
FROM cities
|
|
|
INNER JOIN rainfall ON cities.city_id = rainfall.city_id
|
|
|
WHERE rainfall.year = 2019
|
|
|
|
|
|
-- Output
|
|
|
|
|
|
-- city | amount
|
|
|
-- -------- | ------
|
|
|
-- Tokyo | 1874
|
|
|
-- Atlanta | 1111
|
|
|
-- Auckland | 942
|
|
|
```
|
|
|
|
|
|
## 總結
|
|
|
|
|
|
關聯式資料庫的核心是將資訊分成多個表格，然後將它們重新結合以進行顯示和分析。這提供了高度的靈活性來進行計算或其他方式操作資料。你已經了解了關聯式資料庫的核心概念，以及如何在兩個表格之間進行連結。
|
|
|
|
|
|
## 🚀 挑戰
|
|
|
|
|
|
網路上有許多關聯式資料庫可供使用。你可以使用上述學到的技能來探索這些資料。
|
|
|
|
|
|
## 課後測驗
|
|
|
|
|
|
## [課後測驗](https://purple-hill-04aebfb03.1.azurestaticapps.net/quiz/9)
|
|
|
|
|
|
## 回顧與自學
|
|
|
|
|
|
[Microsoft Learn](https://docs.microsoft.com/learn?WT.mc_id=academic-77958-bethanycheum)上有許多資源可供你繼續探索SQL和關聯式資料庫的概念
|
|
|
|
|
|
- [描述關聯資料的概念](https://docs.microsoft.com//learn/modules/describe-concepts-of-relational-data?WT.mc_id=academic-77958-bethanycheum)
|
|
|
- [開始使用Transact-SQL進行查詢](https://docs.microsoft.com//learn/paths/get-started-querying-with-transact-sql?WT.mc_id=academic-77958-bethanycheum)（Transact-SQL是SQL的一個版本）
|
|
|
- [Microsoft Learn上的SQL內容](https://docs.microsoft.com/learn/browse/?products=azure-sql-database%2Csql-server&expanded=azure&WT.mc_id=academic-77958-bethanycheum)
|
|
|
|
|
|
## 作業
|
|
|
|
|
|
[作業標題](assignment.md)
|
|
|
|
|
|
---
|
|
|
|
|
|
**免責聲明**：
|
|
|
本文檔已使用 AI 翻譯服務 [Co-op Translator](https://github.com/Azure/co-op-translator) 進行翻譯。我們致力於提供準確的翻譯，但請注意，自動翻譯可能包含錯誤或不準確之處。應以原始語言的文件作為權威來源。對於關鍵信息，建議尋求專業人工翻譯。我們對因使用此翻譯而引起的任何誤解或錯誤解讀概不負責。 |
