500_Goncharov_S._A._Informatsionnye_tekhnologii_v_mediaindustrii_Upravlenie_dannymi_
.pdfЯзык СУБД и запросы
Общепризнанны две группы вариантов языков запросов. Первая объединяет языки, унаследованные от SQL и представляют собой разновидность OQL (Object Query Language), языка, стандартизованного ODMG. Хотя он существенно отличается от SQL, некоторое подобие явно прослеживается. Некоторые функции принципиально не могут быть реализованы для объектных баз данных только средствами SQL (например, функции модификации структуры данных). Это обусловлено, прежде всего, возможной потерей связи с объектами в прикладных программах. Объектнореляционные СУБД используют различные варианты ограниченных объектных расширений SQL.
Вторая, сравнительно новая (применяется с 1998 года) группа языков запросов базируется на XML. Собирательное название языков этой группы — XML QL (или XQL). Они могут применяться в качестве языков запросов в объектных и объектно-реляционных базах данных. Использование в чисто реляционных базах нецелесообразно, поскольку языком предусматривается объектная структура запроса.
Транзакции в ООСУБД
В соответствии со стандартом ODMG 2.0 транзакции представляют логический блок, гарантирующий атомарность (atomicity), целостность
(consistency), изолированность (isolation) и долговечность (durability).
Короткие транзакции характеризуются малым временем выполнения; они могут существовать только в рамках сеанса работы с ООСУБД. Это наиболее простой вид транзакций, реализованный во всех современных СУБД. Все объекты, подлежащие изменениям, блокируются, а после принятия транзакции разблокируются, изменения же записываются в базу данных.
Длинные транзакции предназначены для увеличения производительности при групповой работе. Реализовано это следующим образом. Например, в Versant можно создавать персональные и групповые базы. Для снижения вычислительной нагрузки на центральный сервер при одновременной работе большого числа пользователей в Versant предлагает пользователям, постоянно работающим с определенными объектами, возможность организации персональной базы данных. Пользователи работают со своей базой, а объекты из нее синхронизируются с групповой базой данных. Пользователь, начав длинную транзакцию, тем самым отмечает объекты, с которыми предстоит работать в групповой базе данных (операция "поставить на контроль" – check out). Эти объекты копируются в его персональную базу, а в групповой базе блокируются, причем блокировать их можно как на запись, так и на чтение. В групповой базе создается объект, содержащий все данные о длинных транзакциях. В случае повреждения групповой базы или физического отключения сервера групповой базы пользователь сможет продолжать работу с объектами в своей персональной базе, а после восстановления групповой базы
131
– синхронизировать объекты. Перед завершением длинной транзакции пользователь должен поместить все измененные объекты обратно в основную базу (операция "зарегистрировать" – check in). После этого объекты копируются в основную базу, а блокировка снимается. В случае аварийного завершения длинной транзакции все изменения будут потеряны.
Вложенные транзакции по принципу функционирования аналогичны коротким. В процессе выполнения одной транзакции формируются другие. Если в текущем сеансе работает один процесс, то создается стек, а если несколько процессов – дерево транзакций.
Блокировки в ООСУБД
Назначение блокировок – гарантировать монопольность использования объекта конкретным пользователем с целью предотвращения одновременного изменения данных. В соответствии с терминологией, принятой в системе Versant, существуют короткие, продолжительные и оптимистические блокировки.
Короткие блокировки (short lock) предназначены для обеспечения последовательного доступа к данных при многопользовательском режиме работы. Они автоматически выполняются во время выполнения коротких транзакций.
Продолжительные блокировки (persistent lock) обеспечивают блокирование объектов на продолжительное время – часы, дни, недели. Применяются совместно с длинными транзакциями. При этом объект может быть заблокирован несколькими способами: с исключением снятия другим процессом (hard lock); с возможностью снятия другим процессом (soft lock); по конкретным операциям.
Ведение версий
В "Манифесте объектно-ориентированных баз данных" поддержка множественных версий объектов отнесена к необязательным характеристикам ООСУБД. Однако большинство современных коммерческих ООСУБД поддерживает версионность; более того, именно она рассматривается многими авторами как отличительная черта ООСУБД (это не совсем так, поскольку и в других СУБД, используя специфические приемы, можно поддержать версионность: но, безусловно, в ООСУБД реализация такого механизма будет гораздо проще).
Важность версионности для ООСУБД обусловлена их историческими корнями: считается, что версионность появилась для решения задач автоматизированного проектирования, выделившись постепенно в самостоятельный класс систем. Для САПР характерна задача сохранения многих версий одного и того же проекта. Впрочем, поддержка версионности может оказаться полезной и для других приложений. Достаточно указать на делопроизводство, где также необходима поддержка многих версий (редакций) документа, при этом высока вероятность появления запросов типа: "Найти
132
редакцию проекта контракта по состоянию на 1.12.2000". Кроме того, версионность способствует повышению надежности информационной системы в целом: пользователи модифицируют не сами объекты, а их версии, а окончательные изменения происходят на сервере лишь после выполнения специальных процедур. Это уменьшает вероятность порчи информации из-за ошибок оператора или вследствие каких-то умышленных действий.
В качестве примера вновь рассмотрим ООСУБД Versant. Для всех объектов возможно сохранение всех версий их изменения. Создается граф происхождения версий, поддерживающий ряд свойств.
1.Доступ к любой ранее сохраненной версии. Благодаря этому свойству возможно извлечение из базы данных, например, случайно удаленных данных.
2.Установка версии по умолчанию. Это свойство объясняет причину возникновения ветвей в графе происхождения версий, так как любая порожденная версия создаст ветвь от установленной текущей, не последней версии.
3.Удаление версии. Вполне логичным является необходимость удаления некоторых версий (например, промежуточных или случайно порожденных) из графа происхождения версий.
Физические хранилища
Один из ключевых моментов функционирования любой СУБД — хранилище данных. Обычно база данных объединяет несколько хранилищ, каждое из которых ассоциируется с одним или несколькими файлами. Хранятся как метаданные (класс, атрибут, определения операций), так и пользовательские данные. Выделяют три типа хранилищ:
1.Системное хранилище (system store) используется для хранения системы классов, создается на этапе установки Jasmine и содержит информацию о семействах классов и пользовательских хранилищ. Возможно определение пользовательских хранилищ для помещения в них описаний пользовательских семейств классов.
2.Пользовательское хранилище (user store) служит для хранения пользовательских объектов, например Persons, Projects или Locations. Пользовательские хранилища могут располагаться внутри системного.
3.Рабочее хранилище (work store) предназначено для поддержки
временной информации в ходе сеанса работы, например результатов поисковых запросов.
Другой пример – организация хранилищ в ООСУБД Versant, все базы данных в которой делятся на групповые и персональные. База данных состоит из нескольких физических разделов:
1.системный раздел (system volume), который создается автоматически при создании базы данных;
2.раздел данных (data volume), который может быть добавлен для увеличения доступного размера базы;
133
3.раздел логического протокола (logical log volume) и раздел физического протокола (physical log volume) предназначены для хранения служебной информации о транзакциях, блокировках для обеспечения возможности отката транзакций и восстановления базы.
Контрольные вопросы к разделу 9
1.Какие три направле6ния в развитии СУБД существуют на сегодняшний момент?
2.Что такое модель данных ООБД?
3.Какие новые типы данных существуют?
Литература
1.Гарсиа-Молина Г. Системы баз данных. Полный курс: пер. с англ. / Г. Гарсиа-Молина, Дж. Ульман, Дж. Уидом. – М.: Вильямс, 2003.– 1088 с.
2.Дейт К. Дж. Введение в системы баз данных: пер. с англ. / К. Дж.
Дейт. – 6-е изд. – М.: Вильямс, 2000. – 848 с.
3.Диго С. М. Базы данных: проектирование и использование: учебник / С. М. Диго. – М.: Финансы и статистика, 2005. – 592 с.
4.Карпова Т. С. Базы данных: модели, разработка, реализация: учебное пособие / Т. С. Карпова. – СПб. : Питер, 2001. – 304 с.
5.Кренке Д. Теория и практика построения баз данных. – 9-е изд. –
СПб.: Питер, 2005. – 859 с.
6.Марков А. С. Базы данных. Введение в теорию и методологию: учебник / А. С. Марков, К. Ю. Лисовский. – М.: Финансы и статистика, 2004. – 512 с.
7.Мещеряков Е. В. Публикация баз данных в Интернете / Е. В. Мещеряков, А. Д. Хомоненко. – СПб. : БХВ-Петербург, 2001. – 560 с.
8.Общеотраслевые руководящие материалы по созданию банков данных.
– М.: ГКНТ, 1982. – 158 с.
9.Олле Т. Предложения КОДАСИЛ по управлению базами данных: пер. с англ. / Т. Олле. – М.: Финансы и статистика, 1981. – 286 с.
10.Риккарди Г. Системы баз данных. Теория и практика использования в Internet и среде Java: пер. с англ. / Г. Риккарди. – М.: Вильямс, 2001. – 480 с.
11.Роб П., Коронел К. Системы баз данных: проектирование, реализация и управление : пер. с англ. / К. Коронел, П. Роб. – 5-е изд., перераб. и доп. – СПб. : БХВ-Петербург, 2004. – 1040 с.
12. Ролланд Ф. Д. Основные концепции баз данных: пер. с англ. / Ф. Д. Ролланд. – М.: Вильямс, 2002. – 256 с.
13.Толковый словарь по вычислительным системам / под ред. В. Иллингоурта и др.: пер с англ. – М.: Машиностроение, 1990. – 560 с.
134
14. Харрингтон Д. Разработка баз данных : пер. с англ. / Д. Харрингтон. – М.: ДМК Пресс, 2005. – 272 с.
15. Хомоненко А. Д. Базы данных: учебник / А. Д. Хомоненко, В. М. Цыганков, М. Г. Мальцев. – СПб. : КОРОНА принт, 2002.–672 с.
16.Доктрина информационной безопасности Российской федерации утв. 9 сентября 2000 г.
17.ГОСТ-Р ИСО/МЭК 27001-2006 Информационная технология, методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности.
18.СТО ВР ИББС -1.0-2008 Стандарт Банка России. Обеспечение информационной безопасности организации банковской системы Российской Федерации.
19.ISO 27001.
20.Базовая модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных. Утв. ФСТЭК 14 февраля 2008 г.
21.Требования к защите персональных данных при их обработке в информационных системах персональных данных. Утв. Постановлением Правительства РФ от 01 ноября 2012 года № 1119.
22.Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных. Утв. приказом ФСТЭК России от 18 февраля 2013 года № 21.
23.Методика определения актуальных угроз безопасности персональных данных при их обработке в информационных системах персональных данных. Утв. ФСТЭК 14 февраля 2008 г.
135
Учебное издание
Гончаров Сергей Анатольевич
Информационные технологии в медиаиндустрии:
«УПРАВЛЕНИЕ ДАННЫМИ»
Учебное пособие
Редактор Забелин Л.Ю. Корректор Гончарова И.Л.
Подписано в печать 04.08.2014 г., формат бумаги 60х84/16, отпечатано на ризографе, шрифт №10,
изд. л. 8,5, заказ № 98, тираж 80 экз., СибГУТИ, 630102, Новосибирск, ул. Кирова, 86.