Главное меню

EN | RU | UK

На главную

7. Корпоративные ограничения целостности

Помощь & Консультация
Помощь & Консультация
Пишите мне в
Наверх страницы
Лекция
Цель

Цель раздела - общее ознакомление с корпоративными ограничениями целостности и основными «механизмами» их реализации.

7.1. Классификация корпоративных ограничений целостности

Обеспечение целостности реляционных данных (п. 4.6.2) за счет использования первичных и внешних ключей дополняется корпоративными ограничениями целостности [2, 4, 6].

Корпоративные ограничения целостности - это правила, согласно которым определяют как клиент может манипулировать данными на сервере.

Под правилами манипулирования данными рассматриваются действия, которые обусловлены особенностями процессов учета и бизнес-процессов внутри организации: добавление, удаление строк из таблиц, а также обновление информации в самых строках. Они отражают, во-первых, специфику взаимодействия организации со своими внешними клиентами и структурами, для которых она выступает как клиент, а во-вторых, взаимодействие субъектов внутри организации. В большинстве случаев внешние взаимодействия регулируются законодательством разного уровня и договорами. Все эти особенности процессов учета и бизнес-процессов невозможно удержать в пределах реляционной модели.

Корпоративные ограничения целостности определяются на этапе логического проектирования, а реализуются во время физического проектирования БД. Их можно условно разделить на следующие группы:

  1. Поддержка уникальности значений потенциальных ключей, которые не используются для связи между отношениями внутри БД.
  2. Поддержка области допустимых значений в атрибутах отношений.
  3. Поддержка ограничений количества кортежей в отношениях, вызванное действующим законодательством и (или) особенностями процессов учета внутри организации.
  4. Поддержка каскадного обновления и извлечения информации в отношениях БД.

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

ReaderCardNumber (№ билета читателя),

PasportCode (код паспорта) в отношении Readers (читатели);

ClockNumber (табельный номер),

PasportCode (код паспорта) в Librarians (библиотекари);

Name, IssueYear (название, год издания) в Books (книги);

Series, Number (серия, номер) в PasportData (паспортные данные);

ReaderCode, PhoneNumber (код читателя, телефонный номер) в Phones (телефоны);

InventoryNumber (инвентарный номер) в BookInventoryNumbers (инвентарные номера книг);

Name (название книжного фонда) в BookFunds (книжные фонды);

Name (название типа телефона) в PhoneTypes (типы телефонов);

Code (номер операции) в BookGiveOutRecord (учет видачи книг).

Code (номер операции) в BookGiveOutRecord (учет видачи книг).

BookCode, AuthorCode (код книги и автора) в Сoаuthorship (соавтори).

Необходимо определить область допустимых значений, прежде всего, для атрибутов отношений, входящих в состав потенциальных ключей и не участвуют в связях между отношениями в БД. Например, анализ приведенных выше атрибутов, входящих в состав потенциальных ключей и не участвуют в связях между отношениями, показывает, что в них не должно быть определителя NULL. Есть ряд явных дополнительных ограничений. В атрибутах типа INTEGER - ReaderCardNumber (№ билета читателя), ClockNumber (табельный номер) Number (номер паспорта ), InventoryNumber (инвентарный номер) - значение должны быть больше 0. В атрибутах типа CHAR - Name (название книги), Series (серия паспорта), PhoneNumber (номер телефона читателя), Name (название книжного фонда), Name (название типа телефона) не должно пустых строк или строк, состоящих из одних пробелов.

Для других неключевых атрибутов отношений определения области допустимых значений также может быть актуальным. Эта область зависит от требований пользователей, определяемых на этапе логического проектирования БД. Например, если необходимо указать основное место работы читателей и их должность, то в атрибутах Job (место основной работы) и Post (должность) не должно быть определителя NULL, пустых строк или строк, состоящих из одних пробелов.

Примером ограничения числа кортежей в отношении BookGiveOutRecord (учет выдачи книг) БД «Библиотека» может служить ограничение количества книг, выдаемых одному читателю. Другим явным ограничением может быть запрет на выдачу одновременно нескольких экземпляров одной и той же книги. Например, если есть правило, что один читатель может взять не более пяти книг, то в отношении BookGiveOutRecord может быть только 5 кортежей с одинаковыми значениями в атрибуте ReaderCode (код читателя), где атрибут FactReturnDate (фактическая дата возврата) содержит определитель NULL. Дополнительно необходимо проверить в отношении BookGiveOutRecord (учет выдачи книг), чтобы значения атрибутов BookGiveOutRecord.InventoryCode (инвентарный номер книги) для указанных кортежей соответствовали различным значением BookGiveOutRecord.BookCode (код книги).

В СУБД архитектуры клиент-сервер механизмы поддержки корпоративных ограничений целостности можно разместить как на стороне клиента, так и на стороне сервера (см. п. 1.3.3). Мы рассмотрим только механизмы, реализованные на стороне сервера: SQL-операторы, хранимые процедуры и триггеры. Для каждого конкретного случая необходимо выбирать самое простое решение, позволяющее выполнить поставленную задачу по поддержке корпоративных правил ограничения целостности.

7.2. Использование SQL-операторов для поддержки корпоративных ограничений целостности

Операторы CREATE DOMAIN, CREATE INDEX и CREATE TABLE могут использоваться для поддержки корпоративных ограничений целостности. Они позволяют обеспечивать уникальность значений потенциальных ключей, которые не используются для связи между отношениями внутри БД, и определять область допустимых значений атрибутов отношений.

Формат оператора

CREATE DOMAIN Имя [AS] <Тип данных>

    [DEFAULT {Константа | NULL | USER}]

    [NOT NULL] [CHECK (<Область определения>)]

    [COLLATE Набор символов для сортировки]

позволяет в предложении CHECK указать область определения значений потенциального ключа и исключить из нее определитель NULL, указав NOT NULL при создании домена. Для описания области определения значений потенциального ключа используются такие же предикаты и правила построения логических выражений, как и в условиях поиска для выборки данных в предложении WHERE оператора SELECT:

<Область определения> =

 VALUE <оператор> <значение>

VALUE [NOTBETWEEN <значение> AND <значение>

VALUE [NOTLIKE <значение> [ESCAPE <значение>]

VALUE [NOTIN (<значение> [, <значение> ...])

VALUE IS [NOTNULL

VALUE [NOTCONTAINING <значение>

VALUE [NOTSTARTING [WITH] <значение>

| (<Область определения>)

NOT <Область определения>

| <Область определения> OR <Область определения>

| <Область определения> AND <Область определения>

<оператор> = {= | < | > | <= | >= | !< | !> | >< | !=}.

Формат оператора CREATE INDEX позволяет избегать дублирования значений в ключевых атрибутах, указав фразу UNIQUE:

CREATE [UNIQUE] [ASС[ENDING] | DESC[ENDING]]

    INDEX Имя ON Имя таблицы (атрибут [, атрибут...]).

Оператор CREATE TABLE позволяет поддерживать все возможности корпоративных ограничений целостности, которые заложены в операторах CREATE DOMAIN и CREATE INDEX:

CREATE TABLE Имя [EXTERNAL [FILE]'Шлях та имя файлу']

    (<Описание атрибута>[, <Описание атрибута> | <Ограничения целостности> …]).

Описание атрибута позволяет определить столбец на базе ранее созданного домена, установить область определения значений потенциального ключа и исключить определитель NULL из нее, отметив NOT NULL:

<Описание атрибута> Имя

{Тип данных | COMPUTED [BY] (<Виражение>) | Домен}

[DEFAULT {Константа | NULL | USER}]

[NOT NULL] [<Ограничения целостности>]

[COLLATE Набор символов для сортировки].

Предложение COMPUTED [BY] (<Выражение>) позволяет вычислять значение атрибута. <Выражение> должено возвращать скалярное значение. Например, оператор

CREATE TABLE SomeTable

    (Cost FLOAT NOT NULL,

    Number INTEGER NOT NULL,

    TotalCost COMPUTED BY (Cost * Number))

создает три столбца: Cost (стоимость), Number (количество), TotalCost (общая стоимость). В последнем столбце величина рассчитывается как произведение двух предыдущих значений.

На уровне описания атрибута ограничения целостности выглядят так:

<Ограничения целостности> = [CONSTRAINT Имя] <Описание ограничений целостности>, где

<Описание ограничений целостности> = UNIQUE | PRIMERY KEY

CHECK (<Область определения>)

REFERENCES Имя другой таблицы [( Имя другого атрибута[, Имя другого атрибута …]]

[ON DELETE {NO ACTION | CASCADE | SET DEFAULT | SET NULL}]

[ON UPDATE {NO ACTION | CASCADE | SET DEFAULT | SET NULL}].

Bы можете в <Описании ограничения целостности> указать, что значение в столбце должны быть уникальными (предложение UNIQUE или PRIMERY KEY), установить область определения значений столбца (предложение CHECK); организовать каскадное обновление, удаление значений и кортежей отношения, указав связь со значениями атрибутов другой таблицы (предложение REFERENCES …).

Описание области определения значений атрибута отношения отличается от описания области значений домена тем, что в нем можно использовать оператор SELECT:

<Область определения> =

VALUE <оператор> {<значення> | <SELECT: скаляр>}

VALUE [NOTBETWEEN <значение> AND <значение>

VALUE [NOTLIKE <значение> [ESCAPE <значение>]

VALUE [NOTIN (<значение> [, <значение> …] | (<SELECT: список>)

VALUE IS [NOTNULL

VALUE {>= | <=} | [NOT] {= | < | >}

{ALL | SOME | ANY} (<SELECT: список>)

EXISTS (<SELECT: виражение>)

SINGULAR (<SELECT: виражение>)

VALUE [NOTCONTAINING <значение>

VALUE [NOTSTARTING [WITH] <значение>

| (<Область определения>)

NOT <Область определения>

| <Область определения> OR <Область определения>

| <Область определения> AND <Область определения>

<оператор> = {= | < | > | <= | >= | !< | !> | >< | !=}.

7.3. Хранимые процедуры

7.3.1. Определение и классификация хранимых процедур

Хранимая процедура - это модуль, написанный процедурным языком СУБД и хранится в БД как метаданные (т.е. как данные о данных).

Хранимую процедуру можно вызвать из приложения клиента. Существует две разновидности хранимых процедур: процедура выбора и процедура действия [2, 4, 6].

Процедура выбора может возвращать несколько значений. В приложении ее имя может подставляться в оператор SELECT вместо имени таблицы.

Процедура действия вообще может не возвращать данных и применяется для выполнения каких-либо действий.

Хранимым процедурам можно передавать параметры. С их помощью можно возвращать значения параметров, измененных в соответствии с заложенными алгоритмами.

Преимущества хранимых процедур следующие:

  1. одна процедура, расположенная на сервере, может совместно использоваться многими приложениями клиента;
  2. упрощения приложений клиентов за счет переноса части кода на сервер
  3. любое изменение хранимой процедуры на сервере немедленно становится доступной для приложений клиентов;
  4. уменьшение сетевого трафика.

7.3.2. Создание хранимой процедуры

Создание хранимой процедуры выполняется оператором

CREATE PROCEDURE Имя

[(<входной параметр> <тип данных>[, <входной параметр> <тип данных> …])]

[RETURNS

(<выходной параметр> <тип данных>[, <выходной параметр> <тип данных> …])]

AS

<Тело процедуры>

Входные параметры служат для передачи в процедуру значений из приложения клиента [10, 14, 15]. Менять входные параметры в теле процедуры не имеет смысла: эти изменения сразу будут забыты после окончания работы процедуры. Выходные параметры служат для возврата результирующих значений. Они устанавливаются в теле процедуры, и после окончания ее работы передаются приложению клиента. И входные, и выходные параметры могут отсутствовать, если в них нет необходимости.

Формат тела процедуры такой:

[<объявления локальных переменных>]

BEGIN

    <оператор>;

    [<оператор>; …]

END

7.3.3. Алгоритмический язык триггеров и хранимых процедур

7.3.3.1. Локальные переменные

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

Объявления локальных переменных имеет следующий формат:

DECLARE VARIABLE <имя> <тип>;

Здесь могут использоваться только стандартные типы СУБД Interbase.

7.3.3.2. Оператор присваивания

Оператор присваивания служит для присваивания значений переменным. Его формат

Имя переменной = выражение

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

XBuyer = 'Покупатель не определён';

Здесь переменной с именем XBuyer присваивается срочная константа.

7.3.3.3. Операторные скобки BEGIN … END

Операторные скобки BEGIN … END, во-первых, ограничивают тело процедуры, и, во-вторых, могут использоваться для указания границ составного оператора. Под простым оператором понимается единичное разрешенное действие (см. пример выше). Под составным оператором понимается группа простых или составных операторов, взятая в операторные скобки BEGIN … END.

7.3.3.4. Оператор IF … THEN … ELSE

Оператор IF … THEN … ELSE в общем виде записывается так:

IF (<условие>) THEN <оператор> [ELSE <оператор>]

Если условие истинно, то выполняется оператор, указанный после предложения THEN, если нет, то оператор, написанный после предложения ELSE.

7.3.3.5. Оператор SELECT

Оператор SELECT используется в хранимых процедурах для передачи переменной одной строки. К нему добавлено предложение:

INTO переменная[, переменная …]

Она служит для указания переменных или выходных параметров, в которые должны быть записаны значения, возвращаемые оператором SELECT (результирующие значения, перечисленные после предложения SELECT).

7.3.3.6. Оператор SUSPEND

Оператор SUSPEND прекращает выполнение хранимой процедуры, и в приложение, из которого ее вызвали, возвращаются значения параметров, перечисленных после предложения RETURNS. Например, хранимая процедура FindAutorName возвращает в параметр InAutorName имя автора, соответствующее его коду - InAuthorCode:

CREATE PROCEDURE FindAuthorName

    (InAuthorCode INTEGER)

RETURNS (InAuthorName CHAR(30)) AS

BEGIN

    SELECT Name

        FROM BookAuthors

        WHERE Code = :InAuthorCode

        INTO :InAuthorName;

    SUSPEND;

END

7.3.3.7. Оператор FOR SELECT … DO

Оператор FOR SELECTDO имеет следующий формат:

FOR

    <оператор SELECT>

DO

    <оператор>

После предложения FOR оператор SELECT возвращает набор кортежей. Затем для каждого кортежа выполняется оператор или последовательность операторов, следующей за предложением DO. Другими словами, это цикл по строкам таблицы, сформированной оператором SELECT.

7.3.3.8. Оператор WHILE … DO

Для реализации оператора WHILEDO используется конструкция вида

WHILE(<условие>)

DO <оператор>

Он организует циклическое выполнение оператора или последовательности операторов после предложения DO, пока условие после WHILE не будет истинным.

7.3.3.9. Оператор EXIT

Оператор EXIT прекращает процедуру и возвращает управление прикладной программе, которая ее вызвала.

7.3.3.10. Оператор EXECUTE PROCEDURE

Оператор EXECUTE PROCEDURE имеет следующий вид:

EXECUTE PROCEDURE Имя [параметр[, параметр …]];

[RETURNING_VALUES параметр[, параметр …]];

С его помощью в любом месте тела процедуры можно задействовать другую хранимую процедуру, которая имеется в БД. После оператора EXECUTE PROCEDURE обязательно указывается ее имя. Далее, в случае необходимости, приводятся параметры, которые передаются процедуре. Предложение RETURNING_VALUES позволяет получить результаты выполнения вызываемой процедуры и записать их в переменные.

7.3.3.11. Оператор POST_EVENT

Оператор POST_EVENT направляет из хранимых процедурах в приложения-клиенты сообщение о возникновении какой-либо ситуации, связанной с именем события. Он имеет формат

POST_EVENT "  Имя события"

7.3.3.12. Оператор CREATE EXCEPTION

Оператор CREATE EXCEPTION определяет исключительную ситуацию с заданным именем и сообщением:

CREATE EXCEPTION Имя ' сообщение'

Для генерации исключительной ситуации внутри хранимых процедур используется следующий синтаксис:

EXCEPTION Имя

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

7.3.4. Поддержка корпоративных ограничений целостности данных

Поддержка корпоративных ограничений целостности данных с помощью хранимых процедур является наиболее мощным инструментом. Его следует применять в том случае, когда с помощью SQL-операторов на этапе создания структуры БД у Вас нет возможности учесть все корпоративные и законодательные правила, влияющие на особенности ведения учета внутри организации. Хранимые процедуры применяют и при необходимости генерации сообщений для пользователя, описывающие исключительную ситуацию.

Приведем текст хранимых процедуры, изменяет код автора книги в отношении СoАuthorship. Процедура применяется для проверки наличия кода автора книги в БД. Она содержит все необходимые проверки допустимости этой операции для БД «БИБЛИОТЕКА». Если операция недопустима, то после генерации соответствующей исключительной ситуации выполнение процедуры прекращается. Если окажется, что для сохранения целостности данных при изменении кода автора необходимо выполнить еще какие-то действия или проверки, то все они должны выполняться в рамках данной хранимой процедуры. В результате любая прикладная программа клиента, которая её использует, будет придерживаться одинаковых ограничений целостности данных.

CREATE EXCEPTION AuthorNotFound "  Автор не найден."  ;

CREATE PROCEDURE FindAuthor

    (AuthorCode INTEGER, BookCode INTEGER)

AS

DECLARE VARIABLE FindAuthorCode INTEGER;

/* Определяем переменную для розмещения результата поиска кода автора в таблице BookAuthors. /*

BEGIN

    SELECT ba.Code

        FROM BookAuthors ba

        WHERE ba.Code = AuthorCode

        INTO :FindAuthorCode;

/* В переменную помещаем результат поиска кода автора в таблице BookAuthors. /*

    IF (FindAuthorCode IS NULLTHEN

/* В таблице BookAuthors заданного кода автора книги не обнаружено. /*

        EXCEPTION AuthorNotFound;

    ELSE

/* В таблице BookAuthors обнаружен заданный код автора книги. /*

        UPDATE СoАuthorship

            SET AuthorCode = FindAuthorCode

            WHERE BookCode = :BookCode

END

7.4. Тригеры

Триггер - это процедура, которая автоматически вызывается SQL-сервером при обновлении, удалении или добавлении данных в отношение [10, 14, 15].

Непосредственно из других программ к триггерам обратиться невозможно. Невозможно также передавать им входные параметры и получать от них выходные. Триггеры всегда реализуют действие и обрабатывают следующие события: добавление новой записи, изменение значений атрибутов в существующей записи или удаление записи. Относительно события триггеры делятся на те, которые выполняются до него или после него. Оператор CREATE TRIGGER имеет следующий формат:

CREATE TRIGGER Имя

    FOR Имя таблицы [ACTIVE | INACTIVE]

    {BEFORE | AFTER} {DELETE | INSERT | UPDATE}

    [POSITION номер]

AS

    <тело триггера>.

После предложения CREATE TRIGGER необходимо указать уникальное имя триггера. Затем в предложении FOR определить имя таблицы, для которой создается триггер. По умолчанию триггер активен (ACTIVE), но, если указать INACTIVE, то неактивен, то есть не будет обрабатывать событие. Предложения BEFORE и AFTER указывают, когда будет выполняться триггер - до или после события удаления (DELETE), добавления (INSERT) записи или изменения значений атрибутов в ней (UPDATE). Предложение POSITION позволяет для каждого события задействовать несколько триггеров. Последовательность их выполнения соответствует номеру.

Структура тела триггера:

[<объявления локальных переменных>]

BEGIN

    <оператор>

END

Для определения тела триггера используется процедурный язык, рассмотренный в разделе, который посвящен хранимым процедурам. К нему добавляется возможность доступа к старому (OLD) и новому (NEW) значениям, изменяемым в таблице. Еще раз подчеркнем, что эта возможность недоступна в хранимых процедурах. Запись OLD.Имя_столбца позволяет обратиться к значению, которое имело место до внесения изменений в ячейку таблицы, а значение NEW.Имя_столбца - после внесения изменений. В том случае, если значение не изменилось, OLD.Имя_столбца равно NEW.Имя_столбца.

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

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

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

Например, для БД «БИБЛИОТЕКА» на этапе создания отношений был определен внешний ключ, непозволяющий вводить в атрибут СoAuthorship.AuthorCode (код автора книги) такое значение, которое отсутствует в атрибуте BookAuthors.Code отношения, содержащее справочник авторов книг:

CREATE TABLE BookAuthors

    (Code INTEGER NOT NULL,

    FamilyName CHAR(30) NOT NULL,

    Name CHAR(30) NOT NULL,

    Patronymic CHAR(30) NOT NULL,

    Birthday DATE NOT NULL,

    Deatheday DATE,

    IssuePlace CHAR(100),

    PRIMARY KEY (Code));

CREATE TABLE CoAuthorship

    (BookCode INTEGER NOT NULL,

    AuthorCode INTEGER NOT NULL,

    FOREIGN KEY (AuthorCode) REFERENCES BookAuthors

        ON DELETE CASCADE

        ON UPDATE CASCADE,

    FOREIGN KEY (BookCode) REFERENCES Books

        ON DELETE CASCADE

        ON UPDATE CASCADE);

Для автоматического выполнения каскадного удаления записи и изменения кода автора с помощью триггеров необходимо, во-первых, исключить определение внешнего ключа из отношения СoАuthorship, а, во-вторых, определить триггеры, которые будут выполнять каскадное изменение информации.

Триггер, котрый обеспечивает каскадное обновление, имеет следующий вид:

CREATE TRIGER UpAuthorCodeBooks FOR BookAuthors

    ACTIVE

    BEFORE UPDATE AS

    BEGIN

        IF (OLD.Code >< NEW.Code) THEN

            UPDATE Сoаuthorship

                SET AuthorCode = NEW.Code

                WHERE AuthorCode = OLD.Code

    END

Триггер, реализующий каскадное удаление:

CREATE TRIGER DelAuthorCodeBooks FOR BookAuthors

    ACTIVE

    AFTER DELETE AS

    BEGIN

        DELETE FROM Сoаuthorship

            WHERE AuthorCode = OLD.Code

    END

С помощью триггеров можно вести журнал наблюдений за изменением информации в БД. Журнал изменений представляет собой таблицу, в которой фиксируются действия над всей БД или отдельными ее таблицами. В системах, где много пользователей, такой журнал позволяет определить источник недостоверных или искаженных данных.

7.5. КОНТРОЛЬНЫЕ ВОПРОСЫ

  1. Какие составляющие, обеспечивающие целостность реляционных данных, вам известны?
  2. С помощью каких действий управляют корпоративными ограничениями целостности?
  3. На какие группы можно разделить корпоративные ограничения целостности?
  4. Как выбрать «механизм» реализации корпоративных ограничений целостности?
  5. Какие SQL-операторы реализуют корпоративные ограничения целостности?
  6. Какие виды корпоративных ограничений целостности возможно реализовать с помощью SQL-операторов?
  7. Что общего и различного есть между различными видами хранимых процедур?
  8. Какие преимущества имеет использование хранимых процедур для реализации корпоративных ограничений целостности?
  9. Какие возможности алгоритмического языка хранимых процедур Вам известны?
  10. Когда оправдано использование хранимых процедур для реализации корпоративных ограничений целостности?
  11. Что общего и отличного между хранимыми процедурами и триггерами?
  12. Какие события возможно обработать с помощью триггеров?
  13. Какие дополнительные возможности имеет процедурный язык триггеров?
  14. Какие особенности использования триггеров для обеспечения каскадных обновлений и изменений данных Вам известны?
Вывод

Корпоративные ограничения, определяемые пользователем и обеспечивающие дополнительные правила поддержания целостности, дополняют ограничения, налагаемые целостностью сущностей и ссылочной целостностью реляционной модели данных. Механизмы обеспечения всех видов целостности одинаковы: SQL-операторы, триггеры и хранимые процедуры. Выбор механизма реализации целостности зависит от конкретной ситуации, но при наличии нескольких путей его реализации следует выбирать самый простой.

© Куваев Я.Г., 2005—2023.

Все права защищены.

Вся информация, размещенная на данном веб-сайте, предназначена только для персонального использования и не подлежит дальнейшему воспроизведению и/или распространению в какой-либо форме, иначе как с письменного разрешения Автора.