Введение

Классификация ограничений целостности

Заключение

Библиографический список

Введение

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

Существуют несколько типов логической целостности данных:

• Сущностная целостность – обеспечение индивидуальности строки в определённой таблице;
• Доменная целостность – обеспечение достоверности значений в столбцах таблицы;
• Ссылочная целостность – обеспечение согласованности связи между первичным ключом и внешним ключом.

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

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

Классификация ограничений целостности

По способам реализации:

• Декларативная поддержка. Реализация ограничений производится посредством написания кода на языке DDL. Средства данной поддержки определяют ограничения на данные домена и атрибута, ключи отношений и внешние ключи;
• Процедурную поддержку. Реализация ограничений производится использованием триггеров и хранимых процедур.

Присутствие ограничений приводит к созданию и применению некорректного кода, но разница состоит в том, где этот код сохранить и каким из способов его создать.

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

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

По времени проверки:

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

По области действия:

Ограничения домена (тип данных). Ограничения действуют только на допустимые значения домена и автоматически не проверяются. Например, ограничением домена «Возраст сотрудника» может быть условие «Возраст сотрудника не менее 18 и не более 65»;

• Ограничения атрибута:
• Тип и формат поля;
• Задание диапазона значений;
• Недопустимость пустого поля;
• Задание домена;

Ограничение атрибута совпадают с ограничениями соответствующего домена. Отличие в том, что ограничения атрибута проверяются.

• Ограничения кортежа. Кортеж — это именование значений определённого типа. Ограничения действуют на допустимые значения отдельного кортежа отношения, и не являющиеся ограничением целостности атрибута, а так же ограничены атрибутом. На момент проверки кортежа должны быть проверены ограничения атрибутов, входящих в этот кортеж.;
• Ограничения отношения. Отношения – это связи в таблицах. Ограничения действуют только на допустимые значения отдельного отношения, и не являющиеся ограничением целостности кортежа. У него присутствует требования: ограничение относится к отдельному отношению; некоторая таблица должна быть не пуста. На момент проверки отношения должны быть проверены ограничения целостности кортежей этого отношения;
• Ограничения базы данных. Ограничения действуют на значения двух или более связанных между собой отношений. На момент проверки базы данных должны быть проверены ограничения целостности отношений.

Реализация ограничений средствами SQL

Стандарт SQL поддерживает декларативные ограничения, а использование триггеров и хранимых данных нет. Эти ограничения реализуются как:

• Ограничения домена;
• Ограничения, входящие в определение таблицы;
• Ограничения, хранящиеся в базе данных в виде независимых утверждений (assertion).

В стандарте SQL аналогом триггеров являются действий, исполняемых по ссылке. Действия определяют, что будет происходить при изменении значения родительского ключа, на который ссылается некоторый внешний ключ. Их можно задавать независимо для операций обновления (ON UPDATE) или для удаления (ON DELETE) записей в родительском отношении. Определяется 4 типа действий:

• CASCADE. Изменения значения родительского ключа автоматически приводят к таким же изменениям связанного с ним значения внешнего ключа. Удаление кортежа в родительском отношении приводит к удалению связанных с ним кортежей в дочернем отношении;
• SET NULL. Все внешние ключи, которые ссылаются на обновленный или удаленный родительский ключ получают значения NULL;
• SET DEFAULT. Все внешние ключи, которые ссылаются на обновленный или удаленный родительский ключ получают значения, принятые по умолчанию для этих ключей;
• NO ACTION. Значения внешнего ключа не изменяются. Если операция приводит к нарушению ссылочной целостности (появляются «висящие» ссылки), то такая операция не выполняется.

Ограничения стандарта SQL:

• Ограничение типа CHECK. Содержит предикат, который может принимать значения TRUE, FALSE и UNKNOWN (NULL). Ограничение типа CHECK может быть использовано как часть описания домена, таблицы, столбца таблицы или отдельного ограничения целостности — ASSERTION. Ограничение считается нарушенным, если предикат ограничения принимает значение FALSE.
• Ограничения таблицы и ограничения столбца. Входят как часть описания таблицы или столбца таблицы соответственно. Ограничение таблицы может относиться к нескольким столбцам таблицы. Ограничение столбца относится только к одному столбцу таблицы. Любое ограничение столбца можно описать как ограничение таблицы, но не наоборот. Ограничения таблицы или столбца могут иметь наименования, при помощи которого в дальнейшем можно отменять это ограничение или менять время его проверки.
• Ограничение PRIMARY KEY. Группа из одного или нескольких столбцов образуют потенциальный ключ таблицы. Это означает, что комбинация значений в PRIMARY KEY должна быть уникальной для каждой строки таблицы. Дублированные значения или значения, содержащие NULL, будут отвергнуты. Для одной таблицы может быть определено единственное ограничение PRIMARY KEY. В терминах стандарта SQL это называется первичным ключом таблицы.
• Ограничение UNIQUE. Группа из одного или нескольких столбцов образуют потенциальный ключ таблицы, в котором допускаются значения NULL. Это означает, что две строки, содержащие одинаковые и не равные NULL-значения, считаются нарушающими уникальность и не допускаются. Две строки, содержащие NULL-значения считаются различными и допускаются. Для одной таблицы может быть определено несколько ограничений UNIQUE.
• Ограничения FOREIGN KEY и REFERENCES. Ограничение FOREIGN KEY… REFERENCES… для таблицы и ограничение REFERENCES… для столбца определяют внешний ключ таблицы. Ограничение REFERENCES… для столбца определяет простой внешний ключ, т.е. ключ, состоящий из одной колонки. Ограничение FOREIGN KEY… REFERENCES… для таблицы может определять как простой, так и сложный внешний ключ, т.е. ключ, состоящий из нескольких колонок таблицы. Столбец или группа столбцов таблицы, на которую ссылается внешний ключ, должна иметь ограничения PRIMARY KEY или UNIQUE. Столбцы, на которые ссылается внешний ключ, должны иметь тот же тип данных, что и столбцы, входящие в состав внешнего ключа. Таблица может иметь ссылку на себя. Ограничение внешнего ключа нарушается, если значения, присутствующие во внешнем ключе, не совпадают со значениями соответствующего ключа родительской таблицы ни для одной строки из родительской таблицы. Операции, приводящие к нарушению ограничения внешнего ключа, отвергаются. Как должны совпадать значения внешнего ключа и ключа родительской таблицы, а также, какие действия необходимо выполнить при изменениях ключей в родительской таблице, описаны ниже в ссылочной спецификации.
• Ограничение NOT NULL. Ограничение NOT NULL столбца не допускает появления в столбце NULL-значений.
• Ссылочная спецификация. Ссылочная спецификация определяет характеристики внешнего ключа таблицы.
• Предложение MATCH {FULL | PARTIAL}. Предложение MATCH FULL требует полного совпадения значений внешнего и первичного ключей. Предложение MATCH PARTIAL допускает частичное совпадение значений внешнего и первичного ключей. Предложение MATCH может быть также пропущенным. Для случая MATCH PARTIAL в дочерней таблице могут появиться строки, имеющие значения внешнего ключа, неуникально совпадающие со значениями родительского ключа. Т.е. одна строка дочерней таблицы может иметь неуникальные ссылки не несколько строк родительской таблицы. Это очень сильно отличается от реляционной модели данных, и это отличие провоцируется допущением NULL-значений. Чтобы рассмотреть различные варианты совпадений внешнего и родительского ключей, рассмотрим следующий пример.
• Предложения ON UPDATE и ON DELETE. Определяют действия, исполняемые по ссылке. Действия, исполняемые по ссылке, в основном описаны выше в этой главе. Сложности в понимании того, как выполняются эти действия, возникают если установлено MATCH PARTIAL и колонки, входящие в состав внешнего ключа, допускают NULL-значения.
• Атрибуты ограничения. Определяют, в какой момент проверяются ограничения. Ограничение может быть определено как NOT DEFERRABLE (неоткладываемое) или DEFERRABLE (откладываемое). Если атрибуты ограничения не указаны, то по умолчанию принимается NOT DEFERRABLE. Если ограничение определено как NOT DEFERRABLE (неоткладываемое), то ограничение всегда проверяется сразу после выполнения каждого оператора INSERT, UPDATE или DELETE, которые могут привести к нарушению ограничения. Если ограничение определено как DEFERRABLE (откладываемое), то ограничение может иметь два режима проверки — немедленно после выполнения операции или в конце транзакции. Режим проверки может быть изменен в любой момент внутри транзакции командой SET CONSTRAINTS. При определении ограничения можно указать начальный режим проверки INITIALLY DEFERRED (начально отложенное) или INITIALLY IMMEDIATE (начально немедленно проверяемое).

Заключение

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

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

Тот факт, что данные верны, подразумевает, что они непротиворечивы (но не наоборот). Кроме того, тот факт, что данные противоречивы, означает, что данные неверны (но не наоборот). Здесь слово «правильный» означает, что база данных содержит правильные данные только в том случае, если база данных идеально отражает реальную ситуацию в реальном мире.

Объявление ограничений — это всего лишь вопрос использования соответствующих функций языка базы данных, а принудительное применение ограничений осуществляется СУБД, контролирующей операции обновления, которые могут нарушать ограничение, и аннулирование операций, которые его нарушают. . Когда ограничение объявляется впервые, система должна проверить, удовлетворяет ли ему база данных в настоящее время. Если это условие не выполняется, ограничение должно быть отклонено. В противном случае он будет принят (то есть записан в системный каталог).

Библиографический список

1. Целостность данных // Wikipedia. – 2022. URL: https://en.wikipedia.org/wiki/Data_integrity (дата обращения 17.01.2023);
2. Upload. Понятие ограничения целостности базы данных. Классификация ограничений целостности. Реализация ограничений целостности средствами sql. // Белорусский государственный университет информатики и радиоэлектроники. – 2018. URL: https://studfile.net/preview/7003805/page:31/ (дата обращения 17.01.2023);
3. Обеспечение целостности данных. // Програмысли. URL: https://www.flenov.info/books/read/transact-sql/14 (дата обращения 18.01.2023);
4. Ограничение целостности в SQL //База знаний системного администратора. – 2021. URL: https://sysadminium.ru/constraining_integrity_in_sql/ (дата обращения 18.01.2023);
5. Ограничения уникальности и проверочные ограничения // Microsoft. – 2022. URL: https://learn.microsoft.com/RU-RU/sql/relational-databases/tables/unique-constraints-and-check-constraints?view=sql-server-ver15&viewFallbackFrom=azure-sqldw-latest (дата обращения 18.01.2023).