Oak Ridge National Laboratory

Михаил Красовский

Oak Ridge National Laboratory

Carbon Dioxide Information Analysis Center

Управление данными (Data management)

Что происходит с данными?

• Amazon.com: в июле 1995 in Bellevue, Washington два сервера. Сегодня около 50 миллионов покупателей в месяц в США; 24 региональных центра - в северной Америке (10), Европе (10) и Азии (4)
• Wal-Mart: в 1962 году первый магазин в штате Арканзас, в 1968 первые магазины в других штатах. В 2005, Wal-Mart продает на $312.4 миллиардов, имеет около 6,200 магазинов по всему миру, 1.6 миллионов работников, крупнейший частный работодатель в мире.
• KamLAND: The Kamioka Liquid Scintillator Antineutrino Detector (Taoyama, Japan) - детектор частиц; начал работать в январе 2002, в настоящее время поставляет около 200GB информации в день.
• LHC: The Large Hadron Collider (Geneva, CERN), будет запущен в этом году, ожидается поток в 15 петабайт (15 миллионов гигабайт) данных в год, около 41 террабайта в день

Управление данными (Data management)

Определения

• Data Resource Management is the development and execution of architectures, policies, practices and procedures that properly manage the full data lifecycle needs of an enterprise (DAMA - The Data Management Association International)
• Управление данными – набор процессов, обеспечивающих накопление, организацию, запоминание, обновление, хранение, обработку данных и поиск информации.

Функции управления данными

• Руководство данными (Data Governance)
• Архитектура, анализ и дизайн данных (Data Architecture, Analysis & Design)
• Управление базами данных (Database Management)
• Безопасность данных (Data Security Management)
• Контроль качества данных (Data Quality Management)
• Управление мастер- и референц- данными (Reference and Master Data Management)
• Хранение и анализ данных (Data Warehousing & Business Intelligence)
• Управление данными вне БД (Document, Record & Content Management)
• Уравление метаданными (Metadata management)

Руководство данными (Data Governance)

• Определение и распределение обязанностей (Roles & Organizations)

Кто заказчики? Кто и за что отвечает внутри команды?

• Определение стандартов (Policies, Standards & Compliance)

Выходные данные должены соответствовать вновь разработанному стандарту или внешнему заданному стандарту (метры, футы, доллары, рубли, мм ртутного столба, kPa)

• Методика работы с данными (Data Strategy)

Все источники поставляют информацию в разных форматах. Как их привести к одному?

• Построение архитектуры данных (Architecture)

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

• Оценка активов данных (Data Assets Valuation)

Какие-то агрегатные и средние могут уже быть

• Обмен информацией (Communications & Issue Management)

Необходимое количество каналов коммуникации: (N * (N - 1)) / 2. Для команды из 4 =6, для команды из 7 =21

Архитектура, анализ и дизайн данных (Data Architecture, Analysis & Design)

• Построение концептуальной модели данных (Enterprise Data Modeling and Related Data Architecture)

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

• Построение логической модели (Logical Modeling and Value Chain Analysis)

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

• Физическое моделирование (Physical Modeling)

На каких серверах, на какой БД, языки програмирования, инструменты аналитики

• Стандартизирование модели (Modeling Standards)
• Управление моделью (Model Management)

Управление базами данных (Database Management)

• Дизайн баз(ы) данных (DB Design)
• Внедрение БД (DB Implementation)
• Резервное копирование и восстановление (Backup & Recovery)
• Производительность и настройка (Performance & Recovery)
• Архивация и удаление (Archival & Purging)
• Управление технологией (Technology Management)

 

Контроль качества данных (Data Quality Management)

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

• Обработка бумажной докумантации (Physical Record & File Management)
• Идентификация
• Хранение
• Оборот (циркуляция)
• Архивация

Введение

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

Встроенные файловые системы

Относительно возможности встраивания функций файловой системы в СУБД много говорилось еще до выхода Microsoft SQL Server 2005. Однако реальный шаг в этом направлении был сделан компанией Oracle в выпуске 11g. В этой СУБД появился новый тип данных SecureFiles [15], позволяющий создавать LOB-объекты, с которыми можно работать в файловом интерфейсе с сохранением всех прочих возможностей СУБД, в частности, журнализации и восстановления после сбоев. Oracle утверждает, что эта встроенная в базу данных файловая система исключительно эффективна, и призывает активно ей пользоваться для хранения обычных файлов. В SQL Server 2008 Microsoft делает ответный ход, объявляя о поддержке типа данных FILESTREAM [16]. В решении Microsoft пользователи получают возможность доступа средствами SQL Server к файлам, хранящимся в файловой системе NTFS (при этом сохраняется ограниченная возможность доступа к тем же файлам на основе интерфейса Win32). Доступ к объектам типа FILESTREAM из SQL Server производится в транзакционном режиме с поддержкой журнализации и восстановления. По-видимому, организация файловых систем, интегрированных с базами данных, – это только первый шаг на пути к созданию единой информационной среды с общими средствами поддержки целостности данных и их поиска.

Заключение раздела

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

Поддержка реального времени

Многие заказчики компании Релэкс используют в своей работе операционные системы реального времени. СУБД Линтер изначально проектировалась так, чтобы удовлетворять ограничениям, которые накладывает функционирование в таких операционных системах [25]. Архитектура Линтер достаточно гибка для переноса в разные программно-аппаратные среды. В настоящее время СУБД Линтер функционирует как на платформах Windows CE и Linux, так и в средах различных операционных систем реального времени (QNX 4, QNX6, VxWorks, ОС РВ, OS/9, OS9000) на разнообразных аппаратных платформах (x86, PPC, Sparc, ARM, MIPS и т.д.). При этом обеспечивается полная совместимость по протоколам взаимодействия между узлами под управлением разных операционных систем, что позволяет использовать

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

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

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

MySQL

Особенностью СУБД MySQL является то, что, будучи системой с открытыми исходными текстами, она разрабатывалась коммерческой компанией MySQL AB (в числе сотрудников этой компании немало специалистов из России и Украины). Более того, в действительности компания распространяла свою систему в двух вариантах: бесплатном и корпоративном, под разработанной в самой MySQL AB коммерческой лицензии. До августа 2007 г. исходные коды обоих вариантов находились в свободном доступе, но затем доступ к текстам программ коммерческой версии был закрыт для всех, кроме корпоративных клиентов, оплативших лицензию. В начале 2008 г. компания MySQL AB была приобретена компанией Sun Microsystems. Sum Microsystems официально утверждает, что «новая СУБД MySQL корпорации Sun Microsystems является ключевым компонентом популярных программных комплексов для создания приложений Web 2.0». [29]. Однако к середине 2008 г. не видно серьезного воздействия перехода MySQL в собственность Sun Microsystems на дальнейшую разработку MySQL. Пока все работы по развитию MySQL идут по ранее намеченному плану. Текущим выпуском системы является MySQL Enterprise Server 5.1 [30]. По сравнению с предыдущей версией 5.0, вышедшей в октябре 2005 г., в MySQL 5.1 появился ряд новых возможностей, которые компания MySQL AB относит к областям хранилищ данных и интеллектуального анализа данных; средств обеспечения высокой доступности данных; упрощенного управления и средств обеспечения высокой производительности.

В области хранилищ данных и интеллектуального анализа данных основным нововведением является средство горизонтального разделения таблиц и индексов (по диапазону значений, с хэшированием и т.д.). Разделение таблиц возможно для всех подсистем хранения данных, используемых в MySQL: MyISAM, Archive, InnoDB и т.д. Кроме того, к этой области относится новый подключаемый модуль, поддерживающий

полнотекстовый поиск, и поддержка XPath для работы с XML-данными с возможностью выбора и модификации узлов XML-документов на стороне сервера баз данных. Для повышения уровня доступности данных наряду с механизмом репликации на основе операторов SQL, существовавшим в MySQL 5.0, в MySQL 5.1 обеспечивается средство репликации таблиц на уровне строк. В MySQL Cluster появилась поддержка данных, сохраняемых в дисковой памяти, и также обеспечивается возможность асинхронной репликации данных из одного кластера в другой. Для облегчения управления системами баз данных в MySQL 5.1 появился планировщик событий, позволяющий администраторам базы данных создавать и запускать запланированным образом задания, выполняющие различные функции на сервере баз данных. Достижению более высокой производительности содействует новое средство параллельной загрузки базы данных, а также утилита стрессового тестирования, которая моделирует поведение заданного числа пользователей, задающих запросы разного вида. После завершения работы этой утилиты формируется отчет, содержащий статистические данные о работе сервера. На конец 2008 г. планируется выпуск MySQL 6.0, в котором будет внедрена новая подсистема управления данными Falcom, обеспечивающая полную поддержку транзакций со свойствами ACID. Эта подсистема не предназначена для замены транзакционной подсистемы управления данными InnoDB, но, по мнению разработчиков, в ряде случаев будет работать более эффективно. Кроме того, в MySQL 6.0 должны обеспечиваться поддержка неблокирующих вариантов операций, изменяющих схему таблиц, а также ожидается ряд нововведений в оптимизаторе запросов SQL.

PostgreSQL

Под названием PostgreSQL система существует с 1996 года. Это название отражает связь PostgreSQL с оригинальным проектом Postgres и внедрением в систему поддержки языка SQL [31]. Управление проектом осуществляет небольшая группа инициативных пользователей и разработчиков, называемая PGDG (PostgreSQL Global

Development Group). В число основных разработчиков PostgreSQL входит ряд российских специалистов. В начале февраля 2008 г. была выпущена СУБД PostgreSQL 8.3 [32], в работе над которой принимали участие десятки разработчиков из 18 стран. В течение 15 месяцев разработки и тестирования были обработаны и успешно внедрены более 280 пакетов изменений исходного кода. Основные изменения и новшества разработчики разбивают на три части: средства, способствующие улучшению производительности; новые возможности для программистов приложений баз данных; нововведения, предназначенные для администраторов баз данных. Основными новыми средствами, способствующими повышению производительности СУБД PostgreSQL 8.3, являются механизм асинхронной фиксации транзакций и синхронизованные просмотры таблиц. При асинхронной фиксации не происходит немедленного выталкивания во внешнюю память записи о фиксации транзакции. Тем самым, существенное повышение производительности сопровождается риском потери результатов последних по времени транзакций при крахе системы. Синхронизированный просмотр таблицы позволяет избежать нескольких просмотров одной таблицы при одновременном выполнении нескольких однотипных запросов. Наиболее существенным изменением PostgreSQL, затрагивающим интересы разработчиков приложений, является миграция модуля полнотекстового поиска tsearch2 в ядро системы. Другое заметное изменение — поддержка XML. Появился специальный тип данных xml, встроенный в ядро. В соответствии со стандартом SQL:2003 реализован набор функций для преобразования реляционных данных в XML (т. н., функции публикации SQL/XML). Для ускорения выполнения запроса к XML-данным возможно использование функциональных индексов и GIN-индексов, а также использования полнотекстового поиска для XML-данных. Соответствующие программные средства были разработаны российскими программистами.

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

можно переопределять переменные окружения, которые будут действовать только в рамках выполнения данной функции (привязка к функциям значений переменных). В настоящее время уточняется состав новых функциональных возможностей, которые должны войти в следующую версию PostgreSQL 8.4. Работа над этой версией уже активно ведется, и завершение планируется в начале 2009 г. Продукты на основе исходных текстов PostgreSQL производит не только сообщество PostgreSQL под управлением PGDG, но и коммерческие компании, наиболее известной среди которых является EnterpriseDB Corporation [33]. Эта компания выпускает свободно доступный продукт Postgres Plus и совместимую с Oracle коммерческую систему Postgres Plus Advanced Server. Наиболее интересным и совершенно новым для мира PostgresSQL является интегрированный с Postgres Plus продукт GridSQL, в котором реализуется архитектура распределенных баз данных без общих ресурсов между узлами.

Firebird

Как говорится на официальном сайте проекта [28], «Firebird – это коммерчески независимый проект программистов сообщества C/C++, технических консультантов и спонсоров, разрабатывающих и совершенствующих мультиплатформенную реляционную СУБД, основанную на исходных кодах, которые были переданы в свободное использование 25 июля 2000 г. компанией Inprise Corp. (называемой теперь Borland Software Corp)». Речь здесь идет про исходные тексты СУБД InterBase 6.0. Коммерческую линию развития этой системы продолжает Borland. В апреле 2008 г. после двухлетней работы команды разработчиков, значительную часть которой составляют российские специалисты, была выпущена версия Firebird 2.1 [34]. В этой версии улучшены средства администрирования баз данных, повышена производительность системы и введена поддержка ряда новых средств языка SQL. Упростить администрирование позволяют новые виртуальные таблицы мониторинга, на основе которых администраторы могут увидеть статистическую информацию о сервере в целом, а рядовые пользователи – только те данные, которые соответствуют их соединению. Введена возможность аутентификации пользователей средствами Windows.

На уровне SQL появилась возможность определения триггеров, условием срабатывания которых являются подключение к базе данных, начало, фиксация и откат транзакции и т.д. Появилась возможность использования глобальных временных таблиц и общих табличных выражений, которые, в частности, можно использовать для формулировки рекурсивных запросов. Введена конструкция UPDATE OR INSERT, срабатывающая как UPDATE, если условию оператора соответствует хотя бы одна строка целевой таблицы, и как INSERT в противном случае. Наконец, поддерживается оператор MERGE, позволяющий слить две таблицы. Следует заметить, что не все введенные средства SQL присутствуют в стандарте языка. Наконец, основным средством повышения производительности является новый сетевой протокол, в котором, в частности, некоторые виды пакетов группируются и посылаются в сеть вместе. Ожидаемый в конце этого года выпуск Firebird 2.5 разработчики рассматривают как важный шаг на пути к СУБД Firebird 3.0, которая будет представлять собой параллельный масштабируемый сервер с универсальной архитектурой, ориентированной на симметричные мультипроцессоры.

История ООСУБД

Область ООСУБД возникла на основе ранее существовавшей области языков программирования баз данных. В этой области было выполнено множество исследований, и был разработан ряд интересных экспериментальных систем, включающих Атлант [35], DBPL [36] и PS-algol [37]. В 1990-е гг. консорциум ODMG разработал несколько стандартов объектно-ориентированной модели данных, последним среди которых был опубликован стандарт ODMG 3.0 [38]. В конце 1980-х – начале 1990-х гг. было создано несколько интересных ООСУБД, к которым относятся GemStone, Objectivity, Versant, Object Store и т.д. [1]. Коротко обсудим основные архитектурные особенности этих систем.

ООСУБД GemStone

ООСУБД GemStone была одной из первых коммерчески доступных ООСУБД. Система была разработана компанией Servio-Logic совместно с OGI. В исходном варианте системы разработчики GemStone опирались на язык Smalltalk. Хотя в первых выпусках системы ее основной язык назывался Opal, было видно, что в действительности это Smalltalk с поддержкой стабильного хранения объектов, и вскоре название языка было заменено на GemStone Smalltalk. Впоследствии в GemStone была обеспечена поддержка языков C и C++, но во все времена базовым языком оставался Smalltalk, а все остальные интерфейсы строились поверх базового интерфейса. И серверная, и клиентская части системы могут работать под управлением всех основных ветвей ОС UNIX и всех развитых вариантов Windows. В настоящее время продукт поддерживается, развивается и распространяется компанией GemStone Systems Inc. [39].

Система основана на трехзвенной архитектуре клиент-сервер, в которой прикладная обработка данных производится на среднем уровне между процессом взаимодействия с пользователем и процессом, поддерживающим хранилище данных. Важность этого подхода состоит в том, что если в приложении используется много данных, то код приложения целесообразно расположить на стороне хранилища данных, а если в приложении производится много изменений над небольшим объемом данных, то имеет смысл разместить код приложения на стороне пользователя. Тем самым, архитектура позволяет уменьшить объем сетевого трафика без перегрузки сервера, что повышает скорость обработки данных. Архитектура поддерживается рядом системных взаимодействующих процессов, среди которых доминирующими являются процессы Stone и Gem. Процесс Stone координирует доступ к хранилищу объектов, состоящему из нескольких областей внешней памяти, которые могут представлять собой файлы или разделы дисков, а также могут быть разнесены по нескольким машинам. Процесс Stone синхронизирует другие процессы и обеспечивает согласованность данных при фиксации транзакций. Кроме того, процесс отвечает за распределение идентификаторов объектов, объектных страниц и объектных блокировок. Объекты делаются стабильными (т.е. сохраняются в базе данных) путем использования своего рода стабильного корня, называемого коннектором. Все объекты, прямо или косвенно достижимые по объектным ссылкам от коннектора, являются стабильными. В GemStone для каждого класса, в котором существует хотя бы один стабильный объект, поддерживается эквивалентная серверная версия класса. Другими словами, один вариант класса служит классом в контексте программирования, а другой – в контексте базы данных. Такие пары поддерживаются автоматически: если создается класс в смысле Smalltalk, и некоторый объект этого класса становится стабильным, то автоматически создается серверный класс этого объекта (класс в смысле GemStone). Создание коннектора приводит к появлению экземпляра класса GemStone, эквивалентного классу объекта, который должен быть сделан стабильным. Аналогично, любой объект, достижимый от коннектора, автоматически становится стабильным.

ООСУБД Objectivity/DB

Компания Objectivity Ошибка! Закладка не определена.Ошибка! Закладка не определена. [40] была образована в 1988 г. В 1990 г. была выпущена первая версия системы, которая представляла собой распределенную СУБД, основанную на использовании объектной технологии, высокопропускных локальных сетей и симметричных мультипроцессоров. Система работает на всех основных UNIX-платформах и в среде Windows. Система основана на клиент-серверной архитектуре, в которой единицей обмена между сервером и клиентом является блок базы данных. Тем самым, многие системные функции, включая кэширование, поиск объектов и преобразование их форматов, выполняются на стороне клиента. Объектные идентификаторы представляются в 64-разрядном формате, что обеспечивает потенциальную возможность работы со сверхбольшими базами данных. Поддерживается четырехуровневая структура хранения данных. Объекты содержатся в контейнерах, каждый из которых представляет собой часть локальной базы данных. Локальные же базы данных могут комбинироваться в федеративную (распределенную) базу данных. Надежность хранения данных поддерживается механизмом репликации. В системе поддерживаются языки C++ и Smalltalk, но способы использования языков сильно различаются. Это относится и к механизмам стабильности, и к средствам определения данных. В среде C++ стабильными являются объекты всех классов, являющихся наследниками специального системного класса. В среде Smalltalk стабильными являются все объекты, достижимые от именованных корневых объектов-словарей. Соответственно, в Smalltalk для удаления объектов используется механизм сборки мусора, а в C++ – явные операции.

ООСУБД Versant

С 1988 г. компания Versant [41] предлагает решения, основанные на хорошо масштабируемой объектно-ориентированной архитектуре и проприетарном алгоритме кэширования. ООСУБД Versant является одной из немногих объектно-ориентированных систем, допускающих масштабирование уровня любого предприятия. Решения на базе

Versant применяются в телекоммуникациях, обороне, на транспорте и т.д. Система работает как на основных UNIX-платформах, так и в среде Windows. Архитектура Versant в большей степени ориентирована на логическое управления данными, т.е. объектами, а не на физическое представление данных в виде, например, страниц. Управление размещением объекта осуществляется системой способом, полностью прозрачным для пользователей. Для поддержки локальных хранилищ объектов используется кэширование. Система обладает свойством отказоустойчивости. Для этого допускается синхронная репликация базы данных на двух серверах, которые могут находиться в одной локальной сети или разнесены в разные точки глобальной сети. В одной базе данных Versant может храниться около трехсот триллионов объектов, размер каждого из которых неограничен. Для архивации данных может использоваться ленточная внешняя память с автоматическим оповещением оператора в случае потребности извлечения объектов из архива. Поддерживаются кластеры совместно используемых объектов, причем встроенные объекты хранятся внутри своих объектов-предков, что способствует уменьшению уровня фрагментации памяти. Кластеризация применяется и при внешнем кэшировании. Кроме того, в системе Versant поддерживается возможность использования персональных баз данных, установленных на мобильных компьютерах. Они могут быть отсоединены от сервера центральной базы данных, использоваться автономно и фиксировать свои изменения в центральной базе данных после восстановления соединения. Для представления связей между объектами базы данных используется единый стабильный указательный тип. В системе поддерживаются скрытые от пользователей преобразования указателей базы данных в обычные указатели C++ и наоборот. Поэтому объекты создаются и ликвидируются с помощью стандартных конструкторов и деструкторов классов.

Для программирования можно использовать языки C++ и Smalltalk, причем безо всяких расширений. Поддерживаются возможности, специфичные для работы с базами данных. Например, имеется средство автоматической генерации схемы базы данных прямо по файлам заголовков C++. Это позволяет обойтись без использования

специализированных препроцессоров или компиляторов. Специальные системные классы позволяют работать со всеми разновидностями типов коллекций, специфицированными в стандарте ODMG. Любой объект, созданный в среде C++, доступен в среде Smalltalk и наоборот.

ООСУБД ObjectStore

Компания Object Design была основана в 1988 г. с целью ускоренной разработки и вывода на рынок ООСУБД, которую стали называть ObjectStore. В конце 90-х у Object Design установились тесные партнерские отношения с IBM, что позволило привлечь к созданию ObjectStore тысячи разработчиков приложений. На основе технологии ObjectStore компанией был разработана одна из первых коммерческих СУБД – Excelon, ориентированная на управление XML-данными. С начала 2003 г. компания является подразделением компании Progress Software [42]. ООСУБД ObjectStore основана на архитектуре клиент-сервер, в которой каждый сервер отвечает за регулирование доступа к хранилищу объектов и управляет журнализацией обновлений, блокировками, установкой контрольных точек, разрешением конфликтов по данным, резервированием данных и восстановлением базы данных после сбоев. Каждый сервер поддерживает множество клиентов. В клиентском процессе используется представление данных более высокого уровня, и клиентская часть ObjectStore отвечает за управление коллекциями, выполнение запросов и управление транзакциями. Серверная часть спроектирована в расчете на использование механизма отображения виртуальной памяти, которая распространяется на всю сеть и может охватывать несколько серверов. Извлекаемые из базы данных объекты могут объединяться в пакеты для передачи по сети, что позволяет снизить объем сетевого трафика. Для сокращения времени доступа в серверах используется техника кластеризации. На каждой клиентской части имеется локальный кэш, в котором сохраняются используемые объекты. Когда объект перемещается в адресное пространство клиента, ссылки на него перерабатываются таким образом, что для каждого доступа к объекту достаточно выполнить одну команду компьютера.

В ObjectStore стабильность хранения объектов поддерживается за счет наличия именованных корневых стабильных объектов класса база данных. База данных создается с помощью вызова метода new этого класса. Имеются методы для открытия и закрытия базы данных. Кроме того, в классе содержатся методы для создания стабильных корневых объектов, обычно являющихся коллекциями, в которых размещаются стабильные объекты.

Требования реального времени

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

Проблемы XML-СУБД

Для успешного применения систем управления XML-данными требуется решить ряд проблем. Из-за потенциальной сложности структуры и различий в потребностях разных приложений в разных ситуациях требуются разные методы хранения и индексации баз XML-данных. Нужно понять, в каких ситуациях, и каким образом необходимо оптимизировать запросы к базам XML-данных. В частности, до сих пор непонятно, нужны ли XML-СУБД «стоимостные» оптимизаторы запросов наподобие тех, которые используются в SQL-ориентированных СУБД. Остается открытым вопрос о требуемом уровне изоляции данных при поддержке транзакционного доступа к базам XML-данных.

Интеграция информации

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

Самоадаптация

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

Заключение

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

Литература

1. С.Д. Кузнецов. Базы данных: языки и модели. Москва, Бином, 2008

2. Марк Ривкин. Новая версия СУБД Oracle - Oracle 11g. Oracle Magazine - Русское издание (Май Июнь 2007). http://www.oracle.com/global/ru/oramag/mayjune2007/russia_oracle_11g.html

3. К. М. Саракко. Что нового в DB2 Viper. http://www.ibm.com/developerworks/ru/library/dm-0602saracco/

4. Мишель Дамлер. Microsoft SQL Server 2008. Общие сведения о продукте. https://msdb.ru/Downloads/sql/2008/sqlserver2008_productoverview_final_rus.doc

6. Oracle Real Application Clusters Administration and Deployment Guide 11g Release 1 (11.1). http://download.oracle.com/docs/cd/B28359_01/rac.111/b28254/title.htm

7. Whei-Jen Chen, Alain Fisher, Aman Lalla, Andrew D McLauchlan, Doug Agnew. Database Partitioning, Table Partitioning, and MDC for DB2 9. http://www.redbooks.ibm.com/abstracts/SG247467.html?Open

8. Query Optimization in Oracle Database10g Release 2. An Oracle White Paper June 2005. http://www.oracle.com/technology/products/bi/db/10g/pdf/twp_general_query_optimization_10gr2_0605.pdf

9. Brian Babcock, Surajit Chaudhuri. Towards a Robust Query Optimizer: A Principled and Practical Approach. Proceedings of the 2005 ACM SIGMOD International Conference on Management of Data, pp. 119–130. ftp://ftp.research.microsoft.com/users/autoadmin/sig05_p119.pdf

10. V. Markl, G. M. Lohman, and V. Raman. LEO: An autonomic query optimizer for DB2. IBM Systems Journal, Volume 42, Number 1, 2003. http://www.research.ibm.com/journal/sj/421/markl.html. Имеется перевод на русский язык. Виджайшанкар Раман, Волкер Маркл, Гай Лохман. LEO: самонастраивающийся оптимизатор запросов для DB2. Открытые системы, N 4, 2003. http://www.osp.ru/os/2003/04/182936/_p1.html

11. Surajit Chaudhuri, Vivek Narasayya. Self-Tuning Database Systems: A Decade of Progress. Proceedings of the 33rd International Conference on Very Large Data Bases, pp. 3-14. http://www.vldb2007.org/program/papers/special/p3-chaudhuri.pdf

12. С.Кузнецов. Развитие идей и приложений реляционной СУБД System R. http://www.citforum.ru/database/articles/art_27.shtml

13. Иван Бодягин. Версионность в Yukon. RSDN Magazine #6-2003. http://www.rsdn.ru/article/db/yukonvers.xml

14. Oracle 11g Release 1 (11.1) Database Concepts. Chapter 13. 13 Data Concurrency and Consistency. http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/consist.htm

15. Аруп Нанда. SecureFiles: новые большие объекты. http://www.oracle.com/global/ru/oramag/apr2008/apr-08_11g_sfs.pdf

16. Электронная документация по SQL Server 2008. Общие сведения о FILESTREAM. http://technet.microsoft.com/ru-ru/library/bb933993(SQL.100).aspx

17. С.Д. Кузнецов. Объектно-реляционные базы данных: прошедший этап или недооцененные возможности? Труды Института системного программирования, т. 13, часть 2, М., ИСП РАН, 2007, стр. 115-140. http://citforum.ru/database/articles/ordbms10/

18. Б.Б.Костенко, С.Д. Кузнецов. История и актуальные проблемы темпоральных баз данных. Труды Института системного программирования, т. 13, часть 2, М., ИСП РАН, 2007, стр. 77-114. http://citforum.ru/database/articles/temporal/

19. Oracle 11g. Oracle Flashback Technology. http://www.oracle.com/technology/deploy/availability/htdocs/Flashback_Overview.htm

20. Электронная документация по SQL Server 2005 (сентябрь 2007 г.). Основные понятия компонента Full-Text Search. http://technet.microsoft.com/ru-ru/library/ms142547.aspx

21. Дуглас Шерер и Кэрол Бреннан. Изучение основ Oracle Text. http://www.oracle.com/global/ru/oramag/may2001/intermedia_3.html

22. DB2 Net Search Extender. http://www-306.ibm.com/software/data/db2/extenders/netsearch/

23. Oracle TimesTen In-Memory Database. Обзор. http://www.oracle.com/global/ru/pdfs/tech/tg_oracle_imdb.pdf

24. СУБД ЛИНТЕР. Техническ