数据库设计:对Len Silverston的概念感到困惑。

6 浏览
0 Comments

数据库设计:对Len Silverston的概念感到困惑。

我正在阅读Len Silverston的数据建模书籍。

举个例子,我们有两个表格:

enter image description here

Len Silverston的说法是:

主键应该由主键属性(用“#”标识)以及与波浪线指向的实体的主键组合而成。

因此,订单项的主键是订单项序列ID加上订单的主键,即订单ID。

当我在关系型数据库管理系统(如MySQL)中实现这个模型系统时,我感到困惑:

  • 如何找到所有作为某个订单子项的订单项?
  • 当我们删除一个订单时,如何确保所有订单项(订单的子项)在之前被删除?
  • 如果订单项有多个外键,会发生什么?
0
0 Comments

这篇文章主要讨论了关于数据库设计中的一些混淆问题,并给出了相应的解决方法。问题的出现是因为数据库设计中的一些概念和表示不清晰,导致了混淆和困惑。下面将根据内容整理成一篇文章。

在内容中提到的一个问题是关于订单项的主键的定义。指出,订单项的主键应该由订单项序列号(order item seq ID)和订单的主键(order id)组成。然而,上面的图表并没有显示迁移关系中的属性。换句话说,在订单项实体中应该有一个"ORDER ID"属性。这是一个标识关系(identifying relationship)或者是一个多对多关系的部分表示。

另一个问题是如何查找某个订单的所有订单项。如果已经知道订单的ID,可以直接使用SELECT语句进行查询。如果不知道订单的ID,可以使用子查询进行查询。还可以使用JOIN操作进行查询。

删除订单时,如何确保在删除之前先删除所有的订单项。最简单的方法是使用适当的级联引用操作,即在创建表时设置外键的级联删除操作。这样,在删除父表数据时,数据库管理系统会自动删除相应的子表数据。如果不使用级联引用操作,可以使用DELETE语句进行手动删除。

最后一个问题是订单项有多个外键时会发生什么。指出,数据库管理系统会针对每个声明的外键强制执行引用完整性。可以合并通过多个外键迁移的字段,这在某些情况下是必要的,但在其他情况下是完全错误的。

这篇文章主要讨论了数据库设计中的一些混淆问题,并给出了相应的解决方法。这些问题的出现主要是因为概念和表示不清晰,导致了混淆和困惑。通过正确理解数据库设计的概念和使用正确的方法,可以避免这些问题的出现。

0