Целостность данных в oracle
Аннотация: Затрагиваются две темы: ограничений целостности в таблицах и построения и употребления представлений данных трех разновидностей, существующих в Oracle.
Проверочные ограничения
используете Проверочные (CHECK) ограничения применяются для обеспечения соответствия данных столбца определенным параметрам, которые вы укажете. Например,предположим, что годовая зарплата сотрудника фирмы не может быть равна или превышать $100 000 при определенных обстоятельствах. Это ограничение можно навязать с помощью следующего оператора, который устанавливает ограничение CHECK на столбце SALARY:
DBA_CONS_COLUMNS
Представление DBA_CONS_COLUMNS показывает имя столбца и позицию в таблице,где определено ограничение:
Однажды возникла необходимость организовать сложный контроль вводимой одновременно в несколько таблиц логически связанной информации в БД ORACLE. Преобразование начального логически корректного набора данных в таблицах в конечный логически корректный набор производится последовательностью DML операторов. При этом проводить модификацию может произвольный клиент поведение которого неконтролируемо а структура данных такова, что в процессе выполнения пошаговой модификации на некоторых шагах набор данных может становится логически ошибочным.
Простейший пример это таблица истории значений из трех полей: значение, начальная дата действия значения, конечная дата действия значения. Логически корректная история не может иметь записей у которых перекрываются периоды действия значений. Для изменения границы действия двух соседних значений необходимо изменить две даты — дату конца действия предыдущего значения в предыдущей записи и дату начала действия последующего в следующей записи. Если границу смены значений двигать по времени вперед и на первом шаге переставить вперед дату окончания действия значения первой записи получим логически ошибочный набор данных. Именно поэтому решить задачу табличными триггерами невозможно — они срабатывают по каждому оператору модификации данных.
Реальная задача слегка отличается от простейшего примера. Набор данных разложен в десятке таблиц, алгоритм бизнес правил контроля вылился в процедуру на 400 строк с обращением через линки к API на других серверах.
Для реализации такого контроля нужен был триггер, который срабатывает только один раз в транзакции по событию COMMIT, с возможностью отката транзакции по результату отработки процедуры контроля бизнес логики. Такой триггер нашелся.
Рассмотрим на примере подробности реализации. Набор данных.
Данные примера является набором сущностей типа — «Сотрудник» с информацией о подразделении и месте расположения подразделения. Попробуем реализовать для этих данных бизнес правило ограничивающее количество сотрудников с должностью 'CLERK' в одном городе не более 2х.
В общем случае правил бизнес контроля может быть несколько а в одной транзакции проходить модификация информации нескольких сотрудников. Соответственно на момент commit-а нам надо иметь два набора информации:
— набор полей которые были модифицированы определит список бизнес правил которые должны быть проконтролированы;
— набор идентификаторов сотрудников подлежащих контролю.
Практический список правил бизнес контроля и их сложность позволяют без критической нагрузки на сервер осуществлять проверку каждого модифицированного сотрудника по всем реализованным правилам. Это допущение позволит в нашем случае упростить реализацию ограничения целостности.
Создаем таблицу которая будет содержать набор идентификаторов сотрудников модифицированных текущей транзакцией.
На все таблицы содержащие информацию для правила контроля вешаем триггера которыми будем вставлять в emp_chk идентификаторы модифицированных сотрудников. Некоторые комментарии к триггерам. Заказчик боевого применения функционала контроля потребовал совместимость с ORACLE-9, поэтому триггера не составные (compound).
Использование MERGE вызвано желанием проводить модификацию одним оператором. Поле emp_chk.i является платой за использование MERGE т.к. написать MERGE без фразы WHEN MATCHED не удалось.
Очистку таблицы emp_chk в начале новой транзакции осуществляют следующие триггера. Управляет очисткой пакетная переменная var_chk.first_dml_in_commit:
Создаем materialized view.
Триггер инициализирующий var_chk.first_dml_in_commit обеспечивает очистку EMP_CHK в начале транзакции.
Собственно триггер запускающий бизнес контроль.
Некоторые комментарии к тексту CHK_EMP_MV_AS. Отладка и контроль функционирования констрэйнта можно облегчить логированием. Учтем, что в случае возникновения ошибки набор данных предъявленный для commit-а обычно откатывается и теряется. В данной реализации в лог пишется не только итоговый статус обработки но и весь набор данных сотрудника подвергшегося модификации предъявленный для commit-a независимо от результата обработки. Снимки наборов данных помещаются в поле emp_chk_log.XML. Лог пишется пакетной функцией var_chk.write_log в таблицу:
Все бизнес правила реализованы в отдельной функции emp_logic. Функция не является членом пакета. Это позволяет разделить в разработке и сопровождении бизнес правила констрйнта и слой системных механизмов его функционирования. Ниже текст пакета var_chk.
Функция контроля бизнес правил.
Проверим велосипед на ходу.
Реальная реализация этого решения работает на трех десятках серверов центрального офиса и филиалов с весны 2015 года.
Утверждение, представленное в качестве эпиграфа, взято из документации Oracle, но вся практика до прочтения документации указывала на противоположное. Проверка путём создания пары Unique Constraint -ов подтвердила это. Налицо ошибка в документации.
А что ещё (с надеждой на безошибочность описания) можно почерпнуть из документации об Ограничениях целостности в Oracle? Я постарался выписать различные терминологические и функциональные особенности Ограничений целостности как отдельных типов объектов БД Oracle без углубления в синтаксис и подробности их использования. Многое для меня оказалось новым, не буду скрывать.
Начнём с самого начала – Oracle9i Database Concepts Release 2 (9.2). В документации выделяется понятие «Целостность данных» ( Data Integrity ), которое связывается с выполнением бизнес-правил, сопряжённых с БД. Data Integrity делится на пять типов правил, часть из которых обеспечивается «Ограничениями целостности» ( Integrity Constraints ) СУБД Oracle :
1. NULL -правило – NOT NULL ограничение;
2. уникальные значения – ограничения уникального ключа;
3. значения первичного ключа – ограничения первичного ключа;
4. правила ссылочной целостности – ограничения внешнего ключа (или «ограничения ссылочной целостности» – в документации Oracle встречаются оба названия);
5. проверка комплексного ограничения – Check -ограничения.
(Здесь слева от тире представлено правило «Целостности данных», а справа – тип «Ограничений целостности», реализующий это правило)
Четвёртый тип правил «Целостности данных» является составным, и обеспечивается «Ограничениями целостности» лишь частично:
1. выставление в NULL зависимых данных при удалении справочных данных;
2. каскадное удаление зависимых данных при удалении справочных данных;
3. а также отсутствие какого либо действия над зависимыми данными при изменении или удалении справочных данных. (Здесь для меня осталась неясность в плане отличия Restrict от No Action . Может, кто из читателей поможет обнаружить различие…)
Оставшиеся существующие подтипы четвёртого пункта «Целостности данных»:
o выставление в NULL зависимых данных при изменении справочных данных;
o каскадное изменении зависимых данных при изменении справочных данных;
o выставление в значение по умолчанию зависимых данных при изменении или удалении справочных данных;
Те типы правил «Целостности данных», которые нельзя обеспечить с помощью существующих типов «Ограничений целостности», можно реализовать с помощью триггеров. Впрочем, любые типы правил «Целостности данных» можно организовать посредством триггеров, только этот путь более сложен и менее производителен.
Далее для краткости и в силу привычки буду использовать названия «Ограничений целостности» в английском варианте (соотнесение с вышеупомянутыми русскими названиями, на мой взгляд, очевидно), а вместо «Ограничения целостности» писать просто Ограничения.
Итак, UNIQUE Key Constraint . Это Ограничение требует, чтобы каждое значение в поле ключа было уникальным. Под понятием «значение» здесь подразумевается определённая величина, а NULL-значение под данное определение не подпадает, так что одно, два, да даже все поля в ключе UNIQUE Key Constraint могут быть равны NULL. В отличие от ключа PRIMARY Key Constraint , в котором NULL-значение не допускается вовсе.
При создании UNIQUE Key Constraints или PRIMARY Key Constraints неявно создаётся уникальный индекс по тем полям таблицы, на которые накладывается данное Ограничение. Однако, если некий (неважно – уникальный или неуникальный) индекс по полям ключа уже используется, то будет использоваться именно он вместо неявного создания нового. При удалении этих Ограничений будут удаляться и индексы. Уникальные Ограничения, созданные с атрибутом DEFERRABLE (см. ниже) всегда используют неуникальные индексы. При удалении таких Ограничений неуникальные индексы остаются.
Referential Integrity Constraint требует существования в родительской ( справочной ) таблице UNIQUE Key Constraint или PRIMARY Key Constraint. При отсутствии Ограничения NOT NULL на каком либо поле, входящем в Referential Integrity Constraint , в этом поле
допускается NULL -значение, и такой Referential Integrity Constraint будет считаться правильным.
- Если на внешнем ключе отсутствует индекс. Тогда при удалении или изменении первичного ключа родительской таблицы, Oracle будет выставлять блокировку дочерней таблицы на уровне таблицы, освобождая эту блокировку сразу после её получения. Если внешний ключ определён как ON DELETE CASCADE , то удаление записей из родительской таблицы будет приводить к share-subexclusive блокировкам на дочерней таблице. Разделяемая блокировка всей дочерней таблицы также потребуется при изменении тех полей в родительской таблице, на которые ссылаются поля дочерней таблицы. Разделяемая блокировка позволяет только чтение данных, так что ни вставка, ни удаление, ни изменение данных в дочерней таблице не будут доступны до тех пор, пока не завершится транзакция на родительской таблице.
- Если на внешнем ключе присутствует индекс, то никаких блокировок на уровне таблицы уже не будет, и при любом удалении или изменении данных в родительской таблице, в дочерней таблице будут блокированы до завершения транзакции только отдельные соответствующие записи (эксклюзивная блокировка на уровне строк).
CHECK Integrity Constraints . Допускаются на одном или нескольких полях таблицы и требует в качестве результата выполнения определённого условия TRUE или UNKNOWN для каждой строки таблицы. Примечательно, что под UNKNOWN подразумевается… NULL! Иными словами, если везде (во всяком случае, следуя той же документации Oracle) NULL -значение не равно ничему, в том числе и самому себе, то здесь оно «работает» как TRUE . Забавно, не так ли?
- может использоваться только Булево выражение;
- нельзя использовать подзапросы, SQL-функции или последовательности (интересно, почему?);
- нельзя использовать SYSDATE , UID , USE R, USERENV , LEVEL , ROWNUM .
Количество CHECK Integrity Constraints неограниченно, но порядок их срабатывания непредсказуем. Ну, и при использовании строчных литералов или таких SQL -функций, как TO_CHAR, TO_DATE, TO_NUMBER с параметрами поддержки глобализации в качестве аргументов, Oracle использует значения этих параметров по умолчанию на уровне базы. Эти значения можно переписать в создаваемом CHECK Integrity Constraint .
Все перечисленные Ограничения, реализованные в Ora c le, допускают их нарушение на уровне оператора, то есть сначала оператор будет полностью выполнен (пускай он коснётся хоть миллиона строк), а потом начнётся проверка Ограничений. Хотя, возможна отложенная проверка Ограничений– до завершения транзакции (о чём речь далее).
Режим SET CONSTRAINTS.
Оператор SET CONSTRAINTS делает Ограничения или DEFERRED , или IMMEDIATE ( DEFERRED и IMMEDIATE относятся к атрибутам Ограничений, о чём речь далее) для части транзакции. Данный оператор можно использовать для установки режима либо для списка Ограничений, либо для всех ( ALL ) Ограничений. Действие данного оператора заканчивается вместе с завершением текущей транзакции, либо с началом действия ещё одного такого же оператора. Данный оператор недоступен в триггерах.
SET CONSTRAINTS … IMMEDIATE вначале вызывает проверку наличия отложенных ранее срабатываний Ограничений, а потом уже срабатывают Ограничения, вызванные выполняющимися операторами в текущей транзакции. Любое нарушение Ограничения при таком процессе будет просигнализировано ошибкой, а при достижении COMMIT’а будет вызван полный откат текущей транзакции. Оператор ALTER SESSION также может иметь выражение SET CONSTRAINTS , но только для всех Ограничений (нельзя их перечислить списком). Это эквивалентно выполнению оператора SET CONSTRAINTS в самом начале каждой транзакции.
Выполнение оператора SET CONSTRAINTS … IMMEDIATE перед самым завершением транзакции позволяет определить успешность предстоящего COMMIT’а и избежать лишних откатов.
Состояния Ограничений.
С помощью операторов CREATE TABL E или ALTER TABLE можно задавать состояние каждого Ограничения на уровне таблицы, используя следующие выражения:
- ENABLE гарантирует удовлетворение всех входных данных Ограничению;
- DISABLE позволяет входным данным не соответствовать Ограничению;
- VALIDATE гарантирует, что все уже имеющиеся в таблице данные соответствуют Ограничению;
- NOVALIDATE позволяет уже имеющимся в таблице данным не соответствовать Ограничению;
…и их комбинации:
- ENABLE VALIDATE аналогично ENABLE и гарантирует, что абсолютно все (и уже вставленные, и вставляемые) записи удовлетворяют Ограничению;
- ENABLE NO VALIDATE гарантирует удовлетворение Ограничению всех входных данных, однако уже имеющиеся в таблице данные могут не соответствовать Ограничению;
- DISABLE NOVALIDATE аналогично DISABLE . Не гарантируется удовлетворение Ограничению как входных данных, так и уже имеющихся в таблице;
- DISABLE VALIDATE отключает Ограничение, удаляет индекс, на котором оно строилось, и запрещает любые изменения на полях, входящих в Ограничение.
… и немного об особенностях применения:
· выражение ENABLE подразумевает ENABLE VALIDATE ;
· выражение DISABLE подразумевает DISABLE NOVALIDATE ;
· VALIDATE и NOVALIDATE ничего не подразумевают в отношении ENABLE и DISABLE (скажем так, они являются зависимой частью выражения при ENABLE и DISABLE );
· про создание и удаление индексов уже упоминалось;
· при изменении состояния из NOVALIDATE в VALIDATE выполняется проверка всех имеющихся в таблице данных, что может занять очень много времени. Наоборот, при приведении состояния Ограничения из VALIDATE в NOVALIDATE просто «забывается», что имеющиеся данные когда-то соответствовали Ограничению;
· перевод одиночного ограничения из состояния ENABLE NO VALIDATE в состояние ENABLE VALIDATE не блокирует чтения, записи или другие DDL операции, они могут быть выполнены параллельно.
Ограничения ссылочной целостности
Ограничения ссылочной целостности гарантируют, что значения определенных важных столбцов будут иметь смысл. Предположим, что есть родительская таблица, которая ссылается на значения из другой таблицы, как в случае таблиц dept и employee.Сотрудник в таблице employee не может быть назначен в департамент, если такой департамент в таблице dept не существует.
Гарантировать существование действительного департамента можно с помощью ограничения ссылочной целостности. В этом случае столбец departament_id служит первичным ключом таблицы dept, а столбец dept_id в таблице employee, ссылающийся на соответствующий столбец таблицы department, называется внешним ключом. Таблица,содержащая внешний ключ, обычно называется дочерней таблицей, а таблица, содержащая ключ, на который ссылается внешний ключ — родительской таблицей. Как и со всеми прочими типами ограничений, ссылочные ограничения целостности можно создавать во время создания таблицы или позднее, с помощью оператора ALTER TABLE:
База данных назначает столбец dept_id таблицы employee внешним ключом, потому что он ссылается на столбец dept_id таблицы dept. Обратите внимание, что для того, чтобы столбец служил ссылочным (на который ссылаются), он должен быть уникальным или же быть первичным ключом в таблице, на которую установлена ссылка.
Ограничение уникальности
Ограничение уникальности (UNIQUE) очень распространено в реляционных базах данных. Эти ограничения гарантируют уникальность строк в реляционной таблице.В таблице могут существовать сразу несколько таких ограничений. Например, ограничение уникальности на столбце employee_id гарантирует, что ни один сотрудник не появится дважды в таблице employee.
В следующем примере первый оператор специфицирует ограничение уникальности на комбинации столбцов dept_name и location:
Создать уникальное ограничение на таблице department можно также с помощью такого оператора ALTER TABLE:
Ограничения первичного ключа
Первичный ключ — очень важный тип ограничения в таблице. Когда необходимо,чтобы значения столбца идентифицировались уникальным образом, это обеспечивается созданием первичного ключа по значению столбца. Столбец, на котором определен первичный ключ, должен быть уникальным и не null.
Таблица может иметь только один первичный ключ, который можно создать при создании таблицы, как показано в следующем примере:
Кроме того, можно добавить ограничение и к существующей таблице:
Поскольку в предыдущем примере ограничению не присвоено имя, Oracle даст ему имя, сгенерированное системой. Если требуется присвоить ограничению собственное имя, воспользуйтесь следующей командой, которая назовет ограничение dept_pk:
Обратите внимание, что если первичный ключ будет построен по более чем одному столбцу (т.е. будет составным), специфицировать назначение первичного ключа напротив имени столбца при создании таблицы нельзя. Столбцы первичного ключа должны быть указаны как отдельный элемент оператора CREATE TABLE после списка всех столбцов.
На заметку! В обоих предыдущих примерах Oracle автоматически создает индексы на столбце,который назначен первичным ключом.
DBA_CONSTRAINTS
Представление DBA_CONSTRAINTS предоставляет информацию обо всех типах ограничений таблицы в базе данных. Опрос этого представления делается, когда необходимо узнать, какого типа ограничения имеет таблица. Представление перечисляет несколько типов ограничений, как показано в следующем запросе:
Следующий запрос позволит узнать, какие ограничения установлены для таблицы TESTD. Ответ на запрос показывает, что таблица имеет единственное ограничение CHECK. Префикс SYS в столбце NAME отражает тот факт, что CONSTRAINT_NAME — имя по умолчанию, а не явно указанное владельцем таблицы.
Обратите внимание, что если необходимо увидеть определенное ссылочное ограничение и правило удаления, то нужно применить следующую вариацию предыдущего запроса:
Состояние Enable No Validate
При этом состоянии ограничения база данных проверяет все новые вставки и обновления на соответствие условию ограничения. Поскольку существующие данные на такое соответствие не проверяются, нет уверенности, что они удовлетворяют этому условию ограничения. Обычно эта опция применяется при загрузке крупных таблиц,когда есть основания для уверенности, что эти таблицы уже удовлетворяют условию ограничения. Вот пример:
Более подходящая стратегия заключалась бы в использовании состояния DISABLE NOVALIDATE при загрузке данных, с переходом к состоянию ENABLE NOVALIDATE и затем к ENABLE VALIDATE в конце цикла извлечения, трансформации и загрузки (extraction,transformation, loading — ETL).
Ограничения NOT NULL
Обычно таблица имеет один или более столбцов, в которых не допускается значение null — т.е. без значений. Хорошим примером является столбец last_name таблицы employee. Заставить пользователей обязательно вносить значения в этот столбец можно при создании таблицы, указав опцию NOT NULL для столбца, который не должен быть null:
Если таблица уже создана, и требуется модифицировать столбец с допускающего null на не допускающий null, для этого можно использовать следующий оператор:
Заявляемые ограничения целостности
Все величины, заносимые в таблицу, обязаны входить в множество допускаемых типов соответствующего столбца. Ограничения целостности данных позволяют добавить для них требования, дополнительные к соблюдению типа. Заявляемые (схемные, формальные, "декларативные") ограничения целостности записываются ("провозглашаются") в виде условий, которые должны соблюдаться явно как таковые, на уровне схемы данных, и этим отличаются от правил целостности, сформулированных в виде запрограммированных проверок (см. ниже). Поэтому иначе такие ограничения можно называть "явными". Оригинальный термин имеет полное название " integrity data constraints" — "ограничения на значения данных, налагаемые для более точного учета обстоятельств предметной области ", но часто сокращается до " integrity constraints " или даже просто "constraints". Слово " integrity " вряд ли хорошо понятно массам разработчиков.
Само понятие заявляемых ограничений целостности в SQL было унаследовано от реляционной модели и усложнялось вместе с развитием стандарта. В Oracle номенклатура ограничений целостности в целом соответствует SQL -92 (при том, что объем реализации не выдержан), но не доведена до уровня SQL :1999. Так, Oracle не позволяет завести ограничение целостности на уровне БД (с помощью служебного слова ASSERTION ) и сильно ограничен в формулировании условия проверки значений конструкцией CHECK тем, что не допускает обращения к данным базы.
Слово ASSERTION из стандарта SQL подсказывает еще один перевод (и понимание) integrity constraints , как "утвердительные ограничения целостности".
Заявляемые ограничения целостности в Oracle можно задавать на уровнях:
- отдельного поля строки в таблице;
- отдельной строки;
- пары таблиц.
Проверка на выполнение действующих заявляемых ограничений целостности выполняется СУБД автоматически и всегда, вне зависимости от источника поступления изменений, чем и гарантировано их соблюдение, в отличие, скажем, от проверок вводимых значений, осуществляемых клиентскими прикладными программами.
Oracle позволяет формулировать подобные ограничения при создании таблицы командой CREATE TABLE , а для уже существующих таблиц их можно добавлять и отменять следующими командами:
- ALTER TABLE … MODIFY — добавление ограничений всех видов и снятие ограничения NOT NULL ;
- ALTER TABLE … ADD/DROP — добавление и снятие ограничений всех видов, кроме NOT NULL .
Всем ограничениям целостности, сформулированными в схеме, Oracle сообщает имена. Если при создании ограничения употребить конструкцию CONSTRAINT имя , ограничение получит имя от программиста, в противном случае СУБД создаст имя по своему усмотрению. Сведения о каждом существующем ограничении можно найти в таблице словаря-справочника USER_CONSTRAINTS по его имени. Неудачное имя ограничения можно изменить; к примеру:
Разновидности заявляемых ограничений целостности
Ограничение NOT NULL
Ограничение NOT NULL обязывает столбец или группу столбцов всегда иметь значение (если группа — то хотя бы в одном поле). Требование непустоты столбца крайне желательно, так как избавляет программиста от многочисленных забот, связанных с особенностями обработки NULL . К сожалению, требования предметной области и некоторые действия в SQL (например, GROUP BY ROLLUP … ) не позволяют совсем отказаться от столбцов со свойством NULL .
Это единственное из ограничений целостности, информация о котором хранится не только в таблице USER_CONSTRAINTS , но и в таблице USER_TAB_COLUMNS в качестве свойства столбца. (Когда-то признак NULL/NOT NULL формально считался свойством столбца, а не ограничением целостности). По этой причине добавление и упразднение этого ограничения оформляется по правилам изменения свойства столбца, только через ключевое слово MODIFY :
В современных версиях Oracle самостоятельное ограничение NOT NULL будет оформлено технически как ограничение вида CHECK с условием для проверки: budget IS NOT NULL и одновременно будет зафиксировано в USER_CONSTRAINTS значением NULLABLE = 'Y' . Свойство NOT NULL , вытекающее из правила первичного ключа, будет отражено только в USER_CONSTRAINTS .
Первичные ключи
От столбцов, назначенных первичным ключом, требуется, чтобы значения в их полях всех строк были уникальными и имелись всегда (для ключа из нескольких столбцов значение должно быть хотя бы в одном поле). Примеры создания и удаления:
Значения в полях первичного ключа должны существовать всегда.
Некоторые типы столбцов не допускаются до формирования первичного ключа (например, LOB или TIMESTAMP WITH TIME ZONE ).
Уникальность значений в столбцах
От столбцов, назначенных уникальными, требуется, чтобы значения в их полях всех строк были уникальными. Уникальность в SQL наиболее близка к понятию "альтернативного", "возможного" (candidate) или же просто "ключа" в реляционной модели.
Обратите внимание, что в столбце PNAME не запрещаются пропуски значений. По стандарту SQL уникальность отслеживается для имеющихся значений столбца. Если на такой столбец дополнительно наложить ограничение
он сможет играть роль ключа в реляционной модели и быть объявлен первичным (путем замены двух ограничений: UNIQUE и NOT NULL на одно PRIMARY KEY ). Если же уникальной объявляется группа столбцов, сообщить ей свойства ключа средствами SQL сложнее (обязательность хотя бы одного значения в уникальной группе можно потребовать ограничением вида CHECK ).
Другое отличие ограничения уникальности от первичного ключа в том, что первых в таблице может быть сформулировано несколько, а второе присутствует разве что в единственном числе. Oracle не препятствует объявлению уникальности не только непересекающихся групп столбцов, но даже и повторяющихся. Следующая цепочка команд не вызовет ошибок:
Потребовать в таблице EMP , чтобы в один и тот же отдел одновременно не принималось двух сотрудников в одной должности, можно следующим образом:
Более того, Oracle не запретит включить в состав уникальной группы столбцы первичного ключа, в том числе все из них. Последнее в реляционной теории соответствует понятию "суперключа" и невозможно для ключа.
Однако точное повторение списка имен столбцов в новом определении приведет к ошибке (что довольно необычно логически и вызвано техническими причинами реализации):
Внешние ключи
Столбцы, объявленные внешним ключом, обязаны (а) ссылаться на однотипные столбцы из другой или той же таблицы при условии, что адресат — это первичный ключ или уникальная группа столбцов, и (б) принимать только существующие в данный момент в столбцах-адресатах значения. Пример создания:
По правилам внешнего ключа в столбце LDEPT не запрещаются пропуски значений. Стандарт SQL требует от СУБД проверки соответствия значениям в столбцах-адресатах таблицы только имеющихся значений внешнего ключа; иными словами, значения в полях внешнего ключа могут отсутствовать.
Внешних ключей в таблице может быть определено несколько. Например, при более тщательном моделировании примера "сотрудники — отделы" в дополнение к имеющемуся внешнему ключу DEPTNO таблицы EMP можно было бы объявить внешним ключом столбец JOB , заставив его ссылаться на отдельную таблицу с описаниями штатных должностей.
База данных Oracle была бы не слишком полезной, если бы множество пользователей не могли обращаться к данным и модифицировать их одновременно. Под параллелизмом данных (data concurrency) понимают способность базы данных обеспечивать параллельный доступ для множества пользователей. Чтобы обеспечить согласованные результаты, база данных нуждается в механизме, который гарантирует, что пользователи не будут натыкаться на изменения, проводимые друг другом. Целостность данных (data consistency) — это возможность для пользователя получать согласованное представление данных, включая все изменения, проведенные в них другими пользователями.
Для обеспечения целостности данных Oracle использует специальные структуры, именуемые сегментами отмены (undo segments). Например, когда вы читаете набор данных для транзакции, Oracle обеспечивает, чтобы прочитанные данные были согласованы по набору транзакций, т.е. гарантирует, что данные, которые вы видите, отражают один набор зафиксированных транзакций. Oracle также обеспечивает согласованность данных по чтению, что означает, что все данные, выбранные вашими запросами,относятся к одному моменту времени. Сегменты отмены Oracle — это часть табличного пространства undo, упомянутого ранее в блогах.
Oracle использует механизм блокировок для обеспечения параллелизма данных. Позволяя одному пользователю блокировать индивидуальные строки или целые таблицы, он гарантирует ему исключительное использование таблицы в целях обновления.Важной характеристикой механизмов блокировки Oracle является то, что они по большей части происходят автоматически. Вам не нужно беспокоиться о деталях блокировки объектов, которые вы хотите модифицировать — Oracle “за кулисами” позаботится об этом.
Oracle использует две базовые модели блокировок. Модель исключительной блокировки применяется для обновлений, а модель разделяемой блокировки используется для операций SELECT на таблицах. Модель разделяемой блокировки позволяет нескольким пользователям одновременно читать одни и те же строки таблицы. Модель исключительной блокировки, поскольку включает обновления таблицы, может использоваться только одним пользователем в любой заданный момент времени. Исключительные блокировки почти всегда применяются к определенным строкам, подлежащим обновлению, позволяя одновременно использовать базу данных множеству пользователей.После выполнения команды COMMIT или ROLLBACK Oracle автоматически освобождает блокировки на таблицах и прочие важные ресурсы.
Блокировки Oracle сложны, и вы детально познакомитесь с ними в главе 8, вместе с тем, как Oracle обеспечивает согласованность и параллелизм данных.
Ограничения Rely
Обычно перед загрузкой в таблицы хранилища данных предполагается выполнение шагов ETL. Если есть уверенность в качестве данных, можно сэкономить время на загрузку, отключив проверку ограничений. Для этого применяется команда ALTER TABLE с конструкцией RELY DISABLE NOVALIDATE, как показано в следующем примере:
Системный номер изменения
Системный номер изменения, или SCN (system change number) — важный оценочный фактор, используемый базой данных Oracle для отслеживания состояния в каждый данный момент времени. Когда вы читаете (SELECT) данные в таблицах, то не затрагиваете состояния базы данных, но когда модифицируете, вставляете или удаляете строку, то состояние базы данных изменяется по отношению к тому, каким оно было до операции. Oracle использует SCN для слежения за всеми изменениями, проведенными в базе данных со временем. SCN — это логическая временная метка, используемая Oracle для упорядочивания событий, происходящих с базой данных. SCN очень важен по нескольким причинам, не последняя из которых — восстановление базы данных после сбоя.
SCN подобны возрастающим номерам последовательности, и Oracle увеличивает их в SGA. Когда транзакция модифицирует или вставляет данные, Oracle сначала пишет новый SCN в сегмент отката. Процесс-писатель журналов затем немедленно вносит запись о фиксации транзакции в журнал повторного выполнения, и эта запись получает уникальный SCN новой транзакции. Фактически запись этого SCN в журнал повторного выполнения отмечает зафиксированную транзакцию в базе данных Oracle.
SCN помогает Oracle определять необходимость восстановления после сбоя после внезапного прерывания работы экземпляра базы данных или после издания команды SHUTDOWN ABORT. Всякий раз, когда база данных выполняет операцию контрольной точки, Oracle пишет команду START SCN в заголовки файлов данных. Управляющий файл поддерживает значение SCN для каждого файла данных, называемый STOP SCN, который обычно устанавливается в бесконечность, и всякий раз, когда экземпляр останавливается нормально (командой SHUTDOWN NORMAL или SHUTDOWN IMMEDIATE), Oracle копирует номер START SCN в заголовках файлов данных в номера STOP SCN для файлов данных в управляющем файле. Когда вы перезапускаете базу данных после успешного останова, нет необходимости ни в каком восстановлении, потому что номера SCN в файлах данных и управляющих файлах соответствуют. С другой стороны, внезапное прерывание работы экземпляра не оставляет времени на приведение в соответствие номеров SCN, и Oracle обнаруживает необходимость восстановления экземпляра, потому что отличаются номера SCN в файлах данных с одной стороны, и управляющем файле — с другой. Как вы узнаете из главы 16, они играют ключевую роль в восстановлении базы данных. Oracle определяет, на сколько нужно вернуться, применяя архивные журналы повторного выполнения во время восстановления на основе SCN.
Отложенные и немедленные ограничения
В дополнение к указанию типа проверки достоверности ограничения можно специфицировать, когда именно должно проверяться ограничение в процессе загрузки данных.
Если хотите, чтобы ограничение проверялось немедленно после модификации данных, выберите опцию not defferable (не откладывая), которая, фактически задает поведение по умолчанию в базах данных Oracle. Если необходимо выполнить едино-временную проверку ограничения после фиксации всей транзакции, выберите опцию deferrable. Все ограничения и внешние ключи могут быть объявлены как deferrable или not deferrable.
В случае выбора опции deferrable появляются еще две дополнительных опции.Ограничение deferrable можно специфицировать либо как initially deferred, либо как initially immediate (изначально отложенное или изначально немедленное). В первом случае база данных откладывает проверки ограничения до окончания транзакции. Если же была выбрана опция initially immediate, то база данных проверит ограничения перед изменением любых данных. Обратите внимание, что если предварительно создается индекс, то он должен быть не уникальным, чтобы обработать дублированные значения.
Следующий пример показывает, как специфицировать такого рода ограничения в таблице employee:
В Oracle также предусмотрен способ изменения отложенного ограничения с immediate на deferred или наоборот с помощью следующих операторов:
Писатель базы данных и протокол опережающей записи
Писатель базы данных (db writter), как вы видели ранее, отвечает за запись в файлы данных всех модифицированных буферов из буферного кэша базы данных. Кроме того, он следит за наличием свободного пространства с буферном кэше, чтобы серверный процесс мог читать новые данные из файлов данных при необходимости. Протокол опережающей записи (журнала) также требует, чтобы записи повторного выполнения в буфере журнала повторного выполнения, ассоциированные с измененной информацией в буферном кэше, были записаны в буфер журнала повторного выполнения перед тем, как они отразятся в файлах данных. Важность содержимого журнала повторного выполнения диктует Oracle обязательность записи содержимого файла журнала повторного выполнения в постоянное хранилище перед тем, как изменения данных будут проведены в файлах данных на диске.
Когда пользователь фиксирует транзакцию, процесс-писатель журнала немедленно вносит в файлы журналов повторного выполнения запись о фиксации. Полный набор записей, затронутых зафиксированной транзакцией, может и не записываться одновременно в файлы данных. Механизм быстрой фиксации, наряду с журналом опережающей записи, гарантирует, что база данных не будет ждать завершения всех физических операций записи после каждой транзакции. Как вы можете себе представить, огромные базы данных OLTP с многочисленными изменениями на протяжении всего дня не могли бы функционировать оптимально, если бы им пришлось выполнять запись на диск после каждого зафиксированного изменения данных.
На заметку! При наличии огромного числа транзакций и, как следствие, огромного количества запросов на фиксацию, процесс-писатель журнала может и не вносить немедленно запись о каждой зафиксированной транзакции в журнал повторного выполнения. Он может накапливать по нескольку запросов на фиксацию, если очень занят в данный момент. Такая пакетированная запись информации о множестве зафиксированных транзакций называется групповой фиксацией.
Заявляемые ограничения целостности
Все величины, заносимые в таблицу, обязаны входить в множество допускаемых типов соответствующего столбца. Ограничения целостности данных позволяют добавить для них требования, дополнительные к соблюдению типа. Заявляемые (схемные, формальные, "декларативные") ограничения целостности записываются ("провозглашаются") в виде условий, которые должны соблюдаться явно как таковые, на уровне схемы данных, и этим отличаются от правил целостности, сформулированных в виде запрограммированных проверок (см. ниже). Поэтому иначе такие ограничения можно называть "явными". Оригинальный термин имеет полное название " integrity data constraints" — "ограничения на значения данных, налагаемые для более точного учета обстоятельств предметной области ", но часто сокращается до " integrity constraints " или даже просто "constraints". Слово " integrity " вряд ли хорошо понятно массам разработчиков.
Само понятие заявляемых ограничений целостности в SQL было унаследовано от реляционной модели и усложнялось вместе с развитием стандарта. В Oracle номенклатура ограничений целостности в целом соответствует SQL -92 (при том, что объем реализации не выдержан), но не доведена до уровня SQL :1999. Так, Oracle не позволяет завести ограничение целостности на уровне БД (с помощью служебного слова ASSERTION ) и сильно ограничен в формулировании условия проверки значений конструкцией CHECK тем, что не допускает обращения к данным базы.
Слово ASSERTION из стандарта SQL подсказывает еще один перевод (и понимание) integrity constraints , как "утвердительные ограничения целостности".
Заявляемые ограничения целостности в Oracle можно задавать на уровнях:
- отдельного поля строки в таблице;
- отдельной строки;
- пары таблиц.
Проверка на выполнение действующих заявляемых ограничений целостности выполняется СУБД автоматически и всегда, вне зависимости от источника поступления изменений, чем и гарантировано их соблюдение, в отличие, скажем, от проверок вводимых значений, осуществляемых клиентскими прикладными программами.
Oracle позволяет формулировать подобные ограничения при создании таблицы командой CREATE TABLE , а для уже существующих таблиц их можно добавлять и отменять следующими командами:
- ALTER TABLE … MODIFY — добавление ограничений всех видов и снятие ограничения NOT NULL ;
- ALTER TABLE … ADD/DROP — добавление и снятие ограничений всех видов, кроме NOT NULL .
Всем ограничениям целостности, сформулированными в схеме, Oracle сообщает имена. Если при создании ограничения употребить конструкцию CONSTRAINT имя , ограничение получит имя от программиста, в противном случае СУБД создаст имя по своему усмотрению. Сведения о каждом существующем ограничении можно найти в таблице словаря-справочника USER_CONSTRAINTS по его имени. Неудачное имя ограничения можно изменить; к примеру:
Разновидности заявляемых ограничений целостности
Ограничение NOT NULL
Ограничение NOT NULL обязывает столбец или группу столбцов всегда иметь значение (если группа — то хотя бы в одном поле). Требование непустоты столбца крайне желательно, так как избавляет программиста от многочисленных забот, связанных с особенностями обработки NULL . К сожалению, требования предметной области и некоторые действия в SQL (например, GROUP BY ROLLUP … ) не позволяют совсем отказаться от столбцов со свойством NULL .
Это единственное из ограничений целостности, информация о котором хранится не только в таблице USER_CONSTRAINTS , но и в таблице USER_TAB_COLUMNS в качестве свойства столбца. (Когда-то признак NULL/NOT NULL формально считался свойством столбца, а не ограничением целостности). По этой причине добавление и упразднение этого ограничения оформляется по правилам изменения свойства столбца, только через ключевое слово MODIFY :
В современных версиях Oracle самостоятельное ограничение NOT NULL будет оформлено технически как ограничение вида CHECK с условием для проверки: budget IS NOT NULL и одновременно будет зафиксировано в USER_CONSTRAINTS значением NULLABLE = 'Y' . Свойство NOT NULL , вытекающее из правила первичного ключа, будет отражено только в USER_CONSTRAINTS .
Первичные ключи
От столбцов, назначенных первичным ключом, требуется, чтобы значения в их полях всех строк были уникальными и имелись всегда (для ключа из нескольких столбцов значение должно быть хотя бы в одном поле). Примеры создания и удаления:
Значения в полях первичного ключа должны существовать всегда.
Некоторые типы столбцов не допускаются до формирования первичного ключа (например, LOB или TIMESTAMP WITH TIME ZONE ).
Уникальность значений в столбцах
От столбцов, назначенных уникальными, требуется, чтобы значения в их полях всех строк были уникальными. Уникальность в SQL наиболее близка к понятию "альтернативного", "возможного" (candidate) или же просто "ключа" в реляционной модели.
Обратите внимание, что в столбце PNAME не запрещаются пропуски значений. По стандарту SQL уникальность отслеживается для имеющихся значений столбца. Если на такой столбец дополнительно наложить ограничение
он сможет играть роль ключа в реляционной модели и быть объявлен первичным (путем замены двух ограничений: UNIQUE и NOT NULL на одно PRIMARY KEY ). Если же уникальной объявляется группа столбцов, сообщить ей свойства ключа средствами SQL сложнее (обязательность хотя бы одного значения в уникальной группе можно потребовать ограничением вида CHECK ).
Другое отличие ограничения уникальности от первичного ключа в том, что первых в таблице может быть сформулировано несколько, а второе присутствует разве что в единственном числе. Oracle не препятствует объявлению уникальности не только непересекающихся групп столбцов, но даже и повторяющихся. Следующая цепочка команд не вызовет ошибок:
Потребовать в таблице EMP , чтобы в один и тот же отдел одновременно не принималось двух сотрудников в одной должности, можно следующим образом:
Более того, Oracle не запретит включить в состав уникальной группы столбцы первичного ключа, в том числе все из них. Последнее в реляционной теории соответствует понятию "суперключа" и невозможно для ключа.
Однако точное повторение списка имен столбцов в новом определении приведет к ошибке (что довольно необычно логически и вызвано техническими причинами реализации):
Внешние ключи
Столбцы, объявленные внешним ключом, обязаны (а) ссылаться на однотипные столбцы из другой или той же таблицы при условии, что адресат — это первичный ключ или уникальная группа столбцов, и (б) принимать только существующие в данный момент в столбцах-адресатах значения. Пример создания:
По правилам внешнего ключа в столбце LDEPT не запрещаются пропуски значений. Стандарт SQL требует от СУБД проверки соответствия значениям в столбцах-адресатах таблицы только имеющихся значений внешнего ключа; иными словами, значения в полях внешнего ключа могут отсутствовать.
Внешних ключей в таблице может быть определено несколько. Например, при более тщательном моделировании примера "сотрудники — отделы" в дополнение к имеющемуся внешнему ключу DEPTNO таблицы EMP можно было бы объявить внешним ключом столбец JOB , заставив его ссылаться на отдельную таблицу с описаниями штатных должностей.
База данных Oracle была бы не слишком полезной, если бы множество пользователей не могли обращаться к данным и модифицировать их одновременно. Под параллелизмом данных (data concurrency) понимают способность базы данных обеспечивать параллельный доступ для множества пользователей. Чтобы обеспечить согласованные результаты, база данных нуждается в механизме, который гарантирует, что пользователи не будут натыкаться на изменения, проводимые друг другом. Целостность данных (data consistency) — это возможность для пользователя получать согласованное представление данных, включая все изменения, проведенные в них другими пользователями.
Для обеспечения целостности данных Oracle использует специальные структуры, именуемые сегментами отмены (undo segments). Например, когда вы читаете набор данных для транзакции, Oracle обеспечивает, чтобы прочитанные данные были согласованы по набору транзакций, т.е. гарантирует, что данные, которые вы видите, отражают один набор зафиксированных транзакций. Oracle также обеспечивает согласованность данных по чтению, что означает, что все данные, выбранные вашими запросами,относятся к одному моменту времени. Сегменты отмены Oracle — это часть табличного пространства undo, упомянутого ранее в блогах.
Oracle использует механизм блокировок для обеспечения параллелизма данных. Позволяя одному пользователю блокировать индивидуальные строки или целые таблицы, он гарантирует ему исключительное использование таблицы в целях обновления.Важной характеристикой механизмов блокировки Oracle является то, что они по большей части происходят автоматически. Вам не нужно беспокоиться о деталях блокировки объектов, которые вы хотите модифицировать — Oracle “за кулисами” позаботится об этом.
Oracle использует две базовые модели блокировок. Модель исключительной блокировки применяется для обновлений, а модель разделяемой блокировки используется для операций SELECT на таблицах. Модель разделяемой блокировки позволяет нескольким пользователям одновременно читать одни и те же строки таблицы. Модель исключительной блокировки, поскольку включает обновления таблицы, может использоваться только одним пользователем в любой заданный момент времени. Исключительные блокировки почти всегда применяются к определенным строкам, подлежащим обновлению, позволяя одновременно использовать базу данных множеству пользователей.После выполнения команды COMMIT или ROLLBACK Oracle автоматически освобождает блокировки на таблицах и прочие важные ресурсы.
Блокировки Oracle сложны, и вы детально познакомитесь с ними в главе 8, вместе с тем, как Oracle обеспечивает согласованность и параллелизм данных.
Состояния ограничений целостности
Как было показано в предыдущем выше, ограничения целостности определяются на таблицах для гарантии, что данные, нарушающие заранее установленные правила,в таблицу не попадут. Однако иногда, например, при загрузке данных, ограничения целостности не должны поддерживаться в действительном состоянии, поскольку это приведет к определенным проблемам. При необходимости Oracle позволяет отключать ограничения и затем включать их, когда они снова понадобятся. Давайте рассмотрим некоторые способы изменения состояния ограничений таблиц.
При загрузке больших объемов данных с использованием SQL*Loader или утилиты Import может потребоваться значительное время на загрузку данных, каждую строку которых нужно проверять на предмет нарушения целостности. Более эффективная стратегия предусматривает отключение ограничения, загрузку данных и последующую проверку корректности загруженных данных. После завершения загрузки ограничения вновь вводятся в действие посредством включения. Когда ограничение отключается,как описано здесь, база данных уничтожает индекс. Подобным образом реализуется лучшая стратегия — предварительное создание неуникальных индексов для ограничений, которые база данных не должна уничтожать, поскольку они обрабатывают дублированные записи.
На заметку! Состояние enabled (включено) — это состояние ограничений Oracle по умолчанию
Отключаются ограничения двумя способами: указание в качестве состояния ограничения либо disable validate (отключить с проверкой), либо disable no validate (отключить без проверки) с использованием конструкции DISABLE VALIDATE и DISABLE NO VALIDATE, соответственно. Аналогично, для включения ограничения применяются конструкции ENABLE VALIDATE и ENABLE NO VALIDATE. Ниже кратко обсуждаются различные способы включения и отключения ограничений.
Состояние Enable Validate
Это состояние ограничения включает ограничение, гарантируя проверку всех данных на соответствие условию ограничения. Это состояние в точности то же, что обычное состояние “включено”. Следующий пример демонстрирует использование этого состояния:
Управление отменой
Когда вы проводите изменение в базе данных, вы должны иметь возможность отменить или откатить это изменение при необходимости. Информация, необходимая для отмены или отката изменений транзакции, которая в основном состоит из информации таблицы, предшествующей изменению, называется данными отмены (векторами изменений) и хранится в записях отмены (undo records). При выдаче команды ROLLBACK Oracle использует эти записи отмены для замены измененных данных их исходными версиями. Как объясняется в главе 8, записи отмены жизненно важны для восстановления базы данных, когда незавершенные или незафиксированные транзакции должны быть отменены, чтобы оставить базу в согласованном состоянии.
Oracle настоятельно рекомендует использовать средство автоматического управления изменениями ( Automatic Undo Management — AUM), при котором сам сервер Oracle будет поддерживать и управлять сегментами отмены (отката). Все, что вам нужно сделать — это предоставить выделенное табличное пространство undo и установить параметр инициализации UNDO_MANAGEMENT в auto. Oracle создаст необходимое количество сегментов отмены, которые структурно подобны традиционным сегментам отката, и будет расширять их по мере необходимости. Нет ничего необычного в том, что будут создаваться новые сегменты отмены, а старые — деактивизироваться в зависимости от количества транзакций, проводимых в базе данных. Глава 8 содержит более подробную информацию о средстве AUM.
Поскольку Oracle самостоятельно управляет размерами индивидуальных сегментов отмены, два решения, которые вы должны принять, касаются размера табличного пространства undo и установки инициализационного параметра UNDO_RETENTION (который определяет, насколько долго Oracle будет стараться хранить для вас записи об отмене в табличном пространстве undo). Помните, что ваше табличное пространство undo должно не только вместить все долговременные транзакции, но также быть достаточно большим, чтобы позволить работать всем средствам ретроспективы (flashback), которые вы можете реализовать в вашей базе данных; средства ретроспективы Oracle позволяют отменять изменения данных на различных уровнях. Некоторые из них, такие как Flashback Query, Flashback Versions Query и Flashback Table, используют данные отмены. О них мы поговорим в главе 8.
Вы можете использовать Undo Advisor Oracle через OEM для нахождения идеального размера табличных пространств undo и идеальной длительности, чтобы специфицировать параметр UNDO_RETENTION. Посредством статистики текущего использования пространства отмены можно оценить оптимальные параметры генерации данных отмены для вашего экземпляра.
Ограничения целостности в реляционных базах данных (и Oracle Database в частности) позволяют легко и автоматически применять важные бизнес-правила к таблицам базы данных. Например, в таблице, используемой в системе управления кадрами, нельзя завести сотрудника, не назначив ему руководителя. При создании связанных таблиц можно объявить необходимые ограничения целостности, которые должны быть удовлетворены при каждом вводе или модификации данных в таблице.
Для выполнения бизнес-правил можно также задействовать логику приложения,однако ограничения целостности обычно применять проще, и обычно они хорошо выполняют свою работу, гарантируя, что вставки, обновления и удаления данных таблиц будут соответствовать определенным правилам. С другой стороны, логика приложения обладает тем преимуществом, что позволяет отклонить или подтвердить данные без обращения к содержимому таблицы. Таким образом, выбирать метод выполнения бизнес-правил — логикой приложения или ограничениями целостности — необходимо на основе потребностей конкретного приложения. В любом случае ограничения целостности настолько фундаментальны для операций в реляционных базах данных, что вы обречены на их использование в конкретной базе.
По умолчанию Oracle разрешает значения null во всех столбцах. Если эти значения недопустимы для некоторых столбцов таблицы, для них необходимо задавать ограничение NOT NULL. Обратите внимание, что налагать ограничения базы данных на таблицы можно как во время их создания, так и позднее, с помощью команды ALTER TABLE.Однако очевидно, что если в таблице уже имеются значения null или дублированные данные, то изменить таблицу, применив ограничение NOT NULL или ограничение уникальности, будет невозможно.
Для таблицы Oracle можно установить несколько типов ограничений. Упрощенно их можно разделить на пять основных типов:
Все перечисленные типы ограничений обсуждаются далее в этой статье. В дополнение будет также представлен краткий обзор состояний ограничений целостности.
Состояние Disable No Validate
При отключении ограничения без проверки ограничение отключается, и нет никаких гарантий соответствия данных требованиям ограничения, поскольку Oracle не предпринимает проверку его действительности. Это по существу то же самое, что команда DISABLE CONSTRAINT.
Представления, относящиеся к ограничениям и индексам
Состояние Disable Validate
В случае использования команды DISABLE VALIDATE выполняются следующие два действия сразу. Во-первых, конструкция VALIDATE гарантирует, что все данные в таблице удовлетворяют условию ограничения. Во-вторых, конструкция DISABLE избавляет от необходимости поддерживать ограничение. Oracle сбрасывает индекс ограничения,но сохраняет его действительным. Вот пример:
После выдачи приведенного выше оператора SQL наличие только уникальных комбинаций уникальных ключей prod_id и customer_id в таблице гарантируется, однако уникальный индекс не поддерживается.
Обратите внимание, что поскольку было решено сохранить ограничение в отключенном состоянии, никаких DML-действий в отношении таблицы выполнять нельзя. Эта опция идеально подходит для крупных таблиц хранилищ данных, которые обычно используются только для извлечения данных по запросам.
Читайте также: