Ограничения целостности данных

 

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

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

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

При проектировании БД особое значение имеют так называемые семантические ограничения целостности (или семантические условия).

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

Семантические ограничения целостности различают:

1) ограничения целостности атрибутов (доменов);

2) ограничения целостности отношений (таблиц);

3) ограничения целостности ссылок между отношениями (ограничения целостности базы данных).

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

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

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

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

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

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

В случае, когда база данных моделируется не одним, а несколькими (хотя бы и двумя) связанными отношениями, возникает проблема ограничения целостности базы данных. Ограничение целостности базы данных в реляционном представлении определяется как ограничение ссылочной целостности, или ограничение, основанное на связях между отношениями-объектами. Связи между отношениями могут быть типа «один к одному» (1:1) или «один ко многим» (1:N).

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

Внешний ключ – это первичный ключ отношения-отца, переданный «по наследству» отношению-сыну.

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

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

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

Примерами ограничений целостности ссылок в нашем случае являются, например такие:

1. Отношение между таблицами «Кафедра» и «Студент» должно быть таково, что студент не может быть принят на несуществующую специальность.

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

Контроль целостности данных

 

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

Задание 9. Для проверки корректности процедур манипулирования данными связанных таблиц попытайтесь добавить вручную в таблицу «Студент» бесконтрольную запись такого содержания: «000000», «Одинцов О.О.», «c0» (речь идет о приёме студента на несуществующую специальность):

1) в окне БД на закладке Таблица выберите из списка таблицу «Студент» и нажмите экранную кнопку ;

2) введите вручную новую запись: «000000», «Одинцов О.О.», «с0»;

3) сохраните результат по команде Файл | Сохранить и Файл | Закрыть.

Вы выполнили некорректную с точки зрения семантики ПО операцию:

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

 

Семантика связей между таблицами

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

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

Познакомимся с этими возможностями подробнее.

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

 

Задание 10. Для обеспечения контроля ввода корректных значений внешнего ключа «специальность» в таблице «Студент» настройте его свойство подстановка (создайте на основе таблицы «Кафедра» поле со списком разрешенных значений):

1) в окне БД на закладке Таблицы откройте таблицу «Студент» в режиме Конструктор;

2) выделите поле «специальность»;

3) в нижней части диалогового окна, на закладке «Подстановка» настройте свойства элемента управления «Поле со списком» в соответствии с образцом, приведенным на рис. 37;

4) по завершении модификации структуры таблицы «Студент» сохраните результаты по команде Файл | Сохранить и закройте диалоговое окно;

5) откройте таблицу «Студент» в Режиме таблицы, для чего нажмите экранную кнопку ;

6) в любой строке таблицы щелчком мыши в поле «специальность» вызовите список «разрешенных» значений (рис. 38);

7) попробуйте ввести данные в обход элемента управления, убедитесь в тщетности этой попытки.

Рис. 37. Настройка свойств элемента управления для поля специальность

 

Рис. 38. Ввод данных под управлением поля со списком

 

 

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

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

 

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

1) выполните команду Сервис | Схема данных – появится макет схемы данных БД (рис. 39);

2) для установления контроля целостности связи между таблицами «Кафедра» и «Студент» щелкните правой клавишей мыши по изображению связи и выберите в контекстном меню «Изменить связь» – раскроется окно «Изменение связей» (рис. 39);

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

Рис. 39. Окно спецификации связей в схеме данных

Рис. 40. Сообщение о неудачной попытке установления связи

 

4) для установления контроля целостности связи между таблицами «Студент» и «Сессия» щелкните правой клавишей мыши по изображению связи и выберите в контекстном меню «Изменить связь» – раскроется окно «Изменение связей»;

5) в окне «Изменение связей» мышью «включите» состояние «Обеспечение целостности данных» и нажмите экранную кнопку OK – связь будет установлена. Корректная связь в схеме данных выделяется жирной линией и метками кардинальности связи 1 и (рис. 41);

6) сохраните результат создания связей между таблицами по команде Файл | Сохранить. Ничего, что попытка установления связи с обеспечением целостности данных между таблицами «Кафедра» и «Студент» оказалась неудачной. Схему данных (макет), как и любой объект Access, можно отредактировать в новых условиях.

Из полученных результатов важно уяснить себе следующее:

1) методы создания связи с обеспечением целостности данных;

2) причины неудачи создания связей;

3) невозможность установления контроля целостности некорректных данных.

 

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

1) в окне БД на закладке Таблица выберите из списка таблицу «Студент» и нажмите экранную кнопку ;

2) удалите вручную запись: «000000 Одинцов О.О. с0»;

3) сохраните результат по команде Файл | Сохранить и Файл | Закрыть;

4) вернитесь к настройке свойств связей по команде Сервис | Схема данных – появится макет схемы данных;

5) щелкните мышью по связи «Кафедра»:«Студент» – раскроется окно «Изменение связей» (рис. 39);

6) в окне «Изменение связей» мышью «включите» состояние «Обеспечение целостности данных» и нажмите экранную кнопку OK. Макет схемы данных примет вид, как на рис. 41;

7) сохраните результат создания связей между таблицами по команде Файл | Сохранить.

 

Рис. 41. Корректная схема базы данных УЧЕБА

Внимание! Важный результат: наша демонстрационная ПО УЧЕБА представлена БД в виде совокупности нормализованных таблиц «Кафедра», «Студент» и «Сессия», связанных корректными связями, которые обеспечивают контроль целостности данных.

 

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

 

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

Для того чтобы при манипулировании данными одной из связанных таблиц выполнялись адекватные изменения других таблиц, могут быть «включены» каскадные обновление и удаление данных [7–10].

Какие правила обеспечения целостности данных выбрать, зависит от семантики данных моделируемой ПО. Рассмотрим эти проблемы на нашем примере БД УЧЕБА.

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

В случае обновления строки в таблице «Кафедра» (например, изменении номера специальности) разумно допустить каскадирование, т.е. адекватное изменение этих же данных в таблице «Студент».

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

 

Задание 13. Настройте контроль целостности в схеме данных на каскадные обновление и удаление данных:

1) раскройте макет схемы данных по команде Сервис | Схема данных;

2) для редактирования связи «Кафедра»:«Студент» щелкните мышью по связи – раскроется окно «Изменение связей» (рис. 42);

3) в окне «Изменение связей» мышью «включите» настройку «Каскадное обновление связанных полей» и нажмите кнопку ОК (рис. 42);

4) для редактирования связи «Студент»:«Сессия» щелкните мышью по связи. Раскроется окно «Изменение связей» (рис. 43);

5) в окне «Изменение связей» мышью «включите» состояния «Каскадное обновление связанных полей» и «Каскадное удаление связанных полей»; нажмите экранную кнопку ОК (рис. 43);

Рис. 41. Настройка свойств связи «Кафедра»: «Студент»

6) сохраните результаты редактирования связей между таблицами по команде Файл | Сохранить;

Рис. 42. Настройка свойств связи «Студент»: «Сессия»

 

Задание 14. Выполните простейшие манипуляции с данными в условиях контроля целостности данных:

1) попробуйте добавить в сыновью таблицу «Студент» запрещенные данные. В окне БД на закладке Таблица выберите из списка таблицу «Студент» и нажмите экранную кнопку ;

2) добавьте вручную запись: «000000 Одинцов О.О. с0». При попытке сохранить некорректные данные появится диагностическое сообщение о невозможности ввода (рис. 44);

Рис. 43. Диагностическое сообщение о невозможности добавления записей

 

3) попробуйте теперь удалить из отцовской таблицы «Кафедра» запись, имеющую потомков в сыновьей таблице «Студент». В окне БД на закладке Таблица выберите из списка таблицу «Кафедра» и нажмите экранную кнопку ;

4) удалите запись «с1 ф1». При попытке удаления появится диагностическое сообщение о невозможности этой операции (рис. 45);

Рис. 44. Диагностическое сообщение о невозможности удаления связанных записей

 

5) попробуйте теперь изменить в отцовской таблице «Кафедра» запись, имеющую потомков в сыновней таблице «Студент»;

6) измените в таблице «Кафедра» номер специальности «c2» на «c4» в соответствующей записи;

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

8) попробуйте изменить в таблице «Студент» её независимые данные, например, «номер студента»;

9) измените в соответствующей строке «номер студента» (это Сергеева Н.Н.) «031512» на «040000» и сохраните результаты по команде Файл | Сохранить;

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

11) попробуйте удалить в таблице «Студент» хотя бы одну её запись.

В окне БД на закладке Таблица выберите из списка таблицу «Студент» и нажмите экранную кнопку ;

12) удалите запись о студенте Андрееве А.А. в таблице «Студент» в соответствующей строке и сохраните результаты по команде Файл | Сохранить;

13) посмотрите, как эта операция скажется на подчиненной таблице

«Сессия». В окне БД на закладке Таблица выберите из списка соответствующую таблицу и нажмите экранную кнопку . Зависимые записи (такая была одна о студенте Андрееве А.А. под номером 028101) должны исчезнуть. Должно произойти каскадное удаление данных в подчиненной таблице;

14) попробуйте добавить в таблицу «Сессия» некорректные данные. В окне БД на закладке «Таблица» выберите из списка таблицу «Сессия» и нажмите экранную кнопку ;

15) добавьте вручную запись: «000000 физика 2 3». При попытке сохранить некорректные данные появится диагностическое сообщение о невозможности ввода;

16) попробуйте удалить запись в таблице «Сессия» «031512 математика 1 5»;

17) убедитесь, что эта операция прошла без проблем.

 

ЗАКЛЮЧЕНИЕ

 

Собственно разработка структуры БД включает в себя:

1. Разработку структуры каждой таблицы, в том числе:

1) определение имен всех ее полей;

2) определение типов данных полей;

3) определение свойств полей;

4) определение ключевых полей.

2. Построение схемы базы данных, в том числе:

1) установление корректных связей между таблицами;

2) обеспечение контроля целостности связей;

3) установление правил целостности данных (запрет или разрешение каскадных преобразований).

Разработка структуры БД должна быть выполнена до наполнения ее

содержательной информацией.