dxb, неправильно. Какой PowerDеsigner открываете?

Концептуальная - совсем высокоуровневые связи. Например с отношениями много-ко-многим. Или вообще три сущности на всю будущую систему.

Логическая - близка к физической - полна, насыщена, но универсальна - не привязана к конкретной СУБД.

Физическая - может содержать нюансы, присущие уже реализации конкретной СУБД.

_модdxb
Conceptual Data Model - это модель предметной области в терминах ER
Logical Data Model - это и есть МД в терминах СУБД
А физическая МД - это уже физические файлы, блоки и т.д

Серьёзно? Сами придумали?

dxb, 12-ка прошла мимо меня, но вот что на єту тему гласит официальная документация
Conceptual Data Models
A conceptual data model (CDM) helps you analyze the conceptual structure of an information system, to identify the principal entities to be represented, their attributes, and the relationships between them. A CDM is more abstract than a logical (LDM) or physical (PDM) data model.
Logical Data Models
A logical data model (LDM) helps you analyze the structure of an information system, independent of any specific physical database implementation. An LDM has migrated entity identifiers and is less abstract than a conceptual data model (CDM), but does not allow you to model views, indexes and other elements that are available in the more concrete physical data model (PDM).
Physical Data Models
A physical data model (PDM) helps you to analyze the tables, views, and other objects in a database, including multidimensional objects necessary for data warehousing. A PDM is more concrete than a conceptual (CDM) or logical (LDM) data model. You can model, reverse-engineer, and generate for all the most popular DBMSs.[/quote]

dxb, переводить нужно?

Речь идёт о трактовках "понятий", как бы это двусмысленно не звучало :).
Мы обсуждали пока 2 трактовки: "Т.Коннолли и К.Бегг" и "ПО Sybase PowerDesigner".
У каждого из нас своё видение, но ТСу в конце-концов работать с PD :) или же искать другой инструмент.

ТС читает книгу-теорию, сравнивает с ПО-практической реализацией и сомневается, правильно ли он всё понял.
Причём ТС в первом же посте расписал шаги 1,2,3, полностью соответствующие шагам создания моделей PD (15): Conceptual, Logical, Physical.
Достаточно вместо "Step 3 Translate Logical Data Model for Target DBMS" написать "Step 3 Build And Validate Physical Data Model (Translate Logical Data Model for Target DBMS)".

Внимание: если посмотреть на "забор", то видно что Logical Data Model отсутствует в документации PD12.5 и появляется в 15.0.

Я некорректно в своём первом посте дал краткое описание именно моделей для PD. Извиняюсь за некорректность, а выдержку из документации я уже привёл. Если ViPRos'у охота потроллить - пожалуйста :).

_мод, твои определения для понятий в книге или для понятий в PD?

"индексы - это элемент ФМ, т.к. нужны только для скорости (величина физическая)" - для PD - это так.

"таблицы, констрейнты, вью - ЛД". Вот тут с точки зрения PD вас ждёт засада: все эти слова при переводе как Table, Constraint, View - из физической модели PD :).

ЛМД в PD использует следующий набор: Domain, Entity, Entity Attribute, Identifier, Relationship, Inheritance...

АнатоЛойЛМД в PD использует следующий набор: Domain, Entity, Entity Attribute, Identifier, Relationship, Inheritance...
Причём после Inheritance троеточие даже излишне - на этом ряд обрывается :).

_модАнатоЛойтвои определения для понятий в книге или для понятий в PD?
Путаница понятий в PD - это проблема самого PD.
Концептуальная МД - модель предметной области в терминах ER
Логическая МД - в логических терминах СУБД
Физическая МД - в физических терминах СУБД
Все логично
Гммм... Если отталкиваться от совпадения слов, то "спору нет".
Кто бы еще ткнул пальцем:
1. в логичное разделение между "логическими" и "физическими" терминами :).
2. в подтверждение данным трактовкам - особенно с учётом метаморфоз, которые претерпевали данные понятия.

Повторюсь, ТС спрашивал про книгу и про ПД, и про корреляцию совпадающих в них названий :). Я рассказал про ПД, вы грузите про логику. ВиПРос, _мод, вы хоть книгу-то читали (в отличие от меня :) ) ?!

ViPRosАнатоЛой,

какую книгу?
я когда то читал Мартина :) году в 81-82 где то

Я понял... Вы не то что книгу (Т.Коннолли, К.Бегг "Database Design Methodology for Relational Databases"), а даже первый пост ТС не читали... Ну да... Тролли не читатели...

Вы рассказываете про трактовку понятий но основе "Мартина" + свой опыт (разные проекты + разное ПО + мозг).
ТС спрашивает про понятия в книге и понятия в ПД . Что тогда Вы с нами обсуждаете? Знакомые слова из 80-x?
Так мы долго можем спорить, что такое "шнурок": - "Элемент одежды!", "Не-е-е-е, родитель подростка..."...

_модАнатоЛойКто бы еще ткнул пальцем:
1. в логичное разделение между "логическими" и "физическими" терминами :).
2. в подтверждение данным трактовкам - особенно с учётом метаморфоз, которые претерпевали данные понятия.

"физические" элементы влияют на физические хар-ки БД - скорость , объем, расположение.
"логические" - это таблицы (сегменты, записи для не РМД) и констрейнты
никаких метаморфоз не замечал - с Мартина как повелось, так и осталось
Хотел затеять делёж поимённо, но бросил - нет времени.
Просто объясните:
"таблицы, констрейнты, вью - ЛД "
1. Какие констрейнты являются элементами ЛД? Foreign key - констрейнт? Если да - он часть ЛД?
2. Почему view - элемент ЛД? Есть сущности "Приход/расход склада" и "Остатки на складе" - ещё из Conceptual DM.
Принятие решения, будет "Остатки на складе" view (приход - расход) или же table (система правит и оброты и параллельно остатки) - чисто физическое (выбор между затратами на дублирование данных и скоростью получения остатков) - чисто физическое. Почему тогда "вью - ЛД"? .

_модПостроение ЛМ включает в себя и вопросы производительности (как ни странно)
_мод, спасибо за серьёзность и терпеливость. Итог:
1. С краткими и строгими определениями дела обстоят плохо как для книги, так и для ПД.
2. Полных параллелей понятий книги с понятиями ПД не наблюдается.

ТС, обрати внимание, что:
1) в опциях моделей есть ещё выбор нотаций
2) ПД имеет возможность "подкручивания" моделей - при большом желании можно сделать свои "правильнокнижные" модели - но угрохаешь времени немало, ибо отличия серьёзные...