МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ОБРАЗОВАНИЯ «САМАРСКИЙ ГОСУДАРСТВЕННЫЙ АЭРОКОСМИЧЕСКИЙ

УНИВЕРСИТЕТ имени академика С.П. КОРОЛЕВА (НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ)» (СГАУ)

Е.И. ЧИГАРИНА

БАЗЫ ДАННЫХ

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

С А М А Р А Издательство СГАУ

2015

2

УДК 004(075) ББК 32.97я7 Ч 586

Рецензенты: д-р техн. наук, проф.С.А. Пи я в с к и й ; канд. техн. наук, доц. Л.А. Жа р и н о в а ; канд. пед. наук, доц. М.В. Д о д о н о в

Чигарина Е.И. Ч586 Базы данных: учеб. пособие / Е.И. Чигарина. – Самара: Изд-

во СГАУ, 2015. – 208 с.

ISBN 978-5-7883-1031-2

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

Учебное пособие предназначено для студентов – бакалавров, обучающихся по очной форме по направлению 230100.62 Информати-ка и вычислительная техника по курсу «Базы данных», и подготовлено на кафедре информационных систем и технологий Самарского аэро-космического университета.

УДК 004(075) ББК 32.97я7

ISBN 978-5-7883-1031-2 © СГАУ, 2015

3

ОГЛАВЛЕНИЕ

Введение. ................................................................................................................ 5

Глава 1. Модели данных ................................................................................... 11 1.1. Уровни представления данных. Понятия схемы и подсхемы данных ............................................................................................................. 11 1.2. Модели концептуального уровня представления данных ................... 13 1.3. Модели данных логического уровня представления данных.............. 20 1.4. Методология IDEF1X построения логических моделей реляционных баз данных ............................................................................... 25 1.5. CASE-средства проектирования баз данных ........................................ 42

Глава 2. Теоретические основы реляционных баз данных ........................ 48 2.1. Основные понятия. Операции обновления и реляционной алгебры .. 48 2.2. Реляционное исчисление кортежей и доменов ..................................... 57 2.3. Языки манипулирования данными в реляционных системах ............. 59 2.4. Понятие ключа и функциональных зависимостей ............................... 61 2.5. Нормализация отношений. 1, 2, 3, 4, 5 нормальные формы отношений ....................................................................................................... 62 2.6. Описание формального алгоритма приведения отношений к третьей нормальной форме ......................................................................... 69 2.7. Пример анализа отношений базы данных на третью нормальную форму ........................................................................................ 74

Глава 3.Физическое проектирование баз данных ....................................... 77 3.1. Формат и размещение физических (хранимых) записей ..................... 77 3.2. Методы доступа к данным...................................................................... 82

Глава 4. Свойства баз данных ......................................................................... 93 4.1. Целостность данных................................................................................ 93 4.2. Свойство безопасности и секретности баз данных .............................. 94 4.3. Восстанавливаемость, согласованность и эффективность баз данных ....................................................................................................... 96 4.4. Реорганизация баз данных. Администратор баз данных. Словарь данных .............................................................................................. 97

Глава 5. Язык SQL. Стандарт языка SQL .................................................... 99 5.1. История SQL. История стандарта SQL. Уровни соответствия. Классы инструкций SQL ................................................................................ 99 5.2. Идентификаторы. Константы. Операторы. Типы данных. Ограничения ................................................................................................. 100 5.3. SQL – инструкции для работы со схемами ......................................... 104 5.4. SQL – инструкции для работы с данными .......................................... 106 5.5. SQL – инструкции для работы с сеансами .......................................... 109

4

5.6. SQL – инструкции для работы с транзакциями ................................. 110

Глава 6. Теоретические основы распределенных баз данных ................ 111 6.1. Основные понятия систем с распределенной обработкой данных .. 111 6.2. Изолированность пользователей в многопользовательских системах ........................................................................................................ 114 6.3. Сериализация транзакций. Методы сериализации транзакций ........ 117 6.4. Журнализация и буферизация изменений в базах данных ................ 125

Глава 7. Пример реализации распределённых баз данных. MS SQL Server .................................................................................................. 129

7.1. Основные характеристики MS SQL Server. Системные базы данных, таблицы и хранимые процедуры. Базы данных и файлы ........ 129 7.2. Таблицы баз данных. Создание, удаление, изменение ................... 138 7.3. Индексы баз данных .......................................................................... 139 7.4. Программирование на Transact SQL. Комментарии. Переменные. Команды управления ................................................................................ 141 7.5. Курсоры. Типы курсоров. Работа с курсорами ............................... 143 7.6. Правила, значения по умолчанию, представления ......................... 147 7.7. Хранимые процедуры и функции ..................................................... 154 7.8. Управление триггерами и транзакциями ......................................... 157 7.9. Диагностика и сбор данных. Оптимизация запросов ..................... 162 7.10. Удаленный доступ к данным .......................................................... 166

Глава 8. Администрирование баз данных на примере SQL Server ........ 170 8.1. Система безопасности. Аутентификация. Учетные записи и роли. Планирование разрешений .......................................................................... 170 8.2. Репликация данных. Типы репликаций .............................................. 175 8.3. Перемещение данных ........................................................................... 183 8.4. Резервное копирование и восстановление баз данных ...................... 187 8.5. Автоматизация решения административных задач. Система оповещений ................................................................................... 193

Заключение ....................................................................................................... 195

Приложение ...................................................................................................... 196

Список рекомендуемой литературы ............................................................ 207

5

ВВЕДЕНИЕ

Понятие баз данных. Виды баз данных. Средства реализации баз данных. Основные этапы создания баз данных.

Одной из самых распространенных сфер применения вычисли-тельной техники является создание различных автоматизированных систем. Среди них САПР (системы автоматизированного проектирова-ния), АСУ (автоматизированные системы управления), АИС (автома-тизированные информационные системы), АСНИ (автоматизирован-ные системы научных исследований) и другие. Главное отличие этих систем – вид автоматизируемой человеческой деятельности. В САПР осуществляется автоматизация проектирования, в АСУ – управления (причем системы автоматизированного управления технологическими процессами называются АСУ ТП, управления производством – АСУП), в АИС – хранения и поиска данных, в АСНИ – научно-экспериментальных исследований. В отличие от автоматических сис-тем, в автоматизированных системах часть функций выполняет чело-век и чаще всего это функции принятия решения.

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

6

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

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

В зависимости от способа хранения данных различают следую-щие виды баз данных:

1. Локальная база данных (централизованная) – база данных, хранящая данные в памяти одной вычислительной машины.

2. Распределенная база данных – база данных, хранящая данные в памяти различных ЭВМ вычислительной сети.

В зависимости от вида хранимой информации различают сле-дующие виды баз данных:

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

2. Динамические базы данных – базы данных, хранящие данные и время их внесения или изменения, отображающие состояние пред-метной области в определенный момент времени.

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

7

4. Графические базы данных – базы данных, хранящие инфор-мацию в виде графических объектов, например видеоданные, “puctoral date base”, “graphics based data base” и другие.

5. Интегрированные базы данных – базы данных, хранящие ин-формацию в виде данных, документов, графических объектов в любой комбинации.

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

Важным вопросом при работе с базами данных является вопрос выбора средства реализации баз данных. Можно выделить следующие виды основных средств реализации баз данных:

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

2. Система управления базами данных (СУБД) – средство реали-зации баз данных, выполняющее все функции файловой системы, функции создания и ведения базы данных как совокупности взаимо-связанных файлов, функции манипулирования данными. К функциям файловых систем относятся возможности создания, удаления, пере-именования, изменения структуры файлов баз данных. К функции ве-дения данных относятся операции добавления, удаления, изменения, просмотра данных. К функции манипулирования данными относятся операции сортировки данных, поиска, выборки, фильтрации данных.

3. Машины баз данных – программно-аппаратные средства реа-лизации баз данных. Машины баз данных не стали таким же массовым инструментом разработчика автоматизированных информационных систем, как СУБД. Это связано с тем, что машины баз данных, имея преимущество в быстродействии выполнения многих функций баз

8

данных, по сравнению с СУБД, так как многие функции реализуются аппаратно, тем не менее проигрывают в универсальности применения обычных персональных компьютеров. Машины баз данных позволяют преодолеть те ограничения производительности СУБД, которые вы-званы сложностью их архитектуры и выполняемых ими функций управления данными. Решение этой проблемы особенно актуально для создания систем распределенной обработки данных. Новое оборудова-ние повышает уровень надежности систем баз данных, позволяет раз-грузить универсальные ЭВМ и за счет этого обеспечить более эффек-тивное функционирование прикладных систем. В дальнейшем предполагается использование машин баз данных не только в качестве периферийного оборудования, но и в качестве самостоятельных про-цессоров – узлов сети ЭВМ. Использование машин баз данных будет способствовать прогрессу распределенных баз данных и систем баз знаний, а также прогрессу в работе с базами данных больших объемов. Следует отметить, что в настоящее время наиболее распространенным средством реализации баз данных являются СУБД.

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

К основным этапам проектирования баз данных относятся сле-дующие этапы:

1. Анализ предметной области и определение требований к базе данных.

2. Концептуальное (инфологическое) проектирование базы дан-ных.

3. Выбор средства реализации базы данных. 4. Логическое (датологическое) проектирование базы данных. 5. Физическое проектирование базы данных. При определении требований к базе данных выполняется оценка

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

9

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

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

Задача логического этапа проектирования баз данных – органи-зация данных в виде структур данных или выбор и построение модели данных логического уровня представления данных.

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

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

База знаний – это не только совокупность данных, но и совокуп-ность знаний и набора правил вывода новых знаний. Аналогом СУБД для баз данных является понятие экспертной системы для баз знаний. Экспертные системы – это управляющая система, интерпретирующая правила вывода при работе с базами знаний.

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

Система баз данных – автоматизированная система хранения и обработки данных, то есть фактически это определение автоматизи-

10

рованной информационной системы и банка данных. В настоящее время системы баз данных делят на системы оперативной (иногда называют операционной) обработки данных или системы OLTP (OnLine Transaction Processing), а также системы аналитической об-работки данных или OLAP (OnLine Analytikal Processing). Цели этих систем и модели представления данных в таких системах существен-но отличаются. В данном учебном пособии будут рассмотрены сис-темы баз данных OLTP.

11

Глава 1. МОДЕЛИ ДАННЫХ

1.1. Уровни представления данных. Понятия схемы и подсхемы данных

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

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

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

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

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

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

12

ления данных. Это связано с тем, что в настоящее время при разра-ботке баз данных в основном используются реляционные или объ-ектно-реляционные модели данных и этапы концептуального и ло-гического проектирования реляционных баз данных совмещены. Отсюда все современные CASE-средства проектирования баз дан-ных позволяют строить логические и физические модели баз данных (см. раздел 1.5).

На каждом уровне представления данных имеются различные модели представления данных. Фактически синонимом понятия моде-ли данных является понятие схемы базы данных.

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

Внешний уровень Представление1 Представление2…… Представление n

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

При описании базы данных возможно наличие нескольких

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

13

ных, описание представления о данных отдельного пользователя или приложения.

1.2. Модели концептуального уровня представления данных

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

Наибольшее распространение получила семантическая модель данных типа «сущность – связь» (модель Entity – Relation, ER – мо-дель, модель Чена), предложенная впервые Ченом. Основными абст-рактными понятиями этой модели являются понятия сущности, экзем-пляра сущности, атрибута и связи.

Сущность – реальный или мыслимый объект предметной облас-ти. Сущность характеризуется свойствами – атрибутами. Каждая сущность состоит из множества экземпляров сущности. Например, сущность «студент» имеет экземпляры сущности – сведения о кон-кретных студентах. Фамилия и номер зачётной книжки студента – это характеристики или атрибуты сущности «студент».

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

1:1 – связь один к одному между сущностями. Связь «один к одному» между сущностями устанавливается, если каждому экземп-ляру одной сущности соответствует только один экземпляр другой сущности.

1:M (или М:1) – связь один ко многим (или многие к одному). Связь «один ко многим» между сущностями устанавливается, если ка-ждому экземпляру одной сущности соответствует несколько экземпля-ров другой сущности.

M: N – связь многие ко многим. Связь «многие ко многим» меж-ду сущностями устанавливается, если каждому экземпляру одной сущ-ности соответствует несколько экземпляров другой сущности и наобо-рот.

14

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

На диаграммах Бахмана для описания модели сущность-связь используются следующие графические примитивы:

или

имя сущности - сущность (множество экземпляров сущности)

имя связи

- имя атрибута 1имя сущности

- описание связи между сущностями

или или S1 S, где 1 - тип связи

- имя атрибута n- описание атрибутов сущности

1

N

1:N

...

Например, дано описание следующей предметной области: в го-роде имеется несколько предприятий, на каждом из которых работают сотрудники. Сотрудники характеризуются должностью, фамилией, именем, отчеством (ФИО), окладом, возрастом, адресом. Предприятие характеризуется названием, числом сотрудников, ФИО директора. Ка-ждый сотрудник может работать на одном предприятии, на одном предприятии работают несколько сотрудников.

Описание модели средствами диаграммы Бахмана представлено на рисунке 1.1.

15

Предприятие

Сотрудник

Адрес

Название предприятия

Адрес предприятия

включает/работает наявляется директором

ВозрастОкладДолжностьФИО сотрудника

Число сотрудников

ФИО директора

Рисунок 1.1 – Пример диаграммы Бахмана модели сущность-связь

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

16

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

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

- представление сущности

- представление атрибута

- наименование связи

- представление связи типа 1:1- представление связи типа 1:М- представление связи типа :N M

Имяатрибута

Имясвязи

Имя сущности

17

Рассмотренный ранее пример на диаграмме Чена представлен на рисунке 1.2.

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

ФИОдиректора

Названиепредприятия

Адреспредприятия

Числосотрудников

Предприятие

являетсядиректором включаетработает на

Оклад

Адрес

Сотрудник

Должность

Возраст

ФИОсотрудника

Рисунок 1.2 – Пример диаграммы Чена модели сущность-связь

18

Ту или иную форму графического представления модели сущ-ность-связь выбирает проектировщик базы данных, но обязательно на любой диаграмме модели должны присутствовать сущности, атрибуты, при этом ключевые атрибуты выделены, показаны связи с указанием имен и мощностей. В настоящее время кроме приведенных диаграмм для описания моделей сущность-связь используются методологии, ис-пользуемые в CASE-средствах проектирования баз данных, рассмот-ренные в разделах 1.4 и 1.5 пособия.

Альтернативой модели сущность-связь, используемой на кон-цептуальном уровне представления данных, является модель Смита или семантическая иерархическая модель (SHM-модель, Semantik Hierarchic Model). Подход Смита предполагает использование мно-жества понятий (концепций, абстракций), которые должны быть ин-тегрированы в иерархическую структуру. Каждое из таких понятий имеет отличное от других значение, смысл которого понятен проек-тировщику.

В качестве элементарных форм абстракции Смит использует обобщение и агрегацию. Обобщение – объединение однородных эле-ментов или объединение классов однородных элементов. Агрегация – объединение разнородных понятий. Например, объект автомобиль характеризуется маркой, номером, цветом кузова. Здесь можно ска-зать, что автомобиль агрегирует разнородные понятия – марку, цвет, номер, которые не имеют между собой ничего общего, кроме того, что они относятся к характеристикам автомобиля. В случае рассмот-рения объекта линия можно сказать, что к линиям относятся окруж-ность, прямая, эллипс. Линия имеет свойства, присущие и прямой, и окружности, и эллипсу, в то же время последние понятия имеют свои собственные, отличные от других свойства. То есть можно сказать, что понятие линия обобщает такие геометрические фигуры, как ок-ружность, эллипс и другие.

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

19

индивидуальные отличия. В обобщении наблюдается наследование свойств.

Агрегация и обобщение не являются взаимоисключающими ка-тегориями. Агрегатный объект может быть обобщением некоторого класса объектов и наоборот. Но может быть такая ситуация, когда не-которые компоненты объекта или его категории не представляют ин-тереса и тогда они не отображаются в концептуальной модели. Объект называется первичным, если ни компоненты, ни категории объекта не представляют интереса. Если несколько раз последовательно приме-нить к некоторым объектам обобщение или агрегацию, образуется ие-рархия объектов. В SHM-модели различают иерархии агрегаций и обобщений. В иерархии агрегаций все связи имеют тип 1:1. На рисунке 1.3 приведен пример иерархии обобщения.

Транспорт

воздушный речной железнодорожный

Рисунок 1.3 – Пример иерархии обобщения в SHM-модели

На рисунке 1.4 приведен пример иерархии агрегации.

Автомобиль

ФИОвладельца

марка номергосрегистрации

год выпуска

Рисунок 1.4 – Пример иерархии агрегации в SHM-модели

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

20

блока в виде объединения иерархий агрегаций и обобщения. В этом случае агрегации размещаются в плоскости страницы, а обобщенные понятия – в перпендикулярной плоскости или вводятся обозначения на связи. Связь типа ребра обобщения называется «является» и обознача-ется ISA; ребро иерархии агрегации – «является частью» помечается PART OF. На рисунке 1.5 приведен пример иерархии абстракций.

По сравнению с моделью сущность-связь SHM–модель более на-глядна, так как иерархия всегда более ясна по сравнению с сетью или графом. Но не каждая предметная область может быть описана с по-мощью одной иерархии, для связей «многие ко многим» приходится строить несколько иерархий. В настоящее время при проектировании баз данных в основном используются модели сущность-связь.

Транспорт

воздушный речной железнодорожный

ISA

самолет вертолет марка тип двигателя

тип двигателя взлетно-посадочнаяхарактеристика

тип винтовой системы

ISA PART OF

PART OFPART OF

Рисунок 1.5 – Пример иерархии абстракций в SHM модели

1.3. Модели данных логического уровня представления данных

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

21

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

Личность

Студент NСтудент 2Студент 1 . . . Служащий NСлужащий 1 . . .

фио 1 . . . фио 2 . . . фио N . . .

Рисунок 1.6 – Пример иерархической модели данных Реализация связей типа «многие ко многим» на иерархических

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

S1

А1 А2 А3

S2

А1 А3

А1

S1 S2

А3

S1 S2

А2

S1

Рисунок 1.7 – Дублирование информации при реализации связей «многие ко многим» на иерархической модели

22

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

Примерами современных СУБД, реализующих иерархическую модель данных, являются СУБД семейства IMS и System.

Сетевая модель логического уровня представляется в виде гра-фа, возможно имеющего циклы и петли. В узлах графа могут нахо-диться сущности, экземпляры сущностей, атрибуты, значения атрибу-тов. Ребрами графа являются связи между объектами графа. Модель типа “сущность – связь” лучше всего трансформируется именно на се-тевую модель данных. Наиболее развитая сетевая модель данных – это модель, созданная рабочей группой по базам данных (КОДАСИЛ). Эта модель состоит из множества сущностей, которые могут быть владель-цами или членами наборов данных.

Примером СУБД, реализующей сетевую модель данных КОДА-СИЛ, является СУБД db_VISTA. Эта СУБД предназначена для созда-ния и использования базы данных сложной структуры в рамках раз-личных программных систем, реализованных на языке “С”.

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

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

23

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

Наглядное

представлениеКонцептуальный

уровеньЛогическийуровень

Физическийуровень

Таблица Сущность Отношение Файл===

Строка Экземпляр сущности Кортеж Запись

Столбец Атрибут Подмножество домена Поле

Рисунок 1.8 – Соответствие понятий реляционной модели на различных уровнях представления данных

Определение отношения, кортежа и домена будут даны в разделе

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

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

Примерами СУБД, поддерживающими реляционную модель данных, являются FoxPro, Clipper, Paradox и многие другие.

24

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

Примером СУБД, реализующей постреляционную модель дан-ных, является СУБД UniVerse.

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

Примерами СУБД, реализующих объектную модель данных, можно назвать СУБД O2, ORION, GemStone, Iris. Распространенную СУБД ORACLE иногда называют объектно-реляционной.

25

1.4. Методология IDEF1X построения логических моделей реляционных баз данных

Методология IDEF1X была разработана и широко используется в государственных учреждениях США, финансовых и промышленных корпорациях при разработке реляционных баз данных. Эта методоло-гия входит в общую методологию проектирования автоматизирован-ных систем IDEF, в основе которой лежит структурный системный анализ. В нашей стране в настоящее время методология IDEF1X, реа-лизующая двухуровневую архитектуру представления данных, наибо-лее часто используется для построения логических моделей реляцион-ных баз данных. В нотации этой методологии используется диаграмма модели сущность-связь. Она включает сущности и взаимосвязи, отра-жающие основные бизнес-правила предметной области.

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

В IDEF1X различают зависимые и независимые сущности. Тип сущности определяется её связью с другими сущностями. Независимая сущность может находиться на модели вне связи с другими сущностя-ми и не требует дополнительных атрибутов, относящихся к другим сущностям. Независимая сущность обозначается на модели графиче-

26

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

Имя независимой

сущностиИмя независимой

сущности

Имя независимой сущности

Имена первичныхключевых атрибутовили или

Имена первичныхключевых атрибутов

Имена атрибутов

Рисунок 1.9 – Обозначения независимой сущности в методологии IDEF1X Зависимая сущность всегда связана с другой сущностью, одной

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

Имя зависимойсущности

Имя зависимой сущности

Имя зависимойсущности

Имена первичныхключевых атрибутов

Имена первичныхключевых атрибутов

Имена атрибутов

или

или

Рисунок 1.10 – Обозначения зависимой сущности в методологии IDEF1X

27

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

Характеристическая зависимая сущность – это зависимая до-черняя сущность, которая связана только с одной родительской и по смыслу хранит информацию о характеристиках родительской сущно-сти. На рисунке 1.11 приведен пример характеристической зависимой сущности «Хобби».

Сотрудник Хобби

Рисунок 1.11 – Пример характеристической зависимой сущности «Хобби»

Ассоциативная зависимая сущность – сущность, связанная с не-

сколькими родительскими сущностями. Такая сущность содержит ин-формацию о связях сущностей. Пример ассоциативной зависимой сущности «Врач_Пациент» приведен на рисунке 1.12.

Категориальная зависимая сущность – дочерняя сущность в ие-рархии наследования. Пример категориальных зависимых сущностей «Постоянный сотрудник» и «Совместитель» показан на рисунке 1.17.

Врач

Номер врача

Врач - Пациент Пациент

Номер пациентаНомер врача Номер пациента

Рисунок 1.12 – Пример ассоциативной зависимой сущности «Врач–Пациент»

В нотации IDEF1X различают связи идентифицирующие, не-

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

28

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

Идентифицирующая

связьНеидентифицирующая

связьКатегориальная

связь

Рисунок 1.13 – Обозначения видов связей в нотации IDEF1X

При установлении идентифицирующей связи атрибуты первич-ного ключа родительской сущности автоматически переносятся в со-став первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется мигра-цией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ – (FK). Впоследствии, при физической генерации схемы базы данных, внешний ключ, мигрирующий в область первичных клю-чей, получит признак NO NULL. На рисунке 1.14 показаны пример ус-тановления идентифицирующей связи между сущностями и миграция атрибутов.

Клиент

Номер клиента

Заказ

Номер заказаНомер клиента (FK)

Сумма заказаДата отгрузкиДата заказа

Имя клиентаАдрес клиента

размещает

Рисунок 1.14 – Идентифицирующая связь между зависимой и независимой сущностями

29

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

Отдел

Номер отдела

Сотрудник

Табельный номер

ФИОАдресНомер отдела ( К)F

Рисунок 1.15 – Неидентифицирующая связь с признаком NOT NULL для внешнего ключа

Атрибут «Номер отдела», автоматически мигрирующий в об-

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

Отдел

Номер отдела

Сотрудник

Табельный номер

ФИОАдресНомер отдела ( К)F

Рисунок 1.16 – Неидентифицирующая связь с признаком NULLS для внешнего ключа

30

Теперь рассмотрим категориальные связи, участвующие в ие-рархии наследования сущностей. Иерархия наследования (или иерар-хия категорий) представляет собой особый тип объединения сущно-стей, которые имеют общие характеристики. Например, в организации работают служащие, занятые полный рабочий день (по-стоянные служащие), и совместители. Из их общих свойств можно сформировать обобщенную сущность (родовой предок) «Сотрудник» (рисунок 1.17), чтобы представить информацию, общую для всех ти-пов служащих. Специфическая для каждого типа информация может быть расположена в категориальных сущностях (потомках) «Посто-янный сотрудник» и «Совместитель». Обычно иерархию наследова-ния создают, когда сущности имеют общие по смыслу связи (напри-мер, если бы «Постоянный сотрудник» и «Совместитель» имели бы сходную по смыслу связь «работает в» с сущностью Организация). Для каждой категории указывается дискриминатор – атрибут родово-го предка, который показывает, как отличить одну категориальную сущность от другой.

ФИОАдрес

Сотрудник

Табельный номер

Табельный номер (FK)Табельный номер (FK)

Оклад Процент ставки

СовместительПостоянный сотрудник

Рисунок 1.17 – Иерархия наследования. Неполная категория

Иерархии категорий делятся на два типа – полные и неполные. В

полной категории одному экземпляру родового предка (сущность

31

«Служащий», рис.1.18) обязательно соответствует экземпляр в каком-либо потомке, то есть в примере служащий обязательно является либо совместителем, либо консультантом, либо постоянным сотрудником. Если категория еще не выстроена полностью и в родовом предке могут существовать экземпляры, которые не имеют соответствующих экзем-пляров в потомках, то такая категория будет неполной. На рисунке 1.17 показана неполная категория – сотрудник может быть не только постоянным или совместителем, но и консультантом, однако сущность «Консультант» еще не внесена в иерархию наследования.

ФИОАдрес

Сотрудник

Табельный номер

СовместительПостоянный сотрудник Консультант

Табельный номер (FK)

Оклад Процент ставки

Табельный номер (FK) Табельный номер (FK)

ДатаРазмер выплат

Рисунок 1.18 – Иерархия наследования. Полная категория

Возможна комбинация полной и неполной категорий. На рисун-

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

Как уже отмечалось ранее, при рассмотрении модели сущ-ность-связь важным понятием для любой связи является понятие мощности связи. Мощность связи (Cardinality) – служит для обозна-чения отношения числа экземпляра родительской сущности к числу экземпляров дочерней. В нотации IDEF1X различают четыре типа мощности (рис. 1.20):

1) общий случай, когда одному экземпляру родительской сущ-ности соответствует 0,1 или много экземпляров дочерней сущности. На связи не помечается каким-либо символом;

32

2) символом P помечается случай, когда одному экземпляру родительской сущности соответствует 1 или много экземп-ляров дочерней сущности (исключено нулевое значение);

3) символом Z помечается случай, когда одному экземпляру родительской сущности соответствует 0 или 1 экземпляр дочерней сущности (исключены множественнные значения);

4) цифрой помечается случай точного соответствия, когда од-ному экземпляру родительской сущности соответствует за-ранее заданное число экземпляров дочерней сущности.

Сотрудник

Штатный

Мужчина Женщина

Рисунок 1.19 – Иерархия наследования.

Комбинация полной и неполной категорий

0,1 или много

1 или много

0 или 1

точно (5)N

Р

Z

5

Рисунок 1.20 – Обозначения мощности

33

На рисунке 1.20 показано обозначение мощности для идентифи-цирующей связи. Аналогично, только для пунктирной линии, вводится значение мощности для неидентифицирующей связи. Мощность для категориальной связи не указывается, так как по смыслу категория связь имеет значение 0 или 1, то есть Z.

Важным для описания модели сущность-связь является указание наименования связи. Имя связи (Verb Phrase) – фраза, характеризую-щая отношение между родительской и дочерней сущностями. Для свя-зи один ко многим идентифицирующей или неидентифицирующей достаточно указать имя, характеризующее отношение от родительской к дочерней (Pfrent-to-Child). Для связи многие ко многим следует ука-зывать имена как Parent-to-Child и Child-to-Parent.

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

Отдел Сотрудник

Номер отдела

Название отдела

Табельный номер Где работает. Номер отдела )(FK

ФИОРуководит. табельный номер (FK)

Руководит / подчиняется

состоит из

Рисунок 1.21 – Имена ролей внешних ключей В примере, приведенном на данном рисунке, в сущности «Со-

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

34

Номер валюты

Валюта Продажа валюты

Проданная. Номер валюты )(FK

Купленная. Номер валюты )(FKНазвание валюты

продается

покупается

Рисунок 1.22 – Случай обязательности имен ролей На рисунке 1.22 сущность Продажа валюты содержит инфор-

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

Другим примером обязательности присвоения имен ролей яв-ляются рекурсивные связи (иногда их называют «рыболовный крю-чок» – fish hook), когда одна и та же сущность является и родитель-ской и дочерней одновременно. При задании рекурсивной связи атрибут должен мигрировать в качестве внешнего ключа в состав не-ключевых атрибутов той же сущности. Атрибут не может появиться дважды в одной сущности под одним именем, поэтому обязательно должен получить имя роли. На рисунке 1.21 сущность «Сотрудник» содержит атрибут первичного ключа Табельный номер. Информация о руководителе сотрудника содержится в той же сущности, поскольку руководитель работает в той же организации. Чтобы сослаться на ру-ководителя сотрудника, следует создать рекурсивную связь (на рисун-ке связь руководит/подчиняется) и присвоить имя роли («Руководи-тель»). Причем рекурсивная связь может быть только неидентифицирующей. В противном случае внешний ключ должен был бы войти в состав первичного ключа и получить при генерации

35

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

Связь руководит/подчиняется на рисунке 1.21 позволяет хра-нить древовидную иерархию подчиненности сотрудников. Такой вид рекурсивной связи называется иерархической рекурсией (hierarchical recursion) и задает связь, когда руководитель (экземпляр родитель-ской сущности) может иметь множество подчиненных (экземпляров дочерней сущности). Но подчиненный имеет только одного руково-дителя (рис. 1.23)

Иерархическая рекурсия Сетевая рекурсия

Рисунок 1.23 – Подчиненность экземпляров сущности в иерархической и сетевой рекурсии

Другим видом рекурсии является сетевая рекурсия (network re-

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

36

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

Номер валюты

Родственник Родственное отношение

Младший. Номер родственника )(FKСтарший. Номер родственника )(FKТип отношения

Рисунок 1.24 – Пример реализации сетевой рекурсии Если атрибут мигрирует в качестве внешнего ключа более чем на

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

Связь многие ко многим возможна только на уровне концепту-альной модели данных. На рисунке 1.26 показан пример связи многие ко многим. Врач может принимать много пациентов, пациент может лечиться у нескольких врачей. Такая связь обозначается сплошной ли-нией с двумя точками на концах.

37

Номер команды

Команда Игрок

В какой команде играет. Номер команды )(FK

Номер игрокаНазвание команды

Имя игрока

Гол

Дата/время голаНомер игрока (ЕК)В какой команде играет (ЕК)

Рисунок 1.25 – Миграция имен ключей

принимает

Врач

Номер врача

Пациент

лечитсяНомер пациента

Рисунок 1.26 – Связь «многие ко многим» Связь многие ко многим должна именоваться двумя фразами – в

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

Важными понятиями в IDEF1X являются понятие ключа и раз-личные типы ключей.

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

Первичный ключ (Primary key) – это атрибут или группа атри-бутов, однозначно идентифицирующих экземпляры сущности. Атри-

38

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

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

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

Например, рассмотрим кандидатов на первичный ключ сущности Сотрудник. Здесь можно выделить следующие потенциальные ключи:

Табельный номер. Номер паспорта. Фамилия + Имя + Отчество.

Для того чтобы стать первичным, потенциальный ключ должен удовлетворять ряду требований: Уникальность. Два экземпляра не должны иметь одинаковых значений возможного ключа. Потенциаль-ный ключ Фамилия+Имя+Отчество является плохим кандидатом, по-скольку в организации могут работать полные тезки. Компактность. Сложный возможный ключ не должен содержать ни одного атрибута, удаление которого не приводило бы к утрате уникальности. Для обес-печения уникальности ключа Фамилия+Имя+Отчество дополним его атрибутами Дата рождения и Цвет волос, а ключ Фами-лия+Имя+Отчество+Дата рождения+Цвет волос не является компакт-ным.

При выборе первичного ключа предпочтение должно отдаваться более простым ключам, то есть в нашем примере это либо Табельный номер, либо номер паспорта.

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

39

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

Значение атрибутов ключа не должно меняться в течение всего времени существования экземпляра сущности. Сотрудница организа-ции может выйти замуж и сменить как фамилию, так и паспорт. По-этому ключи Номер паспорта и Фамилия+Имя+Отчество не выбраны в качестве первичного ключа.

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

При работе информационной системы часто бывает необходимо обеспечить доступ к нескольким экземплярам сущности, объединен-ным каким-либо одним признаком. Для повышения производительно-сти в этом случае используются неуникальные индексы. Атрибуты, участвующие в неуникальных индексах, по которым будет осуществ-ляться выборка данных, называются инверсионными входами (Inversion Entry). Инверсионные входы – это атрибут или группа атрибутов, кото-рые не определяют экземпляр сущности уникальным образом, но часто используются для обращения к экземплярам сущности.

На диаграмме атрибуты альтернативных ключей обозначаются как (AKn.m), где n – порядковый номер ключа, m – порядковый номер атрибута в ключе. Когда альтернативный ключ содержит несколько атрибутов, (AKn.m) ставится после каждого.

На рисунке 1.27 атрибуты Фамилия, Имя, Отчество и Дата ро-ждения входят в альтернативный ключ № 1 (AK1), Номер паспорта составляет альтернативный ключ № 2 (AK2). Инверсионные входы обозначаются как (IEn.m), где n – порядковый номер входа, m – поряд-ковый номер атрибута. Инверсионный вход IE1 (атрибут Должность) позволяет выбрать всех сотрудников, занимающих одинаковую долж-

40

ность, IE2 (атрибуты Город и Улица) – всех сотрудников, живущих на одной улице, IE3 (атрибут Номер комнаты) – всех сотрудников, рабо-тающих в одной комнате, а IE4 (атрибут Дата рождения) – всех со-трудников, родившихся в один день.

Отдел

Номер отдела

Сотрудник

Табельный номер

Название отдела Фамилия (АК1.1)Имя (АК1.2)Отчество (АК1.3)Номер отдела ( )Номер паспорта (АК2)Дата рождения (АК1.4, Е4)Должность ( Е4)Номер комнаты ( Е3)Город ( Е2.1)Улица ( Е2.2)Дом

FK

II

III

Рисунок 1.27 – Сущность «Сотрудник» с отображением ключей Если один атрибут входит в состав нескольких ключей, ключи

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

Внешние ключи (Foreign Key) создают автоматически, когда связь соединяет сущности. Связь образует ссылку на атрибуты пер-вичного ключа в дочерней сущности, и эти атрибуты образуют внеш-ний ключ в дочерней сущности (миграция ключа). Атрибут внешнего ключа обозначается символом (FK) после своего имени (см. рисунок 1.27). Атрибут внешнего ключа Номер отдела является атрибутом первичного ключа (PK) сущности Отдел.

41

Рассмотрим пример описания предметной области для проекти-рования базы данных: государственная автоинспекция города Самары ведет учет транспортных средств, учет владельцев транспортных средств и нарушений, которые совершаются владельцами транспорт-ных средств, находящимися за рулем своей автомашины. Транспорт-ное средство характеризуется государственным номером, мощностью двигателя, маркой, датой выпуска. Владелец транспортного средства характеризуется номером паспорта, ФИО владельца, адресом с указа-нием района проживания, телефонами (сотовым, рабочим и/или до-машним). Нарушение характеризуется номером протокола, местом на-

Адрес Владелец Телефон

Код адреса (FK)

ФИО владельцаКод типателефона (FK)

Номер протоколаучаствует

Код типа нарушения

учитывается в

Район

Тип телефона

Код адреса

Номер района (FK)

УлицаДомКвартира

Номер паспорта (FK)Номер телефона

Код типа телефона

Название телефона

Номер района

Название района

учитывается вимеет

имеет1принадлежит

Номер паспорта

Транспортноесредство

Мощность двигателяМаркаДата выпуска

Р

Номер паспорта (FK)Гос_номер

совершает

Нарушение_Тр_средства

Нарушение

Место нарушенияДата нарушения

Номер паспорта (FK)Гос_номер (FK)Номер протокола

Код типа нарушения (FK)

Р

Учитывается в

Тип нарушения

Название типа нарушения

Рисунок 1.28 – Полная атрибутивная логическая модель базы данных «ГИБДД»

42

рушения, типом нарушения, датой. На рисунке 1.28 описана полная атрибутивная логическая модель базы данных в терминах методологии IDEF1X. Для обеспечения целостности данных введены сущности «Тип нарушения», «Район», «Тип телефона» которые являются спра-вочниками и позволяют сократить возможные ошибки при наборе ин-формации введением возможности выбора из справочников нужных значений, а также использованием одного и того же значения справоч-ника многократно для разных сущностей.

Кроме нотации IDEF1X распространенной в настоящее время является и нотация IE. На рисунке 1.29 приведено соответствие графи-ческих примитивов связей в обеих нотациях.

IE

1

z

p

p

IDEFIX

Рисунок 1.29 – Соответствие графических примитивов связей нотаций IDEF1X и IE для моделей «сущность-связь»

1.5. CASE-средства проектирования баз данных

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

43

фической технике: для описания различного рода моделей использу-ются схемы и диаграммы. Для автоматизации этой технологии в настоящее время используются программно-технологические средства специального класса – CASE-средства, реализующие CASE-технологию создания и сопровождения информационных систем. Тер-мин CASE (Computer Aided Software Engineering) используется в на-стоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения, в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных автомати-зированных систем в целом.

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

Классификация по типам включает следующие основные CASE-средства:

1) средства анализа, предназначенные для построения и анализа моделей предметной области (Bpwin, Design/IDEF);

2) средства анализа и проектирования, предназначенные для соз-дания проектных спецификаций (CASE.Аналитик, Vantage Team Build-er, Designer/2000, Silverrun, PRO-IV);

3) средства проектирования баз данных, обеспечивающие моде-лирование данных и генерацию схем баз данных для наиболее распро-страненных СУБД (Silverrun, Vantage Team Builder, Designer/2000, ERwin, S-Designor);

44

4) средства разработки приложений и генераторы кодов (Vantage Team Builder, Silverrun, PRO-IV);

5) средства реинжениринга, обеспечивающие анализ программ-ных кодов, схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем баз дан-ных входят в состав: (Silverrun, Vantage Team Builder, Designer/2000, Erwin, S-Designor). Для анализа программных кодов используются та-кие средства, как Rational Rose и Object Team.

В контексте данного учебного пособия наиболее интересны CASE-средства, используемые при проектировании баз данных, пере-численные в пункте 3.

CASE-средство Silverrun американской фирмы Computer Systems Advisers (CSA) используется для анализа и проектирования информа-ционных систем бизнес-класса и ориентировано, в большей степени, на спиральную модель жизненного цикла. Оно применимо для поддержки любой методологии, основанной на раздельном построении функцио-нальной и информационной моделей (диаграмм потоков данных и диа-грамм «сущность-связь»). Silverrun имеет модульную структуру и со-стоит из четырех модулей, каждый из которых является самостоятельным продуктом. Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных (BMP – Business Process Modeler) позволяет моделировать функционирование обследуемой ор-ганизации или создаваемой информационной системы. Модуль кон-цептуального моделирования данных (ERX – Entity-Relationship eXpert) обеспечивает построение моделей данных «сущность-связь», не привязанных к конкретной реализации. Модуль реляционного мо-делирования (RDM – Relational Data Modeler) позволяет создавать де-тализированные модели «сущность-связь», предназначенные для реа-лизации в реляционной базе данных. Менеджер репозитория рабочей группы (WRM – Workgroup Repository Manager) применяется как сло-варь данных для хранения общей для всех моделей информации, а также обеспечивает интеграцию модулей Silverrun в единую среду проектирования. Для автоматической генерации схем баз данных у Silverrun существуют мосты к наиболее распространенным СУБД: Or-acle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase. Для

45

передачи данных в средства разработки приложений имеются мосты к языкам 4GL: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Del-phi. Система Silverrun реализована на трех платформах – MS Windows, Macintosh, OS/2 Presentation Manager – с возможностью обмена про-ектными данными между ними.

Vantage Team Builder представляет собой интегрированный про-граммный продукт, ориентированный на реализацию каскадной моде-ли жизненного цикла программного обеспечения. Vantage Team Builder обеспечивает выполнение следующих функций: 1) проектирование диаграмм потоков данных, «сущность-связь», структур данных, струк-турных схем программ и последовательностей экранных форм; 2) ге-нерацию кода программ на языке 4GL целевой СУБД с полным обес-печением программной среды и генерация SQL-кода для создания таблиц баз данных, индексов, ограничений целостности и хранимых процедур; 3) программирование на языке C со встроенным SQL; 4) управление версиями и конфигурацией проекта; 5) генерация про-ектной документации по стандартным и индивидуальным шаблонам; 6) экспорт и импорт данных проекта. Vantage Team Builder поставляет-ся в различных конфигурациях в зависимости от используемых СУБД (Oracle, Informix, Sybase, Ingress) или средств разработки приложений (Uniface).

CASE-средство Designer/2000 фирмы Oracle является интегриро-ванным CASE-средством, обеспечивающим в совокупности со средст-вами разработки приложений Developer/2000, поддержку полного жиз-ненного цикла программного обеспечения для систем, использующих СУБД Oracle. В состав Designer/2000 входят следующие компоненты: 1) Repository Administrator – средства управления репозиторием (соз-дание, удаление приложений, управление доступом к данным со сто-роны различных пользователей, экспорт и импорт данных); 2) Reposi-tory Object Navigator – средства доступа к репозиторию, обеспечивающие многооконный объектно-ориентированный интер-фейс доступа ко всем элементам репозитория; 3) Process Modeller – средство анализа и моделирования деловой деятельности, основываю-щиеся на концепциях реинжениринга бизнес-процессов и глобальной системы управления качеством; 4) Systems Modeller – набор средств

46

построения функциональных и информационных моделей проекти-руемой информационной системы, включающий средства для по-строения диаграмм «сущность-связь», диаграмм функциональных ие-рархий, диаграмм потоков данных и средство анализа и модификации связей объектов репозитория различных типов; 5) Systems Designer – набор средств проектирования информационных систем, включающий средство построения структуры реляционной базы данных, а также средства построения диаграмм, отображающих взаимодействие с дан-ными, иерархию, структуру и логику приложений, реализуемую хра-нимыми процедурами на языке SQL; 6) Server Generator – генератор описаний объектов базы данных Oracle (таблиц, индексов, ключей, по-следовательностей и т.д.). Помимо продуктов Oracle, генерация и ре-инжиниринг баз данных может выполняться для СУБД Informix, DB/2,Microsoft SQL Server, Sybase,а также для баз данных, доступ к которым реализуется посредством ODBC; 7) Forms Generator – генера-тор приложения, включающий в себя различные экранные формы, средства контроля данных, проверки ограничений целостности и авто-матические подсказки; 8) Repository Reports – генератор стандартных отчетов. Среда функционирования Designer/2000 – Windows 3.x, Win-dows 95, Windows NT.

Erwin – средство логического моделирования баз данных, ис-пользующее методологию IDEF1X. Erwin реализует проектирование схемы баз данных, генерацию её описания на языке целевой СУБД (Oracle, Informix, DB/2, Ingres, Progress, SQL Server, SQLBase, Sybase и др.) и реинжениринг существующей базы данных. Erwin выпускается в нескольких различных конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Версия Er-win/Open полностью совместима со средствами разработки приложе-ний PowerBuilder и SQLWindows и позволяет экспортировать описание спроектированной базы данных непосредственно в репозитории дан-ных средств.

S –Designor представляет собой CASE – средство для проектиро-вания реляционных баз данных. S –Designor реализует стандартную методологию моделирования данных и генерирует описание баз дан-ных для таких СУБД, как Oracle, Informix, DB/2, Ingres, Progress, SQL

47

Server, SQLBase, Sybase и др. Для существующих систем выполняется реинжениринг баз данных.

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

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

48

Глава 2. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ

2.1. Основные понятия. Операции обновления и реляционной алгебры

Основоположником теории реляционных баз данных является американский ученый Кодд. Ниже приведены основные понятия этой теории.

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

Отношение R – это множество упорядоченных наборов данных (кортежей), являющихся подмножеством декартового произведения доменов (домены необязательно различные). Кортежи обозначаются перечислением значений доменов, заключенных в угловые скобки. Домены обозначаются заглавной латинской буквой D. Отсюда отно-шение R D1 D2 D3 … Dn. Почему в определении отношения говорится о подмножестве доменов? Рассмотрим отношение «Сту-дент» (рисунок 2.1), включающее два атрибута «Имя» и «Возраст».

Рисунок 2.1 – Отношение «Студент»

ИМЯ (домен символьных строк D1

длиной меньше 15)

ВОЗРАСТ (домен целых чисел D2)

Галя 17 Ира 18 Света 19

49

Операция декартового произведения кортежей включает множе-ство кортежей вида: D1 D2 = Галя, 17, Галя, 18, Галя, 19 … Света, 19 . На самом деле имени соответствует один возраст, то есть R D1 D2. С другой стороны, не всё множество значений домена используется в отношении, что также подтверждает определение от-ношения как подмножества декартового произведения домены.

Схема отношения – это перечень имён атрибутов отношения. Обозначается схема как R (A1, A2, …, An), где Ai – номера или имена атрибутов. Для примера отношения «Студент» схема имеет вид R(Имя, Возраст) или R(A1,A2), где A1=Имя, A2=Возраст.

Мощность отношения – число кортежей отношения. Для отно-шения «Студент» мощность равна трем.

Степень отношения – число атрибутов отношения. Для отноше-ния «Студент» степень равна двум.

Каждое отношение должно удовлетворять следующим требова-ниям:

1) отношение имеет фиксированное число и расположение атри-бутов;

2) отношение имеет конечное множество кортежей; 3) в отношении не может быть одинаковых кортежей. Всё множество операций над отношениями можно разделить на

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

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

Пусть имеется отношение R(A1,A2,…,An). Операция добавления кортежа в это отношение выглядит следующим образом:

ADD(R; A1=d1, A2=d2, …,An=dn) или ADD(R; d1,d2,…,dn),

где di, i=1,2,…,n – компоненты добавляемого кортежа <d1,d2,…,dn>. При выполнении операции добавления возможно возникновение

следующих ошибочных ситуаций: 1) добавляемый кортеж не соответствует схеме указанного от-

ношения;

50

2) некоторые значения кортежа не принадлежат соответст-вующим доменам;

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

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

Операция удаления кортежа из отношения записывается в виде DEL(R; A1=d1, A2=d2, …,An=dn) или DEL(R; d1,d2,…dn),

где di, i=1,2,…,n – компоненты удаляемого кортежа <d1,d2,…,dn> . Для удаления кортежа можно указать только значения ключевых

атрибутов:

DEL(R; B1=l1, B2=l2, …,Bn=ln) или DEL(R; l1,l2,…,ln),

где kBBB ,...,, 21 – перечень ключевых атрибутов,

lj nddd ,..., 21 -значения ключевых атрибутов (j=1,2,…,k).

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

CH(R; A1=d1, A2=d2, …,An=dn; C1=e1,C2=e2,…,Cp=ep). Операция изменения может быть выполнена с помощью после-

довательности операций удаления и добавления, поэтому ошибочные ситуации этих операций присущи и операции изменения.

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

51

1. Операция объединения отношений R=R1 R2, выполняется над совместимыми отношениями. В результирующее отношение вхо-дят кортежи первого и второго отношений. Повторяющиеся кортежи не включаются. На рисунке 2.2 показан пример выполнения операции объединения.

R1: Группа 634 (приклад-

ная математика) R2: Группа 633 (физи-

ка) Фамилия Возраст Фамилия Возраст Раудин 19 Гашников 19 Кайрис 18 Дюмина 18 Осин 19 Москаленко 19

Осин 19 R1 R2

Фамилия Возраст Гашников 19 Дюмина 18

Москаленко 19 Осин 19 Раудин 19 Кайрис 18

Рисунок 2.2 – Операция объединения отношений

2. Операция пересечения над отношениями R= R1 R2 также

выполняется над совместимыми отношениями. В итоговое отношение включаются кортежи, принадлежащие как первому, так и второму от-ношениям. На рисунке 2.3 показан результат выполнения операции пересечения.

. Фамилия Возраст Осин 19

Рисунок 2.3 – Результат выполнения операции пересечения

R= R1 R2

R= R1 R2

52

3. Операция разности над отношениями R=R1\R2 (или R1-R2), выполняется над совместимыми отношениями. В результирующее от-ношение включаются только те кортежи первого отношения, которых нет во втором отношении. На рисунке 2.4 показан результат операции разности отношений

Фио Возраст

Раудин 19 Кайрис 18

Рисунок 2.4 – Результат выполнения операции разности R=R1-R2

4. Операция декартового произведения R = R1 R2. Здесь R1 и

R2 могут иметь разные схемы. Степень отношения R равна сумме степеней отношений R1 и R2. Мощность отношения R равна произ-ведению мощностей отношений R1 и R2. На рисунке 2.5 показан пример выполнения операции декартового произведения над отно-шениями.

5. Операция деление над отношениями R = R1:R2. Отношение-делимое R1 должно содержать в качестве подмножества множество атрибутов отношения делителя. Частное R содержит только те атрибу-ты делимого, которых нет в делителе. В отношение-частное включены только те кортежи, декартовое произведение которых с отношением-делителем содержатся в отношении-делимом.

a

a

a

z

y

x

R

1

1

2

1

b

aF

12

11

12

11

12

11

baz

aaz

bay

aay

bax

aax

FR

Рисунок 2.5 – Пример выполнения операции декартового произведения над отношениями

53

На рисунке 2.6 показан пример выполнения операции деления над отношениями.

R1 R2 Фамилия Пред-

мет Оценка Предмет Оценка

Иванов Иванов Петров Петров Сидоров Сидоров

Оит Физика Оит

Физика Оит

Физика

5 5 4 4 5 4

Оит Физика

5 4

Фамилия R=R1:R2 Сидоров

Рисунок 2.6 – Пример выполнения операции деления над отношениями

Следующие операции характерны только для отношений. 6. Операция проекции на некоторые атрибуты – это операция

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

121 ,...,, RiiiR r ,

где i1,…,ir – номера или имена атрибутов отношения R1, входящих в результирующее отношение. На рисунке 2.7 приведен пример выпол-нения операции проекции над отношением R, со схемой R(фамилия, предмет, оценка).

Проекция )1(3,2)1(, RRоценкапредметR

Фамилия Предмет Оценка Предмет Оценка Иванов Иванов Петров Петров

Оит Физика Оит

Физика

5 5 5 4

Оит Физика Физика

5 4 4

Рисунок 2.7 – Пример выполнения операции проекции над отношением R

54

7. Операция соединение является двухместной операцией, то есть выполняется над двумя отношениями. В каждом отношении вы-деляется атрибут, по которому будет производиться соединение. Эта операция отличается от декартового произведения тем, что комбини-руются лишь те кортежи отношений, у которых значения совпадаю-щих атрибутов равны. Обозначается эта операция следующим обра-зом:R=R1►◄R2. На рисунке 2.8 приведен пример выполнения операции соединения отношений R1 и R2 по атрибуту «Код студента».

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

R1 R2

Специальность Код студента Код студента Фамилия Курс Математика Физика Оит

1 2 3

1 2 3

Иванов Петров Сидоров

1 2 3

R=R1►◄R2

Специальность Код

студента Фамилия Курс

Математика Физика

1 2

Иванов Петров

1 1

Рисунок 2.8 – Пример выполнения операции внутреннего соединения отношений

В результате выполнения операции правого внешнего соединения

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

55

при этом кортежи с неизвестными значениями поля соединения запол-няются значениями Null (рисунок 2.10).

Специальность Код студента Фамилия Курс Математика 1 Иванов 1 Физика 2 Петров 1 Оит 3 Null Null

Рисунок 2.9 – Пример выполнения операции левого внешнего соединения отношений

Специальность Код студента Фамилия Курс Математика 1 Иванов 1 Физика 2 Петров 1

Null 4 Сидоров 3

Рисунок 2.10 – Пример выполнения операции правого внешнего соединения отношений

В результате выполнения операции полного соединения двух

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

Специальность Код

студента Фамилия Курс

Математика 1 Иванов 1 Физика 2 Петров 1 Оит 3 Null Null Null 4 Сидоров 3

Рисунок 2.11 – Пример выполнения операции

полного соединения отношений

56

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

8. Операция селекции является операцией над несколькими от-ношениями. Результирующее отношение содержит подмножество кор-тежей, выбранных по некоторому условию:

1,...,F nR R R ,

где F – формула, включающая: 1) имена атрибутов и константы различных типов; 2) логические операции и кванторы всеобщности: , , , , ;

3) арифметические операции и операции сравнения: , ,<,>,=, ;

4) скобки. Например, дано отношение R1:

Фамилия Оценка Предмет Иванов 5 Оит Иванов 5 Физика Петров 5 Оит

R= )( 1)()4( Rоитпредметоценка – отношение, включающее два кор-

тежа: <Иванов,5,Оит>,<Петров, 5, Оит >. Современные языки манипулирования данными в реляционных

базах данных включают команду Select, название которой совпадает с

57

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

9. Операция перемены местами позиций Rji создает но-

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

10. Операция расширения исходного отношения атрибутом. По-следние две операции позволяют изменять структуру отношения.

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

2.2. Реляционное исчисление кортежей и доменов

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

)(|)( xfRx ,

где f-формула, выражающая некоторый предикат над переменной-кортежем x . Результат этого выражения есть отношение r(R),которое состоит из всех кортежей t(R), для которых f(t) истинно.

Минимальные строительные блоки для формул называют атома-ми. Атомы бывают следующих типов:

1) атом x R или R(x), где x – кортеж отношения R;

58

2) атом S(i) U(j), где S и U – переменные-кортежи; – опера-тор сравнения; i, j – номера или имена атрибутов в соответ-ствующих кортежах;

3) атом S(i) а или, а S(i), где, а – константа, S – перемен-ная-кортеж; – оператор сравнения; i – номер или имя ат-рибута в соответствующем кортеже;

4) операции: сравнения ( , ,<,>,=, ), кванторы всеобщности

( , ), логические операции( .,, );

5) скобки. В реляционном исчислении с переменными-кортежами справед-

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

Реляционное исчисление доменов напоминает реляционное ис-числение кортежей, за тем исключением, что переменные этого исчис-ления являются переменными значениями из доменов, а не перемен-ными-кортежами. Выражение исчисления доменов имеет вид

| ,1 1 2 2 1( ) ( )... ( ) ,...,k

n n nfx A x A x A x x

где f – формула, обладающая тем свойством, что ее переменные явля-ются переменными значениями из доменов. Формула состоит из сле-дующих атомов:

1) атом R(a1,…,ak), где ia – либо переменная исчисления до-

менов, либо постоянная из домена, с помощью которого за-дается атрибут;

2) атом x y , где x, y – константы или переменные на домене; – оператор сравнения;

59

3) формула использует кванторы x;x и логические операции , , ;

4) скобки. В реляционном исчислении с переменными на доменах справед-

ливы следующие утверждения: 1. Для каждого безопасного выражения реляционного исчис-

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

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

2.3. Языки манипулирования данными в реляционных системах

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

1. На основе реляционной алгебры фирмой IBM был разработан язык ISBL(Information System Base Language). Выражения этого языка строятся с помощью операций, соответствующих операциям реляци-онной алгебры или их обобщениям. Например, объединение, пересече-ние, соединение и выбор обозначаются соответственно:

RF;;; (R : F).

Результат вычисления любого выражения языка ISBL может быть присвоен некоторому отношению, либо напечатан с помощью ключевого слова list.

2. Реляционное исчисление кортежей послужило основой для создания языка QUEL(QUEry Language), разработанного в универси-тете шт. Калифорния. Все переменные языка неявно связаны кванто-ром существования, и область определения каждой из них ограниче-

60

на одним из отношений. Объявление переменной и её привязка к оп-ределенному отношению производится с помощью оператора сле-дующего вида:

range of <переменная> is <имя отношения>

Основной формой оператора запроса в QUEL является:

retrieve (<целевой список>) where <условие>,

где условию соответствует формула исчисления кортежей. Целевой список представляет собой последовательность компонент перемен-ных, напоминающую ту часть выражения в исчислении доменов, что расположена слева от вертикальной черты. Результат запроса можно присвоить некоторому отношению, если после ключевого слова re-trieve написать into <отношение>.

3. Слабость языка QUEL заключается в том, что он использует для исчисления кортежей только кванторы существования. Это послу-жило причиной роста популярности другого языка, основанного на полном исчислении кортежей и частично реляционной алгебре – язык SQL. Язык SQL был разработан в научно-исследовательской лаборато-рии фирмы IBM в Сан-Хосе (шт. Калифорния). Основной операцией в SQL служит отображение, представляющее собой композицию огра-ничения предикатом и проекции. В простейшем случае отображение выражается синтаксической конструкцией вида

select <список атрибутов> from <отношение> where <условие>.

4. Реляционное исчисление доменов стало основой для создания языка QBE(Query-By-Example) – реляционного языка манипулирова-ния данными, разработанного Злуфом из Уотсоновского исследова-тельского центра фирмы IBM. Язык QBE обладает двумерным синтак-сисом. Запрос формулируется путём заполнения табличной формы,

61

содержащей имя отношения и имена атрибутов схемы. Строки запроса имеют вид

Имя

отношения Имя

атрибута 1 ….

Имя атрибута n

операция Примером СУБД, реализующей язык QBE, является Paradox. Каждый из рассмотренных языков обладает своими особенно-

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

2.4. Понятие ключа и функциональных зависимостей

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

Атрибут В функционально зависит от атрибута А (А В), ес-ли для каждого значения атрибута А существует ровно одно, связанное с ним значение атрибута В. А и В могут быть составными атрибутами. Атрибут называется составным, если он включает множество атрибу-тов отношения.

62

Если А = А1А2…Ак и А В, то есть В функционально зависит от всей группы атрибутов А, то говорят, что В функционально полно зави-сит от А.

Если А = А1А2…Ак и Аi…Аj В и i, j < k, то между А и В имеет-ся частичная функциональная зависимость.

Если А В, то А и В взаимозависимые атрибуты. Взаимозависимость также может быть полной и частичной. Если для атрибутов А, В и С выполняется условие А В и В С,

но обратной связи нет, то говорят, что С транзитно зависит от А. Атрибут В многозначно зависит от А, А В, если каждому

значению А соответствует множество значений В, никак не связанных с другими атрибутами отношения.

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

2.5. Нормализация отношений. 1, 2, 3, 4, 5 нормальные формы отношений

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

Аппарат нормализации отношений разработан Коддом. В нем определены различные нормальные формы отношений. Каждая нор-мальная форма ограничивает типы допустимых функциональных зави-симостей отношений. Кодд выделил три нормальные формы: 1, 2, 3НФ, а сегодня определены 4НФ, 5НФ.

63

Следует отметить, что нормализация или иначе декомпозиция должна быть обратимой, то есть выполняться без потерь информации. Вопрос о том, происходит ли утрата информации при декомпозиции, тесно связан с концепцией функциональной зависимости. В качестве примера рассмотрим отношение поставщик (номер поставщика, статус поставщика, город проживания поставщика). В отношении 2 корте-жа:(«S1, 30, Париж», «S2, 30, Лондон»). Выполним 2 варианта деком-позиции исходного отношения: а) R1(номер, статус), R2(номер, город); б) R1(номер, статус), R2(статус, город). Первая декомпозиция получи-лась без потерь, а другая с потерей информации. Операция декомпози-ции выполнялась путём применения дважды операции проекции к исходному отношению. В случае а) при обратном соединении полу-ченных отношений получается исходное отношение. В случае б) при соединении полученных отношений исходное отношение не получает-ся, а значит некоторая информация утрачена. Это произошло из-за по-тери одной функциональной зависимости (ФЗ), присутствующей в ис-ходном отношении. Действительно, в исходном отношении имеются следующие ФЗ: номер → статус и номер → город. В случае а) обе функциональные зависимости сохраняются, в б) вторая ФЗ потеряна, в результате чего при выполнении операции соединения R1 и R2 про-изойдет потеря информации, так как неизвестно, в каком городе про-живают поставщики с одинаковыми статусами, но разными номерами. Зависимость между декомпозицией без потерь ФЗ подтверждается теоремой Хеза.

Теорема Хеза: Пусть R(A,B,C) является отношением с атрибута-ми A,B,C. Если оно удовлетворяет зависимости A → B, то R равно со-единению его проекций (A,B) и (A,C).

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

2НФ – отношение находится во второй нормальной форме, если оно находится в первой нормальной форме и отсутствуют частичные функциональные зависимости атрибутов, не входящих в ключ от клю-ча (зависимости атрибутов, не входящих в ключ от части ключа). Ина-че можно сказать, если каждый атрибут, не входящий в ключ, функ-

64

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

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

Поставщик Товар Цена Иванов Мыло 2000 Иванов Сахар 2500 Петров Мыло 2000 Петров Сыр 20000

В отношении имеется один составной ключ: Поставщик, то-

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

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

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

3. Аномалия обновления: изменилась цена товара, надо полно-стью посмотреть всё отношение, чтобы найти все поставки товара, чтобы изменение цены было отражено для всех поставщиков. То есть изменение значения одного объекта приводит к необходимости изме-нения в нескольких кортежах, иначе база будет несогласованной.

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

65

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

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

Для рассмотренного примера в результате нормализации полу-чим отношения R1 (поставщик, товар) и R2 (товар, цена). Отношение R1 имеет кортежи:<Иванов, мыло >, <Иванов, сахар>, <Петров, мыло >, <Петров, сыр>; отношение R2 имеет кортежи: <мыло,2000>, <сахар, 2500>, <сыр, 20000>. Анализируя возможность работы с базой данных «Поставки», при наличии двух отношений, видно, что можно добавить сведения о товаре и его цене до того, как кто-то начинает поставлять этот товар, сведения о товаре и его цене хранятся в базе один раз. То есть избыточность хранения устранена, аномалии устранены, кроме этого декомпозиция выполнена без потери информации.

3НФ – отношение находится в третьей нормальной форме, если оно находится во второй нормальной форме, и отсутствуют транзитив-ные зависимости атрибутов, не входящих в ключ от ключа. Иными словами, если выполняется совокупность условий:

A → B; В → С; С → А; В → А; С → B,

66

тогда в отношении существует транзитивная зависимость атрибутов, не входящих в ключ от ключа A, и отношение не находится в третьей нормальной форме. Если хотя бы одно из условий не выполняется, то такой зависимости между атрибутами A,B,C нет. Причем атрибуты A,B,C могут быть составными.

Рассмотрим пример отношения «Хранение» с информацией о наименовании фирмы, о наименовании складов, принадлежащих фир-мам, и объеме продукции на складах, причем каждая фирма получает товары с одного склада, склад определяется объемом. Таблица «Хра-нение» выглядит следующим образом:

Фирма Склад Объем

МЕНАТЕП МКЧ 200 ИКС ДП 600 АСКО ДП 600 ПАРУС СК 200

В данном отношении имеется один атомарный ключ <фирма>.

Выполняются следующие функциональные зависимости: фирма склад;склад объем, объем фирма;склад фир-ма; объем склад.

По определению, это отношение не находится в 3 НФ, в резуль-тате чего возникают избыточность хранения информации (если не-сколько фирм хранят товар на складе, то в данном отношении несколь-ко раз повторяется информация об объеме склада) и аномалии:

Аномалия включения. Если надо ввести объем склада, а нет фир-мы, получающей товар со склада, то добавление невозможно.

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

Аномалия обновления. Если объем склада изменился, то надо просмотреть всё отношение и изменить все кортежи для фирм, связан-ных с этим складом, а это неэффективно.

67

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

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

Для рассмотренного примера выполнение правила приведения к третьей нормальной форме приведет к замене исходного отношения на два следующих отношения: R1(фирма, склад); R2(склад, объем). Такое разбиение является разбиением без потери информации. Если бы мы выполнили декомпозицию таким образом: R1(фирма, склад); R2(фирма, объем), то при соединении этих отношений было бы непонятно, к ка-кому складу относится фирма, если склад имеет одинаковый объем, то есть происходит потеря информации.

4НФ – отношение находится в четвертой нормальной форме, если оно находится в третьей нормальной форме и в нем отсутствуют независимые многозначные функциональные зависимости.

Рассмотрим пример отношения «Преподаватель»:

Номер преподавателя

Дети преподавателя

Шифр курса

1 Ира Математика 1 Вася Математика 1 Коля Физика 2 Петя Математика

В отношении имеются один составной ключ <номер преподава-

теля, дети преподавателя, шифр курса> и многозначные функциональ-ные зависимости:

68

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

В результате нормализации получим: R1(номер преподавателя, дети); R2(номер преподавателя, шифр курса).

В отношениях со многими многозначными зависимостями 4НФ может не устранять избыточности, а вместе с тем и аномалий обновле-ния. Тогда применяется 5НФ.

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

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

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

69

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

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

В следующем пункте рассмотрен формальный алгоритм приве-дения отношения к третьей нормальной форме на примере некоторого отношения.

2.6. Описание формального алгоритма приведения отношений к третьей нормальной форме

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

70

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

1 2 3 4 5 6

21 12 53 12 14 25 12 17

15 21 35 21 14 52 12 17

7 6

27 6 7

12 6 8

13 12 9

14 15 12 16 17

21 13 24 15 27 14 11 10

3 3

13 3 3 6 3 4

Рисунок 2.12 – Пример описания отношения R для демонстрации формального алгоритма приведения к третьей нормальной форме

Используя метод классификации, по каждому отдельному столб-

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

1 2 3 4 5 6 1 2 3 2 4 5 2 6

1 2 3 2 4 5 6 7

1 2 3 2 1 4 2 5

1 2 3 4 5 2 6 7

1 2 3 4 5 6 7 8

1 1 2 1 1 3 1 4

Рисунок 2.13 – Вид отношения R после применения метода классификации

71

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

Для этого определяем по значениям отдельных атрибутов (столбцов) или совокупности атрибутов (столбцов) наличие таких ат-рибутов, у которых все значения не повторяются, то есть уникальные в пределах атрибута отношения. Как видно из рисунка 2.13, такими ключевыми атрибутами являются следующие атомарные и составные ключи: <5>,<1,4>,<2,4>,<3,4>,<4,6>.

Так как в отношении имеются составные ключи, то, возможно, это отношение не находится во второй нормальной форме. Начиная с первого составного ключа, проверяем наличие частичных функцио-нальных зависимостей. У составного ключа <1,4> имеются две части – атрибуты 1 и 4. От части ключа могут зависеть атрибуты, не являю-щиеся ключами и не входящие с данным атрибутом в ключ для остав-шихся составных ключей. Анализ наличия функциональной зависимо-сти от атрибута 1 нужно выполнить для атрибутов 2,3,6. Определение функциональной зависимости дано в пункте 1.4. Как видно от атрибута 1 функционально зависят 3 и 6: 1→3, 1→6. Раз имеются зависимости от части ключа, то отношение не находится во второй нормальной форме. После приведения к 2НФ по правилу, получим два отношения R1(1,3,6) и R2(1,2,4,5). Оба этих отношения показаны на рисунке 2.14. Следует заметить, что повторяющиеся кортежи удалены, это необхо-димо сделать, так как по определению в отношении не допускаются одинаковые кортежи.

После этого шага для каждого из полученных отношений алго-ритм повторяется, начиная с определения ключевых атрибутов. Снача-ла рассмотрим отношение R1. В этом отношении имеется один ато-марный ключ <1>. Так как отсутствуют составные ключи, то отношение находится во второй нормальной форме. Выполним анализ на третью нормальную форму. В данном случае ключевой атрибут A –

72

это атрибут <1>. Для этого отношения выполняются соотношения: 1→3, 3→6, 6 -/->1, 6-/->3, 3-/->1.

R1(1,3,6) R(1,2,4,5)

1 3 6 1 2 4 5 1 2 3 4 5 6

1 2 3 1 4 5

1 1 2 1 3 4

1 2 3 2 4 5

1 2 3 2 4 5

1 2 3 4 5 2

1 2 3 4 5 6

2 6

6 7

6 7

7 7

Рисунок 2.14 – После приведения

ко второй нормальной форме отношения R

Наличие перечисленных функциональных зависимостей показы-вает, что в отношении имеется транзитивная зависимость атрибутов, не являющихся ключом, от ключа и, значит, отношение не находится в третьей нормальной форме. Применение правила нормализации для третьей нормальной формы приводит к возникновению двух отноше-ний R3 и R4 со следующими схемами R3(3,6), R4(1,3), показанными на рисунке 2.15.

R3(3,6) R4(1,3)

3 6 1 3 1 2 3 4 5

1 1 2 3 4

1 2 3 4 5

1 2 3 4 5

2 6

6 7

Рисунок 2.15 – Схемы отношений после нормализации отношения R1

73

Полученные отношения R3 и R4 в третьей нормальной форме. Для анализа отношения на вторую нормальную форму в отношении должен быть как минимум один составной ключ из двух атрибутов и атрибут, не входящий в ключ, то есть не менее трех атрибутов. Для анализа на третью нормальную форму также в отношении должно быть не менее трех атрибутов, это следует из определения транзитив-ной функциональной зависимости.

Теперь проверим на наличие нормальных форм отношение R2(1,2,4,5). В этом отношении имеется следующий состав ключей: <5>,<1,4>,<2,4>. При определении состава ключей в данном случае, когда после нормализации не удалялись кортежи отношения, можно не анализировать значения атрибутов отношения, а оставить из списка ключевых атрибутов отношения R те ключи, которые состоят из атри-бутов отношения R4. Аналогично рассуждаем, как и для отношения R, так как в отношении R4 имеются составные ключи, то проверяем его на наличие второй нормальной формы, анализируя по порядку ключ <1,4>. Анализ наличия функциональных зависимостей от части ключа 1 была выполнена ранее. Выполняем анализ наличия функциональных зависимостей атрибутов отношения R4 от части ключа 4. Таких зави-симостей нет, так как атрибут 5 является атомарным ключом, а остав-шиеся атрибуты отношения 1 и 2 входят с атрибутом 4 в составной ключ, отсюда также не могут от него зависеть. Осталось проанализи-ровать составной ключ <2,4>, а более точно наличие зависимости от части ключа- атрибута 2. Анализируя отношение R4, видим, что такая зависимость есть: 2→1. Таким образом, наличие частичной зависимо-сти показывает, что отношение R4 не находится во второй нормальной форме. В результате его нормализации получим два отношения: R5(1,2) и R6(2,4,5). На рисунке 2.16 показаны отношения R5 и R6.

Полученные отношения R5 и R6 находятся в третьей нормальной форме. Отношение R5 имеют только два атрибута, а в отношении R6 все атрибуты либо являются первичными ключами, либо входят в со-ставной ключ. Таким образом, в результате применения описанного алгоритма нормализации исходного отношения R получена совокуп-ность следующих схем отношений, находящихся в третьей нормальной форме: R3(3,6), R4(1,3), R5(1,2), R6(2,4,5).

74

R5(1,2) R6(2,4,5) 1 2 2 4 5 1 2 3 4 5 2 6

1 2 3 4 5 6 7

1 2 3 2 4 5 6 7

1 2 3 4 5 2 6 7

1 2 3 4 5 6 7 8

Рисунок 2.16 – Отношения R5 и R6 после нормализации отношения R2 В следующем пункте рассмотрен пример выполнения анализа

базы данных, модель которой рассмотрена в первом разделе, на нали-чие третьих нормальных форм отношений.

2.7. Пример анализа отношений базы данных на третью нормальную форму

Рассмотрим анализ базы данных «ГИБДД» на третью нормаль-ную форму (см. рисунок 1.28). Все отношения базы данных находятся в первой нормальной форме, так как атрибуты отношений не являются множеством или списком. Отношения «Тип телефона», «Тип наруше-ния», «Район» находятся в третьей нормальной форме, так как количе-ство атрибутов в отношениях меньше трех. Отношения «Адрес», «Вла-делец», «Нарушение» находятся во второй нормальной форме. Проверим, находятся ли отношения «Транспортное средство», «Теле-фон», «Нарушение_Тр.средство» во второй нормальной форме. Вы-полним анализ отношения «Транспортное средство» на наличие час-тичных функциональных зависимостей. В этом отношении один составной ключ<Номер паспорта, гос.номер>. От части ключа атрибу-ты, не входящие в ключ и не являющиеся атомарными ключами, не зависят. Действительно: Номер паспорта-/->Мощность двигателя, Но-

75

мер паспорта-/->Марка, Номер паспорта-/->Дата выпуска. Аналогично нет зависимостей и для части ключа Гос.номер. То есть отношение на-ходится во второй нормальной форме. Аналогично в отношении «На-рушение_Тр.средство» отсутствуют зависимости атрибута, не входя-щего в ключ, <Код типа нарушения> от частей составного ключа <Номер паспорта, гос.номер,номер протокола>. В отношении «Теле-фон» отсутствуют зависимости атрибута «Код типа телефона» от час-тей составного ключа «Номер паспорта, номер телефона». То есть от-ношения «Нарушение_Тр.средство» и «Телефон» также находятся во второй нормальной форме. Отношения «Телефон» и «Наруше-ние_Тр.средство» находятся и в третьей нормальной форме, так как для проверки на наличие транзитивных зависимостей в отношениях кроме ключа должно быть как минимум два атрибута, а в этих отно-шениях имеется только один атрибут. Проверим, находятся ли в третьей нормальной форме отношения «Адрес», «Владелец», «Транспортное средство» и «Нарушение». Например, в отношении «Нарушение» имеются следующие зависимости: Номер протокола → Место нарушения -/->Дата нарушения, Номер протокола →Дата на-рушения -/-> Место нарушения, то есть отсутствуют транзитивные зависимости и отношение находится в третьей нормальной форме. Аналогично в отношениях «Адрес», «Владелец», «Транспортное средство» отсутствуют связи между атрибутами, не входящими в ключ, отсюда эти отношения также находятся в третьей нормальной форме.

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

76

выборки данных, выполнения запросов к базе данных. Так, в базах данных, предназначенных для систем OLAP, отношения даже не нахо-дятся в первой нормальной форме.

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

77

Глава 3. ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

БАЗ ДАННЫХ

3.1. Формат и размещение физических (хранимых) записей

Этап логического проектирования баз данных заканчивается оп-

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

их длины. На этапе физического проектирования осуществляется вы-

бор формата физической записи, размещение записей в памяти и выбор

метода доступа к данным. Главный принцип при определении струк-

туры физической записи – сохранение содержания логической записи.

Хранимая запись – совокупность связанных элементов данных, соот-

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

запись (физическая запись) состоит из двух частей: служебной части и

информационной.

Служебная часть хранимой записи используется для идентифи-

кации записи, задания ее типа, хранения признака удаления, для хра-

нения указателей на элементы записи, идентификатора длины записи,

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

рования значений элементов. Пользовательские программы не имеют

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

части хранимой записи содержат значения элементов данных.

Существует несколько способов размещения элементов данных в

хранимой записи, или иначе видов формата хранимой записи. Напри-

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

виды форматов хранимых записей: позиционный, с разделителями,

индексный и с описателями. На рисунке 3.1 приведен пример структу-

ры логической записи таблицы «Студент».

78

FIO PREDMET DATA SROC OCENKA 50, С 10, С 8 D 1 L 2, N

Смирнов Сергей Дмитриевич

Математика 3.01.95 .Y. 5

Рисунок 3.1 – Пример структуры логической записи отношения «Студент»

Виды форматов хранимых записей: а) позиционный способ организации хранимых записей В каждой записи порядок следования элементов одинаковый,

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

б) способ хранения записей с разделителем Запись имеет поля переменной длины и соответственно сама

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

Смирнов Сергей Петрович#47.5#07.02.94#Y#5.

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

в) индексный способ организации хранимых записей

79

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

Рисунок 3.2 – Пример индексного способа организации хранимых записей Аналогично способу хранения с разделителем индексный способ

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

г) способ хранения с описателями Этот способ эффективен, если запись содержит много элементов,

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

Например, известна фамилия студента и его средний балл, зато неизвестна оценка и признак сдачи (в срок или нет). Для этого примера введем такие описатели:

Описатель F вместо fio = фамилия имя отчество Описатель P вместо predmet = средний балл Описатель D вместо data= дата Описатель R вместо Sroc = срок сдачи Описатель O вместо Ocenka = оценка.

Тогда хранимая запись имеет вид F Смирнов Сергей Петрович S47.5. Понятно, что в последних трёх способах память используется

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

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

80

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

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

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

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

81

ляется от одного до N блоков, где размещаются записи (в одном блоке могут разместиться все записи или в нескольких блоках – одна запись, либо в одном блоке – одна запись; от этого будет зависеть время счи-тывания и записи элементов файла). Каждый байт в блоке имеет свой номер: 0, 1, 2, …, х. Номер байта блока, с которого начинается запись, определяет относительный адрес записи в блоке, то есть адрес записи равен номеру блока, плюс относительный адрес в блоке (последова-тельный доступ), либо номер блока и значение ключа (здесь сочетание последовательного и прямого методов доступа). Записи в блоках раз-мещаются плотно, без промежутков, последовательно одна за другой. В блоке часть памяти отводится под служебную информацию: относи-тельный адрес свободных участков памяти, указатели на следующий блок и так далее.

Для хранения поступающих данных, которые должны разме-щаться в одном блоке, заполненном уже полностью, выделяется до-полнительный блок памяти в области переполнения записи, организо-ванной в виде одного блока, где записи связываются указателями в одну цепь. Обычно стремятся область переполнения ограничить, так как время поиска информации в области переполнения сильно увели-чивается. Поэтому, как только достигается предел области переполне-ния, проводят реорганизацию файла базы данных. Файлу добавляется нужное количество блоков в основной памяти и выполняется нужная перекомпоновка записей. При этом исходят из расчета, чтобы можно было освободить область переполнения, а все записи разместить в час-тично незаполненных блоках (пустых или резервных для возможного добавления записей). Для каждого файла блоки пронумерованы: 1, 2, …, N и система определяет требуемый файл по имени файла и по номеру блока. Таким образом, на скорость поиска влияют: объем блока в байтах, объем файла, количество записей в блоке файла, количество записей в блоке индекса, количество блоков в файле, доля резервной части блока, число полей в записи, размер записи в байтах, длина клю-чевого поля в записи.

82

3.2. Методы доступа к данным

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

Выделяют три основных группы методов доступа к данным: по-следовательные, индексные, произвольные методы доступа. Последо-вательные методы используются при поиске большого числа записей (от 10 до 100%), индексные для получения одной или нескольких запи-сей, произвольные для получения отдельных записей.

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

а) В случае последовательного метода доступа на смежной памяти записи хранятся в виде логической последовательности, орга-низация которой похожа на одномерный линейный массив. Например, в файле хранятся имена:

Лена Катя Ира Света Галя

При поиске записи, например со значением «Ира», поиск начи-

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

83

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

б) В случае последовательного метода доступа на несмежной

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

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

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

84

файла базы данных имеется множество разновидностей индексных ме-тодов доступа. Некоторые из них рассмотрены ниже.

В индексно-последовательном методе доступа индексный файл всегда упорядочен по первичному ключу (главному атрибуту физиче-ской записи), по значению которого идентифицируется физическая запись. Индексный файл содержит ссылки не на каждую запись базы данных, а на группу записей, хранимых в физическом блоке, по диапа-зону ключей. Например, если в блоке хранится 10 записей, то для него в индексном файле будет одна статья, а не 10, и размер индексного файла уменьшится в 10 раз. Таким образом, индексно-последовательный метод доступа строится на основе упорядоченного физически файла и иерархической структуры индексов блоков, каж-дый из которых упорядочен по значениям первичных ключей подобно записям в файле данных. Каждое значение ключа в индексе некоторого j-уровня представляет собой наибольшее значение ключа в блоке ин-декса или блоке данных на уровне (j + 1). На каждом уровне индекса и данных последовательный поиск выполняется до тех пор, пока не бу-дет установлено местонахождение искомой записи или ее отсутствие. На рисунке 3.3 приведен пример организации индексно-последовательного метода доступа к данным.

При добавлении записи, например со значением ключа 103, в индексном файле одним из быстрых методов поиска ищется номер блока, в котором необходимо разместить запись с указанным ключом. В данном случае это четвёртый блок, где запись размещается между 100 и 105, так как в блоках основного файла эти записи упорядочены. При поиске нужной записи по заданному ключу сначала ищется быст-рым методом поиска в индексном файле номер блока, содержащего искомую запись, а затем последовательным методом в найденном бло-ке основного файла осуществляется поиск требуемой записи. При уда-лении записи сначала она ищется описанным выше способом, а затем удаляется из блока способом, описанным в последовательном методе доступа.

85

Рисунок 3.3 – Пример организации индексного файла в индексно-последовательном методе доступа к данным

При индексно-произвольном методе доступа записи в основном

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

Неключевые элементы

Ключ

86

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

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

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

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

87

Рисунок 3.4 – Пример организации индексного файла в индексно-произвольном методе доступа к данным

Рисунок 3.5 – Пример организации индексного файла в виде бинарного дерева

88

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

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

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

Рисунок 3.6 – Пример организации инвертированного метода доступа

89

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

Например, компания имеет 30 отделений (с номерами от 1 до 30). В каждом блоке хранится 5 записей данных об отделениях, следо-вательно, нужно 6 блоков.

Функция преобразования ключа в адрес:

5

___

отделенияномерблокаадресныйотноситель . Напри-

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

Метод хеширования идентификатора или метод рандомизации (random – произвольный доступ; hash – размешивание) – это метод бы-строй выборки и обновления записей, относящийся к группе произ-вольных методов доступа. В этом методе используется следующая терминология. Идентификатор – атрибут, уникально определяющий каждый экземпляр некоторой сущности предметной области. В кон-тексте файла и базы данных идентификатор – это первичный ключ. Хеширование – метод доступа, обеспечивающий адресацию данных путем преобразования значения ключа в относительный или абсолют-ный физический адрес. Функция преобразования ключа – функция хе-ширования или функция рандомизации. В прямом методе доступа име-

90

ет место отображение 1:1, в методе хеширования – М : 1, то есть воз-можно преобразование двух или более значений ключа в один и тот же физический адрес, так называемый собственный адрес. Такие ключи называют синонимами, а случай преобразования ключа в уже занятый собственный адрес – коллизией.

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

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

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

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

91

Рисунок 3.7 – Пример организации метода хеширования идентификатора Наилучшей функцией хеширования является функция, отобра-

жающая NR значений ключа в NR собственных адресов без синони-мов. Теоретически будет NR! способов такого идеального отображе-ния. Но если учесть, что существует NRNR способов присвоения NR ключами NR собственных адресов, то вероятность этого идеального отображения ничтожна. Рассмотрим пример. Пусть необходимо по-строить хеш-функцию, ставящую в соответствие каждому значению ключа адрес для последовательности чисел 36, 16, 13, 5, 85 и для ад-ресного пространства из 10 бакетов, причём построить функцию хе-ширования, не приводящую к коллизиям:

а) fхеш = значение ключа (mod 10) + 1. Значения 36 и 16 сино-нимы и они отображаются в бакет 7, а также 5 и 85, которые отобра-жаются в бакете 6, то есть имеется четыре коллизии;

б) fхеш = сумма цифр значения ключа (mod 10) + 1. Тогда полу-чим такое размещение значений ключа по адресам:

3 + 6 = 9; 9 mod 10 + 1 = 10 fхеш(16) = (1 + 6) mod 10 + 1 = 8 fхеш(13) = (1 + 3) mod 10 + 1 = 5 fхеш(5) = 5 mod 10 + 1 = 6 fхеш(85) = 13 mod 10 + 1 = 4

92

То есть для данной комбинации цифр здесь нет коллизий. Метод

деления является наиболее часто применяемым методом при построе-нии функций хеширования.

93

Глава 4. СВОЙСТВА БАЗ ДАННЫХ

4.1. Целостность данных

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

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

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

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

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

94

4. Отношение может иметь кроме первичного ключа также воз-можные ключи (вторичные), значения которых должны быть также уникальными либо могут повторяться и использоваться для связи один ко многим. Для спецификации этого типа ограничений достаточно фразы UNIQUE (A) при описании модели данных, где А – атрибут или комбинация атрибутов.

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

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

Ограничения на структуру данных: 1. Контроль типа поля данных при всех операциях над базой (на-

пример, если целое поле, то заполнять, заменять и т.д. на строковое нельзя).

2. Ограничение на число полей в записи. 3. Ссылочная целостность означает, что все изменения во взаи-

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

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

4.2. Свойство безопасности и секретности баз данных

Под безопасностью данных понимается защита от непреднаме-ренного доступа к данным, идентификации и разрушения. Под секрет-ностью данных понимается защита от преднамеренного доступа, мо-дификации и разрушения.

При решении вопросов защиты данных необходимо:

95

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

1) неограниченный доступ ко всем отношениям для всех ти-пов операций;

2) запрет на доступ к любым частям отношения для всех ти-пов операций;

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

4) доступ к любой части отношения, но с правом изменения значений заданного перечня атрибутов: A1…An;

5) неограниченный доступ только к одному кортежу отноше-ния для всех типов операций;

6) доступ только к одному кортежу отношения без права из-менения содержимого этого кортежа;

7) неограниченный доступ к атрибутам A1A2…Ar отношения для всех типов операций и запрет доступа к остальным ат-рибутам отношения;

8) доступ к атрибутам A1A2…Ar отношения без права измене-ния их значений и запрет доступа к остальным атрибутам отношения;

9) разрешить доступ к атрибутам A1A2…Ar, применяя вычис-лительные операторы без права изменения их самих;

10) доступ к данным, но в ограниченном времени (от t1 до t2) или дате.

2. Организовать систему контроля доступа к данным. 3. Тестирование всех вновь создаваемых средств защиты дан-

ных. 4. Периодическое проведение проверок правильности функцио-

нирования данных и т.п. Основные методы и приемы защиты данных: 1. Идентификация пользователя, по которой определяется уро-

вень доступа пользователя к данным (пароли, ответы на вопросы или реализация некоторых алгоритмов).

96

2. Контроль и фиксация попыток нарушения допустимого уров-ня доступа с последующими штрафными функциями.

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

4. Защита данных от сбоев в аппаратных или программных средствах: хранение поколений данных (bak), формирование кон-трольных точек (промежуточная перезапись).

4.3. Восстанавливаемость, согласованность и эффективность баз данных

Восстанавливаемость – это возможность восстановления цело-стности данных после любого сбоя системы.

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

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

2. Сохранение в буфере при выполнении транзакции содержимо-го неизменяемых файлов (файл – дубликат), если проведена защита от неправильной корректировки данных.

97

3. Фактическая корректировка данных откладывается до завер-шения транзакции (вместо этого заносится в отдельный файл образов).

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

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

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

4.4. Реорганизация баз данных. Администратор баз данных.

Словарь данных

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

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

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

Администратор базы данных – лицо или группа лиц, осуществ-ляющих управление в базе данных и решающих все вопросы по реор-ганизации базы данных. К вопросам управления в базе данных отно-сятся:

1) определение необходимости реорганизации; 2) состав изменения; 3) способ реорганизации; 4) время проведения реорганизации;

98

5) определения уровня доступа к данным. На первом этапе проектирования базы данных необходимо со-

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

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

Назначение словаря: 1) документирование данных; 2) обеспечение эффективного взаимодействия между различны-

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

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

элемент данных должен иметь уникальное имя; групповой элемент данных (объект-сущность, отношение); выводимый элемент данных (формула для его определе-

ния); синонимы, омонимы; описание концептуальной модели, логических и внешних

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

99

Глава 5. ЯЗЫК SQL. СТАНДАРТ ЯЗЫКА SQL

5.1. История SQL. История стандарта SQL. Уровни соответствия. Классы инструкций SQL

В начале семидесятых годов был создан программный продукт для работы с реляционной моделью данных SEQUEL (Structured Eng-lish Query Language) – структурированный английский язык для запро-сов, который в настоящее время называют SQL (Structured Query Lan-guage). Хотя компания IBM первая разработала теорию реляционных баз данных, первой на рынок с этой технологией вышла компания Ora-cle. Через некоторое время SQL завоевал на рынке популярность и привлек внимание Американского национального института по стан-дартизации (American National Standards Institute, ANSI), который в 1986, 1989, 1992, 1999 и 2003 годах выпустил стандарты языка SQL. Стандарт 1992 года имеет обозначение SQL92 или SQL2, стандарт 1999 года SQL99 или обозначают SQL3, сейчас используется промыш-ленный стандарт SQL2003, который по сравнению с SQL3 имеет рас-ширения, касающиеся объектно-ориентированных типов и базовых функций OLAP. Уровни соответствия стандарту были впервые пред-ложены в 1992 году. Были введены три категории соответствия: на-чальный уровень, средний и полный (Entry, Intermediate, Full). Чтобы соответствовать стандарту, производитель SQL должен был выпустить продукт не ниже уровня Entry.

В стандарте SQL2003 существуют семь основных классов ин-струкций – инструкции для установления связи, управления, работы с данными, диагностики, работы со схемами, работы с сеансами, ра-боты с транзакциями. Постоянное развитие стандарта способствовало появлению среди разных производителей и платформ многочислен-ных диалектов SQL. Кроме перечисленных инструкций в диалектах обычно вводятся процедурные команды (условные, циклические,

100

средства работы с массивами, переменными и другие). Наиболее рас-пространены следующие диалекты: PL/SQL (Oracle), Transact/SQL (MS SQL Server), PL/pgSQL (PostgreSQL), SQLPL (DB2).

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

5.2. Идентификаторы. Константы. Операторы. Типы данных. Ограничения

В этом разделе предполагается, что основные понятия языков программирования известны, главное внимание уделено именно осо-бенностям языка SQL.

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

Константы могут быть числовые, строковые константы, кон-станты даты/времени и булевские. Основные категории и типы данных приведены на рисунке 5.1.

Операторы сравнения: = (равно), <(меньше), >(больше), <= (меньше или равно), >= (больше или равно), <>, != (не равно), !< (не меньше),!> (не больше). Арифметические операторы: + (сложение), – (вычитание), * (умножение), / (деление), %(остаток целочисленного деления).

Логические операторы:

101

ALL – возвращает true, если весь набор true; AND – возвращает true, если все сравнения true; ANY – возвращает true, если хотя бы одно сравнение из набора

дает true; Between – возвращает true, если операнд находится внутри диа-

пазона; Exists – возвращает true, если подзапрос возвращает хотя бы од-

ну строку; In – возвращает true, операнд равен одному выражению из спи-

ска или множеству строк, возвращаемых подзапросом; Like – возвращает true, если операнд совпадает с шаблоном; NOT – возвращает true, если отрицается значение булевого опе-

ратора; OR – возвращает true, если одно из сравнений возвращает true; SOME – возвращает true, если несколько сравнений из набора

дают результат true; IS NULL – возвращает true, если операнд имеет неопределенное

значение; NOT IS NULL –возвращает true, если операнд не имеет неопре-

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

целостность данных, определяемое при создании таблиц. Различают четыре типа ограничений: ограничение первичного ключа (Primary Key), ограничение уникальности (Unique), ограничение внешнего клю-ча (Foreign Key), ограничение значением (Check). Ограничения могут приниматься на уровне столбцов и на уровне таблиц. Ограничения на уровне столбцов объявляются при создании столбца и применимы только к нему. Ограничения на уровне таблиц объявляются независимо от определения столбцов в конце инструкции создания таблиц Create Table и могут применяться к одному или нескольким столбцам табли-цы. Ограничения определяются при создании таблицы или ее измене-нии.

<Ограничение>::= [CONSTRAINT [<имя ограничения>]]<тип ог-раничения> [(<имя столбца>[,…])][<предикат>].

102

Ограничение первичного ключа (Primary Key) объявляется для одного или нескольких столбцов, значения которых однозначно иден-тифицируют каждую запись таблицы. В таблице может существовать только один первичный ключ. Столбцы первичного ключа можно оп-ределить на уровне столбца или таблицы, если первичный ключ состо-ит из нескольких столбцов. Столбцы первичного ключа не могут со-держать типы данных BLOB,CLOB,NCLOB,ARRAY. Значения первичного ключа не могут иметь значения Null.

Для составного первичного ключа комбинация значений во всех столбцах должна быть уникальна и не равна Null. Ограничение пер-вичного ключа на уровне столбца выглядит так: <имя столбца> <тип> PIMARY KEY. Ограничение первичного ключа на уровне таблицы:

[CONSTRAINT [<имя ограничения>]] PRIMARY KEY (<имя столбца>[,…]).

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

[CONSTRAINT [<имя ограничения>]]REFERENCES <имя связанной таблицы> [(<имя связанного столбца>)].

Ограничение внешнего ключа может задаваться на уровне таб-лицы:

CONSTRAINT [<имя ограничения>] FOREIGN KEY (<имя связанного столбца> [,…])REFERENCES <имя связанной

таблицы> [(<имя связанного столбца>[,…])].

Ограничение уникальности (UNIQUE) является ограничением альтернативного ключа или потенциального ключа, то есть имеет уни-кальное значение, но не является первичным ключом. Ограничение уникальности на уровне столбца:

<имя столбца> <тип> UNIQUE.

103

Категория Примеры типов дан-ных и аббревиатура

Описание

BINARY () двоичные

BINARY LANGE OB-JECT (BLOB)

Хранятся двоичные строковые значения в шестнадцатеричном формате. Двоичные строки хранятся без ссылок на наборы и без ограничения длины

BOOLEAN (булевы)

BOOLEAN Хранятся сведения об истинности – TRUE или FALSE

CHARACNER Строковые ти-пы (символьные)

CHAR CHARACNER VARYNG(VARCHAR)

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

NATIONAL CHARAC-TER (NCHAR) NATIONAL CHARACNER VARYNG (NVARCHAR)

Типы данных, связанные с национальными символами, разработаны для поддержки конкретных наборов символов, зависящих от реализации

CHARACTER LANGE OBJECT (CLOB)

Строковые типы больших размеров

NACIONAL CHARAC-TER LANGE OBJECT (NCLOB)

Строковые типы больших размеров с под-держкой конкретных наборов символов, зависящих от реализации

DATALINK (Связь с данны-ми)

DATALINK Определяет ссылку на файл или другой внешний источник

INTERVAL (интервал)

INTERVAL Определяет набор временных значений или промежуток времени

COLLECTION (коллекция)

ARRAY MULTISET

Отсортированные коллекции фиксирован-ной и несортированные коллекции данных переменной длины

NUMERIC (чи-словые)

INTEGER (INT) SMALLINT BIGINT NUMERIC(p,c) DEC[IMAL](p,c) FLOAT(p,c) REAL DOUBLE PRECISTION

Типы INT, BIGINT, SMALLINT хранят точные числовые значения с заранее за-данной точностью (precision,p) и масшта-бом (scale,s), равным нулю. Типы NUMER-IC,DEC хранят точные числовые значения с регулируемой точностью и масштабом. FLOAT хранит числовые значения с пла-вающей точкой с регулируемой точностью

TEMPORAL (время)

DATE TIME TIME WITH TIME ZONE

Хранит дату или дату и время. Может включать сдвиг, соответствующий часово-му поясу

XML XML Хранит данные формата XML

Рисунок 5.1 – Основные категории и типы данных SQL2003

104

Ограничение уникальности на уровне таблицы:

[CONSTRAINT [<имя ограничения>]] UNIQUE (<имя столбца>[,…]).

Ограничение значением (CHEK) выполняет сравнение значения поля, для которого введено ограничение, с определенным условием. Ограничение значением на уровне поля определяется следующим об-разом:

[CONSTRAINT [<имя ограничения>]] CHEK (<условие>).

5.3. SQL – инструкции для работы со схемами

Схема – это объект базы данных, являющийся набором объектов базы данных или, иначе, это контейнер объектов. К основным объек-там реляционной базы данных относятся таблицы, хранимые процеду-ры и функции, виды, триггеры, пользовательские типы, пользователь-ские роли, схемы. Для создания объекта любого вида используется команда CREATE, для изменения объектов – команда ALTER, для удаления объектов – команда DROP. Команда создания таблиц выгля-дит следующим образом:

CREATE TABLE <имя таблицы> (<имя поля> <тип поля> [< ограничения на уровне поля>], [, …] ,<ограничение на уровне

таблицы> [, …]).

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

CREATE PROCEDURE <имя процедуры> [(<описание списка параметров>)] [<опции>] AS <тело процедуры>.

105

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

CREATE FUNCTION <имя функции> [(<описание списка параметров>)] RETURNS <тип функции> [<опции>] AS <тело

функции>.

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

CREATE VIEW <имя вида> [<опции>] AS <команда выборки данных>.

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

CREATE TRIGGER <имя триггера> [<вид триггера>] <команды, вызывающие срабатывание триггера> ON <имя таблицы> AS <тело

триггера>.

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

CREATE TYPE <имя типа> AS <имя стандартного типа> [<атрибуты>].

106

Пользовательская роль – набор поименованных прав пользова-телей. Пользовательская роль используется для реализации в базах данных системы безопасности. Команда создания пользовательской роли выглядит следующим образом:

CREATE ROLE <имя роли> AS <список разрешений>.

Команда создания схемы данных выглядит следующим образом:

CREATE SCHEMA <имя схемы> AS <список объектов>.

Каждая команда работы с объектами имеет в различных диалек-тах языка SQL свои синтаксические особенности.

5.4. SQL – инструкции для работы с данными

К инструкциям для работы с данными в реляционных базах дан-ных относят команды добавления, удаления, изменения, выборки, ко-манды работы с курсорами. Команда добавления выглядит следующим образом:

INSERT [INTO] {<имя таблицы>|<имя вида>} [(<список полей>)] {VALUES (<список значений>) [(список значений),

…]|DEFAULT VALUES|<команда выборки данных>|<команда вызова хранимой процедуры>}.

Особенности выполнения команды добавления и всех команд ведения данных рассмотрены в разделе операций обновления данных (пункт 2.1). Команда изменения данных выглядит следующим образом:

UPDATE {<имя таблицы>|<имя вида>} [<псевдоним>] SET <имя поля>=<значение> [<имя поля>=<значение>, …] [WHERE<условие>|WHERE CURRENT OF <имя курсора>].

Команда удаления выглядит следующим образом:

107

DELETE FROM <имя таблицы>[WHERE <условие>|WHERE CURRENT OF <имя курсора>].

Команда выборки данных, реализующая операцию селекции, вы-глядит следующим образом:

SELECT [<ограничения на количество выводимых записей>] <список выбираемых элементов> FROM <откуда осуществляется выборка> [WHERE <условие выборки>] [GROUP BY <список группируемых элементов>[HAVING <ус-

ловие на группируемые данные>]] [ORDER BY <список сортируемых элементов>]. В разделе команды SELECT <ограничения на количество выво-

димых записей> могут присутствовать следующие ключевые слова: ALL (означающее выборку всех записей из полученного набора дан-ных, без учета наличия возможных повторений), DISTINCT (выборка неповторяющихся записей из набора), TOP <количество > [PERCENT] (выборка указанного количества записей, возможно не записей, а числа записей в процентном отношении от общего количества записей вы-борки).

В разделе команды SELECT <список выбираемых элементов> указывается через запятую список отбираемых элементов набора дан-ных. Элементом может быть поле таблицы, может быть скалярная функция или функция агрегирования, может быть подзапрос. Элемен-ту можно присвоить новое имя или псевдоним, которое видно только в пределах самой команды. Для введения псевдонима используется син-таксическая конструкция: <элемент> AS <псевдоним>.

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

<элемент> [[AS] <псевдоним>] [<тип соединения>] JOIN <элемент> [[AS] <псевдоним>] ON <условие соединения>.

108

Тип соединения может быть внутренним (INNER), левым внешним (LEFT OUTER), правым внешним (RIGHT OUTER), пол-ным (FULL). Особенности этих соединений были рассмотрены в пункте 2.1.

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

В разделе команды SELECT <список группируемых элементов> указывается список имен элементов из раздела <список выбираемых элементов> или номеров этих элементов. В результате выполнения этого раздела команды SELECT данные набора объединяются (груп-пируются), возможно, в несколько множеств записей, каждое из кото-рых имеет одинаковые значения элементов, присутствующих в списке группируемых элементов. В сочетании с группировкой обычно ис-пользуется выполнение функций агрегирования для каждого множест-ва сгруппированных данных. При необходимости ввести ограничение на функции агрегирования используется раздел <условие на группи-руемые данные>.

В разделе команды SELECT <список сортируемых элементов> указываются через запятую имена или номера элементов из раздела <список выбираемых элементов>. В результате выполнения этого раз-дела команды данные в результате выборки сортируются в указанном порядке, насколько это возможно в реляционной модели данных.

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

109

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

SELECT (<скалярный подзапрос>) FROM (<вложенный табличный подзапрос>) AS<псевдоним> WHERE <нечто>=(<скалярный

подзапрос>)|<нечто> IN (<табличный подзапрос>) |EXISTS (<любой вид подзапроса>).

Курсор – временный набор данных, созданный на основе выбор-ки данных. В отличие от объектов базы данных, курсор постоянно не хранится в базе данных, а используется во время сеанса работы поль-зователя с базой данных. Курсор необходим для доступа к отдельным записям полученного набора данных. Работа с курсором включает сле-дующие этапы: объявление курсора, открытие курсора, доступ к от-дельным записям курсора, закрытие курсора и освобождение памяти от курсора. В стандарте языка SQL для объявления временных данных, в том числе переменных, курсоров, используется команда DECLARE. Для открытия курсора команда OPEN, для доступа к отдельной записи команда FETH, для закрытия курсора команда CLOSE, для освобожде-ния памяти команда DEALLOCATE. В диалектах SQL синтаксис пере-численных команд различается, как и наличие различных видов курсо-ров.

5.5. SQL – инструкции для работы с сеансами

Для изменения настроек сеанса работы пользователя с базой данных в языке SQL используется команда установки SET. Эта коман-да имеет одну из следующих синтаксических конструкций:

SET <ключевое слово> ON|OFF SET <ключевое слово> <опции> SET <переменная>=<значение>.

110

Таких команд установки в каждом диалекте обычно бывает мно-го для реализации настройки сеанса пользователя. Например, для при-своения сеансу конкретной или текущей роли используется команда SET ROLE {<имя роли>|NONE}. Для определения уровня изолирован-ности пользователей используется команда:

SET TRANSACTION ISOLATION LEVEL <опции>.

5.6. SQL – инструкции для работы с транзакциями

Транзакция – неделимая с точки зрения воздействия на базу дан-ных последовательность операций, завершающаяся фиксацией или от-катом. Главное назначение транзакций – это сохранение базы данных в целостном состоянии при выполнении различных операций. Для соз-дания транзакции используется команда BEGIN TRANSACTION. Для выполнения отката транзакции, в результате чего база данных возвра-щается в исходное состояние, используется команда ROLLBACK. Для фиксации в базе данных сделанных в транзакции операций использу-ется команда COMMIT. В случае необходимости реализации логики внутри транзакции могут быть использованы точки сохранения тран-закций – SAVEPOINT TRANSACTION. Понятие транзакции является фундаментальным в задачах систем с распределенной обработкой дан-ных, основы которых будут рассмотрены в следующей главе.

111

Глава 6. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ РАСПРЕДЕЛЕННЫХ БАЗ ДАННЫХ

6.1. Основные понятия систем с распределенной обработкой данных

Распределённая база данных – это база данных, состоящая из не-скольких, возможно пересекающихся или дублирующих друг друга частей, хранимая в различных ЭВМ вычислительной сети. Распреде-лённая база данных находится на рабочих станциях вычислительной сети.

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

В настоящее время системы коллективного доступа к данным могут поддерживать одну из следующих трех моделей: модель файло-вого сервера; сервера базы данных; сервера приложений. Модель фай-лового сервера представлена на рисунке 6.1.

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

112

Pro, Access,Clipper,Paradox,dBase и другие. Модель файлового сервера не поддерживает распределенную обработку данных.

Диалог с пользователем

Операторы обращенияв СУБД

Выполнениеоператоров

Технологическиефайлы

Файлы базыданных

представлений

Уровень Рабочая станция Файловый сервер

бизнес-правила

ядро СУБД

Запросы к файлу Данные из файла

Рисунок 6.1 – Модель файлового сервера

На рисунке 6.2 приведена модель сервера базы данных.

Диалог с пользователем

Операторы обращенияк СУБД

Файлы базыданных

Уровеньпредставления

Рабочая станция Сервер

бизнес-правилаЯдро СУБД

SQL операторы Результаты выполнения

Рисунок 6.2 – Модель сервера базы данных

При реализации модели сервера базы данных приложение вы-

полняется на рабочих станциях. Операторы не выполняются на рабо-

113

чих станциях, а пересылаются для обработки на сервер. Ядро СУБД транслирует запрос и выполняет его, обращаясь к индексам и другим промежуточным данным. Обратно на рабочую станцию передаются только результаты обработки оператора. Эта модель поддерживает распределенную обработку данных. Модель сервера базы данных под-держивают такие СУБД, как Oracle, MS SQL Server, Sybase, Informix, Ingress и другие. Системы с такой моделью имеют высокую произво-дительность, так как по шине передаются только SQL-запросы и ре-зультаты выполнения. Сами запросы выполняются на высокоскорост-ных серверах. Недостатком такой модели является использование дорогих сервера и сети. На рисунке 6.3 показана модель сервера при-ложений. Сервер приложений можно организовать с помощью храни-мых процедур на языках, таких как PL/SQL, TRANSACT SQL и дру-гих. Эта модель также поддерживает распределенную обработку данных. Системы на базе моделей сервера базы данных и сервера при-ложений поддерживают архитектуру клиент-сервер.

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

Вызов хранимыхпроцедур

Файлы базы данных

Рабочая станция Сервер

Уровеньпредставления

Обращение к серверу Результаты выполнения сервиса

Сервер приложений

Реализациябизнес-правил

ЯдроСУБД

Рисунок 6.3 – Модель сервера приложений Клиент базы данных – это логический процесс, посылающий

серверу запрос на обслуживание. Архитектура клиент-сервер позволя-ет нескольким клиентам использовать совместно один сервер. При большом числе клиентов такая архитектура приводит к увеличению

114

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

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

6.2. Изолированность пользователей в многопользовательских системах

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

115

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

Первый уровень изолированности пользователей – отсутствие потерянных изменений. Здесь будем считать, что пользователь или транзакция, запускаемая пользователем, одно и то же. Рассмотрим сле-дующий сценарий совместного выполнения двух транзакций. Транзак-ция первая изменяет объект базы данных А. До завершения первой транзакции, вторая транзакция, как и первая транзакция, изменяет тот же объект базы данных А, и вторая транзакция завершается операто-ром ROLLBACK (например, по причине нарушения ограничений це-лостности). Тогда, при повторном чтении объекта базы данных, тран-закция 1 не видит изменений этого объекта, произведённых ранее. Такая ситуация называется ситуацией потерянных изменений и проти-воречит требованию изолированности пользователей. Во избежании такой ситуации для первой транзакции требуется, чтобы до ее завер-шения никакая другая транзакция не могла изменять объект А. Отсут-ствие потерянных изменений является минимальным требованием к СУБД по части синхронизации параллельно выполняемых транзакций.

Второй уровень изолированности пользователей – отсутствие чтения «грязных данных». Рассмотрим следующий сценарий совмест-ного выполнения транзакций 1 и 2. Транзакция 1 изменяет объект базы данных А, параллельно с этим транзакция 2 читает тот же объект базы данных. Поскольку операция изменения ещё не завершена, транзакция 2 видит несогласованные «грязные» данные. Это тоже не соответству-ет требованию изолированности пользователей, так как каждый поль-зователь начинает свою транзакцию при согласованном состоянии ба-зы данных и ожидает увидеть согласованные данные. Чтобы избежать ситуации чтения «грязных» данных, до завершения транзакции 1, из-менившей объект А, никакая другая транзакция не должна читать объ-ект А (необходимо выполнить блокировку чтения объекта А до завер-шения операции его изменения в транзакции 1).

Третий уровень изолированности пользователей – отсутствие неповторяющихся чтений. Рассмотрим следующий сценарий. Тран-закция 1 читает объект базы данных А, и до ее завершения транзакция

116

2 изменяет объект А и успешно завершается оператором COMMIT. Транзакция 1 повторно читает объект А и видит его изменённое со-стояние. Чтобы избежать неповторяющихся чтений, до завершения транзакций 1 никакая другая транзакция не должна изменять объект А. В большинстве систем это является максимальным требованием к син-хронизации транзакций, хотя отсутствие неповторяющихся чтений ещё не гарантирует реальной изолированности пользователей.

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

К более тонким проблемам изолированности транзакций отно-сится так называемая проблема кортежей – “фантомов” (четвертый уровень изолированности пользователей), вызывающая ситуации, ко-торые также противоречат изолированности пользователей. Рассмот-рим следующий сценарий. Транзакция 1 выполняет оператор выборки кортежей отношения R с условием выборки S (то есть выбирается часть кортежей отношения R, удовлетворяющих условию S). До за-вершения транзакции 1 транзакция 2 вставляет в отношение R новый кортеж r, удовлетворяющий условию S, и успешно завершается. Тран-закция 1 повторно выполняет оператор А и в результате появляется кортеж, который отсутствовал при первом выполнении оператора (фантом). Такая ситуация также противоречит идее изолированности транзакций и может возникнуть даже на третьем уровне изолированно-сти транзакций. Чтобы избежать появления кортежей–фантомов, тре-буется более высокий «логический» уровень синхронизации транзак-ций. Идеи такой синхронизации (предикатные синхронизационные захваты) известны давно, но в большинстве систем не реализованы.

117

6.3. Сериализация транзакций. Методы сериализации транзакций

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

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

118

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

Методы, основанные на синхронизационных захватах, в свою очередь делятся на методы: двухфазного протокола синхронизацион-ных захватов; гранулированных синхронизационных захватов; преди-катных захватов.

Сначала рассмотрим метод двухфазного протокола синхрониза-ционных захватов.

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

Совместный режим – S (Shared), означающий разделяемый за-хват объекта и требуемый для выполнения операции чтения объекта;

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

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

Текущее состояние

объекта Х S

Нет захвата – Да Да X Нет Нет S Нет Да

119

В первом столбце приведены возможные состояния объекта с точки зрения синхронизационных захватов. При этом «–» соответству-ет состоянию объекта, для которого не установлен никакой захват. Транзакция, запросившая синхронизационный захват объекта БД, уже захваченный другой транзакцией в несовместимом режиме, блокирует-ся до тех пор, пока захват с этого объекта не будет снят. Заметим, что слово «нет» в таблице соответствует описанным ранее возможным случаям конфликтов транзакций по доступу к объектам базы данных (WW, RW, WR). Совместимость S– захватов соответствует тому, что конфликт RR не существует.

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

файл – физический объект, область хранения нескольких отно-шений и, возможно, индексов;

отношение – логический объект, соответствующий множеству кортежей данного отношения;

страница данных – физический объект, хранящий кортежи одно-го или нескольких отношений, индексную или служебную информа-цию;

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

120

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

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

121

Захват IS (Intented for Shared lock) по отношению к некоторому составному объекту О означает намерение захватить некоторый вхо-дящий в О объект в совместном режиме. Например, при намерении читать кортежи из отношения R это отношение должно быть захвачено в режиме IS (а до этого в таком же режиме должен быть захвачен файл).

Захват IX (Intented for eXclusive lock) по отношению к некоторо-му составному объекту О означает намерение захватить некоторый входящий в О объект в монопольном режиме. Например, при намере-нии удалять кортежи из отношения R это отношение должно быть за-хвачено в режиме IX (а до этого в таком же режиме должен быть за-хвачен файл).

Захват SIX (Shared, Intented for eXclusive lock) по отношению к некоторому составному объекту О означает совместный захват всего этого объекта с намерением впоследствии захватывать какие–либо входящие в него объекты в монопольном режиме. Например, если вы-полняется длинная операция просмотра отношения с возможностью удаления некоторых просматриваемых кортежей, то экономичнее все-го захватить это отношение в режиме SIX (а до этого захватить файл в режиме IS).

Довольно трудно описать словами все возможные ситуации. Ни-же приведена таблица совместимости захватов:

X S IX IS SIX

– Да да да да да

X Нет нет нет нет нет

S Нет да нет да нет

IX Нет нет да да нет

IS Нет да да да да

SIX Нет нет нет да нет

Несмотря на привлекательность метода гранулированных син-

хронизационных захватов, следует отметить, что он не решает пробле-

122

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

Поскольку любая операция над реляционной базой данных зада-ётся некоторым условием (то есть в ней указывается не конкретный набор объектов базы данных, над которыми нужно выполнить опера-цию, а условие, которому должны удовлетворять объекты этого набо-ра), идеальным выбором было бы требовать синхронизационный за-хват в режиме S или X именно этого условия. Но если посмотреть на общий вид условия, допускаемых, например, в языке SQL, то стано-вится непонятно, как определить совместимость двух предикатных за-хватов. Ясно, что без этого использовать предикатные захваты для синхронизации транзакций невозможно, а в общей форме проблема неразрешима. Но эта проблема сравнительно легко решается для слу-чая простых условий.

В методе предикатных синхронизационных захватов рассматри-ваются простые условия. Условие простое, если оно является конъ-юнкцией простых предикатов, имеющих вид

Имя атрибута {=, >,<} значение.

Для простых условий совместимость предикатных захватов лег-ко определяется на основе следующей геометрической интерпретации. Пусть R отношение с атрибутами а1,...а2,...,аn, а m1, m2,..., mn – множество допустимых значений a1,a2,...,аn соответственно (все эти множества – конечные). Тогда можно сопоставить R конечное n-мерное простран-ство возможных значений кортежей R. Любое простое условие “выре-зает”m–мерный прямоугольник в этом пространстве (m<=n). Тогда S–X, X–S, X–X предикатные захваты от разных транзакций совместимы, если соответствующие прямоугольники не пересекаются.

123

Главным недостатком всех методов, основанных на синхрониза-ционных захватах, является наличие тупиков между транзакциями, необходимость их определения и разрушения. Например, тупик возни-кает между транзакциями Т1 и Т2 в следующем случае: транзакции Т1 и Т2 установили монопольные захваты объектов r1 и r2 соответствен-но; после этого Т1 требуется совместный захват r2, а Т2–совместный захват r1. Ни одна из транзакций не может продолжаться, следователь-но, монопольные захваты не будут сняты, а совместные – не будут удовлетворены. Поскольку тупики возможны и никакого естественно-го выхода из тупиковой ситуации не существует, то эти ситуации не-обходимо обнаружить и искусственно устранить. Основой обнаруже-ния тупиковых ситуаций является построение (или постоянное поддержание) графа ожидания транзакций.

Граф ожидания транзакций – это ориентированный двудольный граф, в котором существуют два типа вершин – вершины, соответст-вующие этим транзакциям, и вершины, соответствующие объектам захвата. В этом графе существует дуга, ведущая из вершины–транзакции к вершине–объекту, если для этой транзакции существует удовлетворённый захват объекта. В графе существует дуга из верши-ны–объекта к вершине–транзакции, если транзакция ожидает удовле-творения захвата объекта. Легко показать, что в системе существует ситуация тупика, если в графе ожидания транзакций имеется хотя бы один цикл. Для распознавания тупика периодически производится по-строение графа ожидания транзакций (как уже отмечалось, иногда граф ожидания поддерживается постоянно) и в этом графе ищутся циклы. Традиционной техникой (для которой существует множество разновидностей) нахождения циклов в ориентированном графе являет-ся редукция графа.

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

124

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

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

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

Основная идея метода временных меток, у которого существует множество разновидностей, состоит в следующем: если транзакция Т1 началась раньше транзакции Т2, то система обеспечивает такой режим выполнения, как если бы Т1 была целиком выполнена до начала Т2. Для этого каждой транзакции т предписывается временная метка t, со-ответствующая времени начала Т. При выполнении операции над объ-ектом r транзакция Т помечает его своей временной меткой и типом операции (чтение или изменение). Перед выполнением операции над объектом r транзакция Т1 выполняет следующие действия: проверяет,

125

не закончилась ли транзакция Т, пометившая этот объект. Если Т за-кончилась, Т1 помечает объект r и выполняет свою операцию. Если транзакция Т не завершилась, то Т1 проверяет конфликтность опера-ций. Если операции неконфликтны, при объекте r остаётся или про-ставляется временная метка с меньшим значением и транзакция Т1 вы-полняет свою операцию. Если операции Т1 и Т конфликтуют, то при t(T)>t(T1) (т.е. транзакция Т является более «молодой», чем Т1) произ-водится откат Т и Т1 продолжает работу. Если же t(T)<t(T1) (T «старше» T1), то Т1 получает новую временную метку и начинается заново.

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

6.4. Журнализация и буферизация изменений в базах данных

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

126

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

Индивидуальный откат транзакций. Тривиальной ситуацией отката транзакции является её явное завершение оператором ROLLBAK. Возможны также ситуации, когда откат транзакции ини-циируется системой. Примерами могут быть возникновение исключи-тельной ситуации в прикладной программе (например, деление на ноль) или выбор транзакции в качестве жертвы при обнаружении син-хронизационного тупика. Для восстановления согласованного состоя-ния базы данных при индивидуальном откате транзакции нужно уст-ранить последствия операторов модификации базы данных, которые выполнялись в этой транзакции.

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

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

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

127

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

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

128

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

129

Глава 7. ПРИМЕР РЕАЛИЗАЦИИ РАСПРЕДЕЛЁННЫХ БАЗ ДАННЫХ. MS SQL SERVER

7.1. Основные характеристики MS SQL Server. Системные базы данных, таблицы и хранимые процедуры.

Базы данных и файлы

СУБД MS SQL Server – это распределенная СУБД, реализующая клиент-серверную технологию. Задача сервера – управление хранени-ем данных и осуществление контроля целостности. Задача клиента – осуществление контроля вводимых данных, управление интерфейсом пользователя, приведение данных к нужному формату для пользовате-ля. Язык – Transact SQL, являющийся расширением языка SQL (позво-ляет создавать хранимые процедуры, триггеры, такие объекты баз дан-ных, как пользовательские типы, правила, значения по умолчанию, средства работы с транзакциями). Операционная система Windows NT. СУБД MS SQL Server позволяет определять до 32767 баз данных, внутри каждой базы данных до 2 миллиардов таблиц. В каждой табли-це до 250 столбцов; нет ограничения на количество строк в таблице. Для каждой таблицы можно определить до 250 индексов.

Основные службы: 1) SQL Server Management Studio – главная утилита администри-

рования и работы с данными; 2) SQL Server Agent – служба автоматизации административных

задач; 3) SQL Server Browser – обозреватель, предоставляющий клиент-

ским компьютерам информацию о соединениях с SQL Server; 4) SQL Server Profiler – утилита управления отчетами, генери-

руемыми службами. При работе SQL Server возникает задача сохранения информа-

ции о том, как хранятся данные в базе. Информация о хранении дан-

130

ных называется метаданными, которые хранятся в словаре данных. Словарь данных реализуется в виде системных таблиц и заполняется при выполнении команд Create и Alter.

Базы данных делятся на системные и пользовательские базы данных. В системных базах данных хранятся данные, используемые системой для управления другими данными. В SQL Server имеет четы-ре вида системных баз данных: master, model, tempdb, msdb.

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

Model – шаблон для вновь создаваемых на сервере баз данных SQL Server создаёт копию базы данных model. В model добавляют объекты, которые используются в каждой вновь создаваемой базе данных.

Tempdb – системная база данных, которая обеспечивает место для размещения на диске временных таблиц и других объектов вре-менного хранения, таких как курсоры, результаты группировки данных и другие. Для доступа к этой базе не надо специальных разрешений и она удаляется при прерывании связи с SQL Server.

Msdb – поддерживает службу SQL Server Agent – планировщика задач (оповещения и задания, данные об операторах) и управления ошибочными ситуациями, в эту базу входят таблицы – sysalerts – таб-лица о всех определённых пользователем событиях, Sysoperators – ин-формация о всех операторах и другое при работе с интернет и элек-тронной почтой.

Каждая системная и все пользовательские базы данных имеют системные таблицы, куда заносится информация о SQL Server в целом и о каждой базе данных в отдельности. Все системные таблицы начи-наются с SYS.

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

131

Файлы делятся на три типа: первичные файлы (используются для хранения данных и информации, определяющих начальные действия с базой, база данных содержит лишь один первичный файл – primary, стандартное расширение- .mdf); вторичные файлы – secondary (одна или несколько областей для хранения данных, могут использоваться для распределения операций чтения/записи по нескольким дискам, стандартное расширение – ndf); файлы журналов – log (содержат жур-налы транзакций базы данных, база данных содержит хотя бы один файл журнала транзакций, стандартное расширение – ldf). Каждый файл может принадлежать лишь одной базе данных. Каждая база дан-ных содержит, по крайней мере, один первичный файл и один файл журнала.

Файловая группа – это способ создания набора файлов. Файл может относиться только к одной группе (файлы журналов не могут входить в файловые группы). Файловые группы используются для рас-пределения нагрузки, связанной с выполнением чтения и записи, по нескольким дискам для таблиц, которые размещены на этой файловой группе. Если группа содержит больше одного файла, чтение и запись для этой группы распределяется между файлами групп. Каждая база данных имеет первичную файловую группу под названием Primary. Эта группа содержит первичный файл данных и все остальные файлы данных, для которых специально не указано, что они относятся к дру-гим файловым группам. Данные могут размещаться в любой файловой группе. Все данные, для которых специально не указано, что они будут храниться в определенной файловой группе, будут размещены в фай-ловой группе по умолчанию. Любую файловую группу можно сделать файловой группой по умолчанию в любой момент времени. Файл и файловая группа могут использоваться только одной базой данных. Файл может быть членом только одной файловой группы. Вы должны хранить данные и записи журнала в разных файлах. Файлы данных и файлы журнала не могут принадлежать к одной файловой группе, так как файлы журнала вообще не могут входить в какие-либо файловые группы. В одной базе данных может быть одновременно до 256 файло-вых групп. Для повышения производительности при работе с базой данных необходимо придерживаться следующих рекомендаций:

132

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

объекты, увеличивающиеся в размерах наиболее быстро, желательно размещать в различных файловых группах;

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

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

не размещайте файлы журналов на тех же физических дис-ках, где размещены файлы и файловые группы или другие файлы, не относящиеся к SQL Server.

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

Журнал транзакций состоит из множества виртуальных файлов журнала. Виртуальный файл журнала – это сегмент файла журнала. Когда журнал транзакций обрезается, при этом удаляется один или бо-лее виртуальных файлов журнала. Файл журнала состоит из двух или более виртуальных файлов. Минимальный размер виртуального файла журнала – 256 Кбайт. SQL Server создает новые виртуальные файлы, когда журнал увеличивается в размере. Количество и размер виртуаль-

133

ных файлов зависят от размера приращения (growth increment) для файла журнала. Больший размер приращения определяет и большой размер виртуальных файлов. Создание базы данных осуществляют ли-бо через главную утилиту администрирования, используя инструмен-тальные средства, либо с помощью команды CREATE DATABASE.

CREATE DATABASE <имя базы данных> [ ON [PRIMARY] ( [NAME = <логическое имя файла>, ] [ , FILENAME = <имя файла ОС> [, SIZE =< размер>] [ MAXSIZE = {<максимальный размер>| UNLIMITED}] [ FILEGROWTH = <приращение> ] ) | { FILEGROUP <имя группы файлов> FILEDEFINITIONS} [ , …n ] ] [ LOG ON { [ NAME = <логическое имя файла> ,} [FILENAME = <имя файла ОС>] [, SIZE =< размер> ] [, MAXSIZE = {<максимальный размер> | UNLIMITED}] [, FILEGROWTH = <приращение> ] ) [ , …n ] [FOR LOAD| FOR ATTACH]. В случае, если при создании базы данных не указан первичный

файл данных и/или файл журнала, то отсутствующий файл (или фай-лы) создается с именем по умолчанию. Физические файлы будут нахо-диться в стандартном каталоге. Первичному файлу приписывается имя: имя базы.mdf, а файлу журнала – имя базы.ldf. Если размер фай-лов не задан, то при создании размер первичного файла совпадает с размером первичного устройства базы данных model, а размер файла журнала и вторичных файлов равен 1 Мбайт. Он может быть и больше, если размер первичного файла базы данных model превышает 1 Мбайт. Хотя имена и размеры файлов указывать не обязательно, на практике это нужно делать. SQL Server создает базу в два этапа. На первом этапе база данных model копируется в новую базу данных, а на втором этапе инициализируется все неиспользуемое пространство.

134

Команда CREATE DATABASE имеет следующие параметры: PRIMARY – файл определяется как первичное устройство; NAME – логическое имя, по умолчанию совпадающее с

базой данных; FILENAME – полное имя файла на диске; SIZE – исходный размер файла. Минимальный размер

файла журнала равен 512 Кбайт; MAXSIZE – максимальный размер файла; UNLIMITED – размер файла не ограничивается; FILEGROWTH – приращение файлов в мегабайтах (МВ),

килобайтах (КВ) или процентах (%). По умолчанию при-ращение равно 10%;

FOR LOAD – обеспечивает обратную совместимость со сценариями SQL Server, написанными для предыдущих версий;

FOR ATTACH – указывает, что файлы базы данных уже существуют.

Пользователь, создавший базу данных, является её владельцем. Все параметры конфигурации базы данных копируются из базы дан-ных model, если только при создании базы данных не был указан параметр FOR ATTACH. Удаление базы данных осуществляется ко-мандой

DROP DATABASE <имя базы данных> [,…n]. При удалении базы удаляются файлы, используемые ими. Нельзя

удалить базу, используемую в данный момент. После удаления базы данных её файлы не могут быть использованы.

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

Sp_changedbowner [@loginame=] ‘учетная запись пользова-теля для входа’[,[@map=]флаг уничтожения псевдонима].

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

135

данных Вы должны быть подключены к этой базе данных. Использо-вание хранимой процедуры показано на примере:

USE MyDB Go Sp_changedbowner @loginame=’NewDBO’ go. Для смены имени используется хранимая процедура Sp_renamedb «старое имя», «новое имя». Базу данных может переименовать только системный админист-

ратор. Предварительно база данных должна быть переведена в одно-пользовательский режим.

Изменение определений базы данных и её размеров осуществля-ется командой:

ALTER DATABASE <имя базы данных> {ADD FILE <спецификация> [,…n] [TO FILEROUP <имя

группы> ] | ADD LOG FILE <спецификация> [,…n] | REMOVE FILE <логическое имя файла> | ADD FILEGROUP <имя группы> | REMOVE FILEGROUP <имя группы> | MODIFY FILE <спецификация> | MODIFY FILEGROUP <имя группы> < свойство группы> } <спецификация> ::= ( NAME = <логическое имя файла> [,FILENAME= <имя файла ОС>] [, SIZE = <размер> ] [, MAXSIZE = {<максимальный размер> | UNLIMITED}] [, FILEGROWTH = <приращение>]).

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

136

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

Используя команду ALTER DATABASE для модификации фай-лов, необходимо указывать логическое имя файла. Спецификация по-зволяет изменить все остальные параметры, но в одной команде AL-TER DATABASE можно указать один параметр. Если изменяется размер файла, новый размер не может быть меньше текущего.

При модификации группы файлов можно задавать свойства READONLY, READWRITE, DEFAULT. Свойство READONLY гово-рит о том, что группа файлов доступна только для чтения. Оно предот-вращает возможную модификацию объектов из этой группы. Для пер-вичной группы установка этого свойства невозможна. Свойство READONLY может устанавливаться только пользователями, обла-дающими монопольным доступом к базе данных. Свойство READWRITE обладает противоположным действием. Оно разрешает обновление объектов в группе. Свойство READWRITE может устанав-ливаться только пользователями, обладающими монопольным досту-пом к базе данных. Свойство DEFAULT говорит о том, что группа на-значается стандартной группой для базы данных. При установке свойства DEFAULT это свойство отменяется для группы, которая была назначена стандартной ранее. При создании базы стандартной группой назначается первичная группа файлов. Если в командах CREATE NABLE, ALTER TABLE, CREATE INDEX не указана группа файлов, новые таблицы и индексы создаются в стандартной группе. Непосред-ственное перемещение файлов из одной группы в другую невозможно. Для этого нужно сначала удалить файл, а затем включить его в новую группу.

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

DBCC SHRINKDATABASE ( <имя базы> [,< процент>] [, { NOTRUNCATE| TRANCATEONLY}]).

137

При сжатии базы данных можно указать необязательный пара-метр – процент свободного места, которое вы хотите оставить в базе данных. Параметр NOTRUNCATE отменяет стандартное поведение и оставляет свободное место в файлах операционной системы после сжа-тия файла. Параметр TRANCATEONLY возвращает операционной системе все неиспользуемое место в файлах данных и сокращает файл до последнего экстента. Команда не пытается переместить записи в невыделенные страницы. При наличии параметра NOTRUNCATE зна-чение «процент» игнорируется. Параметр NOTRUNCATE не позволяет сократить файл ниже минимального размера. В целом команда не сжимает файл больше минимума, необходимого для хранения данных в файле. Если параметр NOTRUNCATE используется вместе с пара-метром «процент», то последствия ограничиваются перемещением ис-пользуемых страниц в начало файла. База данных не может быть меньше базы model.

Многие параметры конфигурации SQL Server настраиваются на уровне баз данных с помощью системной хранимой процедуры:

Sp_dboption [ ‘база данных’ ] [, ‘имя параметра’] [, ‘значение’]. Например, параметр: OFFLINE – если его значение равно true, то база данных нахо-

дится в отключенном состоянии и не может никем использоваться; READ ONLY – если его значение равно true, пользователи могут

только читать данные из базы, не модифицируя её; SINGLE – задает одно- или многопользовательский режим рабо-

ты системы. Просмотр информации о базе данных, её конфигурации: Sp_helpdb [имя базы]. Просмотр сведений о файлах, связанных с текущей базой дан-

ных: Sp_helpfile [[@filename=]’имя ’]. Просмотр информации о группе файлов текущей базы данных: Sp_helhfilegroup [[@filegroupname=]’имя’].

138

7.2. Таблицы баз данных. Создание, удаление, изменение

Команда создания таблиц соответствует стандарту языка SQL. Имена таблиц ограничиваются 128 символами. Они должны быть уни-кальными по отношению к владельцу. Таблица может содержать до 1024 столбцов. Имя столбца имеет длину до 128 символов и уникально в пределах таблицы (допускаются в имени служебные символы _, @, #). Типы полей также соответствуют стандарту. В качестве одного из видов полей может использоваться счетчик. Столбец счетчика (IDEN-TITY) – это автоматизированный столбец, генерирующий уникальные значения с некоторым приращением. Столбцы счетчика не могут со-держать неопределенные значения и должны относиться к числовым типам данных – int, smallint, tinyint, numeric(p,0),decimal(p,0). Если при объявлении столбца не указаны начальное значение и приращение, столбец действует как счетчик с начальным значением 1 и приращени-ем 1. Недостаточный размер счетчика может вызвать проблемы. В примере тип tinyint допускает максимальное значение 255, при дости-жении максимума таблица будет отвергать все дальнейшие операции вставки.

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

ALTER TABLE <имя таблицы> <параметры>. Добавить столбцы после определения таблицы можно с помо-

щью команды: ALTER TABLE <имя таблицы> ADD <имя поля> <тип по-

ля> <ограничения>. Удаление столбцов осуществляется командой: ALTER TABLE <имя таблицы> DROP COLUMN < имя

поля>. Удаление из таблиц ограничений:

139

ALTER TABLE <имя таблицы> DROP CONSTRAINT <имя ограничения>.

Команда удаления таблицы выглядит следующим образом: DROP TABLE <имя таблицы>.

Удаленная таблица навсегда пропадает из базы данных, то есть действие команды удаления невозможно отменить. Удаляются не только пользовательские, но и системные таблицы. Таблицу, на кото-рую ссылаются какие-либо ограничения, удалить нельзя. Перед удале-нием таблицы эти ограничения необходимо отключить или удалить. Таблица может быть удалена только владельцем. Удаленную таблицу нельзя восстановить. Кроме рассмотренных пользовательских таблиц и системных таблиц, существуют временные таблицы. Имена системных таблиц начинаются с префикса sys. Временные таблицы отличаются от обычных тем, что они не предназначены для постоянного хранения данных. Временные таблицы могут быть локальными и глобальными. Локальные временные таблицы доступны только одному пользователю во время сеанса, глобальные временные таблицы доступны всем поль-зователям сети во время сеанса. Имена временных таблиц начинаются на # (локальные временные таблицы) и на ##(глобальные временные таблицы). Имена временных таблиц ограничиваются 116 символами. Временные таблицы удаляются при отключении пользователя от базы данных. Временные таблицы используются так, как будто они входят в текущую базу данных, однако в действительности данные хранятся в TEMPDB. Временные таблицы удаляются как обычные таблицы во время сеанса работы пользователя.

7.3. Индексы баз данных

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

140

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

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

Рекомендуется помнить: выбор индекса определяется соображениями быстродей-

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

141

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

с ростом количества индексов (больше 5) затраты стано-вятся чрезмерными;

в системах OLTP с оперативной обработкой транзакций создается минимальное количество индексов, что позволя-ет ускорить выполнение команд UPDATE, INSERT, DE-LETE.

Команды ведения данных при работе с таблицами соответствуют стандарту языка SQL.

7.4. Программирование на Transact SQL. Комментарии. Переменные. Команды управления

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

Обозначение однострочного комментария: -- Однострочный комментарий.

Обозначение многострочного комментария: /* Многострочные ** комментарии*/. Переменные могут быть двух типов – локальные (начинаются с

символа @) и глобальные (начинаются с двух символов @@). Локаль-ные переменные существуют в пределах сеанса, глобальные перемен-ные используются для получения информации о сервере в целом (ино-гда называют функциями). Локальные переменные объявляются командой DECLARE и значения задаются командами SELECT и SET. Например:

DECLARE @R DATETIME, @C INT

142

SELECT @C=1 SET @R =getdate() SELECT @C, @R. Обычно рекомендуется для присваивания переменных использо-

вать команду SET , а не SELECT, так как первая работает быстрее. В одной команде SELECT можно присваивать значения нескольким пе-ременным. Команда PRINT передает сообщение длиной 1024 байта обработчику сообщений клиента.

Команды условного выполнения: IF <логическое выражение>

{ <команда> |< блок команд>} ELSE

{ <команда> | <блок команд>}. Например, использование команды условного выполнения вы-

глядит так: IF (SELECT AVG(price) from titles WHERE type = “business”)

>$19.6 PRINT ” Сообщение 1”

ELSE PRINT “ Сообщение 2”.

Блок команд – множество команд в операторных скобках BEGIN

.. END Цикл WHILE: WHILE <логическое условие> [ <команда> |< блок команд>] [BREAK] [CONTINUE] END. Например, использование цикла с предисловием: WHILE (SELECT AVG(price) FROM titles) < $25

BEGIN UPDATE titles SET price =price*1.05 IF (SELECT COUNT(*) FROM titles WHERE price

< $15) <10)

143

CONTINUE ELSE

IF (SELECT MAX(price) FROM titles) >$50 BREAK

END. Команда WAITFOR переводит запрос в состояние ожидания в

течение некоторого интервала или до наступления заданного времени (и потому называется обработчиком события):

WAITFOR {DELAY “время” | TIME “время”}. Параметр DELAY заставляет пакет или процесс сделать паузу

заданной длины (максимум – 24 часа). Параметр TIME останавливает процесс до наступления заданного времени. Время задается в формате hh: mi: ss. Например: WAITFOR TIME “ 22:00:00”.

7.5. Курсоры. Типы курсоров. Работа с курсорами

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

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

Статические курсоры – курсоры, изолированные от изменений в данных. Сервер сохраняет весь итоговый набор курсора в tempdb при первой выборке.

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

144

Работа с курсором выполняется в следующем порядке: 1. Объявление курсора. 2. Открытие курсора. 3. Выборка записей, модификация или удаление записей из

курсора (обработка записей в курсоре). 4. Закрытие курсора. 5. Освобождение ресурсов курсора.

Объявление курсора реализуется следующей командой: Declare <имя_курсора> [ INSENSITIVE] CURSOR [LOCAL |

GLOBAL ] [FORWARD ONLY | SCROLL ] [ STATIC | KEYSET |DYNAMIC] [READ_ONLY | SCROLL_LOCKS | OPTIMISTIC] FOR <инструкция_Select> [FOR UPDATE [OF <список столбцов>]]. Объявление курсора с ключевым словом INSENSITIVE заставля-

ет сервер создать копию данных во временной рабочей таблице. При работе с курсором Вы действительно работаете с содержимым времен-ной таблицы, которое не изменяется с модификацией настоящей таб-лицы. Если при определении курсора не используются опции Read Only и UPDATE, то способности курсора к обновлению определяются следующим:

а) если используется опция ORDER BY в предложении Select или указано INSENSITIVE, курсор будет доступен только для чтения. В противном случае курсор доступен и для обновлений;

б) если в выражении выборки используются GROUP BY, UNION, Distinct или Having, курсоры доступны только для чтения и не будут обновляться изменениями. Результаты передаются во времен-ную таблицу и выбираются оттуда.

Так как курсоры могут считывать строки в переменные, находя-щиеся в хранимых процедурах или пакетах команд, в инструкции Se-lect нельзя применять маску *.

В курсорах может использоваться любая команда SELECT, удовлетворяющая условиям:

не может содержать секции INTO, COMPUTE, FOR BROWSE;

145

при использовании секций GROUP BY, HAVING, DIS-TINCT, UNION курсор становится статическим;

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

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

Используемые параметры имеют следующий смысл: Local – курсор локальный по отношению к пакету; Global – курсор доступен в течение всего подключения; Forward_only – курсор допускает перебор записей только в пря-

мом направлении, если ключевое слово STATIC | KEYSET |DYNAMIC не указано, то курсор является динамическим;

Scroll – позволяет любые перемещения. Функция, обратная IN-SENSITIVE. Заставляет курсор читать завершенные изменения и уда-ления, выполняемые другими процессами сервера. Если вы не объяви-ли курсор с ключевым словом Scroll, единственным методом считывания информации является последовательный проход результи-рующего набора;

Read Only – эта опция предотвращает любую модификацию дан-ных курсора;

UPDATE – эта опция устанавливается по умолчанию для курсо-ра, определенного в одной таблице.

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

Считывание данных их курсора осуществляется с помощью ко-манды:

FETCH [[NEXT | PRIOR | FIRST | LAST | ABSOLUTE n | @nvar | RELATIVE n | @nvar] FROM] имя_курсора

[INTO @имя_переменной 1, @имя_переменной 2]. Здесь используемые параметры:

146

NEXT – нормальный порядок считывания (возвращает след. строку);

PRIOR – если курсор определен с ключевым словом Scroll, опция PRIOR позволяет читать предыдущую запись;

FIRST – считывание 1-й записи набора; LAST – последняя строка набора; ABSOLUTE n – вызывает считывание n-й строки результирую-

щего набора. Если n – положительное число, то считывание будет с 1-й записи заданное число, если n –отрицательное, то с последней на-зад заданное число;

Relative n – вызывает считывание n-й записи результирующего набора относительно текущей строки;

Если указываете отрицательное число, то находится нужная строка, отсчитав от текущей назад. Причем, вместо “n” могут исполь-зоваться переменные типа int, smallint tinyint;

FROM – следом идет имя курсора из которого считываются дан-ные;

INTO – используется в хранимых процедурах. Когда вы указы-ваете это ключевое слово, данные, возвращаемые курсором, помеща-ются во временные переменные;

Закрытие курсора осуществляется с помощью команды: Close <имя курсора>.

Курсор следит за вашим местоположением в базе данных и под-держивает активную, открытую структуру указателей на предыдущую и следующую строки информации. При освобождении курсора полно-стью удаляются любые связанные с ним структуры данных, которые SQL Server держал в открытом состоянии. Освобождение курсора от-личается от его закрытия. После освобождения вы больше не сможете открыть данный курсор. Команда освобождения памяти от курсора: Deallocate <имя курсора>.

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

147

ство языков программирования приложений клиента не различают данные в курсоре и команде select. Используются специальные функ-ции для обращения к данным в курсоре, если он и ассоциированная с ним обработка возвращают несколько результирующих наборов. Кур-соры позволяют производить индивидуальные операции с записями в наборе, созданном в команде select. Курсор может включать все табли-цы базы данных. Модификация записей с помощью курсора выполня-ется с помощью команд UPDATE, DELETE через включение секции WHERE CURRENT OF. Модификация разрешается только для одно-табличных курсоров.

7.6. Правила, значения по умолчанию, представления

Правило – объект базы данных, который связывается со столб-цами таблицы и ограничивает их домены. Правило представляет собой выражение, вычисляемое при вставке или обновлении записи. Если это выражение принимает значение FALSE, команда INSERT или UP-DATE, ставшая причиной нарушения, отменяется. Команда создания правила:

CREATE RULE <имя правила> <@Переменная> <оператор> <выражение> [ { AND | OR } …]. Например: CREATE RULE rule1 AS @age between 16 and 21. Здесь переменная обозначает позицию, в которую подставляется

значение столбца. Имя переменной не влияет на выполнение правила. Удаление правила осуществляется командой DROP RULE <имя прави-ла>. Удаляемое правило исчезает из базы данных. Чтобы использовать правило, необходимо ассоциировать его со столбцами. Этот процесс называется связыванием: Sp_bindrule имя правила, ‘имя таблицы. Имя столбца’.

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

148

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

в правиле могут участвовать только константы, функции и маски редактирования;

правило не может выполнять просмотр таблицы; в правилах не могут сравниваться столбцы таблиц; с каждым столбцом может быть связано одно правило; если со столбцом связано некоторое правило, оно замеща-

ется новым устанавливаемым правилом; значения, используемые в правилах, должны быть совмес-

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

правила не применяются к данным, уже находящимся в таблице, но действуют при обновлении существующих данных;

правило, связанное со столбцом или пользовательским ти-пом данных, нельзя удалить. Предварительно необходимо разорвать связь правила со всеми столбцами и типами дан-ных;

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

ется со столбцами и в базе данных и предоставляет значение столбца в том случае, если столбец отсутствует в команде INSERT. Команда соз-дания значения по умолчанию:

CREATE DEFAULT <имя значения по умолчанию> AS <выра-жение – константа>.

149

Например: CREATE DEFAULT adef AS 18. Удаление значения по умолчанию: DROP DEFAULT <имя зна-

чения по умолчанию>. Связывание со столбцом: Sp_bindefault <имя значения по умол-

чанию>, ‘имя таблицы. Имя столбца’. Разрыв связи со столбцом: Sp_unbindefault ‘имя таблицы. Имя столбца’.

Ограничения для значений по умолчанию (з.п.у.): в определении значения по умолчанию может использо-

ваться лишь одна константа или функция – логические возможности отсутствуют;

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

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

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

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

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

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

з.п.у. применяются до применения правила; з.п.у. не применяются к данным, уже находящимся в таб-

лице; з.п.у. связанное со столбцом или пользовательским типом,

нельзя удалить, предварительно связь должна быть разо-рвана со всеми столбцами.

Пользовательский тип – объект базы данных, используемый для описания доменов столбцов базы данных, является производным от стандартных типов данных. Создание пользовательских типов:

150

sp_addtype имя пользовательского типа данных, системный тип данных,

Null | No Null, Просмотр пользовательских типов данных: sp_help. Удаление

пользовательского типа: sp_droptype <имя типа>. Между правилами могут возникнуть конфликты. Для их разре-

шения должны быть выработаны определенные соглашения: правила, связанные со столбцом, имеют приоритет выше, чем

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

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

Представление (Вид) (view) – объект базы данных, но в отличие от таблиц не является физическим хранилищем данных – это логиче-ский «вид» физических данных, хранящихся в базе. Его можно пред-ставить как хранимое выражение выборки с минимальным набором свойств. Удаление всего представления как объекта никак не повлияет на данные, на основе которых оно построено. В то же время удаление всех записей в представлении может удалить эти записи в исходных таблицах. После определения вида на него можно ссылаться так же, как и на таблицу. Вид не создает постоянную копию выбранных строк и столбцов базы данных. Если в какой-нибудь инструкции вместо име-ни таблицы указать имя вида, то выполнится инструкция select, входя-щая в определение вида, и после этого создается временная таблица, которая и отображается на экране. Таким образом, при ссылке на вид выполняется заданная в определении вида инструкция Select. Если вы добавляете столбцы в таблицы, лежащие в основе вида, новые столбцы не появляются в нем до тех пор, пока вы сначала его не удалите и за-тем снова не определите. Рекомендуется в имени вида добавлять пре-фикс “vw_имя”, иначе объект внешне выглядит как таблица. Виды можно использовать для обеспечения безопасности базы данных. Можно представить такие права доступа к видам, которые будут отли-чаться от прав доступа к таблицам, лежащим в основе вида. Команда создания вида:

CREAT VIEW <имя вида>

151

[WITH ENCRYPT] AS SELECT <инструкция> [WITH CHECK OPTION].

Здесь опция WITH ENCRYPTION лишает пользователя возмож-ности отображать определение вида в системной таблице Syscomments (то есть никто, кроме создателя вида не может посмотреть его код). При отсутствии этой опции после создания вида его определение со-храняется в системной таблице Syscomments. Для отображения этой информации может использоваться хранимая системная процедура sp_helptext <имя вида>. Просмотреть определение зашифрованного вида невозможно ни одним из способов. Недостатком шифрования оп-ределений вида является то, что такие виды не могут воссоздаться при обновлении базы данных или SQL Server. Шифровка используется для безопасности данных, чтобы лишить пользователя возможности про-сматривать объекты базы данных. Ограничения на использование и определение видов (по поводу команды Select):

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

2. Для вида нельзя определить триггер (триггер – объект базы данных, который автоматически выполняется при добавлении, обнов-лении и удалении строк таблицы.)

3. Нельзя включать в определение вида ORDER BY. Строки в виде неупорядочены. Если бы внутри вида можно было использовать инструкцию Select с предложением ORDER BY, строки получившегося вида стали бы упорядоченными и вид стал бы отличаться от стандарт-ной таблицы базы данных, где данные неупорядочены (хотя секция может быть использована при выборке из вида).

4. В виде нельзя использовать предложение COMPUTE. 5. Внутрь вида нельзя включать предложение Distinct команды

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

6. Нельзя использовать внутри вида предложение INTO, т.е. вы-вод строк не на экран, а в другую таблицу.

152

Иногда виды делят на простые и составные виды (simple view) определяют для доступа к одной таблице, составные виды (complex view)- доступ к нескольким таблицам, тогда в команде FROM присут-ствуют несколько таблиц. В некоторых случаях вы можете так изме-нить данные, что они больше не будут удовлетворять условиям выбор-ки в представлении. Опция WITH CHECK OPTION позволяет контролировать измененные данные, так чтобы критерий выборки не нарушался. Эта опция – работает с командами UPDATE, INSERT и DELETE (запрещает пользователям вставку и обновление записей, не входящих в представление, разрешает модификацию записей, входя-щих в представление). Для модификации видов используется команда:

ALTER VIEW <имя представления> [ with encryption ] AS < команда select> [WITH CHECK OPTION].

Команда изменяет существующее представление и не влияет на зависящие от него хранимые процедуры или триггеры, а также не из-меняет прав пользователей. Эта команда относится к новым возможно-стям последней версии SQL Server и позволяет модифицировать пред-ставления без их удаления и повторного создания. Представление, используемое в настоящий момент, модифицировать нельзя. Удаление видов осуществляется командой: DROP VIEW <имя_вида>. Удаление вида не влияет на постоянные таблицы, лежащие в их основе, опреде-ление вида удаляется из базы данных. Если вы удалите вид, указанный в определении другого вида, то при последующей ссылке на него поя-вится сообщение об ошибке. Можно создать вид, ссылающийся на не-сколько видов и таблиц. Модификация данных с помощью видов воз-можна только для простых видов. Вставленные с помощью вида строки можно вставлять даже тогда, когда они не удовлетворяют кри-терию, заданному в предложении Where внутри определения вида, а вот считать такую строку с помощью этого вида не удастся.

Чтобы не запутаться, к определению вида можно добавить пред-ложение WITH CHECK OPTION, которое запрещает операцию добав-ления строки посредством вида, если впоследствии с помощью того же вида строку невозможно отобразить. Если при добавлении в вид опре-

153

деляются не все столбцы, т.е. один или несколько столбцов в виде не заданы, тогда эти столбцы должны допускать значения NULL или De-fault, иначе строка не будет добавлена. С помощью видов можно уда-лить строки, даже если в этом виде происходит обращение не ко всем столбцам таблицы. Delete from <имя_вида> WHERE <условие>. Не-возможно выполнить операцию удаления строк посредством вида, если в критерии, заданном в предложении WHERE определения вида, не указаны строки, которые вы собираетесь удалять, указывая их в пред-ложении WHERE у инструкции DELETE. Поэтому для запрещения удаления строк, которые не удовлетворяют условию WHERE приме-нять опцию WITH CHECK OPTION не обязательно. Невозможно уда-лить строку из таблицы посредством вида, если столбец, заданный в предложении WHERE инструкции DELETE, не указан в определении вида. Строки можно удалять непосредственно из таблицы, входящей в определение вида. Любые изменения, сделанные посредством вида, будут выполнены в таблице, указанной в определении вида.

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

представления могут создаваться только в той базе данных, которую вы используете, хотя к представлениям можно обращаться и из других баз – для этого надо ввести полно-стью определенное имя представления;

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

154

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

представление может содержать до 1024 столбцов (рань-ше – 255);

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

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

7.7. Хранимые процедуры и функции

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

Хранимые процедуры могут быть четырех типов: системные (System), локальные (Local), временные (Temporary) и удаленные (Re-mote).

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

155

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

Локальные хранимые процедуры создаются в пользовательских базах данных. Если процедура создается с именем # или ##, то полу-чаете временную хранимую процедуру, помещаемую в базу данных tempdb. Процедуры, начинающиеся с ## – глобальные, они видны лю-бой сессии связи с данным сервером. Процедуры с одним # – локаль-ные и видны только из соединения, в котором они созданы. Когда со-единение, в котором создана процедура, закрыто, процедура автоматически уничтожается.

Удаленные процедуры могут вызываться не только с текущего сервера, с которым клиентское приложение установило соединение. При этом текущий сервер является промежуточным звеном. Есть еще один тип хранимых процедур – расширенные хранимые процедуры. Они принципиально отличаются от перечисленных. Это DLL, как пра-вило, написанные на С, и называются хранимыми только потому, что имя хранится в базе данных SQL Server. Сами DLL хранятся как файлы в соответствующем каталоге ОС.

Для создания хранимой процедуры используется команда: CREATE PROC[EDURE] <имя процедуры> [;< число>] [@ имя_параметра тип_данных [VARYING] [=<значение>]

[OUTPUT] [, …] [WITH {RECOMPILE | ENCRYPTION}] [FOR REPLICATION] AS <инструкции SQL>. Здесь [; число] – задает номер версии вашей же программы с тем

же именем; @параметр – параметр, передаваемый или получаемый из про-

цедуры. Процедура может иметь до 1024 параметров. Параметры мо-гут принимать значения NULL. Параметр может относиться к любому типу данных, в том числе TEXT, IMAGE, CURSOR. Для параметра ти-па CURSOR ключевые слова VARYING и OUNPUT являются обяза-тельными;

156

VARYING – означает, что параметр возвращает итоговый набор, используется только для типа данных CURSOR;

<Значение> – определяет значение параметра по умолчанию. Может быть любой константой или NULL;

OUNPUT – означает, что параметр является выходным, то есть может возвращаться стороне, вызвавшей процедуру. Параметры типа CURSOR обязаны быть выходными;

With RECOMPILE – процедуры будет повторно компилировать-ся при каждом выполнении;

FOR Replication – опция позволяет выполнить процедуру в про-цессе репликации.

Нельзя применять опцию WITH RECOMPILE в инструкции Cre-ate Procedure, содержащей опцию FOR Replication. Эту опцию приме-няют для создания процедуры, которая выполняется в режиме репли-кации.

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

Ограничения: процедуры не могут содержать команд ALTER TABLE, CREATE INDEX, CREATE TABLE, DROP TABLE, DROP IN-DEX, TRANCATE TABLE, UPDATE STATSTICS.

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

EXEC[UTE] [@код возврата] <имя процедуры> [;<число>] [@список параметров] [WITH RECOMPILE]. Здесь код возврата – переменная для сохранения кода возврата

процедуры, номер – числовой идентификатор процедуры, при его отсутствии

выполняется процедура с максимальным номером версии. Удаление хранимой процедуры:

Drop procedure <имя_хранимой процедуры>.

157

Процедуры могут встраиваться внутрь других процедур. Воз-можно до 16 уровней вложенности. Модификация хранимых процедур осуществляется командой:

ALTER PROC[EDURE] имя процедуры [; число] [@ имя_параметра тип_данных [VARYING] [=значение] [OUT-

PUT] [, …] [WITH {RECOMPILE | ENCRYPTION}] [FOR REPLICATION] AS ИНСТРУКЦИЯ_SQL [ RETURN [код статуса]].

7.8. Управление триггерами и транзакциями

Триггер – это объект базы данных, являющийся специальным ти-пом хранимой процедуры, которую SQL Server выполняет при опера-циях в данной таблице. Триггеры выполняют после применения пра-вил, значений по умолчанию и обеспечивают ограничения целостности на уровне строк, обеспечивает ссылочную целостность в базе данных. Выполнение любой команды модификации приводит к срабатыванию триггера.

Для создания триггера нужно быть владельцем базы данных. Триггеры делятся на триггеры вставки, обновления или удаления. Ко-манда создания триггера:

Create Trigger <имя триггера> ОN <имя таблицы> FOR {insert, UPDATE, Delete} AS <команды sql> [RETURN]

При создании триггера можно задать одну, две или три опера-ции. В случае выбора нескольких операций их следует разделить запя-тыми. SQL Server ограничивает типы инструкций SQL, которые могут быть выполнены при работе с триггером. Большинство ограничений связаны с тем, что в случае возвращения в начальное состояние ре-зультатов работы операций обновления, добавления и удаления, вы-

158

звавших активизацию триггера, результаты выполнения инструкций внутри триггера откатить невозможно. Триггер не может использовать: все команды Create, все инструкции удаления Drop, объектное разре-шение доступа: Grand и Revoke, Update Statistics, Reconfigure, опера-ции загрузки Load Database, Load transaction, инструкции физической модификации диска: Disk, временное создание таблиц Select into. Нельзя создавать триггер для вида, а только для базовой таблицы или таблиц. Любая правильная операция Set работает только в период су-ществования триггера. После завершения работы триггера все уста-новки возвращаются в прежнее состояние. Не следует применять опе-рацию select, возвращающую результирующие наборы из триггера, для приложения клиента, требующего специального управления результи-рующими наборами, независимо от того, делается ли это в хранимой процедуре или нет. Тщательно проверьте, все ли операции select счи-тывают свои значения в локально определенные переменные, доступ-ные в триггере. Удаление триггера: Drop trigger < имя триггера>.

Триггеры могут встраиваться друг в друга. Доступно 16 уровней вложенности. Триггеры становятся вложенными, когда выполнение одного триггера модифицирует таблицу, что вызывает к работе другой триггер. Триггер может вызвать бесконечный цикл. Например таблица А имеет триггер TR_A, который выполняется при обновлении таблицы А. При выполнении триггер А вызывает обновление таблицы В. Эта таблица включает триггер В, который выполняется, когда обновляется таблица В и вызывает обновление таблицы А. Таким образом, если пользователь обновляет любую из этих двух таблиц, два триггера про-должают бесконечно вызывать выполнение друг друга. При возникно-вении такого состояния SQL Server закрывает или отменяет выполне-ние триггера. Если триггер вызывает дополнительную модификацию своей базовой таблицы, это не приводит к его рекурсивному выполне-нию. В этой версии SQL Server нет поддержки повторной (reentrant) или рекурсивной (recursive) хранимой процедуры или триггера.

SQL Server выполняет транзакции автоматически, но системный администратор может управлять ими с помощью опций команды select, установить уровень изолированности пользователей с помощью ко-

159

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

Определение уровня изолированности пользователей:

SET TRANSACTION ISOLATION Level Read Commited.

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

Этот уровень изолированности устанавливается по умолчанию. Команда

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITED

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

SET TRANSACTION ISOLATION REPEATABLE READ.

Отсутствие повторяемого чтения – это 3-й уровень изолирован-ности пользователей, наиболее эксклюзивный (до завершения транзак-ции1 транзакция2 изменяет объект А и успешно завершается, транзак-ция 1 повторно читает объект А и видит его измененное состояние). Этот уровень изолированности гарантирует неизменность читаемых вами данных и невозможность влияния на ваши данные со стороны любой выполняемой другим пользователем транзакции в течение вре-мени вашей жизни. Этот уровень сильно снижает параллельность дос-тупа к данным и используется не часто:

SET TRANSACTION ISOLATION LEVEL SERIALZABLE.

160

Обеспечивает 4-й уровень изолированности – отсутствие карте-жей – фантомов (транзакцию 1 выполняет оператор А выборки карте-жей R с условием выборки S, до завершения транзакции 1, транзакции 2. Вставляет в R запись, удовлетворяющую условию S, тогда при по-вторении выборки читается новая запись в транзакции 1).

В SQL Server реализован гранулированный метод синхронизаци-онных захватов.

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

SQL Server дает возможность изменять пороговый уровень бло-кировок от одной страницы до таблицы. Максимальный порог блоки-ровки – это максимальное число блокированных страниц перед пере-ходом на табличную блокировку, даже если процентный порог расширения блокировки не пройден. Значение порога по умолчанию – 200 страниц. Есть понятие минимального порога блокировки. Таблич-ная блокировка произойдет, только если будут достигнуты минималь-ный порог и процентный порог расширения. Минимальный порог расширения блокировки предотвращает переход к табличной блоки-ровке для маленьких таблиц, там, где процентный порог расширения достигается часто. Значение по умолчанию – 20 заблокированных страниц. Процентный порог расширения указывает процент заблоки-рованных страниц, необходимый для перехода на табличную блоки-ровку. Значение по умолчанию – 0, что указывает на возможность таб-личной блокировки только при достижении максимального порога расширения. Процедура sp_configure позволяет установить 3 типа по-рогов распространения блокировок. Переход к табличной блокировке называется экскалацией.

Экскалация произойдет при превышении процентного порога блокировки и достижении минимального порога. Действие процентно-

161

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

Управление блокировками на уровне команды Select, указывая опции оптимизатора Nolock, UpDlock, Tablock, Paglock и Tablockx:

Nolock –отменяет разделяемые блокировки и не принимает во внимание монопольные при исполнении команды, т.е. позволяет чи-тать «грязные данные», аналогична установке уровня Read UNCommit-ted, но действует только в рамках одной команды.

UPDLOCK – указывает на применение блокировок обновления вместо разделяемых. Позволяет не перекрывать другим процессам дос-туп на чтение, но к моменту изменения данных позволяет быть уве-ренным, что модифицироваться будут именно считанные ранее дан-ные.

Tablock – поднимает разделяемую блокировку на уровень таблицы. В случае UPDATE равнозначно директиве Tablockx. Tablockx – налагает монопольную блокировку на таблицу. Paglock – задает страничную блокировку. В сочетании с

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

Rowlock – блокировка на уровне записей. Но при достижении заданного порога экскалации блокировка пе-

реводится на уровень таблицы. В команде Select указания оптимизато-ру устанавливаются следующим образом:

Select <список выбора> FROM имя таблицы1| вида[(указание оптимизатору)], имя таблицы n| вида [(указания оптимизатору)]. Создание транзакций реализуется командой: Begin TRAN [SACTION] <инструкции TR.SQL> [ROLLBACK TRAN[SACTION]] COMMIT TRAN[SACTION].

162

При появлении команды begin Tran сервер помечает в журнале транзакций базы данных точку возвращения, которая будет использо-ваться в случае отката транзакций.

Ключевое слово COMMIT TRAN приводит к тому, что все, что было сделано в транзакции, будет реализовано в базе данных.

ROLLBACK Tran – отменяет все инcтрукции. Нельзя внутри транзакции использовать команды: Create всех видов, DROP всех ви-дов, Alter, Crant и Revoke, Select INTO, TRUNCATE TABLE. Для рабо-ты с большими транзакциями используются именованные транзакции и точки сохранения.

7.9. Диагностика и сбор данных. Оптимизация запросов

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

Стоимость запроса – оценка предполагаемого количества и объема операций ввода/вывода, исходя из предполагаемого количества возвращаемых записей. При этом используется информация о структу-ре данных, размерах таблиц и индексах, индексная статистика.

Исполнение запроса включает 5 этапов: 1. Синтаксический разбор, состоящий из проверки SQL – пред-

ложений и формирования обрабатываемой далее структуры – дерева запроса.

2. Стандартизация – преобразование дерева запроса с целью уда-ления избыточных структур (например, Between преобразуется в ин-тервал, IN в OR и т.д.).

3. Оптимизация – выработка плана исполнения запроса. 4. Компиляция – перевод выбранного плана в исполняемый код. 5. Исполнение запроса. Процесс оптимизации запроса включает этапы: 1) анализ запроса, 2) выбор индексов, 3) выбор порядка соедине-

ния, 4) выбор наилучшего плана, 5) анализ запроса.

163

Анализ запроса включает определение аргументов поиска, усло-вий или (OR), условий межтабличного соединения (Join).

Цель определения аргументов поиска – установление возможно-сти использования индексов. Аргументом поиска является условие, позволяющее сузить область поиска данных. К таким относятся усло-вия, задаваемые простыми операторами сравнения (=, >, <, >=, <=), где сравниваются поля и константы. Условия поиска можно объеди-нить оператором конъюнкции (AND). Несколько объединенных усло-вий могут быть признаны аргументами поиска, если все поля, участ-вующие в сравнениях, принадлежат одной таблице.

Не является аргументом поиска условие – А/12>=300, не явля-ется аргументом поиска и сравнение двух полей А=В, не являются аргументами поиска и условия с наличием в сравнении отрицания – NOT, NOT IN(), <>; (!=), NOT EXISTS, так как условие отрицания не позволяет ограничить область поиска, а наоборот, требует проверки каждого конкретного значения на предмет удовлетворения условию (может иногда переписать условие, избежав отрицания А<>0. А типа tinyint=> A>0).

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

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

Условие Избирательность = 100%

164

одностороннее сравнение(<,>) 33% интервал 25%

Статистическая страница не создается, если индекс строится на основе таблицы, в которой нет данных. При выполнении команды TRUNCATE TABLE уничтожаются все статистические страницы для индексов данной таблицы. Чтобы создать статистическую страницу, следует выполнить команду UPDATE STATISTICS. Для каждого ин-декса оптимизатор строит одну статистическую страницу и включает диаграмму распределения и плотность индекса. Статистическая стра-ница имеет объем 2 Кб. Диаграмма – это гистограмма. Количество ша-гов равно длине сводного пространства 2016 байт, делится на длину строки шага = 2 байта (под номер шага)+количество байт под значение ключа (тип индекса). Затем число строк делится на количество шагов. В каждый шаг попадает определенное количество значений индексов. Если в запросе задано условие равенства и имеется уникальный ин-декс, то количество искомых записей по определению не больше 1. При этом оптимизатор полагает количество отбираемых записей еди-ницей и не обращается к статистике независимо от ее наличия. Оценив количество записей в таблице, предположительно удовлетворяющих условию запроса, оптимизатор рассчитывает количество логических чтений страниц, необходимое для их считывания. Число страниц, ко-торые должны быть прочитаны, зависит не только от количества запи-сей, но и от метода доступа, выбранного оптимизатором, для получе-ния этих записей. Оптимизатор производит расчет для всех возможных методов доступа. Количество логических чтений для него равно обще-му количеству страниц данных в таблице. Если возможно применение кластерного индекса, расчет производится по формуле

Logic_Reads=Cl_IndLevels+N_Data_Pages, где Количество Кол-во уровней предполагаемое логических кластерного кол-во страниц чтений индекса данных = целочисленному кол-ву выбранных за-

писей/ среднее кол-во записей на странице данных. Среднее кол-во записей на странице во всех формулах определя-

ется по таблице Sysindexes. Если применяется некластерный индекс, модель расчета меняется. SQL Server считывает ключевые значения с

165

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

Logical_Reads=N_Ind_Levels+N_Ind_Pages+N_Records N_Ind_Levels – количество уровней некластерного индекса. N_Ind_Pages – кол-во страниц нижнего индексного уровня =

оценочное кол-во выбранных записей /среднее количество записей на странице нижнего индексного уровня/

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

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

Оптимизатор рассматривает возможные варианты, оценивает не-обходимое количество чтений и выбирает наименее затратный путь. Версия 6.5 использует только одну технику соединения – «вложенные циклы». Многотабличный запрос в принципе обрабатывается следую-щим образом: таблицы выстраиваются в определенном порядке. Таб-лица, обрабатываемая первой, называется внешней (Outer), остальные таблицы называются внутренними (inner). Любые соединения таблицы в цепи являются по отношению друг к другу внешней и внутренней. Первую таблицу в цепи часто называют самой внешней (outermost). Выполняется проход на самой внешней таблице. Для каждой записи внешней таблицы из внутренней выбираются записи, удовлетворяю-щие условиям соединения и другим табличным ограничениям. Про-

166

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

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

7.10. Удаленный доступ к данным

Существует два способа обращения к данным, находящимся на разных серверах: удаленный вызов процедур(RPC) и распределенные запросы. Удаленный вызов процедур (RCP, remote procedure call) ис-пользуется для доступа к данным, которые находятся на другом SQL Server. Для того чтобы стал возможным RCP, оба сервера необходимо настроить на взаимодействие друг с другом. Для этого имена локаль-ного и удаленного сервера должны быть зарегистрированы с помощью хранимой процедуры:

Sp_addserver @server = ‘сервер’ [, @local=’локальный’|NULL], где @server – имя сервера, @local – определяет, является ли сервер локальным. Если уста-

новлено значение ’локальный’, то сервер считается локальным, если NULL, то удаленным.

Затем выполняется настройка только системным администрато-ром RCP. По умолчанию настройка SQL Server позволяет ему как при-нимать, так и производить вызовы RCP. Для изменения этих настроек можно воспользоваться процедурой:

Sp_configure ‘remote access’,[1|0] Reconfigure.

167

При параметре 1 разрешен доступ к данному серверу, при 0 дру-гие серверы не могут обращаться к этому серверу. Характер взаимо-действия можно определить с помощью процедуры:

Sp_serveroption @server = ‘сервер’ [,@optname = ‘наименование параметра’] [,@optvalue = ‘значение параметра’], где наименование параметра, значение параметра ‘rcp’, ‘rcp out’ ‘true’, ‘false’. Если вы устанавливаете для ‘rcp’ значение ‘true’, то локальный

сервер сможет принимать вызовы RCP от серверов, определенных в параметре @server. Если то же значение будет установлено для ‘rcp out’, то локальный сервер сможет посылать вызовы RCP на серверы, определенные в аргументе @server. После того как серверы настроены, можно осуществлять удаленное выполнение хранимых процедур, ис-пользуя их полные имена:

Exec[ute] имя сервера.[база данных].[владелец].имя хранимой процедуры [параметр [,параметр…]].

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

Распределенные запросы позволяют обратиться к данным из не-скольких источников в одном запросе. Распределенный запрос выпол-няет на локальном сервере команду SQL, которая влияет на данные удаленного сервера. Перед использованием распределенных запросов подключение должно установить флаги ANSI_NULLS AN-SI_WARNINGS: SET ANSI_NULLS ON, SET ANSI_WARNINGS ON.

Связанный сервер представляет собой заранее сконфигурирован-ный источник данных OLE DB. Команды SQL ссылаются на связанный сервер по полному имени объекта. Перед использованием связанного сервера необходимо предварительно настроить локальный сервер на работу с удаленным источником. Полное имя объекта выглядит сле-дующим образом: Имя сервера.имя базы.имя владельца объекта.имя объекта.

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

168

командах SQL вместо таблицы или представления. Функция OPENQUERY предназначена для выполнения сквозных запросов в ис-точниках данных OLE DB: Openquery(связанный сервер,’запрос’).

Локальный сервер предварительно должен быть настроен на ра-боту со связанным сервером:

1) сначала связанный сервер надо добавить с помощью процеду-ры

sp_addlinkedserver @server=’сервер’ [,@srvproduct = ‘наименование программного продукта’] [,@provider = ‘драйвер соединения’] [@datasrc = ‘источник данных’] [@location =’местонахождение’] [,@provstr = ‘строка драйвера’] [@catalog = ‘каталог’]. Здесь: @server – имя связанного сервера, @srvproduct – наименование программного продукта, если он

указан, то остальные параметры указывать не обязательно, @provider – уникальный программный идентификатор обработ-

чика OLE DB для источника данных, который должен быть зарегист-рирован в реестре,

@datasrc – имя источника данных, известное обработчику OLE DB,

@location – местонахождение базы данных, известное обработ-чику OLE DB

@provstr – специфическая для провайдера OLE DB строка, кото-рая идентифицирует уникальный источник данных,

@catalog – каталог, используемый при установлении соединения с провайдером OLE DB.

Имеется ещё одна функция, которую можно использовать, если заранее источник не создан:

OPENROWSET(‘имя провайдера’ {‘ источник данных’ ; ‘ идентификатор пользователя’ ; ‘пароль’|

‘строка драйвера’} {[Каталог.] [структура.] объект| ‘запрос’}).

169

При работе с удаленными данными происходят преобразования типа данных и кодировки, используемых на локальном сервере. При выборке данных командами SELECT, UPDATE, INSERT, DELETE удаленные данные преобразуются в тип данных и кодировку локально-го сервера. При модификации данных данные локального сервера пре-образуются к типу данных и кодировке удаленного сервера.

Если кодировка удаленных данных отличается от кодировки ло-кального сервера, результаты запроса могут оказаться бессмысленны-ми. В распределенных запросах разрешаются команды SELECT, со-стоящие только из секций SELECT, FROM, WHERE.Секция INTO разрешается при условии, что создаваемая таблица находится на ло-кальном сервере. Команды UPDATE, INSERT, DELETE должны соот-ветствовать требованиям OLE DB на удаленном сервере. При работе с удаленной таблицей с помощью курсора секция обновления и удале-ния WHERE CURRENT OF может выполняться лишь в том случае, если провайдер OLE DB поддерживает данную возможность. Команды полнотекстовой обработки не функционируют в распределенных за-просах. Команды CREATE, DROP, ALTER не могут использоваться для удаленных серверов. Курсоры типа STATIC, INSENSITIVE могут ссылаться на удаленные таблицы. Курсоры типа KEYSET могут ссы-латься на удаленные таблицы лишь в том случае, если провайдер OLE DB соответствует требованиям, документированным в описании функ-циональных возможностей курсоров KEYSET. Курсоры FOR-WARD_ONLY не работают с удаленными таблицами.

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

Begin distributed transaction [<имя транзакции>].

170

Глава 8. АДМИНИСТРИРОВАНИЕ БАЗ ДАННЫХ НА ПРИМЕРЕ SQL SERVER

8.1. Система безопасности. Аутентификация. Учетные записи и роли. Планирование разрешений

Для доступа к данным в SQL Server имеются следующие уровни защиты: операционная система, SQL Server, база данных, объектов базы данных. Для доступа к объектам и данным пользователь проходит два уровня проверки безопасности – уровень аутентификации и уро-вень проверки разрешений.

Аутентификация пользователя – процесс допуска или недопус-ка к соединению с SQL Server. В SQL Server существует два режима контроля проверки возможности подключения: на уровне с SQL Server с SQL Server (SQL Server authentication) и смешанная система на уров-не SQL Server и Windows NT (Windows NT authentication). В первом случае задаются имя пользователя для входа (учетная запись) и пароль во время соединения. Во время установки SQL Server создается только одна учетная запись – sa. Эта учетная запись имеет все права на доступ ко всем объектам всех баз данных. Добавить новую учетную карточку можно с помощью мастера создания нового пользователя SQL Server Security Wizard или New Login через Security дерева административной консоли, либо с помощью системной хранимой процедуры: Sp_addlogin . Удаление имен пользователей для входа:

Sp_droplogin ‘имя пользователя для входа’. Изменение паролей: Sp_password ‘старый пароль’,’новый пароль’,’учетная запись

пользователя для входа’. Аутентификация со смешанной системой безопасности предос-

тавляет пользователю использовать имена и пароли, которые исполь-

171

зуются в сети. Это же можно сделать с помощью системной хранимой процедуры

Sp_grantlogin ‘учетная запись для входа’. Запретить подключение’: Sp_denylogin ‘учетная запись для входа’. Роль – именованный набор прав в рамках сервера или конкрет-

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

Встроенные серверные роли: Sysadmin – системный администратор (может выполнять любые

действия с SQL Server); Securityadmin – администратор безопасности (управляет учетны-

ми записями сервера); Serveradmin – администратор сервера (управляет настройками

сервера); Setupadmin – администратор установки (добавляет и удаляет свя-

занные серверы); Processadmin – администратор процессов (осуществляет управ-

ление процессами); Diskadvin – администратор дисков ( осуществляет управление

файлами ); Dbcreator – создатель баз данных ( создает и изменяет их пара-

метры). Присвоение встроенной роли можно осуществить с помощью ви-

зарда или системной хранимой процедурой: Sp_addsrvrolemember ‘учетная запись пользователя’,’роль’

Отмена роли: Sp_dropsrvrolemember ‘учетная запись пользовате-ля’,’роль’

Просмотр информации о встроенных ролях: Sp_helpsrole, sp_helpsrvrolemember.

Встроенные роли баз данных: Db_owner – владелец базы данных (может выполнять любые

операции с базой данных);

172

Db_accessadmin – администратор доступа к базе данных (добав-ляет и удаляет пользователей базы данных);

Db_securityadmin – администратор безопасности базы данных (управляет ролями в базе данных и разрешениями на запуск команд и на работу с объектами базы данных);

Db_ddladmin – администратор DLL (добавляет, изменяет и уда-ляет объекты базы данных);

Db_backupoperator – администратор резервного копирования (осуществляет резервное копирование базы данных);

Db_datareader – лицо, имеющее право на просмотр базы данных; Db_datawriter – лицо, имеющее право изменять старые данные и

вносить новые; Db_denydatareader – лицо, которому запрещен просмотр данных; Db_denydatawriter – лицо, которому запрещено изменение дан-

ных. Для добавления пользовательских ролей (добавить новую сер-

верную роль нельзя), а не встроенных, можно воспользоваться систем-ной хранимой процедурой, для которых сделать впоследствии ряд раз-решений:

Sp_addrole ‘роль’,’владелец’. Удаление пользовательской роли: Sp_droprole ‘роль’. В каждой базе данных имеется специальная роль – роль public.

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

Кроме пользовательских ролей можно создавать роли приложе-ний. Эти роли нельзя присвоить пользователям. Чтобы использовать предоставленные этой ролью разрешения, её вначале надо активизиро-вать.

Роли приложений создаются хранимой процедурой: Sp_addapprole ‘роль’,’пароль’. После этого роль приложения активизируется хранимой проце-

дурой:

173

Sp_setapprole ‘имя роли’, ‘пароль’. Применяя роль приложения (иногда говорят прикладную роль),

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

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

Для каждого объекта могут быть предоставлены различные ти-пы разрешений: Select – таблица, вид (читать), Update– таблица, вид (изменять), INSERT– таблица, вид (добавлять), Delete– таблица, вид (разрешает удалять данные), References– таблица (дает возможность пользователю обращаться к таблице или виду посредством предло-жения where), EXECUTE–хранимая процедура (разрешает пользова-телю выполнять хранимую процедуру), ALL – предоставляет любые разрешения.

Типы разрешений Select, UPDATE, INSERT, Delete используют-ся часто. Они определяют возможность пользователя выполнять ко-манды, в опции FROM которых перечислены такие объекты, как таб-лицы или представления, к которым пользователь должен иметь доступ. Тип разрешения Reference управляет доступом пользователя к поддержке целостности данных. На практике это необходимо только в том случае, когда требуется установить отношение между двумя объ-ектами, имеющими разных владельцев. Тип разрешения EXECUTE позволяет пользователю выполнять хранимые процедуры. Таким обра-зом, пользователь может выполнять какие-либо действия, определяе-мые хранимыми процедурами, но не имеет доступа непосредственно к

174

данным таблиц или представлений. Разрешить или запрещать доступ к объектам базы данных может владелец объекта.

Командные разрешения: возможность выполнять следующие команды: Create Database, Create Default, Create Procedure, Create Table, Create View, Backup Database, Backup Log, ALL. Командные разреше-ния могут представляться системным администратором или владель-цем базы данных. Разрешение на создание временных таблиц не требу-ется. Наиболее простой путь – предоставление или запрещение действий группам пользователей. Рекомендуется следующая последо-вательность при предоставлении разрешений: предоставьте соответст-вующие разрешения группе public, предоставьте соответствующие разрешения другим группам, которые находятся в иерархии ниже сис-темной группы public, предоставьте соответствующие разрешения от-дельным пользователям.

Предоставление прав осуществляется с помощью команды: Grant ‘список_прав доступа’ |All ON [‘таблица’| ‘вид’ [(‘столбец’, …)] | ‘хранимая процедура ’] TO список_имен ролей или учетных записей | PUBLIC. Удаление прав осуществляется с помощью команды: REVOKE список_прав_доступа ON имя_объекта TO список_имен. Здесь Список_прав_доступа – права через запятую или ALL. Имя_объекта – таблица, вид или хранимая процедура, для кото-

рой предоставляется или уничтожается разрешение. Запрещение доступа к объектам: DENY { ALL | ‘список разрешений’} TO ‘учетная запись’. Ограничения на использование разрешений: только собственник объекта имеет по умолчанию к нему

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

175

запрет доступа пользователю, группе или роли имеет при-оритет над любым разрешением;

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

имена пользователей, имена ролей, паролей должны иметь размер от 1 до 128 символов, не должны содержать обрат-ных слэшей;

имена пользователей, паролей, ролей не должны совпадать с ключевыми словами и встроенными именами пользова-телей SQL Server.

8.2. Репликация данных. Типы репликаций

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

Задержка – это интервал между обновлением распределенных данных. Распределенные транзакции характеризуются практически нулевой задержкой. При репликации возможны задержки от несколь-ких секунд до нескольких дней.

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

176

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

Репликация (тиражирование) – это операция пересылки ин-формации из источника в место назначения. Тиражируя, администра-торы могут защитить свою информацию или же, наоборот, сделать ее доступной для других. Например: 1)Запросы пользователей выполня-ются долго. Если администратор знает, что пользователям нужна ин-формация, «возраст» которой не превышает двух часов, чтобы «по-местить» данные в этот двухчасовой промежуток, можно воспользоваться средством тиражирования. Создать вторичный сер-вер, первичный сервер будет ему посылать данные каждые 30 минут, и пользователи будут обращаться к вторичному серверу, не влияя на первичный сервер. После установки и конфигурирования вторичного сервера запросы пользователей выполняются быстрее. 2)Например, есть распределенное финансовое приложение. Самые важные данные хранятся в таблице налогов, которую обслуживает центральный офис. Эта таблица большая и часто изменяется. Администратор должен об-служивать локальные копии этой таблицы на каждом отдельном уда-ленном узле, его интересуют только ставки налогов его региона. При-чем информация всегда должна быть свежей. Для этого используется тиражирование, причем не всех данных, а устанавливается горизон-тальное тиражирование с возможностью посылать только нужную информацию на удаленные серверы. 3) Одно из преимуществ тиражи-рования – это то, что на сервере-подписчике тиражирование таблицы имеет свойство “только для чтения”, позволяющее защитить целост-ность данных.

Терминология тиражирования.

177

1. Немедленная гарантированная согласованность (жесткая со-гласованность) – изменение БД, являющейся источником, немедленно передается в базу – адресат.

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

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

3. Издатель (Published) – сервер с исходной базой данных. Изда-тель у любого подписчика только один. Схема множественного изда-ния не реализуется в SQL Server.

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

Начиная с SQL Server 6.5 можно тиражировать данные в любую базу данных, имеющую драйвер ODBC, а не только в базе данных SQL-сервера.

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

178

(distribution database) и рабочий каталог распространения (distribution working folder).

6. Статья (Article)- это единый реплицируемый элемент данных. В качестве статьи может выступать: таблица (при снимочной репликации может реплициро-

ваться схема таблицы, включая триггеры, а также данные таблицы);

набор полей таблицы (вертикальная фильтрация); набор записей таблицы (в случае горизонтальной фильтра-

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

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

7. Публикация – это набор статей, предназначенных для тиражи-рования. Каждая тема представлена отдельной статьей.

8. Подписка – это конфигурация, определяющая способ получе-ния подписчиком публикации от издателя. Существует два вида под-писок: активные и пассивные. Подписка, которая создается и управ-ляется на сервере-издателе, называется пассивной (её создает сервер-издатель, на любую публикацию можно подписать сразу несколько подписчиков). Подписка, созданная на подписчике, называется ак-тивной (её создает сервер-подписчик, для использования активных подписок сервер, на котором находится публикация, должен быть постоянно подключен к сети). Активные подписки бывают стандарт-ными (регистрируются на сервере-издателе) и автономными (полно-стью настраиваются на сервере-подписчике, и информация на изда-теле не хранится). Последнее идеально подходит для подписчиков, подключающихся через Интернет. Такие подписчики могут подклю-чаться по протоколу FTP.

Для хранения информации тиражирования SQL-сервер исполь-зует специальную БД, называемую БД распределения(distribution da-tabase)-тиражируемая информация содержится в ней до тех пор, пока не будет передана нужным подписчикам. Пользователи не имеют доступа к этой БД: она предназначена только для работы системы. В

179

этой базе имеются таблицы 1) Msjob_commands-в каждой транзакции имеется одна или несколько команд. В этой таблице хранятся записи о таких командах (в этой таблице столбцы – номер сервера-издателя, имя опубликованной БД, идентификатор задания(job), идентифика-тор команды, номер статьи, реальная команда (строка)). 2) Msjob_subscriptions-используется для контроля за тем, какие ста-тьи необходимы конкретным подписчикам (имя подписчика и его номера статей). 3)Msjobs-в этой таблице хранятся реальные транзак-ции. 4)Mssubscriber_info-подробная информация о заданиях тиражи-рования, которые должен выполнить SQL Server(тип подписчика: (0-SQL Server; 1-ODBC; идентификатор регистрации; сколько времени должно пройти до момента, когда транзакции будут переданы подпис-чикам). 5)Mssubscriber_jobs-обеспечивает взаимосвязь между подпис-чиком и всеми изданиями, которые должны быть выполнены для дан-ного подписчика. 6)Mssubscriber_status-эта таблица контролирует состояние всех изданий, выполняемых для всех подписчиков.

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

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

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

180

распределения и обеспечивает их выполнение в нужном месте назна-чения.

Чтобы сделать репликацию наиболее эффективной, необходимо предусмотреть следующее:

1. Так как сервер-подписчик может сам тиражировать информа-цию, то можно построить многоуровневую архитектуру тиражирова-ния. Многоуровневые среды могут работать быстрее, чем одноуровне-вые, т.к. с помощью промежуточных компьютеров многоуровневая топология может устранить необходимость в дорогостоящих протя-женных соединениях.

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

3. После подписки на публикацию нужно использовать автома-тическую синхронизацию. Этот метод позволяет объединить задачи синхронизации вместо выполнения каждой из них в отдельности после каждой новой подписки.

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

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

181

и если до этого дисковод журнала работал на пределе, система еще сильнее перегружается.

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

7. Зеркально отображать журнал транзакций. 8. Для того чтобы система могла работать в качестве сервера-

издателя или сервера-распределителя, нужны 32 Мбайта ОЗУ, причем минимум 16 Мбайтов д.б. SQL Serverу.

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

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

11. Рекомендуется отменять проверку ограничения «внешний ключ» добавлением опции Not For Replication в операторы Create Table и Alter Table, т.к. проверка занимает некоторое время.

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

Репликация-дублирование, тиражирование информации между серверами.

Виды реплицируемых данных(виды статей): 1) целые БД(entire database); 2) целые таблицы(entire tables); 3) горизонтальные разделы(horizontal partitions) информации;

182

4) вертикальные разделы(vertical partitions); 5) выборочные виды(custom views).

1. Если статья – целая БД, то SQL Server осуществляет отслежи-вание любой активности, связанной с этой БД, и предоставляет ин-формацию об изменениях. Для администратора это самый простой способ передачи информации.

2. При репликации целых таблиц определяется таблица, за кото-рой производится слежение. Любые изменения, сделанные в этой таб-лице, пересылаются с помощью ядра репликаций(replication engine) в приемный сервер.

3 и 4. При издании горизонтальных разделов таблиц применяется инструкция select, которая выбирает все столбцы информации, но только определенные строки репликации. Вертикальная репликация-выбор только определенных столбцов информации. Возможна комби-нация вертикальных и горизонтальных разделов.

5. Можно реплицировать виды. Если распределение и издание комбинируется на одном сервере,

то на нем необходимо иметь 32 Mb ОЗУ. Столбцы типа text или image не подлежат тиражированию. В ти-

ражировании не могут участвовать следующие объекты: БД model, tempdb, msdb и системные таблицы master, таблицы без первичного ключа, таблицы с типом поля timestamp.

Если инициатива на тиражирование со стороны сервера публи-каций – «проталкивание подписки», если со стороны сервера подпис-ки-«вытягивание подписки».

В SQL Server различают следующие виды репликаций: снимоч-ная репликация, транзакционная репликация, репликация сведением (слиянием).

Снимочная репликация (репликация моментальных снимков) – периодическая рассылка всей публикации серверам-подписчикам. Это самая простая в настройке и сопровождении репликация (snapshot). Моментальный снимок создается с помощью агента моментальных списков Snapshot Agent, который записывает структуру и данные. За-тем моментальный снимок посылается агентом распределения Distribu-tion Agent, который передает данные подписчикам. Подписчики полу-

183

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

Репликация транзакций – передаются не новые таблицы цели-ком, а только изменения к опубликованным таблицам и команды на исполнение хранимых процедур с соответствующими параметрами. В процессе репликации участвуют агент моментальных снимков Snap-shot Agent, агент распределения Distribution Agent, агент чтения жур-нала Log Reader Agent. Snapshot Agent используется для предоставле-ния подписчикам начального набора данных. Log Reader Agent просматривает журнал транзакций на предмет наличия записей типа insert, update, delete, относящимся к опубликованным объектам, и осу-ществляет их пакетное применение к базе данных распределения. Log Reader Agent может работать постоянно или по графику, определенно-му администратором. Изменения хранятся в базе данных распределе-ния до тех пор, пока Distribution Agent , ответственный за передачу данных подписчикам, не перешлет эти данные. Подписчики могут по-сле этого вносить соответствующие изменения или осуществить пере-направленный вызов процедур в своей базе данных.

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

8.3. Перемещение данных

Управление данными является одной из важных задач системно-го администратора; к процессу управления относятся: передача данных в БД из разных источников; преобразование данных из БД SQL Server в другой формат; распространение данных на другие серверы по сети; загрузка архивной копии данных.

184

1-й способ перемещения данных: Data Transformation Service (DTS) – служба преобразования данных – используется для импорта, экспорта и трансформации данных между разнородными источниками данных. DTS можно использовать с любыми источниками данных, к которым можно обратиться посредством OLE DB. DTS состоит из че-тырех компонентов: мастера импорта DTS, мастера экспорта DTS, соз-дателя пакетов DTS и программных интерфейсов DTS. В DTS напря-мую не поддерживаются языки С, Visual C++, зато Perl, Java, Visual Basic поддерживаются. DTS переносит данные и их структуру. Другие объекты баз данных (триггеры, правила, хранимые процедуры, значе-ния по умолчанию и т.д.) не переносятся. При использовании мастеров DTS можно указать привязку столбцов и информацию по преобразова-нию.

Утилита dtswiz – это программа, которая позволяет запустить DTS из командной строки. При её запуске можно указать некоторые параметры для того, чтобы не отвечать на вопросы экранов мастеров импорта и экспорта:

Dtswiz [{/?|{/n|[/u идентификатор учетной записи пользователя для входа] [/p пароль]}

[/f имя файла ] {/I | /x} {/r драйвер соединения | [/s имя сервера] [/d база данных ] [/y]}}], где

/ f – имя файла экспортируемого или импортируемого; / I – говорит об импорте в таблицу базы данных SQL Server; /x – экспорт из таблицы; / r – указывает драйвер соединения; / s – указывает на экземпляр SQL Server; / u – определяет имя пользователя при соединении; / p – указывает пароль; / n – определяет, что используется доверенное соединение; / d – определяет, какая база данных будет использоваться; / y – во время работы утилиты системные базы данных будут

спрятаны, их не будет ни в списке баз данных получателя, ни в списке источника.

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

185

Bulk insert ‘имя таблицы’ from имя файла данных [опции]. Главное отличие между программой bcp и командой Bulk insert

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

3-й способ: копирование с помощью программы bcp. Утилита Bulk Copy Program (bcp.exe или bcp) используется для

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

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

Bcp <имя таблицы> | <имя вида> | ‘запрос’ {in |out | queryout | format}<файл данных>

[-m максимальное количество ошибок][-f файл форматирования]

[-e файл ошибок] [-F первая строка][-L последняя строка][-b размер пакета] [-n][-c][-w][-N][-6][-q][-C кодировка] [-t разделитель полей] [-r разделитель строк] [-I входной файл][-o файл выхода][-a размер пакета] [-S имя сервера] [-U идентификатор учетной записи пользователя

для входа] [-P пароль] [-T] [-v] [-k] [-E][-h” подсказка [,…n]”]. Здесь имя таблицы – полный путь к ней. Если используется таб-

лица, то указываются параметры: in (из файла в таблицу), out (из таб-

186

лицы в файл), format (предварительно создается файл форматирования, кроме этого должен быть ключ –f). Если указывается запрос, то дол-жен быть параметр queryout. В запросе должна быть одна команда SE-LECT или вызов хранимой процедуры, возвращающий один набор данных:

-m – число ошибок, которые могут возникнуть до прекращения работы bcp. Та строка, при операции с которой произошла ошибка, бу-дет проигнорирована. Значение по умолчанию 10;

-f – указывается файл форматирования; -e – определяет файл ошибок, возникших при выполнении ко-

манды; -F –L используется для определения первой и последней строк.

По умолчанию используются все строки в таблице или файле; -b – определяет количество строк в пакете (по умолчанию пакет

равен размеру всего файла); -n – указывает на необходимость использования родного форма-

та SQL Server; -c – указывает на необходимость конвертировать все типы дан-

ных в текстовый тип. При этом типе хранения считается CHAR, разде-литель между полями – символ табуляции, между строк – символ на-чала строки;

-w – указывает на необходимость конвертировать все типы дан-ных в формат UNICODE;

-N – определяет использовать типы данных SQL для нетекстовых данных. Использование этого параметра в сочетании с –w часто ис-пользуется для переноса с одного экземпляра SQL на другой;

-6 – используется для SQL 6.5 и более ранних; -q – указывает, что название таблицы содержит специальные

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

-C – определяет страницу кодировки символов для текстовых данных. Этот параметр влияет на коды символов > 127 и < 32;

-t – указывает на разделитель между полями. Разделитель между полями по умолчанию – символ табуляции;

187

-r – междустроковый разделитель (по умолчанию – символ нача-ла новой строки);

-I –имя входящего файла ответов; -o –имя исходящего файла, куда будут записаны данные; -a – размер пакета; -S –имя экземпляра SQL Server, к которому подключаются для

выполнения команды; -U – имя пользователя (по умолчанию имя локального пользова-

теля); -P – пароль; -T – определяет, что будет выполнено доверенное соединение (то

есть без указания имени пользователя и пароля); -v –сообщает номер версии и кому принадлежат права на про-

грамму BCP; -k –указывает, что в полях, не имеющих при копировании значе-

ний, будет вставлено NULL (даже если для этих столбцов имеется зна-чение по умолчанию);

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

-h – определяет подсказки при выполнении команды bcp.

8.4. Резервное копирование и восстановление баз данных

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

полное архивирование (или дамп базы данных, содержит все используемые страницы базы данных, full backup) подразумевает соз-дание копий всех страниц с данными в БД, включая все системные

188

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

пошаговое архивирование(incremental backup) предусматри-вает архивирование только журнала транзакций. Другими словами, создается копия только измененных данных;

архивирование таблицы(table backup)-позволяет создать ар-хивную копию отдельной таблицы базы данных. Восстановить отдель-ную таблицу можно и из полного архива БД. Архивирование таблиц следует сочетать с регулярным полномасштабным архивированием данных:

1. Прежде всего при резервном копировании (при архивирова-нии) нужно определить место копии данных или иначе устройство для резервного копирования данных.

2. После того как вы решили, какое устройство вы будете ис-пользовать для резервного копирования, необходимо указать это уст-ройство SQL Server, используя хранимую процедуру sp_addumpdevice:

sp_addumpdevice{‘тип устройства’, ’логическое имя’, ’физиче-ское имя’}

[, { тип контроллера|’состояние устройства’}] тип устройства – определяет тип устройства резервного копиро-

вания. Тип данных, используемый для этого аргумента, – varchar(10), значение по умолчанию не используется, и должно быть выбрано одно из следующих значений:

Disk – жесткий диск Pipe – именованный канал tape – устройство для записи на магнитную ленту

’логическое имя’ – указывает имя устройства резервного копи-рования, которое вы затем сможете использовать в командах BUCKUP и RESTORE. Тип данных для этого аргумента – sysname, он не может принимать значение NULL и не имеет значения по умолчанию. Этот аргумент показывает, каким образом вы будете идентифицировать дамп-устройство непосредственно во время резервного копирования

’физическое имя’ – указывает на физическое местонахождение устройства резервного копирования. Физическое имя должно включать

189

полный путь. Тип данных этого аргумента nvarchar(26), он не может принимать значения NULL и не имеет значения по умолчанию.

Для устройства резервного копирования разрешения должны быть установлены правильно, в противном случае определить и ис-пользовать устройства резервного копирования будет невозможно. Также для того, чтобы определить устройство резервного копирования, вы должны быть в базе данных master, так как устройство резервного копирования – это ресурс, определяемый для всего сервера, и записи о нем должны храниться в таблице sysdevices баы данных master.

Например: Use master Execsp_addumpdevice disk’,’newdumpdev’,’c:\dump\newdump.dat’. После того как определено устройство резервного копирования,

можно создавать резервную копию базы данных. Для этого использу-ется команда BACKUP. Команда создания резервной копии базы дан-ных:

BACKUP DATABASE {база данных|@переменная для базы дан-ных’} to устройство резервного копирования [,…]

[With blocsize – {размер блока|@переменная для размера блока}] [,description={текст|@переменная для текста}] [,differential] [,expiredate={дата|@переменная для даты}|retaindays={количество

дней |@переменная для количества дней}] [,format|noformat] [,unit|nounit] [,mediadescription={текст|@переменная для текста}] [,medianame={имя носителя|@переменная для имени носителя}] [,name={имя набора резервных копий|@переменная для имени

резервных копий}] [,noskip|skip] [,{nounload|unload}] [, restart] [,stats=проценты]. Команда создания резервной копии журнала транзакций: BACKUP LOG {база данных|@переменная для базы данных’}

190

[with no_log|trancate_only}] to устройство резервного копирования [,…] [With blocsize – {размер блока|@переменная для размера блока}] [,description={текст|@переменная для текста}] [,differential] [,expiredate={дата|@переменная для даты}|retaindays={количество

дней |@переменная для количества дней}] [,format|noformat] [,unit|nounit] [,mediadescription={текст|@переменная для текста}] [,medianame={имя носителя|@переменная для имени носителя}] [,name={имя набора резервных копий|@переменная для имени

резервных копий}] [,noskip|skip] [,{nounload|unload}] [, restart] [,stats=проценты], где <устройство резервного копирования> – имя устройства резерв-

ного копирования |disk|tape|pipe; blocsize – размер физического блока в байтах; description –используется для добавления описания к набору ре-

зервных файлов; differential –определяет, что будет создана резервная копия толь-

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

expiredate – определяет дату, после которой резервная копия счи-тается устаревшей и может быть перезаписана;

retaindays – определяет сколько дней может пройти до момента, когда резервная копия на устройстве может быть перезаписана;

format|noformat – указывает, что может быть создана новая ин-формация о разметке для всех томов, используемых при копировании;

unit –указывает на то, что резервная копия будет первым файлом на диске или магнитной ленте, но сохраняет существующую информа-

191

цию о разметке. При этом вся информация на устройстве резервного копирования будет перезаписана;

nounit – параметр по умолчанию, указывает на то, что новая ре-зервная копия будет добавлена к уже существующей информации на носителях устройств резервного копирования;

mediadescription – добавляет описание носителя в текстовом формате;

medianame – указывает имя носителя (до 128 символов) для всего набора носителей, используемого для резервного копирования;

name – определяет имя резервной копии; noskip – даты устаревания и имена резервных копий должны

быть проверены, прежде чем старые будут перезаписаны |skip – от-ключается проверка дат устаревания и имен;

nounload магнитная лента по умолчанию будет выгружена | un-load – будет автоматически перемотана и выгружена;

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

Stats – выводит сообщение после того, как выполнен процент от всего задания (если процент опущен, то через 10 процентов от общего задания выводится сообщение о резервном копировании);

No_log – удаляет неактивную часть журнала транзакций и обре-зает файл журнала транзакций. Этот параметр освобождает дисковое пространство. При этом необходимости указывать устройство резерв-ного копирования нет, так как резервная копия журнала транзакций создана не будет. После использования этого параметра записи из журнала транзакций не могут быть восстановлены. Поэтому в целях обеспечения возможности восстановления вы должны немедленно вы-полнить команду BACKAP DATABASE;

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

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

192

вание. Для баз данных большого размера полное резервное копирова-ние производится реже, а вместо него выполняются операции по ре-зервному копированию журнала транзакций (который содержит изме-нения, внесенные с момента последнего резервного копирования). Конкретные параметры зависят от того, сколько времени занимает соз-дание резервной копии базы данных и насколько часто в базу данных заносятся изменения. Резервное копирование журнала транзакций про-изводят, когда необходимо освободить занимаемое им дисковое про-странство. Информация о резервном копировании хранится в базах данных master и msdb.

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

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

Во время выполнения резервного копирования базы данных нельзя выполнять команды ALTER DATABASE с ключами ADD FILE, REMOVE FILE, CREATE INDEX, bcp, BULK INSERT, SELECT INTO. Во время резервного копирования можно делать все транзакции, вклю-чая операции без записи в журнал транзакций.

Способ восстановления базы данных зависит от способа созда-ния резервной копии. Если была создана резервная копия только базы данных, то восстанавливаться будет база данных. Если – полная ре-зервная копия, то восстанавливается база данных вместе с журналом транзакции. Для восстановления баз данных и журналов транзакций используется команда RESTORE DATABASE [опции], RESTORE LOG [опции].

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

193

8.5 Автоматизация решения административных задач. Система оповещений

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

создание индексов заново с новым FILLFACTOR; сжатие файлов данных путем устранения пустых страниц в

базах данных; обновление статистики индексов для более эффективного

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

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

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

стратором называются задачами (jobs). Сотрудники, которые ответст-венны за выполнение этих задач, называются операторами (operators). Сообщения о ситуациях, о которых необходимо известить системного администратора, называются оповещениями (alerts). Задачу можно оп-ределить один раз и выполнять многократно.

Настройка автоматизированного администрирования включает пять этапов:

1. Сначала необходимо определить себя как оператора. 2. Затем настроить сервер, на котором нет рабочих баз данных,

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

3. Создать задачу и установить график ее выполнения. 4. Настроить задачу так, чтобы она извещала вас о ходе ее вы-

полнения. 5. После этого запустить службу SQL Server Agent, которая

должна работать для выполнения задач. Для настройки задач можно воспользоваться визардом: Database

Maintenance Plan Wizard. С помощью этого средства указываются имя задачи, время выполнения, формулировка задачи или, пользуясь служ-

194

бой SQL Server Agent, определяются оператор, задача и оповещение. Все эти службы называются диспетчерами. Информацию о необходи-мости выполнения каких-либо заранее спланированных действий служба SQL Executive получает из данных, записанных в системную БД msdb. На их основании запускается один из диспетчеров, которые и составляют основу SQL DMF. Администратор БД может получать по-стоянную информацию о состоянии БД путем определения и после-дующего наблюдения за оповещениями. Например, администратор может получать информацию об остановке сервера или исчерпания свободного пространства БД. С определенным оповещением может быть связана, например, задача расширения пространства, отводимого для размещения БД. Таким образом, создается полностью автоматизи-рованная среда администрирования SQL Server. События часто связы-ваются с ошибками.

195

ЗАКЛЮЧЕНИЕ

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

196

ПРИЛОЖЕНИЕ

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

1 Вариант Создать базу данных «Сведения о жителях города». В базе дан-

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

2 Вариант Создать базу данных «Адресная книга». В базе данных хранятся

сведения о владельце адресной книги, включая информацию о номере паспорта, номере полиса, ФИО, адресе, телефонах. Хранится инфор-мация о родственниках, включая ФИО, адрес, телефон, степень родст-ва, дату рождения. Хранятся сведения о друзьях и знакомых (ФИО, адрес, телефон, место работы, должность). Все сведения ориентирова-ны на одного человека, у которого друзей и родственников может быть много.

3 Вариант Создать базу данных «Аптека». В базе данных хранятся сведения

о лекарстве, включая название, категорию, название фирмы-производителя, название фирмы-поставщика, форму выпуска, вид упа-ковки, количество в упаковке, дозировку, срок годности. Хранится ин-формация об аптеке, включая номер аптеки, адрес, телефон, компания,

197

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

4 Вариант Создать базу данных «Студенческая библиотека». В базе данных

хранятся сведения о книгах, с указанием ФИО авторов, названия кни-ги, места издания. Хранятся сведения об экземплярах книг (инвентар-ный номер). Хранятся сведения о читателях, с указанием номера чита-тельского билета, ФИО, номер группы, телефон, адрес читателя. Хранятся сведения о разделах библиотеки (название раздела (учебный или научный абонемент), номер комнаты). В каждом разделе библио-теки имеется много книг, одна и та же книга хранится в одном разделе. Книга имеет несколько экземпляров. Книга может быть выдана только одному читателю, один читатель может получить несколько книг.

5 Вариант Создать базу данных «Биржа». В базе данных хранятся сведения

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

6 Вариант Создать базу данных «Больница». В базе данных хранятся сведе-

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

198

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

7 Вариант Создать базу данных « Бытовое обслуживание населения». В ба-

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

8 Вариант Создать базу данных «Дума». В базе данных хранятся сведения о

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

9 Вариант Создать базу данных «Перемещения кадров предприятия». В

базе данных хранятся сведения о работниках предприятия, с указани-ем номера паспорта, ФИО, даты рождения, адреса, домашнего теле-фона работника. Хранятся сведения об отделах предприятия, с указа-нием названия отдела, ФИО начальника отдела, телефона,

199

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

10 Вариант Создать базу данных «Повышение квалификации сотрудников».

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

11 Вариант Создать базу данных «Преподаватели кафедры». В базе данных

хранятся сведения о преподавателях, с указанием номера паспорта, ФИО, даты рождения, должности, ученого звания, ученой степени. Хранятся сведения о курсах, с указанием названия курса, вида занятий (лекции, практика, лабораторные, курсовой проект), номера семестра, вида отчетности. Хранятся сведения о группах студентов, с указанием номера группы, названия специальности или направления, количества студентов. Преподаватель может читать несколько курсов с разными видами занятий. Один курс с определенным видом занятий в опреде-ленном семестре читается одним преподавателем. В одной группе изу-чается несколько курсов, один курс может читаться в нескольких группах.

12 Вариант

200

Создать базу данных «Труды кафедры». В базе данных хранятся сведения о преподавателях, с указанием номера паспорта, ФИО, учено-го звания, ученой степени. Хранятся сведения о трудах (название тру-да, место издания, тираж, объем в печатных листах, год издания, цена). Один труд может быть подготовлен несколькими авторами, при этом задается процент участия в изданном труде каждого соавтора. Один преподаватель может подготовить несколько трудов.

13 Вариант Создать базу данных «Квартплата». В базе данных хранятся све-

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

14 Вариант Создать базу данных «Конференция». В базе данных хранятся

сведения об участниках конференции, с указанием номера паспорта, ФИО, даты рождения, организации, адреса, телефона, ученого звания, ученой степени участника. Хранятся сведения о комитетах конферен-ции, с указанием названия комитета, ФИО руководителя, описания по-мещения, телефона руководителя. Хранятся сведения об оплате участ-ников конференции, с указанием номера квитанции, даты оплаты, суммы, способа оплаты. Участник конференции может входить только в один комитет, в одном комитете присутствует несколько участников. Руководитель комитета также является участником конференции. Уча-стник конференции может оплачивать частями несколько раз. В одной квитанции об оплате может быть оплачено участие в конференции не-скольких участников.

15 Вариант

201

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

16 Вариант Создать базу данных «Лекарства». В базе данных хранятся све-

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

17 Вариант Создать базу данных «Нагрузка кафедры». В базе данных хра-

нятся сведения о преподавателях кафедры, с указанием ФИО препода-вателя, должности, общей плановой нагрузки в часах преподавателя. Хранятся сведения о нагрузке преподавателя по предмету, с указанием названия предмета, количества студентов, вида отчетности (зачет, эк-замен), объема лекционных часов, лабораторных часов, практических, курсовых часов. Хранится информация о нагрузке кафедры, с указани-ем названия предмета, количества студентов, объема лекционных ча-

202

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

18 Вариант Создать базу данных «Начисление зарплаты». В базе данных

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

19 Вариант Создать базу данных «Поликлиника». В базе данных хранятся

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

20 Вариант Создать базу данных «Путевки». В базе данных хранится ин-

формация о путевках, с указанием кода путевки, места отдыха, начала, окончания, количества, стоимости. Хранятся сведения о заявлениях на путевки, с указанием ФИО написавшего заявление, о дате подачи, дате

203

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

21 Вариант Создать базу данных «Расписание». В базе данных хранятся све-

дения о преподавателях, с указанием ФИО, должности. Хранятся све-дения о парах, с указанием номера пары, начало1, окончание1, нача-ло2, окончание2. Хранятся сведения о записи в расписании, с указанием недели (первая или вторая), дня недели, номера пары, груп-пы, вида занятий, аудитории. Хранятся сведения о предметах, с указа-нием названия предмета. В расписании учитываются предмет и препо-даватель, его ведущий. Преподаватель может вести занятия в разные дни, в один день несколько преподавателей читают разные курсы.

22 Вариант Создать базу данных «Рецепты приготовления блюд». В базе

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

23 Вариант Создать базу данных «Сведения о сессии». В базе данных хра-

нятся сведения о студентах, с указанием номера зачетки, ФИО студен-та, номера группы. Хранятся сведения о преподавателях, с указанием ФИО преподавателя, названия кафедры, должности. Хранятся сведения о предметах, сдаваемых в данную сессию, с указанием названия пред-мета, вида отчетности (экзамен, зачет, зачет с оценкой). Хранятся све-дения о результатах сдачи студентов группы конкретного предмета конкретному преподавателю. Студенты сдают в сессию несколько предметов, один предмет сдают несколько студентов группы, препода-

204

ватель может принимать в сессию несколько предметов, один предмет в данную сессию принимает один преподаватель.

24 Вариант Создать базу данных «Склад». В базе данных хранятся сведения

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

25 Вариант Создать базу данных «Спорт». В базе данных хранятся сведения

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

26 Вариант Создать базу данных « Телефонные переговоры». В базе данных

хранятся сведения об абонентах, с указанием номера телефона абонен-та, ФИО, адреса, льготы. Хранятся сведения о переговорах абонентов,

205

с указанием кода города, даты разговора, времени разговора, о количе-стве минут разговора, дате оплаты за разговор. Хранятся сведения о кодах города и тарифах города, с указанием кода города, названия го-рода, тарифа за одну минуту (цена минуты). Тариф за одну минуту ме-няется в зависимости от времени суток разговора, поэтому хранятся сведения о тарифных коэффициентах, включая указание начала перио-да, конца периода, значение коэффициента. Один абонент может зво-нить неоднократно. Стоимость переговоров учитывает город и период времени звонка.

27 Вариант Создать базу данных «Товары». В базе данных хранятся сведе-

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

28 Вариант Создать базу данных «Фототека». В базе данных хранятся сведе-

ния о пленках, с указанием кода пленки, цены, чувствительности, типа пленки (цветная, негативная), количества кадров, даты начала съемки, даты проявления, места проявления, места хранения. Хранится инфор-мация о кадрах, с указанием даты съёмки, места съемки, темы, ФИО участников. Хранятся сведения о фотографиях, с указанием размера, бумаги, количества, ФИО изготовителя, цены, места нахождения. В фототеке ведется учет изготовленных фотографий с учетом пленки и кадра. Из одной пленки может быть напечатано несколько кадров и для каждого кадра несколько фотографий.

29 Вариант

206

Создать базу данных «Футбольный турнир». В базе данных хра-нятся сведения о команде, с указанием названия команды, ФИО глав-ного тренера, ФИО продюсера. Хранятся сведения об игроках команд, с указанием ФИО, номера, амплуа, возраста. Хранятся сведения о мат-чах, с указанием номера матча, название команды1, название коман-ды2, даты матча, места, времени, результата, количества зрителей, средней цены билета. Хранятся сведения о составе игроков каждой из двух команд на игру, с указанием амплуа во время игры и результа-тивности игроков. В одной игре могут играть разные игроки, то есть состав игроков команды на игру может меняться. Одна команда может участвовать в нескольких матчах, один игрок может входить в одну команду, в одной команде несколько игроков.

30 Вариант Создать базу данных «Личное имущество». В базе данных хра-

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

207

СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ

1. Дейт, К. Дж. Введение в системы баз данных / К. Дж. Дейт. ; пер. с англ. – 6-е изд: – Киев; М.; СПб.: Издательский дом «Виль-ямс»,1999. – 848 с.

2. Конноли, Т. Базы данных. Проектирование, реализация и сопрово-ждение. Теория и практика / Т. Конноли, К.Бегг ; пер. с англ. – 3-е изд. – М.: Издательский дом «Вильямс», 2003.-1440 с.

3. Хомоненко, А.Д. Базы данных: учеб. для высш. учеб. заведений / А.Д. Хомоненко, В.М. Цыганков, М.Г. Мальцев ; под ред. проф. А.Д. Хомоненко. – СПб.: КОРОНА принт, 2000. – 416 с.

4. Хансен, Г. Базы данных: разработка и управление / Г. Хансен, Д. Хансен ; пер. с англ. – М.: ЗАО «Издательство БИНОМ», 1999. – 704 с.

5. Клайн, К. SQL: справочник / К. Клайн ; пер. с англ. – 3-е изд. – М.: КУДИЦ-ОБРАЗ, 2010 – 832 с.

6. Маклаков, С.В. Создание информационных систем с AllFusion Modeling Suite / С.В. Маклаков. – М.: ДИАЛОГ-МИФИ, 2003. – 432 с.

7. Гарбуз, Дж. Database Design on SQL Server 7. Сертификационный экзамен – экстерном (экзамен 70-029) / Дж. Гарбуз, Д. Паскузи, Э. Чанг. – СПб.: Издательство «Питер», 2000. – 560 с.

8. Гарбуз, Дж. Administering SQL Server 7. Сертификационный экза-мен – экстерном (экзамен 70-028) / Дж. Гарбуз, Д. Паскузи, Э. Чанг. – СПб.: Издательство «Питер», 2000. – 560 с.

208

Учебное издание

Чигарина Елена Ивановна

БАЗЫ ДАННЫХ

Учебное пособие

Редактор Т.К. К р е т и н и н а Доверстка Л.Р. Д м и т р и е н к о

Подписано в печать 22.05.2015. Формат 60х84 1/16. Бумага офсетная. Печать офсетная.

Печ. л. 13,0. Тираж 100 экз. Заказ . Арт. 17/2015.

федеральное государственное автономное образовательное учреждение высшего образования «Самарский государственный аэрокосмический

университет имени академика С.П.Королева (национальный исследовательский университет)»

443086 Самара, Московское шоссе, 34.

Изд-во СГАУ. 443086 Самара, Московское шоссе, 34.