Такая ситуация, рисуя связь между двумя типами сущностей пусть Иерархическую где определяется какие атрибуты данная связь связывает, я как только не искал этого не нащёл, что получается что Data Modeler это просто Бизнес модель системы а не её ER модель как описано в Help, я пологал что создав модель в Data Modeler я получу её отображение в БД но у меня что-то это ни как не получается, Если кто создавал модели напишите Ваше мнение по данной теме
Спасибо

ЧТо никто не создаёт модели данных к своим программам?
Цитата из книги:
"Создание реальных прикладных программ обычно требует обработки большого кол-ва таблиц и их связей по внешнему ключу..."

Таблиц - требует. А моделей...опционально

Стандартные, типа BCFLIGHT, смотрел для примера?

>Таблиц - требует. А моделей...опционально
Немного не понял что значит опционально (видимо когда требуется ты хотел сказать) но скажу так если ты просто создашь таблицы, свяжешь, сделаешь в общем всё красиво и не построишь модель это будет тоже самое что сделать физическую модель без логической. А как ты знаешь любая модель несёт в себе как аналитическое описание так и синтетическое (т.е. логич и физич), в данном случае если не сделать модель (которая как я понимаю несёт в SAP Только аналетический смысл без синтетического т.к. не позволяет прокинуть связи на физический уровень) то в дальнейшем при анализе (или смене программистов или реинженеринге) потребуется гораздо больше времени чтобы понять то что автор хотел сообщить (это когда ты не строишь логической модели) особенно представь если проэкт огромный (БЕЗ ЭТОГО ПРОСТО НЕЛЬЗЯ)

Стандартные, типа BCFLIGHT, смотрел для примера?
А за примерчик особое спасибо только не BCFLIGHT а BC_FLIGHT,
так как этот пример описан в книге и конечно сделан поуму а не так как встретившиеся на моем пути

Спасибо

в SAPе "обработка большого количества таблиц" вовсе не подразумевает "создание большого количества таблиц" и проектирование большой функциональности, основанной на "своих" таблицах - явление достаточно редкое, видимо поэтому модели не столь востребованы, разработчики и так знают, какие связи между стандартными таблицами.

Не соглашусь с данным высказываением т.к.
Систему R/3 в общем случае можно назвать мощным средством разработки крупнейших БД, в-первую очередь хотя бы из за того что система бухучета и иные системы как раз реализованы используя данные средства разработки и из-за такого примера пусть R/3 установлена на каком-нибудь заводе, с бух учетом допустим справляется отлично, а вот о тех процессе предприятия не знает ничего, вот тут и следует группе разработчиков замечу предприятия а не SAP занятся разработкой системы на базе R/3 которая бы этот тех процес полностью реализовала, а реализовывать группа будет средствами R/3 и начнёт конечно же с DataModeler (если конечно не хочет в дальнейшем иметь трудности совершив глупость не использовать его)
2)

теоретически вы правы, НО если R/3 не удовлетворяет функциональным требованиям в такой мере - что она вообще делает на предприятии? и будет ли заказчик заинтересован во вкладывании огромных денег в отраслевое решение? поэтому такие случаи достаточно редки и не всегда обоснованы реальной необходимостью

Согласен что редки, НО все же есть! Так что и разбираться следует. Да и на мой взгляд система работает на 99% совметимо только не в странах СНГ, так как R/3 развивалась и оттачивалась на основании потребностей не этих стран.
Но разрабатывая даже малые системы с несколькими таблицами всё равно следует пользоваться средствами предназначенными для данных целей, не стоит игнорировать это вот что я хотел сказать