Базы данных: сборник задач с комментариями и примерами решений: учебное пособие 9785421707035

Table of contents :
Содержание
Предисловие
Часть 1. Проектирование и программирование баз данных
Тема 1. Данные как объект управления
1.1. Вводные замечания и определения
1.2. Практические задания
Тема 2. Концептуальная модель данных
2.1. Три уровня моделирования данных
2.2. Примеры концептуальных (ER-) моделей
2.2.1. Описательные и ключевые атрибуты сущностей
2.2.2. Представление бинарных связей на ЕR-диаграммах
2.2.3. Унарные и бинарные связи вида «обобщение»
2.2.4. Слабые сущности
2.2.5. Моделирование таксономий
2.3. Практические задания
2.3.1. Определение состава атрибутов сущностей предметной области
2.3.2. Формирование ЕR-модели предметной области
2.3.3. Использование «слабых сущностей»
2.3.4. Разработка ЕR-моделей таксономий
Тема 3. Реляционная модель данных
3.1. Примеры
3.1.1. Пример использования выражений реляционной алгебры
3.1.2. Использование реляционного исчисления кортежей
3.1.3. Преобразование ЕR-модели в схему реляционной БД
3.2. Практические задания
3.2.1. Реляционная алгебра
3.2.2. Реляционное исчисление
3.2.2. Правила преобразования ЕR-модели в исходную R-схему БД
3.2.3. Реляционная реализация таксономий
3.2.4. Нормализация реляционной БД
Тема 4. Язык SQL
4.1. Примеры использования SQL-операторов
4.1.1. Примеры DDL-команд
4.1.2. DСL-команды (листинг 4.2)
4.1.3. DМL-операторы
4.1.4. Хранимые представления
4.1.5. Подчиненные запросы
4.1.6. GROUP ВУ и НAVING
4.2. Практические задания
Контрольные задания
Вариант 1.1. Библиотечная система
Контрольное задание 1.1.1. Управление библиотечным фондом
Контрольное задание 1.1.2. Управление персоналом библиотеки
Контрольное задание 1.1.3. Управление контингентом читателей библиотеки
Вариант 1.2. Система торгово-складского учета интернет-магазина компьютерной и оргтехники
Контрольное задание 1.2.1. Управление справочными данными в системе торгово-складского учета
Контрольное задание 1.2.2. Управление товарными запасами в системе торгово-складского учета
Контрольное задание 1.2.3. Управление персоналом в системе торгово-складского учета
Контрольное задание 1.2.4. Управление продажами в системе торгово-складского учета
Вариант 1.3. Система управления образовательной платформой
Контрольное задание 1.3.1. Управление справочными данными образовательной платформы
Контрольное задание 1.3.2. Планирование образовательных программ
Контрольное задание 1.3.3. Управление образовательным контентом
Контрольное задание 1.3.4. Управление контингентом слушателей образовательной платформы
Контрольное задание 1.3.5. Управление учебным процессом, реализуемым на образовательной платформе
Вариант 1.4. Система автоматизированного документооборота
Контрольное задание 1.4.1. Фасетно-иерархический классификатор документов
Контрольное задание 1.4.2. Планирование и мониторинг исполнения внутренних документов
Контрольное задание 1.4.3. Планирование и мониторинг исполнения исходящих документов
Часть 2. Управление и администрирование
Тема 5. Физическая модель реляционной базы данных
5.1. Примеры управления физической моделью данных
5.1.1. Файлы и группы файлов
5.1.2. Файловые страницы
5.1.3. Экстенты
5.2. Практические задания
Тема 6. Индексы
6.1. Примеры анализа структур данных
6.1.1. Структура типа «куча» (heap)
6.1.2. Индексные структуры данных
6.2. Практические задания
Тема 7. Процедурные планы выполнения SQL-запросов
7.1. Типовой алгоритм трансляции SQL-запроса
7.2. Примеры анализа процедурных планов
7.3. Практические задания
Тема 8. Управление транзакциями и блокировками
8.1. Свойства и уровни изолированности транзакций
8.2. Общие методические указания и используемые инструменты
8.3. Пример
8.4. Практические задания
8.5. Контрольные вопросы
Тема 9. Защита данных
9.1. Триада CIA
9.2. Примеры
9.2.1. Управление доступом к данным
9.2.2. Безопасность уровня строк таблиц
9.2.3. Динамическое маскирование данных
9.2.4. Шифрование данных
Ключи шифрования
9.3. Практические задания
Часть 3. Постреляционные решения
Тема 10. Многомерные модели данных
10.1. Примеры
10.2. Практические задания
Тема 11. NoSQL-модели данных
11.1. Реляционный подход
11.2. Подход NoSQL
11.3. Примеры
Идентификация документов
11.3. Практические задания
Тема 12. Объектно-реляционные отображения
12.1. Паттерны взаимодействия с реляционными базами данных
12.2. Установка SQLAlchemy
12.3. Пример 1. SQLAlchemy - работа с DBAPI
12.3.1. Создание базы данных под управлением SQLiteЗ
12.3.2. Заполнение и просмотр содержимого таблиц базы данных
12.3.3. Примеры SQL-запросов к базе данных
12.4. Пример 2. SQLAlchemy ОRM
12.4.1. Определение классов -сущностей предметной области
12.4.2. Заполнение базы данных (листинг 12.6)
12.4.3. Выполнение запросов к базе данных (листинг 12.7)
12.5. Практические задания
Предметная область «Отдел библиотеки»
Предметная область «Заказы товаров»
Выполнение запросов с использованием SQLAlchemy DBAPL
Выполнение запросов с использованием SQLAlchemy ОRM
Контрольные задания
Общие методические указания
Вариант 3.1. Библиотека
Вариант 3.2. Управление заказами
Вариант 3.3. Учет успеваемости студентов
Вариант 3.4. Подготовка и проведение научной конференции
Вариант 3.5. Продажи автомобилей с пробегом
Учебно-методические материалы и информационные ресурсы

Citation preview

В.К.Волк,В.Ю.Осеев,О.С.Черепанов

&АЗЫ ДАННЫХ СБОРНИК ЗАДАЧ

С КОММЕНТАРИЯМИ И ПРИМЕРАМИ РЕШЕНИЙ Учебно-методическое пособие

■--

Курган 2024

МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ федеральное государственное бюджетное образовательное учреждение высшего образования «Курганский государственный университет»

В. К. Волк, В. Ю. Осеев, О. С. Черепанов

БАЗЫ ДАННЫХ СБОРНИК ЗАДАЧ С КОММЕНТАРИЯМИ И ПРИМЕРАМИ РЕШЕНИЙ

Учебно-методическое пособие

Курган 2024

УДК 004.658. 2 (0758) ББК 16.35 В67

Рецензенты: кафедра прикладной информатики и автоматизации бизнес-процессов Шадринского государственного педагогического университета (канд. физ.­ мат. наук, профессор Владислав Юрьевич Пирогов); ООО «Такстелеком» (заместитель технического директора Дмитрий Владимирович Новгородов). Печатается по решению методического совета Курганского государ­ ственного университета. Научный редактор - канд. пед. наук, доц. А. А. Медведев. Волк В. К. Базы данных: сборник задач с комментариями и примерами решений : учебное пособие/ В. К. Волк, В. Ю. Осеев, О. С. Черепанов. Курган : Издательство Курганского государственного университета, 2024. - 256 С. Пособие входит в состав учебно-методического комплекса модуля «Управ­ ление данными»,компоненты которого традиционно представлены в образователь­ ных программах IТ-специальностей различных уровней - от среднего специаль­ ного образования до магистратуры,и содержит практические задания по основным тематическим разделам этого модуля: данные, как объект управления, концепту­ альная ЕR-модель,реляционная модель данных,SQL-программирование,управле­ ние физической моделью реляционной БД,управление производительностью и без­ опасностью систем баз данных. Рассмотрены также объектно-реляционные отобра­ жения и постреляционные решения- многомерные модели и NoSQL-бaзы данных. Пособие предназначено для студентов IТ-специальностей и может быть использовано преподавателями при проведении практических и лабораторных занятий, подготовке контрольных и аттестационных заданий, формировании те­ матики курсовых проектов. Рисунков - 70,таблиц - 7,листингов программного кода- 25. ISBN 978-5-4217-0703-5 © Курганский государственный университет,2024 © Волк В. К.,Осеев В. Ю., Черепанов О. С.,2024

2

СОДЕРЖАНИЕ ПРЕДИСЛОВИЕ ................................................................................................. 6 ЧАСТЬ 1. ПРОЕКТИРОВАНИЕ И ПРОГРАММИРОВАНИЕ БАЗ ДАННЫХ ................................ 9 Тема 1. ДАННЫЕ КАК ОБЪЕКТ УПРАВЛЕНИЯ ...................................... 9 1.1 Вводные замечания и определения ........................................................ 9 1.2 Практические задания ............................................................................. 13 Тема 2. КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ ДАННЫХ ................................... 16 2.1 Три уровня моделирования данных ...................................................... 16 2.2 Примеры концептуальных (ER-) моделей ............................................ 18 2.2.1 Описательные и ключевые атрибуты сущностей .......................... 18 2.2.2 Представление бинарных связей на ЕR-диаграммах .................... 18 2.2.3 Унарные и бинарные связи вида «обобщение» ............................. 19 2.2.4 Слабые сущности .............................................................................. 20 2.2.5 Моделирование таксономий ............................................................ 24 2.3 Практические задания ............................................................................. 29 2.3.1 Определение состава атрибутов сущностей предметной области ........................................................................................................ 29 2.3.2 Формирование ЕR-модели предметной области ........................... 30 2.3.3 Использование «слабых сущностей» .............................................. 31 2.3.4 Разработка ЕR-моделей таксономий .............................................. 33 Тема 3. РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ ............................................ 36 3.1 Примеры ................................................................................................... 36 3.1.1 Использование выражений реляционной алгебры ........................ 37 3.1.2 Использование реляционного исчисления кортежей ................... 38 3.1.3 Преобразование ЕR-модели в схему реляционной БД ................. 38 3.2 Практические задания ............................................................................. 39 3.2.1 Реляционная алгебра ........................................................................ 39 3.2.2 Реляционное исчисление.................................................................. 41 3.2.2 Правила преобразования ЕR-модели в исходную R-схему БД ... 41 3.2.3 Реляционная реализация таксономий ............................................. 43 3.2.4 Нормализация реляционной БД ...................................................... 45 Тема 4. Язык SQL ............................................................................................. 49 4.1 Примеры использования SQL-операторов ........................................... 49 3

4.1.1 DDL-команды .................................................................................... 49 4.1.2 DСL-команды .................................................................................... 50 4.1.3 DМL-операторы ................................................................................ 50 4.1.4 Хранимые представления ................................................................ 54 4.1.5 Подчиненные запросы ...................................................................... 55 4.1.6 GROUP ВУ и НАVING .................................................................... 56 4.2 Практические задания ............................................................................. 57 КОНТРОЛЬНЫЕ ЗАДАНИЯ .......................................................................... 65 Вариант 1.1. Библиотечная система ............................................................ 65 Вариант 1.2. Система торгово-складского учета интернет-магазина компьютерной и оргтехники.................................................. 73 Вариант 1.3. Система управления образовательной платформой ........... 80 Вариант 1.4. Система автоматизированного документооборота ............. 91 ЧАСТЬ 2. УПРАВЛЕНИЕ И АДМИНИСТРИРОВАНИЕ ........................... 97 Тема 5. ФИЗИЧЕСКАЯ МОДЕЛЬ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ.... 97 5 .1 Примеры управления физической моделью данных ........................... 97 5 .1.1 Файлы и группы файлов................................................................... 97 5 .1.2 Файловые страницы ........................................................................ 100 5.1.3 Экстенты .......................................................................................... 103 5 .2 Практические задания.......................................................................... 105 Тема 6. ИНДЕКСЫ ......................................................................................... 110 6.1 Примеры анализа структур данных .................................................... 11О 6.1.1 Структура типа «куча» (heap) ....................................................... 11О 6.1.2 Индексные структуры данных ..................................................... 111 6.2 Практические задания ........................................................................... 120 Тема 7. ПРОЦЕДУРНЫЕ ПЛАНЫ ВЫПОЛНЕНИЯ SQL-ЗAПPOCOB .. 123 7.1 Типовой алгоритм трансляции SQL-зaпpoca ..................................... 123 7.2 Примеры анализа процедурных планов ............................................. 124 7.3 Практические задания........................................................................... 127 Тема 8. УПРАВЛЕНИЕ ТРАНЗАКЦИЯМИ И БЛОКИРОВКАМИ ......... 138 8.1 Свойства и уровни изолированности транзакций ............................. 138 8.2 Общие методические указания и используемые инструменты ....... 139 8.3 Пример.................................................................................................... 141 8.4 Практические задания........................................................................... 147 4

8.5 Контрольные вопросы .......................................................................... 173 Тема 9. ЗАЩИТА ДАННЫХ ........................................................................ 175 9.1 Триада CIA ............................................................................................. 175 9.2 Примеры ................................................................................................. 176 9.2.1 Управление доступом к данным ................................................... 176 9.2.2 Безопасность уровня строк таблиц ............................................... 183 9.2.3 Динамическое маскирование данных ........................................... 190 9.2.4 Шифрование данных ...................................................................... 193 9.3 Практические задания........................................................................... 196 ЧАСТЬ 3. ПОСТРЕЛЯЦИОННЫЕ РЕШЕНИЯ .......................................... 205 Тема 10. МНОГОМЕРНЫЕ МОДЕЛИ ДАННЫХ...................................... 205 1О.1 Примеры ............................................................................................... 206 10.2 Практические задания ........................................................................ 211 Тема 11. NoSQL-MOДEЛИ ДАННЫХ ........................................................ 212 11.1 Реляционный подход .......................................................................... 212 11.2 Подход NOSQL.................................................................................... 213 11.3 Примеры ............................................................................................... 213 11.3 Практические задания ........................................................................ 220 Тема 12. ОБЪЕКТНО-РЕЛЯЦИОННЫЕ ОТОБРАЖЕНИЯ ...................... 221 12.1 Паттерны взаимодействия с реляционными базами данных ......... 221 12.2 Установка SQLAlchemy..................................................................... 224 12.3 Пример 1. SQLAlchemy - работа с DBAPI ..................................... 226 12.4 Пример 2. SQLAlchemy ОRМ ............................................................ 235 12.5 Практические задания ........................................................................ 242 КОНТРОЛЬНЫЕ ЗАДАНИЯ ........................................................................ 250 Общие методические указания .................................................................. 250 Вариант 3.1. Библиотека............................................................................. 251 Вариант 3.2. Управление заказами ............................................................ 251 Вариант 3.3. Учет успеваемости студентов ............................................. 251 Вариант 3.4. Подготовка и проведение научной конференции ............. 252 Вариант 3.5. Продажи автомобилей с пробегом ...................................... 253 УЧЕБНО-МЕТОДИЧЕСКИЕ МАТЕРИАЛЫ И ИНФОРМАЦИОННЫЕ РЕСУРСЫ ......................................................... 254 5

ПРЕДИСЛОВИЕ Разработка и эффективное использование технологий хранения, по­ иска и извлечения информации требует от IT-специалистов глубокого по­ нимания теоретических основ и концепций построения баз данных, но не менее важным является приобретение практического опыта решения типо­ вых задач, связанных с проектированием, программированием и админи­ стрированием баз данных на соответствующих стадиях их жизненного цикла. При всем многообразии монографий, учебников и учебно-методиче­ ских пособий, посвященных теории и практике использования баз данных, примеры и задания, приводимые в этих изданиях, имеют в основном иллю­ стративный и комплексный характер, что ограничивает возможности их массового использования преподавателями при проведении практических занятий и лабораторных работ, планировании контрольных и аттестацион­ ных мероприятий. Авторами предлагаемого сборника задач сделана попытка ликвида­ ции этого пробела в учебно-методическом обеспечении дисциплины. По всем основным ее разделам подготовлены практические задания различных уровней сложности, рассмотрены примеры их решений, снабженные де­ тальными комментариями и иллюстрированные листингами программного кода, приведены контрольные вопросы и контрольные задания, позволяю­ щие оценить степень освоения студентами соответствующего учебного ма­ териала. Учебное пособие состоит из трех частей и двенадцати глав, охватыва­ ющих основные тематические разделы дисциплины. Первая часть (темы с первой по четвертую) охватывает базовый уро­ вень освоения технологий баз данных - элементы реляционной теории, проектирование и основы SQL-программирования. В первой (вводной) теме рассматриваются данные как объект управ­ ления (модель DIKW, архитектура данных, классификация данных), прак­ тические задания этой главы нацелены на выработку понимания базовых концепций и освоение профессиональной терминологии в области управ­ ления данными. Во второй, третьей и четвертой темах рассмотрены традиционные темы, ориентированные на проектировщиков и программистов баз данных. Приведены примеры разработки концептуальных ЕR-моделей различных 6

предметных областей, преобразования ЕR-моделей в соответствующие схемы реляционных баз данных, их последующей нормализации и SQL­ реализации. Для выполнения практических заданий по этим темам потре­ буются навыки использования специализированных САSЕ-средств для раз­ работки ЕR-диаграмм и владение языком SQL на базовом уровне. Завершает первую часть перечень контрольных заданий, рекомендуе­ мых для использования при проведении зачетов или при выполнении кон­ трольных работ по первой части дисциплины. Каждое из таких заданий предполагает выполнение мини-проекта базы данных, включающего все типовые этапы ее разработки: формирование ЕR-модели предметной обла­ сти, преобразование ЕR-модели в схему реляционной БД и ее последую­ щую нормализацию, а также написание SQL-запросов для выборки, моди­ фикации и статистической обработки данных. Вторая часть (темы с пятой по девятую) обеспечивает более глубокий уровень подготовки в области администрирования, SQL-программирова­ ния и управления базами данных. В пятой, шестой и седьмой темах рассматриваются задачи управления физической ( файловой) моделью реляционной БД, вопросы индексации данных и оптимизации процедурных планов исполнения SQL-запросов. Практические задания по этим темам имеют исследовательский характер, их выполнение позволит понять алгоритмы реализации типовой процедуры трансляции SQL-запросов и освоить инструментальные программные сред­ ства анализа и управления производительностью операций доступа к дан­ ным. Еще одному важному аспекту управления производительностью по­ священа восьмая тема, в которой рассматривается проблематика много­ пользовательского доступа к объектам базы данных и исследуются алго­ ритмы управления транзакциями и блокировками. В этой теме представ­ лены как относительно простые задания для ознакомления с концепцией транзакционного управления и процедурой управления транзакциями и блокировками (подтверждение и откат изменений в транзакциях), так и бо­ лее сложные задания, помогающие понять поведение СУБД в различных ситуациях (взаимоблокировки, блокировки при изменении структур дан­ ных и пр.).

7

В девятой теме рассмотрены методы и программные средства защиты баз данных от несанкционированного доступа. Задания этой темы позво­ ляют понять методы дискреционной защиты данных (применительно к ре­ ляционным базам данных) и практически освоить SQL-средства разграни­ чения доступа, а также встроенные средства управления доступом, реали­ зованные компонентами СУБД. В третьей части учебного пособия (темы с десятой по двенадцатую) рассматриваются специальные вопросы использования баз данных - мно­ гомерные модели, применяемые в аналитических системах, NоSQL-модели данных, ориентированные в основном на распределенное хранение и обра­ ботку данных, а также средства объектно-реляционных отображений. В десятой теме рассмотрены многомерные модели данных, использу­ емые в ОLАР-системах. Выполнение практических заданий этой главы тре­ бует понимания концепций многомерного анализа данных и требований к соответствующим моделям данных (тест FASMI, модели MOLAP и ROLAP), а также способов реляционной реализации модели гиперкуба и типовых операций многомерного анализа. В одиннадцатой теме приведен краткий обзор NоSQL-моделей дан­ ных и примеры использования СУБД Cassandra, поддерживающей «столб­ цовую» модель данных, и документно-ориентированной СУБД MongoDB. Практические задания этой темы требуют разработки ЕR-модели заданной предметной области, формирования на основе этой модели NoSQL-бaзы данных и написания запросов к этой базе данных на языке CQL. В двенадцатой теме рассматриваются средства взаимодействия при­ кладных программ, написанных в парадигме ООП, с реляционными СУБД. Рассмотрены примеры, иллюстрирующие различные способы установки программного инструментария фреймворка SQLAlchemy и примеры ра­ боты с СУБД с использованием SQLAlchemy DBAPI и SQLAlchemy ОRМ. Практические задания этой главы ориентированы на использование языка программирования Python и СУБД SQLite.

8

ЧАСТЬ 1 ПРОЕКТИРОВАНИЕ И ПРОГРАММИРОВАНИЕ БАЗ ДАННЫХ Тема 1. ДАННЫЕ КАК ОБЪЕКТ УПРАВЛЕНИЯ 1.1 Вводные замечания и определения Очевидно, что базовым понятием информационных технологий явля­ ется «информация» - философская категория, определение которой вряд ли может быть дано в рамках какой-то одной науки, но при этом интуитивно понятно, что информация-это сведения о каком-либо объекте, целенаправ­ ленно извлекаемые субъектом из каких-то фактов (данных), пополняющие знания субъекта об этом объекте и уточняющие понимание им определен­ ных аспектов некоторой предметной области. В приведенном неформальном описании подчеркивается субъектив­ ный характер информации, ее целесообразность и значимость для получа­ теля, а также взаимосвязь этого понятия с другими (почти синонимичными) понятиями, такими как данные, знания и понимание. Стандарт ISO/IEC 2382 (ГОСТ 33707-2016) дает следующие более формализованные определения: Данные - представление информации в некотором формализованном виде, пригодном для передачи, интерпретации или обработки. База данных - собрание данных, организованных в соответствии с концептуальной структурой, описывающей характеристики этих данных и взаимоотношения между ними, причем такое собрание данных, которое поддерживает одну или более областей применения. Извлечение информации - действия, методы и процедуры, использу­ емые для получения информации о заданном предмете из хранимых дан­ ных. Информация - любой факт, понятие или значение, полученные из данных, а также контекст, выбранный из знаний, или контекст, ассоции­ рованный со знаниями. Знания - организованное, интегрированное собрание фактов и обоб­ щений. База знаний - база данных, содержащая правила вывода и информа­ цию о человеческих знаниях и опыте в некоторой области знаний. Экспертная система - система обработки данных, которая обеспечи­ вает экспертное решение проблем в заданной области применения, строя вы­ воды на основе базы знаний, в которой формализован человеческий опыт 9

Существуют определенные трудности в понимании различий между данными, информацией и знаниями, что вызвано кажущейся синонимично­ стью этих понятий. В качестве примера можно привести известное в инже­ нерии знаний направление Data Mining, которое по-разному переводится на русский язык, причем в различных переводах используются все три этих понятия: «интеллектуальный анализ данных», «извлечение информации» или «добыча знаний». Несмотря на отмеченные различия, все эти понятия тесно связаны и являются элементами единого информационного процесса, иллюстрируемого «информационной пирамидой» (рисунок 1.1) и извест­ ного как «Модель DIKW»: Data -Inf01�mation - Knowledge - Wisdom. В основании пирамиды находятся данные - набор разрозненных фак­ тов, полученных в результате наблюдений, измерений или выполнения ло­ гико-математических операций и сохраненных в форме, удобной для ком­ пьютерного хранения и последующей обработки. Используя термин данные, мы подчеркиваем техническую сторону информации и не затрагиваем ее содержательный и семантический ас­ пекты.

,Yisdom

Пони�зние объясненне прогнозы nове.:1ен11я сбъе1;.а 11 пр11ня1'\1е решен11i1

Knowledge

Знания инстру1-ции по иссJiе;�ован11ю объекта

lnformation

Информация описание азаимосв�зей и отношен11и между эпементам11 данных

Data

Дзннь,е мно:�ество объект11вных qвктов об 11ссле;1уемом объеr..е

Рисунок 1.1 - Модель DIKW Следующий уровень пирамиды занимает информация, формируемая в процессе интерпретации данных путем выявления и осмысления взаимо­ связей между их отдельными элементами. 10

Информация, в отличие от данных, несет в себе некоторый смысл, но наличия информации еще недостаточно для решения проблем. Одни и те же данные могут быть источником самой различной, в том числе и проти­ воречивой, информации в зависимости от того, какие методы были приме­ нены для ее извлечения: возможны ситуации, когда объективно корректные данные могут стать источником недостоверной информации. Еще более высокий уровень - это знания, которые получаются в ре­ зультате целенаправленного восприятия, обработки и осмысления инфор­ мации. Связанные по смыслу факты образуют полную картину явления или процесса, позволяющую делать выводы (если А, то Б). Знания по своей при­ роде процедурны и могут использоваться в процессах выработки и приня­ тия решений. Вершину информационной пирамиды занимают глубокие знания, по­ нимание или мудрость. На этом этапе обработки данных к знанию добав­ ляется понимание того, где и как можно использовать полученные знания. На каждом новом уровне обрабатываемые данные становятся более структурированными, процедурными и пригодными для использования в процессе принятия решений. Если информация описывает исследуемый объект и дает ответы на вопросы: «Что?», «Сколько?» и «Почему?», а зна­ ние позволяет выработать технологические инструкции и получить ответы на вопрос «Как?», то понимание дает нам объяснение и позволяет ответить на более сложные вопросы: «Зачем?» и «Как лучше всего?». Пирамидальный образ модели DIKW наглядно демонстрирует лишь общую концепцию: при движении вверх по информационной пирамиде объемы данных преобразуются в ценность знаний, однако такое упрощен­ ное представление создает ряд трудностей в понимании технологий прак­ тической реализации процедур такого преобразования: - во-первых, данные считаются объективно существующими, но это не так, потому что данных в природе не существует, они должны быть созданы (или получены); - во-вторых, данные - это средство представления фактов, они «засло­ няют собой» реальные факты и в отрыве от контекста бесполезны, при этом контекст - это тоже данные (метаданные, данные о данных); - в-третьих, линейная последовательность преобразования «данные информация - знание -понимание» игнорирует тот факт, что еще до начала

11

такого преобразования нужны знания о том, как получить данные, затем знания о том, как преобразовать данные в информацию; - в-четвертых, предполагается, что данные и информация отделены друг от друга, тогда как в действительности два этих понятия тесно пере­ плетены, взаимозависимы и по отдельности не существуют: информация это форма представления данных о реальном объекте, а состав накапливае­ мых данных зависит от того, какая информация об этом объекте будет вос­ требована. Не всякие данные могут быть преобразованы в информацию, и не вся­ кая информация сможет превратиться в знания. В качестве примера можно рассмотреть текст научной статьи, написанный на незнакомом читателю языке. С формальной точки зрения текст статьи - это данные, закодирован­ ные символами некоторого алфавита. При отсутствии аппарата интерпре­ тации такие данные не смогут быть восприняты и осмыслены читателем, то есть не смогут быть преобразованы в информацию. С помощью аппарата интерпретации (словаря или переводчика, знающего оба языка) можно сде­ лать корректный перевод статьи, превратив тем самым данные в информа­ цию, пригодную для восприятия. Теперь статью можно прочитать, однако не факт, что эта информация сможет получить статус знаний и в дальней­ шем будет использована для принятия решений. Возможно, читатель недо­ статочно подготовлен для осмысления полученной информации или для понимания содержания статьи необходимо привлечение дополнительной информации. Продолжим цитировать терминологический стандарт ISO/IEC 2382:

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

управления данными относятся к задачам более низкого уровня и «вло­ жены» в соответствующие функции управления информацией. Признание концептуальных различий между понятиями информация и данные, а также признание факта их неразрывной взаимосвязи служит ос­ новой следующего базового постулата об управлении данными [1]: Объектом управления являются и данные, и информация, причем качество и того, и другого возрастает лишь при согласованном управлении ими с учетом потребностей конечных потребителей 1.2 Практические задания Задание l.l Дайте неформальные определения понятий: данные, информа­ ция, знания и понимание. В каких соотношениях находятся эти поня­ тия и какое место занимает каждое из них в процессе обработки дан­ ных? Задание 1.2 Приведите примеры корректного преобразования данных в ин­ формацию, информации - в знание, а знания - в понимание. Задание 1.3 Приведите примеры ситуаций, в которых невозможно кор­ ректное преобразование данных в информацию, информации - в зна­ ние, а знания - в понимание. Задание 1.4 Определите содержание информационной пирамиды DIKW для задач регистрации первичной информации о поездках пассажи­ ров, подготовки аналитических отчетов и принятия решений в авто­ матизированной системе анализа пассажиропотоков. Несколько конкурирующих компаний предоставляют услуги обще­ ственного транспорта жителям мегаполиса. Сформированы маршруты дви­ жения городских автобусов, в каждом автобусе установлены терминалы по продаже билетов (или другие устройства, регистрирующие факты оплаты поездок пассажирами), все эти терминалы связаны компьютерной сетью и сохраняют в базе данных информацию о каждой поездке (маршрут, коор­ динаты точки начала поездки, № автобуса, дату и время начала поездки, ее стоимость). Транспортные компании используют такую информацию для реше­ ния оперативных задач финансовой отчетности, при этом информация за прошлые периоды оказывается невостребованной и хранится в архивах «на 13

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

Были подготовлены следующие аналитические отчеты на основе по­ лученной информации: 1) средняя загрузка каждого маршрута (поездок за сутки); 2) сравнительный анализ средней загруженности маршрутов по вре­ менам года, дням недели и времени суток (по часам). По результатам проведенного анализа Департаментом транспорта были приняты следующие решения: 1) допустить еще одну транспортную компанию для увеличения ко­ личества автобусов на следующих маршрутах (список прилага­ ется); 2) увеличить количество автобусов на маршрутах (список прилага­ ется) в дневное время по выходным и праздничным дням; 3) проложить ветку метрополитена для связи центра города с райо­ нами (список районов прилагается). Задание 1.5 Определите содержание информационной пирамиды DIKW для задач оперативного учета продаж, маркетингового анализа и принятия решений в автоматизированной системе марке­ тингового анализа в торговом предприятии. В торговом зале супермаркета установлены кассовые аппараты, объ­ единенные в локальную сеть и обеспечивающие оперативную регистрацию в базе данных всех операций по продаже товаров покупателям супермар­ кета: категория товара, его наименование, цена и количество, дата и время покупки. Для постоянных клиентов (владельцев дисконтных карт) допол­ нительно указывается код клиента и текущий размер предоставленной ему торговой скидки. В офисе супермаркета работают специалисты-маркетологи, формиру­ ющие следующие аналитические отчеты по результатам выполнения со­ ответствующих запросов к базе данных торгового учета: 1) текущие складские запасы (по категориям товаров); 14

2) объемы продаж за период времени (сутки, неделя, месяц, квартал, год) в денежном исчислении; 3) сравнительный анализ объемов продаж по категориям товаров; 4) почасовой анализ динамики продаж в течение суток; 5) средняя доля продаж постоянным покупателям. Управляющий супермаркетом анализирует содержание представлен­ ных ему отчетов и после дополнительных консультаций с маркетологами и экономистами принимает следующие решения: 1) пополнить складские запасы интенсивно продаваемых товаров; 2) установить 50 %-ю скидку на цены товаров, срок реализации которых приближается к критическому; 3) объявить акцию «У нас - всегда низкие цены!» (постоянная скидка 0,5 % на все товары ограниченного перечня категорий); 4) объявить акцию «Кто ходит в гости по утрам, тот экономит умно!» (скидка 10 % на все товары, купленные до 8-00); 5) отменить дисконтные карты постоянным покупателям. Задание 1.6 Определите содержание информационной пирамиды DIKW для автоматизированной системы оперативного учета и ана­ лиза успеваемости студентов, а также состав дополнительных данных, информации и знаний, необходимых для реализации управленческого решения №4. 10 групп студентов-первокурсников Института компьютерных наук сдали экзамены по шести дисциплинам: математике, информатике, про­ граммированию, астрологии, хиромантии и основам научного оккультизма. Результаты сдачи экзаменов каждым из студентов по каждой дисциплине (оценки по 100-балльной шкале) были зафиксированы в базе данных авто­ матизированной системы. По окончании экзаменационной сессии для ди­ ректора Института были подготовлены аналитические отчеты четырех видов: 1) групповые экзаменационные ведомости по каждой из дисциплин; 2) рейтинговые списки студентов по каждой из шести дисциплин; 3) рейтинговые списки студентов, ранжированные по среднему баллу студента по всем дисциплинам; 4) рейтинговые списки студенческих групп, ранжированные по среднему баллу всех студентов группы по всем дисциплинам. По результатам анализа содержимого отчетов директор Института 15

принял следующие решения, оформленные соответствующими приказами: 1) исключить экзаменационные ведомости из перечня предоставля­ емых Директору отчетов по причине их низкой информативности и большого объема неструктурированной информации; 2) назначить следующим студентам (список прилагается) повышен­ ный размер стипендии на следующий семестр за отличную успе­ ваемость по всем дисциплинам; 3) поощрить кураторов следующих групп (списки номеров групп и фамилии кураторов прилагаются) за высокие показатели акаде­ мической успеваемости групп; 4) провести дополнительное исследование причин весьма скромной успеваемости студентов по информатике, математике и програм­ мированию по сравнению с их высокими достижениями в освое­ нии астрологии, хиромантии и основ научного оккультизма, вы­ работать предложения по сбору дополнительных данных, необ­ ходимых для проведение такого исследования. Тема 2. КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ ДАННЫХ 2.1 Три уровня моделирования данных Проектирование баз данных - это процесс последовательного выяв­ ления и анализа требований к данным и их последующего представления в точно определенной форме, называемой моделью данных. Модель данных - это форма документирования требований к данным, определения (описания) данных, и одновременно - главное средство ком­ муникации в процессе проектирования и сопровождения информационных систем, обеспечивающее передачу требований к данным от сферы бизнеса в сферу ИТ, а также (внутри ИТ-сферы) от аналитиков и архитекторов дан­ ных к проектировщикам, программистам и администраторам баз данных. Модели данных: определяют структуру данных на разных уровнях детализации, со­ держат информацию об элементах данных и связях между ними; определяют единую терминологию в области данных, улучшают по­ нимание структуры информационных активов предприятия и служат средством коммуникации в процессе реализации ИТ-проектов;

16

являются средством документирования ИТ-проектов, могут сохра­ нять «корпоративную память» о действующих системах и служить ос­ новой для разработки новых проектов в качестве версии «как есть»; создают основу процессов разработки, настройки и интеграции про­ граммных приложений, соответствующих текущим и перспективным потребностям бизнеса; содержат метаданные (данные о данных), важные для потребителей информации и используемые другими функциями управления дан­ ными, например функциями поддержки хранилищ данных и бизнес­ аналитики. Процесс моделирования данных носит итерационный характер и предусматривает разработку моделей разных уровней абстракции (детали­ зации) - концептуальных моделей «Сущность-Связь» (ER, Entity-Relation­ ship ), логических и физических моделей данных. На концептуальном (верхнем и наиболее абстрактном) уровне компо­ ненты моделей представляют объекты моделируемой предметной области: сущности, атрибуты, связи, события, факты. Для описания моделей исполь­ зуются различные системы графической нотации, например ЕR-диаграммы П. Чена, UМL-диаграммы классов-сущностей или гиперкубы для представ­ ления многомерных моделей данных. Как правило, концептуальные мо­ дели слабо зависят от их последующей программной реализации: одна и та же концептуальная модель может быть представлена (детализирована) раз­ личными моделями логического уровня. Детальное описание концептуаль­ ных моделей и технологий их разработки приведено в учебнике одного из авторов учебного пособия [6, 38-53]. Если концептуальная модель описывает семантику предметной обла­ сти, то логическая модель - это уже модель данных, полученная в резуль­ тате программной реализации концептуальной модели путем ее описания на некотором языке программирования высокого уровня. Физическая модель представляет низкоуровневую (файловую) орга­ низацию данных, она формируется программно в результате трансляции языкового описания логической модели данных (например, SQL-кoдa реля­ ционной модели).

17

2.2 Примеры концептуальных (ER-) моделей 2.2.1 Описательные и ключевые атрибуты сущностей Рисунок 2.1 иллюстрирует классификацию атрибутов сущности Со­ трудник в автоматизированной системе управления персоналом. Атрибут Етр/оуее /О - это так называемый суррогатный ключ, уни­ кально идентифицирующий экземпляр сущности (первичный ключ). Описательные атрибуты, выделенные на рисунке сплошными рам­ ками, представляют свойства сотрудников, существенные для задач кадро­ вого учета.

. ................ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ю [Пас п о рт] [ ИНН ] уе 1 о_ р_ _е_ _Е_m_ _

: ! [ ! i � i !-Q - - - ��: : - - - - - - - - � - - - - - - - - - - - - � . 1

: - - - - - : -: - - - - - - - -

•

� :

•

Дата_найма [Ста ж] : :

Гооо,щ ]

□

•

1"' - - - - - - - - - - - - , :

1

----

1 :

: :................ j :. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .: 1

1

Рисунок 2.1 - Пример представления атрибутов сущности ЕR-модели Группы атрибутов, выделенные на рисунке пунктирными рамками, представляют составные вторичные ключи, значения которых моrут иден­ тифицировать различные подмножества экземпляров сущности, необходи­ мость которых была определена по результатам анализа бизнес-процессов предметной области. 2.2.2 Представление бинарных связей на ЕR-диаграммах На рисунках 2.2 и 2.3 приведены примеры представлений на ЕR­ диаграммах бинарных связей между сущностями в трех различных стилях графической нотации.

18

"entity" Speciality +ID_Spec +Speciality_name 1 1 . .* "entity" Educational_Level +ID Level +Level name

"entity" Educational_For111s

"entity" Groups 1

•

+ID_Group +Group_name

•

1

"

+ID Form +Form name +Short-Form -Name

1 . .* "entity" Students +ID Student +FullName

Рисунок 2.2 - Фрагмент ЕR-диаграммы модели «Контингент студентов»

ФИО

1 D сотр

Г о д_Рожд .

С отрудн и к

Д ОJП ЖН О СТЬ

Д ата н а зн . Допжн ость

Окп ад

Занимает

С отрудн и к ID_c oт p Ф И О. Год р ожде н и я

За н и мае т

Дат а н аз н ач е н и я

Должность

I D_должн _ Должност ь О клад

Рисунок 2.3 - Два способа обозначений связей кратности M: N 2.2.3 Унарные и бинарные связи вида «обобщение» На рисунке 2.4 изображен фрагмент ЕR-диаграммы предметной обла­ сти «Библиотечный каталог», иллюстрирующий представление иерархиче­ ских связей вида «обобщение» (наследование) бинарных связей между 19

сущностями «Книги», «Журналы» и «Библиотечный фонд» и унарных свя­ зей между различными экземплярами сущности «Жанры». Кн и ги

Б и бл . фонд

Журн алы

..--------11 1е Торгое1г.;;f-iс; ....е с!ка

Ко;]_�

Ко,;: _Сотр •,'): --!Иi 1. 151

Вариант 1 4

Индексированная кластеризованная таблица. Две тран­ закции обновляют две разных строки таблицы: первая транзакция выбирает строку по значению первичного ключа, а вторая - по значению индексированного некла­ стеризованного вторичного ключа: - создаем таблицу, например, так: CREATE TABLE [d bo] . [T_TEST_З] ( [1 D] [i nt] I DENTITY( l 1 l) N OT N U LL1 [C_NAM E] [nva rchar] ( l00) N U LL1 [1 D ТУРЕ] [i nt] N U LL PRI MARY КЕУ CLUSTER E D ( [ I D] ASC) WITH ( PAD_I N DEX = OFF1 STATISTI CS_NORECOM PUTE = OFF 1 I G N ORE_D U P_КЕУ = OFF 1 ALLOW_ROW_LOCKS = ON 1 ALLOW_PAG E_LOCKS = O N ) ON [PRI MARY] ) ON [PRI MARY] ); CREATE NON CLUSTER E D I N DEX [IX_T_TEST_З_I D_TYPE] ON [d bo] . [T_TEST_З] ( I D_TYPE] ASC) WITH ( PAD_I N DEX = OFF1 STATISTI CS_NORECO M P UTE = OFF1 SORT_I N_TE M P DB=OFF1 DROP_EXISTI N G=OFF1 O N LI N E=OFF1 ALLOW_ROW_LOCKS = ON 1 ALLOW_PAG E_LOCKS = O N ) ON [PRI MARY] ;

- вставляем в таблицу четыре строки: I NS E RT I NTO [d bo] . [T_TEST_З](C_NA M E 1 I D_TYP E) VALU ES ('SOM E\ 10) 1 ( ' E LSE\ 12) 1 ('SOM ETH I NG\ 15) 1 ( ' М ЕТА\ 10); - в первой транзакции обновляем строку с I D = 1; - во второй транзакции обновляем строку с I D_TYPE = 12.

Вариант 1 5 Индексированная кластеризованная таблица. Обе тран­

закции обновляют одну строку таблицы: первая транзак­ ция выбирает строку по значению первичного ключа, а вторая - по значению индексированного некластеризо­ ванного вторичного ключа: - создаем таблицу и вставляем в нее четыре строки (Вариант 14); - в первой транзакции обновляем 1-ю строку с I D = 1; - во второй транзакции обновляем две строки с I D_TYPE = 10. 152

Вариант 1 6 Индексированная кластеризованная таблица. Обе тран­

закции обновляют одну строку таблицы: первая транзак­ ция выбирает строку по значению индексированного не­ кластеризованного вторичного ключа, а вторая - по зна­ чению первичного ключа. - создаем таблицу и вставляем в нее четыре строки (Вариант 1 4); - в первой транзакции обновляем две строки с I D_TYP E = 10; - во второй транзакции обновляем 1-ю строку с 1 D = 1 .

Задание 8.4 Анализ обновлений (U P DATE), проводимых конкурирующими транзакциями в условиях возникновения взаимоблокировок (Dead Locks). Для каждого варианта (кроме 10-го) потребуется создать три сессии: - в сессии А : создать таблицу соответствующей структуры, заполнить ее определенным набором строк и наблюдать за изменениями состо­ яний очереди транзакций и журнала блокировок; - в сессиях Б и В: начать по одной транзакции, в каждой транзакции обновить по одной (различной) строке таблицы, транзакции НЕ фик­ сировать; - в сессии В: обновить одну (любую другую) строку таблицы, транзак­ цию НЕ фиксировать; - в сессии Б: обновить ту же строку, которая обновлялась в сессии В, транзакцию НЕ фиксировать; - в сессии В: обновить ту же строку, которая обновлялась в сессии Б, транзакцию НЕ фиксировать; - провести анализ процессов наложения и снятия блокировок: уровни и режимы блокирования объектов БД, типы накладываемых блоки­ ровок, моменты снятия блокировок и время ожидания освобождения заблокированных ресурсов; - сформировать отчет, в котором привести иллюстрации выполнен­ ного эксперимента и сделать выводы по результатам проведенного анализа.

153

Вариант 1

-

Индексированная кластеризованная таблица. Выборка строк по первичному ключу, обновление пяти различных строк двумя транзакциями: создаем таблицу (Задание 8.3, Вариант 5), вставляем 10 строк; сессия Б: обновляем строку с I D = 1, транзакцию не фиксируем; сессия В: обновляем строку с I D = 2, транзакцию не фиксируем; сессия Б: обновляем строку с I D = 3, транзакцию не фиксируем; сессия В: обновляем строку с I D = 4, транзакцию не фиксируем; сессия Б: обновляем строку с I D = 5, транзакцию не фиксируем.

Вариант 2

-

Индексированная кластеризованная таблица. Обновление совпадающих строк двумя транзакциями: создаем таблицу (см. Задание 8.3, Вариант 5), вставляем 10 строк; сессия Б: обновляем строку с I D = 1, транзакцию не фиксируем; сессия В: обновляем строку с I D = 2, транзакцию не фиксируем; сессия Б: обновляем строку с I D = 3, транзакцию не фиксируем; сессия В: обновляем строку с I D = 1, транзакцию не фиксируем; сессия Б: обновляем строку с I D = 2, транзакцию не фиксируем.

Вариант 3

-

Индексированная кластеризованная таблица. Выборка строк по первичному ключу, обновление перекрыва­ ющихся множеств строк двумя транзакциями: создаем таблицу (Задание 8.3, Вариант 5), вставляем 10 строк; сессия Б: обновляем строки с 1 D i n ( 1 1 21 3), не фиксируем; сессия В: обновляем строку с 1 D i n (41 5 1 6), не фиксируем; сессия Б: обновляем строку с 1 D i n (81 71 6), не фиксируем; сессия В: обновляем строку с 1 D i n (91 2 1 4), не фиксируем.

Вариант 4

-

Индексированная кластеризованная таблица. Выборка строк по первичному ключу, обновление перекрыва­ ющихся диапазонов строк двумя транзакциями: создаем таблицу (Задание 8.3, Вариант 5), вставляем 10 строк; сессия Б: обновляем строки с I D < 3, не фиксируем; сессия В: обновляем строку с 1 D BETWEEN 3 AN D 6, не фиксируем; сессия Б: обновляем строку с I D >= 6, не фиксируем; сессия В: обновляем строку с I D = 1, не фиксируем. 154

Вариант 5

-

-

Индексированная кластеризованная таблица. Обновление перекрывающихся диапазонов строк двумя транзакциями с выборкой строк по разным ключам: создаем таблицу (Задание 8.3, Вариант 5); вставляем в таблицу три строки: I NS E RT I NTO [d bo] . [T_TEST_4] (C_NAM E 1 I D_TYP E) VALU ES ( ' F I RST\ 10) 1 ( ' E LSE\ 12) 1 ('SOM ETH I NG\ 15); сессия Б: обновляем строки с I D = 3, транзакцию не фиксируем; сессия В: обновляем строку с C_NAM E = ' F I RSТ', не фиксируем; сессия Б: обновляем строку с I D = 1, транзакцию не фиксируем.

Вариант 6 Индексированная кластеризованная таблица. Обновление

-

перекрывающихся диапазонов строк двумя транзакциями с выборкой строк по разным ключам: создаем таблицу (Задание 8.3, Вариант 5); вставляем в таблицу три строки (Вариант 5); сессия Б: обновляем строку с C_NAM E = 'FI RSТ', не фиксируем; сессия В: обновляем строки с I D = 3, транзакцию не фиксируем; сессия В: обновляем строку с I D = 1, транзакцию не фиксируем.

Вариант 7 Индексированная кластеризованная таблица. Выборка

-

строк по различным полям таблицы, обновление пере­ крывающихся диапазонов строк двумя транзакциями: создаем таблицу (Задание 8.3, Вариант 5); вставляем в таблицу три строки (Вариант 5); сессия Б: обновляем строки с I D_TYP E = 3, не фиксируем; сессия В: обновляем строку с C_NAM E = ' E LSE', не фиксируем; сессия Б: обновляем строку с I D = 2, транзакцию не фиксируем.

Вариант 8

-

Индексированная кластеризованная таблица. Выборка строк по различным полям таблицы, обновление различ­ ных строк двумя транзакциями: создаем таблицу (Задание 8.3, Вариант 5); вставляем в таблицу три строки (см. Вариант 5); сессия Б: обновляем строки с I D = 3, не фиксируем; сессия В: обновляем строку с C_NAM E = 'FI RSТ', не фиксируем; сессия Б: обновляем строку с I D_TYP E = 12, не фиксируем. 155

Вариант 9

Индексированная кластеризованная таблица с неуникаль­ ным некластеризованным индексом. Обновление совпа­ дающих строк двумя транзакциями: первая выбирает строки по первичному ключу, вторая - по неуникальному вторичному ключу: - создаем таблицу и некластеризованный индекс (см. Задание 8.3, Вариант 1 4); - вставляем в таблицу семь строк: I NSERT I NTO [d bo] . [T_TEST_4] (C_NAM E 1 I D_TYPE) VALU ES ('TEST_l\ 10) 1 ('TEST_2\ 10) 1 ('TEST_3\ 15) 1 ('TEST_4\ 15) 1 ('TEST_3\ 20) 1 ('TEST_2\ 20) 1 ('TEST_1 \ 10);

- сессия Б: обновляем строки с I D = 1, транзакцию не фиксируем: - сессия В: обновляем строку с I D_TYP E = 15, не фиксируем; - сессия Б: обновляем строку с I D = 4, не фиксируем; - сессия В: обновляем строку с I D_TYP E = 10, не фиксируем.

Вариант 1 О Индексированная кластеризованная таблица с неуникаль­

ным некластеризованным индексом. Обновление совпа­ дающих строк тремя транзакциями с выборкой строк по первичному ключу. Для выполнения 1О-го варианта потребуется дополнительная четвер­ тая сессия Г, в которой будет выполняться третья транзакция, конкурирую­ щая с первыми двумя, выполняемыми в сессиях Б и В: - создаем таблицу и некластеризованный индекс (см. Задание 8.3, Вариант 1 4); - вставляем в таблицу семь строк (см. Вариант 9); - сессия Б: обновляем строки с I D = 1, транзакцию не фиксируем; - сессия В : обновляем строку с I D = 3, транзакцию не фиксируем; - сессия Г: обновляем строку с I D = 5, транзакцию не фиксируем; - сессия Б: обновляем строку с 1 D i n (3 1 5), транзакцию не фиксируем; - сессия В : обновляем строку с I D = 5, транзакцию не фиксируем; - сессия Г: фиксируем (COM M IT) транзакцию.

156

Задание 8.5 Анализ процесса эскалации блокировок при массовом обновле­ нии ( U P DATE) строк таблицы. Для выполнения задания рекомендуется создать две сессии: - сессия А : создаем кластеризованную таблицу CREATE TABLE [d bo] . [T_TEST_S] ( [1 D] [i nt] I DENTITY( l 1 l) N OT N U LL1 [C_NAM E] [nva rchar] ( l00) N U LL1 [1 D ТУРЕ] [i nt] N U LL PRI MARY КЕУ CLUSTER E D ( [ I D] ASC) WITH ( PAD_I N DEX = OFF1 STATISTI CS_NORECOM PUTE = OFF 1 I G N ORE_D U P_КЕУ = OFF 1 ALLOW_ROW_LOCKS = ON 1 ALLOW_PAG E_LOCKS = O N ) ON [PRI MARY] ) ON [PRI MARY] ); - сессия А: вставляем в таблицу 50 ООО строк; - сессия Б: начинаем транзакцию; - сессия Б: обновляем (пакетно) 10 строк таблицы с выборкой строк по диапазону значений первичного ключа I D; - сессия А : просматриваем очередь транзакций и журнал блоки­ ровок, сохраняем в отчете количество пользовательских тран­ закций, количество наложенных блокировок, режимы блокиро­ вания и уровни блокирования ресурсов; - повторяем два предыдущих пункта до момента эскалации бло­ кировки, то есть до тех пор, пока уровень блокируемого ре­ сурса не поднимется от строки таблицы ( ROW) или ключа ин­ декса (КЕУ) до уровня таблицы (OBJ ECT); - сохраняем в отчете количество пакетов и количество обновля­ емых строк, при котором произошла эскалация блокировки; - трижды повторяем четыре предыдущих пункта, каждый раз увеличивая размер пакетов обновления (соответственно, по 100, 1ООО и 1О ООО строк в пакете); - сессия Б: определяем количество строк в таблице с I D_TYP E = 9999 и обновляем все такие строки; - сессия А : просматриваем очередь транзакций и журнал блоки­ ровок, сохраняем в отчете информацию о результатах выпол­ нения предыдущего пункта. 157

Задание 8.6 Анализ процессов наложения и снятия блокировок с намерени­ ями (1 NTENT LOCK). Для каждого из вариантов этого задания потребу­ ется создать три сессии: - сессия А: создать таблицу соответствующей структуры, вставить в таблицу 1ООО строк и наблюдать за изменениями состояний оче­ реди транзакций и журнала блокировок в результате выполнения ко­ манд чтения строк этой таблицы в транзакциях сессиях Б и В; - сессии Б и В: начать транзакции и читать (SELECT) строки таб­ лицы или читать строки таблицы с намерением их обновления (ис­ пользуя хинт U P DLOCK: SELECT * FROM ТаЬlе WITH(UPDLOCK));

- провести анализ процессов наложения и снятия блокировок: уровни и режимы блокирования объектов БД, типы накладываемых блокировок; - сформировать отчет, в котором привести иллюстрации выпол­ ненного эксперимента и сделать выводы по результатам проведен­ ного анализа. Вариант 1

Неиндексированная таблица. Выборка строк по автоин­ крементному ключу. Чтение одной и той же строки двумя транзакциями (с намерением ее обновления): - сессия А: создаем некластеризованную таблицу: CREATE TABLE [d bo] . [T_TEST_б] ( [ I D] [i nt] I DE NTITY( l 1 l) NOT N U LL1 [C_NAM E] [nva rcha r] ( l00) N U LL1 [I D_TYPE] [i nt] N U LL)

и вставляем в нее 1 ООО строк. - сессии Б и В: читаем строку с I D = 1 с намерением обновления. Вариант 2

Неиндексированная таблица. Чтение (с намерением об­ новления) двух разных строк двумя конкурирующими транзакциями с выборкой строк по автоинкрементному ключу.: - сессия А: создаем некластеризованную таблицу (см. Вариант 1) и вставляем в нее 1 ООО строк; - сессия Б: читаем строку с I D = 1 с намерением обновления; - сессия В: читаем строку с I D = 100 с намерением обновления.

158

Вариант 3

Неиндексированная таблица. Выборка строк по автоин­ крементному ключу. Чтение (с намерением обновления) двух разных строк двумя конкурирующими транзакци­ ями (одной строки не существует): - сессия А: создаем некластеризованную таблицу (см. Вариант 1) и вставляем в нее 1 ООО строк; - сессия Б: читаем строку с 1 D = -1 с намерением обновления; - сессия В: читаем строку с I D = 1 с намерением обновления.

Вариант 4

Неиндексированная таблица. Выборка строк по автоин­ крементному ключу. Чтение (с намерением обновления) двух строк двумя транзакциями (ни одной из выбираемых строк не существует): - сессия А: создаем некластеризованную таблицу (см. Вариант 1) и вставляем в нее 1 ООО строк; - сессии Б и В: читаем строку с 1 D = -1 с намерением обновления.

Вариант 5

Индексированная кластеризованная таблица. Выборка строк по первичному ключу. Чтение одной и той же строки двумя транзакциями (с намерением обновления): - сессия А: создаем таблицу и вставляем в нее 1 ООО строк: CREATE TABLE [d bo] . [T_TEST_б] ( [ I D] [i nt] I DENTITY( l 1 l) N OT N U LL1 [C_NAM E] [nva rcha r] ( l00) N U LL1 [I D_TYPE] [i nt] N U LL) PRI MARY КЕУ CLUSTE RED ( [ I D] ASC) WITH ( PAD_I N DEX = OFF 1 STATISTI CS_N ORECOM PUTE = OFF1 I G N ORE_D U P _КЕУ = OFF 1 ALLOW_ROW_LOCKS = ON 1 ALLOW_PAG E_LOCKS = O N ) ON [PRI MARY] ) ON [PRI MARY] ); - сессии Б и В: читаем строку с I D = 1 с намерением обновления.

Вариант 6 Индексированная кластеризованная таблица. Выборка

строк по первичному ключу. Чтение двух разных строк двумя транзакциями (с намерением обновления): - сессия А: создаем кластеризованную таблицу (Вариант 5) и вставляем в нее 1 ООО строк; - сессия Б: читаем строку с I D = 1 с намерением обновления; - сессия В: читаем строку с I D = 10 с намерением обновления. 159

Вариант 7 Индексированная кластеризованная таблица. Чтение (с

намерением обновления) двумя транзакциями двух строк (одной строки не существует): - сессия А: создаем кластеризованную таблицу (Вариант 5) и вставляем в нее 1 ООО строк; - сессия Б: читаем строку с I D = 1 с намерением обновления; - сессия В: читаем строку с I D = -1 с намерением обновления.

Вариант 8

Индексированная кластеризованная таблица. Чтение (с намерением обновления) двумя транзакциями двух строк (ни одной из выбираемых строк не существует): - сессия А: создаем кластеризованную таблицу (Вариант 5) и вставляем в нее 1 ООО строк; - сессии Б и В: читаем строку с I D = -1 с намерением обновления.

Вариант 9

Индексированная кластеризованная таблица. Чтение (с намерением обновления) двух строк двумя транзакциями с выборкой строк по разным ключам: - сессия А: создаем кластеризованную таблицу (Вариант 5) и вставляем в нее 1 ООО строк; - сессия Б: читаем строку с I D = 1 с намерением обновления; - сессия В: читаем строку с I D_TYP E = 1 с намерением обновления.

Вариант 1 О Индексированная кластеризованная таблица. Чтение (с

намерением обновления) двух строк двумя транзакциями с выборкой строк по разным ключам: - сессия А: создаем кластеризованную таблицу (Вариант 5) и вставляем в нее 1 ООО строк; - сессия Б: читаем строку с I D_TYP E = 12 с намерением обновления; - сессия В: читаем строку с 1 D = 1 с намерением обновления.

Вариант 1 1 Индексированная кластеризованная таблица. Чтение (с

намерением обновления) двух строк двумя транзакциями с выборкой строк по разным ключам: - сессия А: создаем кластеризованную таблицу (Вариант 5) и встав­ ляем в нее 1 ООО строк; - сессия Б: читаем строку с I D = 1 с намерением обновления; - сессия В: читаем строку с С NAM E = 'SOM E 1 с намерением обновления. 1 60

Вариант 12 Индексированная кластеризованная таблица. Чтение (с

намерением обновления) двух строк двумя транзакциями с выборкой строк по разным ключам: - сессия А: создаем кластеризованную таблицу (Вариант 5) и встав­ ляем в нее 1 ООО строк; - сессия Б: читаем строку с C_NAM E = 'SOM E 1 с намерением обновления; - сессия В: читаем строку с 1 D = 1 с намерением обновления. Вариант 1 3 Индексированная кластеризованная таблица с некласте­ ризованным индексом по полю I D_TYPE. Чтение (с наме­ рением обновления) двух строк двумя транзакциями с вы­ боркой строк по разным ключам: - сессия А: создаем кластеризованную таблицу (Задание 8.3, Вариант 14) и вставляем в нее 1 ООО строк; - сессия Б: читаем строку с I D = 1 с намерением обновления; - сессия В: читаем строку с I D_TYP E = 1 с намерением обновления. Вариант 1 4 Индексированная кластеризованная таблица с некласте­ ризованным индексом по полю I D_TYPE. Чтение (с наме­ рением обновления) двух строк, выбираемых двумя тран­ закциями по значениям индексированных столбцов: - сессия А: создаем кластеризованную таблицу (Задание 8.3, Вариант 14) и вставляем в нее 1 ООО строк; - сессия Б: читаем строку с I D_TYP E = 1 с намерением обновления; - сессия В: читаем строку с 1 D = 1 с намерением обновления. Вариант 1 5 Индексированная кластеризованная таблица с некласте­ ризованным индексом по полю I D_TYPE. Чтение (с наме­ рением обновления) двух строк, выбираемых двумя тран­ закциями по значениям индексированных столбцов: - сессия А: создаем кластеризованную таблицу (Задание 8.3, Вариант 14) и вставляем в нее 1 ООО строк; - сессия А: находим max_sel_id_type - знaчeниe I D_TYPE с максималь­ ной степенью селективности (максимальное количество строк таб­ лицы с таким значением); - сессия Б: читаем строку с I D = 1 с намерением обновления; - сессия В: читаем строку с I D_TYP E = max_sel_id_type с намерением обновления. 161

Вариант 1 6 Индексированная кластеризованная таблица с некласте­

ризованным индексом по полю I D_TYPE. Выборка строк по первичному и вторичному индексам. Чтение (с наме­ рением обновления) двух строк двумя транзакциями:

- сессия А : создаем кластеризованную таблицу (Задание 8.3, Ва­ риант 14) и вставляем в нее 1 ООО строк; - сессия А : находим mi n_sel_id_type - значение I D_TYPE с макси­ мальной степенью селективности (минимальное количество строк таблицы с таким значением); - сессия Б: читаем строку с I D = 1 с намерением обновления; - сессия В: читаем строку с I D_TYPE = mi n_sel_id_type с намерением обновления. Вариант 1 7 Индексированная кластеризованная таблица. Выборка

строк по автоинкрементному полю. Чтение (с намере­ нием обновления) строки первой транзакцией и обновле­ ние этой же строки второй транзакцией: - сессия А : создаем кластеризованную таблицу (Задание 8.3, Ва­ риант 14) и вставляем в нее 1 ООО строк; - сессия Б: читаем строку с I D = 1 с намерением обновления; - сессия В: обновляем строку с 1 D = 1.

Вариант 1 8 Индексированная кластеризованная таблица. Выборка

строк по автоинкрементному полю. Обновление одной строки первой транзакцией и чтение (с намерением об­ новления) этой же строки второй транзакцией: - сессия А : создаем кластеризованную таблицу (Задание 8.3, Ва­ риант 14) и вставляем в нее 1 ООО строк; - сессия Б: обновляем строку с I D = 1; - сессия В: читаем строку с I D = 1 с намерением обновления.

Задание 8.7 Анализ процессов наложения и снятия блокировок с намерени­ ями (1 NTENT LOCK) с пропуском заблокированных строк. Для каждого из вариантов этого задания потребуется создать три сессии: - в сессии А: создать таблицу соответствующей структуры, вста­ вить в таблицу 1 ООО строк и наблюдать за изменениями состояний очереди транзакций и журнала блокировок в результате выполнения команд чтения строк этой таблицы в транзакциях сессий Б и В; 162

- в сессиях Б и В: начать транзакции, читать (SELECT) строки таб­ лицы или читать строки таблицы с намерением их обновления и пропуском заблокированных (используя хинты U PDLOCK и READPAST); - провести анализ процессов наложения и снятия блокировок: уровни и режимы блокирования объектов БД, типы накладываемых блокировок; - сформировать отчет, в котором привести иллюстрации выпол­ ненного эксперимента и сделать выводы по результатам проведен­ ного анализа. Вариант 1 Неиндексированная таблица. Чтение одной (любой) строки двумя конкурирующими транзакциями (с намере­ нием блокировки обновления и пропуском заблокирован­ ных строк): - сессия А: создаем некластеризованную таблицу и вставляем в нее 1000 строк: CREATE TABLE [d bo] . [T_TEST_7] ( [1 D] [i nt] I DENTITY( l 1 l) N OT N U LL1 [C_NAM E] [nva rcha r] ( l00) N U LL1 [I D_TYPE] [i nt] N U LL); - сессия Б: начинаем транзакцию; - сессия В: начинаем транзакцию; - сессия А: анализируем очередь транзакций и журнал блокировок; - сессия Б: читаем одну строку с хинтами U P DLOCK и READPAST; - сессия А: анализируем очередь транзакций и журнал блокировок; - сессия В: читаем одну строку с хинтами U P DLOCK и READPAST; - сессия А: анализируем очередь транзакций и журнал блокировок. Вариант 2

Неиндексированная таблица. Выборка строк по автоин­ крементному ключу. Чтение одной и той же строки двумя транзакциями (с намерением блокировки обновления и пропуском заблокированных строк): - сессия А: создаем некластеризованную таблицу (Вариант 1) и вставляем в нее 1 ООО строк; - сессии Б и В: начинаем транзакции; - сессия А: анализируем очередь транзакций и журнал блокировок; 163

-

сессия Б: сессия А: сессия В: сессия А:

читаем строку с 1 D = 1 с хинтами U P DLOCK и READPAST; анализируем очередь транзакций и журнал блокировок; читаем строку с 1 D = 1 с хинтами U P DLOCK и READPAST; анализируем очередь транзакций и журнал блокировок.

Вариант 3

-

Неиндексированная таблица. Выборка строк по автоин­ крементному ключу. Чтение нескольких строк из диапа­ зона значений ключа двумя конкурирующими транзакци­ ями (с намерением блокировки обновления и пропуском заблокированных строк): сессия А: создаем некластеризованную таблицу (Вариант 1) и вставляем в нее 1 ООО строк; сессии Б и В: начинаем транзакции; сессия А: анализируем очередь транзакций и журнал блокировок; сессия Б: читаем 5 строк с 1 D > 10 с хинтами U P DLOCK и READPAST; сессия А: анализируем очередь транзакций и журнал блокировок; сессия В: читаем 5 строк с 1 D > 10 с хинтами U PDLOCK и READPAST; сессия А: анализируем очередь транзакций и журнал блокировок.

Вариант 4

-

Неиндексированная таблица, строки отсортированы по 1 D. Чтение одной (любой) строки двумя конкурирующими транзакциями (с намерением блокировки обновления и пропуском заблокированных строк): сессия А: создаем некластеризованную таблицу (Вариант 1) и вставляем в нее 1 ООО строк; сессия Б: начинаем транзакцию; сессия В: начинаем транзакцию; сессия А: анализируем очередь транзакций и журнал блокировок; сессия Б: читаем одну строку без условий с сортировкой по полю ID с хинтами U PDLOCK и READPASТ. сессия А: анализируем очередь транзакций и журнал блокировок; сессия В: читаем одну строку без условий с сортировкой по полю ID с хинтами U PDLOCK и READPASТ. сессия А: анализируем очередь транзакций и журнал блокировок. 164

Вариант 5

Индексированная кластеризованная таблица. Чтение од­ ной (любой) строки двумя конкурирующими транзакци­ ями (с намерением блокировки обновления и пропуском заблокированных строк):

- сессия А: создаем таблицу и вставляем в нее 1 ООО строк: CREATE TABLE [d bo] . [T_TEST_7] ( [ 1 D] [i nt] I DE NTITY( l 1 l) NOT N U LL1 [C_NAM E] [nva rchar] ( l00) N U LL1 [I D_TYPE] [i nt] N U LL) PRI MARY КЕУ CLUSTE RED ( [ I D] ASC) WITH ( PAD_I N DEX = OFF1 STATISTI CS_NORECO M P UTE = OFF1 I G N ORE_D U P_КЕУ = OFF 1 ALLOW_ROW_LOCKS = ON 1 ALLOW_PAG E_LOCKS = O N ) ON [PRI MARY] ) ON [PRI MARY] );

- сессии Б и В: начинаем транзакции; - сессия А: анализируем очередь транзакций и журнал блокировок; - сессия Б: читаем одну строку с хинтами U P DLOCK и READPAST; - сессия А: анализируем очередь транзакций и журнал блокировок;

- сессия В: читаем одну строку с хинтами U P DLOCK и READPAST; - сессия А: анализируем очередь транзакций и журнал блокировок. Вариант 6 Индексированная кластеризованная таблица. Выборка

-

строк по первичному ключу. Чтение одной и той же строки двумя конкурирующими транзакциями (с намере­ нием блокировки обновления и пропуском заблокирован­ ных строк): сессия А: создаем кластеризованную таблицу (см. Вариант 5) и вставляем в нее 1 ООО строк; сессии Б и В: начинаем транзакции; сессия А: анализируем очередь транзакций и журнал блокировок; сессия Б: читаем строку с 1 D = 1 с хинтами U P DLOCK и READPAST;

- сессия А: анализируем очередь транзакций и журнал блокировок; - сессия В: читаем строку с 1 D = 1 с хинтами U P DLOCK и READPAST; - сессия А: анализируем очередь транзакций и журнал блокировок.

165

Вариант 7 Индексированная

-

кластеризованная таблица. Чтение строк двумя конкурирующими транзакциями (с намере­ нием блокировки обновления и пропуском заблокирован­ ных строк): сессия А: создаем кластеризованную таблицу (см. Вариант 5) и вставляем в нее 1 ООО строк; сессия Б: начинаем транзакцию; сессия В: начинаем транзакцию; сессия А: анализируем очередь транзакций и журнал блокировок; сессия Б: читаем одну строку без условий с сортировкой по полю ID с хинтами U PDLOCK и READPAST; сессия А: анализируем очередь транзакций и журнал блокировок; сессия В: читаем одну строку без условий с сортировкой по полю ID с хинтами U PDLOCK и READPAST; сессия А: анализируем очередь транзакций и журнал блокировок.

Вариант 8

-

Индексированная кластеризованная таблица. Выборка строк по неуникальному ключу. Чтение одной строки двумя транзакциями (с намерением блокировки обновле­ ния и пропуском заблокированных строк): сессия А: создаем кластеризованную таблицу (см. Вариант 5) и вставляем в нее 1 ООО строк; сессии Б и В: начинаем транзакции; сессия А: анализируем очередь транзакций и журнал блокировок; сессия Б: читаем строку с I D_TYPE = 1 с хинтами U PDLOCK и READPAST; сессия А: анализируем очередь транзакций и журнал блокировок; сессия В: читаем строку с I D_TYPE = 1 с хинтами U PDLOCK и READPAST; сессия А: анализируем очередь транзакций и журнал блокировок.

Задание 8.8 Анализ процессов наложения и снятия блокировок транзакци­ ями, создающими (CREATE) и модифицирующими (ALTER) схемы таб­ лиц. Для каждого из вариантов этого задания потребуется создать три сессии: - в сессии А: создать таблицу соответствующей структуры, вста1 66

вить в таблицу 100 строк и наблюдать за изменениями состоя­ ний очереди транзакций и журнала блокировок в результате вы­ полнения команд в транзакциях сессий Б и В; - в сессиях Б и В: начать транзакции и выполнять соответствую­ щие команды; - провести анализ процессов наложения и снятия блокировок (уровни и режимы блокирования объектов БД, типы накладываемых блокировок; - сформировать отчет, в котором привести иллюстрации выпол­ ненного эксперимента и сделать выводы по результатам проведен­ ного анализа. Вариант 1

Модификация таблицы первой транзакцией и чтение строк таблицы второй транзакцией:

- сессия А: создаем некластеризованную таблицу вставляем в нее 100 строк и анализируем очередь транзакций и журнал блокировок:

-

CREATE TABLE [d bo] . [T_TEST_] ( [1 D] [i nt] I DENTITY( l 1 l) N OT N U LL1 [C_NAM E] [nva rchar] ( l00) N U LL1 [I D_TYPE] [i nt] N U LL);

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

Вариант 2 Чтение строк таблицы первой транзакцией и модифика-

-

ция таблицы второй транзакцией: сессия А: создаем таблицу (Вариант 1); сессия А: анализируем очередь транзакций и журнал блокировок; сессии Б и В: начинаем транзакции; сессия Б: читаем строку с выборкой по 1 D; сессия А: анализируем очередь транзакций и журнал блокировок; сессия В: добавляем в таблицу колонку C_SOM E i nteger; сессия А: анализируем очередь транзакций и журнал блокировок.

167

Вариант 3

Модификация схемы таблицы двумя транзакциями (добавление одинаковых колонок): - сессия А: создаем таблицу (Вариант 1); - сессия А: анализируем очередь транзакций и журнал блокировок; - сессии Б и В: начинаем транзакции; - сессия Б: добавляем в таблицу колонку C_SOME integer; - сессия А: анализируем очередь транзакций и журнал блокировок; - сессия В: добавляем в таблицу такую же колонку C_SOME integer; - сессия А: анализируем очередь транзакций и журнал блокировок. Вариант 4 Модификация таблицы двумя транзакциями (добавление разных колонок): - сессия А: создаем таблицу (Вариант 1); - сессия А: анализируем очередь транзакций и журнал блокировок; - сессии Б и В: начинаем транзакции; - сессия Б: добавляем в таблицу колонку C_SOM E i nteger; - сессия А: анализируем очередь транзакций и журнал блокировок; - сессия В: добавляем в таблицу такую же колонку C_CASE i nteger; - сессия А: анализируем очередь транзакций и журнал блокировок. Вариант 5 Модификация таблицы двумя транзакциями (добавление колонки и создание индекса): - сессия А: создаем таблицу (Вариант 1); - сессия А: анализируем очередь транзакций и журнал блокировок; - сессии Б и В: начинаем транзакции; - сессия Б: добавляем в таблицу колонку C_SOM E i nteger; - сессия А: анализируем очередь транзакций и журнал блокировок; - сессия В: создаем индекс по полю I D_TYP E; - сессия А: анализируем очередь транзакций и журнал блокировок. Вариант 6 Модификация таблицы двумя транзакциями (создание индекса и добавление колонки): - сессия А: создаем таблицу (см. Вариант 1); - сессия А: анализируем очередь транзакций и журнал блокировок; - сессии Б и В: начинаем транзакции; - сессия Б: создаем индекс по полю I D_TYPE; - сессия А: анализируем очередь транзакций и журнал блокировок; - сессия В: добавляем в таблицу колонку C_SOM E i nteger; - сессия А: анализируем очередь транзакций и журнал блокировок. 1 68

Вариант 7 Создание одноименных таблиц двумя транзакциями:

-

сессия А : анализируем очередь транзакций и журнал блокировок; сессии Б и В: начинаем транзакции; сессия Б: создаем таблицу Т_TEST_7; сессия А : анализируем очередь транзакций и журнал блокировок; сессия В: создаем таблицу Т_TEST_7; сессия А : анализируем очередь транзакций и журнал блокировок.

Вариант 8

-

Создание разноименных таблиц двумя транзакциями: сессия А : анализируем очередь транзакций и журнал блокировок; сессии Б и В: начинаем транзакции; сессия Б: создаем таблицу Т_TEST_8; сессия А : анализируем очередь транзакций и журнал блокировок; сессия В: создаем таблицу Т_TEST_8_; сессия А : анализируем очередь транзакций и журнал блокировок.

Задание 8.9 Анализ процессов наложения и снятия блокировок транзакци­ ями с промежуточными точками сохранения (SAVE POI NT). Для каж­ дого из вариантов этого задания потребуется создать две сессии: - в сессии А : создать таблицу соответствующей структуры, вста­ вить строки в таблицу и наблюдать за изменениями состояния таб­ лицы, очереди транзакций и журнала блокировок в результате вы­ полнения команд в транзакциях сессии Б; - в сессии Б: начать транзакцию, вставлять и обновлять строки таблицы, создавать точки сохранения, выполнять откат и фикса­ цию транзакции; - провести анализ процессов наложения и снятия блокировок (уровни и режимы блокирования объектов БД, типы накладыва­ емых блокировок; - сформировать отчет, в котором привести иллюстрации выпол­ ненного эксперимента и сделать выводы по результатам проведен­ ного анализа.

169

Откат транзакции до точки сохранения: - сессия А : создаем таблицу:

Вариант 1

CREATE TABLE [d bo] . [T_TEST_9] (

[1 D] [i nt] I DENTITY( l 1 l) N OT N U LL1 [C_NAM E] [nva rcha r] ( l00) N U LL1

[I D_TYPE] [i nt] N U LL);

- сессия Б: вставляем в таблицу две строки: I NS E RT I NTO [d bo] . [T_TEST_9] (C_NAM E 1 I D_TYP E) VALU ES ('TEST_l\ 10) 1 ('TEST_2\ 20);

- сессия Б: создаем транзакцию и выполняем код: BEG I N TRANSACTI ON u pdate d bo.T_TEST_9 set c_name = ' E LSE_l'

where id = 1

SAVE TRANSACTION QWE

u pdate d bo.T_TEST_9 set c_name = ' E LSE_2'

where id = 2

ROLLBACK TRANSACTI ON QWE

COM M IT; - сессия А : анализируем состояние таблицы, очереди транзакций и журнала блокировок. Какое значение сохранено в поле C_NAM E в строках с 1 D = 1 и 1 D = 27 Вариант 2

Без отката транзакции до точки сохранения:

- сессия А : создаем таблицу:

CREATE TABLE [d bo] . [T_TEST_9] (

[1 D] [i nt] I DENTITY( l 1 l) N OT N U LL1 [C_NAM E] [nva rchar] ( l00) N U LL1 [I D_TYPE] [i nt] N U LL);

- сессия Б: вставляем в таблицу две строки:

I NS E RT I NTO [d bo] . [T_TEST_9] (C_NAM E 1 I D_TYP E)

VALU ES ('TEST_l\ 10) 1 ('TEST_2\ 20) 170

- сессия Б: создаем транзакцию и выполняем код: BEG I N TRANSACTI ON u pdate d bo.T_TEST_9

set с name = ' E LSE'

where id = 1

SAVE TRANSACTI ON QWE u pdate d bo.T_TEST_9

set с name = ' E LSE'

where id = 2

COM M IT - сессия А : анализируем состояние таблицы, очереди транзакций и журнала блокировок. Какое значение сохранено в поле C_NAM E в строках с 1 D = 1 и 1 D = 27

Полный откат транзакции: - сессия А : создаем таблицу:

Вариант 3

CREATE TABLE [d bo] . [T_TEST_9] ( [1 D] [i nt] I DENTITY( l 1 l) N OT N U LL1 [C_NAM E] [nva rchar] ( l00) N U LL1 [I D_TYPE] [i nt] N U LL);

- сессия Б: вставляем в таблицу две строки: I NS E RT I NTO [d bo] . [T_TEST_9] (C_NAM E 1 I D_TYP E)

VALU ES ('TEST_l\ 10) 1 ('TEST_2\ 20); - сессия Б: создаем транзакцию и выполняем код : BEG I N TRANSACTI ON u pdate d bo.T_TEST_9 set c_name = ' E LSE' where id = 1 SAVE TRANSACTION QWE u pdate d bo.T_TEST_9 set c_name = ' E LSE' where id = 2 ROLLBACK; - сессия А : анализируем состояние таблицы, очереди транзакций и журнала блокировок. Какое значение сохранено в поле C_NAM E в строках с 1 D = 1 и 1 D = 27 171

Вариант 4 Использование точек сохранения при цикличной обра­

ботке строк таблицы: - сессия А: создаем таблицу:

CREATE TABLE [d bo] . [T_TEST_9] ( [1 D] [i nt] I DE NTITY( l 1 l) NOT N U LL1 [C_NAM E] [nva rchar] ( l00) N U LL1 [I D_TYPE] [i nt] N U LL);

- сессия Б: вставляем в таблицу четыре строки: I NS E RT I NTO [d bo] . [T_TEST_9] (C_NAM E 1 I D_TYP E)

VALU ES ('TEST_l\ 10) 1 ('TEST_2\ 20) 1 ('TEST_3\ 30) 1 ('TEST_4\ 40); - сессия Б: выполняем код: DECLARE @i i nteger = 01 @ max i nteger1 @type i nteger SELECT @ max = MAX( I D) FROM [d bo] . [T_TEST_9] BEG I N TRANSACTION WH I LE @ i < @ max BEG I N SE LECT @type = I D_TYPE FROM [d bo] . [T_TEST_9] WH E R E 1 D = @ i SAVE TRANSACTION TEST U P DATE [d bo] . [T_TEST_9] SET С NAM E = 'CHAN G E D' WHERE 1 D = @ i I F @type < 30 BEG I N COM M IT BEG I N TRANSACTION END ELSE BEG I N ROLLBACK TRANSACTI ON TEST END END COM M IT - сессия А : анализируем состояние таблицы, очереди транзакций и журнала блокировок. Какое значение сохранено в поле C_NAM E в строках с 1 D = 1 ? 172

8.5 Контрольные вопросы 1 2 3 4 5 6 7 8 9 1О 11 12

14 15 16 17 18 19

Что такое транзакция (согласно стандарту SQL/92)? В каком случае SQL-команда будет считаться транзакцией? Какие свойства транзакций обозначены аббревиатурой «ACID»? Чем обеспечивается свойство атомарности транзакции? Чем обеспечивается свойство завершенности транзакции? Допускается ли рассогласованное состояние БД перед началом транзакции и в момент ее завершения? Допускается ли рассогласованное состояние БД «внутри» транзак­ ции? Может ли транзакция, «читающая» объект БД, создать проблему для другой транзакции, также «читающей» этот же объект? Может ли транзакция, «читающая» объект БД, создать проблему для другой транзакции, модифицирующей этот же объект? Может ли транзакция, модифицирующая объект БД, создать про­ блему для другой транзакции, «читающей» этот же объект? Может ли транзакция, модифицирующая объект БД, создать про­ блему для другой транзакции, модифицирующей этот же объект? Приведите примеры проявления конфликтных ситуаций при конкурентном доступе к объектам БД нескольких транзакций: проблема «потерянного обновления»; проблема «чтения грязных данных»; проблема «неповторяющегося чтения»; проблема «кортежей-фантомов». Какие уровни изолированности транзакций позволяют решить проблему «потерянных изменений»? Какие уровни изолированности транзакций позволяют решить проблему «чтения грязных данных»? Какие уровни изолированности транзакций позволяют решить проблему «неповторяющегося чтения»? Какие уровни изолированности транзакций позволяют решить проблему «кортежей-фантомов»? Какой уровень изолированности транзакций устанавливается по умолчанию в СУБД MS SQL-Server? Какие блокировки считаются «высокоуровневыми», а какие «низкоуровневыми»? 173

20 Приведите примеры эскалации и деэскалации блокировок. 2 1 Какие режимы блокировки объекта совместимы с блокировкой в режиме «намерение монопольного доступа»? 22 Какие режимы блокировки объекта совместимы с блокировкой в режиме «монопольного доступа»? 23 Какие режимы блокировки объекта совместимы с блокировкой в режиме «совмещенного доступа»? 24 Какие режимы блокировки объекта совместимы с блокировкой в режиме «обновления»? 25 Что такое «тупиковые» блокировки? Предложите алгоритмы их обнаружения и устранения? 26 Какую информацию содержат «Журнал блокировок» и «Очередь транзакций» и в каких компонентах системного каталога базы дан­ ных хранится эта информация? 27 Опишите алгоритм взаимодействия менеджеров транзакций и бло­ кировок. 28 Транзакция изменила строку таблицы. Будут ли «видеть» эти из­ менения другие транзакции? Что нужно сделать, чтобы они их «увидели»? 29 Какой командой можно зафиксировать изменения в транзакции? 30 Какой командой можно отменить изменения в транзакции? 3 1 Две параллельные транзакции модифицируют структуру разных таблиц базы данных. Будут ли заблокированы обе эти таблицы или какая-то одна из них? Если да, то в каком режиме? 32 Две параллельные транзакции модифицируют структуру одной таблицы базы данных. Будет ли заблокирована эта таблица? Если да, то в каком режиме? 33 Две параллельные транзакции создают новые таблицы с разными именами. Будут ли заблокированы обе эти таблицы или какая-то одна из них? Если да, то в каком режиме? 34 Две параллельные транзакции создают одноименные таблицы. Бу­ дут ли заблокированы обе эти таблицы или какая-то одна из них? Если да, то в каком режиме?

174

Тема 9. ЗАЩИТА ДАННЫХ 9.1 Триада CIA Информационная безопасность включает три базовых компонента конфиденциальность, целостность и доступность, называемые «триадой CIA» (Conjidentiality, Integ,�ity, Availabllity). Конфиденциальность - это спо­ собность защитить данные от лиц, не имеющих к ним прав доступа. До­ ступность - это возможность предоставить санкционированный доступ к данным. Целостность - это предотвращение несанкционированного изме­ нения данных с возможностью выполнения отката таких изменений в слу­ чае нарушения целостности. Для реализации требований CIA используется стратегия глубокой многоуровневой защиты [4], согласно которой на каждом ее уровне разме­ щаются соответствующие средства защиты и применяются защитные меры, затрудняющие несанкционированные проникновения и атаки зло­ умышленников (рисунок 9.1). Хает

Внутренняя сет ь

Рисунок 9.1 - Глубокая защита Типовой набор защитных мер, применяемых на уровне данных, вклю­ чает ограничение (и разграничение) доступа пользователей к объектам дан­ ных, маскирование и шифрование данных, а также резервное копирование и восстановление данных. Соответствующие средства защиты могут быть реализованы как файловыми системами, так и серверами баз данных (в слу­ чае использования баз данных в информационных системах). 175

9.2 Примеры 9.2.1 Управление доступом к данным Большинство коммерческих серверов баз данных используют техно­ логию дискреционного управления доступам (discretionary access control), обеспечивающую логическую защиту данных путем разграничения прав доступа к поименованным объектам данных логического уровня (баз дан­ ных, таблиц, хранимых представлений, функций и процедур) со стороны субъектов доступа (пользователей и их групп, хранимых функций и проце­ дур). Информация о субъектах доступа, как и информация о логических объектах данных, хранится в соответствующих таблицах системных ката­ логов баз данных, из чего следует, что выдача субъекту разрешения (permission) доступа к объекту данных - это установление связи между эк­ земплярами субъектов и объектов доступа, а определение типа разрешения доступа - присвоение соответствующего значения атрибуту такой связи. Таким образом, разрешение доступа также является логическим объектом базы данных, что ограничивает возможности использования технологий дискреционного управления доступом в информационных системах повы­ шенного уровня защищенности. MS SQL-Server поддерживает двухуровневую архитектуру системы дискреционного управления доступом (рисунок 9.2). Субъектами доступа уровня сервера баз данных являются учетные записи (logins) пользователей и фиксированные серверные роли, использу­ емые для группировки учетных записей. На этом уровне производится идентификация и аутентификация учетных записей, их распределение по серверным ролям, в результате чего учетные записи получают соответ­ ствующие глобальные разрешения (permissions) выполнения операций с базами данных, управляемыми сервером. На уровне базы данных производится авторизация субъектов до­ ступа, в результате которой они получают соответствующие разрешения доступа к объектам этой базы данных. Субъекты доступа этого уровня пользователи базы данных, каждый из которых ассоциирован с определен­ ной учетной записью сервера, и роли базы данных, используемые для груп­ пировки субъектов доступа. На уровне базы данных используются роли трех категорий: фиксированные роли, через членство в которых субъекты доступа получают глобальные разрешения ко всем объектам базы данных; 176

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

Участники

3-l!lu.tН щa�мЬl.ВASE СRЕд.ТЕ DПl!.RASE OROP DA.TABASE

::. processadmin

i±I

MembeгSID G�E 1CD5A1 1 ED35144D9788888CAЗDDD2 1 3

dkгeatoг

i:i user1

Г:ЕI

Ser,eгRole Me111beгName ' dkгeatoг i adm 1

З

:., sa Е1

•

-

tJ

Объекты с ервер а Репликаци.� PolyBase Управл ение Профилировщик XEvent >

О Запрос успешно выпол нен.

Рисунок 9.4 - Создание учетных записей и управление их членством в фиксированных серверных ролях

1 80

Пример 9.2 Выборка данных из системной таблицы Syslogi ns (рисунок 9.5). 1::- U S E .мАSТ Е R � S E L EC Т name , isntname , FR01,1 SYSLOG П!JS

Базы данных Системные ба з ы данных М о м енталь ные сни м ки ба з ы ,а а н ных i MyDB Без о пасность Имена для входа :,. -##MS_PolicyEventProce,singlogiп#i't i:ic i't#MS_PolicyTsqlExecutioпlogini't-# i:i adm 1 i:i adm2 ,li BUILТIN\Пользователи i:i LAPTOP-06A220 1 1\vk_vo i:i NТ AUTHORITY\CИCПMA i:i NТ Service\MSSQLSERVER i:i NТ SERVICE\SQLTШMEТRY i:i NТ SERVIC E\SQLWriter i:i NT SERVICE\Wiпmgmt

l

100 %

sysadmin , securityadmin , dbc reator

т

m1 Резульпны �il Сообщения name

2 з 4

5 б

lli!M S_S OLR esou гсе:S i g 11 i 11 g С ertifi catei!li ,'l;':'MS_SOLRe pl1cat1oпS1gп1пgC ert1!1cat�# ll#M S_S OLAuth епt, cato� ertif, catellll ,'l;':'MS_Pol1 cyS1g11 111g Cert1f1cate,I/II ll# MS_S1110E,te11dedS1gn111gC e,rt1ficatellll

1s-ntпame

sys admin

se,cuпtyadm,n

d bereator

[1

[1

о

[1

[1

()

: [1 [1 [1 Q Q

() [1

о о

о о

[1

о

Q

NT S ER\'IC E·•. SOL\liiпte,г

11

NТ S erv,ce\MSSOLSERVER

12

BUILТI/JЛоль:ювател'1

о

13

Ю AUTHORIТY\C И CTEMA

14

NT SERV1C E\SQLTELEMETRY

15

#i!MS_Poli cyEveпtProce,ssi ngloginll#

8 g

10

i:i user1

..................................................

о о о

7

:,. sa

Гsа .........................

,'l;':'MS_Poli cyTsqlE,eп1tionloginll# LAPTOP-Cl5A22Cl1 l\vk_vo NT SER\/IC E\Winmgmt

G G

Q

() [1

()

[1 [1 [1 [1

о

[1 [1 [1 [1

G

[1

[1

Q

о о

[1

о о

Рисунок 9.5 - Результат просмотра списка учетных записей и их членства в фиксированных ролях сервера Пример 9.3 Создание и модификация пользователей и ролей базы дан­ ных, управление разрешениями доступа (рисунок 9.6). MyD B Диаграммы баз даннЬ"1х Таблицы ffi III Системные таблицы ffi III FileTaЫes ffi III Внешние таблицы ffi III Графовые таблицы 8 m1 dЬо.МуТаЫе III Столбцы ..о I D (РК, int, Не NUЩ § Data (char(8), NULL) ffi III Клюци ffi III Ограницения ffi III Триггеры ffi III Индексы ffi III Статистика Е1 m1 dЬо.МуТаЫе 1 8 111 Столбцы § 1D (int, NULL) § Name (char(1 6), NUЩ

в

"

E US E NyDB С R ЕАТ Е US ER u s 1 F OR LOG IN u se r1 СR ЕАТ Е US ER u s 2 F OR LOG IN adm l СR ЕАТ Е US ER u s 3 FOR LOG IN adm2 ALТER ROLE db_secu rityadm in ADD MENB ER u s_З ALТER ROL E db dat awrit e r ADD M E NB ER u s 2 ALT ER USER u s - 1 WITH NAME=bad-u s e r ALTER ROLE db_denydatawrit e r ADD ME MB ER bad u se r ALT E R ROL E db_denydata reade r ADD MENE ER bad u se r GRANT CR EATE PROC Т О U S 2 GRANT CR EATE VIEW ТО US 1 C R EAT E ROL E U s e r sRole GRANT S E LECT ON МуТаЫе ТО U se r sRole GRANT S E LECT ON MyTaЬle l : Name ) TO U s e r sRole DENY D E L ET E , INS ERT ON МуТаЫе ТО U se r sRole DENY UPDAT E ON NyTaЬle ( DATA ) ТО U s e r sRole ALTER ROLE Use r sRole ADD M EMB ER u s 2 ALTER ROL E U s e r sRole ADD M EMB ER u s 3 ALT ER ROL E U sersRole ADD MEMB ER bad u se r

Рисунок 9.6 - SQL-средства управления субъектами и разрешениями 181

Пример 9.4 Субъекты доступа - пользователи и роли БД (рисунок 9.7) . .::. US E l'\yDB l s E L E C T uid , name , s id , i s s qlu s e r , i s s ql ro le FROM Sy sUse r s 1/!)

Р езульт а ты � Сообщения uid

о

2 3 4 5 5 7 81 538-4 1 6 38-5 1 538-5 1 538-7 1 6 38-91 639-0 1 539-1 1 6 39-2 1 639-3

name puЬli c dbo guest INF ORMATION SCHEMA

sid 0>".0 1 05000000000009-04000000Ю 74 1 В О... о.._о 1 050000000000051 5000000F GG2 F 7...

о... оо

NULL NULL G>".5D55G7F9-3B BВЗF4 1 A29-536B GA 1 F3B9-... О�Е 1 GD5A 1 1 E D351 44D9-78-8-8-8-8-CA3DDD . .. О>'.50751 4 059Е 56АЗ4Е 8-9-8-ЗGD ЕВ 1 1 Е37В .. о.._о 1 05000000000009-04 0000005055А2 7. ..

sys

bad_user us_2 us_3 UsыsRole db_owner db_accessad m i n db_secu rityad m i n db_ddladmin db_backupoperator db_datare ader db_datawriter d Ь_d е nyd ata ге а d е г db_denydatawriter

о...о 1 05000000000009-04 0000000000000 .. о,,._о 1 05000000000009-04 ООООООООСЮООО .. о,,._о 1 0500000000000-9-04 0000000000000 .. : о...о 1 05000000000009-04 0000000000000 .. о...о 1 05000000000009-04 0000000000000 .. о...о 1 05000000000009-04 0000000000000 .. о...о 1 05000000000009-04 0000000000000 .. о,,._о 1 05000000000009-04 00000000-0-0000 .. о,,._о 1 0500000000000-9-04 0000000000000 ..

issqlu � er

is�qlrole

о о

о о о о о о о

о о о о !о о о о о о

Рисунок 9.7 - Выборка данных из системной таблицы SysUsers

l

Пример 9.5 Просмотр разрешений доступа субъектов к объектам БД с ис­ пользованием системной процедуры sp_helprotect (рисунок 9.8). 1::. US E �lyDB

ii MyDB 1±1 Диа,раммы баз данных 8 Таблицы Системные таблицы ЕВ FileTaЬles 1±1 Внешние таблицы ЕВ 1±1 1111 Графовые таблицы В m! dЬо.МуТаЫе С,олбцы Е1 .о 10 (РК. int, Не NULL) Е3 Data (char(3), NULL) Ключи 1±1 1±: Ограничения f:Б li Триггеры ЕВ Индекс ы Стати стика 1±1 Е1 m! dЬо.МуТаЫе 1 Столбцы В Е3 1D (int, NULL) Е1 Name (char(1 б), NUЩ

"'

100 %

EXEC ЕХЕС ЕХЕС ЕХЕС �

sp_help rotect sp_help rotect sp_help rotect sp_he lp rot e ct

nul l , u s e r s role , null , ' о ' null , bad_u ser , nul l , ' s ' null , u s_2 , пul l , ' s ' nul l , u s_З , nu ll , ' s '

m! Резульппы @111 Сообщения

-1

-

Оwпег

г····-···: dbe>

Ob1 e ct

-

МуТаЫе

Graпtee

-

U sersRole

-

G rantor

Р re>lec!Tуре

dbo

D епу

-

-

Actioп

Update

-

Ce>l u m п Data

2

!__ ... doo

МуТаЫе

U sere,Rc.le

doo

Graпt

Select

(All+New)

3

dtю

МуТаЫе1

U sersRol e

dbo

Gгапt

S e lect

Name

Оwпег

Obj e ct

1

2

...........

.............

Оwпе,г

1

2

i.......................... Owne,r

1

!. . .

Obj e ct

Obj ect

Gгапtее

Gгапtог

Pre>tectTурс,

дсtiоп

bad-us.e-r

dbo

Gгапt

Сге-аtе Vie-w

bad user

dtю

Gгапt

Cc.l u m п

GON NEGT

Gга пtее,

Gгапtог dbe>

F"rote ctTуре Gгапt

дctie>n

u s_2

dtю

Gгапt

Gr-e-ate Proce-d ure

Gга пt€е

Gra 11tor

Ргоtе ctTуре

Acticn

us_2

u s_3

dbo

Grant

Column

CONNECT

CON NEGT

Col u m n

Рисунок 9.8 - Результаты работы хранимой процедуры sp_helprotect 182

9.2.2 Безопасность уровня строк таблиц В ситуации, когда при проектировании базы данных было принято ре­ шение о централизованном (и единообразном) хранении какой-либо ин­ формации в одной таблице, бывает необходимо разграничить доступ к её отдельным строкам со стороны различных пользователей. Например, клиенты компании видят только свои контракты, студенты - только свои оценки, а врачам должна быть доступна информация только о своих паци­ ентах. Одно из возможных решений - применение технологии RLS (Row Level Security), которая позволяет использовать метаданные о пользовате­ лях базы данных для разграничения их доступа к различным строкам таб­ лицы. Для реализации RLS необходимо создать предикат безопасности, задающий условие доступности строки таблицы, и политику безопасности, связывающую предикат безопасности с целевой таблицей и включающую (или отключающую) режим RLS. Предикат безопасности определяется как встроенная ТVF-функция, вычисляющая значение логического выражения, операндами которого мо­ гут быть входные параметры функции и метаданные пользователя базы данных. Предикат безопасности может использоваться в качестве преди­ ката фильтрации строк (при их выборке) или предиката блокировки строк (при их модификации). После создания соответствующей политики безопасности для целе­ вой таблицы предикат безопасности будет автоматически применяться к каждой строке этой таблицы при каждой попытке доступа. Приведем типовую последовательность этапов подготовки к реализа­ ции RLS (для случая использовании предиката фильтрации). Шаг 1. Определить в базе данных целевую таблицу, доступ к строкам которой требуется разграничить (например, таблицу Сотруд­ ники, в которой столбец Имя_Сотрудника будет использо­ ваться в предикате фильтрации для сравнения с именем поль­ зователя). Шаг 2. Создать в базе данных пользователей (CREATE USER), для которых требуется разграничить доступ к строкам целевой таблицы. Шаг 3. Создать ТVF-функцию (CREATE FUNCTION), в которой дол-

183

жен быть определен предикат фильтрации (логическое выра­ жение, единичное значение которого определит доступные строки целевой таблицы). Шаг 4. Выдать пользователям разрешение G RANT S E LECT на целевую таблицу и ТVF-функцию предиката фильтрации. Шаг 5. Создать политику безопасности (CR EATE S ECU RITY POLI CY), в которой должны быть заданы: - ТVF-функция, используемая в качестве предиката филь­ трации (AD D FI LTER P R E D I CATE), с указанием имени столбца целевой таблицы в качестве входного параметра (например столбца, в котором хранится имя сотрудника); - целевая таблица (ON ); - режим включения политики безопасности (WITH (STATE = O N )).

Сформированная политика безопасности будет автоматически приме­ няться к целевой таблице до тех пор, пока она не будет отключена (ALTER S ECU R ITY POLICY . . . WITH (STATE = O F F)).

Детальное описание, примеры и условия применения RLS приведены в соответствующем разделе технической документации [13]. Пример 9.6 Реализация RLS для разграничения доступа к строкам таб­ лицы успеваемости студентов. В базе данных ведется учет успеваемости студентов по нескольким учебным дисциплинам в соответствии со следующей бизнес-моделью: сту­ дент изучает несколько дисциплин (и несколько студентов изучают одну дисциплину) под руководством нескольких преподавателей (не более од­ ного преподавателя на одну дисциплину, но несколько дисциплин у одного преподавателя), у одного родителя может быть несколько студентов. Оценки студентов по изучаемым ими дисциплинам регистрируются в еди­ ной таблице TЬ I_AI I_G rad es(Cтyдe нт1 Дисци п л и н а 1 О це н ка 1 П ре п ода вател ь1 Родитель_студе нта ) . 8

8

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

В базе данных определены пользователи четырех категорий: мене­ джеры, преподаватели, студенты и родители студентов, при этом имя поль­ зователя (за исключением пользователя « Менеджер » ) совпадает с одним из значений столбцов: Студент1 П репода вател ь или Родител ь_студента . Студент должен иметь доступ только к своим оценкам, родитель - к оцен­ кам только своих детей, преподаватель -к оценкам только по своим дисци­ плинам, а менеджер должен иметь полный доступ ко всем строкам таблицы. Этапы подготовки к реализации RLS (для случая использовании пре­ диката фильтрации). Шаг 1. Целевая таблица - TЬI_AI I_G rades (Студент1 Дисци пл ина 1 Оцен ка 1 П репода вател ь1 Родител ь_студента) в базе данных RLS-test_Stud ies. Таблица заполнена данными в соответствии с описанной выше бизнес-моделью (в качестве примера: восемь студентов (детей четырех родителей) получили различные оценки по восьми дисциплинам у четырех препо­ давателей). Шаг 2. Пользователи (create user WITHOUT LOG I N): - восемь студентов с соответствующими именами Student_eught); (Student_one 1 - четыре преподавателя с соответствующими именами (Teacher_one 1 Teacher _fou r); - четыре родителя с соответствующими именами Parent _fou r); (Pa rent_one 1 - один менеджер с именем M a nager. Шаг 3. Предикат фильтрации (листинг 9.1). ... 1

... 1

... 1

CREATE FU N CТION fn_RLS_Predicate(@ Person_name AS NVARCHAR(З2)) RETU RNS TABLE

WITH SCH E MABI N DI N G AS

RETU RN SELECT 1 AS fn_secu rityPredi cate_resu lt

WHERE @ Person_name = USER_NAM E() O R USER_NAM E()=' Ma nager';

Листинг 9.1 - SQL-кoд для создания предиката фильтрации

185

Функция возвратит единицу, если имя пользователя совпадает со зна­ чением переданного в функцию параметра или если запрос к целевой таб­ лице выполняется от имени пользователя M a nager. В примере использована системная функция USER_NAM E(), возвраща­ ющая имя пользователя (строкового типа), под которым он зарегистриро­ ван в системном каталоге базы данных. Аналогичный результат будет по­ лучен при использовании системных переменных USER 1 CU RRENT_USER и SESSION_USER. Системная функция USER_I D() возвращает идентификатор пользователя. Для проверки работоспособности предиката фильтрации можно использовать SQL-кoд (листинг 9.2). execute as user = ' M a nager' select * from fn_RLS_Pred icate('1234'); revert; (возвращает 1) execute as user = 'Student one' select * from fn_RLS_Pred icate('Student_one'); revert; (возвращает 1) execute as user = 'Student one' select * from fn_RLS_Pred icate('Student_two'); revert; (возвращает N u l l) Листинг 9.2 - SQL-кoд для проверки предиката фильтрации Шаг 4. Разрешения G RANT SELECT на целевую таблицу TЬI_AI I_G rades и ТVF-функцию предиката фильтрации fn_RLS_Pred icate всем 17 пользователям. Шаг 5. Три политики безопасности - по одной для каждой категории пользователей (листинг 9.3). CREATE SECURITY POLICY Students Fi lter ADD F I LTER PREDICATE fn_RLS_Predicate(Cтyдeнт) ON TЬI_AI I_Grades WITH (STATE = O N ); CREATE SECURITY POLICY TeacherFilter ADD F I LTER PREDICATE fn_RLS_Predicate(Пpenoдa вaтeль) ON TЬI_AI I_Grades WITH (STATE = OFF); CREATE SECURITY POLICY Pa rents Fi lter ADD F I LTER PREDICATE fn_RLS_Рrеdiсаtе(Родител ь_студента) ON TЬI_AI I_Grades WITH (STATE = OFF);

Листинг 9.3 - SQL-кoд для создания политики безопасности 1 86

Для проверки работоспособности сформированной политики без­ опасности уровня строк таблицы: 1 Возвращает все строки целевой таблицы execute as user = ' M a nager' select * from TЫ_All_Grades; revert; 2 Возвращает только строки с оценками пользователя Student_one execute as user = 'Student one' select * from TЫ_All_Grades; revert; 3 Возвращает только строки с оценками пользователя Student_five execute as user = 'Student five' select * from TЫ_All_Grades; revert; Выключение политики безопасности уровня строк таблицы: CREATEALTER SECU RITY POLI CY StudentsFi lter WITH (STATE = OFF); Пример 9.7 Разграничение доступа к строкам таблицы успеваемости студентов через хранимое представление без применения технологии RLS. Согласно бизнес-модели, описанной в примере 9.6, создана нормали­ зованная база данных, состоящая из пяти соответственно взаимосвязанных таблиц: Students 1 Pa rents, Techers, Disci p l i nes и G rades. Таблицы заполнены так же, как и в примере 9.6: восемь студентов (детей четырех родителей) получили различные оценки по восьми дисциплинам у четырех преподава­ телей. Создано хранимое представление, формирующее выборку всех оце­ нок, полученных всеми студентами по всем дисциплинам у всех препода­ вателей (листинг 9.4). По аналогии с примером 9.6 в базе данных созданы 17 пользователей (один менеджер, восемь студентов, четыре преподавателя и четыре роди­ теля), каждому из которых выдано разрешение G RANT SELECT на представ­ ление AII G rades. 187

CREATE VI EW AI I -G rades-view AS SELECT S.Student as Студент1 D. Disci pline as Дисци пл ина 1 G .G rade as Оце н ка 1 T.Teacher as П репода вател ь1 P.Parent as [Родител ь Студента] FROM (((Parents Р JOI N Students S ON P . Parentl D=S. Parentl D) JOI N G rades G ON S.Studentl D=G .Studentl D) JOI N Disci pli nes D ON G . Disci p l i nel D=D. Disci p l i nel D) JOI N Teachers Т ON T.Teacherl D=D.Teacherl D;

Листинг 9.4 - SQL-кoд для создания хранимого представления

Возможность разграничения доступа пользователей к строкам храни­ мого представления иллюстрируется листингом 9.5. execute as use r='Student_one'; Select * fro m AII-G rades-view Where Студе нт = USER_NAM E() OR USER_NAM E()='Ma nager'; revert; execute as use r='Teacher_one'; Select * fro m AII-G rades-view Where П репода вател ь = USER_NAM E() OR USER_NAM E()=' M a nage r'; revert; execute as use r=' Parent_one'; Select * fro m AII-G rades-view Where [Родител ь Студента] = USER_NAM E() OR USER_NAM E()='Ma nager'; revert; execute as use r=' M a nager'; Select * fro m AII G rades Where Студе нт = USER_NAM E() OR USER_NAM E()='Ma nager'; revert;

Листинг 9.5 - SQL-кoд для разграничения доступа Приведенный пример вряд ли имеет практическую ценность, так как все пользователи получают право чтения хранимого представления и ничто не мешает любому из них выполнить Select * from AI I_G rades без фильтра­ ции строк. 1 88

Пример 9.8 Разграничение доступа к строкам таблицы успеваемости студентов через хранимую процедуру без применения технологии RLS. В базе данных, рассмотренной в примере 9.7, дополнительно к храни­ мому представлению AI I_G rades_view создана хранимая процедура AI I_G rades_proc (листинг 9.6), в которой организована фильтрация строк, выбираемых из хранимого представления по условию совпадения имени пользователя и имени персоны (студента, его родителя или преподавателя изучаемой студентом дисциплины) со значением соответствующего столбца (за исключением пользователя Ma nager, для которого выборка производится без фильтрации строк). Каждому пользователю выдано разрешение G RANT EXECUTE на вы­ полнение этой процедуры. CREATE PROCE D U R E [d bo] . [AI I_G rades_proc] AS BEG I N declare @ username nvarchar(32) SET @ username = user_name() if @ username ='Ma nager' select * fro m AII -G rades-view else if @ username i n (se lect Студент from AI I_G rades_view) select * fro m AII -G rades-view where Студе нт = @ username else if @ username in (se lect П репода вател ь from AI I_G rades_view) select * fro m AII -G rades-view where П репода вател ь = @ username else if @ username in (se lect [Родител ь Студента] from AI I_G rades_view) select * fro m AII -G rades-view where [Родитель Студента]= @ username END

Листинг 9.6 - SQL-кoд для создания хранимой процедуры с фильтрацией строк хранимого представления

189

Для проверки рассмотренного выше метода фильтрации строк храни­ мого представления через доступ к нему из хранимой процедуры можно использовать SQL-кoд (листинг 9.7). use [RLS-test Studies] -- выборка данных об успеваемости студента "student_one" execute as use r = 'stuent one' ехес AI I_G rades_proc revert; -- выборка данных об успеваемости студентов -- по дисциплинам преподавателя "teacher_four" execute as use r = 'teache fou r' ехес AI I_G rades_proc revert; -- выборка данных об успеваемости студентов -- детей родителя " Parent_two" execute as use r = 'parent_two' ехес AI I_G rades_proc revert; -- выборка данных об успеваемости всех студентов -- по всем дисциплинам execute as use r = 'ma nager' ехес AI I_G rades_proc revert; Листинг 9.7 - SQL-кoд для проверки результатов фильтрации строк с использованием хранимой процедуры 9.2.3 Динамическое маскирование данных Dynamic Data Masking (DDM) позволяет скрыть от непривилегиро­ ванных пользователей реальные значения конфиденциальных данных, но при этом, в отличие от шифрования данных, сами хранимые данные не мо­ дифицируются, а только «маскируются» при выводе. Реальные данные, по­ лученные выборкой из таблицы, представляются пользователю замаскиро­ ванными в соответствии с определенными для этих данных правилами, ко­ торые называются «масками». 190

Столбец таблицы можно замаскировать, если при создании (CREATE) или модификации (ALTE R) схемы таблицы применить к нему функцию, за­ дающую правило маскирования. Всего имеется пять типов масок (SQL Server 2022) и, соответственно, пять функций маскирования (таблица 9.1). Пример 9.9 Использование функций маскирования данных. Таблица 9 .1 - Функции маскирования данных Функция Правило маскирования Примеры исп ользования

defa u lt()

Полное маскирование столбца: CREATE TABLE: • ХХХ ... Х - для строк; ... < имя столбца> va rchar(32) MASKED • число О - для чисел; WITH (FUNCТION = 'defa u lt()') • 1900-0 1-01

00 :00 :00,0000000

для ALTER TABLE:

дата-временных типов; ALTER CO LU M N ADD • цифра «О» (ASCI I ) - для би- MASKED WITH (FU NCTION = 'defa u lt()') парных типов

email()

CREATE TABLE: ... < имя столбца> va rchar(32) MASKED Маскируются ХХХ@ХХХ все WITH (FUNCТION = 'e mail()')

символы адреса кроме первого ALTER TABLE: символа и суффикса .com ALTER CO LU M N ADD MASKED WITH (FU NCTION = 'e mail()')

ra ndom ()

CREATE TABLE: бца> Ь ig int MAS KED WITH числового ... va rchar(32) MASKED WITH (FUNCТION = 'pa rtia l (З,'qwe rty', 2)') ALT ER TA BLE : ALTER CO LU M N name ADD MASKED WITH (FUNCТION = 'pa rtia l (З,'хххх',О)' ) CREATE TABLE: ... Birthday datetime MASKED WITH (FU N С­ TION = 'datetime ("У")') ALTER TABLE: ALTER COLU M N Birthday ADD MASKED WITH (FUNCТION = 'datetime ("М")')

Пример 9. 1 0 Просмотр информации о замаскированных столбцах.

Для просмотра списка замаскированных столбцов таблиц базы дан­ ных с указанием имен соответствующих функций маскирования можно ис­ пользовать системные представления sys. masked_co l u m ns и sys.ta Ыes, как это показано в листинге 9.8. SELECT tЬl.name as ta Ыe_name 1 c.name as col u m n_name 1 c.is_masked 1 с. mas ki ng_f u nctio n FROM sys. masked_col u m ns AS с JOI N sys.taЫes AS tЫ ON c.object_id = tЬl .object_id WHERE is_masked = 1;

Листинг 9.8 - SQL-кoд для просмотра замаскированных столбцов Созданную маску можно удалить, как это показано в листинге 9.9. ALTER TABLE ALTER COLU M N DROP MASKED; Листинг 9.9 - SQL-кoд для удаления маски Пример 9. 1 1 Выдача и отзыв разрешения U N MASK По умолчанию пользователи (или пользовательские роли), имеющие разрешение типа SE LECT на таблицу с маскированными столбцами, при про­ смотре строк таблицы будут видеть в этих столбцах замаскированные дан­ ные. Для того, чтобы пользователь (или роль) мог просматривать замаски­ рованные данные в исходном (немаскированном) виде, он должен получить разрешение типа U N MASK на объект соответствующего уровня (базы дан­ ных, схемы базы данных, таблицы или столбца таблицы), как это показано в листинге 9. 1 0 . G RANT U N MASK ON () ТО ; G RANT U N MASK ON ТО ; G RANT U N MASK ON SCH EMA: : ТО ; G RANT U N MASK ТО ;

Листинг 9. 1 0 - SQL-кoд для выдачи разрешений типа U N MASK 192

Отзыв разрешения типа U N MASK иллюстрируется в листинге 9.11. REVOKE U N MASK ON () FROM ; REVOKE U N MASK ON FROM ; REVOKE U N MASK ON SCH EMA : : FROM ; REVOKE U N MASK FROM ; Листинг 9.11 - SQL-кoд для отзыва разрешений типа U N MASK Детальное описание и ограничения на использование DDM, требуе­ мые разрешения и примеры применения функций маскирования приведены в соответствующем разделе технической документации [13]. 9.2.4 Шифрование данных Шифрование не решает проблем ограничения доступа к данным, но если злоумышленник все же смог преодолеть установленные защитные ограничения и получил несанкционированный доступ к объекту базы дан­ ных, то шифрование исключит (или крайне затруднит) для него возмож­ ность прочтения и последующей интерпретации нелегально полученной конфиденциальной информации, что сделает ее практически бесполезной. При этом для легальных пользователей эта информация будет оставаться и доступной, и интерпретируемой. MS SQL Server поддерживает иерархическую инфраструктуру управ­ ления шифрованием (симметричные и асимметричные ключи различных уровней, сертификаты, подписи, хеширование) и предоставляет соответ­ ствующие функции для реализации шифрования на каждом уровне иерар­ хии. Перечень таких функций приведен в таблице 9.2 [13]. Таблица 9.2 - Функции шифрования данных Симметричное шифрование / дешифрование

-

encryptbykey() decryptbykey() encryptbypassph rase() decryptbypassph rase() - key_id (), key_g u i d () - key_na me() - decryptbykeya utoasymkey() - sym keyproperty() - DecryptByKeyAutoCert()

Асимметричное шифрование / дешифрование

-

encryptbyasym key() decryptbyasym key() encryptbycert() decryptbycert() - asym keyproperty() - asym key_id () Криптографическое хеширование - hashbytes()

193

Копирование сертификатов

- certencoded() - certprivatekey() Управление подписями - sign byasym key() - verifysigned byasym key() - sign bycert() - verifysigned bycert() - is_objectsigned()

Ключи шифрования Корнем иерархии является главный ключ службы (Service Master Кеу, SMK) - симметричный ключ, который создается автоматически при первом запуске MS SQL Server, шифруется средствами ОС и используется для шифрования главного ключа базы данных. Пример 9.12. Создание главного ключа базы данных Главный ключ базы данных (Database Master Кеу, DМК) - симметрич­ ный ключ, хранится в базе данных, в которой он создан, а его копия - в системной базе данных Master. DMK может применяться для защиты за­ крытых ключей, используемых в базе данных. Для создания DMK требу­ ется выполнить SQL-кoд (листинг 9.12) в контексте пользовательской базы данных. CREATE MASTE R КЕУ E NCRYPTI ON ВУ PASSWORD = 'a ny password 1 ;

Листинг 9.12 - SQL-кoд для создания главного ключа базы данных Пример 9.13 Управление ключами шифрования базы данных Ключ шифрования базы данных (Database Encryption Кеу, DEK) ис­ пользуется для прозрачного шифрования (Transparent Data Encryption, TDE) пользовательской базы данных на файловом уровне (называемого также не­ активным шифрованием). TDE шифрует ввод-вывод в реальном времени: каждая файловая страница dаtа-файлов и lоg-файлов базы данных автома­ тически шифруется при записи из буфера ОЗУ в соответствующий файл и автоматически дешифруется при загрузке в буфер ОЗУ из файла. В листинге 9.13 приведена синтаксическая конструкция SQL-кoдa для создания ключа DEK. CREATE DATABASE ENCRYPTI ON КЕУ WITH ALGORITH M = { AES_128 1 AES_192 1 AES_256 } EN CRYPTI ON ВУ SERVER { CERTI FICATE Encryptor_N ame I ASYM M ETRIC КЕУ Encryptor_Name } ;

Листинг 9.13 - Создание ключа прозрачного шифрования базы данных

194

DEK - это симметричный ключ, он создается и хранится в пользова­ тельской базе данных и может быть защищен сертификатом или асиммет­ ричным ключом. Сертификат, используемый для защиты DEK, создается и хранится в системной базе данных MAS TER. Изменение или удаление DEK производятся SQL-командами ALTER DATABASE ENCRYPTION КЕУ или DROP DATABASE ENCRYPTI ON КЕУ. Для управления режимом TDE (включением и выключением TDE, приостановкой проверки шифрования и возобновление проверки) исполь­ зуется следующая SQL-команда: ALTE R DATABASE SET ENCRYPТION { ON I OFF I S U S P E N D I RESU M E } . Для просмотра информации о режиме TDE предназначены системные хранимые представления sys.data bases, sys.certificates и sys.d m_data­ base_encryption_keys. Пример 9.14 Шифрование данных столбцов таблиц В листинге 9.14 приведен SQL-кoд для шифрования столбца таблицы пользовательской базы данных симметричным ключом, защищенным сер­ тификатом, а в листингах 9.15 и 9.16 - SQL-кoд для просмотра зашифро­ ванных данных. CREATE CERTI FICATE Cert_Name WITH S U BJ ECT = 'Sert_owner1 ;

CREATE SYM M ETRI C КЕУ Key_N ame WITH ALGORITH M = AES_256 EN CRYPRION ВУ CERTI FICATE Cert_N ame;

CREATE TABLE Ta Ьle_with_secret_data ( l d I NT I DENTITY PRI MARY REY1 N a me VARCHAR( 128) 1 Secret_data VARCHAR( MAX)); OPEN SYM M ETRIC КЕУ Key_Name DECRYPTI ON ВУ CERTI F I CATE Cert_Na me;

I NSERT I NTO TaЫe_with_secret_data ( l d 1 N a me 1 Secret_data) VALU ES (na me_one 1 E ncryptByRey( Key_G U I D( Key_N a me/ secret_data_one 1 ) ) ) 1 (na me_two 1 EncryptByRey( Key_G U I D( Key_N ame 1 1 secret_data_two 1 ) ) ) 1 (na me_six1 E ncryptByRey( Key_G U I D( Key_N ame 1 1 secret_data_six1 ) ) ) ; CLOSE SYM M ETRI C КЕУ Key_Na me;

Листинг 9.14 - Шифрование столбцов таблицы симметричным ключом 195

SELECT name 1 Secret_data FROM Ta Ыe_with_secret_data; Листинг 9 .15 - Просмотр строк таблицы (информация зашифрованного столбца недоступна) OPEN SYM M ETRI C КЕУ Key_Name DECRYPTI ON ВУ CERTI F I CATE Cert_Na me; SELECT name 1 DecryptByKey(Secret_data) FROM Ta Ыe_with_secret_data; CLOSE SYM M ETRI C КЕУ Key_Na me; Листинг 9 .16 - Просмотр строк таблицы с дешифрованием данных зашифрованного столбца Детальное описание иерархической инфраструктуры шифрования и управления ключами и примеры применения механизмов шифрования при­ ведены в соответствующем разделе технической документации [13]. 9.3 Практические задания Задание 9.1 Дискреционная (логическая) защита данных: а) опишите основные черты и применяемые методы дискреционной защиты информации в реляционных базах данных. Почему такая защита получила название «логической»? б) верно ли утверждение о том, что при дискреционном управлении доступом информация о защите данных хранится отдельно от са­ мих защищаемых данных? Ответ подтвердите экспериментально по результатам анализа структуры хранимыых представлений уровня сервера sys.server_permissions, sys.server_pri ncipals и пред­ ставлений sys.data base_permissions и sys.data base_pri nci pals уровня базы данных. в) позволяет ли дискреционное управление доступом изолировать администратора базы данных от хранимой в ней конфиденциаль­ ной информации? г) как организовано хранение информации о субъектах и объектах доступа в реляционных СУБД? Приведите примеры извлечения такой информации из системного каталога одной из пользователь­ ских баз данных MS SQL Server. 196

д) предложите несколько способов защиты от несанкционирован­ ного чтения/модификации отдельных строк таблицы. Оцените их надежность и предложите способы обхода такой защиты. е) предложите несколько способов защиты от несанкционирован­ ного чтения/модификации отдельных столбцов таблицы. Оцените их надежность и предложите способы обхода такой защиты. Задание 9.2 Мандатная (физическая) защита данных: а) опишите основные черты и применяемые методы мандатной защиты информации. Почему такая защита получила название «физической»? б) верно ли утверждение о том, что при мандатном управлении до­ ступом информация, защищающая данные, хранится отдельно от самих защищаемых данных? в) определите понятие «метка безопасности» и опишите информаци­ онную структуру меток безопасности объекта и субъекта доступа. г) опишите классическую модель мандатного управления доступом (модель Белла - Лападулы): - может ли субъект доступа читать объект, уровень конфиденци­ альности которого выше его собственного уровня? - может ли субъект доступа читать объект, уровень конфиденци­ альности которого ниже его собственного уровня? - может ли субъект доступа модифицировать объект, уровень конфиденциальности которого выше его собственного уровня? - может ли субъект доступа модифицировать объект, уровень конфиденциальности которого ниже его собственного уровня? д) что определяют «уровень ценности» WAL (Write Access Level) и «уровень конфиденциальности» RAL (Read Access Level) объекта доступа? е) в каком отношении находятся WAL- и RАL-уровни объекта и субъекта доступа? Задание 9.3 Управление субъектами и объектами доступа уровня сервера баз данных (MS SQL Server): а) перечислите субъекты и объекты доступа уровня сервера и дайте каждому из них краткую характеристику; б) прямым доступом к системному каталогу определите состав учет­ ных записей и баз данных, управляемых сервером; 197

в) определите состав разрешений доступа, получаемых учетными записями через их членство в следующих серверных ролях: - d bcreator; - d iskad min; - secu ritya d m i n; - sysa d m i n; - puЬlic; г) используя SQL-средства и системные процедуры, создайте не­ сколько учетных записей, поместите их в серверные роли (по сво­ ему усмотрению) и экспериментально подтвердите факт получе­ ния ими соответствующих разрешений доступа; д) допускается ли членство учетной записи одновременно в несколь­ ких серверных ролях? Ответ подтвердите экспериментом; е) допускается ли членство серверной роли в другой серверной роли? Ответ подтвердите экспериментом; ж) получает ли учетная запись через членство в серверной роли раз­ решение включать другие учетные записи в эту роль и/или в какие­ нибудь другие серверные роли? Ответ подтвердите эксперимен­ тально. Задание 9.4 Управление субъектами и объектами доступа уровня базы дан­ ных MS SQL Server: а) перечислите субъекты и объекты доступа уровня базы данных и дайте каждому из них краткую характеристику; б) прямым доступом к системному каталогу базы данных определите состав объектов и субъектов доступа этой базы данных; в) напишите три хранимых представления для выборки из системной таблицы Sysuse rs (или из представления Sys.Sysusers) информации о пользователях, пользовательских и фиксированных ролях базы данных; г) определите состав разрешений доступа, получаемых пользовате­ лями базы данных через их членство в следующих фиксированных ролях базы данных: - d b_data reader; d b_datawrier; - d b_de nydata reader; d b_denydatawriter; - d b_dd lad min; d b_owner; pu Ьlic. 198

Для выполнения последующ их заданий потребуется: - создать базу данных с несколькими таблицами произвольной структуры (не менее двух столбцов) ; - заполнить таблицы произвольными данными; - создать несколько хранимых представлений для чтения данных из соединенных (Join) таблиц; - создать несколько хранимых процедур для чтения/модифика­ ции данных в созданных таблицах; - используя SQL-cpeдcmвa и соответствующие системные про­ цедуры, создать в этой базе данных несколько пользователей и несколько пользовательских ролей; - экспериментально подтвердить правильность своих ответов на поставленные вопросы; д) поместите пользователей в фиксированные роли базы данных (по своему усмотрению). Какие разрешения доступа получены поль­ зователями соответствующих ролей? е) допускается ли членство пользователя одновременно в нескольких фиксированных ролях базы данных? ж) допускается ли членство фиксированной роли в другой фиксиро­ ванной роли базы данных? з) получает ли пользователь через членство в фиксированной роли разрешение включать других пользователей в эту роль? и) допускается ли членство пользователя одновременно в нескольких пользовательских ролях базы данных? к) допускается ли членство пользовательской роли в другой пользо­ вательской роли базы данных? л) допускается ли членство пользовательской роли в фиксированной роли базы данных? м) получает ли пользователь через членство в пользовательской роли разрешение включать других пользователей в эту роль? Задание 9.5 Управление разрешениями доступа к объектам БД. а) перечислите категории разрешений доступа (MS SQL Server) и дайте характеристику каждому из них; б) используя SQL-операторы G ra nt, Deny, Revoke, установите поль­ зователю следующие разрешения доступа: - право/запрет чтения всей таблицы и её отдельных столбцов; 199

-

право/запрет удаления строк таблицы; право/запрет вставки строк таблицы; право/запрет выполнения хранимой процедуры; право/запрет создания/модификации хранимой процедуры/хранимого представления; - отмените ранее установленные разрешения. Задание 9.6 Анализ иерархии разрешений доступа к данным. Эксперимен­ тально подтвердите, опровергните или уточните формулировки следующих гипотез: Гипотеза № 1. Запрет доступа (Deny) к объекту всегда имеет более вы­ сокий приоритет по сравнению с предоставлением (Grant) доступа. Рассмотрите следующие ситуации: а) персональное (явное) и косвенное (через членство в пользователь­ ской роли) предоставление разрешений; б) локальное (явное или косвенное) и глобальное (через членство в фиксированной роли базы данных) предоставление разрешений; в) разрешение, установленное для таблицы в целом, и разрешение, установленное для ее отдельных столбцов. Гипотеза № 2. Использование хранимых представлений позволяет « обойти » установленный запрет доступа к таблицам базы данных. Рассмотрите следующие ситуации: а) пользователю явно установлен запрет (Deny Select) доступа к таб­ лице, но установлено разрешение (G ra nt Select) доступа к пред­ ставлению, в котором присутствует оператор чтения (Select) этой таблицы; б) пользователю явно установлен запрет (Deny Select) доступа к таб­ лице, но установлено разрешение (G ra nt Create) создания пред­ ставления, в котором присутствует оператор чтения (Select) этой таблицы; в) пользователю явно установлен запрет (Deny Select) доступа к таб­ лице, но установлено разрешение (G ra nt Create) создания таблиц и представлений, в том числе - представления, в котором присут­ ствует оператор чтения (Select) этой таблицы и оператор копиро­ вания (l nse rt l nto) данных в другую таблицу. 200

Гипотеза № 3. Использование хранимых процедур позволяет « обойти » установленный запрет доступа к таблицам базы дан­ ных. Рассмотрите следующие ситуации: а) пользователю явно установлен запрет (Deny Select) доступа к таб­ лице, но установлено разрешение (G ra nt Ехес) доступа к хранимой процедуре, в которой присутствует оператор чтения (Select) этой таблицы; б) пользователю явно установлен запрет (Deny Select) доступа к таб­ лице, но установлено разрешение (G ra nt Create) создания храни­ мых процедур (в том числе и таких, в которых присутствует опе­ ратор чтения (Select) этой таблицы); в) пользователю явно установлен запрет (Deny Select) доступа к таб­ лице, но установлено разрешение (G ra nt Create) создания таблиц и хранимых процедур (в том числе и таких, в которых присутствует оператор чтения (Select) этой таблицы и оператор копирования (l nsert l nto) данных в другую таблицу). Задание 9.7 Безопасность уровня строк таблиц (RLS). а) какие задачи защиты данных решаются средствами RLS и в каких ситуациях RLS будет эффективной? б) определите базовые понятия RLS: «предикат безопасности», «пре­ дикат фильтрации», «предикат блокировки» и «политика безопас­ ности»; в) опишите типовую последовательность этапов подготовки к реали­ зации RLS для случая использования предиката фильтрации; г) опишите типовую последовательность этапов подготовки к реали­ зации RLS для случая использования предиката блокировки; д) приведите пример SQL-кoдa для создания предиката безопасности уровня строк таблиц; е) приведите пример SQL-кoдa для создания политики безопасности уровня строк таблиц; ж) приведите пример SQL-кoдa для включения и отключения поли­ тики безопасности уровня строк таблиц; з) реализуйте стандартными средствами RLS разграничение доступа врачей и медицинских сестер к информации о пациентах отделе­ ния лечебного учреждения: заведующий отделением имеет доступ 201

и) к)

л) м)

н)

к информации обо всех пациентах, лечащие врачи и медицинские сестры - к информации только о тех пациентах, которых они лечат (см. пример 9.6); выполните задание 9.7 з) без применения стандартных средств RLS (см. примеры 9.7 и 9.8); реализуйте стандартными средствами RLS разграничение доступа сотрудников компании к информации о клиентах: начальник от­ дела по работе с клиентами имеет доступ к информации обо всех клиентах, менеджеры отдела - к информации только о тех клиен­ тах, которых они обслуживают (см. пример 9.6); выполните задание 9.7 к) без применения стандартных средств RLS (см. примеры 9.7 и 9.8); реализуйте стандартными средствами RLS разграничение доступа руководителей компании к информации о подчиненных им со­ трудниках: директор компании имеет доступ к информации обо всех сотрудниках, начальники отделов - к информации только о тех сотрудниках своих отделов, а сотрудники (в том числе и начальники) - только к своей персональной информации (см. при­ мер 9.6); выполните задание 9.7 м) без применения стандартных средств RLS (см. примеры 9.7 и 9.8).

Задание 9.8 Динамическое маскирование данных (DDM). а) какие задачи защиты данных решаются средствами DDM и в каких ситуациях DDM будет эффективным? б) какие алгоритмы и ключи шифрования применяются в DDM? в) дайте общее определение функции маскирования данных и приве­ дите примеры использования функции defa u lt(); г) дайте общее определение функции маскирования данных и приве­ дите примеры использования функции emai l(); д) дайте общее определение функции маскирования данных и приве­ дите примеры использования функции ra ndom(); е) дайте общее определение функции маскирования данных и приве­ дите примеры использования функции partial(); ж) приведите примеры маскировки и демаскировки столбца таблицы пользовательской базы данных; 202

з) приведите пример просмотра списка замаскированных столбцов таблиц пользовательской базы данных; и) приведите примеры выдачи и отзыва разрешений пользователю базы данных на просмотр замаскированного столбца таблицы; к) приведите примеры выдачи и отзыва разрешений пользователю базы данных на просмотр всех замаскированных столбцов; л) приведите примеры выдачи и отзыва разрешений пользователю базы данных на просмотр всех таблиц базы данных, содержащих замаскированные столбцы; м) приведите примеры выдачи и отзыва разрешений группе пользо­ вателей базы данных на просмотр замаскированного столбца таб­ лицы, на просмотр всех замаскированных столбцов таблицы и на просмотр всех таблиц базы данных, содержащих замаскированные столбцы; н) приведите примеры выдачи и отзыва разрешений группе пользо­ вателей базы данных на просмотр замаскированного столбца таб­ лицы; о) приведите примеры выдачи и отзыва разрешений группе пользо­ вателей базы данных на просмотр всех замаскированных столбцов таблицы; п) приведите примеры выдачи и отзыва разрешений группе пользо­ вателей базы данных на просмотр всех таблиц базы данных, содер­ жащих замаскированные столбцы; р) экспериментально исследуйте приоритетность иерархии разреше­ ний на просмотр замаскированных данных. Задание 9.9 Шифрование данных. а) рассмотрите схему иерархической инфраструктуры управления шифрованием, реализованную в MS SQL Server [13], и опишите состав задач, методов и инструментов, используемых на каждом уровне иерархии; б) дайте определение сертификата (как оно трактуется в MS SQL Server). Для чего используются сертификаты? Приведите примеры их создания и использования средствами SQL; в) дайте определение симметричного и асимметричного шифрова­ ния. Как они используются в инфраструктуре шифрования MS SQL Server? Приведите примеры; 203

г) какие алгоритмы шифрования используются в инфраструктуре шифрования MS SQL Server (2022)? Приведите примеры; д) дайте определение главного ключа базы данных (DMK). Приведите примеры его создания и использования; е) что называют прозрачным (или неактивным) шифрованием (Transparent Data Encryption, TDE)? ж) дайте определение ключа шифрования базы данных (DEK). Приве­ дите примеры его создания, изменения и использования; з) приведите примеры включения и отключения режима TDE в поль­ зовательской базе данных; и) приведите примеры использования элементов системного ката­ лога базы данных для просмотра информации о созданных серти­ фикатах и ключах шифрования; к) приведите пример создания и использования симметричного ключа для шифрования / дешифрования нескольких столбцов таблицы; л) приведите пример создания и использования асимметричного ключа для шифрования / дешифрования нескольких столбцов таблицы.

204

ЧАСТЬ 3. ПОСТРЕЛЯЦИОННЫЕ РЕШЕНИЯ Тема 10. МНОГОМЕРНЫЕ МОДЕЛИ ДАННЫХ Концепция ОLАР-технологий ( On-Line Analytical Processing) предпо­ лагает использование методов оперативного многомерного анализа данных с целью поддержки процедур принятия решений и базируется на пяти ба­ зовых требованиях к ОLАР-системам, получившим название теста FASMI («быстрый анализ разделяемой многомерной информации»). Условия функционирования OLAP- и OLТР-систем существенно от­ личаются. В ОLАР-системах: - относительно небольшое число пользователей (бизнес-аналити­ ков), одновременно работающих с системой; - аналитические запросы предполагают выполнение многомерного анализа данных по нескольким независимым измерениям; - отсутствует фиксированный и заранее определенный набор анали­ тических запросов: пользователи работают с системой в интерактивном ре­ жиме, формулируя очередной запрос для уточнения результатов выполне­ ния предыдущих запросов; - скорость выполнения аналитических запросов важна, но не столь критична, как в OLТР-системах; - загрузка новых данных в ОLАР-систему производится эпизодиче­ ски крупными блоками (например, раз в сутки, неделю или месяц; - загруженные в систему данные не подлежат модификации, что требует контроля их качества и очистки при выполнении процедуры за­ грузки; - загруженные в систему данные не подлежат удалению, что при­ водит к необходимости хранения и оперативной обработки весьма больших объемов данных; - загруженные в систему данные используются в качестве « исто­ рических», что требует их хронологической упорядоченности. В таких условиях классические ER-модели и формируемые на их ос­ нове реляционные модели данных оказались мало пригодными для реали­ зации требований FASMI, что потребовало разработки многомерных моде­ лей данных и создания на их основе специализированных СУБД (или спе­ циализированных компонентов, расширяющих возможности классических СУБД). 205

Многомерные модели данных, обслуживающие ОLАР-системы, должны соответствовать следующим основным требованиям: - агрегируемость данных, позволяющая рассматривать анализируе­ мую информацию с различной степенью детализации на разных уровнях ее обобщения; - статичность данных (неизменность как самих данных, так их вза­ имосвязей), позволяющая использовать денормализованные схемы их хранения и специализированные методы индексации и поиска; - историчность данных, требующая их обязательной привязки ко времени и соответствующей упорядоченности, а также наличия функций прогнозирования, применяемых к различным временным интервалам. 1О.1 Примеры Многомерная модель данных На концептуальном уровне многомерная модель данных может быть представлена многомерным кубом (рисунок 10.1), ребрами которого явля­ ются так называемые измерения (dimensions ), на пересечении которых находятся меры (measures, факты, показатели) - ячейки куба, содержащие агрегированные данные, соответствующие множеству значений измерений.

Факты (.'\Iеры )

Ив1еренпе

Рисунок 10.1 - Концептуальное представление многомерной модели данных

206

Каждое измерение представляет множество значений какого-то од­ ного параметра анализируемого процесса, а мера - это результат выборки и агрегации данных, соответствующий множеству определенных значений всех измерений. Например, для анализа объемов продаж могут потребо­ ваться измерения: «категория товаров», «место продажи», «исполнитель» и «время продажи», а в качестве меры может использоваться «суммарный объем продаж в денежном исчислении». При этом каждое измерение может рассматриваться на разных уров­ нях обобщения: «место продажи» - страна, регион, город; «время продажи» - год, квартал, месяц, день, час; «исполнитель» - филиал, отдел, сотрудник. Рассмотренный выше гиперкуб - это концептуальная модель, логиче­ ская и физическая реализация которой может быть выполнена по-разному. При этом выделяют три слоя: - слой многомерного представления данных, обеспечивающий их многомерную визуализацию; - слой многомерной обработки, представленный языком формули­ рования многомерных запросов и программными средствами их выполнения. - слой многомерного хранения данных, обеспечивающий их физи­ ческую организацию (этот слой представлен далеко не во всех ОLАР-системах, так как данные для их многомерного представле­ ния могут извлекаться из соответствующих реляционных струк­ тур). В ОLАР-системах реализованы четыре стандартных типа операций: формирование среза (Slice, сечение), вращение (Rotation), агрегация (кон­ солидация - Drill Up) и детализация (Drill Down). Slice. Операция сечения формирует подмножество гиперкуба, в кото­ ром значение одного или нескольких измерений фиксировано (рисунок 10.2), тем самым размерность гиперкуба понижается. На рисунке 10.2 а) показано сечение по измерению «дата» - трехмер­ ный гиперкуб превращен в плоскую таблицу, представляющую информа­ цию о всех товарах, проданных всем покупателям за один день (месяц, квартал, ... ).

207

1 овар

/ . 1н 1 а

Пщ;:ушm•.11,

б)

а)

а) фиксировано измерение «дата»; б) фиксированы измерения «дата» и «товар» Рисунок 10.2 - Иллюстрации операции «Сечение» Рисунок 1О .2 б) иллюстрирует сечение исходного гиперкуба с фикса­ цией двух измерений: «дата» и «товар»; полученный линейный список бу­ дет содержать данные о товаре одного типа, проданном всем покупателям за один день (месяц, квартал, ... ). Rotation . Операция вращения (рисунок 10.3) изменяет визуальное представление гиперкуба для более удобного его восприятия. п I ll('Pl'[J lll'

llшt>peн11e 2

1 1.tж•рt•шн.' J

i ! J щ'Гl'IIII('

J

Рисунок 10.3 - Иллюстрации операции «Вращение» 208

2

Drill Up и Drill Down (рисунок 10.4) Операция консолидации (Up) обеспечивает переход «снизу-вверх» по иерархии измерений - от детализированных данных к обобщенным (напри­ мер, по измерению «Дата» - от дней к месяцам и годам), а операция дета­ лизации (Down), наоборот, - переход от агрегированных данных к более детализированным (например, по измерению «Товар» - от категорий това­ ров к подкатегориям и т. д. до наименований товаров). Многомерный гиперкуб может быть представлен в многомерной (MO-LAP), в реляционной (ROLAP) или гибридной (HOLAP) моделях данных. МОLАР-модель реализуется в виде упорядоченных многомерных массивов, что дает ей ряд преимуществ по сравнению с реляционной реа­ лизацией: высокая производительность выполнения аналитических запро­ сов по причине отсутствия нормализации БД и хранения заранее агрегиро­ ванных показателей, а также простота добавления встроенных функций. В то же время МОLАР-модель проигрывает ROLAP по многим дру­ гим показателям: низкая эффективность хранения данных (гиперкуб часто бывает сильно разреженным по объективным причинам - не по всем изме­ рениям присутствуют все необходимые данные), при этом любое измене­ ние структуры гиперкуба почти всегда требует радикальной перестройки модели.

Рисунок 10.4 - Иллюстрации операций «Консолидация» и «Детализация» 209

Использование МОLАР-систем оправдано в условиях, когда объем хранимых данных не превышает нескольких Гбайт и при этом критичным является время отклика системы на аналитические запросы. Многие промышленные сервера баз данных поддерживают МОLАР­ архитектуру данных: Microsoft Analysis Services, Oracle OLAP Option, IBM Informix MetaCube и др. RОLАР-модель хранит данные в реляционной БД, при этом эмуляция гиперкуба производится на уровне СУБД специальными преобразованиями агрегирующими SQL-запросами, выполняемыми в контексте исходной ре­ ляционной базы данных OLТР-системы На рисунке 10.5 приведена схема реляционной базы данных, исполь­ зуемой в ОLТР-системе оперативного учета продаж, а на рисунке 10.6 - ре­ ляционная реализация гиперкуба, периодически формируемого путем агре­ гации результатов оперативного учета и используемого в ОLАР-системе для многомерного (четыре измерения) финансового анализа объемов продаж.

?1

Журнал_ Проt:аж I D_Продаю1 Д ата I D_Покупателя I D_Toвapa Цена Количеств о

1 -

ID_Категор 1н1

00

ID_Города

00 -

\ •.l.,.

ti' ю_группы

Покупатель

)

�------�

Группы_Товаров

Покуп атели

00

_ Г-

.2.1

n

Кате ro р и и_ о куп ател ей

У1 ID_Поf..·уп ателя

l'i' 1D _Категории

-

Категор1-1я_Покупателей

00

----_______ То в а р ь 1

1s

Города

ID_Toв a pa Покупатель Ю_гр','ППЫ

�--�

00

'\f ID_Город Город 1D _Региона

Группа_товаров

Р егионы

Страны

'i5 I D_ Региона Реги о н I D_Страны

'u 1D _ Страны Страна

00

Рисунок 10.5 - Схема реляционной базы данных OLТР-системы 210

Недели ID_Mecaцa \'1 Неделя

J

'

МЕ'СЯЦЫ

t1 ID_Месяца Месяц

1О_Ква ртала

'

-\ .l..

J'

Кварталы

'

t1 ID_Квартала ю_года

,,-

tJ ID_Пш:упателя Покупател ь

1D_Катего р r,�,

1D_Недел и

ID_Го р ода

tl Д ень

Товары \'/ ID_Toвa p a Поf...·упатель ID_Группы

Объемы_Продаж ID_дня ID_По купателя ID_Toвa p a ю_города

Города fl 1D_Го р ода Город 1О_Реги о на

�,.,,..-

Покупатели

'

Дни

'

.

�Г

Регионы ll 1D_ Региона Рег�юн

1D_Стр аны

\'1 Год

Категории_Покупателей

'

�-/

. =/ ' �

/

Годы

- -- --

fl ю_категор,н1 к.атего р ия_пш..·упателей

Группы_Товаров

fl ю_группы

Груп па_то варав

Страны \'/ ID_ Страны Стра на

�/

Рисунок 10.6 - Реляционная реализация гиперкуба (схема «снежинка») 10.2 Практические задания Задание 10.1 Дайте определения OLTP- и ОLАР-систем и сравните их по областям применения и условиям функционирования. Задание 10.2 Перечислите и прокомментируйте пять базовых требова­ ний к ОLАР-системам (тест FASMI). Задание 10.3 Сформулируйте основные требования, предъявляемые к многомерным моделям данных, обслуживающим ОLАР-системы. Задание 10.4 Прокомментируйте назначение и результаты выполнения основных многомерных операций: срез, вращение, консолидация и детализация. Задание 10.5 К какому типу таксономий можно отнести многомерные модели типа «снежинка» (рисунок 10.6)? Задание 10.6 Разработайте реляционную модель гиперкуба для много­ мерного анализа данных некоторой предметной области. Задание 10.7 На основе реляционной модели гиперкуба (задание 10.6) создайте базу данных и разработайте SQL-реализации следующих многомерных операций по нескольким измерениям гиперкуба: - операция консолидации; - операция детализации; - операция вращения; - операция сечения для понижения размерности гиперкуба. 211

Тема 11. NOSQL-MOДEЛИ ДАННЫХ 11.1 Реляционный подход Реляционные базы данных имеют множество преимуществ, благодаря которым они и нашли такое широкое применение в практике хранения и управления данными. Основные достоинства реляционной модели - это строгая структурированность данных, обеспечение их целостности, нагляд­ ность представления информации и технологичность разработки. Классическая архитектура информационной системы включает цен­ трализованную реляционную базу данных, размещенную на вертикально масштабируемом сервере, и множество взаимодействующих с этой базой приложений, обрабатывающих данные в соответствии с определенными бизнес-правилами. При этом база данных рассматривается как «целевая ди­ намическая информационная модель предметной области», и процесс ее проектирования нацелен на реализацию информационных потребностей пользователей информационной системы. В какой-то момент такой подход перестал быть актуальным: разнооб­ разные приложения накапливают огромное количество данных, которые следует сохранить для их последующей обработки в других (не менее раз­ нообразных) приложениях, каждое из которых может предъявлять специ­ фические требования к структурам хранимых данных. В этих условиях строгая структуризация данных, поддерживаемая ре­ ляционной моделью, перестает быть достоинством и превращается в суще­ ственный недостаток, препятствующий использованию реляционных баз данных в некоторых, весьма популярных областях, требующих, в частно­ сти, хранения описаний объектов с разным составом характеристик. Разу­ меется, все это можно реализовать и в реляционной модели данных, но тре­ бование нормализации реляционной схемы при большом объеме данных приведет к резкому падению производительности информационной системы. Следует отметить, как минимум, еще две проблемы, связанные с рас­ пределенным хранением реляционных данных: низкую эффективность го­ ризонтального масштабирования (распределения фрагментов сильно свя­ занных данных на множестве узлов сети) и трудность (а в ряде случаев и невозможность) реализации требований ACID в процессе управления тран­ закциями, что особенно критично для обеспечения требования согласован­ ности данных, размещенных на различных узлах сети. 212

11.2 Подход NOSQL Аббревиатура NoSQL вначале трактовалась как «Не SQL» (по суще­ ству, отказ от реляционных моделей данных), впоследствии пришли к ме­ нее радикальному и более корректному Not Only SQL - «не только SQL». В соответствии с подходом NOSQL: - каждое приложение может работать со своей базой данных; - база данных может быть распределена по узлам кластера, причем количество узлов кластера может быть сколько угодно боль­ шим; - данные, относящиеся к одному объекту предметной области, могут храниться в разных базах данных и в разных форматах. Разработано множество СУБД, имеющих специфические области применения и поддерживающих различные NОSQL-модели данных, основ­ ными из которых являются: - модель типа «ключ-значение»; - документа-ориентированная модель; - столбцовая модель данных; - графовая модель. Первые три модели являются агрегатно-ориентированными: в этих моделях логической единицей хранения данных является агрегат данных объект с множеством атрибутов различных типов, непосредственно ис­ пользуемый приложением, работающим с NOSQL-бaзoй данных. Графовая модель представляет хранимые данные как атрибуты вер­ шин и ребер ориентированного графа и позволяет выполнять запросы, реа­ лизуя алгоритмы поиска путей на графах. 11.3 Примеры Пример 11.1 Система хранения данных в документа-ориентирован­ ной СУБД MongoDB. Хранимые в MongoDB данные представлены набором реплик, распре­ деленных по узлам (называемых «машинами»). Один из узлов объявлен ос­ новным, остальные имеют статус вторичных, которые сохраняют целост­ ность данных и автоматически обновляются синхронно с обновлением ос­ новного узла. Если основной узел по каким-то причинам становится недо­ ступным, статус основного получает один из вторичных.

213

Логическая структура данных База данных MongoDB состоит из коллекций (рисунок 11.1). База да н н ы х Mo пgo D B

/ Коллекци я !

1

1 Колл е к ц и я 2

1

�

Колл е кц ия п

Доку ме нт i, Доку м е н т2, Доку м е н тЗ,

Доку м ен ri , Док у1м ент2, Доку 1мен тJ,

Докумен тi , Доку м е н т2, Доку м е н тЗ,

Доку м е н т п

Доку1 мен т п

Доку мен т п

1

r

Рисунок 11.1 - Структура базы данных MongoDB Коллекция в MongoDB является аналогом реляционной таблицы: каж­ дая коллекция имеет уникальное имя (произвольный текстовый идентифи­ катор длиной не более 128 символов) и включает множество документов, каждый из которых можно рассматривать как объект, в котором хранится некоторая информация. Документ в MongoDB подобен строке реляционной таблицы, в кото­ рой хранится информация об экземпляре сущности, с той разницей, что все строки одной реляционной таблицы должны быть структурно идентич­ ными и моrут включать поля простых скалярных типов, а разные доку­ менты одной коллекции MongoDB моrут иметь разную, причем довольно сложную, структуру. Каждый документ представлен набором атрибутов - пар «ключ - зна­ чение», где ключ атрибута должен иметь строковый тип данных (по суще­ ству, ключ - это имя атрибута), а значения атрибутов моrут иметь один из следующих типов данных: - Binary data - двоичные данные; - Boolean - логические данные (True / False); - Integer / DouЫe - целые / вещественные числа; - String - строки символов (в кодировке UTF-8); - Array - массивы элементов; - Date - дата в формате Unix; - Null - неопределенные значения; - ObjectID - идентификаторы (_id) документов; 214

- Object - объекты сложной структуры; - JavaScript - код на JavaScript; - Regular expression - регулярные выражения (шаблоны для поиска и обработки символьных строк); MinKey/МaxKey - используется для сравнения значений с наибольшим/наименьшим элементом BSON. На рисунке 11.2 приведено два примера типичных документов кол­ лекции Persons (заметим, что документы этой коллекции могут отличаться как составом атрибутов (ключей), так и типами их значений). {

{

name: " Lara" , first nam e: "Croft", occupation: "tom b raider" , age: Null, com pany: {

name: "William" , first name: "Shakespeare" , occupation: [" Poet", "Dramatist"], is al ive: False age: 457

com pany-name: "Square Enix" , уеаг: 1 996, address: {

}

}

}

country: "Japan" , city: "Т okyo" , district: "Shinjuku" , place: " Eastside Square Building"

}

Рисунок 11.2 - Примеры описаний документов В первом примере документ определен четырьмя атрибутами со зна­ чениями строкового, числового, булевого типов и типа массив, во втором примере значение атрибута company имеет тип object, в котором атрибут address также имеет значение типа object. Идентификация документов Для каждого документа коллекции определен уникальный идентифи­ катор, именуемый «_id». При добавлении документа в коллекцию его иден­ тификатор создается автоматически, но у пользователя имеется возмож­ ность явно указать значение этого идентификатора, но тогда пользователь сам должен гарантировать его уникальность. 215

Создаваемый автоматически _id представлен 12-байтовым агрегатом: 1) значение типа timestamp (4 б.) + идентификатор машины (3 б.); 2) идентификатор процесса (2 б.) + счетчик (3 б.). Таким образом, первые 7 байтов идентификатора гарантируют уни­ кальность документа среди всех узлов (машин), на которых могут быть раз­ мещены реплики базы данных, а последние 5 байтов гарантируют уникаль­ ность документа в течение одной секунды для одного процесса. Поиск и выборка документов коллекции может производиться как по идентификаторам документов, так и по значениям их атрибутов. Например, следующим запросом будут выбраны документы, соответствующие ныне живущим персонам: d b . persons .find ({"is alive": True}). К сожалению, ни один из двух наших экземпляров (рисунок 11.2) не попадет в такую вы­ борку, но по разным причинам: W.Shakespeare - потому, что его атрибут is alive имеет значение False, а Lara Croft - потому, что в ее документе отсутствует атрибут is alive, и применение условия поиска к этому доку­ менту вернет «False». Выборка документов по значениям атрибутов приводит к полному сканированию всей коллекции, которая может быть распределена по мно­ жеству узлов базы данных. Для предотвращения полного сканирования коллекция может быть проиндексирована (по одному или нескольким «по­ исковым» атрибутам документов), при этом экземпляры индекса будут со­ зданы на всех узлах базы данных, что ускорит поиск документов, но потре­ бует модификации индексов на всех узлах при модификации документа, хранящегося на одном из них. Пример 11.2 Система хранения данных в СУБД Cassandra. СУБД Cassandra поддерживает столбцовую модель данных, которая, так же, как и документа-ориентированная, является дальнейшим развитием модели «ключ - значение». Объект хранения данных в столбцовой модели - это семейство столбцов (в некотором смысле - аналог коллекции в документа-ориентированной модели и таблицы в реляционной). На языке CQL СУБД Cassandra семейство столбцов именуется табли­ цей (tаЫе), СQL-оператор Create tаЫе синтаксически подобен аналогич­ ному SQL-oпepaтopy, однако не следует путать семейство столбцов столб­ цовых СУБД с физической схемой хранения реляционных таблиц по столб­ цам, как это делается в некоторых реляционных СУБД (например, в РСУБД 216

TeпaData) для уменьшения дублирования хранимых данных и оптимиза­ ции использования памяти. Семейство столбцов - это двухуровневый ассоциативный массив. В следующем примере (листинг 11.1, язык CQL СУБД Cassandra) создается семейство столбцов (таблица staff), используемое для хранения и последу­ ющей выборки данных о штатном составе предприятия. Create Та Ые staff ( department text1 name text1 age i nt1 role text1 pri mary key (department 1 name)

);

Листинг 11.1 - Создание семейства столбцов Как видим, код на языке CQL практически аналогичен соответству­ ющему SQL-кoдy: создается таблица из четырех столбцов, два из которых включены в составной первичный ключ. Однако эта аналогия только син­ таксическая, семантика же совершенно иная. Главное различие - в трак­ товке понятия «первичный ключ». Если в реляционных базах данных pri­ mary key - это ограничение целостности, накладываемое на столбец (или группу столбцов) таблицы и гарантирующее уникальность его значений для всех строк, то в столбцовых базах данных это совсем не так. В семей­ стве столбцов primary key - это всегда составной атрибут, агрегат, включа­ ющий два атрибута: первый называется ключом распределения (partition key), а второй - кластерным ключом (cluster key). В приведенном выше примере department - это ключ распределения, а name - кластерный ключ. Ключ распределения указывает, по какому из атрибутов будет проводиться распределение данных по узлам кластера, а кластерный ключ выполняет роль ключа в ассоциативном массиве второго уровня. Продолжим рассмотрение примера ( фрагмент штатного расписания предприятия) и заполним данными семейство столбцов staff (листинг 11.2). СQL-оператор Select * From Staff вернет 18 строк, аналогично тому, как это было бы в случае с аналогичной реляционной таблицей, однако се­ мейство столбцов Staff содержит не 18 строк (как можно было предполо­ жить), а 6 групп столбцов - по одной группе для каждого значения ключа распределения department (рисунок 11.3). 217

l nse rt i nto staff (department1 name 1 age 1 role) 1 1 1 va l ues ('Дирекция 1 / М едведев /50 Директор l nse rt i nto staff (department1 name 1 age 1 role) va l ues ('Дирекция 1 / Вол ков1 401 /Заместител ь ди ректора 1 l nse rt i nto staff (department1 name 1 age 1 role) va l ues ('Дирекция 1 Л исицына 1 / ЗО1 / Референт1 l nse rt i nto staff (department1 name 1 age 1 role) va l ues ('ОГК 1 / Бы ков1 /бО1 / Гла вный конструктор 1 l nse rt i nto staff (department1 name 1 age 1 role) va l ues ('ОГК 1 / Конев1 /35 1 / И нженер-конструктор 1 l nse rt i nto staff (department1 name 1 age 1 role) va l ues ('ОГТ/Коровин 1 /55 1 / Гла вный технолог); l nse rt i nto staff (department1 name 1 age 1 role) va l ues ('ОГТ / Баранов1 401 / И нжене р-технолог); l nse rt i nto staff (department 1 name 1 age 1 role) va l ues ('ИТ-отдел 1 Пти цы н 1 / 25 1 / Руководител ь1 l nse rt i nto staff (department1 name 1 age 1 role) va l ues ('ИТ-отдел 1 /Син и цы н 1 /201 / П ро граммист1 l nse rt i nto staff (department1 name 1 age 1 role) va l ues ('Цех №1 1 Лосев1 /501 / Начальник1 l nse rt i nto staff (department1 name 1 age 1 role) 1 va l ues ('Цех №11 /За й цев1 401 / М асте р l nse rt i nto staff (department1 name 1 age 1 role) va l ues ('Цех №1 1 / Гусев1 / ЗО1 / Н аладч и к1 l nse rt i nto staff (department1 name 1 age 1 role) 1 va l ues ('Цех №11 /Утки н 1 / бО1 /Фрезеровщик l nse rt i nto staff (department1 name 1 age 1 role) va l ues ('Цех №21 / Козлов1 /501 / Начал ь н и к1 l nse rt i nto staff (department1 name 1 age 1 role) 1 va l ues ('Цех №21 / Ежов1 401 / Мастер l nse rt i nto staff (department1 name 1 age 1 role) 1 va l ues ('Цех №21 Дятлов1 /301 /Тока рь l nse rt i nto staff (department1 name 1 age 1 role) va l ues ('Цех №21 / Кукуш кин 1 /бО1 /Слеса рь1 l nse rt i nto staff (department1 name 1 age 1 role) 1 va l ues ('Цех №21 /Воробье в1 /lб1 /Стажер Листинг 11.2 - Заполнение таблицы staff /

);

/

);

/

);

);

/

);

/

);

/

);

);

/

);

);

);

);

/

);

/

);

);

218

);

Один из столбцов в каждой группе представляет атрибут cluste,� key (п а те ), а остальные столбцы - неключевые атрибуты (age и ro/e). department (partition key) Цех №1 Цех №2 огк огт ИТ-отдел Дир е кция name age role name age role name age role name age role name age role name age role ... ... ...

... ... ...

... ... ...

... ...

... ...

... ...

... ...

... ...

... ...

... ... ...

... ... ...

... ... ...

... ... ... ...

... ... ... ...

... ... ... ...

... ... ... ... ...

Рисунок 11.3 - Значения ключа распределения department

... ... ... ... ...

... ... ... ... ...

Количество строк в каждой группе столбцов может быть различным и зависит от числа экземпляров объектов, ассоциированных с соответству­ ющим значением ключа распределения. В нашем примере в группе «Дирек­ ция» будет три строки, в группах «ОГК», «ОГТ», и «ИТ-отдел» - по две строки, в группе «Цех №1» - четыре, а в группе «Цех №2» - пять строк. Для регистрации факта приема на работу нового сотрудника в суще­ ствующее подразделение предприятия (например, 40-летнего Лебедева в ИТ-отдел на должность системного администратора) следует выполнить СQL-оператор: l nse rt i nto staff (department1 name 1 age 1 role) 1 va l ues ('ИТ-отдел 1 Лебедев1 401 /Сисадм и н В результате в группе столбцов, ассоциированных с соответствую­ щим значением ключа распределения department, количество строк увели­ чится до трех (в нашем случае в группу столбцов «ИТ-отдел» добавится строка «Л ебедев» 1 «40» 1 «Сисадм и н » ). В реализации СУБД Cassandra может распределить семейство столб­ цов по узлам кластера БД так, что строки с одинаковыми значениями ключа распределения окажутся в одном узле, при этом данные будут полностью размещены в оперативной памяти узла. В такой ситуации время отклика на запрос с условием выборки по значению первичного ключа практически не будет зависеть от общего объема хранимых данных. Если в условии выборки запроса содержатся ссылки на неключевые атрибуты, для предотвращения полного сканирования следует дополни­ тельно включать в условие выборки значения распределительно ключа и (рекомендательно) значения кластерного ключа. /

/

219

);

Для рассмотренного (чисто учебного) примера использование столб­ цовой СУБД вряд ли даст какие-то преимущества по сравнению с класси­ ческой реляционной. Скорее, наоборот, реляционная БД здесь будет более эффективной, так как количество сотрудников предприятия вряд ли будет превышать несколько тысяч человек. Но если рассмотреть другую предметную область (например, реги­ страцию измерений сотен параметров, поступающих с нескольких тысяч датчиков со скоростью в тысячи измерений в секунду), то реляционная мо­ дель явно не справится с таким объемом и с такой скоростью сохранения и обработки информации. 11.3 Практические задания Клиентское приложение обрабатывает результаты измерений, посту­ пающих от множества регистрационных устройств (датчиков) за опреде­ ленный интервал времени. От каждого устройства могут поступать показания по нескольким па­ раметрам, причем количество и состав параметров для каждого устройства могут быть различными. Количество устройств может достигать нескольких тысяч, а общее количество сохраняемых наблюдений - нескольких десятков миллионов. Предусмотрены следующие режимы обработки данных: - обработка всех измерений, поступивших от всех устройств; - обработка всех измерений, поступивших от заданного устройства; - обработка одного или группы измерений, поступающих от одного или группы из нескольких устройств. Задание 1 1.1 1 Разработать ЕR-модель и соответствующую схему реляционной базы данных, обеспечивающей выполнение приложением перечис­ ленных выше требований. 2 Подготовить SQL-запросы, обеспечивающие выборку данных для их обработки в каждом из трех режимов. 3 Разработать соответствующую схему столбцовой базы данных (в стиле языка CQL СУБД Cassandra). 4 Подготовить СQL-запросы, обеспечивающие выборку данных для их обработки в каждом из трех режимов.

220

Тема 12. ОБЪЕКТНО-РЕЛЯЦИОННЫЕ ОТОБРАЖЕНИЯ 12.1 Паттерны взаимодействия с реляционными базами данных При проектировании прикладного программного обеспечения разра­ ботчик часто сталкивается с задачей хранения и обработки данных. В плохо спроектированных решениях нередко можно увидеть, что код логики пред­ метной области тесно связан с кодом взаимодействия с системами хранения данных и с кодом представления информации пользователю. В таком слу­ чае даже небольшие изменения, например переход на другую СУБД, могут вызвать шквал изменений во всем коде приложения. Возникла необходи­ мость абстрагировать друг от друга слои домена (модель бизнес-процессов предметной области), представления (например, графический пользова­ тельский интерфейс) и источника данных (средства работы с системами хранения данных). Для проектирования слоя «Источник данных» к настоящему времени предложено несколько подходов (паттернов), в том числе следующие пат­ терны, поддерживающие реляционную модель хранения данных: «Шлюз к данным таблицы», «Шлюз к данным записи», «Активная запись», «Преоб­ разователи данных» [14]. Первые два паттерна используются, когда предметная область описы­ вается в процедурном стиле программирования, и к настоящему времени в сложных проектах практически не применяются, а два других паттерна то­ гда, когда домен моделируется с использованием объектно-ориентирован­ ного подхода. Такой подход называют Object Relation Mapping (ОRМ, объ­ ектно-реляционное отображение), и его реализация дает программистам простой и быстрый способ работы с системами хранения данных, когда, например, предметная область описывается набором связанных классов. При этом часто приходится использовать наследования от классов библио­ теки, реализующей паттерны слоя источника данных. Но в случае, напри­ мер, активной записи мы получаем обширный набор методов, через кото­ рые можно сохранять объекты классов предметной области в базу данных, извлекать их, удалять и модифицировать, строить сложные запросы и т. д. без необходимости задействовать мощный язык SQL-запросов. Трансляция вызова методов, взаимодействия с системами хранения данных полностью ложится на плечи библиотек источника данных. Пример такой работы схематично представлен на рисунке 12.1. Чтобы найти в базе данных информацию о человеке, программист вызывает метод 221

jind (часто статического) класса Pe,�son, передав, например, значение пер­ вичного ключа. В итоге этот вызов транслируется в SQL-зaпpoc, выполня­ ется, а результат возвращается программисту в виде объекта класса Pe,�son. Далее этот объект может быть модифицирован (например, изменена фами­ лия вызовом метода setLastName), после чего вызывается метод update, и изменения закрепляются в базе данных. Клиент

r ..:: чlass>> � : 1 }111\

lle'I/

р : Pe.•soo ◄ · · ·· · · · · · · · · ·· · · · · · · · · · · ···

p :Per,oo

ь

s �tlasl NaГJE·:·и��OBJ

1l _ 1 ____

----0----U

uiJda_ l"1

Рисунок 12.1 - Диаграмма последовательности изменения фамилии человека Такой подход понравился разработчикам за счет простоты использо­ вания, в результате чего практически для каждого современного языка по­ явились реализации паттерна «Активная запись». Важной особенностью выделения механизмов взаимодействия с системами хранения данных в от­ дельный слой является поддержка разных реализаций СУБД при том, что программист работает с общим программным интерфейсом. У паттерна «Активная запись» существует очень серьезный недоста­ ток, нарушающий фундаментальный принцип расслоения системы. Напи­ санные классы одновременно находятся в двух слоях: «Домен» и «Источ­ ник данных», так как они инкапсулируют и логику предметной области, и логику взаимодействия с системами хранения данных. Данный недостаток стремится исправить паттерн «Преобразователь данных», классы которого принадлежат слою «Источник данных» и знают, 222

как преобразовать объекты слоя «Домен» в строки таблицы базы данных и наоборот. Если при использовании активной записи классу соответство­ вала таблица данных, а свойству класса - столбец таблицы, то для паттерна «Преобразователь» один объект класса может соответствовать нескольким записям в разных таблицах данных или наоборот. Классы, реализующие ло­ гику паттерна «Преобразователь», должны понимать, как транслируется реляционная модель хранения данных в объектную и объектная - в реляци­ онную. Пример использования паттерна «Преобразователь» схематично представлен на рисунке 12.2. Для получения информации о человеке можно обратиться к преобра­ зователю PersonMapper, вызвав методjiпd. Далее вызов транслируется пре­ образователем в SQL-кoд с дальнейшим его исполнением на стороне СУБД. Полученный от СУБД кортеж преобразуется в объект класса Person. Затем его состояние меняется (например, изменяется фамилия), и для закрепления изменения в базе данных вызывается метод update преобразователя с пере­ дачей объекта Person. Основное отличие данного паттерна от активной за­ писи - взаимодействие с СУБД вынесено в отдельный класс PersonMapper. Стоит обратить внимание на то, что разработчик, использующий ОRМ, описывает предметную область в виде набора классов с указанием ряда метаданных (зависит от конкретной реализации), а далее происходит автоматическая трансляции их в схему базы данных для выбранной СУБД. Для отслеживания изменений в структуре данных на уровне классов для последующих их применений в схеме БД часто применяются системы ми­ граций. Не стоит думать, что использование ОRМ может привести к тому, что разработчики перестанут использовать язык SQL-запросов. Да, простые, типовые запросы к СУБД можно строить через ОRМ, более сложные ино­ гда лучше описать в виде «сырого» SQL-кoдa или поместить его в храни­ мую процедуру на стороне СУБД.

223

Кп11е1ТТ ------ pm:Pe rso11 Mapper неw

!100(64)

►l

p: Person --