Должны быть три таблицы t1, t2, t3. В t3 есть одно поле, которое внешним ключом ссылается сразу на t1 и t2. Если ключи простые, все нормально. Если оба ключа с каскадным обновлением, матерится (не дает создать t3). Если только один из них каскадный, а другой простой, дает. Говорит:
Introducing FOREIGN KEY constraint 'fk_t3_t2_code' on table 't3' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.
Почему? Если уж есть два ключа, то, казалось бы, надо либо не давать обновлять никакие, либо уж давать обновлять все. ????

Нет, между t1 и t2 связей нет. Есть еще таблица t0, на которую ссылаются t1 и t2, а на обе из них ссылается t3. Вот структура:

-- Таблица t0
create table cd_parthners (
code varchar(20) not null,
name varchar(50) not null,
constraint pk_cd_parthners primary key (code)
)

-- Таблица t1
create table cd_phone_groups (
cd_parthner_code varchar(20) not null,
code varchar(20) not null,
name varchar(50) not null,
constraint pk_cd_phone_groups primary key (cd_parthner_code, code),
constraint fk_cd_phone_groups_cd_parthners foreign key (cd_parthner_code) references cd_parthners (code) on update cascade
)

-- Таблица t2
create table cd_phone_infos (
cd_parthner_code varchar(20) not null,
phone varchar(30) not null,
first_name varchar(50) not null,
middle_name varchar(50) null,
last_name varchar(50) not null,
constraint pk_cd_phone_infos primary key (cd_parthner_code, phone),
constraint fk_cd_phone_infos_cd_parthner_code foreign key (cd_parthner_code) references cd_parthners (code) on update cascade
)

-- Таблица t3
create table cd_gi_rels (
cd_parthner_code varchar(20) not null,
cd_phone_group_code varchar(20) not null,
phone varchar(30) not null,
constraint pk_cd_gi_rels primary key (cd_parthner_code, cd_phone_group_code, phone),
constraint fk_cd_gi_rels_cd_groups
foreign key (cd_parthner_code, cd_phone_group_code) references cd_phone_groups (cd_parthner_code, code) on update cascade,
constraint fk_cd_gi_rels_cd_phones
foreign key (cd_parthner_code, phone) references cd_phone_infos (cd_parthner_code, phone) /* вот если здесь поставить on update cascade, не даст, а нужно каскадно обновлять поле cd_phone_infos.phone. */
)

Попробую через триггер instead update на cd_phone_infos.

Но почему все-таки он не дает?

PS. Спасибо тому, кто не поленится это все читать :)

Уважаемая Ольга!

Спасибо, что потрудились вникнуть в мою проблему.

Задача такая: есть данные о владельцах телефонов (cd_phone_infos), которые могут входить в группы (cd_phone_groups). Связь многие ко многим, поэтому есть еще таблица связей (cd_gi_rels). Но дело в том, что вся информация хранится отдельно для каждого из "партнеров" (это организации). Проблема в том, что и владельцы, и группы должны быть привязаны к партнерам, а это может привести к тому, что появится связь между группой и владельцем телефона (в cd_gi_rels), принадлежащих разным группам. Можно было сделать на триггерах, но хотелось поизящней. Поэтому решил сделать так: PK таблицы владельцев - код партнера + номер телефона, PK таблицы групп - код партнера + код группы. Таблица связей содержит код партнера, код группы и код владельца, и получается, что 3 поля содержат ссылки на 2 ключа из двух элементов каждый. Таким образом, противоречивую информацию ввести невозможно, но поле cd_gi_rels.parthner_code участвует сразу в двух внешних ключах. Поэтому каскадное обновление обоих невозможно. (Почему, не знаю - это и было темой первого вопроса.) И теперь нельзя каскадно менять номер телефона владельца, что плохо. Хотел сделать триггер instead of update, но нельзя, если есть FK с каскадными обновлениями. В общем, плоховато получается.

Почему отказался от identity? Дело в том, что identity уникальна в пределах всей таблицы, и, если таблица связей будет ссылаться на код партнера + identity группы, получится ссылка на избыточный ключ, что тоже неизящно. Если ссылаться только на identity, опять же, возможен ввод противоречивых данных.

Ольга, большое спасибо за совет, но дело в том, что таблицу владельцев телефонов нельзя отвязывать от партнеров, т.к. владельцы телефонов могут и не входить ни в какие группы. А информация об одном и том же владельце телефона у разных организаций (партнеров) может быть разная. И каждая группа относится только к одной организации. Так что при связывании группы и владельца, если использовать identity, можно связать владельца и группу разных партнеров. Поэтому и включил в таблицу связей код партнера. А вообще, что касается identity, оно сильно девальвирует понятие первичного ключа. Что это за PK, который не несет НИКАКОЙ информации о сущности? Я сам до недавнего времени злоупотреблял identity, но понял, что оно годится только для таблиц, у которых по сути нет уникальных ключей (например, банковские проводки или неподробная информация о клиентах). Кстати, в книгах о БД в примерах первичные ключи обычно реальные. А больший размер внешних ключей не критичен, если записей не слишком много. Еще раз спасибо за ценные советы.

Glory, спасибо большое, по-видимому, сделаю, как Вы советуете.

Добрый день, прошу прощения за молчание: был в отпуске неделю.

ASCRUS, Ольга, спасибо за советы. Действительно, искусственный ключ + уникальный индекс - хороший способ, им я до этого и пользовался, но захотел попробовать без избыточных полей. Не получается - сложно и неудобно. Воспользуюсь привычным identity, и группировать будет просто. Еще раз большое спасибо.