Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Вопрос про работу ERWIN'a
|
|||
|---|---|---|---|
|
#18+
Если в erwin создать 2 сущности (логическая модель), каждая из которых содержит атрибут с одинаковым именем и пытаться установить внешний ключ между ними, то erwin заставляет либо переименовать один из атрибутов, либо насильно впихивает его в PK, и не дает оттуда убрать. Зачем он так делает и как с этим бороться ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 16:04 |
|
||
|
Вопрос про работу ERWIN'a
|
|||
|---|---|---|---|
|
#18+
StalkerSлибо насильно впихивает его в PK, и не дает оттуда убрать. Потому что ты вибираешь идентифицирующее отношение (Identifying relationship). ВЫберешь non-identifying - не будет впихивать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 16:20 |
|
||
|
Вопрос про работу ERWIN'a
|
|||
|---|---|---|---|
|
#18+
Denis Popov StalkerSлибо насильно впихивает его в PK, и не дает оттуда убрать. Потому что ты вибираешь идентифицирующее отношение (Identifying relationship). ВЫберешь non-identifying - не будет впихивать. Гонишь, будет впихивать в любом случае. Это вам не SDesignor, это - настоящий ER -CASE. :)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2005, 12:10 |
|
||
|
Вопрос про работу ERWIN'a
|
|||
|---|---|---|---|
|
#18+
StalkerSЕсли в erwin создать 2 сущности (логическая модель), каждая из которых содержит атрибут с одинаковым именем и пытаться установить внешний ключ между ними, то erwin заставляет либо переименовать один из атрибутов, либо насильно впихивает его в PK, и не дает оттуда убрать. Что-то я не понял. Он в любом случае попросить переименовать атрибут в дочерней таблице, либо сказать, что атрибут в дочерней будет связан с родительской, либо поставить RoleName ( другое имя для проносимого по связи атрибута). Будет он класть его в PK или нет - это вопрос другой. StalkerS Зачем он так делает и как с этим бороться ? А затем, что делать FK без пронесения в доч. таблицу атрибутов PK родительской бессмысленно. Так (неправильно) позволяет делать напр. SDesigner (на сколько я в курсе, может мои сведения и устарели), а ErWIN наоборот - не позволяет. И это гарантирует что в дочерней таблице всегда будут атрибуты PK родительской, на которую они ссылаются. Что ты их руками не забудешь добавить. Бороться так : Когда ты проносишь связь, в дочернюю таблицу добавляются поля из PK родительской. Если хоть один атрибут из родительской таблицы в дочерней уже есть (атрибуты ErWIN идентифицирует по их логическим именам), то вам будет предложено ( в вер. начиная с 3.5.2) на выбор : Сделать RoleName для проносимых атрибутов род. табл. (т.е. попросту их переименовать) Переименовать атрибут(ы) в дочерней таблице Сказать, что этот атрибут(ы) в дочерней и есть тот (те) самый атрибут(ы), которые проносятся по связи (т.е. слить их воедино). По-моему функционально подный набор действий, ни с чем бороться не нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2005, 12:21 |
|
||
|
Вопрос про работу ERWIN'a
|
|||
|---|---|---|---|
|
#18+
MasterZivГонишь, будет впихивать в любом случае. Это вам не SDesignor, это - настоящий ER -CASE. :)) В SDedigner'е, как, впрочем, и в PowerDesigner'е на панели кнопка только одна - Reference, а в ERwin'е их две: Identifying relationship и Non-identifying relationship. Впрочем, связь одного типа превращается в другую через редактирование ее свойств. Я про то, что впихивать существующий атрибут в PK дочерней таблицы будет предлагать именно Identifying relationship, а не вторая. В физической модели PD такое понятие как Identifying/Non-identifying по-моему вообще отсутствует, по крайней мере я сам потом указываю PK у дочерней таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2005, 13:17 |
|
||
|
Вопрос про работу ERWIN'a
|
|||
|---|---|---|---|
|
#18+
Хорошо, тогда помогите разобраться, что есть идентифицирующая связь, а что нет. Имеем такие такие таблицы : Заказ -------- НазваниеЗаказа (РК) Активность (естественный первичный ключ - "НазваниеЗаказа") Изделие ------- id_изделия (РК) НазваниеЗаказа НазваниеИзделия (естественный первичный ключ - "НазваниеЗаказа"+"НазваниеИзделия") Деталь --------- id_детали (РК) Шифр id_изделия Название (естественный первичный ключ - "Шифр"+"id_изделия"+"Название") Вот соединяем первые две таблицы - вроде как связь идентифицирующая (изделие не может существовать без заказа), но тогда НазваниеЗаказа лезет в первичный ключ, а оно там нафиг не нужно. Аналогично с 2й и 3й таблицей - id_изделия пойдет в первичный ключ, хотя я его там видеть не желаю. Если-же из таблицы Изделие убрать id_изделия и РК сделать естественным ключом ("НазваниеЗаказа"+"НазваниеИзделия"), то в первичном ключе таблицы Деталь соответственно окажется "НазваниеЗаказа"+"НазваниеИзделия", что уж точно ни в какие ворота не лезет. А ведь id_детали учавствует в массе сущностей, таскать первичный ключ из кучи полей нельзя. Что-же тут делать ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2005, 16:57 |
|
||
|
Вопрос про работу ERWIN'a
|
|||
|---|---|---|---|
|
#18+
StalkerSВот соединяем первые две таблицы - вроде как связь идентифицирующая (изделие не может существовать без заказа), но тогда НазваниеЗаказа лезет в первичный ключ, а оно там нафиг не нужно. Ну и делай связи неидентифицирующими. А вот "изделие не может существовать без заказа" - это другое: у отношения поставь Cardinality: One or More (буква P на схеме) и Nulls: No Nulls. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2005, 17:22 |
|
||
|
Вопрос про работу ERWIN'a
|
|||
|---|---|---|---|
|
#18+
Тогда я что-то не догоняю отличия идентифицирующих связей от неидентифицирующих. Я нашел такие их определения: ---------------------- Идентифицирующим является отношение между двумя сущностями, в котором каждый экземпляр подчиненной сущности идентифицируется значениями атрибутов родительской сущности. Это означает, что экземпляр подчиненной сущности зависит от родительской сущности и не может существовать без экземпляра родительской сущности. В идентифицирующем отношении единственный экземпляр родительской сущности связан с множеством экземпляров подчиненной. Атрибуты первичного ключа родительской сущности мигрируют в атрибуты подчиненной, чтобы стать там атрибутами первичного ключа. ---------------------- -------------------- Неидентифицирующим является отношение между двумя сущностями, в котором каждый экземпляр подчиненной сущности не зависит от значений атрибутов родительской сущности. Это означает, что экземпляр подчиненной сущности не зависит от родительской сущности и может существовать без экземпляра родительской сущности. В неидентифицирующем отношении единственный экземпляр родительской сущности связан с множеством экземпляров подчиненной. Атрибуты первичного ключа родительской сущности мигрируют в подчиненную, чтобы стать там не ключевыми атрибутами. --------------------- Изделие-же напрямую зависит от заказа, разве нет так ? Оно не может без него существовать. Почему-же его можно ставить неидентифицирующим ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2005, 17:35 |
|
||
|
Вопрос про работу ERWIN'a
|
|||
|---|---|---|---|
|
#18+
Извините, возвращаюсь к теме вопроса. Чтобы при установлении связи правильно мигрировал атрибут связи, просто укажите имя роли для мигрирующего атрибута, отличное от имени поля, с которым наблюдается конфликт. Вот и все. Причем, если в данном слечае, при конфликте имен полей дело касается уникальности имени поля первичного ключа, все заканчивается "принудительным" переименованием либо поля первичного ключа одной из таблиц, либо удалением такого поля из состава ПК, либо выведением такого поля из состава ПК, либо вовсе удалением такого поля (Несмотря на все вопли девелопера ), то в ситуации, когда выполняешь несколько однотипных связей между двумя таблицами ( "Сотрудники" ... "Рабочее место" три связи, к примеру - Закреплен, Начальник, Фактический работник), ErWin просто смолчит. В этом случае просто нужно явно указывать Rolename, отличное от имен уже существующих атрибутов. Например: в Вашем случае - имя ключевого поля для обоих таблиц = Id, тогда укажите имя роли = Id_Ext, и все будет OK. А как же иначе-то?! -- Мимопроходивший != Мимопроходящий ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 23:47 |
|
||
|
Вопрос про работу ERWIN'a
|
|||
|---|---|---|---|
|
#18+
на приведенной схеме действительно неверно изображено идентифицирующая связь., в отношении менять нужно не Nulls: No Nulls., а тип TYPE:Identifying. а так схема читается не в соответствии с тем , что про неё написано. идентифицирующее отношение в приложенном файле ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2005, 06:20 |
|
||
|
Вопрос про работу ERWIN'a
|
|||
|---|---|---|---|
|
#18+
хотя, если подумать, в том , что написал Денис, он прав. можно так сделать. но всё равно я не вижу на схеме, что Nulls: No Nulls. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2005, 06:33 |
|
||
|
Вопрос про работу ERWIN'a
|
|||
|---|---|---|---|
|
#18+
но делать можно по разному. только изначальный вопрос был не про как сделать, а как ервин делает :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2005, 06:44 |
|
||
|
Вопрос про работу ERWIN'a
|
|||
|---|---|---|---|
|
#18+
Запутаться в трех таблицах - это великое искусство. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2005, 12:07 |
|
||
|
Вопрос про работу ERWIN'a
|
|||
|---|---|---|---|
|
#18+
_AndreyPхотя, если подумать, в том , что написал Денис, он прав. можно так сделать. но всё равно я не вижу на схеме, что Nulls: No Nulls. Это логическая схема:) Я е нашел, можно ли на ней отображать обязательность атрибутов. На физической можно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 12:14 |
|
||
|
Вопрос про работу ERWIN'a
|
|||
|---|---|---|---|
|
#18+
Denis Popov _AndreyPхотя, если подумать, в том , что написал Денис, он прав. можно так сделать. но всё равно я не вижу на схеме, что Nulls: No Nulls. Это логическая схема:) Я е нашел, можно ли на ней отображать обязательность атрибутов. На физической можно. Можно на ней тоже - в свойствах самой связи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 14:29 |
|
||
|
Вопрос про работу ERWIN'a
|
|||
|---|---|---|---|
|
#18+
StalkerSТогда я что-то не догоняю отличия идентифицирующих связей от неидентифицирующих. Я нашел такие их определения: ---------------------- Идентифицирующим является отношение между двумя сущностями, в котором каждый экземпляр подчиненной сущности идентифицируется значениями атрибутов родительской сущности. Это означает, что экземпляр подчиненной сущности зависит от родительской сущности и не может существовать без экземпляра родительской сущности. В идентифицирующем отношении единственный экземпляр родительской сущности связан с множеством экземпляров подчиненной. Атрибуты первичного ключа родительской сущности мигрируют в атрибуты подчиненной, чтобы стать там атрибутами первичного ключа. ---------------------- -------------------- Неидентифицирующим является отношение между двумя сущностями, в котором каждый экземпляр подчиненной сущности не зависит от значений атрибутов родительской сущности. Это означает, что экземпляр подчиненной сущности не зависит от родительской сущности и может существовать без экземпляра родительской сущности. В неидентифицирующем отношении единственный экземпляр родительской сущности связан с множеством экземпляров подчиненной. Атрибуты первичного ключа родительской сущности мигрируют в подчиненную, чтобы стать там не ключевыми атрибутами. --------------------- Изделие-же напрямую зависит от заказа, разве нет так ? Оно не может без него существовать. Почему-же его можно ставить неидентифицирующим ? Кроме того, что связи бывают идентифицирующими и неидентифицирующими, они еще бывают обязательными и необязательными. Идентифицирующая связь всегда является обязательной. А вот неидентифицирующая может быть как обязательной, так и нет. Неидентифицирующая обязательная = идентифицирующей с даталогической точки зрения, с тем отличием, что первичный ключ родительской сущности в первичный ключ дочерней сущности не мигрирует. Т.е. является foreign key NOT NULL. (Именно этот случай тебе и нужен, если не хочешь, чтобы был составной PK). Идентифицирующая связь вообще редко когда нужна. ИМХО. Подтверждением тому является отсутствие ее как таковой в PD. А вообще, когда нарисуешь побольше, чем три сущности, то и сам скоро все поймешь... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 14:39 |
|
||
|
Вопрос про работу ERWIN'a
|
|||
|---|---|---|---|
|
#18+
StalkerSТогда я что-то не догоняю отличия идентифицирующих связей от неидентифицирующих. Неидентифицирующая связь помещает проносимые из первичного ключа родительской сущности атрибуты в неключевые атрибуты дочерней таблицы. Идентифицирующая связь проносит атрибуты первичного ключа родительской таблицы в первичный ключ дочерней таблицы. Вот и все отличие. Ну а далее можно навернуть много философии. Если ПК родительской таблицы есть в ПК дочерней, то запись в дочерней не может существовать без записи в родительской (поскольку есть FK). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2005, 16:25 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=33257537&tid=1545682]: |
0ms |
get settings: |
7ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
24ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
| others: | 260ms |
| total: | 378ms |
| 0 / 0 |
