3.8. Хранилища данных и базы знаний
Основными идеями, лежащими в основе концепции хранилища данных, являются:
• интеграция разъединенных детализированных данных, которые описывают некоторые конкретные факты, свойства, события и т.д., в едином хранилище;
• разделение наборов данных и приложений на используемые для оперативной обработки и применяемые для решения задач анализа.
В начале восьмидесятых годов прошлого века в период бурного развития регистрирующих ИС возникло понимание ограниченности возможности применения БД для целей анализа данных и построения на их основе систем поддержки и принятия решений.
Регистрирующие системы создавались для автоматизации рутинных операций по ведению бизнеса — выписка счетов, оформление договоров, проверка состояния склада и т.д. Пользователями таких систем был в основном линейный персонал. Основные требования, которые предъявлялись к регистрирующим системам, — обеспечение транзакционности вносимых изменений и максимизация скорости их выполнения. Именно эти требования определили выбор реляционных СУБД и соответствующей модели представления данных в качестве основных используемых технических решений при построении регистрирующих систем.Для менеджеров и аналитиков требовались системы, которые бы позволяли:
• анализировать информацию во временном аспекте;
• формировать произвольные запросы к системе;
• обрабатывать большие объемы данных;
• интегрировать данные из различных регистрирующих систем.
Очевидно, что регистрирующие системы не удовлетворяли ни
одному из вышеуказанных требований. В регистрирующей системе информация актуальна только на момент обращения к базе данных, в следующий момент времени по тому же запросу можно получить совершенно другой результат. Интерфейс регистрирующих систем рассчитан на проведение жестко определенных операций и возможности получения результатов на нерегламентированный запрос сильно ограничены. Возможность обработки больших массивов данных также мала из-за настройки СУБД на выполнение коротких транзакций и неизбежного замедления работы остальных пользователей.
Ответом на возникшую потребность стало появление новой технологии организации баз данных — технологии хранилищ данных.
Хранилище данных (ХД) — это система, содержащая непротиворечивую интегрированную предметно-ориентированную совокупность исторических данных крупной корпорации или иной организации с целью поддержки принятия стратегических решений [31].
Информационные ресурсы ХД формируются путем извлечения моментальных снимков БД операционной ИС организации и различных внешних источников. ХД собирает, очищает, загружает, агрегирует, хранит данные и предоставляет к ним быстрый доступ.
При эффективном использовании ХД может быть одним из основных источников достоверной информации для руководителей и специалистов всех подразделений организации. Это обеспечит согласованность, своевременность и обоснованность принятия управленческих решений, облегчит выверку обязательной отчетности, выпуск управленческой отчетности.
О хранилище данных можно говорить как о совокупности источника данных (структура связанных таблиц — это и есть хранилище), где собирается информация для дальнейшей обработки, и процедур извлечения, преобразования и загрузки данных (ETL — extraction, transformation, loading).
Физически хранилище данных представляет собой реляционную базу данных. Однако в отличие от БД корпоративных информационных систем (КИС) хранилище имеет принципиально иную структуру.
Например, хранилище содержит агрегированные данные, вычисляемые показатели, хранит исторические накопленные данные по конкретным объектам (период хранения информации — длительный). В отличие от ХД базы данных КИС содержат детализированные данные, период их хранения относительно короткий.Классическая архитектура ХД состоит из следующих элементов: реляционная, многомерная, или гибридная БД, средства извлечения, очистки и загрузки данных, средства визуализации данных и генерации отчетов (OLAP-клиенты). Реляционная БД строится по архитектуре «звезда», в которой с одной таблицей фактов связаны несколько таблиц измерений (справочников), или «снежинка», отличающаяся наличием иерархических справочников. Это делается для оптимизации скорости выполнения объемных запросов (в последнее время появилось много статей, критикующих этот подход за его упрощенность и невозможность решения исключительно в рамках «звезды» всего многообразия задач ХД). В многомерной БД строятся «кубы» — специфические структуры, аналогичные по смыслу реляционным «снежинкам», но хранящие вычисленные агрегаты на всех пересечениях измерений.
Концептуально модель хранилища данных можно представить в виде схемы, показанной на рис. 3.20.
Данные из различных источников помещаются в ХД, а описания этих данных в репозитории метаданных. Конечный пользователь, используя различные инструменты (средства визуализации, построения отчетов, статистической обработки и т.д.) и содержимое репозитория, анализирует данные в хранилище. Результатом его деятельности является информация в виде готовых отчетов, найденных скрытых закономерностей, каких-либо прогнозов. Так ,как средства работы конечного пользователя с хранилищем данных могут быть самыми разнообразными, то теоретически их выбор не должен влиять на его структуру и функции его поддержания в актуальном состоянии.
Рис. 3.20. Концептуальная модель хранилища данных |
Особенности хранилища данных связаны с особенностями задач, на решение которых оно ориентировано: аналитическую оперативную обработку информации и, как следствие, сложные для оперативных баз данных БС^Ь-запросы.
На основе ХД создаются подмножества данных — ОЬАР-кубы, многомерные иерархические структуры данных, содержащие множество признаков:
• дата/время (период времени, к которому относятся данные);
• сфера деятельности (бизнес-сфера, результат), к которой относятся данные;
• субъект управления (лицо, принимающее решение — ЛПР);
• вид ресурса и др.
Эти признаки позволяют агрегировать данные путем произвольного сочетания признаков и вычисления статистических оценок. В результате анализа информации создается новое знание, полезное для целей управления.
Данные в хранилище попадают из оперативных систем (ОЬ ГР- систем), которые предназначены для автоматизации бизнес-процессов. Кроме того, хранилище может пополняться за счет внешних источников, например статистических отчетов.
На вопрос «Зачем строить хранилища данных — ведь они содержат заведомо избыточную информацию, которая и так присутствует
в БД или файлах оперативных систем?», можно ответить, что анализировать данные оперативных систем напрямую невозможно или очень сложно. Это объясняется различными причинами, в том числе разрозненностью данных, хранением их в форматах различных СУБД и в разных «уголках» корпоративной сети. Но даже если на предприятии все данные хранятся на центральном сервере БД, аналитик почти наверняка не разберется в их сложных, подчас запутанных структурах.
OLAP (On-line Analytical Processing) не представляет собой необходимый атрибут хранилища данных, но он все чаще и чаще применяется для анализа накопленных в этом хранилище сведений.
Компоненты, входящие в типичное хранилище, представлены на рис. 3.21.
Построение отчетов |
Перенос и трансформация данных |
Реляционное хранилище |
Оперативные базы данных |
ISÈ |
OLAP- хранилище |
OLAP- анализ
Репозиторий
----- ». потоки данных
потоки метаданных
Рис. 3.21. Структура хранилища данных
Оперативные данные собираются из различных источников, очищаются, интегрируются и складываются в реляционное хранилище. При этом они уже доступны для анализа при помощи различных средств построения отчетов. Затем данные (полностью или частично) подготавливаются для OLAP-анализа. Они могут быть загружены в специальную БД OLAP или оставлены в реляционном хранилище. Важнейшим его элементом являются метаданные, т.е. информация о структуре, размещении и трансформации данных.
Благодаря им обеспечивается эффективное взаимодействие различных компонентов хранилища.
Таким образом, задача хранилища — предоставить «сырье» для анализа в одном месте и в простой, понятной структуре.
Есть и еще одна причина, оправдывающая появление отдельного хранилища. Сложные аналитические запросы к оперативной информации тормозят текущую работу компании, надолго блокируя таблицы и захватывая ресурсы сервера.
Основными причинами, побуждающими организации внедрять хранилища данных, являются:
• необходимость выполнения аналитических запросов и генерации отчетов на не задействованных основными ИС вычислительных ресурсах;
• необходимость использования моделей данных и технологий, ускоряющих процесс выполнения запросов и подготовки отчетности, но не предназначенных для обработки транзакций;
• создание среды, в которой даже относительно небольших знаний основ СУБД достаточно для создания запросов и подготовки отчетов, что означает сокращение времени, требуемого от персонала ИТ-отдела для сопровождения системы;
• создание источника с предварительно очищенной информацией;
• упрощение процесса подготовки отчетов на основе информации из нескольких транзакционных систем и/или внешних источников данных и/или данных, используемых исключительно для генерации отчетов;
• создание выделенного источника в тех случаях, когда возможности операционной системы не соответствует требуемому бизнесом сроку хранения данных и/или необходимо иметь возможность подготовки отчетов на определенные моменты времени в прошлом;
• защита конечных пользователей от необходимости в какой бы то ни было степени вникать в структуру и логику работы БД регистрирующей системы.
Переход от данных к знаниям — логическое следствие развития и усложнения информационно-логических структур, обрабатываемых с помощью компьютера. Активно развивающейся областью использования современных компьютеров является создание баз знаний (БЗ) и их применение в различных областях науки и техники.
Знания — это закономерности предметной области (принципы, связи, законы), полученные в результате практической деятельности и профессионального опыта, позволяющие специалистам ставить и решать задачи в этой области.
Знания можно рассматривать как стратегическую информацию, необходимую для формирования цели и построения кинематической траектории, а информацию — как оперативные знания, используемые системой в динамическом процессе.
Под базой знаний (БЗ) понимают совокупность знаний, накопленных человеком в определенной предметной области, выраженную с помощью некоторого языка представления знаний.
Для создания БЗ разрабатываются соответствующие программные средства. Они позволяют обеспечивать загрузку, актуализацию, поддержание в достоверном состоянии, расширение БЗ, формирование, обработку и включение новых знаний, соответствующих текущей ситуации. Базы знаний составляют основу экспертных систем при подготовке управленческих решений.
Экспертные системы (ЭС) — прикладные системы искусственного интеллекта, в которых база знаний представляет собой формализованные эмпирические знания высококвалифицированных специалистов (экспертов) в какой-либо узкой предметной области, а также может содержать результатную информацию, полученную при решении экономических задач.
Структура экспертной системы и ее компоненты представлены на рис. 3.22.
Рис. 3.22. Структура экспертной системы |
• База знаний предназначена для хранения экспертных знаний о предметной области, которые используются при решении задач экспертной системой. База знаний состоит из набора фреймов и правил-продукций. Фрейм — это структура данных, состоящая из слотов (полей). Фреймы используются в базе знаний для описания объектов, событий, ситуаций, прочих понятий и взаимосвязей между ними. Правила используются в базе знаний для описания отношений между объектами, событиями, ситуациями и прочими понятиями. На основе отношений, задаваемых в правилах, выполняется логический вывод. В условиях и заключениях правил присутствуют ссылки на фреймы и их слоты.
• База данных предназначена для временного хранения фактов или гипотез, являющихся промежуточными решениями или результатом общения системы с внешней средой, в качестве которой обычно выступает человек, ведущий диалог с экспертной системой.
• Машина логического вывода — механизм рассуждений, оперирующий знаниями и данными с целью получения новых данных из знаний и других данных, имеющихся в рабочей памяти. Для этого обычно используется программно реализованный механизм дедуктивного логического вывода (какая-либо его разновидность) или механизм поиска решения в сети фреймов или семантической сети. Машина логического вывода может реализовывать рассуждения в виде дедуктивного вывода (прямого, обратного, смешанного), нечеткого вывода, вероятностного вывода, поиска решения с разбиением на последовательность подзадач, поиска решения с использованием стратегии разбиения пространства, поиска с учетом уровней абстрагирования решения или понятий, с ними связанных, монотонного или немонотонного рассуждения, рассуждений с использованием механизма аргументации, ассоциативного поиска с использованием нейронных сетей и др.
• Подсистема общения служит для ведения диалога с пользователем, в ходе которого ЭС запрашивает у пользователя необходимые факты для процесса рассуждения, а также дает возможность пользователю в какой-то степени контролировать и корректировать ход рассуждений экспертной системы.
• Подсистема объяснений необходима для того, чтобы дать возможность пользователю контролировать ход рассуждений и, может быть, учиться у ЭС. Если нет этой подсистемы, ЭС выглядит для пользователя как «вещь в себе», решениям которой можно либо верить, либо нет. Пользователь выбирает последнее, и такая ЭС не имеет перспектив для применения.
• Подсистема приобретения знаний служит для корректировки и пополнения базы знаний. В простейшем случае это — интеллектуальный редактор базы знаний, в более сложных экспертных системах — средства для извлечения знаний из баз данных, неструктурированного текста, графической информации и т.д.
Среди специализированных систем, основанных на знаниях, наиболее значимы экспертные системы реального времени, или динамические экспертные системы. На их долю приходится 70% этого рынка.
Классы задач, решаемых экспертными системами реального времени, таковы: мониторинг в реальном масштабе времени, системы управления верхнего уровня, системы обнаружения неисправностей, диагностика, составление расписаний, планирование, оптимизация, системы — советчики оператора, системы проектирования.
Еще по теме 3.8. Хранилища данных и базы знаний:
- 6.3. CRM и хранилища данных
- 5.2. БАЗЫ ДАННЫХ
- Базы данных по контрактам.
- 2. БАЗЫ ДАННЫХ
- 2.2. Нормализация файлов базы данных
- 2.1. Принципы построения и этапы проектирования базы данных
- 18.5. Государственная пошлина за совершение уполномоченным федеральным органом исполнительной власти действий по официальной регистрации программы для электронных вычислительных машин, базы данных и топологии интегральной микросхем
- Размеры государственной пошлины за совершение уполномоченным федеральным органом исполнительной власти действий по официальной регистрации программы для электронных вычислительных машин, базы данных и топологии интегральной микросхемы
- 4.4 Результативность и эффективность файлов данных (картотек, массивов данных)
- 7.3. ПРИОБРЕТЕНИЕ И ФОРМАЛИЗАЦИЯ ЗНАНИЙ 7.3.1. ЭЛЕМЕНТЫ ТЕХНОЛОГИИ ПРИОБРЕТЕНИЯ ЗНАНИЙ
- II Главные возражения против антропологических данных. — Метод исследования. — Научные предположения. — Разногласие данных. — Признаки преступности, даже у честных людей. — Историческая и антропологическая изменчивость понятия преступления. Его определение. — Преступный тип. — Происхождение и природа преступности.
- 7.3.2. МЕТОДЫ ПРИОБРЕТЕНИЯ ЗНАНИЙ
- 4.5. Момент определения налоговой базы 4.5.1. Общий порядок определения налоговой базы
- 7.2. МОДЕЛИ ПРЕДСТАВЛЕНИЯ ЗНАНИЙ
- Информационные системы с базами знаний
- 4.2.2. Классификация методов представления знаний
- 3.3.3 Передача знаний
- 3.4.3. СТРУКТУРИЗАЦИЯ ДАННЫХ И МЕТАДАННЫЕ
- 87. ОБЩАЯ МЕТОДИКА ФОРМИРОВАНИЯ ЗНАНИЙ
- ИНФОРМАЦИОННЫЙ ПРОЦЕСС ПРЕДСТАВЛЕНИЯ ЗНАНИЙ