Целостность баз данных. Обеспечение целостности баз данных

Оставьте комментарий 6,950

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

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

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

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

Для полей (атрибутов) используются следующие виды ограничений:

· Тип и формат поля (автоматически допускают ввод только данных определенного типа).

· Задание диапазона значений. Данное ограничение используется обычно для числовых полей. Различают открытые и закрытые диапазоны: первые фиксируют значение только одной из границ, вторые – обеих границ.

· Недопустимость пустого поля. Ограничение позволяет избежать появления в БД «ничейных» записей, в которых пропущены какие-либо обязательные данные, например: поле «ФИО» должно обязательно иметь значение, а у поля «ученая степень» значение может отсутствовать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тесты для самоконтроля

1 . Утверждения о допустимых значениях отдельных информационных единиц и связях между ними называют:

а) ограничениями перехода;

б) ограничениями целостности связи;

в) ограничениями целостности.

2 . Ограничения целостности:

а) определяются в основном особенностями предметной области;

б) предназначены для отражения чисто информационных характеристик;

в) подразумевают, что пользователям разрешается выполнять некоторые действия.

3 . Могут не соблюдаться в процессе выполнения какой-либо группы операций, но обязаны быть соблюдены по завершении этой группы операций:

а) отложенные ограничения;

б) ограничения перехода;

в) явные ограничения.

4 . К классу синтаксических ограничений относятся:

а) ограничения целостности связи;

б) неявные ограничения;

в) ограничения перехода.

5 . Понятие транзакции связано с понятием:

а) отложенного ограничения;

б) одномоментного ограничения;

в) явного ограничения.

6 . По способу задания ограничения разделяют:

а) на одномоментные и отложенные;

б) на синтаксические и семантические;

в) на явные и неявные.

7 . Обеспечение соблюдения ограничений целостности:

а) является заботой пользователя;

б) является заботой проектировщика;

в) является функцией СУБД.

8 . Ограничения целостности являются важной компонентой:

а) даталогической модели;

б) базы данных;

в) инфологической модели.

НАСТОЛЬНЫЕ СУБД

На сегодняшний день известно более двух десятков форматов данных настольных СУБД, однако наиболее популярными, исходя из числа проданных копий, считаются dBase , Раrаdох , FoxPro и Access . Отмечают также СУБД Microsoft Data Engine – по существу серверную СУБД, представляющую собой «облегченную» версию Microsoft SQL Server , но предназначенную для использования главным образом в настольных системах и небольших рабочих группах.

Сведения о производителях перечисленных выше СУБД представлены в табл. 9.1.

DBase и Visual dBase

Первая промышленная версия СУБД dBase – dBase II появилась в начале 80-х годов. Благодаря простоте в использовании, нетребовательности к ресурсам компьютера и, что не менее важно, грамотной маркетинговой политике компании-производителя, этот продукт приобрел немалую популярность, а с выходом следующих его версий – dBase III и dBase III Рlus (1986 г.), оснащенных весьма комфортной по тем временам средой разработки и средствами манипуляции данными, быстро занял лидирующие позиции среди настольных СУБД и средств создания использующих их приложений.

Хранение данных в dBase основано на принципе «одна таблица – один файл» (эти файлы обычно имеют расширение *.dbf ). МЕМО – поля и ВLОВ – поля (доступные в поздних версиях dBase ) хранятся в отдельных файлах (обычно с расширением *.dbt ). Индексы для таблиц также хранятся в отдельных файлах.

Формат данных dBase является открытым, что позволило ряду других производителей заимствовать его для создания dBase -подобных СУБД, частично совместимых с dBase по форматам данных.

Помимо популярного формата данных dBase является родоначальником и некогда популярного семейства языков программирования, получившего название хВаsе . Однако для работы с данными формата dBase (или иных dBase -подобных СУБД) совершенно необязательно пользоваться диалектами хВаsе . Доступ к этим данным возможен с помощью ОDВС АРI (и соответствующих драйверов) и некоторых других механизмов доступа к данным.

После покупки dBase компанией Borland этот продукт, получивший впоследствии название Visual dBase , приобрел набор дополнительных возможностей, характерных для средств разработки этой компании, и для имевшейся у нее другой настольной СУБД – Раrаdох . Среди этих возможностей можно отметить специальные типы полей для графических данных, поддерживаемые индексы, хранение правил ссылочной целостности внутри самой базы данных, а также возможность манипулировать данными других форматов, в частности серверных СУБД, за счет использования ВDЕ АРI и SQL Links .

В настоящее время Visual dBase принадлежит компании dBase , Inс . Его версия – Visual dBase 7.5 имеет следующие возможности:

dBase и FoxPro всех версий;

· средства публикации данных в Internet и создания Web -клиентов;

· ядро доступа к данным Аdvantage Database Server фирмы Extended Systems и ОDВС - драйвер для доступа к данным этой СУБД;

· средства публикации отчетов в Web ;

· средства генерации исполняемых файлов и дистрибутивов.

В настоящее время к Visual dBase в качестве дополнения может быть приобретен компонент dСоnnections , позволяющий осуществить доступ к данным Оracle , Sybase , Informix , МS SQL Server , DB2 , InterBase из Visual dBase 7.5 и приложений, созданных с его помощью.

Компания DBase , Inс объявила также о проекте dBASE Open Source , целью которого является разработка сообществом пользователей dBase новых компонентов и классов с целью включения их в последующую версию dBase (получившую название dBase 2000 ). Иными словами, имеется тенденция превращения dBase (или его частей) в некоммерческий продукт с доступными исходными текстами.

Рarаdох

Раrаdох был разработан компанией Аnsa Software , и первая его версия увидела свет в 1985 году. Этот продукт был впоследствии приобретен компанией Воrland . С июля 1996 года он принадлежит компании Соrеl и является составной частью Соrеl 0ffice Professional .

В конце 80-х - начале 90-х годов Раrаdох , принадлежавший тогда компании Воrland International , был весьма популярной СУБД, в том числе и в нашей стране.

Принцип хранения данных в Раrаdох сходен с принципами хранения данных в dВаsе – каждая таблица хранится в своем файле (расширение *.db ), МЕМО - и ВLOB -поля хранятся в отдельном файле (расширение *.md ), как и индексы (расширение *.рх ). Однако, в отличие от dBase , формат данных Раrаdох не является открытым, поэтому для доступа к данным этого формата требуются специальные библиотеки.

Отсутствие «открытости» формата данных имеет свои достоинства. Так как в этой ситуации доступ к данным осуществляется только с помощью «знающих» этот формат библиотек, простое редактирование подобных данных по сравнению с данными открытых форматов типа dBase существенно затруднено. В этом случае возможны такие недоступные при использовании «открытых» форматов данных сервисы, как защита таблиц и отдельных полей паролем, хранение некоторых правил ссылочной целостности в самих таблицах – все эти сервисы предоставляются Раrаdох , начиная с первых версий этой СУБД.

По сравнению с аналогичными версиями dВаsе ранние версии Раrаdох обычно предоставляли разработчикам баз данных существенно более расширенные возможности, такие как использование деловой графики в DOS -приложениях, обновление данных в приложениях при многопользовательской работе, визуальные средства построения запросов, на основе интерфейса QВЕ – Query by Ехаmрlе , средства статистического анализа данных, а также средства визуального построения интерфейсов пользовательских приложений с автоматической генерацией кода на языке программирования РАL (Paradox Аррlication Language ).

Windows -версии СУБД Раrаdох , помимо перечисленных выше сервисов, позволяют также манипулировать данными других форматов, в частности dВаsе и данными, хранящимися в серверных СУБД. Что же касается базового формата данных, используемого в этом продукте, то он обладает теми же недостатками, что и все форматы данных настольных СУБД, и поэтому при возможности его стараются заменить на серверную СУБД, даже сохранив сам Раrаdох как средство разработки приложений и манипуляции данными.

Версия данной СУБД – Раrаdох 9 , поставляется в двух вариантах – Раrаdох 9 Standalone Edition и . Первый из них предназначен для использования в качестве настольной СУБД и входит в Соrеl Оffice Professional , второй – в качестве как настольной СУБД, так и средства разработки приложений и манипуляции данными в серверных СУБД. Обе версии содержат:

· средства манипуляции данными Раrаdох и dBase ;

· средства создания форм, отчетов и приложений;

· средства визуального построения запросов;

· средства публикации данных и отчетов в Internet и создания Web -клиентов;

· Cоrеl Web – сервер;

· ОDВС – драйвер для доступа к данным формата Раrаdох из Windows -приложений;

· средства для доступа к данным формата Раrаdох из Java -приложений.

Помимо этого, Раrаdох 9 Developer’s Edition содержит:

· Run – time - версию Раrаdох для поставки вместе с приложениями;

· средства создания дистрибутивов;

· драйверы SQL Links для доступа к данным серверных СУБД.

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

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

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

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

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

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

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

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

В-третьих, это поддержка ссылочной целостности (Declarative Referential Integrity, DRI), означает обеспечение одного из заданных принципов взаимосвязи между экземплярами кортежей взаимосвязанных отношений:

· кортежи подчиненного отношения уничтожаются при удалении кортежа основного отношения, связанного с ним;

· кортежи основного отношения модифицируются при удалении кортежа основного отношения, связанного с ним, при этом на месте ключа родительского отношения ставится неопределенное Null значение.

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

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

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

Семантическая поддержка может быть обеспечена двумя путями:

· декларативный, выполняемый средствами языка SQL;

· процедурный, выполняемый посредством триггеров и хранимых процедур.

Декларативный путь связан с наличием механизмов в рамках СУБД, обеспечивающих проверку и выполнение ряда декларативно заданных правил-ограничений, называемых чаще всего «бизнес-правилами» (Business Rules) или декларативными ограничениями целостности.

Выделяются следующие виды декларативных ограничений целостности:

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

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

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

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

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

Примеры правил: вес детали должен быть положительным; количество знаков в телефонном номере не должно превышать 15; возраст родителей не может быть меньше возраста их биологического ребёнка и т. д.

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

Механизмы обеспечения целостности являются одной из составляющих концепции модели данных .

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

В теории реляционных баз данных принято выделять четыре типа ограничений целостности :353:

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

Целостность и истинность данных в БД [ | ]

Целостность БД не гарантирует достоверности (истинности) содержащейся в ней информации, но обеспечивает по крайней мере правдоподобность этой информации, отвергая заведомо невероятные, невозможные значения. Таким образом, не следует путать целостность (непротиворечивость) БД с истинностью БД. Истинность и непротиворечивость - не одно и то же :351 .

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

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

кортежи подчиненного отношения уничтожаются при удалении кортежа основного отношения, связанного с ним;

кортежи основного отношения модифицируются при удалении кортежа основного отношения, связанного с ним, при этом на месте ключа родительского отношения ставится неопределенное Null значение.

Семантическая поддержка может быть обеспечена двумя путями:

декларативный, выполняемый средствами языка SQL;

процедурный, выполняемый посредством триггеров и хранимых процедур.

Выделяются следующие виды декларативных ограничений целостности:

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

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

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

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

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

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

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

связанные поля имеют один тип данных;

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

Для соблюдения этих правил в Access отслеживаются и блокируются следующие действия:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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