【问题标题】:SQL Relationship Cardinality in Logical Design逻辑设计中的 SQL 关系基数
【发布时间】:2013-04-25 13:15:18
【问题描述】:

我有以下问题。我们目前正在为一家班车服务公司开发一个系统。现在,该系统的数据库中的部分实体包括大量查找表(如车辆类型、员工状态等),以及其他一些表,如车辆和车辆服务日志。

现在我们作为一个团队遇到的问题是,我们无法就实体之间的逻辑关系基数应该是什么达成一致。两个主要的问题关系包括定义如下的表:

CREATE TABLE IF NOT EXISTS `user_type` (
  `type_id` tinyint(4) NOT NULL AUTO_INCREMENT,
  `description` varchar(200) NOT NULL,
  PRIMARY KEY (`type_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=latin1 COMMENT='Store the user types - employee
 or consultant' AUTO_INCREMENT=1 ;

链接到

CREATE TABLE IF NOT EXISTS `user` (
  `user_id` int(11) NOT NULL AUTO_INCREMENT,
  `username` varchar(100) NOT NULL,
  `password` varchar(100) NOT NULL,
  `user_type` tinyint(4) NOT NULL,
  PRIMARY KEY (`user_id`),
  KEY `user_type` (`user_type`),
  KEY `username` (`username`),
  KEY `login` (`username`,`password`)
) ENGINE=InnoDB  DEFAULT CHARSET=latin1 COMMENT='Table used when logging in 
to check access level, type of user, etc. ' AUTO_INCREMENT=1 ;

user 表包含其他不相关的数据。所以这里的问题是我说(因为 MySQL Workbench 以这种方式对其进行逆向工程并且更有意义)关系应该是 1-many,而另一个团队成员说它应该是 0-many(因为可能存在一些记录在user_type 表中没有在user 表中使用)

我们所说的另一个表关系定义如下:

CREATE TABLE IF NOT EXISTS `vehicle` (
  `vehicle_id` int(11) NOT NULL AUTO_INCREMENT,
  `registration_number` varchar(10) NOT NULL,
  PRIMARY KEY (`vehicle_id`),
  UNIQUE KEY `registration_number` (`registration_number`),
) ENGINE=InnoDB  DEFAULT CHARSET=latin1 COMMENT='Actual vehicle information'
 AUTO_INCREMENT=1 ;

同样,还有一些与问题无关的其他列。这与

链接
CREATE TABLE IF NOT EXISTS `service_log` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `vehicle_id` int(11) NOT NULL,
  `description` text NOT NULL,
  `date` date NOT NULL,
  `cost` double NOT NULL,
  PRIMARY KEY (`id`),
  KEY `vehicle_id` (`vehicle_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='Store records of all services 
to vehicles' AUTO_INCREMENT=1 ;

这应该是 1-many 还是 0-many,因为车辆可能尚未进行维修?根据我的说法,它应该是 1-many,但我不知道这是否合乎逻辑。

我们都对整个逻辑建模的事情感到非常困惑,所以任何帮助都将不胜感激!

我认为先创建数据库然后将其逆向工程为物理模型对我来说会更容易,但从不考虑逻辑。

【问题讨论】:

  • service_log 中有复合键(idvehicle_id)的原因是什么?不应该只是id吗?
  • 是的,实际上应该。我的错,感谢您指出这一点。

标签: sql database-design relationship cardinality


【解决方案1】:

如果是可选的,则为零到多。例如,销售代表将有零个或多个客户。这是为什么?因为如果有一个新的销售代表,那么这意味着他/她没有客户可以开始,除非他/她当然要承担已辞职销售代表的账户。

另一方面,一个或多个是强制性的。例如,具有订单日期的订单和订购的客户应在订单详细信息表中至少有一条记录。假设客户在 2013 年 4 月 22 日订购了一台平板电脑,那么他/她将会:

 Order table
 ----------------------------------------
 Orderid.  OrderDate. Customermnum
 ----------------------------------------
  1.       04/22/2013 101

 Order detail table
 ----------------------------------------
 Orderid.  Productid.  Qty.   quotedprice
 ----------------------------------------
  1.       T101       1       500

因此,在您的情况下,User 到 UserType 是 1 到 0 或很多,因为用户类型可能尚未被任何用户使用。

现在,车辆到服务它也是 1 比 0 或多,因为车辆可能不一定已经完成服务。

【讨论】:

  • 但这仅适用于逻辑设计阶段?否则这将需要有 NULL-able 字段?
  • 这更多的是逻辑设计,但这适用于逻辑设计和物理设计,因为逻辑设计与数据库无关。关于 NULLable 字段,您是指用户表中的相关外键 user_type 吗?如果是这样,那不是因为用户类型 id 无论如何都来自 user_type 表,而不是相反。
猜你喜欢
  • 2012-03-04
  • 2016-07-17
  • 2016-05-27
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多