了解数据库系统需求规范

发布于 2024-11-09 13:14:06 字数 463 浏览 3 评论 0原文

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

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 网站上,但我认为这是正确的地方,因为我更关心数据库设计,

提前致谢

assuming that you have the following sentence in a requirements document

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

does that mean each publisher can have multiple addresses and multiple phone numbers ?.

again something like that

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

does that mean each book can have multiple authors ?

assuming this is not a real system ( can't get clarification from real clients ) what is the default decision i should take ?

this might not be very programming related , i was going to post this in English stackexchange site but i thought this is the right place since i am more concerned about the database design

thanks in advance

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

厌味 2024-11-16 13:14:06

英语通常是含糊不清的,所以你不能 100% 确定第一种情况的含义;你必须运用你的常识来想出一个解决方案。然而,我确实认为在第二种情况下使用“作者”而不是“作者”确实清楚地表明一本书可能有多个作者 - 它可以被理解为“一个或多个作者”的简写。

English language is often ambiguous, so you can't be 100% sure what is meant in the first case; you'd have to use your common sense to come up with a solution. However I do think that the use of "author(s)" rather than "authors" in the second case does make it clear that a book may have more than one author - it can be read as shorthand for "author or authors".

懒猫 2024-11-16 13:14:06

自然语言规范几乎必然是模糊的。这就是为什么提出“设计规范语言”是一种永恒的尝试,这种语言比自然语言更正式、更精确。 ER、UML、ORM(“这个”ORM,而不是“那个”ORM),甚至是简单的数学公式:所有这些“非自然”语言的发明都是为了解决自然语言散文固有的模糊性。

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

您可以做出假设,但您应该避免将这些假设视为理所当然,而不与用户进行检查,用户应该是业务专家。

Natural language specifications are ambiguous almost by necessity. That is why it is an everlasting attempt to come up with "design specification languages" that allow to be more formally precise than natural language is. ER, UML, ORM ('this' ORM, not 'that' ORM), even plain mathematics formulae : all of them "non-natural" languages invented in an attempt to address the inherent ambiguity of natural-language prose.

That is also why "getting the specs pinned down precisely enough" is typically an iterative process with multiple iterations.

You can make assumptions, but what you should avoid is to take those assumptions for granted without checking them with the user, who is supposed to be the business expert.

微凉 2024-11-16 13:14:06

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

澄清一下:

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

If you can code it in, then have the possibility for each publisher to have separate addresses and numbers. However, based on your spec document, only your books authors field will need to have multiple authors.

To clarify:

  • One publisher should have only one address and one phone number.
  • One book should have one title and 1 or more authors.
旧人 2024-11-16 13:14:06

当然,你必须得到客户的反馈。向他们提问是一件好事。但我假设您需要问最少的问题......您确实需要在创建更灵活的设计方面犯错误。灵活的设计仍然可以应对不太灵活的需求;尽管创建可能需要更多的初始工作。
向客户明确他们所支付的灵活性程度。
常识在很多时候可能是正确的......直到它是错误的。假设一个人可以拥有多个地址的设计在 90% 的人只有一个地址的情况下仍然有效。我可以轻松想象您的示例的场景,其中我需要为许多同级对象进行设计。假设一对一关系通常不是假设的关系。

在您的具体示例中,情况可能与一般情况有所不同,但一般来说,一位作者可以创作多本书籍,书籍可以有多个作者,书籍可以有多个出版商,出版商可以有多个出版商地址,并且每个地址可以有多个电话号码。

Of course, you must get feedback from the client. Asking them questions is a good thing. But I'll assume that you need to ask the very minimum of questions.... You really need to err on the side of creating the more flexible design. A flexible design should still cope with the less flexible requirement; though it may take more initial work to create.
Make it clear to the client what degree of flexibility they are paying for.
Common sense may be right a lot of the time... until it's wrong. A design that assumes that a person can have many addresses can still work for the 90% of cases where a person only has one address. I can easily imagine scenarios for your example where I would need to design for many sibling objects. Assuming one-to-one relations is generally not the one to assume.

In your specific example, things may be different from what happens in general, but in general an author can create more than one book, books can have more than one author, books can have more than one publisher, a publisher can have more than one address and each address can have more than one phone number.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文