Базы Данных - Сибилев, 2007

51

записей. Один из них состоит во включении в состав полей записи-потомка поля, ссылающегося на первичный ключ родительской записи. Оно называ-

ется в данном случае внешним ключом (Foreign Key, FK). Его значения явля-

ются ссылками на экземпляры родительской записи. В нашем примере поле

СТУДЕНТ.НомерГруппы – это внешний ключ, соответствующий первич-

ному ключу записи ГРУППА.

Тип записи СТУДЕНТ

Тип записи ГРУППА

НомерГруппы ГодНабора КодСпециальности

3.10 Представление метаданных

Метаданные, как и данные пользователей, сохраняются в таблицах.

Их называют иногда системными таблицами. Они составляют часть сис-

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

OS/2 EE.

Таблица SYSTABLES – сведения о таблицах БД пользователя

В подобных таблицах хранятся сведения об отношениях таблиц, ин-

дексах, хранимых процедурах, триггерах и других объектах БД пользова-

теля.

3.11 Индексы

Индекс – это служебная структура, сопоставленная базовой таблице.

Он поддерживает прямой доступ к записям по ключу (первичному, вто-

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

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

списка указателей — физических идентификаторов записей, содержащих это значение. Это избыточные данные, которые используются для улучше-

ния производительности системы и доступности БД.

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

8971, то СУБД считает из соответствующей строки индекса список указа-

телей и запросит у ОС соответствующие страницы внешней памяти.

Индексы бывают простыми (как в приведённых примерах), и состав-

ными. Составной индекс для базовой таблицы создаётся, если нужно вы-

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

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

Под целостностью данных понимается их корректность и полнота.

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

мент времени является целостным.

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

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

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

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

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

Современные СУБД действительно могут поддерживать целостность данных в пределах «известных» им правил. Для этого правила нужно пред-

ставить формально, например, в виде предикатов, и сохранить как объекты

55

базы данных. Их называют разными именами: утверждения, предложе-

ния, триггеры БД, хранимые процедуры, процедуры БД. Независимо от на-

звания, все они отражают бизнес-правила и образуют в совокупности сис-

тему ограничений целостности данных.

При каждой попытке обновления состояния базы данных СУБД ав-

томатически проверяет, удовлетворяет ли новое состояние этим ограниче-

ниям. Если ограничения нарушены, то СУБД выполняет одно из двух пре-

допределённых действий:

−сообщает пользователю об ошибке и ждёт его реакции или

−автоматически устраняет рассогласования данных.

Например, согласно правилам ведения записей в регистратуре боль-

ницы, поле Пол таблицы БОЛЬНОЙ может принимать значения ‘Муж’

или ‘Жен’. Это правило должно быть описано предикатом:

Пол=’Муж’ or Пол=’Жен’

При попытке ввода значения в это поле СУБД запустит процедуру вычисления значения этого предиката на введённом значении пола. Если предикат принял значение ИСТИНА, то обновление принимается. В про-

тивном случае оно отвергается, а пользователь получает сообщение об ошибке

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

Заметим, что не любые правила, гарантирующие корректность дан-

ных, можно описать как ограничения целостности.

Например, следующие «записи о студентах» явно некорректны:

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

Нужно знать все существующие имена и фамилии.

56

И ещё одно замечание. Данные могут иметь вполне «благопристой-

ный» вид и удовлетворять всем правилам, но, тем не менее, быть ошибоч-

ными. Например, вторая запись вполне допустима на вид. Каких только имён не бывает в наши времена! Если К.Б. Глокая реально существует и действительно зачислена в группу 3301, то такая запись должна быть со-

хранена в БД. Ну, а если это тот самый легендарный «поручик Киже»,

ошибка писаря?… Опыт показывает, что, случайно попав в БД, К.Б. Глокая может просуществовать в ней вплоть до вручения диплома.

СУБД не в состоянии гарантировать истинность вводимых значений данных. Она может лишь гарантировать их соответствие заданным огра-

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

торые человеку поддерживать очень трудно.

Для СУБД состояние БД является целостным, тогда и только то-

гда, когда оно удовлетворяет всем ограничениям целостности.

Поэтому проектировщик БД должен стремиться выявить и предста-

вить в виде ограничений целостности все бизнес-правила, действующие в предметной области.

58

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

На концептуальном уровне представлена также семантическая ин-

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

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

Пользователи всех категорий на любом этапе проектирования и эксплуата-

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

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

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

альной и целостной информацией о семантике и логической структуре хранимых данных.

Концептуальный уровень представления данных можно понимать как множество экземпляров концептуальных записей. Эти экземпляры фи-

зически не существуют. СУБД воспроизводит их из экземпляров внутрен-

них записей при обработке запросов пользователей.

4.1.2 Внутренний уровень

Внутренний уровень описывает организацию данных в среде хране-

ния и соответствует физическому представлению данных. Внутренняя схема состоит из определений типов внутренних (хранимых) записей, фай-

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

Эти определения выполняются на входном ЯВУ СУБД.

Все семантически значимые поля концептуальных записей представ-

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

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

59

одной и той же концептуальной записи могут соответствовать полям раз-

личных внутренних (см. рис. 11). Могут различаться типы и длины соот-

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

Решения о составе и структуре внутренних записей принимают ис-

ходя из соображений эффективности обработки запросов. Они могут пере-

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

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

Кроме схемы на внутреннем уровне представлена информация

–о распределении дискового пространства для хранения данных и индексов,

–о размещении файлов на физических носителях,

–о сжатии данных и методах шифрования.

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

ционной системы.

4.1.3 Внешний уровень

Внешний уровень поддерживает частные представления данных, не-

обходимые конкретному пользователю. Каждая внешняя схема (подсхема)

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

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

ревать о том, что в БД есть и другие сведения.