Базы Данных - Сибилев, 2007
.pdf51
записей. Один из них состоит во включении в состав полей записи-потомка поля, ссылающегося на первичный ключ родительской записи. Оно называ-
ется в данном случае внешним ключом (Foreign Key, FK). Его значения явля-
ются ссылками на экземпляры родительской записи. В нашем примере поле
СТУДЕНТ.НомерГруппы – это внешний ключ, соответствующий первич-
ному ключу записи ГРУППА.
Тип записи СТУДЕНТ
НомерСтудбилета |
Фамилия |
Имя |
Отчество |
НомерГруппы |
Тип записи ГРУППА
НомерГруппы ГодНабора КодСпециальности
3.10 Представление метаданных
Метаданные, как и данные пользователей, сохраняются в таблицах.
Их называют иногда системными таблицами. Они составляют часть сис-
темного каталога. В них содержатся, в частности, описания полей и типов записей БД пользователя. Вот примеры структур системных таблиц СУБД
OS/2 EE.
Таблица SYSTABLES – сведения о таблицах БД пользователя
Столбец |
Тип данных |
Смысл |
|
|
NAME |
VARCHAR(18) |
Имя таблицы или представления |
||
CREATOR |
CHAR(18) |
Имя владельца |
|
|
TYPE |
CHAR(1) |
Тип: 'T' – таблица, 'V' – представление |
||
CTIME |
TIMESTAMP |
Дата/время создания таблицы |
||
REMARKS |
VARCHAR(254) |
Комментарии |
|
|
PACKED_DESC |
LONG |
Внутренняя форма описания таблицы |
||
|
VARCHAR |
|
|
|
VIEV_DESC |
LONG |
Внутренняя |
форма |
определения |
|
VARCHAR |
представления |
|
|
COLCOUNT |
SMALLINT |
Количество столбцов в таблице |
||
FID |
SMALLINT |
Внутренний идентификатор файла, в ко- |
||
|
|
тором хранятся данные таблицы |
||
TID |
SMALLINT |
Внутренний идентификатор таблицы |
||
CARD |
INTEGER |
Количество строк |
|
|
NPAGES |
INTEGER |
Число используемых страниц памяти |
||
FPAGES |
INTEGER |
Общее число страниц памяти файла |
|
|
52 |
Таблица SYSCOLUMNS – сведения о столбцах таблиц |
||
|
|
|
Столбец |
Тип данных |
Смысл |
|
|
|
NAME |
VARCHAR(18) |
Имя столбца |
|
|
|
TBNAME |
VARCHAR(18) |
Имя таблицы, содержащей столбец |
|
|
|
TBCREATOR |
CHAR(18) |
Имя владельца таблицы |
|
|
|
REMARKS |
VARCHAR(254) |
Комментарии |
|
|
|
COLTYPE |
CHAR(8) |
Тип данных столбца |
|
|
|
NULLS |
CHAR(1) |
'Y' – разрешены значения NULL; |
|
|
'N' – не разрешены |
|
|
|
CODEPAGE |
SMALLINT |
Набор символов IBM (для текстовых дан- |
|
|
ных) |
|
|
|
DBCSCODEPG |
SMALLINT |
Служебное поле |
|
|
|
LENGTH |
SMALLINT |
Максимальная длина столбца (в байтах) |
|
|
|
SCALE |
SMALLINT |
Степень в представлении числа (для чи- |
|
|
словых типов данных) |
|
|
|
COLNO |
SMALLINT |
Позиция столбца в таблице |
|
|
|
COLCARD |
INTEGER |
Число различных значений в столбце |
|
|
|
HIGH2KEY |
VARCHAR(16) |
Второе наибольшее значение в столбце |
|
|
|
LOW2KEY |
VARCHAR(16) |
Второе наименьшее значение в столбце |
|
|
|
AVGCOLLEN |
INTEGER |
Средняя длина столбца |
|
|
|
В подобных таблицах хранятся сведения об отношениях таблиц, ин-
дексах, хранимых процедурах, триггерах и других объектах БД пользова-
теля.
3.11 Индексы
Индекс – это служебная структура, сопоставленная базовой таблице.
Он поддерживает прямой доступ к записям по ключу (первичному, вто-
ричному) и последовательный просмотр записей в порядке возрастания или убывания значений ключа. Основной идеей индекса является хранение
упорядоченного списка значений ключа с привязкой к каждому значению
списка указателей — физических идентификаторов записей, содержащих это значение. Это избыточные данные, которые используются для улучше-
ния производительности системы и доступности БД.
53
Индексы бывают уникальными и неуникальными. Уникальные соз-
даются для полей, значения которых не могут дублироваться в сущест-
вующих записях таблицы. Неуникальные могут создаваться для любых других полей, если по их значениям нужно часто сортировать или от-
фильтровывать записи.
Пример.
В БД ВУЗа существует таблица СТУДЕНТ
НомерСтб |
Фамилия |
Имя |
Отчество |
Группа |
768954 |
Баков |
Борис |
Бенедиктович |
1562 |
456734 |
Даков |
Дмитрий |
Даниилович |
8971 |
768955 |
Гаков |
Гавриил |
Генрихович |
1562 |
768839 |
Лаков |
Леонтий |
Леонидович |
8972 |
456732 |
Заков |
Захар |
Зиновьевич |
8971 |
Таблице СТУДЕНТ обязательно сопоставлен уникальный индекс по первичному ключу НомерСтб. В нём с каждым значением индексируемо-
го поля связано одно значение указателя. Он может выглядеть так
НомерСтб |
Указатель |
456732 |
0271 |
456734 |
В129 |
768839 |
34Е0 |
768954 |
А16С |
768955 |
3478 |
Индекс упорядочен по значениям поискового поля. Если пользовате-
лю потребовалась запись таблицы СТУДЕНТ, содержащая в поле Но-
мерСтб значение 768955, то СУБД найдёт в индексе строку {768955, 3478} и по значению указателя получит из внешней памяти страницу, со-
держащую требуемую запись.
768955 |
Гаков |
Гавриил |
Генрихович |
1562 |
|
|
|
|
|
Эта процедура займёт гораздо меньше времени, чем потребовалось бы на поиск записи в файле.
Для той же таблицы может быть создан неуникальный индекс по по-
лю Группа. В нём с каждым значением индексируемого поля связан список
значений указателя. В нашем примере он будет выглядеть так
Группа |
Указатель |
1562 |
А16С, В129 |
|
54 |
|
|
|
|
8971 |
|
3478, 34Е0 |
8972 |
|
0271 |
Он обеспечивает быстрый отбор записей о студентах, обучающихся в одной группе. Если пользователю потребуется список студентов группы
8971, то СУБД считает из соответствующей строки индекса список указа-
телей и запросит у ОС соответствующие страницы внешней памяти.
Индексы бывают простыми (как в приведённых примерах), и состав-
ными. Составной индекс для базовой таблицы создаётся, если нужно вы-
полнять поиск и сортировку записей по наборам значений какой-то группы полей, например, по составным первичным или внешним ключам.
3.12 Целостность данных и ограничения целостности
Под целостностью данных понимается их корректность и полнота.
Только целостный набор данных адекватно отражает некоторое состояние предметной области, т.е., имеет осмысленную интерпретацию в терминах ПО. База данных действительно полезна, если её состояние в любой мо-
мент времени является целостным.
Осмысленный, интерпретируемый набор данных не может быть произвольным. Он подчиняется множеству правил, ограничивающих до-
пустимые значения элементов данных и свойства их отношений. В каждой предметной области этих правил очень много и они весьма разнообразны.
Они называются бизнес-правилами или деловым регламентом. Деловой регламент определяет ограничения целостности данных.
Эти ограничения должны поддерживаться независимо от способов хранения и обновления данных (бумага, компьютерная система). Это ос-
новная обязанность персонала, работающего с данными в оперативном режиме. Однако люди часто допускают ошибки и не всегда способны своевременно их обнаруживать. Было бы хорошо, если бы СУБД умела блокировать некорректные операции обновления.
Современные СУБД действительно могут поддерживать целостность данных в пределах «известных» им правил. Для этого правила нужно пред-
ставить формально, например, в виде предикатов, и сохранить как объекты
55
базы данных. Их называют разными именами: утверждения, предложе-
ния, триггеры БД, хранимые процедуры, процедуры БД. Независимо от на-
звания, все они отражают бизнес-правила и образуют в совокупности сис-
тему ограничений целостности данных.
При каждой попытке обновления состояния базы данных СУБД ав-
томатически проверяет, удовлетворяет ли новое состояние этим ограниче-
ниям. Если ограничения нарушены, то СУБД выполняет одно из двух пре-
допределённых действий:
−сообщает пользователю об ошибке и ждёт его реакции или
−автоматически устраняет рассогласования данных.
Например, согласно правилам ведения записей в регистратуре боль-
ницы, поле Пол таблицы БОЛЬНОЙ может принимать значения ‘Муж’
или ‘Жен’. Это правило должно быть описано предикатом:
Пол=’Муж’ or Пол=’Жен’
При попытке ввода значения в это поле СУБД запустит процедуру вычисления значения этого предиката на введённом значении пола. Если предикат принял значение ИСТИНА, то обновление принимается. В про-
тивном случае оно отвергается, а пользователь получает сообщение об ошибке
Обновлённое состояние БД фиксируется во внешней памяти системы только после того, как СУБД убедится в его корректности.
Заметим, что не любые правила, гарантирующие корректность дан-
ных, можно описать как ограничения целостности.
Например, следующие «записи о студентах» явно некорректны:
‘330120’ |
‘Свидригайлов’ |
‘Наталия’ |
‘Соломоновна’ |
3301 |
|
|
|
|
|
‘330111’ |
‘Глокая’ |
‘Куздра’ |
‘Бокровна’ |
3301 |
Однако для того, чтобы распознать ошибку в первой строке, система должна знать правила русского языка. В принципе, это возможно, но вряд ли согласуется со здравым смыслом. Во втором случае и это не поможет.
Нужно знать все существующие имена и фамилии.
56
И ещё одно замечание. Данные могут иметь вполне «благопристой-
ный» вид и удовлетворять всем правилам, но, тем не менее, быть ошибоч-
ными. Например, вторая запись вполне допустима на вид. Каких только имён не бывает в наши времена! Если К.Б. Глокая реально существует и действительно зачислена в группу 3301, то такая запись должна быть со-
хранена в БД. Ну, а если это тот самый легендарный «поручик Киже»,
ошибка писаря?… Опыт показывает, что, случайно попав в БД, К.Б. Глокая может просуществовать в ней вплоть до вручения диплома.
СУБД не в состоянии гарантировать истинность вводимых значений данных. Она может лишь гарантировать их соответствие заданным огра-
ничениям целостности. Поэтому когда говорят о целостности БД, имеют в виду именно соответствие её текущего состояния заданной совокупности ограничений целостности. Но, как показывает практика использования компьютерных технологий обработки данных, и это уже очень облегчает жизнь пользователей таких систем. Среди бизнес-правил немало таких, ко-
торые человеку поддерживать очень трудно.
Для СУБД состояние БД является целостным, тогда и только то-
гда, когда оно удовлетворяет всем ограничениям целостности.
Поэтому проектировщик БД должен стремиться выявить и предста-
вить в виде ограничений целостности все бизнес-правила, действующие в предметной области.
57
4 Организация обработки данных в СБД
4.1 Уровни представления данных (Архитектура ANSI/SPARC1)
БД и программные средства их создания и ведения (СУБД) имеют многоуровневое строение (см. рис. 10). Различают концептуальный, внут-
ренний и внешний уровни представления данных БД, которым соответст-
вуют одноимённые схемы (описания).
|
|
|
|
|
|
|
|
|
|
ПП1 |
|
ПП2 |
... |
ППn |
Прикладные программы |
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
УРОВНИ СУБД |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Внешний уровень |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Подсхемы |
|
|
|
|
|
|
|
|
|
|
|
ВМД1 |
|
ВМД2 |
... |
ВМДn |
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(Индивидуальные представления |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Отображения |
|
|
|
|
|
|
|
пользователей) |
||||||||||
|
|
|
|
|
|
|
||||||||||||
|
|
|
|
|
|
|
||||||||||||
ВМДi |
|
|
|
|
|
|
|
КМД |
|
|
|
|
|
|
|
|
Концептуальный уровень |
|
|
|
|
|
|
|
|
|
|||||||||||
|
|
|
|
|
|
|
|
|||||||||||
|
|
|
|
|
|
|
|
|
|
Концептуальная модель данных |
Концептуальная схема |
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
(КМД) |
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(обобщённое представление |
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
пользователей) |
Отображение |
|
|
|
|
|
|
||||||||||||
|
|
|
|
|
|
|
||||||||||||
КМД |
|
|
|
|
|
|
|
ВнМД |
|
|
|
|
|
|
Внутренний уровень |
|||
|
|
|
|
|
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Внутренняя модель данных |
||||||||
|
|
|
|
|
|
|
|
|
|
Внутренняя схема |
||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
(ВнМД) |
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(представление |
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
во внешней памяти) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
УРОВЕНЬ ОС
Физическая база данных
Рис. 4.1 Архитектура ANSI/SPARC
4.1.1 Концептуальный уровень
Центром архитектуры является концептуальный уровень. Он соот-
ветствует логическому представлению данных ПО в обобщённом виде без каких-либо ссылок на реализацию.
Концептуальная схема состоит из определений типов концептуаль-
ных записей, их связей, ограничений целостности данных, а так же опреде-
лений других типов объектов БД, о которых скажем позже. В состав кон-
1 ANSI – American National Standard Institute (Национальный институт стандартизации США), SPARC – Standards Planning and Requirement Committee (Комитет планирования стандартов и норм).
58
цептуальной записи входят только семантически значимые поля. Никаких служебных полей, видимых пользователю, в её структуре нет.
На концептуальном уровне представлена также семантическая ин-
формация о данных и сведения о мерах по обеспечению безопасности и поддержки целостности данных.
Определения концептуального уровня выполняются на ЯОД СУБД и сохраняются в таблицах системного каталога (раздел метаданных БД).
Пользователи всех категорий на любом этапе проектирования и эксплуата-
ции системы могут получать сведения о семантике и логической организа-
ции данных из этих таблиц. СУБД использует определения при обработке запросов пользователей. Таблицы системного каталога автоматически об-
новляются СУБД при внесении каких-либо изменений в концептуальную схему. Таким образом, и СУБД, и пользователи всегда располагают акту-
альной и целостной информацией о семантике и логической структуре хранимых данных.
Концептуальный уровень представления данных можно понимать как множество экземпляров концептуальных записей. Эти экземпляры фи-
зически не существуют. СУБД воспроизводит их из экземпляров внутрен-
них записей при обработке запросов пользователей.
4.1.2 Внутренний уровень
Внутренний уровень описывает организацию данных в среде хране-
ния и соответствует физическому представлению данных. Внутренняя схема состоит из определений типов внутренних (хранимых) записей, фай-
лов внешней памяти, индексов и других компонентов уровня реализации.
Эти определения выполняются на входном ЯВУ СУБД.
Все семантически значимые поля концептуальных записей представ-
лены на внутреннем уровне. Однако в общем случае между внутренними и концептуальными записями не существует соответствия «один к одному».
Различные поля одной и той же внутренней записи могут соответствовать полям нескольких концептуальных записей. И наоборот, различные поля
59
одной и той же концептуальной записи могут соответствовать полям раз-
личных внутренних (см. рис. 11). Могут различаться типы и длины соот-
ветственных полей. Внутренние записи кроме семантически значимых и системных полей содержат служебные поля, созданные разработчиками БД для своих целей.
Решения о составе и структуре внутренних записей принимают ис-
ходя из соображений эффективности обработки запросов. Они могут пере-
сматриваться в процессе эксплуатации системы. Однако в целом между концептуальной и внутренней схемами существует взаимно однозначное соответствие. Поэтому СУБД всегда может сформировать требуемый эк-
земпляр концептуальной записи из значений полей внутренних записей и наоборот.
Кроме схемы на внутреннем уровне представлена информация
–о распределении дискового пространства для хранения данных и индексов,
–о размещении файлов на физических носителях,
–о сжатии данных и методах шифрования.
Таким образом, множество экземпляров внутренних записей и есть база данных с «точки зрения» СУБД. Именно их она запрашивает у опера-
ционной системы.
4.1.3 Внешний уровень
Внешний уровень поддерживает частные представления данных, не-
обходимые конкретному пользователю. Каждая внешняя схема (подсхема)
является частью (подмножеством) концептуальной схемы или выводится из неё посредством однозначных преобразований.
Внешние записи формируются из полей концептуальных записей, но они представляют только те сущности, атрибуты и связи ПО, которые представляют интерес для конкретного КП. Этот КП может даже не подоз-
ревать о том, что в БД есть и другие сведения.
60
Различные внешние схемы могут по-разному отображать одни и те же данные. Внешние записи могут включать вычислимые и производные поля, не хранящиеся в БД как таковые. Поля различных концептуальных записей могут отображаться в одной внешней. Структуру и состав внеш-
них записей проектируют исходя из требований конечного пользователя.
Кроме внешних схем на этом уровне представлены определения форм, отчётов, запросов и другие компоненты приложений. С помощью внешних схем поддерживается интерфейс конечного пользователя и санк-
ционированный доступ к данным и приложениям.
Уровни представления данных связаны однозначными отображе-
ниями.
4.1.4 Отображения
Отображения определяют соответствия между представлениями верхнего и нижнего уровней. Отображение концептуальный ↔ внутрен-
ний (см. рис. 4.2) ставит в соответствие концептуальным полям и записям
хранимые. Это соответствие является взаимно однозначным. При измене-
нии структур хранения отображение концептуальный ↔ внутренний из-
меняется так, чтобы концептуальная схема осталась неизменной. Анало-
гично отображение внешний ↔ концептуальный ставит в соответствие концептуальным полям и записям внешние.
Концептуальная схема
Концептуальная запись 1 |
Концептуальная запись 2 |
Концептуальная запись 3 |
|||||||||||||
А1к |
B1к |
C1к |
D1к |
E1к |
F1к |
|
А2к |
B2к |
C2к |
D2к |
|
А3к |
B3к |
C3к |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
А1в |
B1в |
C1в |
D1в |
E1в |
F1в |
G1в |
H1в |
SF1 |
|
А2в |
B2в |
C2в |
D2в |
E2в |
SF2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Внутренняя запись 1 |
Внутренняя запись 2 |
Внутренняя схема
Служебные поля
Рис. 4.2 Отображение концептуальный ↔ внутренний