理解数据库系统要求规范

Question

假设您在需求文档中有以下句子

The system has to keep track of the names of publishers, their
addresses and telephone numbers

这是否意味着每个发布商都可以拥有多个地址和多个电话号码？

再次类似

Information about the books’ names and author(s) is maintained in the database.

这是否意味着每本书可以有多位作者？

假设这不是一个真实的系统（无法从真实客户那里得到澄清）我应该采取什么默认决定？

这可能与编程无关，我打算在英文stackexchange网站上发布，但我认为这是正确的地方，因为我更关心数据库设计

提前致谢

Answer 1

英语通常含糊不清，因此你无法100％确定第一种情况的含义;你必须用你的常识来提出解决方案。但是我确实认为在第二种情况下使用“作者”而不是“作者”确实表明一本书可能有多个作者 - 它可以被解读为“作者或作者”的简写。

Answer 2

自然语言规范几乎是必要的。这就是为什么它是一种永久性的尝试，提出“设计规范语言”，允许比自然语言更正式的精确。 ER，UML，ORM（'这'ORM，而不是'那'ORM），甚至是普通的数学公式：所有这些都是为了解决自然语言散文固有的模糊性而发明的“非自然”语言。

这也是为什么“让规格足够精确”通常是一个多次迭代的迭代过程。

你可以做出假设，但你应该避免的是将这些假设视为理所当然而不是与用户一起检查，应该是商业专家。

Answer 3

如果您可以对其进行编码，则每个发布商都有可能拥有单独的地址和号码。但是，根据您的规范文档，只有您的图书作者字段需要有多个作者。

澄清：

• 一个发布商应该只有一个地址和一个电话号码。
• 一本书应该有一个标题和一个或多个作者。

Answer 4

当然，您必须从客户那里获得反馈。问他们问题是件好事。但我认为你需要提出最少的问题......你真的需要在创造更灵活的设计方面犯错误。灵活的设计应该仍然能够应对不太灵活的要求;虽然创作可能需要更多的初步工作。 向客户明确说明他们支付的灵活程度。 常识可能在很多时候都是对的...直到它错了。假设一个人可以拥有多个地址的设计仍然适用于一个人只有一个地址的90％的情况。我可以很容易地想象出你需要为许多兄弟对象设计的示例场景。假设一对一关系通常不是假设的关系。

在您的具体示例中，事情可能与一般情况不同，但一般情况下，作者可以创建多本书，书籍可以有多个作者，书籍可以有多个出版商，出版商可以有多个地址，每个地址可以有多个电话号码。