Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
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) во многом совпадают, это:
Установка многих СУБД представляет собой не очень простую задачу, поэтому установку СУБД для промышленной эксплуатации необходимо поручать опытному администратору, иначе через какое-то время могут возникнуть проблемы с выделенной памятью, например, для хранения таблиц, обработки даны и т.п. Поэтому этот процесс должен выглядеть в стиле "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. Облачные системы, как правило, состоят из множества операционных компонентов:
Традиционные устройства хранения ничего не знают о размещенных в них БД, не имеют сведений, которые помогли бы определить конкретные столбцы и строки, содержавшиеся в запросе. Компания 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. Облачные системы, как правило, состоят из множества операционных компонентов:
Традиционные устройства хранения ничего не знают о размещенных в них БД, не имеют сведений, которые помогли бы определить конкретные столбцы и строки, содержавшиеся в запросе. Компания 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)
где:
СУБД 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/) - это высоко-масштабируемое, автоматически восстанавливающее согласованность данных, распределенное, основанное тоже на колончатой модели данных ключ-значение хранилище. Основными единицами модели данных для этой СУБД являются:
СУБД 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 каналы. Виртуальная частная сеть строится на основе программно- аппаратных средств соответствующих международным стандартам и стандартам РФ по криптозащите данных и межсетевым экранам. Программно-аппаратные средства системы безопасности обеспечивают:
Большинство традиционных средств резервного копирования обеспечивают многократное копирование одних и тех же данных, что приводит к увеличению объема данных в резервных копиях в 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 |
В последние годы стали много говорить о создании единого информационного пространство (ЕИП). Понимание этого термина у многих разное. Одни считают, что Интернет уже создает ЕИП, другие - ЕИП это единое окно доступа к информационным ресурсам и сервисам через веб-портал. К сожалению, это далеко не так, т.к. в этих случаях использовать полученную информацию от различных приложений можно только с экрана. А автоматически включить полученную информацию в другое приложение очень трудно - только путем предварительной договоренности о месте записи файла и его структуре. То есть основным критериями ЕИП являются:
При разработке ЕИП необходимо широкое использование:
Развитие моделей данных
Создаваемые в разных организациях БД не имеют единой концептуальной основы и по большому счету не могут взаимодействовать друг с другом. Использовать вместе заложенную в них информацию очень трудно. Поэтому необходимо развитие универсальных моделей данных, стандартизации представления, обмена данными и метаданными [7, 17].
В настоящее время наблюдается три направления развития моделей данных:
Язык 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 – Схема УМД на основе отдельного хранения сведений
о структурных единицах БД
Сенсорные сети
Перспективным направлением развития информационно-измерительных систем (ИИС) с БД является создание сенсорных сетей различного типа датчиков. Сенсорные сети состоят из очень большого числа дешевых устройств, каждое из которых является источником данных, выдающим значение некоторого показателя, например, координаты объекта или температуру внешней среды. Сенсоры позволяют измерять характеристики звуковых, электрических, магнитных, оптических, механических, термических, радиационных, биологических, химических явлений. Можно создать акустическую картину окружающей обстановки, позволяя по звуку определять состояние объектов. Эти устройства, как правило, обладают автономными источниками питания. Сенсорное устройство должно передать в родительский узел результаты измерений своих датчиков или транслировать запрос узлам-потомкам. Сенсорные сети предполагают наличие в каждом узле сети микропроцессора с подсоединенными средствами связи. Стоит задача очень быстро создавать такие сети, подключать или удалять вышедшие из строя сенсоры, датчики. Это является аналогом той поддержки, которую ОС выполняет по отношению к аппаратуре, опознавая все доступные устройства. Функциями систем поддержки сенсорных сетей являются:
Требования к такой системе включают:
Вся сенсорная сеть представляется как огромная распределенная БД, каждый узел которой (сенсор) хранит крохотный объем данных, который сенсор отдает в соответствии с регламентом передачи данных. При необходимости перейти на другой режим передачи данных посылается запрос в систему.
Большое число сенсоров, мобильность и прерывающаяся связность сенсоров со встроенными процессорами требуют масштабируемости, универсальной структуры данных. Такие системы имеют пользовательский интерфейс, но у них не должно быть администратора БД, они должны быть самоуправляемыми, безопасными и надежными. Требуется такой способ управления сенсорными данными, который обеспечивал бы к ним доступ в реальном времени без потребности массовой передачи данных в центральные узлы. Современные сенсорные сети работают по IP-протоколу.
Измерительные системы с сетью сенсоров подключаются к контроллерам, Web-серверам для управления и мониторинга процесса измерений, а также БД для хранения накопленной информации. По мере роста интеллекта сетей сенсоры будут включаться и выключаться по инициативе системы. В результате упрощается обмен цифровой информацией между объединенными в сеть сенсорами и компьютером, на котором находится БД. При изменении конфигурации датчиков сети по причине выхода из строя сенсора или его отключения от сети БД не надо перестраивать.
При создании крупных ИИС, включающих сотни, тысячи и более датчиков, сенсоров, измеряющих различные параметры среды, с разной дискретностью, возникает проблема хранения полученных данных в одной БД – либо создавать множество таблиц, либо терять пространство памяти на отсутствующие в данный момент измерения отдельных параметров. В настоящее время структуры данных разрабатываются для каждого прибора (измерительного комплекса) отдельно. Такой подход требует переработки программного обеспечения при удалении, добавлении нового датчика. Интеграция ИИС усложняется, потому что нет типовой структуры данных. Если данные хранить в универсальной модели данных (УМД), а все ИИС будут представлять информацию в этой модели данных, то интеграция таких систем существенно упростится. Структура данных в УМД для решения этой задачи будет выглядеть с.о.:
Технологией, обеспечивающей взаимодействие сенсоров с БД, является язык XML, который обеспечивает обмен данными вне зависимости от аппаратных и программных платформ. Внедрение стандартов на объединение, управление, взаимодействие и использование данных, собранных от различных датчиков, использование XML технологий позволит значительно увеличить как масштабируемость таких средств, так и упростить их настройку. Этому способствовало появление стандартов Sensor Model Language (SensorML, http://vast.uah.edu/SensorML/) и Transducer Markup Language (TML).
Возможности сенсорных сетей должны использоваться при мониторинге окружающей среды, в промышленности при создании самоуправляемых роботов и возведении интеллектуальных домов. Администратор будет только наблюдать за работой сенсорных сетей, его участие может потребоваться только при принятии критически важных решений. Они свяжут в единое информационное пространство приборы и оборудование и, таким образом, обеспечат автоматический сбор данных, их предварительный анализ, прогноз и выдачу сведений о воздействиях и рекомендаций без личного участия персонала. Эти средства оповестят службы экстренного реагирования. Получив это предупреждение, персонал может скорректировать параметры технологического процесса.
Технологии обслуживания нового поколения
Основными проблемами современных БД являются наличие неполной или противоречивой информации; отсутствие средств повышения достоверности информации; схем обработки информации и получения соответствующих целевых показателей. БД пока не всегда эффективны, уязвимы и слишком дороги. Автоматические системы сбора сведений требуют применения эффективных аналитических средств, консолидации данных.
Современные технологии, создаваемые с уклоном на комплексное информационное обслуживание, ориентируются на работу с распределенными БД. Средства интеграции данных по определённому регламенту осуществляют накопление информации. Затем эта информация преобразуется в формат обработки данных. Далее в соответствии с заранее настроенными процедурами данные консолидируются, агрегируются и представляются в виде карт, таблиц, диаграмм, графиков.
Несмотря на имеющиеся достижения в области разработки информационно-коммуникационных технологий основными проблемами при обслуживании пользователей являются: широкое разнообразие и недостаточная стандартизация форм выдачи; низкий уровень автоматизации обработки данных в части мониторинга выполнения различных этапов обработки данных; отсутствие выдачи сведений о воздействиях и рекомендаций по уменьшению или предотвращению убытков.
Недостатками обслуживания пользователей являются:
В зависимости от оперативности доведения и уровня обобщения данных (наблюдения, анализы, прогнозы и обобщения) получаемая продукция для информационного обслуживания представлена на рис.4.
Рисунок 4 - Схема развития информационного обслуживания
Технология информационного обслуживания включает:
Состав сервисов должен включать:
Информация пользователям представляется в виде метаданных, данных и знаний. Каждый тип информации требует разработки дополнительных функций. Основными функциями для работы с метаданными являются:
Для работы с данными используются следующие функции:
Пользователь, кроме получения данных и метаданных должен:
Выводы
Практически произошел массовый переход на работу с БД с использованием веб-технологий. Уже сейчас востребованы решения, которые позволяют работать со всеми типами данных (фактографической и пространственной информацией, изображениями, видео, текстами) в рамках обычной транзакционной системы.
Тенденции развития БД сводятся к интеграции данных и приложений, работающих с этими данными, широкому использованию этих данных для поддержки решений в различных областях экономической деятельности. Новая волна развития в использовании БД связана с применением современных технологий - web–сервисов, программного обеспечения как сервис - SaaS, унифицированных коммуникаций, защиты данных, контроля доступа к сетям, виртуализации, облачных технологий. Будущие изменения будут вызваны подключением к БД многочисленных физических объектов (различных сенсоров, датчиков, ИИС и т.п.), которые будут иметь IP-адрес.
СУБД третьего поколения должны:
Реализацию этих тенденций стимулируют технологические инновации, в числе которых появление многоядерных архитектур, резкое снижение стоимости дисковой и оперативной памяти, широкое распространение твердотельных (SSD) и флэш-накопителей, увеличение пропускной способности сетевых соединений (в том числе беспроводных), рост популярности мобильных устройств и т.д. Сегодня данные находятся в географически распределенных системах, а требования к скорости доступа к ним постоянно ужесточаются. Аналитическая обработка все чаще выполняется в реальном времени. Появляется потребность в высокоскоростной потоковой обработке данных, которые загружаются в БД. Такие задачи возникают при мониторинге инфраструктуры системы, управлении сенсорами и т.д. Все это позволяет виртуализировать ресурсы БД и гибко маневрировать ими как с целью повышения отказоустойчивости, так и для балансировки нагрузки.
Усложняется управление реляционными БД и его трудоемкость за счет увеличения размеров и количества таблиц. Процесс индексирования создает разрыв по времени между вводом данных и тем моментом, когда они становятся доступны для запросов.
Для крупных БД необходимо создавать подсистемы:
Рекомендации, которые помогут повысить уровень эффективности БД:
Список литературы
Перечень вопросов для самопроверки