Преобразование логической модели в физическую модель. Проблемы с пониманием ERD

Question

Я работаю с ERD. Это предположительно логическая модель, и я должен сделать из нее физическую модель. Я должен форматировать в UML, и наша СУБД - это PostgreSQL.

Некоторые из моих исследований ( http://www.1keydata.com/datawarehousing/data-modeling-levels.html // http://en.wikipedia.org/wiki/Logical_data_model) показывают, что это ERD может содержать слишком много информации, чтобы быть логической моделью, и что она на самом деле может быть ближе к физической.

Мои вопросы следующие:

1. Что означают жирные метки?
2. Что означают белые "N" и красные "U" в конце некоторых записей?
3. В чем разница между пунктирной линией (отношениями) и сплошной?
4. В чем разница между "гусиным лапками" и ломаной линией на обоих концах отношений?
5. Это ближе к физической модели или логической модели? Что мне нужно сделать, чтобы преобразовать его из одного в другое?

Это ERD:

Answer 1

1. Может ли жирный текст указывать атрибуты первичного ключа?
2. Это не является частью какой-либо стандартной записи ER моделирования. Ни в коем случае не уверен, но мое предположение будет U означает уникальный, N означает Nullable.
3. Сплошная линия означает идентифицирующие отношения. Пунктирная линия означает неидентифицирующую. Обычно это не особенно важное различие, но посмотрите эти термины, если хотите узнать больше.
4. Отношение один ко многим. Гусиная лапка представляет собой "многую" сторону отношений; короткая линия поперек - "одна" сторона. Где символ "один" появляется на обоих концах, это отношение один к одному.
5. В контексте информационного моделирования логическая модель означает семантическую модель - модель, которая больше относится к бизнес-сфере, чем к фактическому дизайну базы данных. Что именно входит в логическую модель и на каком уровне детализации, во многом зависит от целевой аудитории модели и от того, как вы хотите ее использовать. Превратить его в "физическую" модель означает превратить ее в проект базы данных с техническими характеристиками и любыми изменениями, которые потребуются для выбранной вами платформы СУБД (например, для конкретных типов данных).

Логические / физические модели в смысле информационного моделирования не следует путать с так называемыми логическим уровнем и физическим уровнем в архитектуре СУБД и теории баз данных. В принципе таблицы реляционных баз данных (переменные отношения AKA) всегда являются конструкциями "логического" уровня, но в терминах моделирования данных они являются частью так называемой "физической" модели. Этот неудачный выбор терминологии моделирования является причиной многих недоразумений и недоразумений.