重組庫存管理數據庫（2到3個表;開發階段）

Question

我正在開發一個數據庫。我會很感激一些幫助重組2到3表，所以數據庫都符合前3個正常形式;並且可以在將來使用和擴展/添加。我現在想花些時間來減少以後的努力和混亂。

序言

請注意，我既是一個NUBE，和一個業餘愛好者，雖然我有一定的經驗和技能，熱情的豐富！

背景PROJECT

我寫一個小的（雖然雄心勃勃的！）Web應用程序（使用PHP和AJAX的的MySQL數據庫）。它本質上是一個系統，用於記錄和查看每件設備的當前位置及其維護歷史。如果相關，交易量將非常低（可能每天不到100個，但可能同時進行連接/操作）。行數也將非常低（可能是幾千）。

它將處理許多完全不同的設備類別，例如自行車和燈（隨機示例）。每個設備單元都將其數據記錄在數據庫中。對於自行車來說，重要的規格可能是框架顏色，而燈可能需要關於燈罩材料的信息。

由於類設備有所以什麼共同之處，我覺得來存儲信息的最合理的方式是每類1臺。這樣，每個類別都可以具有特定於該類別的列。

我打算在一個單獨的表中存儲一個類別列表。每個類別都有一個該類別唯一的ID。 （根據最終的設計，這可以作爲查詢表和/或表格來運行查詢）。可能只有很少的類別（可能是10到20個），除非系統特別成功並且擴展。

自行車列表將在自行車表中舉行。 每輛自行車都有一個自行車專用的標識（例如自行車0001）。 但燈臺（即燈0001）中會存在相同的ID。

在我的應用程序中，我希望用戶從下拉列表中選擇類別類型（例如自行車）。 然後他們將輸入對象的數字ID（例如0001）。 這兩個ID的組合是用於唯一標識對象的足夠信息。

圖片：

當前表設計

擬增設的表

問題

我的直覺是，應該有一個「整體表」，它包含每一件設備的文章，不管它來自何種類別。這比查詢知道多少個迷你桌子要簡單得多。但是當我試圖構建它時，它似乎會打破各種正常形式。例如引入冗餘，不一致的可能性，參照完整性問題等。它也開始看起來像域表。

或許首要表應該是一個查詢或視圖，而不是實體？

您能否看看截圖並讓我知道您的意見。謝謝。

由於各種原因，如果可能的話，我寧願使用代理鍵而不是自然鍵。理想情況下，我寧願在一列中使用代理鍵。

目前，自行車（或燈）表只使用第一列作爲主鍵。我是否應該將其擴展爲包含Equipment_Category_ID列的組合鍵？然後使Equipment_Article表成爲連接這兩列的視圖（迭代地爲每個設備類別）。可以將Bike_ID和Lamp_ID列重新命名爲通用類似Equipment_Article_ID。這可能會使查詢變得更簡單，但有沒有失去特異性的風險？它會/仍然可以通過表名來限定。說到冗餘，當前燈或腳踏車表中的Equipment_Category_ID似乎有點多餘（如果該表中的每個項目/行在該列中具有相同的值）。

這一切聽起來都很亂！但是，對於例如在線電子商店，出租商店等，這肯定是非常普遍的問題。希望有人會說那個老栗子！手指交叉！對不起，因爲不簡明，但我無法弄清楚什麼位可以省略。大部分似乎相關，如果有點健談。提前致謝。

---

UPDATE 27/03/2014（回覆@ElliotSchmelliot）

嗨埃利奧特。
感謝您的回覆，並指引我朝着正確的方向發展。我研究了OOP（用Java），但沒有意識到在SQL中可能有類似的東西。我閱讀了您感興趣發送的鏈接，其餘的網站/書籍看起來像是一個很好的資源。

請問MySQL InnoDB支持專業化&泛化？
不幸的是，經過3個小時的搜索和閱讀，我仍然無法找到這個問題的答案。關鍵詞我正在搜索的內容包括：MySQL +（繼承| EER |專業化|泛化|父|子|類|子類）。我發現的唯一積極結果是：http://en.wikipedia.org/wiki/Enhanced_entity%E2%80%93relationship_model。它提到了MySQL Workbench。 Equipment_Category（表3）
是和否的

可能的冗餘因爲這是一個查找表，它目前擁有的功能。 但是由於Lamp或Bike表中的每個項目都具有相同的類別，所以該列本身可能是多餘的;如果是，那麼Equipment_Category表可能是多餘的......除非在其他地方需要。 I 有打算將其用作網絡表單下拉菜單的行來源/選項列表。在建議的Equipment父表中將Equipment_Category作爲列是否也很方便。沒有它，如何返回燈類別的所有Equipment_Name s的列表（忽略當前不同）。

實施
我不知道，可能需要在將來增加哪些新類設備的方式，所以我必須要限制包含在超/家長的屬性我100％肯定會對所有人來說都是共同的（或者允許我認爲是空值）;爲了提高靈活性並避免長期維護，希望在許多子表中避免重複。這非常重要，因爲我們不會爲這個項目提供專業的IT支持。

變化真的必須自動化。所以我喜歡存儲過程的想法。並且CreateBike的例子聽起來很熟悉（原則上，如果不是在語法上）用Java創建一個類的實例。

很多想法和教我自己！如果您有任何其他意見，建議等，他們會受到歡迎。而且，你能否讓我知道你用什麼軟件來創建你的UML圖。它的造型比我用過的更好。

乾杯！

Answer 1

您聽起來對這個項目非常感興趣，它總是很棒的！

我有幾個建議爲你的數據庫模式：

1. 你必須爲每個設備實體，即自行車或燈單獨的表。然而，你也有一個Equipment_Category表格，純粹用於在Bike表格中將自行車或燈泡中的行識別爲燈泡。這似乎有點多餘。我假設Bike表中的每一行數據代表一輛自行車，那麼爲什麼還要打擾類別表呢？

2. 你提到你的「腸道」感覺是告訴你去爲所有設備的首要表。您是否熟悉generalization and specialization在數據庫設計中的做法？你在這裏尋找的是專業化（也稱爲「自上而下」）。我認爲擁有代表設備的總體或「父」表是一個好主意。然後，諸如自行車或燈的每個子實體將是設備的子表。父表只包含所有子表共享的字段。

考慮到這些建議，這裏是我怎麼可能會改變您的模式：

在上述模式中，一切都開始爲設備。但是，每個設備可以專門用於燈，自行車等。設備實體具有所有的共同領域。燈和自行車每個都有自己的類型。創建實體時，首先創建設備，然後創建專用實體。例如，假設我們添加了「BMX 200 Ultra」自行車。我們首先在Equipment表中創建一個帶有通用信息（equipmentName，dateOfPurchase等）的記錄。然後我們創建專門的記錄，在這種情況下是帶有任何額外的自行車專用字段（wheelType，frameColor等）的自行車記錄。創建專門的實體，我們需要確保將它們鏈接回父級。這就是爲什麼Lamp和Bike實體都有一個用於equipmentID的外鍵。

添加專門實體的簡單而有效的方法是創建一個存儲過程。例如，假設我們有一個名爲CreateBike的存儲過程，它包含參數bikeName，dateOfPurchase，wheelType和frameColor。存儲過程知道我們正在創建Bike，因此可以輕鬆創建設備記錄，插入通用設備數據，創建自行車記錄，插入專用自行車數據以及維護外鍵關係。

使用專業化將使您的交易生活變得非常簡單。例如，如果您希望在2014年1月1日之前購買所有設備，則無需連接。如果你想要所有藍色的frameColor自行車，不需要連接。如果你想要所有由毛氈製成的燈，就不需要連接。唯一需要將專門表格加入設備表格的時間是，如果您希望來自父實體和專門實體的數據。例如，顯示所有使用100瓦燈泡的燈並命名爲「超級燈」。

希望這會有所幫助，祝你好運！

編輯

特化和泛化，如在你的提供源所提到的，是增強實體關係（EER）的一部分，這有助於限定用於您的架構的概念數據模型。因此，它不需要被說成是「支持的」，它更像是一種設計技術。因此，只要設計者實現它，任何數據庫模式都自然支持專業化和泛化。

就你的Equipment_Category表而言，我可以看到你來自哪裏。這確實可以讓所有類別的下拉列表變得容易。但是，您可以簡單地擁有一個靜態表（僅包含表示每個類別的字符串）來幫助這些人羣，並且仍然將您的設備表分開。你提到只有10-20個類別，所以我沒有理由在設備和設備類別之間建立一個橋樑。聯接越少越好。另一種選擇是在Equipment表中包含一個「equipmentCategory」字段，而不是整個表。然後您可以簡單地查詢所有獨特的設備類別值。

我同意你會想讓你的設備表保持所有孩子之間的共同價值。當然。如果事情變得太複雜了，而且你需要更多的定義實體，那麼你總是可以再次破除實體。例如，也許一半的自行車實體是RoadBikes，另一半是MountainBikes。你可以繼續專業化分解，以更好地瞭解這些獨特的領域。

存儲過程對於自動化常見查詢非常有用。最重要的是，參數化提供了針對SQL注入等安全威脅的額外防禦級別。

我使用SQL Server。我創建的圖是直接從SQL Server Management Studio（SSMS）中提取的。您可以簡單地展開數據庫，右鍵單擊數據庫圖表文件夾，然後使用所選表格創建新圖表。 SSMS爲你完成剩下的工作。如果您無法訪問SSMS，我可能會建議嘗試使用Microsoft Visio，或者如果您有權訪問它，Visual Paradigm。