dbForge Studio For MySQL是一個在Windows平臺被廣泛使用的MySQL客戶端，它能夠使MySQL開發人員和管理人員在一個方便的環境中與他人一起完成創建和執行查詢，開發和調試MySQL程序，自動化管理MySQL數據庫對象等工作。

點擊下載dbForge Studio For MySQL最新試用版

數據庫設計基礎

為了設計數據庫模式，讓我們回顧7種規范形式以及規范化和非規范化的概念。它們是所有設計規則的基礎。

讓我詳細說明7種正常形式：

1.一對一關系：

1.1強制性關系：

一個例子是擁有護照的公民（每個公民必須擁有護照，護照是每個公民的護照）。

此關系以兩種方式實現：

1.1.1在一個實體（表）中：

圖1。“公民”實體

在這里，公民表代表公民實體，并且PassportData屬性（字段）包含公民的所有護照數據，并且不能為空（NOT NULL）

1.1.2。在兩個不同的實體（表）中：

圖2。公民和PassportData實體之間的關系

“公民”表代表公民實體，“護照數據”表代表公民護照數據的實體。公民實體包含PassportID屬性（字段），該屬性引用PassportData表的主鍵。護照數據實體具有CitizenID屬性（字段），該屬性引用Citizen表的CitizenID主鍵。

確保CitizenID字段和PassportData表的完整性，以提供一對一的關系也很重要。也就是說，Citizen表中的PassportID字段和PassportData表中的CitizenID字段必須引用相同的記錄，就好像它是第1.1.1段中說明的一個實體（表）一樣。

1.2可選關系：

這里的一個示例是可以擁有護照數據并且可能沒有指定國家/地區的人。因此，在第一種情況下，他是給定國家的公民，而在第二種情況下，他不是。

此關系以兩種方式實現：

1.2.1在一個實體（表）中：

圖3。人員實體

在此，“人”表代表人實體，“ PassportData”屬性（字段）包含一個人的所有護照數據，并且可以為空（NULL）

1.2.2在兩個實體（表）中：

圖4。Person和PassportData之間的關系

在此，“人”表代表人實體，“護照數據”表代表人的護照數據實體（即護照本身）。人員實體包含PassportID屬性（字段），該屬性引用PassportData表的主鍵。而護照數據實體在“個人”表中具有“個人ID”屬性（字段）。人員表的PassportID字段可以為空（NULL）。

保證PersonID字段和PassportData表的完整性，以提供一對一的關系也很重要。也就是說，Person表的PassportID字段和PassportData表的PersonID字段必須引用相同的記錄，就好像它是第1.2.1節中所示的一個實體（表）一樣，或者這些字段必須未指定，即，包含NULL。

2.一對多關系

2.1強制性關系：

這方面的一個例子可以是父母及其子女。每個父母都有至少一個孩子。

您可以通過兩種方式實現這種關系：

2.1.1在一個實體（表）中：

圖5。上級實體

這里，Parent表代表父實體，而ChildList屬性（字段）包含有關子項（即子項本身）的信息。該字段不能為空（NOT NULL）。ChildList字段類型通常是半結構化數據（NoSQL），例如XML，JSON等。

2.1.2在兩個實體（表）中：

圖6。父子實體之間的關系

在此，父表代表父實體，子表代表子實體。子表的ParentID字段引用了Parent表的主ParentID鍵。子表的ParentID字段不能為空（NOT NULL）。

2.2）可選關系：

例如可能有孩子或沒有孩子的人。

此關系以兩種方式實現：

2.2.1在一個實體（表）中：

圖7。人員實體

在這里，Parent表代表父實體，而ChildList屬性（字段）包含有關子項（即子項本身）的信息。該字段可以為空（NULL）。通常的ChildList字段類型是半結構化數據（NoSQL），例如XML，JSON等。

2.2.2在兩個實體（表）中：

圖8。人與子實體之間的關系

在此，父表代表父實體，子表代表子實體。子表的ParentID字段引用了Parent表的主ParentID鍵。子表的ParentID字段可以為空（NULL）。

同樣，在子實體和父實體（表）具有相同的屬性集（字段）而不引用父實體的情況下，存在引用自身的第三種方法：

圖9。具有自我參照的Person實體

這里，Person實體（表）包含引用同一表Person的主PersonID鍵的ParentID屬性（字段），并且可以具有空值（NULL）。

這是具有可選性質的多對一關系的實現。

3.多對一關系

該關系反映了上面所示的一對多關系。這就是子實體與父實體之間的關系，如果孩子至少有一個父輩，并且如果我們帶走所有孩子（包括孤兒院中的孩子），則這種強制關系是可能的，那么這種關系具有選擇性。

通過添加引用相應實體主鍵的必要屬性，也可以通過兩個以上的實體來實現一對多和一對多關系。此實現類似于上面的1.1.2和1.2.2段中的示例。

4.多對多關系

在這種情況下，一個示例可能是一個人或幾個人擁有的房地產。同時，一個人可以擁有幾所房屋或擁有許多房屋的所有權份額。

您可以按照上面針對先前關系描述的方式，使用NoSQL來實現此關系。但是，在關系模型中，通常通過3個實體（表）實現此關系：

圖10。人與房地產實體之間的關系

在此，Person和RealEstate表分別代表一個人的實體和不動產。這些實體（表）通過PersonRealEstate實體（表）通過PersonID和RealEstateID屬性（字段）相關聯，這些屬性分別引用Person表的主鍵PersonID和RealEstate表的RealEstateID。請注意，該對（PersonID; RealEstateID）在PersonRealEstate表中始終是唯一的，因此它可以成為PersonRealEstate鏈接實體（表）的主鍵。

通過添加引用相應實體主鍵的必要屬性，可以通過3個以上的實體來實現此關系。這樣的實現類似于第1.1.2和1.2.2段中描述的示例。

那么您可能想知道這7個范式在哪里？

好吧，這里是：

1. 第1條（第1.1條和第1.2條）是第一和第二條正式規則。
2. 參數2（參數2.1和參數2.2）是第三和第四條正式規則。
3. 第3條（類似于第2條）是第五和第六條正式規則。
4. 第4條是第七條正式規則。

只是在上面的文本中，這7個范式被分為4個功能塊。

標準化消除了數據冗余，因此降低了數據異常的風險。但是，分解實體（表）時的規范化將導致更復雜的查詢構建以進行數據操作（插入，更新，選擇和刪除）。

相反的過程是非規范化。它通過添加冗余數據（例如，如上文在2.1.1和2.2.1中提到的借助于半結構化數據（NoSQL））簡化了數據訪問的查詢處理。

您確定要使用7種范式嗎？您確實掌握了它，而不僅僅是熟悉它。問問自己，是否會在幾個小時內為任何數據域或任何信息系統設計一個數據庫模型（即使實體過多）。您可以稍后通過詢問分析人員和客戶代表來完善復雜性和細節。

如果這個問題使您措手不及，并且您認為完成此任務的可能性很小，那么您知道這7種正常形式，但不了解它們。

消息來源中并沒有以某種方式表明，實體之間的這些關系不僅是被建立而且是被發現的。也就是說，從一開始，它們實際上就存在于真實世界中，介于主體和客體之間。

除此之外，這些關系可以改變，從一對一轉變為一對多，或轉變為多對一，或轉變為多對多，從而改變其強制性或保留其強制性。

我認為您應該嘗試觀察人們并檢測主體之間以及主體與客體之間的現有關系（上面的示例將公民和護照視為具有強制性質的一對一關系，而將人和護照視為具有強制性質的一對一關系）。一對一關系（可選）。

深入了解7種標準形式后，您可以輕松地為任何信息系統設計具有任何復雜性的數據庫模型。

除此之外，您將了解可以多種方式實現關系，并且關系本身可以更改。因此，數據庫模型（模式）是實體在特定時間點之間關系的快照。因此，必須同時指定兩個實體（它們是真實世界或領域對象的圖像），并考慮到將來的變化來確定它們之間的關系。

一個經過精心設計的數據庫模型，充分考慮了現實中和主題領域中的關系更改，長期以來不需要任何更改。對于數據存儲而言，更改涉及重新保存大量數據（從幾GB到幾TB的數據）特別重要。

注意：在關系數據庫模型中，它是實體之間的關系，而行（元組）是這些關系的示例。但是為了簡單起見，我們通常是按表表示實體，按行表示實體實例，并按外部鍵關系表示它們之間的關系。