Проектирование и разработка дополнения

Размещено на http://www.allbest.ru/

Оглавление

Введение

Глава 1. Описание предметной области

1.1 Корпоративное обучение

1.2 История корпоративного электронного обучения

1.3 Система автоматизации корпоративных образовательных процессов WebTutor

1.4 Модель данных системы WebTutor

1.5 Необходимость разработки дополнения к WebTutor и требования к нему

Глава 2. Теоретический базис для разработки решения

2.1 Концепция аналитической обработки данных в реальном времени (OLAP)

2.2 Концепция Business Intelligence

2.3 Выбор методологии и средств проектирования решения

2.3.1 Выбор средства визуализации и анализа данных

Глава 3. Разработка BI-решения

3.1 Первый этап. Разработка хранилища данных

3.1.1 Выделение основных сущностей

3.1.2 Выделение атрибутов сущностей

3.1.3 Модель хранилища данных

3.2 Второй этап. Разработка процедур преобразования и загрузки данных в хранилище

3.3 Третий этап. Разработка OLAP-куба

3.4 Развертывание и тестирование решения на реальных данных

Заключение

Список использованной литературы



Введение

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

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

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

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

Первопроходцем стала компания McDonald's. Она впервые внедрила процесс корпоративного обучения для того, чтобы привить сотрудникам исповедуемые корпоративные ценности на всей территории, где представлен бренд. Позже подобный успешный опыт переняли другие мировые компании в области FMCG и не только. [12]

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

Некоторые компании обладают невероятно большим штатом, распределённым по нескольким континентам. Необходимо вести учет, формировать потребности и организовывать непосредственно само обучение данных сотрудников.

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

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

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

Объектом данного исследования является сфера корпоративного обучения персонала. В свою очередь, предметом исследования - автоматизация организации образовательного процесса с помощью системы управления обучением WebTutor.

Данная работа сосредотачивается на достижении конкретной практической цели: проектировании и разработки некого специального дополнения к системе WebTutor на основе программных продуктов класса Business Intelligence для удовлетворения информационных потребностей основных бизнес-пользователей. Разработанное решение должно содержать функционал, реализующий возможность многомерного анализа данных, для системы поддержки образовательного процесса в организациях.

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

Для разграничения данных понятий известная американская компания Forrester Research, занимающаяся исследованием рынков, предложила два определения понятию Business Intelligence:

Широкое понятие. Business Intelligence представляет собой набор методологий, процессов, архитектур и технологий, которые преобразуют сырые необработанные данные в значимую и полезную информацию, используемую для принятия эффективных стратегических, тактических решений" [4]. В соответствии с этим определением, BI также включает в себя такие технологии, как интеграция данных, качество данных, хранилища данных, анализ данных и так далее.

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

В данной работе Business Intelligence преимущественно будет расцениваться в соответствии с более широким определением.

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

программный информационный бизнес пользователь



Глава 1. Описание предметной области

1.1 Корпоративное обучение

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

Мировой рынок корпоративного обучения находится в постоянном развитии. Согласно прогнозу известной компании TechNavio, специализирующейся на изучении различных рынков, объем глобального рынка корпоративных обучения к 2020 году достигнет 31 млрд. долларов США.[17]

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

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

1.2 История корпоративного электронного обучения

Для описания систем обучения сотрудников компании с помощью информационных технологий используют понятие корпоративное электронное обучение. В зарубежной практике применяется тождественный термин corporate e-learning. Далее представлены основные вехи развития мирового корпоративного электронного обучения.

1990 - 1999 года.

История современного корпоративного электронного обучения начинается с выпуска в производство так называемых компьютерных тренингов (от англ. Computer-Based Training - CBT). Данные тренинги представляли собой самостоятельные обучающие курсы на CD-ROM носителях, воспроизводимые на компьютерах конечных пользователей.

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

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

Очень дорогие: в среднем 4-ех часовой мультимедийный курс стоил от $200,000 до $400,000;

Очень медленная разработка: в среднем разработка 4-ех часового мультимедийного курса требовала от 8 до 10 месяцев;

Неизменяемость структуры: внесение коррективов в законченный и развернутый курс очень трудозатратно.

Поэтому следующим этап развития индустрии стало создание готовых универсальных курсов.

1994 - 1999 года.

Идея предварительной записи CBT-курса на компакт диски и последующая их продажа в большом количестве неограниченному количеству организаций была явной лучшей моделью, при которой поставщик мог получать прибыть и масштабировать свой бизнес. Компании, которые первыми приняли на вооружение данную стратегию развития, скоро стали первыми лидерами данной сферы, а их выручка превышала 100 млн. долларов. Как правило, данные компании не желали предоставлять кастомизацию купленных у них курсов под конкретного заказчика. Большинство разработанных CBT-курсов были посвящены сфере IT, поскольку сотрудники, непосредственно работающие и обслуживающие персональные компьютеры, проще всего воспринимали «новые веяния» корпоративного образования.

Другой причиной, почему первыми были именно IT-курсы, являлся тот факт, что развитие так называемых soft-skill навыков (например, управленческих и коммуникативных навыков) неразрывно связано со сферой их применения. А как уже было сказано выше, на тот момент поставщикам была экономически не выгодна настройка решений под каждого покупателя.

1997-1999 года.

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

Так появился новый тип программного обеспечения - системы управления обучением (от англ. Learning Management Systems - LMS). Данный тип систем призван администрировать, управлять, отслеживать, формировать отчетность по процессам повышения квалификации, проведению аудиторных тренингов и CBT-курсов. Первыми поставщиками такого ПО стали такие компании, как Oracle, IBM/Lotus и многие другие.

Уже на этом этапе встала необходимость введения некоторых строгих стандартов для того, чтобы обеспечить совместимость работы систем управление обучением как с CBT-курсами от различных поставщиков, так и с собственными разработанными курсами на основе купленного программного обеспечения. Впоследствии будет разработан такой стандарт - SCORM, который представляет собой совокупность стандартов и спецификаций для систем дистанционного обучения. Данный стандарт основан на использовании концепции XML-документов и де-факто является определяющим в индустрии.

1999 год.

К этому периоду большинство компаний закончили объединение своих офисов и подразделений в единую интранет-сеть. Внезапно обнаружилась поразительная эффективность перехода от использования компакт дисков к обучению посредством сети. Основные причины такого перехода:

Обучение посредством сети оправдывало часть затрат на развертку интранета;

Внедрение электронного обучения для предметной области куда проще без мероприятий по распределению компакт дисков и их поддержки на бесчисленных ПК пользователей;

Обучение может быть произведено на любой рабочей станции, входящей в сеть;

Длительность использования курса может быть продлена куда проще, так как необходимо установить обновления только на сервер, а не на все рабочие станции;

Интранет объединял слушателей, преподавателей и административный персонал в единую среду.

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

1999 - 2001 год.

Данный период сопровождался бурным развитием сети Интернет и компаний, полностью работающих в ней - доткомов. Это не прошло мимо и индустрии электронного образования.

Многие поставщики электронного обучения (которые уже существовали и которые только для этого и появились) начали предлагать так называемые торговые витрины с централизованно управляемым веб-контентом, доступным на всех предприятиях «где угодно» и «когда угодно». Витрины располагались на образовательных порталах, а их огромное количество стремилось компенсировать низкое качество контента и отсутствие кастомизации под какую-либо сферу. Управление порталами основалось на функциональности lms-систем.

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

Настоящее время.

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

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

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

Стало возможным развитие такой технологии как виртуальный класс. Данная технология представляет возможность обеспечить взаимодействие между преподавателем и группой слушателей в режиме реального времени, а результаты их обучения будут все также учтены в lms-системе. Данная технология позволяет оживить процесс обучения.

Можно сказать, что индустрия полностью извлекла урок из своей истории, и теперь подавляющее большинство разработчиков полностью переориентировались на потребности клиента. Разработка курсов ведется при непосредственном взаимодействии с заказчиком. Конечно, существуют разработанные отраслевые решения, подходящие большинству компаний из соответствующей сферы. Но при необходимости в них можно относительно безболезненно внести коррективы согласно требованиям заказчика.

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

1.3 Система автоматизации корпоративных образовательных процессов WebTutor

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

WebTutor -- система комплексной автоматизации бизнес-процессов, связанных с подбором, оценкой, тестированием и обучением персонала, управлением талантами, систематизацией и хранением знаний, а также с организацией корпоративных коммуникаций и взаимодействия между сотрудниками и HR-подразделением. [28]

Компания WebTutor является разработчиком и сопроводителем данной системы. Компания присутствует на рынке автоматизации HR бизнес-процессов с 1999 года и имеет уже более 1500 клиентов на территории РФ и СНГ. Согласно информации, предоставленной агентством «Интерфакс-ЦЭА», на 1 января 2009 года системой WebTutor пользуются 9 из 10 крупнейших российских банков. [28]

Что касается отечественного рынка в целом: согласно опросу, проведенному на Саммите профессиональных разработчиков электронных курсов в 2011 году в Москве, в российском корпоративном секторе систему WebTutor используют 55% всех опрошенных. Иллюстрация 1.1 демонстрирует результаты ответов и их процентное соотношение. [28]

Иллюстрация 1.1: Результаты опроса, используемой СДО. Источник: www.websoft.ru.

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

Иллюстрация 1.1 демонстрирует, что на верхнем уровне детализации система содержит шесть функциональных блоков - модулей, которые соответствуют основным задачам корпоративных учебных центров и HR подразделений:

обучение и развитие;

оценка персонала;

тестирование;

подбор персонала;

интеграционная платформа;

портал знаний.

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

Иллюстрация 1.2: Модульная система организации приложения. Источник: www.websoft.ru.

Иллюстрация 1.3 наглядно демонстрирует схему взаимодействия основных компонентов системы. Далее дано краткое пояснение по каждому компоненту взаимодействия (с верхнего элемента по часовой стрелке).



Иллюстрация 1.3: Схема взаимодействия компонентов Системы. Источник: www.websoft.ru.

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

Администратор получает доступ к приложению WebTutor Administrator. С помощью этого приложения производятся все настройки справочников, параметров системы, структуры портала. Посредством приложения сотрудники, занятые организацией и непосредственным проведением обучения, назначают курсы и тестирование, создают образовательные мероприятия, получают отчетность и так далее.

Система содержит средства импорта данных из файлов различных типов (например, MS Excel, XML), а также может быть интегрирована с различными ERP и CRM системами (например, 1С, SAP HR, Oracle EBS). Типовым решением является ежедневная выгрузка из других источников актуального состояния штата компании: новых и уволенных сотрудников, изменения отпускного и декретного статуса.

Опционально существует возможность реализации образовательного портала как компонента платформы Microsoft Office SharePoint Server. С другой стороны, возможна настройка авторизации в системе WebTutor относительно сторонних систем (например, Active Directory).

Посредством взаимодействия с почтовым сервером по SMTP или MAPI протоколам осуществляется рассылка настраиваемых почтовых уведомлений. Система позволяет настроить отправку уведомлений по расписанию или вследствие происшествия каких-либо системных событий.

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

1.4 Модель данных системы WebTutor

Система управления обучением WebTutor разработана на базе платформы SP-XML. Данная платформа представляет собой средство быстрой разработки приложений и включает в себя следующее составляющие:

средства описания структур данных, основанные на XML документах;

встроенную систему управления базой данных, включающую полнотекстовый поиск;

средства описания экранных форм интерфейса пользователя;

встроенный интерпретатор языка JavaScript;

встроенный сервер, реализующий возможность создавать клиент-серверные приложения, веб-интерфейсы и самостоятельный веб-сайты;

средства интеграции со сторонним программным обеспечением;

средства работы с сетевыми протоколами (например, HTTP, SMTP, POP3, IMAP);

встроенный универсальный компонент создания плагинов в Internet Explorer и Microsoft Outlook. [31]

Можно утверждать, что платформа SP-XML является самодостаточной для разработки каких-либо приложений. Более того, она, как правило, не требует от пользователя знаний других языков и технологий программирования. Данную платформу можно сравнить с программным продуктом IBM Notes (старое название -- Lotus Notes). Отличительной особенностью SP-XML является ее полная встраиваемость: при работе конечный пользователь ничего не будет знать о платформе до тех пор, пока не захочет изменить решение под свои нужды. Для конечного пользователя запущенное приложение будет являться обычным программным продуктом под ОС Windows.

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

Система WebTutor разработана таким образом, что основной программный код не работает напрямую с данными, хранящимися в таблицах СУБД и файлах. Напротив, бизнес-логика системы WebTutor непосредственно взаимодействует с неким логическим представлением данных. Данные на логическом уровне автоматически преобразуются в их физическое представление. Данное преобразование абсолютно прозрачно для основного программного кода. Иллюстрация 1.4 наглядно иллюстрирует иерархию взаимодействия различных уровней приложения.



Иллюстрация 1.4: Иерархия взаимодействия уровней системы.

На логическом уровне все хранящиеся в Системе данные являются совокупностью неких информационных объектов. Каждый объект принадлежит какому-либо заранее определенному типу. Примером типов объектов будут являться: мероприятие, сотрудник организации, электронный учебный курс и т.д. Объекты одних типов могут быть связаны (иметь ссылки) с другими. Иллюстрация 1.5 демонстрирует такую связь: сотрудники организации являются участниками прохождения корпоративных курсов.

Иллюстрация 1.5: Отношения между объектами.

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

базовый: строковый тип данных, числовой тип данных, дата и т.д.

составной: массивы.

Иллюстрация 1.6 демонстрирует типовой состав абстрактного объекта.



Иллюстрация 1.6: Атрибуты объекта.

На физическом уровне объект представляет собой xml-файл. Важно отметить, что любому одному объекту соответствует один xml-файл. XML-документ является основной и единственной единицей информации Системы. Каждому типу XML-документа (типу объекта на логическом уровне) соответствует описание его схемы - XSD-файл.

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

Иллюстрация 1.7: Объект и его каталог.

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

Как уже было отмечено выше, платформа SP-XML включает в себя встроенную СУБД.

База данных представляет собой просто файлы в файловой системе и располагается в папке с названием wt_data. XML-файлы, характеризующие объекты, хранятся в папке wt_data/objects. В свою очередь, каталоги, представляющие собой бинарные индексные файлы, хранятся в папке wt_data/catalogs и имеют расширение xdb.

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

Стандартным сценарием использования языка является выборка идентификаторов объекта по ключевым полям, вынесенным в каталог. Далее при переборе полученных идентификаторов с помощью встроенных программных средств открываются непосредственно сами объекты и получается доступ ко всем полям этих объектов.

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

Для данных целей используется абстрактный провайдер СУБД - UniBridge. Данный провайдер поддерживает возможность хранения данных в СУБД MS SQL Server версии 2005 и новее, а также Oracle 10g и новее. Данный провайдер является COM-библиотекой и поддерживает набор функций для осуществления транзакций. Абсолютно все операции обмена данных осуществляются через данный компонент.

Иллюстрация 1.8 наглядно демонстрирует роль провайдера в схеме взаимодействия сервера и внешней СУБД.

Иллюстрация 1.8: Роль провайдера.

Согласно иллюстрации, компонент получает инструкции на извлечение (PutUrl), добавление (LoadUrl), удаление объекта (DeleteUrl) или непосредственно запрос на языке SQL (XQuery). В случае запроса на добавление/удаления возвращает результаты операции, в случае извлечения - сам объект, а в случае запроса - коллекцию значений документов.

Во внешних СУБД данные хранятся следующим образом. Каждому типу объекта в системе WebTutor соответствует одноименная таблица базы данных. Данные таблицы создаются на основе xsd-схем типов объектов. Для примера на иллюстрации 1.9 предоставлена таблица collaborator, которая соответствует типу объекта «Сотрудник». Каждая запись таблицы содержит 64-ех битный идентификатор записи и поле data типа XML, в котором содержится непосредственно сам объект (в формате XML).



Иллюстрация 1.9: фрагмент диаграммы базы данных WebTutor.

Каждой таблице, характеризующей тип документа, сопоставлен каталог. Название каталога формируется по формуле: название каталога = название типа объекта + латинский символ S. На иллюстрации 1.9 таковой является таблица collaborators. В каталог вынесены основные поля, по которым можно осуществить запрос без потери производительности. Как можно заметить, тип объекта и каталог не связаны на уровне ограничений целостности базы данных, а только логически - по идентификатору. Это связано, прежде всего, с тем, что каталоги могут содержать какие-либо данные, непривязанные к соответствующим документам.

На основе связи по первичному ключу каждый объект связан с его формой (а точнее с путем в файловой системе, по которому располагается форма): поля spxml_form таблицы (spxml_objects).

Вся не структурируемая информация содержится в таблице (spxml_blobs). Примером такой информации могут служить фотографии или документ MS Word. Дополнительные таблицы (spxml_foreign_arrays) и (spxml_metadata) содержат системную информацию по каталогам и их связи между собой.

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

1.5 Необходимость разработки дополнения к WebTutor и требования к нему

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

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

Как уже было сказано ранее в работе, подавляющее большинство крупных российских компаний с учебными центрами используют систему WebTutor. Данная отчётность формируется на основе данных, хранящихся в ней. WebTutor предоставляет функционал формирования различных типов отчетов, создаваемых непосредственно пользователем под свои задачи. Но данный компонент является скорее инструментом общего назначения: подходит под решение относительно тривиальных задач. Более того, отсутствует возможность создавать так называемые сводные отчеты (от англ. pivot table), невозможно представить данные в виде раскрывающихся иерархий различных типов. Перечисленные выше причины приводят к тому, что пользователи пользуются программными средствами WT и языком SQL для формирования необходимых отчетов.

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

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

Сложная модель хранения данных. Даже в рамках одной СУБД часть данных представляет собой стандартные ячейки таблиц, другие данные хранятся в полях типа XML. Такие промышленные СУБД как MS SQL Server и Oracle, предоставляют средства работы с XML деревьями. Однако операции их объединения (join) с другими данными крайне не производительны.

Повышенные требования к квалификации разработчиков. Как правило, системное администрирование системы WebTutor возлагается на IT-департаменты компаний, а непосредственных разработка дополнительных модулей и надстроек ведется уже непосредственно сотрудниками учебных центров. Часто данные сотрудники не обладают достаточной квалификацией для разработки подобных запросов.

Повышенные временные затраты. В большинстве случаев, штат профессиональных программистов под систему WT ограничивается одним или двумя сотрудниками. Разработка случайных и постоянно меняющихся типов иерархических отчетов является второстепенной задачей, но отнимает у них много времени.

Большой объем данных. Многие компании за последнее десятилетие аккумулировали информацию по различным типам организованного обучения. Сам по себе накопленный объем данных не является критическим для промышленных СУБД. Но в связи с тем, что часть данных хранится в нереляционной форме (XML), размер данных становится самостоятельной проблемой.

Далее представлен пример типовой проблемы, с которой сталкиваются пользователи. В системе WebTutor существует возможность создавать различные пользовательские категории и организовывать их в иерархии. Различные информационные объекты (например, курс, мероприятие и т.д.) можно отнести в какую-либо категорию. Это является очень удобным настраиваемым способом группировки различной информации, поэтому часто применятся пользователями. Однако формирование отчетности с учетом иерархии категорий крайне затруднено, потому что запись о принадлежности объекта категории хранится в ячейке типа XML (см. иллюстрацию 1.10). Производительность операций объединения (join) большого объема данных с такими ячейками довольно низкая и требует от пользователя продвинутых знаний SQL.

Иллюстрация 1.10: реализация принадлежности объекта категории.

Можно заметить, что перечисленные выше проблемы являются типичными для транзакционных систем, представителем которых и является WebTutor. Следовательно, решением данных проблем будет разработка некого специального дополнения к системе на основе программных продуктов класса BI, реализующее применение OLAP концепций. Основное требование к нему звучит следующим образом: стандартный функционал решения должен быть относительно легко внедряем в абсолютно разных компаниях, использующих программный продукт WebTutor, без его кастомизации под конкретного заказчика. Это означает, что теоретически потенциальный заказчик может развернуть решение своими силами и без знаний о том, как оно реализовано. Данное требование осуществимо, прежде всего, из-за того, что тип, состав и структура источников данных для решения заранее определены, а меняются лишь строки подключения к ним - разные адреса серверов и относительные пути расположения в файловой системе.

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

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

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

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

Часто перед организаторами обучения стоит задача выбрать оптимальный временной интервал проведения какого-либо образовательного мероприятия. Для этого им требуется средние данные об отсутствии сотрудников на рабочем месте в различные временные периоды по любым причинам: болезнь, отъезд в командировку и т.д.

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

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



Глава 2. Теоретический базис для разработки решения

2.1 Концепция аналитической обработки данных в реальном времени (OLAP)

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

Реляционная модель является центральной частью так называемого процесса оперативной обработки транзакций (от англ. OnLine Transaction Processing - OLTP), которую Эдгар Кодд называл «общей концепцией управления базами данных в реляционной форме». [2] Программное обеспечение, которое используется для работы с базами данных, называется системами управления базами данных (СУБД). В свою очередь, термин реляционные системы управления базами данных (РСУБД) используется для подчеркивания того факта, что эта СУБД является реляционной. Прилагательное «реляционная» относится к фундаментальным принципам модели, согласно которым данные представлены с помощью математических отношений. В свою очередь, математические отношения реализуются в виде таблиц.

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

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

В качестве решения вышеуказанных проблем была предложена концепция аналитической обработки данных в реальном времени (от англ. Online Analytical Processing - OLAP). Данная концепция широко обсуждалась на протяжении последних лет, и было написано немало работ по этой тематике.

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

В 1993 году Кодд и другие исследователи опубликовали документ, в котором обсуждалась потребность в OLAP-сервисах. Они свели требования, предъявляемые к OLAP, в следующие двенадцать правил:

Многомерное концептуальное представление данных (от англ. Multidimensional Conceptual View). Поскольку проводимый анализ по своей природе сам многомерный, то и представление для конечного пользователя OLAP модели должно быть многомерным. Но стоит отметить, что многомерное представления данных для пользователя не обязательно означает, что фактически данные хранится в многомерном виде.

Прозрачность (от англ. Transparency). Архитектура OLAP должна быть прозрачной: Например, такие факты, как наличие клиент-сервер архитектура приложения, должны быть прозрачными для пользователя.

Доступность (от англ. Accessibility). Инструмент OLAP должен иметь возможность сопоставить свою собственную логическую схему на данные, собранные из различных гетерогенных реляционных и не реляционных источников. Конечного пользователя не должно волновать то, откуда берутся данные, или, как они физически хранятся; данные должны выглядеть, как единое согласованное представление.

Устойчивая производительность при формировании отчетов (от англ. Consistent Reporting Performance). При увеличении числа измерений и размера базы данных пользователь не должен заметить какого-либо существенного ухудшения производительности при формировании отчетности. В случаях, когда производительность становится проблемой, OLAP инструмент может предложить альтернативные решения: например, представление информации в каком-либо ином виде.

Клиент-серверная архитектура (от англ. Client-Server Architecture). Поскольку куб часто представляет собой централизованный репозиторий, к которому имеют удаленный доступ клиентские приложения, необходимым условием для OLAP инструментов является возможность работать в клиент-серверной среде.

Равноправие измерений (от англ. Generic Dimensionality). Все измерения должны быть эквивалентны по своей структуре и операционным возможностям. Могут существовать дополнительные особенности, присущие конкретными измерениям, но основная структура должна быть одинаковой для всех измерений. Также должна быть возможность предоставления дополнительных функций любому из измерений.

Динамическая обработка разреженных матриц (от англ. Dynamic Sparse Matrix Handling). Типичный куб данных очень разряжен Преимущественно нулевые значения элементов. Таким образом, OLAP инструмент должен оптимально обрабатывать разряженные матрицы, чтобы не позволить размеру куба чрезмерно вырасти. Нет необходимости производить агрегированные вычисления для каждой возможной ячейки в кубе, если только небольшая доля от общего количества фактически содержит данные.

Поддержка многопользовательский режима (от англ. Multi-User Support). OLAP инструменты должны обеспечивать возможность одновременной работы с данными и OLAP моделью нескольких пользователями, при которой сохраняется целостность и безопасность.

Неограниченные операции над измерениями (от англ. Unrestricted Cross-dimensional Operations). OLAP инструмент должен иметь возможность производить стандартные вычисления и другие операции над измерениями, не требуя от пользователя явного указания фактического вычисления (формулы). Также инструмент должен предоставлять некий пользовательский язык для того, чтобы пользователь мог задать желаемые операции.

Интуитивно понятное обращение с данными (от англ. Intuitive Data Manipulation). Свертка (от англ. roll-ups), развертка (от англ. drill-downs) и другие операции, которые лежат в самой сути иерархий измерений, должны быть легко доступны посредством прямого обращения к отображаемым данным. Дополнительно они не должны требовать избыточных операций обращения к пользовательскому интерфейсу, таких как меню навигации.

Гибкая настройка генерации отчетов (от англ. Flexible Reporting). Отчетность должна быть гибкой в том смысле, что строки, столбцы и заголовки страниц в полученном отчете должны быть в состоянии содержать любое число измерений модели данных, и что каждое выбранное измерение должно иметь возможность отобразить свои элементы и отношение с ними.

Неограниченный набор измерений и уровней агрегаций (от англ. Unlimited Dimensions and Aggregation Levels). В статье Кодд и др. заявляет, что серьезный OLAP инструмент должен быть в состоянии обрабатывать по меньшей мере, пятнадцать, а лучше двадцать измерений внутри одной модели. Скорее всего, это правило должно быть расширено для того, чтобы позволить обрабатывать неограниченное количество измерений. В любом случае, он также отметил, что каждое измерение должно предусматривать неограниченное количество определенных пользователем уровней агрегации в иерархии измерений.[10]

В этом документе четко указано, что OLAP не должна быть реализована в виде новой технологии баз данных, так как реляционная модель баз данных является «наиболее подходящей технологией для корпоративных баз данных». В нем также говорится, что реляционная модель никогда не была предназначена для соответствия требованиям OLAP инструментов, но что такие услуги могут быть предоставлены отдельным пользовательскими инструментами, которые дополняют содержащие данные РСУБД. [2]



2.2 Концепция Business Intelligence

Концепция OLAP находит свою реализацию в качестве компонента программных продуктов класса Business Intelligence (BI). Business Intelligence представляет собой концепцию, специально разработанную для сбора и проведения анализа собранных данных. Целю данного анализа является предоставление принимающим решения лицам наиболее полной и исчерпывающей информации о процессах, протекающих в организации. На основе данной информации появляется возможность принимать лучшие бизнес-решения.

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

Хранилище данных и ETL-процедуры.

Центральным элементом концепции является, несомненно, хранилище данных, которое представляет собой «копию транзакционных данных, специально структурированную для запросов и анализа». [8] Это определение дано известным экспертом в области хранилищ данных Ральфом Кимбаллом. Хотя существует несколько различных подходов к определению понятия и самой структуры организации хранилищ данных (например, подход Билла Инмона, «data vault» Дэниэла Линстедта и т.д.), в данной работе будет использоваться методология именно Ральфа Кимбалла.

Такое хранилище данных реализуется в виде реляционной базы данных с таблицами двух типов: таблицы измерений и таблицы фактов. «Фактом» является зафиксированное числовое измерение какого-либо события. Как правило, строки в таблице фактов представляют транзакционные данные или отражают состояние процесса в определенный момент времени. Таблица фактов содержит так называемые метрики, над которыми имеет смысл проводить операции агрегации (суммирование, умножение и т.д.). Дополнительно таблицы фактов содержат ссылки (внешние ключи) на таблицы измерений. «Измерения» являются ссылочной информацией, предоставляющей контекст фактам. Обычно таблицы измерений не содержат большое количество записей, но обладают многими атрибутами. По атрибутам измерений и происходит агрегация метрик фактов. Типичным измерением, присутствующим во всех хранилищах данных и делающим данные в нем историческими, является календарь.

...