我想下面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