Что такое концепция «Таблица сохраненных ключей»?

Я прочитал в документации Oracle о сохраненной на ключе таблице в разделе Обновление представлений соединения.

Тем не менее, я не нашел простой способ понять это.

Я надеюсь получить некоторые простые концептуальные подробности, помимо официальной документации Oracle.

Сохранение ключа означает, что 1 значение ключа попадает в 1 таблицу. Предоставление контрпримеров может помочь вам лучше понять эту концепцию.

Example1:

Ваш вид содержит агрегацию. Предположим, у вас есть следующая структура представления.

GroupID, AverageSalary
1 , 10000
2, 12000
3, 14000

В этом примере: ваши значения поступают из нескольких строк. Если вы попытаетесь обновить AverageSalary в этом представлении, база данных не сможет найти, какие строки нужно обновить.

Пример 2: Ваше представление показывает значения из более чем одной таблицы. В вашем представлении отображаются значения из таблицы PERSON и PERSON_CONTACT_DETAILS (ID, PersonID, ContactType, ContactValue).

Пример строки:

 1,1,email,ddd@example.com
 1,1,phone,898-98-99

Вы присоединяетесь к этой 2 таблице и показываете больше информации для бизнеса.

PersonId, Имя, Фамилия, Телефон1, Электронная почта1

Здесь вы хотели бы обновить Phone1 и Email1. Но ваш personID отображается в две разные строки, в этом примере может быть больше строк. В этом представлении, опять же, база данных не может найти какие строки для обновления.

Примечание. Если вы ограничиваете свой вид sql и четко указываете, какие строки для обновления могут работать.

Этот два примера - первые примеры, которые приходят мне в голову. Они могут быть увеличены. Но концепция понятна. База данных должна отобразить 1 значение ключа на 1 таблицу. Например, у вас есть таблицы PERSON, PERSON_DETAILS один на один. Здесь просмотр и обновление будут работать, так как это один в один.

Документации вы уже читали это говорит довольно хорошо. Чтобы объяснить дальше:

Концепция таблицы, сохраняемой ключом, является фундаментальной для понимания ограничений на изменение представлений объединения.

Обычно updateдействует на одном столе. Чтобы избежать извилистых подзапросов в фильтре, Oracle позволяет вам updateпросматривать (или подзапрос) представление, пока оно все еще может легко отображать изменения, которые вы вносите, в реальные базовые строки таблицы. Это возможно, если в setпредложении изменяются только столбцы в таблице с сохранением ключа:

Таблица сохраняется ключом, если каждый ключ таблицы также может быть ключом результата объединения. Таким образом, таблица, сохраненная ключами, имеет ключи, сохраненные посредством объединения.

Например:

create table foo( foo_id integer primary key, foo_val integer not null );
create table bar( bar_id integer primary key, bar_val integer not null, 
                  foo_id integer not null references foo );

update (select * from foo join bar using(foo_id)) set foo_val=1;
ORA-01779: cannot modify a column which maps to a non key-preserved table

update (select * from foo join bar using(foo_id)) set bar_val=1;
0 rows updated.

первое обновление терпит неудачу , потому что Oracle не имеет возможности 1: 1 отображение foo_valв запросе , чтобы foo_valв foo- наоборот, второе обновление успешно , так как Oracle может 1: 1 сопоставьте каждый bar_valна bar_valв bar. Важно то, что foo_idон уникален foo- поэтому для каждой строки barможет быть только одна соответствующая строка foo(на самом деле ровно 1 в этом примере, но то же самое относится и к внешнему ключу, допускающему значение NULL) - дело в том, что более одного ряда).

Позвольте мне сначала привести пример, а потом объяснить. Рассмотрим 2 таблицы студентов (t_students) и курса (t_course).

• Таблица студентов (stundentid, name, courseid) имеет первичный ключ для идентификатора студента.
• Таблица курса (courseid, coursename) имеет первичный ключ для идентификатора курса.

Когда эти две таблицы объединены ->

select * from t_students S, t_course C where S.courseid=C.courseid; 

Полученные данные будут иметь ровно столько же строк, сколько и таблица учеников. В наборе результатов не будет повторяющихся значений studentid (studentid сохраняется). Тем не менее, несмотря на то, что идентификатор курса уникален в таблице курсов, он будет повторяться несколько раз в наборе результатов, так как многие студенты могли выбрать один и тот же курс (другими словами, курс не сохраняется).

Используя этот пример, вы можете прийти к выводу, что:

• Каждый ключ в базовой таблице действует как ключ к результирующим данным после объединения (studentid)
• Строки из базовой строки появляются в результирующих данных максимум один раз (без повторяющихся строк).

Это концепция ключевых сохраненных таблиц.

Чтобы узнать, являются ли столбцы представления обновляемыми,

select * from all_updatable_columns where table_name='V_VIEW_NAME';

PS: укажите название таблицы / представления заглавными буквами.