CC BY
246
Секция
«ИНФОРМАЦИОННО-УПРАВЛЯЮЩИЕ СИСТЕМЫ»
УДК 669.713.7
А. А. Демченко Научный руководитель - В. В. Молоков Сибирский государственный аэрокосмический университет имени академика М. Ф. Решетнева, Красноярск
ОЬЛР-ТЕХНОЛОГИЯ АНАЛИЗА ДАННЫХ
Рассмотрены 12 правил ОЬЛР-систем описанные Эдгаром Коддом в 1993 г., которым должны удовлетворять продукты, предоставляющие возможность выполнения оперативной аналитической обработки.
В настоящее время очень много информации опубликовано о Olap технологиях. Информационные системы масштаба предприятия, содержат приложения, предназначенные для комплексного многомерного анализа данных, их динамики, тенденций и т. д. Такой анализ в конечном итоге призван содействовать принятию решений. Часто такие эти системы называются системами поддержки принятия решений.
Системы поддержки принятия решений обычно обладают средствами предоставления пользователю агрегатных данных для различных выборок из исходного набора в удобном виде для восприятия и анализа. Как правило, такие агрегатные функции составляют многомерный (не реляционный) набор данных, оси которого содержат параметры, а ячейки - зависящие от них агрегатные данные - причем храниться такие данные могут и в реляционных таблицах, но в данном случае мы говорим о логической организации данных, а не о физической реализации их хранения). Вдоль каждой оси данные могут быть организованы в виде иерархии, представляющей различные уровни их детализации. Благодаря такой модели данных пользователи могут формулировать сложные запросы, генерировать отчеты, получать подмножества данных.
Технология комплексного многомерного анализа данных получила название OLAP (On-Line Analytical Processing).
OLAP - это ключевой компонент организации хранилищ данных. Концепция OLAP была описана в 1993 году Эдгаром Коддом, известным исследователем баз данных и автором реляционной модели данных. Сегодня термин OLAP - это понятие для различных техно -логий, включая системы поддержки принятия решений, Business Intelligence и управленческие информационные системы. Также Кодд опубликовал труд под названием «OLAP для пользователей-аналитиков: каким он должен быть». В нем он изложил основные концепции оперативной аналитической обработки и определил 12 правил, которым должны удовлетворять продукты, предоставляющие возможность выполнения оперативной аналитической обработки [1].
- Концептуальное многомерное представление (Multi-Dimensional Conceptual View). Многомерная концептуальная схема или пользовательское представление облегчают моделирование и анализ так же,
впрочем, как и вычисления. Концептуальное представление модели данных должно позволять аналитикам выполнять интуитивные операции анализа «вдоль и поперек» (slice and dice), вращения (rotate) и размещения (pivot) направлений консолидации.
- Прозрачность (Transparency). Пользователь не должен знать о том, какие средства используются для хранения и обработки данных, как данные организованы и откуда берутся. Вне зависимости от того, является OLAP-продукт частью средств пользователя или нет, факт должен быть прозрачен пользователю.
- Доступность (Accessibility). Пользователь-аналитик OLAP должен иметь возможность выполнять анализ, базирующийся на общей концептуальной схеме, содержащей данные всего предприятия в реляционной БД, также как и данные из старых наследуемых БД, на общих методах доступа и на общей аналитической модели. Это значит, что OLAP должен предоставлять свою собственную логическую схему для доступа в гетерогенной среде БД и выполнять соответствующие преобразования, требующиеся для обеспечения единого, согласованного и целостного взгляда пользователя на информацию.
- Постоянная производительность при разработке отчетов (Consistent Reporting Performance). Производительность формирования отчетов не должна существенно падать с ростом количества измерений и размеров базы данных.
- Клиент-серверная архитектура (Client-Server Architecture). OLAP-продукты должны работать в среде клиент-сервер. Поэтому представляется необходимым, чтобы серверный компонент аналитического инструмента был настолько «интеллектуальным» и обладал способностью строить общую концептуальную схему на основе обобщения и консолидации различных логических и физических схем корпоративных БД для обеспечения эффекта прозрачности. Также необходимо чтобы различные клиенты могли присоединяться к серверу с минимальными затруднениями и интеграционным программированием.
- Общая многомерность. Каждое измерение должно применяться безотносительно своей структуры и операционных способностей. Дополнительные операционные способности могут предоставляться выбранным измерениям, и, поскольку измерения
Секция «Информационно-управляющие системы»
симметричны, отдельно взятая функция может быть предоставлена любому измерению. Базовые структуры данных, формулы и форматы отчетов не должны смещаться в сторону какого-либо измерения.
- Динамическое управление разреженными матрицами (Dynamic Sparse Matrix Handling).
- Физическая схема OLAP-инструмента должна полностью адаптироваться к специфической аналитической модели для оптимального управления разреженными матрицами. Для любой взятой разреженной матрицы существует одна и только одна оптимальная физическая схема. Эта схема предоставляет максимальную эффективность по памяти и операбельность матрицы, если, конечно, весь набор данных помещается в памяти.
- Многопользовательская поддержка (Multi-User Support). OLAP-инструмент должен предоставлять возможности совместного доступа (запроса и дополнения), целостности и безопасности.
- Неограниченные перекрестные операции (Unrestricted Cross-dimensional Operations). Вычисления и манипуляция данными по любому числу измерений не должны запрещать или ограничивать любые отношения между ячейками данных.
- Интуитивная манипуляция данными (Intuitive Data Manipulation). Манипулирование данными осуществлялось посредством прямых действий над ячейками в режиме просмотра без использования меню и множественных операций. .
- Гибкие возможности генерации отчето в (Flexible Reporting). Измерения должны быть размещены в отчете так, как это нужно пользователю.
- Неограниченная размерность и число уровней агрегации (Unlimited Dimensions and Aggregation Levels). Исследование о возможном числе необходимых измерений, требующихся в аналитической модели, показало, что одновременно может использоваться до 19 измерений. Отсюда вытекает настоятельная рекомендация, чтобы аналитический инструмент был способен одновременно предоставить как минимум 15 измерений, а предпочтительнее 20. Более того, каждое из общих измерений не должно быть ограничено по числу определяемых пользователем-аналитиком уровней агрегации и путей консолидации [2].
Библиографические ссылки
1. Codd E. F., Codd S. B., Salley C. T. Providing OLAP (On-line Analytical Processing) to User-Analysts: An IT Mandate. Codd & Date, Inc, 1993. Retrieved on 2008-12-11.
2. Барсегян А. А., Куприянов М. С., Степаненко В. В., Холод И. И. Методы и модели анализа данных: OLAP и Data Mining. БХВ-Петербург, 2004.
© Демченко А. А., 2014
УДК 004.051
А. К. Казаков Научный руководитель - А. Г. Суворов Сибирский государственный аэрокосмический университет имени академика М. Ф. Решетнева, Красноярск
ПРОБЛЕМЫ СОВРЕМЕННОЙ АВТОМАТИЗАЦИИ
Рассмотрены существующие проблемы автоматизации на предприятиях. Проведен анализ работы сотрудников. Приведены примеры решения проблем современной автоматизации.
Существует проблема взаимодействия системных администраторов и пользователей базы данных. Часто на практике мы получаем такую проблему, у сотрудников работающих с базой данных (БД) престал работать интерфейс, или другой компонент БД. Они звонят в техническую поддержку. Начинаются претензии, зачастую пользователи не могут объяснить проблему, что именно не так, или понять, что от них хочет администратор. Администраторы в свою очередь, не могу объяснить, что нужно сделать, чтобы БД заработала и т. д. И эта проблема встречается не только с администраторами, но и в других сферах деятельности. Что же делать? Повышать квалификацию пользователей, учить психологии и культуре речи администраторов? В ращении этой проблемы нам поможет такая наука как, теория управленческих решений [1].
Пример 1: разделение обязанностей, и деление на группы пользователей. Далее приведены группы пользователей.
Пользователь БД (user) - это физическое или юридическое лицо, которое имеет доступ к БД и пользу-
ется услугами информационной системы для получения информации.
Конечные пользователи. Это основная категория пользователей, в интересах которых создается БД. В зависимости от особенностей создаваемой БД круг конечных пользователей может различаться. Это могут быть случайные пользователи, которые обращаются за информацией к БД время от времени и регулярные пользователи
Администратор базы данных (АМД) - это лицо или группа лиц, отвечающих за выработку требований к базе данных, ее проектирование, создание, эффективное использование и сопровождение.
Администратор сети. В его обязанности входит контроль за функционированием аппаратно-программных средств, реконфигурация сети, восстановление программного обеспечения после сбоев и отказов оборудования, профилактические мероприятия и обеспечение разграничения доступа.
Разработчики и администраторы приложений. Это группа пользователей, которая функционирует
