Добавил:

Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Обнинский институт атомной энергетики НИЯУ МИФИ

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

БД_1 / Лекции / Лекция 17 Перспективы БД.doc

Скачиваний:

Добавлен:

11.06.2015

Размер:

3.32 Mб

Скачать

☆

1 / 31 2 3 > Следующая >>>

137

XVIII. Перспективы развития бд

Развитие компьютерной техники

Развитие ядра СУБД

Развитие внешнего окружения

Развитие средств работы с БД

Развитие моделей данных

Сенсорные сети

Технологии обслуживания нового поколения

Развитие компьютерной техники

За последние 25 лет тактовая частота процессоров возросла с МГц до ГГц, оперативная память – с нескольких сотен Кбайт до Гигабайт, а память на дисках - со 100 Мбайт до Тбайт и более. Появилась возможность объединить информационные, вычислительные и сетевые ресурсы распределенных компьютеров в виде ГРИД-системы. Увеличение оперативной памяти объемом до десятков Гбайт позволяет постоянно держать в оперативной памяти полностью многие БД или наиболее часто используемые таблицы и большинство индексов.

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

Например, корпорация Oracle продемонстрировала свои первые серверы на базе четвертого поколения RISC-процессоров Sparc T4. Первое поколение этой серии Sparc T1 (кодовое название Niagara) было выпущено в конце 2005 г. компанией Sun Microsystems. Новый восьмиядерный процессор с ядром, поддерживающим два потока команд и работающим на тактовой частоте 3 ГГц, по скорости выполнения одного потока команд в пять раз превосходит 16-ядерный Sparc T3 с тактовой частотой 1,69 ГГц, в котором каждое ядро обслуживает только один поток команд. В Sparc T4 улучшена поддержка средств виртуализации операционной системы Solaris, используемой в серверах на платформе Sparc, и реализован механизм динамических потоков (Dynamic Threads), позволяющий автоматически балансировать ресурсы ядра процессора между двумя потоками команд в зависимости от их текущих потребностей в процессорных ресурсах. Еще одно усовершенствование Sparc T4 — встроенный сетевой интерфейс 10 Gigabit Ethernet. Первой серверной системой, построенной на базе нового Sparc, стал кластер SPARC SuperCluster T4-4. Он масштабируется до 16 Sparc T4 и 4 Тб оперативной памяти и строится из четырехсокетных стоечных серверов SPARC T4-4.

Мобильные телефоны, беспроводные мобильные устройства, в том числе ноутбуки, коммуникаторы и смартфоны позволяют еще больше расширить сферу использования БД. Встроенные вычислительные устройства — в автомобилях, зданиях и даже в теле человека — все шире распространяются. Все они требуют использования БД для хранения измеряемых ими показателей. Интернет проникает во все сферы человеческой деятельности, ИКТ становятся способными не только обслуживать, но и предвидеть запросы пользователя, автоматически адаптироваться к ним. Компьютерные интерфейсы становятся более естественными, для этого используется распознавание речи, естественный язык для формулировки запросов и изображения. Для ИКТ сейчас характерны низкая степень надежности и живучести системы из-за сбоев при эксплуатации; большой объем трафика; доступность в режиме 7*24*365, появилась проблема задержек в иерархии памяти.

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

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

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

Постоянное снижение стоимости оптоволоконных кабелей и активного сетевого оборудования будет способствовать более широкому внедрению Гигабитных каналов. Технология Гигабит Ethernet уже используется в качестве магистральных линий и началось ее применение в отдельных узлах Интернет.

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

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

Осуществляется переход на 64-разрядные ОС. К сожалению, большинство действующих приложений написано для 32-разрядных систем. Основными рабочими средами пользователей остаются ОС Windows, Linux. На серверах и ответственных задачах доминируют ОС Linux. Дружественность ОС Linux к пользователю приближается к уровню ОС Windows. Поддержка больших объемов оперативной памяти позволяет иметь несколько загружаемых ОС на одном сервере одновременно в нескольких виртуальных машинах и повысить скорость работы тех ОС, которые нуждаются в этом. Многие компании уже виртуализировали часть своих ИТ-систем, использование технологий виртуализации будет расширяться. Это дает возможность работать с унаследованными приложениями. Станет доступен режим быстрого переключения между разными ОС. Это важно при анализе аварийных ситуаций на серверах [6].

Следуя современной тенденции к унификации, корпорация Microsoft планирует выпустить единую ОС и одинаковые основные инструменты для персональных компьютеров, смартфонов, планшетов и телевизоров. При этом обеспечивается одинаковый графический интерфейс и одни и те же программные компоненты - браузер, электронная почта, скайп, ICQ, др. Microsoft планирует выпустить первую ОС Windows, которая будет поддерживать разные микропроцессорные архитектуры. Google также стремится к формированию единой и упрощенной экосистемы, которая бы помогла упростить разработку приложений и в целом развитие линейки инструментов. ОС Android 4.0 можно ставить не только на смартфоны, но и на планшеты. Уже имеется определенный опыт замены предустановленных ОС на коммуникаторах и смартфонах [19], что позволит в дальнейшем стандартизовать ОС для различных мобильных устройств.

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

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

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

Центры обработки данных должны создаваться с высокой избыточностью, где максимальная нагрузка на сервера не должна превышать 50%. Тогда они смогут справиться с пиковыми нагрузками даже тогда, когда отказывают критически важные системы, а другие стоят на профилактике. Кроме того надо иметь резервные центры, где будет устанавливаться отдельное оборудование для восстановления, готовое сразу приступить к работе в случае региональной катастрофы.

Развитие ядра СУБД

Современные традиционные СУБД чрезвычайно сложные программные системы. Проблема современных СУБД в их архитектуре, которая не меняется уже 30 лет, операции наподобие Join при большом объеме данных выполняются крайне неэффективно. А реализация блокировок на уровне полей съедает до 95% ресурсов сервера [28]. Недостатками существующих СУБД являются усложнение поиска данных, увеличение времени их извлечения, выполнения резервного копирования при росте объемов данных, слишком длительных сроков восстановления систем и данных в случае сбоев, чрезвычайная сложность в управлении, дороговизна, не гибкость с точки зрения оперативности адаптации.

Медлительность реляционных баз данных объясняется следующими факторами. Они обслуживают буферный пул, ведут журналы операций для нужд восстановления, а также управляют блокировками полей данных, предотвращающими их перезапись конкурирующими операциями. Все эти задачи отнимают более 90% системных ресурсов [9]. Реляционные базы данных не обладают необходимой гибкостью. Их архитектура, разработанная еще в эпоху перфокарт, реализует фиксированный подход к моделированию данных. Если организации нужно добавить новый столбец к таблице, приходится изменять схему базы, что может вызвать определенные трудности. При этом сама схема не всегда точно отражает исходную модель данных.

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

За последние 30 лет развитие СУБД происходило эволюционно в направлении расширения функциональности. Современные СУБД наделяются все более интеллектуальным функционалом, упрощающим процесс управления БД. Пользователям нужно, чтобы СУБД работала без сбоев, была эффективной и имела удобные интерфейсы, позволяла производить обмен данными на основе XML-технологий [20].

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

Требованиями к новым реализациям СУБД являются:

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

Тенденциями развития современных универсальных коммерческих СУБД являются [1,2,8,11-15,18,24,25,26]:

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

Основные направления развития СУБД от главных разработчиков (IBM, Oracle, MS) во многом совпадают, это:

уменьшение затрат на администрирование БД, за счет автоматизации задач администратора БД;
снижение требований к аппаратным средствам серверов и систем хранения данных;
использование технологии сжатия данных, в т.ч. для индексов и временных таблиц;
упрощение конфигурирования и развертывания серверов БД;
развитие средств обеспечения безопасности;
реализация отказоустойчивой конфигурации;
интеграция распределенных и неоднородных данных;
поддержка хранения данных в формате XML (например, СУБД Oracle отображает XML-документ в реляционной структуре и хранит его в таблицах, в СУБД DB2 XML-данные никак предварительно не преобразуются и обрабатываются движком, функционирующим параллельно с реляционным);
учет в БД полного жизненного цикла данных;
использование СУБД для построения хранилищ данных;
переносимость приложений из разных СУБД;
включение в состав приложений СУБД аналитических функций.

Установка многих СУБД представляет собой не очень простую задачу, поэтому установку СУБД для промышленной эксплуатации необходимо поручать опытному администратору, иначе через какое-то время могут возникнуть проблемы с выделенной памятью, например, для хранения таблиц, обработки даны и т.п. Поэтому этот процесс должен выглядеть в стиле "plug and play" – подключай и работай. А СУБД должна самостоятельно подстраиваться под изменение внешних условий путем уточнения установочных и конфигурационных свойств СУБД, автоматического увеличения памяти, создания новых правил обеспечения целостности данных, настройка приложений на уточненные информационные потребности, распознавания внутренних неисправностей, нахождения поврежденных данных, обнаружения сбоев приложений и исправления неисправностей.

Средства диагностирования состояния технических, программных и информационных средств предназначены для выявления соответствующих проблем (получение справок о загрузке процессора, оперативной и дисковой памяти; состоянии информационных ресурсов, БД; работоспособности программных средств). При возникновении отклонений в функционировании системы, подсистема мониторинга на основе анализа состояния системы и ее элементов выявляет первоисточник проблемы, о котором сообщается ответственному администратору. Это позволяет повысить эффективность эксплуатации БД. Например, для диагностики работ аппаратно-программных средств 20 распределенных центров ЕСИМО используется IBM Tivoli мониторинг.

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

Администраторы баз данных должны тратить свое время на сложные задачи, а не на рутинные. Пользователи должны получать исчерпывающую информацию о текущем состоянии всех компонентов БД. СУБД должна выполнять действия, направленные на диагностику запуска программы, восстановление работоспособности компонент. БД и ее компоненты будут в будущем автоматическими, самонастраиваемыми, автоинсталлируемыми, автоуправляемыми, авторемонтируемыми, автопрограммируемыми, самокорректирующимися, самооптимизирующимися и самозащищаемыми. Эта идея реализована в СУБД DB2 UDB 8.2 (Stinger).

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

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

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

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

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

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

Элементы Not Only SQL (NoSQL) уже встраиваются в существующие СУБД общеизвестных поставщиков. Так, версия MySQL 5.6 предлагает принципиально новые возможности: полнотекствый поиск, ускоренную репликацию, поддержку многопоточности, автовосстановление, обработка условий WHERE непосредственно в низкоуровневом движке, интеграционный BinLog API, NoSQL/Memcached - интерфейс, позволяющий обращаться с запросами к движку InnoDB "в обход" SQL-нотации.

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

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

уровень постоянного хранения (на основе одной из существующих СУБД MySQL);
высокопроизводительный серверный компонент (на основе web-сервера Apache);
высокопроизводительный маршрутизатор запросов;
надежную систему обмена сообщениями между центрами обработки данных для тиражирования (специально написанную нами);
механизмы управления кластерными системами и их мониторинга (большей частью состоящие из специально разработанного кода);
системы безопасности для управления сертификатами и аутентификации (специально разработанный код);
собственную логику СУБД для выполнения операций чтения и записи (специально разработанный код).

Традиционные устройства хранения ничего не знают о размещенных в них БД, не имеют сведений, которые помогли бы определить конкретные столбцы и строки, содержавшиеся в запросе. Компания Oracle совместно с Sun Microsystems выпустила специализированную машину Exadata 2, адаптированную для работы с гибридными СУБД, способными работать и со строками, и с колонками. Компания Teradata создала аналитическое облако Enterprise Analytics Cloud и специализированную машину для работы с хранилищами данных Extreme Performance Appliance. В этих реализациях серверы хранения предоставляют данные, но сами они «ничего не знают» о серверах БД, на которых они работают. Эта технология обеспечивает десятикратное улучшение по времени отклика по сравнению с обычными дисками. Программное обеспечение Exadata совместно с Oracle Database анализирует запрашиваемые данные и знает, когда и какие данные следует кэшировать, чтобы избежать «замусоривания» памяти.

БД NoSQL не имеют строго определенных схем построения. Чтобы сформировать запрос, все значения в БД NoSQL необходимо предварительно описать. Каждое значение сопровождается именем, которое относит данные к определенному атрибуту. Таким образом, схема определяется самими данными.

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

Главными требованиями к таким СУБД являются доступность системы для пользователей; масштабируемость (гарантированное удовлетворение требований всех пользователей и клиентов, возможность быстрой установки в новых условиях эксплуатации); последовательность или целостность (если данные изменяются, то изменяются повсеместно, так что все пользователи системы в один и тот же момент времени могли видеть те же самые данные). Традиционные реляционные СУБД обеспечивают доступность и последовательность за счет масштабируемости. Новые СУБД типа NoSQL решают в первую очередь проблемы доступности и масштабируемости [3,27,29].

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

Компания Teradata создала аналитическое облако Enterprise Analytics Cloud и специализированную машину для работы с хранилищами данных Extreme Performance Appliance. В этих реализациях серверы хранения предоставляют данные, но сами они «ничего не знают» о серверах БД, на которых они работают. Эта технология обеспечивает десятикратное улучшение по времени отклика по сравнению с обычными дисками. Программное обеспечение Exadata совместно с Oracle Database анализирует запрашиваемые данные и знает, когда и какие данные следует кэшировать, чтобы избежать «замусоривания» памяти.

Аналитическая СУБД Aster компании Teradata подобно системам Oracle Exadata, EMC Greenplum и SAP HANA предлагается как программный продукт для локальной инсталляции и облачного развертывания. СУБД основана на той же аппаратной платформе, что и хранилища данных Teradata. В СУБД Aster реализован фреймворк распределенной обработки данных MapReduce, позволяющей вызывать функции системы при помощи стандартных SQL-запросов. Добавлены также механизмы анализа поведения пользователей на сайтах, результативности маркетинговых кампаний и дерева принятия решений, а также другие аналитические функции. Остальные усовершенствования касаются управления рабочими нагрузками и скорости исполнения SQL-запросов.

Создаются NoSQL СУБД Apache Hadoop, Cassandra, Amazon SimpleDB и Microsoft Windows Azure Table Services, Oracle NoSQL Database, предназначенные для преодоления ограниченности реляционной модели.

В СУБД Sherpa [22] имеется схема секционирования данных, инфраструктура маршрутизации запросов, механизм тиражирования и т.д. с расчетом на упорядоченные данные. Для выполнения запроса необходимо проверить права клиента и затем переадресовать запрос модулю хранения, содержащему нужный блок данных. Контроллер табличных фрагментов управляет конфигурацией кластера Sherpa. В Sherpa спроектирован простой интерфейс наподобие REST (Representational State Transfer, протокол для Web-сервисов, основанный на HTTP), реализующий всего несколько операций. В Sherpa нет сложных транзакций, сложных запросов (например, на соединение таблиц и агрегацию) и целого ряда других «стандартных» возможностей СУБД.

СУБД Drizzle создана в 2008 г., является ответвлением СУБД MySQL. Эта СУБД предназначена для облачных сервисов и веб-приложений. Чтобы повысить быстродействие СУБД, авторы удалили из кода все функции, не требуемые для этих задач, преобразовали архитектуру системы в микроядро и переписали код на C++.

СУБД Greenplum Database отличает возможность масштабирования до петабайтных значений с линейным ростом затрат, распараллеливание запросов, ускоряющее скорость работы на один-два порядка. С технологической точки зрения эту СУБД отличает использование программы MapReduce, разработанной в Google, которая обеспечивает не только высокую производительность за счет применения большого числа процессоров, а в перспективе и ядер, но и высокую надежность, а также технологии компрессии, от 3 до 10 раз сокращающей объемы передаваемых и хранимых данных. СУБД Greenplum Database имеет встроенные возможности для аналитики и статистической обработки средствами специализированного языка программирования R.

В нереляционной СУБД с открытым кодом MongoDB (компании 10gen) в случае сбоя сервер СУБД восстановится до последнего рабочего состояния. Также реализована возможность добавления новых данных к имеющемуся набору, полученному в результате фильтрации с помощью программы MapReduce. Кроме того, усовершенствована функция тиражирования и механизм секционирования данных. СУБД MangoDB представляет собой документно-ориентированную СУБД, хранящую информацию в последовательном формате, подобном JSON. Базы MongoDB лишены табличных структур и схем и позволяют вносить новые атрибуты по мере необходимости. Запросы выполняются с помощью синтаксиса, напоминающего JavaScript. СУБД MongoDB способна извлекать информацию быстрее, чем реляционные СУБД, особенно при запросах на получение несложных наборов данных.

Отличие архитектуры СУБД Компании Greenplum в том, что каждый отдельный компонент СУБД играет роль законченной мини-СУБД, которая сама владеет и оперирует отдельной порцией доверенных ей данных [21]. Эта СУБД автоматически распределяет данные и нагрузку по обработке запросов с помощью программы MapReduce. Продукты Greenplum ориентированы на системы с массовым параллелизмом, в них используется элементы модернизированной версии PostgreSQL. СУБД Greenplum является реализацией конструкции MapReduce, обеспечивающей работу с большими документами в разных форматах, и классической СУБД, ориентированной на работу с реляционными таблицами. Такого рода универсальность достигается за счет машины для работы с параллельными потоками данных – СУБД может не только независимо работать с каждым из двух источников, но и совмещать работу с двумя одновременно. В частности, средствами MapReduce можно оптимизировать доступ к большим СУБД, либо обеспечить выполнение SQL-запросов к таблицам и к файлам. Ядро Greenplum Database – Parallel Dataflow Engine для обработки параллельных потоков данных задумана так, что в перспективе может поддерживать процессоры, состоящие из многих тысяч ядер и при этом поддерживать SQL в характерной для нее параллельной манере.

Компания Couchbase выпустила бета-версию нереляционной СУБД Mobile Couchbase для ОС iOS, используемой в iPhone. Разработчики могут встраивать СУБД в приложения для iPhone и iPad. Mobile Couchbase создана на основе нереляционной СУБД Apache CouchDB. СУБД Mobile Couchbase отличают возможности синхронизации: при минимальном написании кода можно реализовать автоматическую синхронизацию данных по сети с экземпляром CouchDB, работающим в облаке или в ЦОД. СУБД экономно расходует оперативную память и требует относительно немного пространства хранения: приложение с внедренной БД можно легко уместить в 20 Мбайт. Протоколы передачи сообщений, используемые в СУБД, не слишком трафикоемки.

Компания Oracle выпустила NoSQL Database. Эта СУБД предназначена для комплекса Oracle Big Data Appliance. Основой Oracle NoSQL Database является Java-версия СУБД с открытым кодом Berkeley DB, широко применяемая во встроенных системах. В новой СУБД используется простая модель «ключ-значение», то есть нужный элемент данных можно получить по его числовому ключу-идентификатору. Система позволяет делать структурированные запросы, но не требует фиксированной схемы данных. Фирма Oracle построила кластер NoSQL Database из 300 узлов.

Стоунбрейкер предложил воплощенную в VoltDB концепцию NewSQL - новое поколение СУБД, которые выполнены в архитектуре NoSQL, но поддерживают SQL и реализуют атомарность, согласованность, изолированность, долговечность.

MarkLogic Server – это СУБД для работы с неструктурированной информацией, метаданными, включает развитый поисковый механизм.

Создаются также графо-ориентированные СУБД для поддержки масштабных социальных сетей (InfiniteGraph - Java-СУБД; FlockDB от создателей Twitter).

СУБД HBase V0.19.3 (Apache Software Foundation) и Bigtable (Google) предлагают новый способ последовательной обработки данных. На смену SQL- подобным процессам извлечения и преобразования данных в монолитных системах приходит подход, в котором БД поддерживают операции создания, чтения, изменения, удаления, а сложные преобразования передаются внешним компонентам, рассчитанным на параллельные вычисления. Параллельные вычисления можно выполнять, например, при помощи приложений MapReduce, а высокая пропускная способность достигается при помощи распределенной и реплицируемой файловой системы, такой как Hadoop Distributed File System (HDFS) или Google File System. В СУБД HBase для хранения связанной информации в одной таблице часто используется денормализация. СУБД HBase представляет собой масштабируемую, распределенную, построенную на основе столбцов БД с динамической схемой для структурированных данных. Она обеспечивает надежное и эффективное управление большими объемами информации (несколько петабайт и более), распределенных среди тысяч серверов. Данные СУБД HBase представляют собой многомерный массив, значения которого (ячейки таблицы) обозначаются четырьмя ключами:

value = Map(TableName, RowKey, ColumnKey, Timestamp)

где:

TableName – строка;
RowKey (Ключ строки) и ColumnKey – двоичные значения (тип byte[]);
Timestamp (Метка времени) – 64-разрядное число (тип long);
value (значение) – необрабатываемый массив байтов (тип byte[]).

СУБД HBase является распределенным хранилищем данных с колоночной организацией информации. Модель данных СУБД HBase во многом копирует модель данных Bigtable. Ключ строки является первичным ключом таблицы и обычно представляет собой строковые данные. Строки сортируются по ключам строки в лексикографическом порядке. Информация, хранящаяся в таблице, структурирована в наборы столбцов, которые можно считать категориями. Каждое семейство столбцов может содержать произвольное количество элементов, обозначаемых метками (или квалификаторами). Ключ столбца column состоит из названия набора, двоеточия (:) и метки. Например, для элементаdate и набора info ключ столбца имеет значение info:date. Некоторые наборы столбцов определены в схеме таблицы HBase, но приложения могут на лету создавать новые элементы, добавляя строки в таблицу. В наборе столбцов разные строки таблицы могут иметь разное количество элементов. СУБД HBase поддерживает модель динамической схемы.

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

В таблице 1 приведен простой пример таблицы HBase Persons с двумя наборами столбцов name и contact [21].

Таблица 1 - Таблица Persons с двумя наборами столбцов

Ключ строки	Метка времени	Набор столбцов
Ключ строки	Метка времени	name	contact
000001	t3		contact:http research.google.com/people/jeff/
	t2	name:first Jeffrey
	t1	name:last Dean
000002	t5	name:first Gabriel
000002	t4	name:last Mateescu

Пустые ячейки не имеют значений, связанных с ключами этих ячеек. СУБД HBase не хранит пустые ячейки: чтение пустых ячеек подобно извлечению из массива значения при помощи несуществующего ключа. Для каждой строки одновременно можно получить доступ только к одному элементу группы столбцов (в отличие от реляционных БД, где при помощи одного запроса можно получить доступ к ячейкам строки из многих столбцов). Под строками подразумеваются произвольные наборы байт, т.к. СУБД HBase не интерпретирует данные. Элементы группы столбцов отображаются в строке как подстроки. Таблицы разделены на регионы, соответствующие таблетам Bigtable. Регион содержит строки определенного диапазона. Разделение таблиц на регионы является ключевым механизмом для эффективного обслуживания больших таблиц. Диапазон строк таблицы динамически разбивается на набор регионов. Регион HR отвечает подмножеству строк в таблице [startkey(HR), endkey(HR).

Ключ колонки выглядит следующим образом: key = family_id:column_qualifier, он включает в себя идентификатор семейства колонок family_id и идентификатор колонки внутри семейства column_qualifier. Семейство колонок описывается во время создания или изменения таблицы, тогда как квалификатор колонки внутри семейства может быть произвольным набором байт, таким образом, разные строки могут обладать разным набором колонок. Данные хранятся в файловой системе по семействам колонок. При описании колонки для неё доступно множество опций, таких как максимальное количество версий, есть ли необходимость хранить семейство колонок всегда в оперативной памяти или оно может быть записано на диск, а также необходимо ли сжатие при записи на диск.

Версии объекта доступны по временной метке. При записи объекта в хранилище данных приложение может указать его временную метку. Приложения, которым необходимо избежать коллизий, должны самостоятельно генерировать уникальные временные метки. Версии объектов в СУБД HBase представляются объектами класса KeyValue. KeyValue является неизменяемым объектом (immutable). KeyValue содержит ссылку на массив из байтов, сдвиг в этом массиве, начиная с которого начинаются байты, принадлежащие KeyValue, и длину, которую KeyValue занимает в массиве.

СУБД Cassandra (Apache Software Foundation, http://cassandra.apache.org/download/) - это высоко-масштабируемое, автоматически восстанавливающее согласованность данных, распределенное, основанное тоже на колончатой модели данных ключ-значение хранилище. Основными единицами модели данных для этой СУБД являются:

Column (колонка) - это наименьшая единица данных - кортеж, который содержит название, значение и временная метка, все значения устанавливаются клиентом, включая timestamp;
Column Family (семейство колонок) - это контейнер для колонок, аналог таблицы из реляционных систем, в семействе колонок устанавливается механизм сортировки;
Row (ряд) - это ключ и связанные с ним наборы колонок, каждое семейство колонок сохраняется в отдельном файле, и этот файл отсортирован в row порядке; связанные колонки это те, к которым обращаются вместе (они хранятся в одном семействе колонок);
Keyspace (пространcтво ключей) - это первое измерение, оно содержит семейство колонок; пространство ключей это тоже самое, что и схема в реляционной СУБД;
Super Column (супер колонка) - это колонка контейнер, которая содержит другие колонки.

СУБД Cassandra позволяет размещать в каждой строке до 2 млрд. столбцов. Размеры строк имеют предельный размер около 2 Гбайт. СУБД поддерживает вторичные индексы, что обеспечивает несложный механизм опроса данных, и возможность изменять схему БД, не перезапуская весь кластер. Можно произвести компрессию данных в фоновом режиме, имеются методы оптимизации использования рабочей памяти серверов. СУБД подходит для сред, работающих на нескольких узлах.

БД NoSQL будут говорить на одном языке. Стремясь объединить растущий, но разобщенный рынок СУБД категории NoSQL, создатели СУБД CouchDB и SQLite представили новый язык запросов формата UnQL (Unstructured data Query Language). Он во многом совместим с классическим SQL, предназначен для использования в веб-сервисах, как единый механизм доступа к SQL и NoSQL-базам данных. UnQL использует формат JSON.

Развитие UnQL создало условия для унификации NoSQL. Язык UnQL можно рассматривать в качестве «надмножества» SQL. В этом случае будет реализован анализ всех операторов языка SQL и обеспечена поддержка ряда новых операторов и выражений. Если язык UnQL получит признание достаточно большого числа разработчиков, он может сыграть для рынка NoSQL примерно ту же роль, какую четыре десятилетия назад сыграл для рынка реляционных БД язык SQL, то есть стать общим интерфейсом, который объединит фрагментированный рынок СУБД нового поколения [9].

Язык UnQL создавался для того, чтобы обеспечить единый интерфейс для широкого диапазона архитектур БД, имеющих природу как SQL, так и NoSQL. Язык UnQL, как и SQL, построен на основе реляционной алгебры. Это гарантирует получение предсказуемых и повторяемых результатов.

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

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

Развитие внешнего окружения

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

Развитие БД, работающих в онлайн, одна из наиболее серьезных задач, стоящих сегодня перед профессионалами в области информационных технологий. За последние десятилетия произошли кардинальные изменения в средствах и методах доступа к данным, они стали доступны в любом месте, в любое время, по любой предметной области. Не составляет большого труда разработать новые формы для удаленного ввода данных с помощью систем управления контентом (CMS).

Появляются новые case-средства и языки, позволяющие автоматически создавать программный код для приложений БД, например, как это реализовано в case Rational Rose. За период развития компьютерной техники развитие языков шло от команд языка Ассемблер к алгоритмическим языкам, многоцелевым функциональным языкам пятого поколения и проблемно – ориентированным языкам моделирования требований (шестое поколение). Таким образом, моделирование требований и использование case-средств позволит существенно упростить создание БД.

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

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

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

Интерфейсы пользователей приложений к БД должны строится на единой технической спецификации графического интерфейса, в которой отражаются:

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

«Закон Хикса» утверждает, что время, затрачиваемое человеком на приятие решения, находится в логарифмической зависимости от числа выборов. Это значит, что интерфейс должен быть максимально простым, с количеством пунктов в меню не более 5-7 и минимальным объемом выдаваемой информации. Последнее достигается за счет автоматизированного создания меню на основе значений атрибутов БД и синхронизации поисковых атрибутов.

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

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

Большинство традиционных средств резервного копирования обеспечивают многократное копирование одних и тех же данных, что приводит к увеличению объема данных в резервных копиях в 5-30 раз или даже больше. Повторное резервное копирование одних и тех же файлов и данных — основная причина, по которой резервное копирование начинает захватывать рабочее время, создает чрезмерную нагрузку на сетевые ресурсы и занимают огромную емкость в хранилищах. Поэтому необходимо сохранять только новую и уникальную информацию. Средства дедупликации осуществляют поиск дублированных данных в пределах заданного набора и удаляют такие данные из него [5]. Цель дедупликации заключается в том, чтобы обеспечить хранение каждого уникального информационного объекта только в одном экземпляре, сохранив при этом возможность реконструкции всей информации в ее исходной форме по требованию, со 100% гарантией и без замедления доступа. Дедупликация сокращает расходы на поддержку инфраструктуры хранения данных, емкость дисковой памяти за счет уменьшения объемов копирования данных, времени резервного копирования, ускоряет восстановление данных, затраты на удаленную репликацию резервных копий, повышает надежность защиты данных, производительность системы резервного копирования, значительно снижает нагрузку на сеть, упрощает управление резервным копированием.

Чтобы избежать потери информации, развиваются механизмы миграции данных. Системы нуждаются в средствах хранения, поддерживающих неограниченный во времени доступ к данным в полезной форме. Эти средства автоматизируют процесс миграции данных из одного носителя на другой и/или поддерживают аппаратно-программные механизмы, требующиеся для доступа к этим данным. Но главное должны быть универсальные механизмы преобразования форматов хранения данных. И здесь помогут XML-технологии, стандартизация форматов хранения и обмена данными. То есть также как для офисных документов создан Open Data Format (ODF), необходимо во всех предметных областях разработать единые форматы обмена данными. Например, в гидрометеорологии широко применяется международный формат NetCdf.

Развитие средств работы с БД

Рост объемов БД создает трудности для всех компонент информационной системы. Чем больше данных, тем больше способов их обработать, что в свою очередь приводит к дальнейшему росту объема данных. Данные надо передавать, хранить, структурировать и обрабатывать в реальном времени.

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

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

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

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

Создание метаданных все еще остается проблемой для многих БД. Для обмена метаданными разрабатываются соответствующие структуры для различных объектов метаданных. Для обмена сведениями об Интернет-ресурсах может использоваться формат Dublin Core, для обмена новостной информацией – RSS, для информационного обмена между программными компонентами разрабатываются стандартные интерфейсы (API), позволяющие усваивать информацию, как из технологии интеграции данных, так и других компонент.

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

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

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

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

Информацию надо искать по месту, времени и другим свойствам. Для выполнения анализа текстов и поддержки поиска с использованием семантики приходится иметь дело с огромными объемами информации. Для этого не пригодны ни традиционные файловые системы, ни современные СУБД. Проблемой является также создание простых способов анализа, обобщения, поиска и обозрения электронных подборок мультимедийной информации, относящейся к некоторой персоне. При выдаче ответа на запросы пользователей система должна оценивать полноту и релевантность результатов выдачи, чтобы пользователи могли понять, что они получили. Фактически необходимо объединение возможностей СУБД и файловых систем. Современные СУБД должны поддерживать неструктурированные (текстовые), пространственные и мультимедийные данные; временные ряды; процедурные данные; триггеры; потоки данных. Крупные фирмы – разработчики СУБД включают в свои продукты дополнительные приложения, которые позволяют работать с подобной информацией. Например, СУБД Oracle имеет картриджи для работы с пространственными, текстовыми и XML данными.

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

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

Новые СУБД будут распознавать интересующую пользователя или приложение информацию за счет метаданных; усваивать большие объемы данных в реальном времени; генерировать и синтезировать за счет имеющихся в БД информации новые наборы данных.

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

При создании и поддержке БД должны применяются следующие стандарты, табл.1.

Таблица 1 – Основные стандарты создания и поддержки БД

Назначение	Стандарты
Управление данными и приложениями
Мониторинг аппаратно-программных средств	Common information model (CIM), Simple Network Management Protocol (SNMP), Windows Management Instrumentation (WMI)
Сбор и обработка данных и знаний	JSR87 – Java Agent Services
Управление загрузкой данных	Application Response Measurements (ARM)
Функциональные стандарты	ISO 19120:2001
Правила для схемы приложений	ISO 19109:2003
Интеграция данных
Набор основных семантических элементов, описывающий публикации, http://dublincore.org/documents/dcq-html/	ISO 15836: 2003 DC (Dublin Core) RFC 2413, RFC 2731
Технология интеграции распределенных и неоднородных данных, http://data.meteo.ru/ru/e2edm/index.php?section=1	E2EDM
Описание информационных ресурсов в области образования, http://ltsc.ieee.org/wg12	LOM (Learning Object Metadata): 2002 P1484.12.1
Поддержка сервисов
Регистр источников сервисов	UDDI
Регистр сервисов	WSDL
Доступ к простым объектам. Часть 1: Общая архитектура. Часть 2: Доступ через SQL	ISO 19125:2004
Простой протокол обмена данными	SOAP
Диагностика проблем за счет взаимодействия с источниками данных	JSR47 - Logging API Specification
Сервисы	ISO 19119
Координация Web-сервисов, http://www.isotc211.org/opendoc/211n2034/	TC211/OGC: 2006
Определение прикладных сервисов и спецификация протокола	ISO 23950:1998
Администрирование сервисов
Общий интерфейс	JSR168
Спецификация портлетов, выполняемых на одном узле	JSR286
Спецификация удаленных портлетов	WSRP
Программный интерфейс приложения	API
Качество данных
Принципы оценки качества	ISO 19113:2002, ГОСТ Р ИСО 19113-2003
Методы оценки качества	ISO 19114:2003
Качество программных средств	ISO 9126
Структуры данных
Эталонная модель	ISO 19101:2002
Язык концептуальной схемы	ISO 19103
Профили	ISO 19106:2004
Временная схема	ISO 19108:2002
Методология каталогизации	ISO 19110
Почтовые адреса	ISO 11180
Представление дат и времени, http://xml.coverpages.org/ISO-FDIS-8601.pdf	ISO 8601:2000
Семибитное кодирование набора символов	ISO 646
Модель описания датчиков, приборов и генерируемых ими потоков информации (http://vast.uah.edu/SensorML/)	SensorML (The Sensor Model Language)
Метаданные
Метаданные	ISO 19115:2003
Географический язык разметки GML	ISO 19136
Каталоги, директории и регистры	ISO 19126
Электронная визитная карточка – описание персоны	vCard, REC 2426
Информация о научных проектах (“Проект”, “Организация” и “Персона”)	CERIF
Метаданные – Реализация XML схемы	ISO 19139
Библиографические описания – содержание форма и структура	ISO 690:1987
Информационные технологии – Регистр метаданных. Стандарт для описания элементов данных в БД и документах	ISO 11179
Интеграция информационно – измерительных систем, обмена сообщениями между сенсорами и компьютером, http://www.opengeospatial.org/legal	TML (Transducer Markup Language), 2005
Общая метамодель для обмена метаданными при использовании технологий Хранилищ данных	CWM (Common Warehouse Metamodel)
Кодирование и передача метаданных	METS (Metadata Encoding and Transmission Standard)
Описание моделей данных, реляционных схем, схем обмена данными	MDC OIM (Metadata Coalition Open Informational Model)
Протокол сбора метаданных, http://www.openarchives.org/OAI/openarchivesprotocol.html	Protocol for Metadata Harvesting, the Open Archives Initiative (OAI)
Среда описания ресурсов с разной степенью формализации , http://www.w3.org/RDF/	RDF (Resource Description Framework)
Описание схемы классов и их свойств, с учетом их наследования, ограничений, http://www.w3.org/TR/REC-rdf-syntax/	RDFS (Resource Definition Framework Schema)
Описание предметных онтологий на основе RDFS http://ontology.com/	OWL (Web Ontology Language)
Классификаторы
Кодирование (шифрование)	ISO 19118: 2003
Коды стран	ISO 3166
Сокращения названий языков	ISO 639-2:1998
Модель определения основной структуры и содержания схемы концепций тезауруса, классификационных схем, таксономий, «фолксономий» терминов и определений, глоссариев и других типов контролируемых словарей. http://www.w3.org/2004/02/skos/mapping/spec/	SKOS Core (SKOS Mapping Vocabulary Specification): 2004
Пространственные данные
Пространственная схема	ISO 19107:2003
Привязка в пространстве по координатам, http://portal.opengeospatial.org/files/?artifact_id=6716	ISO 19111:2003
Привязка в пространстве по географическим идентификаторам	ISO 19112:2003
Услуги определения координат	ISO 19116:2004
Изображения и растровые данные	ISO 19121:2000
Схема геометрического и функционального покрытия	ISO 19123:2004
Геодезические коды и параметры	ISO 19127
Интерфейс картографического сервера	ISO 19128
Содержание цифровых геопространственных метаданных	FGDC STD 001–1998
Передача пространственных данных. Часть 5: Профиль и расширения для растровых данных. Часть 6: Профиль для точечных данных, Часть 7: Профиль CADD	FGDC STD 002.5– 1999, FGDC STD 002.6, FGDC STD 002.7– 2000
Точность определения геопространственных координат	FGDC STD 007– 1998
Содержание цифровых ортоизображений	FGDC STD 008– 1999
Содержание сканерных данных дистанционного зондирования	FGDC STD 009– 1999

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

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

При разработке ЕИП необходимо широкое использование:

систем классификации и кодирования информации;
средств интеграции разнородных и распределенных данных;
облачных технологий (IaaS, PaaS, SaaS);
стандартизации протоколов обмена данными, структур данных;
программ учета и архивации данных;
современных коммуникационных средств (web-камер, Skype, ICQ, мобильных телефонов, коммуникаторов, др.);
сервис-ориентированной архитектуры, использующей открытые стандарты UDDI, WSDL, SOAP и тематических XML-схем [20];
геоинформационных систем.

Развитие моделей данных

Создаваемые в разных организациях БД не имеют единой концептуальной основы и по большому счету не могут взаимодействовать друг с другом. Использовать вместе заложенную в них информацию очень трудно. Поэтому необходимо развитие универсальных моделей данных, стандартизации представления, обмена данными и метаданными [7, 17].

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

использование языка XML;
унификация представления данных за счет использования многомерной модели данных;
применение формата JSON.

Язык XML уже более 10 лет широко применяется в области создания ИКТ. Основным назначением языка XML является обмен данными. Данные представленные в этом языке являются самоописывающимися, т.е. могут легко прочитаться компьютером за счет использования XML-схемы и человеком, который по именам тегов может определить, что за данные здесь имеются. Так как количество XML-файлов в некоторых системах достигает миллиона (например, в проекте Европейской Комиссии «SeaDataNet»), то имеется потребность хранить эти данные в БД. И в некоторых СУБД (Oracle, MsSQL, DB2) созданы возможности работы с XML-данными. Но главным достоинством языка XML является возможность создания XML-схемы для любой предметной области. Эта схема позволяет описать весь состав атрибутов, используемых в рассматриваемой предметной области. При разработке таблиц, форм визуализации состав атрибутов настраивается на основе созданной XML-схемы. Это позволяет создавать универсальные программные средства, как для ввода данных, так и для их визуализации [20].

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

Атрибуты метаданных специфицируют характеристики производства (получения, описания, обработки) данных. В атрибутах метаданных определяются идентификаторы структурных единиц данных, платформ наблюдений, инструментов измерений, методов обработки, проектов, географических объектов. В атрибутах «Метаданных» выделяются разделы:

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

Параметры данных, специфицирующие отдельные свойства процесса (явления) могут:

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

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

Значениями «Роли» являются для объектов:

организации – автор, проектировщик, производитель, владелец, разработчик (застройщик), оператор, администратор;
персоны – автор, проектировщик, владелец, разработчик, оператор, администратор;
товара – проектировщик, производитель, продавец;
проект – автор, исполнитель, участник, администратор.

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

- Состояние транспортного объекта - отправление, переход, заход, прибытие, стоянка, на рейде, ремонт, дрейф, производство работ, погрузка, разгрузка;

- Выбросы (отходы): создание, хранение, обезвреживание, утилизация;

- Проект - инициализация; планирование; выполнение; контроль; завершение;

- Данные (управление) - производство измерений, сбор, упорядочение, контроль, создание БД, хранение, каталогизация, обмен, доведение, использование;

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

- Данные (анализ) - прогноз, классификация, сравнение;

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

Для каждого этапа жизненного цикла документа необходимо знать:

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

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

Первая нормальная форма предполагает наличие одного измерения, являющегося ключом. Например, все простые классификаторы, имеющие два поля – код и описание кода, объединяются в одну таблицу за счет включения третьего поля – идентификатора классификатора, табл.2.

Таблица 2 - Первая нормальная форма

ID классификатора	Код	Значение
1	А	ааа
1	Б	ббб
1	С	ввв
2	1	ссс
2	2	ддд

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

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

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

Таблица 3 - Вторая нормальная форма

ID записи	Год	Квартал	Страна	Город	Имя характеристики	Значение
1	2009	1	RU	Обнинск	Кол-во населения	110000
2	2009	1	RU	Обнинск	Число родившихся	500
3	2009	1	RU	Обнинск	Число умерших	600

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

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

Таблица 4 - Третья нормальная форма

ID записи	Имя характеристики	Значение
1	Широта	60.00
2	Долгота	29.00
3	Дата	30.07.2009
4	Номер станции	1
5	Номер рейса	15
6	Прибор	СТД
7	Метод использования прибора	Зондирование
	Горизонт	10
8	Судно	Академик Федоров
	Страна	RU
9	Имя параметра	Т w
	Значение параметра	15.6

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

1 / 31 2 3 > Следующая >>>

Соседние файлы в папке Лекции

#
11.06.2015892.93 Кб40Лекция 12_СППР.doc
#
11.06.2015577.54 Кб41Лекция 13_Web.doc
#
11.06.2015336.38 Кб36Лекция 14_ПУД.doc
#
11.06.2015326.14 Кб41Лекция 15 Достоверность.doc
#
11.06.2015709.12 Кб46Лекция 16 оптимизация.doc
#
11.06.20153.32 Mб36Лекция 17 Перспективы БД.doc
#
11.06.2015372.22 Кб37Лекция 1_вводная.doc
#
11.06.2015441.34 Кб35Лекция 2_орг_тех_пробл.doc
#
11.06.2015472.06 Кб34Лекция 3 Обслед.doc
#
11.06.2015394.75 Кб34Лекция 4_классификация.doc
#
11.06.2015699.39 Кб38Лекция 5 СУБД_Общ_св.doc