understanding database system requirements specifications

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开发者_JAVA百科 the database design

thanks in advance

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".

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.

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.

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.