Термин «целостность» используется для описания точности и корректности (или непротиворечивости) данных, хранящихся в базе данных.

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

Ограничения целостности могут быть любой степени сложности. В ряде случаев дополнительные разные ограничения называют бизнес-правилами. Когда речь идет об элементарных ограничениях, то здесь используется ключевое слово CHECK (контроль правильности ввода данных, соответствия этих данных другим…), их называют элементарными, они чаще всего бывают жестко вписаны. Расширенные правила могут включать вопросы целостности между отдельными таблицами, например, «нет детей без родителей». А бизнес-правила могут касаться конкретных сфер применения баз данных (например, у бухгалтерской базы данных свои, у другой другие …). При этом сами ограничения могут быть установлены на сервере, на клиенте или на промежуточных программных средствах (middleware).

А) Рассмотрим вариант «на сервере», т.е. ограничения размещают в виде кода на сервере. В этом случае данные самостоятельно защищаются от вмешательства и случайного стирания, и все клиенты автоматически подчиняются этим ограничениям. Это приводит к тому, что сами клиентские приложения могут быть более простыми, поскольку в них уже не надо закладывать ограничений. Во-вторых, выполнение ограничений на сервере быстрее, т.к. их не надо высылать на сервер, а надо только прислать ошибку. Однако есть определенные проблемы, связанные с тем, что язык SQL не так хорош, по сравнению с универсальными языками, и там не так просто хитрые ограничения сделать. По своей сути ограничения хранятся в системных таблицах базы данных, у них обычно имеются либо автоматически создаваемые, либо создаваемые пользователем имена (последний вариант лучше, т.к. если автоматически, то идут номера, в которых трудно найти нужное ограничение). В InterBase автоматически они называются integer _№. К недостаткам также можно отнести невозможность клиентского приложения реагировать на некоторые ошибочные ситуации (Например, проблемы с сетью).

Б) При размещении ограничений на клиенте, ввиду универсальных языков с богатыми библиотеками и возможностями, можно создавать очень сложные и гибкие ограничения. Можно встраивать ограничения в визуальные компоненты, создавать новые классы, содержащие эти ограничения и т.д. Но это приводит к тому, что такого рода ограничения надо распространять на разные клиентские приложения, выполняющие разную роль, во-вторых, это требует более мощных клиентских станций, что нарушает философию клиент-серверных систем (когда сервер должен быть мощным, а клиент – простеньким), и в таких случаях трудно просмотреть все ограничения, поскольку они разбросаны по разным станциям. К недостаткам такого рода удобных и гибких возможностей можно отнести то, что в разных языках такого рода ограничения выполняются по-разному, и стандартов на создание таких ограничений нет, поэтому многое зависит от знаний и умений программиста, использующего данный язык программирования. Чем больше квалификация, тем хитрее ограничение он может написать. С базами данных проще, там язык более или менее стандартный, поэтому понять суть ограничения может любой, кто знает этот язык.

В) Размещение ограничений на уровне промежуточных средств. К промежуточным средствам относятся такие системы как ODBC, GDBC, различные API, которые предоставляют унифицированный доступ к базам данных (OLE DB…). Здесь тоже есть определенные плюсы и минусы. Минусы прежде всего связаны с тем, что, несмотря на то, что таких API стало много, тем не менее достаточно сильно развитых средств создания ограничений мало, во-вторых, все эти API обычно привязаны к операционной системе (базы данных как правило делают так, чтоб они и там, и там могли работать, а вот эти промежуточные средства – обычно принадлежность либо UNIX, либо Windows, либо еще чего-нибудь).

Типы (виды) условий целостности данных:

1. обязательность данных – как только вы войдете в набор данных того или иного поля, пока не введете какие-либо данные, вас система из средства набора не выпустит (NOT NULL).
2. проверка на правильность (validity checking)– проверка диапазона значений (правильность введения даты, размера чисел)
3. целостность (entity integrity) – соответствие внешнего ключа и primary key
4. ссылочная целостность (referent integrity) – как правило, проверяют в двух местах: на клиенте, на сервере.
5. непротиворечивость (business правила) – деловые правила, зависит от конкретных СУБД.

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

В 1986 году фирма «say base» ввело понятие «триггера», что позволило включить (перенести) написание деловых правил на сервер и, следовательно, уменьшить объем прикладных программ.

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

Комментарии запрещены.