數據庫設計是否重復？

Question

我正在研究一個數據庫模式，此刻讓我有點發瘋，因為我似乎要重復相同的表來重現不同類型的行為。

基本上，該系統由通過網絡監控的實時傳感器和通過手機收集的記錄器組成。 傳感器和記錄器分為“位置”，“位置”分為“區域”。 一個位置最多可以有1個記錄器，但可以有任意數量的實時傳感器。

我將嘗試打破規則：

1. 系統可以有0到多個區域
   
2. 一個區域可以有0到多個位置
   
3. 一個位置可以有0到1個記錄器
   
4. 一個位置可以有0到許多LiveAnalogSensor
   
5. 一個位置可以有0到許多LiveSwitchSensors
   
6. 一個位置可以有0到多個動作
   
7. 一個LiveAnalogSensor必須屬於1個LiveSensorRelay
   
8. 一個LiveSwitchSensor必須屬於1個LiveSensorRelay
   
9. 記錄器可以有0到許多讀數
   
10. LiveAnalogSensor可以讀取0到許多讀數
    
11. LiveSwitchSensor可以讀取0到許多讀數
    
12. 讀數可能有警報
    
13. 系統可以有0到多個動作
    
14. 警報可以應用0到1的動作
    
15. 一個警報可以有0到1個警報分辨率
    

架構圖片在這里。

因此，場景是一個讀數進入並存儲（通過Logger下載或通過網絡輸入的實時讀數）。 讀數超出范圍，因此帶有警報代碼。 將為該讀數生成警報。 最終，用戶會對其執行操作。 如果出現讀數，表明警報條件已結束，則將AlarmResolution（或在我在架構中稱為AlarmEnd）的條目鏈接到Alarm，以顯示其結束時間和結束時間。

對於模擬警報，只要新讀數高於上一個讀數，就會存儲一個新的“ Peak”讀數，這就是AnalogSensorReadingAlertPeak表的作用。

基本上就是這樣。 我的問題是對於不同的傳感器（尤其是基本相同的記錄器和模擬傳感器），該模式的重復性如何-我似乎有很多1到0..1的關系，盡管我對此不太擔心。

我真的在進行健全性檢查。 我可以想到擺脫重復性的方法，但是它似乎總是以犧牲數據完整性為代價。

謝謝。

編輯：由於沒有特別明確的規定，我在向下表決后已對標題和問題進行了一些修改。 我希望現在會更好。

Answer 1

我要說的是，如果每個Sensor（例如）具有完全相同的屬性（列），則是重復的。 如果它們完全不同，則它們應該具有不同的表。

我也嘗試使用NORMA或類似工具捕獲此內容以驗證設計。

Answer 2

我不會太擔心太多的“一對一”關系。 我不擔心有零到一的擺在首位的關系。 從長遠來看，這些關系是一對多的關系。

對我來說，沒有什么比許多工具中標准的ER圖混亂更令人困惑了。 我使用一種稱為“層次化概念圖”的技術來幫助理解我的關系。

您應該制作一個Levelized Diagram-在進行數據庫設計時，它將使您的生活變得非常輕松。

希望我能使這變得容易-一側在頂部，許多在底部。 多對多分解為兩個一對多表。

重復直到完成。

鏈接到完整圖像： http : //i.stack.imgur.com/VKAGZ.jpg

Answer 3

為什么需要僅包含PK字段的表？ 您不能將他們的孩子直接與父母聯系嗎？

還可以考慮創建一個包含兩個字段和一個contextID鍵字段的限制表，因此，要代替具有2個限制字段的2個表（每個限制字段2個上限和2個下限字段），要有一個包含3個字段的新表，並更改現有表中的2個字段與新的FK關系，名稱如upperLimitContextID和LowerLimitContextID。

另外，由於操作表和結束表具有相同的PK，請考慮將它們組合在一起。 任何時候只要表具有相同的PK，就可以將它們組合在一起。

Answer 4

在Oracle中， ARC描述了與其他表的互斥關系。 可以使用可空FK列在其他數據庫中實現此概念。

根據表的功能，您可以選擇將所有* Readings或所有* Alerts表組合到一個表中，這些表具有指向相應Logger，AnalogSensor和SwitchSensor表的可空外鍵列。

因此，* AlertEnd和* AlertAction表也可以合並（如果需要，可以添加Type列）。

（可選）添加三個域（Logger，AnalogSensor和SwitchSensor）的視圖以模擬原始表。