Аналитическая обработка данных

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

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

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

55. Базы данных и Internet?

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

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

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

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

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

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

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

56. Проблемы и решения?

В заключение считаем целесообразным привести требования и рекомендации [7] к «новым» методам и инструментам проектирования БД, практически подтверждающие, что все новое есть в той или иной степени забытое старое.

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

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

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

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

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

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

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

57. Физическая структура данных в dBase (структура основного файла базы данных (тип DBF), структура memo-файла (тип FPT), структура индексного файла (тип IDX), структура компактного индексного файла (тип IDX))?