48547

Перспективы развития БД

Конспект

Информатика, кибернетика и программирование

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

Русский

2013-12-11

3.17 MB

10 чел.

PAGE   \* MERGEFORMAT 393

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].

Элементы 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 анализирует запрашиваемые данные и знает, когда и какие данные следует кэшировать, чтобы избежать «замусоривания» памяти.

Аналитическая СУБД 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

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 – Схема четвертой нормально формы многомерных данных

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

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

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

Классификаторы оформляются в соответствии с первой нормальной формой для многомерных данных.

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

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

При работе с УМД пользователь должен видеть только плоские таблицы, а соответствующий конвертор должен преобразовывать плоские таблицы в УМД и обратно.

Универсальная схема БД, предложенная для СУБД Oracle включает, следующие таблицы [16]:

- Схема (идентификатор схемы, имя схемы, комментарии);

- Таблица (идентификатор схемы, идентификатор таблицы, имя таблицы, комментарии);

- Столбец (идентификатор схемы, идентификатор таблицы, имя столбца, тип данных, значение по умолчанию, длина, точность, комментарии);

- Данные (идентификатор схемы, идентификатор таблицы, идентификатор столбца, номер строки, значение, комментарии).

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


Рисунок 2 - Универсальная схема [16]

При формировании запроса можно пользоваться только одной таблицей «Данные». Главный недостаток такой универсальной схемы - большое число соединений даже для выполнения тривиальных запросов. Еще одним недостатком является то, что такая схема привязана к одной СУБД Oracle. Хотя похожие схемы можно создать и для других СУБД.

В УМД фирмы Treelogy (http://www.treelogy.ru/cd/42) разработчик оперирует практически с единственной таблицей «Перемещение объектов». Навигация по этой таблице очень проста и понятна, так как она представлена в виде дерева (перемещения связаны между собой полями «Откуда» и «Куда» - узлами дерева), отражающего структуру предприятия и его окружения в виде банков, контрагентов, партнёров и т.д., которое строит сам пользователь. Выглядит это аналогично проводнику Windows, только справа не файлы, а таблица перемещений выбранного в дереве узла. Узлы дерева называются Объектами. Объектами могут быть фирмы, их подразделения, товары, деньги, сотрудники. Все объекты равноправны. Объекты имеют вложенную структуру, то есть одни объекты можно вмещать в другие (так и образуется дерево).

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

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

  •  Дата/Время - фиксирует время произошедших изменений;
    •  Что, Откуда, Куда - фиксируют изменение положения в пространстве объектов (просто выбираем в дереве, что и откуда перемещается, а затем куда);
    •  Количество - количественные изменения;
    •  Дополнительные поля (качественные изменения) произвольные характеристики, создаваемые самим пользователем.

В Treelogy перемещения связаны в цепочки (с возможными ветвлениями). Это позволяет отслеживать всю историю перемещений любого объекта со всеми изменениями характеристик.

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

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

Язык JSON (JavaScript Object Notation) стал активно развиваться только в последние годы. Хотя еще в семидесятых годах подобный подход применялся для хранения документально-фактографической информации. Язык JSON основан на принципе хранения данных в форме «ключевое слово: значение». В работе [23] применена реляционная алгебра классической реляционной схемы к формату JSON и доказано, что этот формат описывается математически эквивалентным аппаратом. JSON предоставляет простой способ форматирования данных, например, описать контактную информацию можно следующим образом:

{

  "contacts" : {

     "contact" : {

        "@attributes" : {

           "id" : "1"

        },

        "name" : "Евгений Вязилов",

        "phone" : "+7 48439 74676",

        "address" : {

           "street" : "6, Королева",

           "city" : "Обнинск",

           "state" : "Россия",

           "zipCode" : "249035"

        }      }   }   }

На основе формата JSON и применения триплов выпускником кафедры КССТ ИАТЕ НИЯУ МИФИ М.Кабановым разработана универсальная модель представления данных, рис.3. Эта модель отталкивается от основных структурных единиц схемы БД: объект, экземпляр объекта, свойства объекта. Для каждой структурной единицы схемы БД предлагается создать свою таблицу, представленную в виде трипла. При этом главная структурная единица схемы – объект имеет ссылку на соответствующие экземпляры объекта. А каждый экземпляр объекта ссылается на таблицу, содержащую свойства конкретных экземпляров объекта. При этом каждая таблица имеет индекс, который хранится не в БД, а в системных файлах.

Объекты          Экземпляры объекта     Свойства объекта         Индекс

ID_o

Name

Value

 

ID_экз

Name

Value

 

ID_св

Name

Value

rowID

rowID

1

#Class

1

 

1

E1

1

 

1

Atr1

a

 

1

1

2

 

3

 

1

E2

2

 

2

Atr2

b

2

2

 

1

E3

4

 

4

Atr3

c

 

3

4

N

 

 

 

3

E1

18

18

Atr1

d

4

18

 

 

 

 

3

E2

23

 

23

Atr2

e

 

5

23

 

3

E3

50

 

50

Atr3

f

6

50

 

 

 

 

 

180

Atr1

g

 

7

180

 

N

 

 

 

 

 

 

 

 

 

 

 

N

 

 

 

N

N

Рисунок 3 – Схема УМД на основе отдельного хранения сведений
о структурных единицах БД

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

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

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

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

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

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

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

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

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

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

Технологией, обеспечивающей взаимодействие сенсоров с БД, является язык XML, который обеспечивает обмен данными вне зависимости от аппаратных и программных платформ. Внедрение стандартов на объединение, управление, взаимодействие и использование данных, собранных от различных датчиков, использование XML технологий позволит значительно увеличить как масштабируемость таких средств, так и упростить их настройку. Этому способствовало появление стандартов Sensor Model Language (SensorML, http://vast.uah.edu/SensorML/) и Transducer Markup Language (TML).

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

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

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

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

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

Недостатками обслуживания пользователей являются:

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

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

  1.  

Рисунок 4 - Схема развития информационного обслуживания

Технология информационного обслуживания включает:

  •  автоматизированные рабочие места пользователей, настраивающиеся по составу компонент в зависимости от потребностей пользователей;
  •  мобильные Интернет-средства с использованием беспроводных каналов – ноутбуки, нетбуки, коммуникаторы, смартфоны;
  •  программные агенты на компьютере пользователя, которые автоматически запускаются при выявлении аномалий состояния среды;
  •  интерактивные киоски с сенсорным экраном, работающие постоянно и в любой момент готовые к выдаче информации (например, аудиовоспроизведение прогноза погоды);
  •  различные средства коммуникаций (ICQ, SMS, MMS, e-mail, Skype).

Состав сервисов должен включать:

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

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

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

Для работы с данными используются следующие функции:

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

Пользователь, кроме получения данных и метаданных должен:

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

Выводы

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

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

СУБД третьего поколения должны:

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

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

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

Для крупных БД необходимо создавать подсистемы:

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

Рекомендации, которые помогут повысить уровень эффективности БД:

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

Список литературы

  1.  Безруков Д. Универсальные коммерческие СУБД: есть ли перспективы? // Журнал «Открытые системы», 2009. № 02. http://www.osp.ru/os/2009/02/7323462 
    1.  Богатырев Р. На пути к автономным вычислениям // Издательство "Открытые системы". Еженедельник "Computerworld", 2005. Вып. 7. http://www.osp.ru/cw/2005/07/032_1.htm.
    2.  Босуорт Билли. Как разобраться в новых технологиях СУБД. 15.03.2011. [Электронный ресурс]. – Режим доступа: http://www.pcweek.ru/idea/article/detail.php?ID=129238, свободный. – Загл. с экрана.
    3.  Веселов В., Долженков А. Опыт построения XML-СУБД // Журнал «Открытые системы», 2002, №6.
    4.  Взгляд ЕМС на дедупликацию данных при резервном копировании // EMC Corporation Hopkinton Massachusetts. 2008. [Электронный ресурс]. – Режим доступа: http://www.pcweek.ru/upload/iblock/fc2/rus_backup_h4413-data-dedup.pdf, свободный. – Загл. с экрана.
    5.  Вязилов Е.Д. Архитектура, методы и средства Интернет технологий.– М.: УРСС.2009. -512с.
    6.  Вязилов Е.Д., Федорцов А.А. Универсальная модель хранения данных с учетом жизненного цикла объектов // Шестая Всероссийская Открытая конференция «Современные проблемы дистанционного зондирования земли из космоса (Физические основы, методы и технологи и мониторинга окружающей среды, потенциально опасных явлений и объектов). - Москва, ИКИ РАН, 10-14 ноября 2008.
    7.  Дейт К. Дж. Основы будущих систем БД. Третий манифест/ Пер. с англ. Изд. 2-е. М.: Янус, 2004. — 656 с.
    8.  Джексон Джоаб. Базы данных NoSQL будут говорить на одном языке // «Computerworld Россия», 2011. № 20. http://www.osp.ru/cw/2011/20/13010118/. NewSQL берет все лучшее от мира SQL и NoSQL // Журнал «Computerworld Россия», 2011. № 22. http://www.osp.ru/cw/2011/22/13010433/.
    9.  Киви Берд. Хранилище-океан // Издательский дом «КОМПЬЮТЕРРА». Журнал «КОМПЬЮТЕРРА». 05.01.2001. http://old.computerra.ru/online/jack/6527/for_print.html 
    10.  Кодд Э.Ф. Расширение реляционной модели для лучшего отражения семантики. // Издательство "Открытые системы", Журнал «СУБД», 1996, № 5.
    11.  Крил Пол. Дискуссия о будущем БД // "Корпоративный сервер Издательства "Открытые Системы" Еженедельник "Computerworld", 2002, №20. http://www.osp.ru/cw/2002/20/031-1.htm .
    12.  Кузнецов С. Будущие направления исследований в области БД: десять лет спустя. [Электронный ресурс]. – Режим доступа: http://www.citforum.ru/database/articles/future_01.shtml, свободный. – Загл. с экрана.
    13.  Кузнецов С. Универсальность и специализация: время разбивать камни? Системы БД третьего поколения: Манифест // Журнал «Системы управления БД», 1995. № 2. http://www.citforum.ru/database/articles/time_to_break_stones/
    14.  Кузнецов С., Гринев М.. Ландшафт области управления данными: аналитический обзор. Институт системного программирования РАН  [Электронный ресурс]. – Режим доступа: http://www.citforum.ru/database/articles/future_01.shtml, свободный. – Загл. с экрана.
    15.  Муса-Оглы Е., Бессарабов Н. Универсальная модель данных в Oracle // Кубанский Государственный Университет. - 2010. [Электронный ресурс]. – Режим доступа: http://www.interface.ru/home.asp?artId=24052, свободный. – Загл. с экрана.
    16.  Пергаменцев Ю. Проектирование БД на основе универсальной модели данных // "Вега-ЛТД". Материалы конференции "Корпоративные БД 2002". [Электронный ресурс]. – Режим доступа: http://www.citforum.ru/seminars/cbd2002/111.shtml, свободный. – Загл. с экрана.
    17.  Ривкин М. Коммерческие СУБД: эволюция или революция? // Журнал «Открытые системы», 2009. № 02. http://www.osp.ru/os/2009/02/7322713/.
    18.  Стародымов А. Спасители маленьких Windows. 29 августа 2008. [Электронный ресурс]. – Режим доступа: http://www.computerra.ru/online/368297/, свободный. – Загл. с экрана.
    19.  Филиппов В.А. Многозначные СУБД и XML базы данных. – М.: УРСС. Серия: «Перспективные информационные технологии и концепции». – 2008ю – 144 с.
    20.  Черняк Л. MapReduce - будущее БД // Журнал «Открытые системы», 2009, № 02. http://www.osp.ru/os/2009/02/7322603/
    21.  Cooper В. et al., PNUTS: Yahoo!’s Hosted Data Serving Platform. Proc. VLDB Endowment, vol.1, No.2, 2008. http://www.osp.ru/os/2010/10/13006332/
    22.  Erik Meijer and Gavin Bierman. Contrary to popular belief, sql and nosql are really just two sides of the same coin. Microsoft. [Электронный ресурс]. – Режим доступа: http://queue.acm.org/detail.cfm?id=1961297, свободный. – Загл. с экрана.
    23.  Future Directions in DBMS Research // Laguna Beach Report). SIGMOD Record. 1988. V. 18, No. 1,
    24.  Laguna Beach meeting of 1988 [SIGMOD Record 18(1): 17-26. Laguna meetings of 1990 and 1995 [SIGMOD Record 19(4): 6-22, SIGMOD Record 25(1): 52-63] www.acm.org/sigmod/record/issues/9603/lagunita.ps ACM 1996 meeting "Strategic Directions in Database Systems - Breaking Out of the Box", ACM Computing Surveys 28{4}: 764-778 www.acm.org/surveys/sdcr 
    25.  Phil Bernstein, Michael Brodie, Stefano Ceri, David DeWitt, Mike Franklin, Hector Garcia-Molina, Jim Gray, Jerry Held, Joe Hellerstein, H.V. Jagadish, Michael Lesk, Dave Maier, Jeff Naughton, Hamid Piranesh, Mike Stonebraker, and Jeff Ullman. The Asilomar Report on Database Research. http://www.citforum.ru/database/digest/asil_01.shtml. September 1998.
    26.  Stonebraker M. and Cetintemel U. One Size Fits All: An Idea Whose Time has Come and Gone. In Proceedings of the International Conference on Data Engineering (ICDE), 2005.
    27.  Stonebraker M., Bear Chuck, Ḉetintemel Uğur, Cherniack Mitch, Ge Tingjian, Hachem Nabil, Harizopoulos Stavros, Lifter John, Rogers Jennie, and Zdonik Stan. One Size Fits All? – Part 2: Benchmarking Results, 3rd Biennial Conference on Innovative Data Systems Research (CIDR) January 7-10, 2007, Asilomar, California.
    28.  Stonebraker Michael, Samuel Madden, Daniel J. Abadi, Stavros Harizopoulos, Nabil Hachem, Pat Helland. The End of an Architectural Era (It’s Time for a Complete Rewrite). Proceedings of VLDB, 2007, Vienna, Austria.

Перечень вопросов для самопроверки

  1.  Назовите основные направления развития компьютерной техники.
  2.  Какие недостатки имеются у существующих СУБД?
  3.  Какие тенденции развития современных коммерческих СУБД?
  4.  Какие новые модели данных Вы знаете?
  5.  На каких принципах создаются универсальные модели данных?


 

А также другие работы, которые могут Вас заинтересовать

17433. Исследование управляемого выпрямителя на тиристорах 316.34 KB
  Отчет по лабораторной работе №4 Исследование управляемого выпрямителя на тиристорах Цель работы: изучение принципа регулирования выходного напряжения выпрямителя; ознакомление с работой схемы бесконтактного регулируемого выпрямительного устройства Описани
17434. Определение компонентов системного блока 43.5 KB
  Лабораторная работа Определение компонентов системного блока Краткие теоретические сведения 1. При подаче питания на процессор происходит его обращение к микросхеме ПЗУ и запуск программы инициализирующей работу компьютера. В этот момент на экране монитора набл...
17435. Ознайомлення з роботою широтно-імпульсного модулятора 248.5 KB
  Мета роботи :Ознайомлення з роботою широтноімпульсного модулятора. Теоретичні відомості Широтноімпульсна модуляція ШІМ англ. Pulsewidth modulation PWM наближення бажаного сигналу багаторівневого або неперервного до дійсних бінарних сигналів таким чином щоби в середнь...
17436. Ознайомлення з принципом роботи частотомірів 701 KB
  Мета роботи Ознайомлення з принципом роботи частотомірів Теоретичні відомості Вимірювання частоти та періоду сигналів по методу прямого перетворення базується на реалізації двох операцій: перетворенні вимірюваного сигналу в послідовність дискретних імпульсів ц
17437. Ознайомлення з принципом роботи аналого-цифрових перетворювачів порозрядного зрівноваження 402 KB
  Мета роботи :Ознайомлення з принципом роботи аналогоцифрових перетворювачів порозрядного зрівноваження. Теоретичні відомості Аналогоцифрове перетворення використовується для обробки зберігання або передачі аналогових сигнал в цифровій формі. Наприклад швидкі в
17438. Ознайомлення з роботою систем автоматичного регулювання зі зворотнім зв’язком 198 KB
  Мета роботи:Ознайомлення з роботою систем автоматичного регулювання зі зворотнім зв’язком. Теоретичні відомості Значні обчислювальні та логічні можливості ЕОМ визначають їх використання для керування автоматизованими об’єктами. Інтегральні пристрої цифрового опр
17439. Поняття Колективного несвідомого та архетипу в концепції К. Юнга 23.87 KB
  Поняття Колективного несвідомого та архетипу в концепції К. Юнга Аналітична психологія один з видів аналізу особистості засновником якого є швейцарський психолог і культуролог К. Г. Юнг. Цей напрямок близький до психоаналізу однак має істотні відмінності. Його
17440. Основні етапи розвитку позитивізму 20.68 KB
  Основні етапи розвитку позитивізму Незвичайність новітніх наукових відкриттів гостро поставила питання про природу наукових понять співвідношення чуттєвого і раціонального моментів пізнання емпіричного і теоретичного знання про істину та її критерії законом...