#database-design #requirements
#база данных-дизайн #требования
Вопрос:
предполагая, что у вас есть следующее предложение в документе требований
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, но я подумал, что это подходящее место, поскольку меня больше беспокоит дизайн базы данных
заранее спасибо
Ответ №1:
Английский язык часто неоднозначен, поэтому вы не можете быть на 100% уверены, что имеется в виду в первом случае; вам придется использовать свой здравый смысл, чтобы найти решение. Однако я думаю, что использование «автора (ов)» вместо «авторы» во втором случае проясняет, что у книги может быть более одного автора — это можно прочитать как сокращение от «автор или соавторы».
Комментарии:
1. Английский язык неоднозначен, вам лучше все делать на французском 🙂
Ответ №2:
Спецификации естественного языка неоднозначны почти по необходимости. Вот почему это постоянная попытка придумать «языки спецификации дизайна», которые позволяют быть более формально точными, чем естественный язык. ER, UML, ORM («этот» ORM, а не «тот» ORM), даже простые математические формулы : все это «ненатуральные» языки, изобретенные в попытке устранить двусмысленность, присущую прозе на естественном языке.
Вот почему «получение спецификаций, закрепленных достаточно точно», обычно является итеративным процессом с несколькими повторениями.
Вы можете делать предположения, но чего вам следует избегать, так это принимать эти предположения как должное, не проверяя их у пользователя, который должен быть бизнес-экспертом.
Ответ №3:
Если вы можете это закодировать, то у каждого издателя будет возможность иметь отдельные адреса и номера. Однако, исходя из вашего документа спецификации, только в вашем поле books authors должно быть указано несколько авторов.
Для уточнения:
- У одного издателя должен быть только один адрес и один номер телефона.
- В одной книге должно быть одно название и 1 или более авторов.
Комментарии:
1. «У одного издателя должен быть только один адрес и один номер телефона». Это именно тот тип ошибки, которого вам следует избегать: просто предполагать что-то, основываясь на собственном восприятии, и просто принимать это как должное, не проверяя это у «настоящего» бизнес-эксперта. Предположение — мать всех ошибок.
2. Нет необходимости подписывать ваши сообщения; ваше имя (ник) уже указано под каждым из них.
Ответ №4:
Конечно, вы должны получить обратную связь от клиента. Задавать им вопросы — это хорошо. Но я предполагаю, что вам нужно задать самый минимум вопросов…. Вам действительно нужно ошибиться в создании более гибкого дизайна. Гибкий дизайн все равно должен соответствовать менее гибким требованиям; хотя для его создания может потребоваться больше начальной работы. Разъясните клиенту, за какую степень гибкости они платят. Здравый смысл может быть прав большую часть времени… пока это не неправильно. Дизайн, который предполагает, что у пользователя может быть много адресов, все еще может работать в 90% случаев, когда у пользователя только один адрес. Я могу легко представить сценарии для вашего примера, в которых мне нужно было бы разрабатывать для многих родственных объектов. Предполагать отношения «один к одному», как правило, не следует.
В вашем конкретном примере ситуация может отличаться от того, что происходит в целом, но в целом автор может создать более одной книги, у книг может быть более одного автора, у книг может быть более одного издателя, у издателя может быть более одного адреса, и у каждого адреса может быть более одного номера телефона.