(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 

Конференция "ERwin"

Обсуждение вопросов, связанных с компанией Computer Associates, ее продуктами ERwin Data Modeler, ERwin Web Portal, ARCserve и др.

 
 
Добавить сообщение »

Тема: Вопрос Игоря Панченко

Автор:  Сергей Маклаков Дата: 12.03.2001 12:42
Могла, но название сложилось исторически
:)

Артем Неганов пишет 11.03:
>Сергей, как Вы считаете, эта тема могла называться не
>
><b>Вопрос Игоря Панченко</b>
>

>
><b>IDEF1x: ERwin: миграция ключей</b>?
>
>:)
Ответить на сообщение »
 
Автор:  Артем Неганов Дата: 11.03.2001 16:39
Сергей, как Вы считаете, эта тема могла называться не

<b>Вопрос Игоря Панченко</b>

а

<b>IDEF1x: ERwin: миграция ключей</b>?

:)
Ответить на сообщение »
 
Автор:  Сергей Маклаков Дата: 11.03.2001 10:17
Уважаемый Игорь,
Признаю свою ошибку - в своем предыдущем ответе вместо "Миграция части ключа при установлении идентифицирующей связи в IDEF1X невозможна" следует читать "Миграция части ключа при установлении идентифицирующей связи в ERwin 3.5.2 невозможна". (но, кстати, изменить функциональность ERwin 3.5.2 я не в состояниии, так же как изменить стандарт IDEF1X). Да, действительно, некоторые CASE - средства позволяют осуществить миграцию не первичного ключа. В ERwin 4.0 можно установить идентифицирующую связь с миграцией альтернативного ключа.




Игорь Панченко пишет 07.03:
>Уважаемый Сергей Владимирович. Вы совершенно правильно обращаете мое внимание на то, что такое идентифицирующая связь. Но по-моему, Вы лукавите, и следствие ставите впереди причины. Я понял, что определение идентифицирующей связи звучит так:
>An identifying relationship is a relationship between two entities in which an instance of a child entity is identified through its association with a parent entity, which means the child entity is dependent on the parent entity for its identify and cannot exist without it. (Help по Erwin)
>В моем случае строка накладной НЕ может существовать без накладной, как это допускается для не идентифицирующей связи. А вот то, что атрибуты первичного ключа мигрируют в дочернюю при идентифицирующей связи, это (как я подозреваю) допущения, которое позволяет облегчить анализ схемы уже непосредственно программе оболочке. Тогда мы имеем то, что имеем. И кстати этот вопрос возникает не только у меня (см. предыдущее сообщение "ERwin и генерация внешних ключей/ 3 таблицы". Судя по всему, другие CASE продукты не выставляют такого строго требование на идентифицирующую связь. И, наверно, это более правильно? А цепочка НЕ РВЕТСЯ! Просто атрибут из первичного ключа родительской сущности я заношу в качестве ОБЯЗАТЕЛЬНОГО атрибута AK. Где же здесь разрыв? Другое дело что анализировать ERwin-у уже сложнее... Я не прав?
>
>>Уважаемый Игорь,
>>Давайте обсудим, что же такое идентифицирующая связь и как она реализуется в IDEF1X. При создании идентифицирующей связи все атрибуты первичного ключа родительской сущности мигрируют в состав первичного ключа дочерней. В результате после генерации схемы СУБД не позволит вставить дочернюю запись без родительской. И так далее по цепочке, если у дочерней есть другая дочерня сущность и т.д. Если Вы меняете первичный ключ на суррогатный то "цепочка рвется" и можно вставить дочернюю запись без соответствующей родительской. Вам придется выбирать - или миграция ключей и идентифицирующие связи или суррогатные ключи и неидентифицирующие. По смыслу Вам, видимо, более подойдут обязательные неидентифицирующие связи. Миграция части ключа при установлении идентифицирующей связи в IDEF1X невозможна. Можно, конечно, попробовать изменить стандарт IDEF1X, но тут я Вам не помошник :)
>
Ответить на сообщение »
 
Автор:  Игорь Панченко Дата: 07.03.2001 15:55
Уважаемый Сергей Владимирович. Вы совершенно правильно обращаете мое внимание на то, что такое идентифицирующая связь. Но по-моему, Вы лукавите, и следствие ставите впереди причины. Я понял, что определение идентифицирующей связи звучит так:
An identifying relationship is a relationship between two entities in which an instance of a child entity is identified through its association with a parent entity, which means the child entity is dependent on the parent entity for its identify and cannot exist without it. (Help по Erwin)
В моем случае строка накладной НЕ может существовать без накладной, как это допускается для не идентифицирующей связи. А вот то, что атрибуты первичного ключа мигрируют в дочернюю при идентифицирующей связи, это (как я подозреваю) допущения, которое позволяет облегчить анализ схемы уже непосредственно программе оболочке. Тогда мы имеем то, что имеем. И кстати этот вопрос возникает не только у меня (см. предыдущее сообщение "ERwin и генерация внешних ключей/ 3 таблицы". Судя по всему, другие CASE продукты не выставляют такого строго требование на идентифицирующую связь. И, наверно, это более правильно? А цепочка НЕ РВЕТСЯ! Просто атрибут из первичного ключа родительской сущности я заношу в качестве ОБЯЗАТЕЛЬНОГО атрибута AK. Где же здесь разрыв? Другое дело что анализировать ERwin-у уже сложнее... Я не прав?

>Уважаемый Игорь,
>Давайте обсудим, что же такое идентифицирующая связь и как она реализуется в IDEF1X. При создании идентифицирующей связи все атрибуты первичного ключа родительской сущности мигрируют в состав первичного ключа дочерней. В результате после генерации схемы СУБД не позволит вставить дочернюю запись без родительской. И так далее по цепочке, если у дочерней есть другая дочерня сущность и т.д. Если Вы меняете первичный ключ на суррогатный то "цепочка рвется" и можно вставить дочернюю запись без соответствующей родительской. Вам придется выбирать - или миграция ключей и идентифицирующие связи или суррогатные ключи и неидентифицирующие. По смыслу Вам, видимо, более подойдут обязательные неидентифицирующие связи. Миграция части ключа при установлении идентифицирующей связи в IDEF1X невозможна. Можно, конечно, попробовать изменить стандарт IDEF1X, но тут я Вам не помошник :)
Ответить на сообщение »
 
Автор:  Сергей Маклаков Дата: 07.03.2001 14:57
Уважаемый Игорь,
Давайте обсудим, что же такое идентифицирующая связь и как она реализуется в IDEF1X. При создании идентифицирующей связи все атрибуты первичного ключа родительской сущности мигрируют в состав первичного ключа дочерней. В результате после генерации схемы СУБД не позволит вставить дочернюю запись без родительской. И так далее по цепочке, если у дочерней есть другая дочерня сущность и т.д. Если Вы меняете первичный ключ на суррогатный то "цепочка рвется" и можно вставить дочернюю запись без соответствующей родительской. Вам придется выбирать - или миграция ключей и идентифицирующие связи или суррогатные ключи и неидентифицирующие. По смыслу Вам, видимо, более подойдут обязательные неидентифицирующие связи. Миграция части ключа при установлении идентифицирующей связи в IDEF1X невозможна. Можно, конечно, попробовать изменить стандарт IDEF1X, но тут я Вам не помошник :)


>Еще одна попытка уточнить вопрос. Предыдущее сообщение, почему-то в форуме не появилось!?
>Проблема в том что связь ДЕЙСТВИТЕЛЬНО идентифицирующая! Т.е. дочерняя запись не может существовать без родительской, ведь это является признаком идентифицирующей связи, не так ли? А иметь у нижней дочерней сущности (в такой цепочке) несколько десятков атрибутов в PK не зачем!!! В конечном итоге это перегружает таблицу и снижает эффективность работы БД. По-моему, здесь прокол в нотации IDEF1X. Иметь же не идентифицирующую связь на схеме в ERwin в этом случае - это вводить в заблуждение других читателей схемы, ведь идентифицирующая связь должна быть видна "сходу".
>С уважением, Игорь Панченко.
>
>>Ответ. В этом случае ПРИНЦИПИАЛЬНО необходимо устанавливать неидентифицирующие связи. Ваше замечание, как раз свидетельствует об этом. Фактически , это описание создание суррогатного ключа и замены идентифицирующей связи на неидентифицирующую.
>
>
Ответить на сообщение »
 
Автор:  Игорь Панченко Дата: 07.03.2001 10:04
Еще одна попытка уточнить вопрос. Предыдущее сообщение, почему-то в форуме не появилось!?
Проблема в том что связь ДЕЙСТВИТЕЛЬНО идентифицирующая! Т.е. дочерняя запись не может существовать без родительской, ведь это является признаком идентифицирующей связи, не так ли? А иметь у нижней дочерней сущности (в такой цепочке) несколько десятков атрибутов в PK не зачем!!! В конечном итоге это перегружает таблицу и снижает эффективность работы БД. По-моему, здесь прокол в нотации IDEF1X. Иметь же не идентифицирующую связь на схеме в ERwin в этом случае - это вводить в заблуждение других читателей схемы, ведь идентифицирующая связь должна быть видна "сходу".
С уважением, Игорь Панченко.

>Ответ. В этом случае ПРИНЦИПИАЛЬНО необходимо устанавливать неидентифицирующие связи. Ваше замечание, как раз свидетельствует об этом. Фактически , это описание создание суррогатного ключа и замены идентифицирующей связи на неидентифицирующую.
Ответить на сообщение »
 
Автор:  Игорь Панченко Дата: 06.03.2001 15:20
Честно говоря, я не понял ответ.
Вопрос о том какой тип связи идентифицирующий или не идентифицирующий устанавливать, определяется отношением между родительской и дочерней сущностью, а не тем мигрирует или не мигрирует PK в FK. В моем случае экземпляр дочерней сущности НЕ МОЖЕТ существовать без родительской, т.е. типичное определение идентифицирующей связи. А вопрос в другом: насколько хорошо "тащить" за собой атрибуты PK всех родителей через цепочку из нескольких сущностей связанных ДЕЙСТВИТЕЛЬНО идентифицирующей связью. В результате у нижней дочерней сущности в PK содержится порядка двадцати атрибутов!!! Вы можете объяснить зачем так необходимо "протаскивать" все атрибуты? Почему нельзя использовать в этой цепочке "суррогатный" ключ, ведь в этом случае количество атибутов у PK в нижней дочерней сущности может быть всего пара атрибутов? Я допускаю, что такое правило в нотации IDEF1X введено для упрощения поддержки Referential Integrity, но в данном примере это приводит к разбуханию нижней дочерней сущности, а в конечном итоге к разбуханию таблицы, сложному первичному Индексу, состоящему из большого количества атрибутов и соответственно к снижению эффективности работы БД. Или я не прав?
С уважением, Игорь Панченко.

>Ответ. В этом случае ПРИНЦИПИАЛЬНО необходимо устанавливать неидентифицирующие связи. Ваше замечание, как раз свидетельствует об этом. Фактически , это описание создание суррогатного ключа и замены идентифицирующей связи на неидентифицирующую.
>>я при проектировании такой цепочки >заводил у ДочьN в качестве PK атрибут >ДочьN_Code (каждый экземляр сущности >имеет уникальный атрибут ДочьN_Code) и >не тащил все атрибуты от родительских >сущностей в дочерние
>
>
Ответить на сообщение »
 
Автор:  Сергей Маклаков Дата: 05.03.2001 16:00
Вопрос: Добрый день, Сергей Владимирович. Прочитал Вашу книгу и ознакомился с Вашей статьей по ERwin. Очень полезный продукт, жаль что мы его не использовали ранее. Но, естественно, образовались вопросы, ответы на которые в полном объеме мне найти не удалось. Можно ли проконсультироваться у Вас?
Один из вопросов прост, но принципиален (для меня:).
Он полностью совпадает с вопросом на сервере PLATINUM FAQ ERwin:
Q3: How do I get only part of my primary key to migrate?
Дело в том, что ответ меня не удовлетворил. А как быть если я имею каскад из Сущностей связанных Идентифицирующей связью.
(Родитель->Дочь1->...->ДочьN). По нотации IDEF1X я вынужден (вернее ERwin это делает автоматом) мигрировать PK от Родительской сущности до ДочериN по дороге собирая атрибуты всех PK дочерних сущностей? В результате у ДочьN я получу PK состоящий из атрибутов количество которых будет больше N?
Воспользоваться предложением отображать эту миграцию только в Logical only я не хочу, потому как хочу иметь атрибут PK от родительской сущности в дочерней. Обычно, я при проектировании такой цепочки заводил у ДочьN в качестве PK атрибут ДочьN_Code (каждый экземляр сущности имеет уникальный атрибут ДочьN_Code) и не тащил все атрибуты от родительских сущностей в дочерние. Зачем перегружать таблицу? Теперь же мне в этой ситуации при миграции ERwin вставляет в PK дочерней сущности еще и атрибут из PK родительской, при этом нарушается второе правило нормализации. Как, на Ваш взгляд, можно ли использовать такой принцип построения связей можду сущностями, и как их отображать в ERwin. Да, сущности в этой цепочки ПРИНЦИПИАЛЬНО связаны идентифицирующими связями.

Ответ. В этом случае ПРИНЦИПИАЛЬНО необходимо устанавливать неидентифицирующие связи. Ваше замечание, как раз свидетельствует об этом. Фактически , это описание создание суррогатного ключа и замены идентифицирующей связи на неидентифицирующую.
>я при проектировании такой цепочки >заводил у ДочьN в качестве PK атрибут >ДочьN_Code (каждый экземляр сущности >имеет уникальный атрибут ДочьN_Code) и >не тащил все атрибуты от родительских >сущностей в дочерние
Ответить на сообщение »
 

Добавить сообщение »

 Распечатать »
 Правила публикации »
   
 Рекомендовать »  
 

Магазин программного обеспечения   WWW.ITSHOP.RU
erwin Data Modeler Navigator Edition r9.7 - Product plus 1 Year Enterprise Maintenance Commercial
erwin Data Modeler Workgroup Edition r9.7 - Product plus 1 Year Enterprise Maintenance Commercial
erwin Data Modeler Standard Edition r9.7 - Product plus 1 Year Enterprise Maintenance Commercial
FastReport.Desktop
WinRAR 5.x 1 лицензия
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Безопасность компьютерных сетей и защита информации
Новости ITShop.ru - ПО, книги, документация, курсы обучения
Программирование на Microsoft Access
CASE-технологии
Каждый день новые драйверы для вашего компьютера!
Новости мира 3D-ускорителей
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
Обсуждения в форумах
Заработок в сети интернет (20)
Зайди сюда - http://www.netbusin.boom.ru и узнай подробности.
 
Модульные здания от производителя (1)
Чтобы сэкономить время на строительство и существенно снизить финансовые затраты, оптимальным...
 
Отмена последнего шага в BPwin (2)
Подскажите, пожалуйста, есть ли в BPwin кнопка (функция) отмены последнего "шага", типа как в...
 
Где взять лицензионный ключ для AllFusion Process Modeler (BPwin) 7? (6)
Выручайте!!! где найти ключ, ужасно срочно нужна программа. заранее спасибо!
 
Русификация рамки IDEF0 BPWin4 (44)
Возможно ли русифицировать рамку диаграмм в BPWin4?
 
 
 



    
rambler's top100 Rambler's Top100