Курносов Ю. В., Конотопов П. Ю

Вид материала

Документы

Содержание Навигационные базы данных Объектные базы данных Объектно-реляционные базы данных Хранилища данных Информационные ресурсы распределенных телекоммуникационных сетей Базы знаний и моделей

Подобный материал:

• Курносов Ю. В., Конотопов, 1160.74kb.
• Договор № на оказание услуг, 160.36kb.
• Курносов Владимир Анатольевич Волжск 2007 Оглавление Введение 3-5 Глава I. Юродство, 355.39kb.
• Литература по курсу «История экономики и экономических учений» Основная   История мировой, 54.21kb.
• Теория и история финансовых кризисов в России 08. 00. 01 экономическая теория (экономическая, 450.88kb.

НАВИГАЦИОННЫЕ БАЗЫ ДАННЫХ


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

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

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


ОБЪЕКТНЫЕ БАЗЫ ДАННЫХ


Мы уже рассмотрели реляционные и навигационные БД, но ни те, ни другие не были признаны нами в качестве средства хранения данных, отвечающего потребностям ИАР и сущности системного подхода (это не значит, что они вообще не могут быть эффективно использованы при ведении ИАР). Еще одной парадигмой построения баз данных, наследующей свойства навигационных баз данных, является парадигма объектных баз данных. Парадигма объектных баз данных по своей сути близка идеологии имитационного моделирования: для описания объектов учета такие БД используют комплекс компонент описания, обеспечивающий учет не только атрибутов объекта, но и системных связей, их параметров, правил комбинирования, проверки допустимости значений и так далее. В классическом варианте объектных БД объекты идентифицируются по именному принципу, их свойства определяются набором общих (свойственных родительскому классу) и частных (свойственных данному экземпляру объекта или производному классу) характеристик. Чрезвычайно полезными механизмами, введенными в модель объектных БД, являются механизмы наследования и переопределения свойств объектов и классов. Чтобы проиллюстрировать этот механизм, приведем следующие утверждения в «объектном стиле»: «Книга — есть документ, отличающийся тем, что носитель символьных данных объединен в блок. Свиток — есть документ, отличающийся тем, что носитель символьных данных представляет собой скрученную в рулон широкую ленту». Как видим, понятия введены на основе использования ранее введенных понятий-классов верхнего уровня «документ» и «носитель символьных данных», за счет чего упрощено описание производных понятий (а термины и понятия, естественно, могут выступать в роли объектов хранения).

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


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

Еще одним полезным свойством объектных технологий является то, что данные, описывающие объект учета, могут быть сопровождены и информацией об интерфейсе их представления. Например, в качестве одного из атрибутов при описании микросхемы в системах автоматизированного проектирования (САПР) использовалось описание ее графического начертания. Однако это было только начало, поскольку метод отображения начертания был реализован в оболочке САПР. Позже, за счет унификации языков программирования и графических интерфейсов операционных систем, стало возможным и совместное хранение данных с описаниями методов их отображения и обработки. Это позволяет при получении исполнительной системой комбинированного блока данных и формализованных описаний алгоритмов их обработки, воспользоваться теми процедурами, которые позволяют корректно обрабатывать и отображать именно этот экземпляр или класс данных. То есть, на момент получения данных их потребитель может в принципе не располагать методами и программами обработки данного класса данных, а все изменения в методах обработки данных, автоматически станут доступны их потребителям. Такая идеология рассматривается как наиболее перспективная, в ее русле разработаны языки гипертекстовой разметки SGML, XML, HTML, MathML, языки программирования Java Script, Java и ряд иных языков программирования и управления представлением данных, разработанных в последние годы.

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

Жаль... А ведь как привлекательна идея «данные, модели и методы в одном флаконе»! Так и хочется спросить: «Девушка, а у вас такого же, но с перламутровыми пуговицами не найдется?». Что ж, Технология — девушка запасливая: есть у нее и «с перламутровыми»...


Поиски путей согласования системного подхода с компьютерными технологиями хранения, поиска и обработки данных привели к разработке еще двух технологий: объектно-реляционной модели организации хранения данных и модели гетерогенных хранилищ данных (или хранилищ данных — Data Warehouse). Однако по порядку...


ОБЪЕКТНО-РЕЛЯЦИОННЫЕ БАЗЫ ДАННЫХ


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

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

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


ХРАНИЛИЩА ДАННЫХ


Идея хранилищ данных (Data Warehouse) впервые была предложена Б. Инмоном. Сейчас аналитикам многих западных компаний уже трудно представить, как они обходились с дезинтегрированными ресурсами различных баз данных, созданных в различные периоды времени в разных организациях с применением различных технологических платформ... Однако теперь, после внедрения технологии хранилищ данных, столь удачно сочетающейся с концепцией оперативной аналитической обработки данных (OLAP), эти различия перестали быть ощутимыми для потребителей. Хранилища данных прочно заняли одно из почетных мест в инструментарии аналитика. Практика построения хранилищ данных доказала необходимость переноса идеологии виртуальных таблиц, реализованной в реляционных базах данных, на крупномасштабные приложения и развития ее до технологии витрин данных (Data Mart), позволяющих сделать прозрачным доступ к данным, хранимым в технологически неоднородных средах.

За прошедшее десятилетие было разработано около десятка различных архитектур корпоративных информационных систем на основе хранилищ и витрин данных, предназначенных для поддержки принятия решений и аналитических исследований. В создании крупных хранилищ данных лидируют такие фирмы, как IBM, Informix, NCR, Oracle, Red Brick, SAS, Sybase.

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

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


ИНФОРМАЦИОННЫЕ РЕСУРСЫ РАСПРЕДЕЛЕННЫХ ТЕЛЕКОММУНИКАЦИОННЫХ СЕТЕЙ


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


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

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

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


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

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


БАЗЫ ЗНАНИЙ И МОДЕЛЕЙ


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

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

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


Логические модели представления знаний формируются из следующих компонентов:

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

Сетевые модели представления знаний формируются из следующих компонентов:

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

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