fair87
Вопросы: 1) правильно ли построена модель БД?(соответствует ли 3-ей НФ) 2) связи указаны верно? 3) нужно ли выводить в отдельную таблицу атрибут "город"?В таблице заказов не совсем понятен выбранный основной ключ(PK). Есть подозрение, что поле "Код_заказа" уже само по себе ключ. Либо надо от него совсем отказаться, а в основной ключ включить, например (Инвентарный_№_диска, №_ЧБ, Дата выдачи) или (№_ЧБ, Инвентарный_№_диска, Дата выдачи) в зависимости от наиболее характерных запросов к этой таблице. При этом полагаем, что один и тот же диск не может быть выдан одному и тому же читателю дважды за одну и ту же дату. Если это не так, то вместо поля даты возможно стоило бы использовать поле даты/времени.
Если могут появиться дополнительные таблицы, из которых могут быть ссылки на заказ, то составной ключ наверное лучше сделать альтернативным ключом(ограничением уникальности), а для ссылок пользоваться суррогатным ключом. Возможно тем самым, которым является текущее поле "Код_заказа".

fair87Сделал так: главным ключом таблицы "Заказы" сделал "№ ЧБ" из таблицы "Читатели": т.е. сущность "заказы" не может существовать без сущности "читатели".
...
Теперь модель составлена верно ?Насколько я понимаю Вашу задачу, то нет, теперь совсем плохо.
Основной ключ(PRIMARY KEY) уникально идентифицирует строку в таблице. В результате Вашей переделки получилось, что каждый читатель может сделать только один-единственный заказ. Вторую строку с тем же кодом читателя Вы добавить не сможете. Что-то мне подсказывает, что Вы не этого добивались.
Ещё раз повторюсь. Уникальность заказа определяется, как минимум, 3 полями: № читателя, № диска и датой выдачи. По описываемой Вами условиям, они все должны быть в составе ключа.

fair87как я понимаю концептуальная модель равна инфологической модели? т.е. это одно и то же? Я не понимаю, обязательно после построения концептуальной модели нужно строить логическую?(это по Конноли), или можно сразу строить физическую модель, т.е на основе выбранной СУБД.Ну так это лучше у Конноли и читать. В принципе, здесь пока особо никуда и не отходили от концептуальной модели в его понимании. Разве что, в правой части Вашей модели, где появились справочники. IMHO, на этом уровне в них нет особого смысла, их появлении скорее диктовалось бы на уровне логической модели, когда происходит проверка модели на корректность, нормализацию и прочая. И на этом этапе Вы бы столкнулись с тем, что без этих справочников обойтись нельзя, так как может произойти потеря информации при удалении из таблицы дисков записи с последним диском определённой тематики. Т.е., была бы потеряна информация о соответствующей тематике. Т.о., здесь проблема не в избыточности, как Вы преположили насчет справочника "Города".
Кстати, как раз такая ситуация с полем "Автор". Насколько я понимаю, автор может сделать не один диск, так что вполне можно создать справочник "Авторы". При этом, даже если будут удалены все диски этого автора, информация о нём сохранится и может быть использована позже, когда надо будет добавить новый диск этого автора. Кроме того, надо задать себе вопрос, а один ли автор у диска ? В результате, на логическом уровне добавится не только справочник авторов, но и таблица связи авторов с диском - "Авторы_диска", а из таблицы "Диски" исчезнет поле "Автор".
Как-то так...