資料庫設計關聯關係表，目的是承載"資料建模"的"資料結構"部分。
"資料建模"的第二個部分，是"資料操作"。即對存量和流量業務資料的各種業務處理和儲存。
這部分早期是透過儲存過程以及資料庫自身的功能來約束，比如,自定義函式，儲存過程等。隨著程式越來越複雜，在工業界實踐中，"資料操作"這部分逐漸從資料庫系統中剝離，透過程式來實現。實際上，有些資料結構，甚至也剝離出來透過配置檔案的形式存在了。
所以，"資料結構"的設計，必須結合"資料操作"的程式實現方式，不是完全按照正規化的規定來的。
正規化是什麼？(normal form),就是規範化的樣式，是一些要求和建議性的規則，俗話就是這樣做最合理。當然也有別的理。正規化不是必須實現的標準。隨著操作資料的程式各異和世界的發展，資料結構的設計也必然多種多樣。
但是，在關係資料建模中，有一些是不變的。那就是，拋開所有的業務細節和操作要求，
1，表都是實體的集合
2，實體有唯一標識
3，實體之間是有聯絡的，而聯絡透過關係表示
對於關係，只有三種就可以充分表達。即,一：一，一：多，多：多
至此，我們就明白關係表的意義就是，僅透過這3種關係，就可清晰的表示所有的表資料結構。
那麼這三種關係，是如何在關係資料庫中實現的？
思路很簡單，就是將主鍵，當做一個維度。透過維度建立座標系來表示點。
在本文的例子中，員工ID是個主鍵。所以員工表是個一維空間。部門ID是個主鍵，部門表也是個以維空間。員工和部門，在各自的一維空間中獨立存在。此時是沒有關係存在的。
如果要有關係，這兩個主鍵所代表的欄位，為簡單起見，假設出現在同一個表:"員工+部門"表中。
(透過中間實體間接關聯情況，是基於簡單的演變，這裡只考慮基本模式)
考慮最簡單情況，員工ID+部門ID構成聯合主鍵。
可見，此時該表是個二維空間，所以表達的關係是個多：多的關係。
那麼如何表示一：多關係？
首先必須確定一，因此這個空間必須是個一維空間。
假設是員工空間，那麼員工ID就是唯一的主鍵。此時，部門ID作為一個屬性介入這個世界，可以看做有無數個平行的員工ID維度線，而員工實體，就透過升維散落到這些平行線上。但這些員工實體，投影到某個具體的員工ID維度線上時，又是不重合的。
這樣，就實現了一：多的關係。
即同一個部門(注意這裡的表達，這裡的一是部門)，在這個維度線上，有很多個員工ID實體。
可想而知，部門ID，不必須是外部主鍵。也就是說，不是必須有個部門表。因此這裡的部門ID,完全可以換位部門的名稱。
至此知道，關係僅僅是數量層面的一種現象，實際的約束是要結合業務才能正確解釋。
這種做法，和原來的員工表有冗餘模式，因此通常就收斂到在員工表中，嵌入部門ID的方式。
至於一：一的關係，只需要在一：多的基礎上，要求多欄位的屬性為unique即可。
當然unique,也可透過程式來控制。用程式也是一種很常見的表示方式。
至於原來的員工表，和現有的關係表，對於員工來說，也是個一對一關係。但這種關係，是透過資料來表達，也就是程式來保證的。同樣的情況還有表的垂直切分。
下面回到問題上來。
1，兩種方案都可以表達員工和部門的關係。
2，方案1，在資料關係上，僅僅是一對多。
3，方案2，在資料關係上，其實是多對多。相容了一對多的情況。
因此，方案2的擴充套件性顯然要更加強。這裡不能用正規化或反正規化來下結論。因為部門和員工的關係，可能以後真的就成了多對多。何況還有程式中的資料操作也表達了資料關係，因此僅僅透過資料表的結構，不能簡單的得到反正規化的結論。
更進一步，在考慮到效能時，有時反正規化也是需要的。
比如員工部門表獨立出來，可以進行表快取，甚至進一步載入到快取資料庫中。這樣員工登入時，系統可快速根據部門情況決定其許可權。如果員工表非常大，每次都要進行關聯查詢無疑是增加了資料庫的壓力。這是常見的空間換時間的打法。
在IT系統服務中，快無疑是個好事。
資料庫設計關聯關係表，目的是承載"資料建模"的"資料結構"部分。
"資料建模"的第二個部分，是"資料操作"。即對存量和流量業務資料的各種業務處理和儲存。
這部分早期是透過儲存過程以及資料庫自身的功能來約束，比如,自定義函式，儲存過程等。隨著程式越來越複雜，在工業界實踐中，"資料操作"這部分逐漸從資料庫系統中剝離，透過程式來實現。實際上，有些資料結構，甚至也剝離出來透過配置檔案的形式存在了。
所以，"資料結構"的設計，必須結合"資料操作"的程式實現方式，不是完全按照正規化的規定來的。
正規化是什麼？(normal form),就是規範化的樣式，是一些要求和建議性的規則，俗話就是這樣做最合理。當然也有別的理。正規化不是必須實現的標準。隨著操作資料的程式各異和世界的發展，資料結構的設計也必然多種多樣。
但是，在關係資料建模中，有一些是不變的。那就是，拋開所有的業務細節和操作要求，
1，表都是實體的集合
2，實體有唯一標識
3，實體之間是有聯絡的，而聯絡透過關係表示
對於關係，只有三種就可以充分表達。即,一：一，一：多，多：多
至此，我們就明白關係表的意義就是，僅透過這3種關係，就可清晰的表示所有的表資料結構。
那麼這三種關係，是如何在關係資料庫中實現的？
思路很簡單，就是將主鍵，當做一個維度。透過維度建立座標系來表示點。
在本文的例子中，員工ID是個主鍵。所以員工表是個一維空間。部門ID是個主鍵，部門表也是個以維空間。員工和部門，在各自的一維空間中獨立存在。此時是沒有關係存在的。
如果要有關係，這兩個主鍵所代表的欄位，為簡單起見，假設出現在同一個表:"員工+部門"表中。
(透過中間實體間接關聯情況，是基於簡單的演變，這裡只考慮基本模式)
考慮最簡單情況，員工ID+部門ID構成聯合主鍵。
可見，此時該表是個二維空間，所以表達的關係是個多：多的關係。
那麼如何表示一：多關係？
首先必須確定一，因此這個空間必須是個一維空間。
假設是員工空間，那麼員工ID就是唯一的主鍵。此時，部門ID作為一個屬性介入這個世界，可以看做有無數個平行的員工ID維度線，而員工實體，就透過升維散落到這些平行線上。但這些員工實體，投影到某個具體的員工ID維度線上時，又是不重合的。
這樣，就實現了一：多的關係。
即同一個部門(注意這裡的表達，這裡的一是部門)，在這個維度線上，有很多個員工ID實體。
可想而知，部門ID，不必須是外部主鍵。也就是說，不是必須有個部門表。因此這裡的部門ID,完全可以換位部門的名稱。
至此知道，關係僅僅是數量層面的一種現象，實際的約束是要結合業務才能正確解釋。
這種做法，和原來的員工表有冗餘模式，因此通常就收斂到在員工表中，嵌入部門ID的方式。
至於一：一的關係，只需要在一：多的基礎上，要求多欄位的屬性為unique即可。
當然unique,也可透過程式來控制。用程式也是一種很常見的表示方式。
至於原來的員工表，和現有的關係表，對於員工來說，也是個一對一關係。但這種關係，是透過資料來表達，也就是程式來保證的。同樣的情況還有表的垂直切分。
下面回到問題上來。
1，兩種方案都可以表達員工和部門的關係。
2，方案1，在資料關係上，僅僅是一對多。
3，方案2，在資料關係上，其實是多對多。相容了一對多的情況。
因此，方案2的擴充套件性顯然要更加強。這裡不能用正規化或反正規化來下結論。因為部門和員工的關係，可能以後真的就成了多對多。何況還有程式中的資料操作也表達了資料關係，因此僅僅透過資料表的結構，不能簡單的得到反正規化的結論。
更進一步，在考慮到效能時，有時反正規化也是需要的。
比如員工部門表獨立出來，可以進行表快取，甚至進一步載入到快取資料庫中。這樣員工登入時，系統可快速根據部門情況決定其許可權。如果員工表非常大，每次都要進行關聯查詢無疑是增加了資料庫的壓力。這是常見的空間換時間的打法。
在IT系統服務中，快無疑是個好事。