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

Выполнение операторов модификации данных в таблицах базы данных INSERT , DELETE и UPDATE может привести к нарушению целостности данных и их корректности, т.е. к потере их достоверности и непротиворечивости.

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

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

• обязательные данные;
• ограничения для доменов полей;
• корпоративные ограничения;
• целостность сущностей;
• ссылочная целостность .

Обязательные данные

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

Ограничения для доменов полей

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

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

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

Целостность сущностей

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

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

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

Ссылочная целостность

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

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

Существует три разновидности связи между таблицами базы данных:

• "один-ко-многим";
• "один-к-одному";
• "многие-ко-многим".

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

Связь "один-ко-многим" наиболее распространена для реляционных баз данных. Она позволяет моделировать также иерархические структуры данных.

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

Отношение "многие-ко-многим" имеет место в следующих случаях:

• одной записи в родительской таблице дочерней таблице ;
• одной записи в дочерней таблице соответствует более одной записи в родительской таблице .

Считается, что всякая связь "многие-ко-многим" может быть заменена на связь "один-ко-многим" (одну или несколько).

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

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

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

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

1. Вставка новой строки в дочернюю таблицу . Для обеспечения ссылочной целостности необходимо убедиться, что значение внешнего ключа новой строки дочерней таблицы первичного ключа одной из строк родительской таблицы .
2. Удаление строки из дочерней таблицы . Никаких нарушений ссылочной целостности не происходит.
3. Обновление внешнего ключа в строке дочерней таблицы . Этот случай подобен описанной выше первой ситуации. Для сохранения ссылочной целостности необходимо убедиться, что значение внешнего ключа в обновленной строке дочерней таблицы равно пустому значению либо некоторому конкретному значению, присутствующему в поле первичного ключа одной из строк родительской таблицы .
4. Вставка строки в родительскую таблицу . Такая вставка не может вызвать нарушения ссылочной целостности . Добавленная строка просто становится родительским объектом, не имеющим дочерних объектов.
5. Удаление строки из родительской таблицы . Ссылочная целостность окажется нарушенной, если в дочерней таблице будут существовать строки, ссылающиеся на удаленную строку родительской таблицы . В этом случае может использоваться одна из следующих стратегий:
   • NO ACTION . Удаление строки из родительской таблицы запрещается, если в дочерней таблице существует хотя бы одна ссылающаяся на нее строка.
   • CASCADE . При удалении строки из родительской таблицы автоматически удаляются все ссылающиеся на нее строки дочерней таблицы . Если любая из удаляемых строк дочерней таблицы выступает в качестве родительской стороны в какой-либо другой связи, то операция удаления применяется ко всем строкам дочерней таблицы этой связи и т.д. Другими словами, удаление строки родительской таблицы автоматически распространяется на любые дочерние таблицы .
   • SET NULL . При удалении строки из родительской таблицы во всех ссылающихся на нее строках дочернего отношения в поле внешнего ключа , соответствующего первичному ключу удаленной строки, записывается пустое значение. Следовательно, удаление строк из родительской таблицы вызовет занесение пустого значения в соответствующее поле дочерней таблицы . Эта стратегия может использоваться, только когда в поле внешнего ключа дочерней таблицы разрешается помещать пустые значения.
   • SET DEFAULT . При удалении строки из родительской таблицы в поле внешнего ключа всех ссылающихся на нее строк дочерней таблицы автоматически помещается значение, указанное для этого поля как значение по умолчанию. Таким образом, удаление строки из родительской таблицы вызывает помещение принимаемого по умолчанию значения в поле внешнего ключа всех строк

Обеспечение целостности данных и хранимые процедуры

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

В таблицах SQL Server может быть определен ряд свойств различного типа, обеспечивающих целостность данных. К ним относятся типы данных, определения NOT NULL и DEFAULT , свойства IDENTITY , ограничения, правила, триггеры и индексы.

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

Обеспечение целостности данных гарантирует их качество. Предположим, что мы создали в базе данных таблицу Persons . Значение столбца PersonId должно уникально идентифицировать каждую персону, сведения о которой занесены в таблицу. Таким образом, если значение PersonId некоей персоны равно 834, то ни для какой другой персоны это значение не может быть таким же. Далее предположим, что имеется столбец PersonRating , в котором определяется рейтинг персон - в диапазоне от 1 до 10. В этом случае столбец PersonRating не должен допускать ввода ни числа 11, ни каких-либо иных значений, кроме чисел из интервала от 1 до 10. В обоих случаях для обеспечения целостности данных следует применять один из методов, поддерживаемых SQL Server.

Среди методов SQL Server, предназначенных для обеспечения целостности данных, - определения NOT NULL и DEFAULT , свойства IDENTITY , ограничения, правила, триггеры и индексы. Некоторые из них уже упоминались, здесь же приводится их краткое описание. Некоторые свойства таблицы, например определения NOT NULL и DEFAULT , иногда считают ограничениями особого типа. Однако в соответствии с задачами нашего курса, они рассматриваются отдельно от ограничений.

Тип данных - это атрибут, который определяет тип (символьный, целочисленный, двоичный и т. д.) данных, которые могут храниться в поле, параметре или переменной. SQL Server поддерживает несколько системных типов данных, на основе которых можно создавать пользовательские типы данных. Системные типы данных определяют все типы данных, которые можно применять в SQL Server. Типы обеспечивают целостность данных, поскольку вводимые данные должны соответствовать типу, заданному для объекта.

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

Задавая возможность ввода в поле пустых значений, мы определяем, могут ли в этом столбце таблицы храниться пустые значения. Пустое значение отличается от нуля, пробела или символьной строки нулевой длины, например «». Пустое значение означает, что информация не введена, то есть значение не известно или не определено. Возможность ввода в столбец пустых значений задается при определении этого столбца во время создания таблицы или ее модификации. Из-за сложностей, связанных с обработкой пустых значений в SQL Server, в определении столбцов как допускающих, так и не допускающих ввода пустых значений всегда следует использовать ключевые слова NULL или NOT NULL . Если столбец допускает пустые значения, используется ключевое слово NULL , если нет - NOT NULL .

Значения по умолчанию задают значения, которые будет использованы, если при добавлении строки значение поля не задано. Определения DEFAULT создают при определении таблицы (как часть этого определения) или добавляют к уже существующей таблице. В любом столбце разрешено только одно определение DEFAULT.

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

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

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

Сначала следует создать правило с помощью оператора CREATE RULE . После этого при помощи системной хранимой процедуры sp_bindrule его привязывают к столбцу или пользовательскому типу данных. Подробнее об использовании CREATE RULE или sp_bindrule - в справочнике по Transact-SQL в SQL Server Books Online.

Триггеры - это особый класс хранимых процедур, автоматически запускаемых при выполнении операторов UPDATE , INSERT или DELETE для таблицы или представления. Триггеры представляют собой мощный инструмент, применяемый для автоматической реализации бизнес-логики при модификации данных. Триггеры способны расширить логику проверки целостности, реализуемую ограничениями, умолчаниями и правилами SQL Server (хотя во всех случаях, когда ограничения способны обеспечить необходимую функциональность, следует использовать их вместо триггеров).

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

Типы целостности данных

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

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

Сущностная целостность

Этот тип целостности определяет строку таблицы как уникальный экземпляр некоторой сущности. Сущностная целостность обеспечивает целостность столбца с идентификатором или первичного ключа таблицы (посредством индексов, ограничений UNIQUE , PRIMARY KEY или свойств IDENTITY ).

Доменная целостность

Этот тип целостности гарантирует наличие в некотором столбце только допустимых значений. Можно обеспечивать доменную целостность, ограничивая тип (посредством типов данных), формат (с помощью ограничений CHECK и правил) или диапазон допустимых значений (с помощью ограничений FOREIGN KEY и CHECK, определений DEFAULT, определений NOT NULL и правил).

Ссылочная целостность

Этот тип целостности обеспечивает сохранность связей между таблицами при добавлении или удалении записей. В SQL Server ссылочная целостность основана на связях между внешними и первичными ключами или между внешними и уникальными ключами (через ограничения FOREIGN KEY и CHECK ). Ссылочная целостность гарантирует согласованность значений ключа в связанных таблицах. Подобная согласованность требует отсутствия ссылок на несуществующие значения и согласованного изменения ссылок на ключ во всей базе данных при изменении самого ключа.

При обеспечении ссылочной целостности SQL Server предотвращает следующие действия пользователей:

Добавление записей в связанную таблицу, если нет необходимой записи в главной таблице;

Изменение значений в главной таблице, в результате которого в связанной таблице останутся «зависшие» записи;

Удаление записей из главной таблицы при наличии связанных записей во внешней таблице.

Конструкция FROM

Конструкцию FROM необходимо помещать в каждом операторе SELECT , который извлекает данные из таблиц или представлений. Эта конструкция позволяет задать список таблиц и представлений, на столбцы которых ссылаются список выбора и конструкция WHERE . Этим таблицам и представлениям могут быть присвоены псевдонимы в конструкции AS . Конструкция FROM , кроме того, позволяет соединять таблицы, задавая условия соединения в конструкции JOIN .

Конструкция FROM представляет собой список имен таблиц, представлений и конструкций JOIN , разделенных запятыми. В следующем примере в операторе SELECT конструкция FROM задает таблицу Persons :

SELECT * FROM Persons

Конструкцию FROM также используют и для определения соединений между двумя таблицами или представлениями. О соединениях более подробно рассказано в следующем разделе.

Конструкции WHERE, GROUP BY и HAVING

В операторе SELECT конструкции WHERE и HAVING определяют строки исходной таблицы, которые необходимы для построения результирующего набора. Конструкции WHERE и HAVING играют роль фильтров. Они задают набор условий поиска: для построения результирующего набора выбираются лишь те строки, которые соответствуют условиям поиска. Например, в операторе SELECT конструкция WHERE возвращает лишь те строки, где в качестве места рождения персоны указан город Красноярск:

SELECT PersonId, LastName, FirstName

WHERE BirthPlace = "Krasnoyarsk"

Конструкция HAVING , как правило (но не обязательно), используется вместе с конструкцией GROUP BY . Конструкция HAVING задает дополнительные фильтры, которые применяются после завершения фильтрации, определяемой конструкцией WHERE . В следующем сценарии в операторе SELECT использованы конструкции WHERE , GROUP BY и HAVING :

SELECT OrdD1OrderId AS OrderId,

SUM(OrdD1.Quantity) AS "Units Sold",

SUM(OrdD1.UnitPrice * OrdD1.Quantity) AS Revenue

FROM AS OrdD1

WHERE OrdD1OrderId IN (SELECT DISTINCT OrdD2.OrderId

FROM AS OrdD2

WHERE OrdD2.UnitPrice > $1000)

GROUP BY OrdD1.OrderId

HAVING SUM(OrdD1.Quantity) > 50

Здесь конструкция WHERE возвращает заказы, стоимость которых больше $1000, а далее конструкция HAVING ограничивает результат, отбирая заказы на более чем 50 единиц товара. Конструкция GROUP BY ограничивает строки для каждого конкретного значения поля OrderId .

Конструкция GROUP BY

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

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

Если в операторе SELECT имеется конструкция GROUP BY , SQL Server налагает ограничения на элементы списка выбора. В списке выбора могут быть лишь те группирующие столбцы и выражения, которые возвращают только одно значение для каждого значения группирующих столбцов, например агрегатные функции (векторные агрегаты), одним из параметров которых является имя столбца.

Как правило, конструкция HAVING используется с конструкцией GROUP BY , хотя ее разрешается применять и отдельно. Любое выражение может стать группирующим, если оно не содержит агрегатных функций.

В конструкции GROUP BY необходимо задавать имя столбца таблицы или представления, а не имя столбца результирующего набора, присвоенное с помощью конструкции AS .

В конструкции GROUP BY допустимо указать несколько столбцов в виде вложенных групп, то есть сгруппировать таблицу посредством любой комбинации столбцов.

Понимание верной последовательности, в которой применяются конструкции WHERE , GROUP BY и HAVING , помогает создавать достаточно эффективные запросы:

Конструкция WHERE фильтрует строки, которые являются результатом операций, заданных в конструкции FROM;

Выходная информация конструкции WHERE группируется с помощью конструкции GROUP BY;

Строки сгруппированного результата фильтруются средствами конструкции HAVING .

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

Конструкция ORDER BY

Конструкция ORDER BY сортирует результат запроса по одному или нескольким полям. Сортировка может быть как по возрастанию (ASC ), так и по убыванию (DESC ). Если не задан ни один из видов сортировки, по умолчанию предполагается ASC . Если в конструкции ORDER BY названо несколько столбцов, выполняется вложенная сортировка.

Следующий оператор сортирует строки таблицы Persons сначала по фамилии (по убыванию), затем по имени (по возрастанию, для каждой персоны) и, наконец, по возрасту (также по возрастанию, поскольку не задан параметр DESC ).

SELECT PersonId, LastName, FirstName, Age

ORDER BY LastName DESC, FirstName, Age

Пакеты, хранимые процедуры и триггеры

Пакет - это группа из одного или нескольких операторов Transact-SQL, которые приложение одновременно посылает на SQL Server для исполнения. SQL Server компилирует операторы пакета в единую исполнимую единицу (план исполнения – Execution Plan ). После этого по очереди выполняются операторы этого плана.

Ошибка при компиляции, например синтаксическая, останавливает процесс компиляции плана исполнения. В этом случае ни один из операторов пакета исполнен не будет.

У ошибки периода выполнения, например арифметического переполнения или нарушения ограничения, возможно одно из следующих последствий:

Большинство ошибок периода выполнения останавливают исполнение текущего и последующих операторов пакета;

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

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

Например, пакет состоит из 3 операторов. Если во втором операторе допущена синтаксическая ошибка, ни один из операторов пакета не будет выполнен. Если пакет уже скомпилирован и при исполнении второго оператора происходит сбой, то результат первого оператора остается без изменений (поскольку он уже получен).

При обработке пакетов действуют следующие правила:

Операторы CREATE DEFAULT , CREATE PROCEDURE , CREATE RULE , CREATE TRIGGER и CREATE VIEW не могут соседствовать в пакетах с другими операторами. Пакет должен начинаться с оператора CREATE . Все следующие за ним операторы будут интерпретированы как часть определения, созданного первым оператором CREATE ;

В пределах одного и того же пакета нельзя модифицировать таблицу и обращаться к новым столбцам;

Если оператор EXECUTE - первый оператор пакета, ключевое слово EXECUTE не требуется. Но оно необходимо, когда оператор EXECUTE не является первым оператором пакета.

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

Для того чтобы задать пакет, имеется несколько способов.

Все операторы SQL, которые приложение отправляет на сервер как единицу исполнения, составляют единый пакет и генерируют один план исполнения.

Все операторы хранимой процедуры или триггера составляют единый пакет. При компиляции любой хранимой процедуры или триггера получается единственный план исполнения.

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

Строка, исполняемая системной хранимой процедурой sp_executesql , - это пакет, при компиляции которого получается один план исполнения.

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

Если оператор пакета вызывает триггер, то план исполнения триггера выполняется отдельно от плана исполнения исходного пакета.

Например, пакет, который содержит следующие четыре оператора, генерирует пять планов исполнения:

Оператор EXECUTE , исполняющий хранимую процедуру;

Вызов процедуры sp_executesql для обработки строки;

Оператор EXECUTE , обрабатывающий строку;

Оператор UPDATE , ссылающийся на таблицу, у которой есть триггер на обновление.

EXEC FirstProcedure

EXEC sp_executesql N"SELECT * FROM AdventureWorks.HumanResources.Employee

WHERE ManagerID = @level",

N"@level tinyint",

SET PersonName = "kuku"

Хранимая процедура - это группа операторов Transact-SQL, которая компилируется один раз и после этого может выполняться многократно. Такая функциональность повышает производительность, поскольку отпадает необходимость в перекомпиляции операторов Transact-SQL.

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

Операторы CREATE PROCEDURE и CREATE TRIGGER не могут располагаться в нескольких пакетах. Другими словами, хранимая процедура или триггер всегда создаются в одном пакете и компилируются в план исполнения.

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

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

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

"...Целостность (данных) (integrity (of data)): свойство данных сохранять точность и непротиворечивость независимо от внесенных изменений (ИСО/МЭК 2382-8)..."

Источник:

"ИНФОРМАТИЗАЦИЯ ЗДОРОВЬЯ. ТРЕБОВАНИЯ К АРХИТЕКТУРЕ ЭЛЕКТРОННОГО УЧЕТА ЗДОРОВЬЯ. ГОСТ Р ИСО/ТС 18308-2008"

(утв. Приказом Ростехрегулирования от 11.03.2008 N 44-ст)

• - завершенность, цельность и собственная закономерность...

  Начала современного Естествознания

• - Конгруэнтность и честность...

  Большая психологическая энциклопедия

• - состояние, в котором сознание и бессознательное сотрудничают вместе в гармоническом согласии.Согласно Юнгу, целостность соответствует здоровью, одновременно представляя потенциал и способность...

  Словарь по аналитической психологии

• - Конгpyэнтность и честность...

  Словарь нейролингвистического программирования

• - англ. integrity; нем. Ganzheit. Обобщенная характеристика объектов, обладающих сложной внутренней структурой...

  Энциклопедия социологии

• - обладание внутренним единством, неразделимость...

  Большой экономический словарь

• - "... - состояние ПО и данных, характеризующееся отсутствием изменений преднамеренного или случайного характера..." Источник: "ОБЩИЕ ТРЕБОВАНИЯ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ СРЕДСТВ ИЗМЕРЕНИЙ. РЕКОМЕНДАЦИЯ...

  Официальная терминология

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

  Финансовый словарь

• - "...Целостность): свойство данных сохранять точность и непротиворечивость независимо от внесенных изменений..." Источник: "ИНФОРМАТИЗАЦИЯ ЗДОРОВЬЯ. ТРЕБОВАНИЯ К АРХИТЕКТУРЕ ЭЛЕКТРОННОГО УЧЕТА ЗДОРОВЬЯ...

  Официальная терминология

• - обобщённая характеристика объектов, обладающих сложной внутренней структурой...

  Большая Советская энциклопедия

• - Р., Д., Пр....

  Орфографический словарь русского языка

• - ЦЕ́ЛОСТНОСТЬ, -и, жен. 1. см. целостный. 2. Нераздельность, единство. Территориальная ц. государства...

  Толковый словарь Ожегова

• - ЦЕ́ЛОСТНОСТЬ, целостности, мн. нет, жен. . отвлеч. сущ. к целостный. Целостность мировоззрения. Национальная целостность...

  Толковый словарь Ушакова

• - це́лостность ж. отвлеч...

  Толковый словарь Ефремовой

• - ц"...

  Русский орфографический словарь

• - ...

  Формы слова

"Целостность данных" в книгах

Проект «Хранилище данных» и проект «Технология выявления скрытых взаимосвязей внутри больших баз данных»

Из книги автора

Проект «Хранилище данных» и проект «Технология выявления скрытых взаимосвязей внутри больших баз данных» Оба этих проекта были интегрированы в 1999 г. Благодаря им начались разработка и проведение кампаний по продаже банковских продуктов. Эти проекты создали большие

Целостность и восстановление данных

Из книги Основы AS/400 автора Солтис Фрэнк

Целостность и восстановление данных Целостность данных, хранящихся в базе крайне важна. Между тем, при одновременном чтении и изменении данных многими пользователями существует вероятность их разрушения. База данных AS/400 предоставляет надежные средства обеспечения

Экспорт данных из базы данных Access 2007 в список SharePoint

автора Лондер Ольга

Экспорт данных из базы данных Access 2007 в список SharePoint Access 2007 позволяет экспортировать таблицу или другой объект базы данных в различных форматах, таких как внешний файл, база данных dBase или Paradox, файл Lotus 1–2–3, рабочая книга Excel 2007, файл Word 2007 RTF, текстовый файл, документ XML

Перемещение данных из базы данных Access 2007 на узел SharePoint

Из книги Microsoft Windows SharePoint Services 3.0. Русская версия. Главы 9-16 автора Лондер Ольга

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

Спасение данных из поврежденной базы данных

Из книги Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil автора Ковязин Алексей Николаевич

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

Проверка введенных данных на уровне процессора баз данных

автора Мак-Манус Джеффри П

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

Из книги Обработка баз данных на Visual Basic®.NET автора Мак-Манус Джеффри П

Обновление базы данных с помощью объекта адаптера данных

Из книги Язык программирования С# 2005 и платформа.NET 2.0. автора Троелсен Эндрю

Обновление базы данных с помощью объекта адаптера данных Адаптеры данных могут не только заполнять для вас таблицы объекта DataSet. Они могут также поддерживать набор объектов основных SQL-команд, используя их для возвращения модифицированных данных обратно в хранилище

Глава 2 Ввод данных. Типы, или форматы, данных

Из книги Excel. Мультимедийный курс автора Мединов Олег

Глава 2 Ввод данных. Типы, или форматы, данных Работа с документами Excel сопряжена с вводом и обработкой различных данных, то есть ин формации, которая может быть текстовой, числовой, финансовой, статистической и т. д. МУЛЬТИМЕДИЙНЫЙ КУРС Методы ввода и обработки данных

3.2. Экспорт данных из ERwin в BPwin и связывание объектов модели данных со стрелками и работами

Из книги Моделирование бизнес-процессов с BPwin 4.0 автора Маклаков Сергей Владимирович

Модель данных база данных

автора Борри Хелен

Модель данных <> база данных Тот "мир", который был получен в процессе описания и анализа, является черновиком для структур ваших данных. Считается, что логическая модель должна описывать отношения и наборы. Обычная ошибка (и западня, присущая всем инструментам CASE) слепо

ГЛАВА 17. Ссылочная целостность данных.

Из книги Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ автора Борри Хелен

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

Базы данных (классы для работы с базами данных)

Из книги Microsoft Visual C++ и MFC. Программирование для Windows 95 и Windows NT автора Фролов Александр Вячеславович

Базы данных (классы для работы с базами данных) В MFC включены несколько классов, обеспечивающую поддержку приложений, работающих с базами данных. В первую очередь это классы ориентированные на работу с ODBC драйверами – CDatabase и CRecordSet. Поддерживаются также новые средства для

Из книги Комментарий к Федеральному закону от 27 июля 2006г. N 152-ФЗ "О персональных данных" автора Петров Михаил Игоревич

Статья 16. Права субъектов персональных данных при принятии решений на основании исключительно автоматизированной обработки их персональных данных Комментарий к статье 161. Комментируемая статья определяет права субъектов персональных данных по отношению к принятию

2. Определение типа сравнения данных (от идеи к сравнению данных)

Из книги Говори на языке диаграмм: пособие по визуальным коммуникациям автора Желязны Джин

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

Обеспечение целостности данных является важнейшей задачей при проектировании и эксплуатации систем обработки данных (СОД).

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

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

Целостность данных - неотъемлемое свойство базы данных, и ее обеспечение является важнейшей задачей проектирования БнД. Це­лостность данных описывается набором специальных предложений, называемых ограничениями целостности. Ограничения целостнос­ти представляют собой утверждения о допустимых значениях отдель­ных информационных единиц и связях между ними. Эти ограничения определяются в большинстве случаев особенностями предметной области, хотя могут отражать и чисто информационные (лингвисти­ческие) характеристики. Например, если используются цифровые коды для обозначения какой-либо номенклатуры, то ограничения на тип используемых символов для соответствующего атрибута в БД определяются не спецификой предметной области, а просто выбран­ным способом кодирования, а ограничение, выражающееся в том, что возраст работающего должен быть не менее 16 лет, - трудовым зако­нодательством, т.е. только спецификой предметной области.

При выполнении операций над БД проверяется выполнение огра­ничений целостности. Действия, приводящие к нарушению подоб­ных ограничений, отвергаются.

Ограничения целостности могут классифицироваться по разным признакам (рис. 4.1).

Ограничения целостности могут относиться к разным информа­ционным объектам  : атрибутам (полям), кортежам (строкам, записям), отношениям (таблицам, файлам)  * , связям между файлами и т.п.

Рис. 4.1. Общая схема классификации ограничений целостности

1. Поле. Для него чаще всего используются следующие виды ог­раничений.

1.1. Тип и формат поля. Тип поля определяет допустимые для данного поля символы, а иногда и более жесткие ограничения на до­пустимые значения (как, например, для полей типа дата или логи­ческое).

1. 2. Задание диапазона значений. Обычно используется для чис­ловых полей.

1.2.1. Различают односторонние и двусторонние диапазоны. Пер­вые фиксируют значение только одной из границ (верхней или ниж­ней), вторые - обеих границ. Так, например, до определенного време­ни в нашей стране ограничивался как нижний, так и верхний предел заработной платы. Это пример двустороннего закрытого диапазона. Затем ограничение по верхнему пределу было снято: заработная пла­та не может быть меньше установленного минимума, но максималь­ное ее значение законодательно не определено - ограничение стало односторонним.

1.2.2. Диапазоны бывают открытые и закрытые. Односторон­ний диапазон всегда является открытым, двусторонний может быть как открытым, так и закрытым.

Двусторонний диапазон будет открытым, если допустимые зна­чения меньше «левой» границы и больше «правой» (рис. 4.2). Зада­ние двусторонних открытых диапазонов используется гораздо реже, чем закрытых. Некоторые СУБД поддерживают высокоуровневые средства задания двусторонних закрытых диапазонов и не поддержи­вают - открытых. Пример открытого диапазона: орган социального обеспечения поддерживает базу данных, содержащих записи о лю­дях моложе 16 лет или старше 60.

Рис. 4.2. Графическая иллюстрация понятий открытого (а)

и закрытого (б) двустороннего диапазона

1.3. Признак непустого поля. Характеризует недопустимость пу­стого значения поля в БД. Так, например, в таблице, содержащей све­дения о сотрудниках, поля «Фамилия», «Имя», «Отчество», «Оклад» должны обязательно иметь какое-то значение, а у поля «Ученая_степень» значение может отсутствовать.

1.4. Задание домена. Поле может принимать значение из задан­ного множества. Множество возможных значений какого-либо атри­бута называется доменом. Домен может задаваться перечислением входящих в него значений (например, значением поля «Пол» может быть только либо «мужской» либо «женский»; значением поля «Дол­жность» для профессорско-преподавательского состава может быть: «ассистент», «старший преподаватель», «доцент» и «профессор») или алгоритмом вычисления допустимых значений (как это обычно про­исходит для полей типа «Дата»). Последний из приведенных приме­ров свидетельствует не только о возможностях СУБД по поддержа­нию целостности данных, но и о важности процедуры выбора типа данных при проектировании баз данных.

Следует обратить внимание, что термин «домен» здесь использу­ется не как сугубо реляционный, а для обозначения множества воз­можных значений какого-либо атрибута безотносительно к использу­емой модели данных.

1.5. Специфическим ограничением на значение поля является признак его уникальности. Это ограничение проверяет допустимость значения данного поля, но при этом просматривается вся таблица (файл). Поэтому, с одной стороны, данное ограничение правильнее было бы отнести к ограничениям на таблицу. Но, с другой стороны, ограничение на уникальность поля проверяется сразу после ввода значения конкретного поля, в отличие от большинства других огра­ничений целостности на таблицу.

Признак уникальности поля тесно связан с понятием ключа, но уже последнего, поскольку ключ может быть представлен не только одним полем, а совокупностью полей (составной ключ). Уникальное поле является вероятным ключом данного отношения. При наличии нескольких вероятных ключей один из них должен быть выбран в качестве первичного ключа. Поле, выбранное в качестве первичного ключа, не должно иметь пустых значений. Не все СУБД поддержива­ют концепцию ключа, т.е. позволяют определять ключ при описании БД. Некоторые СУБД для каждого файла (таблицы) требуют обяза­тельно определять ключ при описании базы данных. Другие СУБД (например, Access), в принципе поддерживая концепцию ключа, раз­решают создавать таблицы, в которых ключ не задан.

Ограничение на уникальность чаще всего возникает при отобра­жении в базе данных каких-то объектов, и уникальное поле являет­ся идентификатором этого объекта. Поэтому это ограничение цело­стности иногда называется ограничением целостности объекта (сущности).

1.6. Очень важным видом ограничений целостности являются функциональные зависимости. Информацию об имеющих место в данной предметной области функциональных зависимостях можно извлечь из инфологической модели (см. разд. 4.2). Эта информация используется и при проектировании базы данных, и для контроля це­лостности при ее функционировании. Если БД спроектирована пра­вильно, т.е. она находится в 4-й нормальной форме, то, определяя ключи и вероятные ключи отношений, тем самым определяются и имеющиеся функциональные зависимости между атрибутами.

1.7. Рассмотренные выше ограничения определяли проверки зна­чения поля вне зависимости от того, вводится это значение впервые или корректируются имеющиеся в базе данных значения. Ограниче­ния, которые используются только при проверке допустимости кор­ректировки, называют ограничениями перехода (или динамическими ограничениями ). Например, если в базе данных имеются поля «Возраст_сотрудника», «Стаж_работы» и т.п., то при корректировке зна­чения этих полей могут только увеличиваться. В аспекте правильнос­ти проектирования БД приведенные выше для иллюстрации поля, особенно поле «Возраст_сотрудника», лучше вообще не хранить в базе данных, а получать расчетным путем. Это не только существенно уп­ростит ведение базы данных, но и облегчит процесс обеспечения це­лостности данных.

Другим примером ограничения перехода является корректировка поля «Семейное_положение». Так, значение «вдовец» может быть исправлено только на «женат», а «холост» не может быть исправлен на «разведен» и т.п.

Ограничение целостности может относиться как к реальному, так и к виртуальному полю, т.е. полю, которое в явном виде в таблице не хранится (например, если в БД фиксируется только поле «Дата__рождения», а ограничение накладывается на возраст). Последнее порож­дает дополнительные сложности. Так, в рассматриваемом примере значение свойства «возраст» в явном виде в БД не хранится - значит, надо разрабатывать специальную процедуру проверки соблюдения ограничения в каждый момент времени и решать вопрос о периодич­ности использования этой процедуры для проверки БД. Когда про­верка происходит в момент ввода данных, то она играет двоякую роль: контроль правильности ввода данных и соответствие человека, о ко­тором вводятся данные, предъявляемым к нему требованиям. При периодической проверке данного ограничения после ввода данных происходит проверка соответствия самой предметной области уста­новленным требованиям.

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

2. Кортеж (запись, строка ) . Здесь имеются в виду ограничения на соотношения значений отдельных полей в пределах одной строки. В качестве ограничения на соотношения полей внутри одного корте­жа можно привести следующее: значение поля «Стаж» не должно пре­вышать [«Возраст» - 16] (предполагается, что трудовой стаж челове­ка начинается не ранее чем в 16 лет).

3. Таблица. Ограничения целостности, относящиеся к таблице, затрагивают разные ее строки. Чаще всего для проверки их соблюде­ния приходится просматривать всю таблицу. К таким ограничениям относятся рассмотренные выше ограничения на уникальность поля или совокупности полей. Другим примером может служить ограни­чение для таблицы, содержащей сведения об окладах сотрудников, заключающееся в том, что средняя зарплата сотрудников не должна превосходить заданную величину. Такое ограничение может иметь место в случае, когда фонд заработной платы формируется исходя из величины нормативной средней заработной платы одного сотрудни­ка и численности сотрудников.

Имеется ряд ограничений целостности, которые проверяют соот­ношения между записями одной таблицы: 1) нельзя быть родителем и ребенком одного и того же человека; 2) год рождения родителя дол­жен быть меньше, чем год рождения ребенка. Первый из приведен­ных примеров является частным случаем более общего ограничения на отсутствие циклов. К аналогичным ограничениям относятся огра­ничения на наличие циклов при определении состава изделия (узел не может входить сам в себя), при описании организационной струк­туры и во многих других случаях. Если СУБД не позволяет контроли­ровать подобные ограничения целостности, то следует написать уни­версальную программу (создать процедуру), позволяющую это делать, поскольку такого рода проверки нужны достаточно часто.

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

4.1. Наиболее часто встречающееся из этих ограничений - огра­ничение целостности связи. Оно выражается в том, что значение ат­рибута, отражающего связь между объектами и являющегося внешним ключом отношения, обязательно должно совпадать с одним из значе­ний атрибута, являющегося ключом отношения, описывающего соот­ветствующий объект. Например, если в базе данных существует таб­лица, отражающая связь между преподавателями и дисциплинами, которые каждый из них может преподавать, то код преподавателя в этой таблице должен соответствовать одному из кодов в таблице «Пре­подаватели», а код дисциплины - значению соответствующего поля в таблице «Дисциплины».

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

4.2. Разновидностью ограничения целостности связи является ограничение по существованию, заключающееся в том, что для суще­ствования объекта в отношении S 1 необходимо, чтобы он был связан с объектом в отношении S 2 .

Например, если сотрудника принимают на работу, то он должен быть «приписан» к какому-либо отделу, т.е. экземпляр записи «Со­трудник» может существовать только при существовании отдела, в котором он работает, и эта связь должна быть обязательно задана. В принципе в предметной области может быть и иная ситуация, допускающая наличие сотрудников, не приписанных ни к какому отделу. В последнем случае ограничение между таблицами «Сотрудник» и «От­дел» будет ограничением по связи, но не будет ограничением по существованию; т.е. ограничение по существованию является более сильным, чем простое ограничение по связи, и предполагает не толь­ко наличие соответствующего значения идентификатора отдела в таб­лице «Отдел», но и недопустимость пустого значения поля «Отдел» в таблице «Сотрудник».

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

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

при удалении записи основной таблицы удаляются все связан­ные с ней записи в зависимой таблице (так называемое каскадное удаление);

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

Удаление записей зависимой таблицы не может привести к нару­шению ограничения целостности по связи или существованию.

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

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

Если изменение касается поля связи в зависимом файле, то при изменении нужно смотреть, есть ли новое значение в соответствующем поле основного файла. Иногда изменения поля связи в зависи­мом файле должны быть запрещены. Например, если имеется пара связанных таблиц «Отдел»-«Сотрудник», то изменение значения поля «Код отдела» в таблице «Сотрудник» будет означать перевод сотруд­ника в другой отдел (при изменении значения поля нужно проверять, что скорректированное значение не нарушает целостность по связи). Если же имеется пара связанных таблиц «Студент»-«Успеваемость», то изменение значение поля «Код_студента» в таблице «Успеваемость» следует запретить, поскольку такая корректировка означала бы, что результаты экзамена одного студента будут приписаны другому сту­денту, что бессмысленно.

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

4.3. Кроме ограничений целостности связи ограничения, охваты­вающие несколько таблиц, могут представлять собой предложения, проверяющие отсутствие логических противоречий между данными взаимосвязанных таблиц. Например, если для каждой должности ус­тановлена определенная вилка оклада, то значение поля «Оклад» в таблице «Кадры» не должно выходить за пределы этой вилки, кото­рая зафиксирована в таблице «Должности».

5. Особым видом ограничений являются алгоритмические зави­симости между показателями. Если в БД хранятся как исходные, так и производные показатели, то необходимо поддерживать соответствие между ними. Следует обратить внимание на особенности корректи­ровки производных показателей: обычно их корректировка либо дол­жна быть запрещена, либо она должна быть следствием изменения исходных показателей.

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

Если объекты имеют статические свойства (на ER-диаграмме от­мечены буквой «С»), то для них можно задавать запрет на обновле­ние. Так, например, если описывается объект ЛИЧНОСТЬ, то такие атрибуты, как «Дата_рождения» и «Место_рождения» являются постоянными и меняться не могут. Задание запрета на обновление для соответствующих полей в базе данных гарантирует, что сохраненная в БД информации не будет случайно или преднамеренно искажена.

Рассмотрим следующий пример ограничения на обновление за­писи. Пусть в базе данных по кадровому составу для каждого сотруд­ника хранятся сведения об их поощрениях/наградах. Эта информа­ция хранится в таблице «Поощрения», имеющей поля: «Табельный_номер сотрудника», «Вид_поощрения», «Дата». В эту таблицу могут добавляться записи, но каждая отдельная запись изменяться не может.

В рассматриваемом примере наблюдается также ограничение свя­зи по существованию между таблицами «Поощрения» и «Сотрудни­ки»: «Табельный_номер» в таблице «Поощрения» должен обязатель­но присутствовать в таблице «Сотрудники»; при удалении записи в таблице «Сотрудники» все связанные с ней записи в таблице «Поощ­рения» должны быть также удалены.

Некоторые СУБД позволяют задавать при описании данных так называемое обязательное членство для включения и каскадное уда­ление. В этом случае целостность при корректировке будет обеспечи­ваться системой автоматически.

7. Ограничения целостности можно не только накладывать, но и отменять. При этом между отношениями могут существовать зависи­мости, и отмена одного из них может потребовать ликвидации дру­гих (ссылочных) ограничений, зависящих от первоначального. На­пример, если объявлено, что в таблице, содержащей сведения об орга­низациях, поле «Наименование_организации» является уникальным и объявлена ссылочная целостность с таблицей «Поставка», в кото­рой также имеется это поле, а потом отменяется ограничение на уни­кальность поля «Наименование_организации» в первой таблице, то ссылочное ограничение целостности также должно быть удалено (по­скольку ссылочная целостность проверяется только в случае, если в главной таблице соответствующее поле является ключевым). Неко­торые СУБД автоматически поддерживают каскадное удаление огра­ничений целостности, когда при удалении одного из них удаляются все зависящие от него ограничения целостности.

Другими словами, понятие целостности можно отнести не только к БД, но и к самой системе ограничений, и было бы хорошо, чтобы СУБД ее автоматически поддерживали.

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

С понятием отложенного ограничения целостности тесно связа­но понятие транзакции - законченной совокупности действий над БД, которая переводит БД из одного целостного в логическом смысле со­стояния в другое целостное состояние.

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

9. Другим признаком классификации по временному признаку является классификация по режиму проверки корректности БД . Возможны два режима проверки ограничений целостности: провер­ка в момент корректировки и проверка существующей БД. Назовем первый из них оперативным режимом , второй - аудитом БД.

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

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

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

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

Для отслеживания взаимосвязи между всеми информационными компонентами БнД должны использоваться словари данных.

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

13. Различают логическую и физическую целостность БД. Логи­ческая целостность - состояние БД, характеризующееся отсутстви­ем нарушений ограничений целостности, присущих логической мо­дели данных (т.е. неявных ограничений), и явных ограничений, за­данных декларативным или процедурным путем. Выше речь шла именно о логической целостности. Физическая целостность - от­сутствие нарушений спецификаций схемы хранения, а также физи­ческих разрушений данных на носителе.

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

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

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

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

В СУБД семейства xBASE основная масса ограничений целост­ности должна была быть определена на ЯМД, так как в ЯОД практи­чески отсутствовали средства определения ограничений целостно­сти данных. Часть ограничений целостности можно было задавать при создании экранных форм.

В современных СУБД многие ограничения можно описать на ЯОД. Они хранятся в схеме данных и при работе с БД поддерживаются ав­томатически.

Для контроля целостности БД применяется также механизм триг­геров. Триггер - это действие, которое активизируется при наступле­нии указанного события (вставки, удаления, обновления записи). Триг­геры специфицируются в схеме базы данных.

Более широким понятием по отношению к триггеру является по­нятие хранимая процедура. Хранимые процедуры описывают фраг­менты логики приложения, хранятся и исполняются на сервере, что позволяет улучшать характеристики производительности.

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

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

Одной из важнейших задач, решаемой СУБД, является поддержание в любой момент времени взаимной непротиворечивости, правильности и точности данных, хранящихся в БД. Этот процесс называется обеспечением целостности базы данных.

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

Целостность базы данных может быть нарушена в результате сбоя оборудования; программной ошибки в СУБД, операционной системе или прикладной программе; неправильных действий пользователей. Эти ситуации могут возникать даже в хорошо проверенных и отлаженных системах, несмотря на применяемые системы контроля. Поэтому СУБД должна иметь средства обнаружения таких ситуаций и восстановления правильного состояния базы данных.

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

Обеспечение целостности данных гарантирует качество данных в таблице.

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

• 1. Сущностная целостность -- определяет строку как уникальную сущность в конкретной таблице. Она обеспечивает целостность столбцов идентификаторов или первичного ключа таблицы с помощью индексов и ограничений UNIQUE или PRIMARY KEY.
• 2. Доменная целостность -- это достоверность записей в конкретном столбце. Она включает ограничения типа данных, ограничения формата при помощи ограничений CHECK и правил, а также ограничения диапазона возможных значений при помощи ограничений FOREIGN KEY, CHECK, DEFAULT, определений NOT NULL и правил.
• 3. Ссылочная целостность -- сохраняет определенные связи между таблицами при добавлении или удалении строк.

В SQL Server ссылочная целостность основана на связи первичных и внешних ключей (либо внешних и уникальных ключей) и обеспечивается с помощью ограничений FOREIGN KEY и CHECK. Ссылочная целостность гарантирует согласованность значений ключей во всех таблицах. Этот вид целостности требует отсутствия ссылок на несуществующие значения, а также обеспечивает согласованное изменение ссылок во всей базе данных при изменении значения ключа.

При обеспечении ссылочной целостности SQL Server не допускает следующих действий пользователей:

• - Добавления или изменения строк в связанной таблице, если в первичной таблице нет соответствующей строки;
• - Изменения значений в первичной таблице, которое приводит к появлению потерянных строк в связанной таблице;
• - Удаления строк из первичной таблицы, если имеются соответствующие ей строки в связанных таблицах.
• 4. Пользовательская целостность -- позволяет определять бизнес-правила, не входящие ни в одну из категорий целостности. Поддержку пользовательской целостности обеспечивают все остальные категории целостности: любые типы ограничений уровня столбца и уровня таблицы в инструкции CREATE TABLE, хранимых процедурах и триггерах.