我想下面2句在ER圖模型：幫助建模ER圖
每個公司都有一套坦克。它是 也被稱爲每個坦克如何填補 它是每一天的時間。
不知道是否有特定時間的日誌存在日誌。它可以是每天一次，兩次，每一個小時，也許有些天你沒有任何信息等
這是我目前的嘗試： 
（我忘了放在坦克/日期關聯屬性稱爲「當前負載」）
雖然由於某種原因，我不喜歡它（我想我不喜歡Dates實體！）。你們通常如何模擬這種情況？
我想我可以改爲擁有一個TankLoads實體，它具有「加載」屬性和關聯中稱爲「日期」的另一個屬性。
感謝
PS：很抱歉的蹩腳DIA圖:(
嗯，我會做到這一點略有不同把所有日期/在一個單獨的表倍（我把它叫做日期現在，但你也可以稱它爲時間或時間戳等等）以及多對多坦克（我使用表格FillLevels）
坦克填充的等級存儲在FillLevels表中
公司：
- [...]
坦克：
- COMPANY_ID：整數
- [...]
FillLevels：
- tank_id：整數
- TIME_ID：整數
- [。 ..]
日期：
- [...]
我是沒有y的一個閃亮的圖對不起ou，但我在家裏這有點道理。
或者，您可以在FillLevels表中創建DateTime字段，而不是使用日期表，具體取決於您打算如何查詢數據庫。
數據建模和數據庫設計是不完全一樣的東西，儘管人們常常用ER圖來概括數據庫模式。
沒有什麼「不真實」，講述一個日期或日期和時間組成的時間戳。它們是抽象的事實並不是什麼大不了的事。銀行賬戶也是抽象的。
無論你將有日期或時間戳的表則是另一回事。在實踐中，我發現在報表數據庫中爲每個日期或每個工作班次建立一個表格目錄非常有幫助。使用適當的屬性，即使企業擁有自己獨特的財務日曆，也可以生成每週，每月，每季度或每年的報表，這使得它變得微不足道。一些屬性可能與SQL中內置的函數是多餘的，但即使如此，這也是一個相對無關緊要的設計決策。
我喜歡這個，但我會放在FillLevels表的日期權跳過獨立日期表 – 2010-10-13 12:31:33
這取決於應用程序的性質的一點點。如果每小時檢查級別，並且您需要快速查詢某個小時，那麼最好將小時實際放在表格中。它使用了更多的空間，但它極大地提高了查詢的速度。 – 2010-10-13 12:57:30